システム開発・要件定義の心得:合意形成について#2

システム開発・要件定義の心得:合意形成について#2

システム開発・要件定義の心得:合意形成について#1」の続きです。
本項で「要件定義」に関するシリーズの最終項となります。システム開発は技術や知識の他にも大切なことがあります。人が関わることですので、その心得もあるとさらに良い開発ができるかと思います。

「事実」と「真実」

「真実」と「事実」の違いは仕事においてよく出てきます。「ノンフィクション=事実」は大切です。けれども、何らかのコミュニティにおいて人が生きていくためには、事実よりも真実を語る物語が不可欠なのです。すなわち「事実」=「本当にあったこと」からの考え・推測が、「真実」ではないそんなことがあるのです。それがどんなに小さなコミュニティであろうともです。

彼氏が彼女に大きな嘘をついていた「事実」があると、人は悪いことをしているとその彼氏を非難するかもしれません。しかし、彼女を大切にしていないのではなく、彼女を大切にしているからこその嘘であるようなこの「真実」があるのです。

人は「真実」を語る物語を通してしか「事実」に向き合えません。自身の価値観や幻想のフィルターを通じて「事実」を垣間見るのです。たとえ人から見れば当たり前の「事実」であろうと、立場や考え方が異なれば「真実」は異なります。システム開発プロジェクトというコミュニティでも同様のことが起こります。

様々なステークホルダーが登場し、それぞれがそれぞれの立場で、「真実」を通じて様々な「事実」に向き合います。そして前述のとおり、人により「真実」のフィルターは異なります。

そんな環境の中で、要件定義の合意形成を行う必要があるのです。このような人間社会の原則というべき制約が、システム開発を難しくしている大きな要因であると、筆者は考えています。

合意に至る本気度

ユーザー、またはそのステークホルダーが、果たしてどの程度の「本気度」で要件定義に向き合っているか、きちんと把握しておく必要があります。もし、要件定義内容の合意が得られない場合は、前項で説明したように「未決」事項として整理しておきます。「未決事項」を残したまま要件定義を終えるのは本来の姿ではありません。

しかし、いつまでも要件定義を引っ張ることは、プロジェクトとして許されません。「未決事項」を残すことは、設計工程で要件定義をやり直すことを意味します。そのための工数バッファ(一時的な記憶)が必要になることを、ステークホルダーと合意しなければなりません。

つまり「未決の合意」は、コスト増になることの合意なのです。未決事項が機能レベルであれば、アジャイル型開発のように飲み込める可能性が高いと言えます。しかし、経営レベルや事業レベルに関わったり、あるいは業務プロセスの変更に関わる未決事項は、ほぼ確実に、プロジェクトの大問題に発展します。バッファでは吸収できない事態に陥るのです。

とはいえ…

冒頭でも触れましたが、見たこともない新システムの仕様を「ここで決めろ」と言われて、簡単にできる人は少ないでしょう。「大枠」を掴むことを要件定義の目的としているのは、それが理由です。 せめて、わかりやすく示した「大枠」には合意が得られるように、要件定義を行い、合意形成ができなければなりません。

その場合、詳細な仕様決定は、設計と併行して行えばよいのです。何がどうであれ、開発対象の新システムの目的と方向性を明確化することで、まず根を張り、幹を確立させた上で枝を伸ばすのが、システム開発を成功に導く最善の近道であると、筆者は確信しています。

テックカテゴリの最新記事