これって、いわゆるEAでのパターン・モデル技法だな。
開発技法を統一して、開発の「進め方」をモデル・テンプレートで揺るぎないようにする方法は
もう10年以上の歴史があるけど、
これは一歩進んで、「出来上がり像」もモデル・テンプレートに従って作ることで
効果・効率を底上げ(*)しようとするものよね。
��同じ考え方で、すでに、2年前にお客さんに
��提案・納入しているねぇ＞某N河統括殿、某F里大アナリスト殿
��社内でも、始めたいところ。ねぇ？＞某S田大部長殿
(*)なぜ「底上げ」と書いたかは、標準化による最適化？を参照
ちなみに、昔は「出来上がり像」の統一化・モデル化は不要だったんだと思う。
なぜなら、メインフレームという「統一アーキテクチャ」があり、その上で「どのようなアプリケーションソフトウエアを作るか、そしてそれをどう進めて作るか」だけを考えれば良かっただろうから。
��社内には、分からんチンが多いから、
��もう一度説明しようかな。
これは会社の業務活動改善という視点かな。消費者向けの製品にこの手法を適用するのは、理解してもらうのが大変でコストが高すぎるけど、設備関連の製品は顧客もある程度知識があるので効果的だと思う。
返信削除機能が使用する要素技術への知識共有が前提となると思う。
もうひとつ、マトリックスの活用法として、社内で営業と開発が分立しているとき、営業はこのマトリックスを使って開発に指示を出してくれないかなと思う。
機能が汎用的であるほど（たとえば、「セキュリティ管理」)プロダクト別に見てばらつきが少なくなることが期待できる。A製品はレベル5、Bは3とか。