デザイン思考によるシステム開発と注意点
株式会社NTTデータエンジニアリングシステムズ 新事業企画室 企画部 加藤 智之, Dr. Eng. |
システムズエンジニアリングについて3回連載でお届けします。今回で最終回となる連載Vol.3です。
はじめに
前回は設計とシステムズエンジニアリング(SE)、デザイン思考の関係について学術的な観点を交えて眺めて見ました。今回はデザイン思考で活用されるプロトタイピングのような考え方が、SEに対してどのように寄与するのかについて、V字モデルをもとに考えてみます。
デザイン思考からみるV字モデル
開発工程とテスト工程の関係をV字型で表現したV字モデルは、多くの方がご存じだと思います。このモデルは、1989年のBoehmの論文[1]にて言及されています。V字モデルの特徴は、成果物のレベルで設計工程の段階およびテスト工程の段階をV時の左右で対応させていることです。V字モデルを使うメリットとして、開発段階に伴う成果物レベルに応じたテストを設計できることから、役割分担が明確になる、プロジェクトの進行状況を把握しやすい、などが挙げられます。一方で、各段階の設計における適否については、各々の段階に対応するテストが完了するまで不明というデメリットがあります。図1はV字モデルによる開発の課題を示したものです。開発が進むまでどこに誤りがあるか分かりづらいという問題に対処するためには、各段階の成果物を正しく評価することが必要です。要求工学の連載[2]で山本修一郎氏は、各工程の成果物を評価する上で、図2のような動的V字モデルを提唱しています。各段階において、その上位の成果物の設計情報(図2中の要求モデル、システムモデル、アーキテクチャモデルを指す)をアップデートし、間違いがないか判別することで、後工程で問題が発生した手戻りを防止できます。この動的V字モデルの考え方は、デザイン思考でいうところのプロトタイピングを行うことに非常に近いといえます。動的V字モデルではプロトタイプではないものの、実際にできた成果物を元に、そこまでに想定した上位の成果物における妥当性の確認(Validation)を行っているとみなすことができます。
アジャイル開発との対比
既存のV字モデルのデメリットは、ウォーターフォール型の開発を前提としているために起こります。ウォーターフォール型開発のデメリットを克服する方法にアジャイル開発が挙げられます。アジャイル開発は、まさにデザイン思考的なアプローチによる開発であるといえます。2001年に宣言されたアジャイルソフトウェア開発宣言[3]では、図3に示すようにドキュメントやプロセスよりも顧客の求める動くものをアウトプットすることを指向する考え方を示しています。デザイン思考のプロトタイピングでは、綿密な計画や設計をすることなく、作ろうとしているもののコアとなるような機能のみにフォーカスして作ります。まずは、主要な機能のみにフォーカスした動くものを作り、それが顧客に受け入れられるかどうかを判断していくようなデザイン思考の考え方は、アジャイル開発の考え方と非常に親和性が高いと考えられます。一方で、アジャイル開発にも問題点があります。
アジャイル開発の主眼は、製品をアウトプットすることであり、ドキュメントやプロセスはあまり考慮されていません。それを拡大解釈してドキュメントを残さなくても構わないという認識や、プロセスを無視して製品開発のみを最大効率化すれば問題ないという認識などの誤解を招くことが多くあります。そのような誤った認識が流布してしまうと、次のような問題が発生しうると考えられます。なお、これらの問題は製造業の研究開発プロジェクトを前提に議論しています[4]。
(1)プロジェクトの時間切れによる網羅性の欠如
新技術開発プロジェクトが未完了のまま製品開発プロジェクトでの技術開発が実施されている状況では、必ずしも新技術の全てを手の内に収めた状況とは言いがたく、製品開発プロジェクトで発生する不具合に対処しているにすぎないと考えることができます。この場合、市場に出した時に致命的となる不具合には対応できていますが、限定的な状況において発生する不具合は対応できないまま、プロジェクトが時間切れとなることが想定されます。そのまま不具合が発生しなければ問題にはなりませんが、複雑化した製品の技術的な手の内を網羅的に把握できていない状態を残しておくことはリスクが高いと考えられます。
(2)属人化による再現性の欠如
アジャイル的にプロジェクトの中で不具合に対応することは、プロジェクトの視点から言えば最終製品で不具合がない状態にできるため、むしろメリットに見えます。アジャイル的にプロジェクトをこなせるプロジェクトマネジャーは、さまざまなことを同時にこなすことが多く、会社では重宝されがちな人材と推測できます。そういったプロジェクトマネジャーは、常にプロジェクトに関与することが多くなる可能性が高くなります。そうすると、当該プロジェクトマネジャーにはアジャイルでのプロジェクトマネジメントを行うための勘所や技術的な要所が知見として蓄積していきます。しかし、それを組織のプロセス資産として整理整頓および、誰もが再現できる仕組みとして出し切る時間が取れないことが想定できます。結果的に、当該プロジェクトマネジャーがいなくなった時に暗黙知になってしまい、俗人化する問題が発生します。
(3)環境変化への柔軟性の欠如
環境変化への対応において、アジャイルは非常に適した方法であるように見えます。実際、プロジェクト単位で成否を見れば、アジャイル開発によるプロジェクトの方が環境の変化に対応できていることは多くあります。しかし、上記の属人化の話のように、環境変化に特定の個人が強いだけであり、組織として強いわけでありません。つまり、アジャイルでプロジェクトマネジメントを行っても組織が環境変化に柔軟に対応できるわけではないということです。
以上の問題点を考えると、アジャイル開発を盲目的に進めることは得策ではないと言えます。そこで、アジャイル開発の柔軟さとウォーターフォール開発の厳格さを取り入れたハイブリッド型の開発が有効であると考えられます。このハイブリッド型の開発方法は、お客さまの業界の環境やお客さまが置かれている状況によってどうあるべきかが変わります。ここで重要なことは、そのようなお客さまのコンテキストに合わせた開発の仕組みを整えることです。私たちは、そのような相談から開発プロセスの実装までご支援する体制を整えております。お気軽にご相談ください。
おわりに
これまで3回にわたりシステムズエンジニアリングに関する情報を展開してきました。今後、読者の皆さまからのご要望に応じて解説記事を掲載することも可能ですのでお気軽にお申し付けいただければと思います。
〈参考文献〉
[1] B. Boehm「Guidelines for Verifying and Validating Software Requirements and Design Specifications」IEEE Software、Computer Science、1989
[2] 山本修一郎「要求モデリングと誤り」株式会社ビジネスコミュニケーション社、月刊ビジネスコミュニケーション、2008年10月号、https://www.bcm.co.jp/site/youkyu/youkyu48.html(外部サイトへ移動します)、2008
[3] Kent Beck他「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/manifesto.html(外部サイトへ移動します)、2001
[4] 加藤智之「製造業はアジャイルで終わらせることなかれ」P2MマガジンNo.14、pp69-72、一般社団法人P2M学会、2022
関連するソリューション
関連するソリューションの記事
- 2024年07月25日
-
システムズエンジニアリング 連載番外編
ドイツにおけるバーチャル開発に関する調査について
- 2024年04月01日
- 第16回「オートモーティブワールド」 展示会レポート
- 2023年07月01日
-
システムズエンジニアリング 連載vol.2
デザイン思考とシステムズエンジニアリング
- 2023年01月10日
-
システムズエンジニアリング 連載vol.1
新しい仕組みに変えるとは
- 2022年01月15日
-
MBSE・MBDソリューション領域における
NDESの取り組み
- 2021年07月10日
-
4事業部のご紹介(1)
オートモーティブソリューション事業部