昨年弊社は「デシジョンシェア」のバージョン2、「RadMap/project」のバージョン5をリリースいたしました。今回のコラムでは、私自身が製品開発プロセスを通して改めて感じた、フレーミングにおけるドキュメンテーションの重要性についてお話したいと思います。

ソフトウェア開発プロセスには様々な手法がありますが、「要求分析」→「仕様記述」→「ソフト設計」→「プログラミング」→「テスト」というプロセスが一般的であり、弊社のソフトウェア開発もほぼ同様のプロセスで行われております。

ソフトウェア開発の終盤では、必ず「テスト」と呼ばれる工程で、様々な検証を行い、ソフトウェアの欠陥(バグや障害とも言う)を発見し、修正します。欠陥には、大きく分類すると2種類あり、1つはソフトウェア上、考慮されていない操作、動作によりソフトウェアが全く動作しなくなる欠陥です。もう1つは、ソフトウェアとして動作はするが、仕様とは異なる動作をしてしまう欠陥です。後者の欠陥は一見するとソフトウェア上は問題ないようにも見えますが、提供する機能としては仕様を満たしていないため、正しい動作とは何かを確認する必要があり、この時に必ず仕様書を確認します。

言うまでもありませんが、仕様書には、ソフトウェアとして何を実現したいのか、それを実現するためにはどういう動作をすべきなのかなど、ソフトウェア(機能)としての枠組みが記載されています。しかしながら、この仕様書にソフトウェアとしての枠組みが記載されていなかったら、またはもし仕様書がなかったら、一体どういうことが起きるでしょうか。おそらくテスト工程で欠陥が発見されても、正しく修正することができず、そもそもこの機能はどういった目的で開発されているのかさえもわからなくなってしまうのではないでしょうか。

一方、話を意思決定の現場に移しますが、意思決定のプロセスでは、最初のステップとして、「フレーミング」を行います(フレーミングについては、2006年6月22日(木)発行のインテグラート・インサイト第2号 http://www.integratto.co.jp/column/002/を参照下さい)。「フレーミング」が行われない場合、或いは「フレーミング」の内容を「ドキュメント化」していない場合、意思決定プロセスが進むにつれて、かなりの高確率で「そもそも論」が発生します。「そもそも何をもってこのプロジェクトをGoとするのか」、「そもそも我々は何をしようとしているのか」など、プロセスの後半での「そもそも論」はプロセスのやり直しを意味し、意思決定のプロセスを振り出しに戻してしまいます。

「フレーミング」を行うことで、「そもそも論」が湧き上がるのを防ぐことができますが、「フレーミング」した内容を「ドキュメント化」していない場合、内容を忘却した時や検討が行き詰ったりした時に、「フレーミング」の内容をトレースすることができず、結局は「フレーミング」を行っていないのと同じになってしまいます。

「フレーミング」の結果を記したドキュメントは、ソフトウェア開発における仕様書と同等であり、「意思決定の仕様書」であると考えられるのではないでしょうか?ソフトウェア開発の現場では、その枠組みを検討する「フレーミング」がしっかりと行われ、それを仕様書といった形でドキュメント化することが通例です。同様に、フレーミングの結果をドキュメントとして残し、関連メンバーでいつでも共有できるようにすることは、その後の意思決定のプロセスや意思決定の品質を管理する上で、非常に重要なのです。

再びソフトウェアの開発の話に戻りますが、「RadMap/project」のバージョン5の開発において、思い出深い出来事がありました。弊社では、インターンシップを導入しており、「RadMap/project」の開発でも二人のインターン生(他社に内定済)に、ソフトウェア開発の作業の一部を手伝ってもらいました。インターンの期間が終わる時に、私がマネジメントをしていた一人のインターン生から「伊藤さん、ソフトウェア開発っておもしろいですね。職種の希望を出す時にSE(システムエンジニア)も考えてみたいと思います。」と言われ、その時に胸が熱くなったのを今でも覚えています。二人とも4月から社会人として、新たな一歩を踏み出すことになると思いますが、この場を借りて、お二人のご健康とご活躍を心よりお祈り申し上げます。

(伊藤 卓也)