はじめに

前回は設計とシステムズエンジニアリング（SE）、デザイン思考の関係について学術的な観点を交えて眺めて見ました。今回はデザイン思考で活用されるプロトタイピングのような考え方が、SEに対してどのように寄与するのかについて、V字モデルをもとに考えてみます。

デザイン思考からみるV字モデル

開発工程とテスト工程の関係をV字型で表現したV字モデルは、多くの方がご存じだと思います。このモデルは、1989年のBoehmの論文^［1］にて言及されています。V字モデルの特徴は、成果物のレベルで設計工程の段階およびテスト工程の段階をV時の左右で対応させていることです。V字モデルを使うメリットとして、開発段階に伴う成果物レベルに応じたテストを設計できることから、役割分担が明確になる、プロジェクトの進行状況を把握しやすい、などが挙げられます。一方で、各段階の設計における適否については、各々の段階に対応するテストが完了するまで不明というデメリットがあります。図1はV字モデルによる開発の課題を示したものです。開発が進むまでどこに誤りがあるか分かりづらいという問題に対処するためには、各段階の成果物を正しく評価することが必要です。要求工学の連載^［2］で山本修一郎氏は、各工程の成果物を評価する上で、図2のような動的V字モデルを提唱しています。各段階において、その上位の成果物の設計情報（図2中の要求モデル、システムモデル、アーキテクチャモデルを指す）をアップデートし、間違いがないか判別することで、後工程で問題が発生した手戻りを防止できます。この動的Ｖ字モデルの考え方は、デザイン思考でいうところのプロトタイピングを行うことに非常に近いといえます。動的Ｖ字モデルではプロトタイプではないものの、実際にできた成果物を元に、そこまでに想定した上位の成果物における妥当性の確認（Validation）を行っているとみなすことができます。

アジャイル開発との対比

既存のＶ字モデルのデメリットは、ウォーターフォール型の開発を前提としているために起こります。ウォーターフォール型開発のデメリットを克服する方法にアジャイル開発が挙げられます。アジャイル開発は、まさにデザイン思考的なアプローチによる開発であるといえます。2001年に宣言されたアジャイルソフトウェア開発宣言^［3］では、図3に示すようにドキュメントやプロセスよりも顧客の求める動くものをアウトプットすることを指向する考え方を示しています。デザイン思考のプロトタイピングでは、綿密な計画や設計をすることなく、作ろうとしているもののコアとなるような機能のみにフォーカスして作ります。まずは、主要な機能のみにフォーカスした動くものを作り、それが顧客に受け入れられるかどうかを判断していくようなデザイン思考の考え方は、アジャイル開発の考え方と非常に親和性が高いと考えられます。一方で、アジャイル開発にも問題点があります。

アジャイル開発の主眼は、製品をアウトプットすることであり、ドキュメントやプロセスはあまり考慮されていません。それを拡大解釈してドキュメントを残さなくても構わないという認識や、プロセスを無視して製品開発のみを最大効率化すれば問題ないという認識などの誤解を招くことが多くあります。そのような誤った認識が流布してしまうと、次のような問題が発生しうると考えられます。なお、これらの問題は製造業の研究開発プロジェクトを前提に議論しています^［4］。

(1)プロジェクトの時間切れによる網羅性の欠如

新技術開発プロジェクトが未完了のまま製品開発プロジェクトでの技術開発が実施されている状況では、必ずしも新技術の全てを手の内に収めた状況とは言いがたく、製品開発プロジェクトで発生する不具合に対処しているにすぎないと考えることができます。この場合、市場に出した時に致命的となる不具合には対応できていますが、限定的な状況において発生する不具合は対応できないまま、プロジェクトが時間切れとなることが想定されます。そのまま不具合が発生しなければ問題にはなりませんが、複雑化した製品の技術的な手の内を網羅的に把握できていない状態を残しておくことはリスクが高いと考えられます。

(2)属人化による再現性の欠如

アジャイル的にプロジェクトの中で不具合に対応することは、プロジェクトの視点から言えば最終製品で不具合がない状態にできるため、むしろメリットに見えます。アジャイル的にプロジェクトをこなせるプロジェクトマネジャーは、さまざまなことを同時にこなすことが多く、会社では重宝されがちな人材と推測できます。そういったプロジェクトマネジャーは、常にプロジェクトに関与することが多くなる可能性が高くなります。そうすると、当該プロジェクトマネジャーにはアジャイルでのプロジェクトマネジメントを行うための勘所や技術的な要所が知見として蓄積していきます。しかし、それを組織のプロセス資産として整理整頓および、誰もが再現できる仕組みとして出し切る時間が取れないことが想定できます。結果的に、当該プロジェクトマネジャーがいなくなった時に暗黙知になってしまい、俗人化する問題が発生します。

(3)環境変化への柔軟性の欠如

環境変化への対応において、アジャイルは非常に適した方法であるように見えます。実際、プロジェクト単位で成否を見れば、アジャイル開発によるプロジェクトの方が環境の変化に対応できていることは多くあります。しかし、上記の属人化の話のように、環境変化に特定の個人が強いだけであり、組織として強いわけでありません。つまり、アジャイルでプロジェクトマネジメントを行っても組織が環境変化に柔軟に対応できるわけではないということです。

以上の問題点を考えると、アジャイル開発を盲目的に進めることは得策ではないと言えます。そこで、アジャイル開発の柔軟さとウォーターフォール開発の厳格さを取り入れたハイブリッド型の開発が有効であると考えられます。このハイブリッド型の開発方法は、お客さまの業界の環境やお客さまが置かれている状況によってどうあるべきかが変わります。ここで重要なことは、そのようなお客さまのコンテキストに合わせた開発の仕組みを整えることです。私たちは、そのような相談から開発プロセスの実装までご支援する体制を整えております。お気軽にご相談ください。

おわりに

　これまで3回にわたりシステムズエンジニアリングに関する情報を展開してきました。今後、読者の皆さまからのご要望に応じて解説記事を掲載することも可能ですのでお気軽にお申し付けいただければと思います。

関連するソリューション

• MBSE/MBDソリューション

関連するソリューションの記事