パターンに基づくプロセス設計

Ｖ字モデルと問題解決プロセス

前回紹介したＶ字モデルは図1の問題解決プロセスを図2のように入れ子にしています。

この場合の『問題』は顧客要求であり、それを『要求定義』で整理します。整理した要求に基づき、「どのようなシステムを開発することで要求を満たすか」を考えます。要求を満たす解法がシステムであり、システム仕様を考えることが『基本設計』です。この段階での『設計モデル』はシステム仕様ということになります。

システム仕様に基づきシステムを現実化することが『実装』です。実装により現実化されたシステムが顧客要求を満たすことを『受け入れテスト』で検証します。

『実装』の過程はもう１つのサイクルが入れ子になります。今度はシステム仕様を現実化することが『問題』になります。システム仕様を現実化するという問題について『分析』を行い問題を整理します。整理された問題に対して解法を考えるのが『詳細設計』です。

次に、『実装』によりプログラムを書き、システムを現実化します。システムが正しく現実化されていることを検証するのが『システムテスト』です。

このように『分析→設計→実装→検証』のプロセスを繰り返し、かつ入れ子にすることで複雑な問題を解決します。

選択→発散→収束

分析や設計などのように物事を検討、思考する時に、図3のサイクルが役に立ちます。プロジェクトの問題解決ミーティングをチームで行う場合にも有効です。

検討のプロセスは、論点を選択することから始まります。論点は、目的、テーマ、議題、問題とも言えます。例えば、「問題は何か？」「問題をどのように解決するか？」などの「問い」が論点になります。論点は「問い」として定義すると次に行う発散がしやすくなります。

論点を選択したら、論点から思い付くことを自由に発想していきます。この過程を『発散』と呼びます。思い付くままに意見や要素などの『項目』を洗い出します。思い付くことは全て書き出し、記録するくらいのつもりで連想していくと効率的です。もし何も思い付かない場合には論点が曖昧すぎるのかもしれません。

例えば、「チームの問題について」よりは「チームの問題は何か？」「チームの問題をどのように減らすか？」の方が具体的です。また、普段から馴染みのある論点の方が項目を思い付きやすくなります。例えば、「チームの問題は何か？」よりは「困っていることは何か？」の方が個人にとっては馴染みがあります。

発散により項目を書き出していくうちに、項目が書ききれなくなってきたり、項目が思い付かなくなってきます。そんな時は、項目の分類や関連付けを行い、項目を構造化します。この過程を『収束』と呼びます。収束により、項目が構造化されるとモレやムダが見つけやすくなります。発散で洗い出した項目をモレなくムダなく整理できる構造を見つけます。モレなくムダなく思考することをMECE（ミッシー、Mutually Exclusive and Collectively Exhaustiveの略）思考と呼んだりします。項目を統合、分割、追加、削除しながら最適な構造を見つけます。

そして、収束の結果から必要に応じて再び論点を設定します。例えば、「困っていることは何か？」という論点について、発散と収束を行い「チームワーク」という項目が残っていたとします。「チームワーク」だけでは抽象的で曖昧です。そこで、「チームワークについて困っていることは何か？」という論点が再設定できます。この場合、収束の途中で発散に戻るという見方もできますが、その際には暗黙的に論点の再設定を行っているとも見ることができます。

図3のサイクルは目的を達成するまで繰り返します。分析では問題をMECEに定義すること、設計では解法をMECEに定義することが終了条件です。チームが抱える問題を解決する場合にも、分析によって問題を明確化する、設計によって問題の解決方法を具体化するという過程を経ることになり、設計と分析の終了条件は同じです。

図1の問題解決プロセスと図3の検討プロセスを併せると図4のようになります。