ストーリー vs 構造——要件定義はなぜ難しいのか

システム構築の支援で現場に入り、いろんな部署の担当者にヒアリングをするなかで、気づいたことがある。

皆さん基本的に「ストーリー」で語る。つまり、時系列で話す。全体像から始まることはほとんどなくて、個別の業務から語り始め、枝分かれしていく。こちらは、相手の話が全体のどのあたりなのかが分からない。何度かヒアリングを重ねて、ようやく業務の輪郭が見えてくる。そこで初めて、「このケースはまだ聞けていなかった」と気づく。最初のうちは正直、非効率だと感じていた。けれど、何人もの担当者と話すうちに分かった。これが「普通」なのだ、と。日々の業務を時間の流れで捉えている人にとって、時系列で語るのがいちばん自然な伝え方になる。それは能力の問題ではなく、業務との向き合い方そのものだ。

一方、自分はそのとき何をしているかというと、そのストーリーを頭のなかで「構造」に変換している。まず時系列の流れを整理し、そこから要素を拾い出して、要素同士の関連を見つけていく。たとえば受注と売上の話が出てきたら、受注1件に対して売上が何件発生するのか、といった関係性を組み立てながら聞いている。

なぜ自分にそれができるのか。振り返ると、長年プログラムを書き、設計書を作ってきた経験が大きい。エンジニアの仕事は、突き詰めれば情報を分類し、関係を定義し、構造として組み立てることだ。その繰り返しのなかで、構造化して物事を捉える力が身についたのだと思う。

業務担当者はストーリー思考で物事を捉え、エンジニアは日々の業務を通じて身につけた構造化思考で捉える。この二者のあいだには、思った以上に大きなギャップがある。

要件定義はなぜ難しいのか

ところで、システム開発の要件定義は難しいと言われる。実際、要件定義が原因でプロジェクトが難航するケースは多い。ユーザーはエンジニアにどう伝えればいいか分からないし、エンジニアの言葉も理解しづらい。エンジニア側はヒアリングで抜け漏れが起き、要件が不完全なまま設計に進んでしまう。出来上がってみたら想定と違う。修正が重なり、システムの内部は整合性を失っていく。

この難しさの根っこに、先ほどのギャップがあるのではないか。

要件定義とは、ユーザーの作りたいシステムを仕様に落とし込んでいく作業だ。その過程では、業務担当者へのヒアリングが欠かせない。しかし担当者はストーリーで語り、エンジニアはそれを構造化しなければシステムには落とし込めない。そしてこの変換が、本質的に難しい。ストーリーで考えることと、構造で考えること。この思考の方法そのものが違うからだ。要件定義の難しさの根っこには、この思考方法のギャップがあるのではないか。今のところ、そう考えている。

4つの象限で俯瞰する

このギャップを可視化するために、4象限の図を考えてみた。横軸に「人」と「仕組み」、縦軸に「現実」と「記述」を置く。

左上「人×現実」には、人が働いている姿。目に見える日々の業務風景。右上「仕組み×現実」には、実際に稼働しているハードウェアやソフトウェア。

左下「人×記述」には、業務の流れを言葉にしたもの。「業務A→業務B→業務C」という時系列のストーリー。右下「仕組み×記述」には、設計図やUML、データモデルといった構造化された情報。

業務担当者は主に左側——「人」の列で物事を見ている。エンジニアは主に右側——「仕組み」の列で捉えている。要件定義の過程では、左下の「時系列のストーリー」を右下の「構造化された情報」へと変換しなければならない。

この図を俯瞰すると、お互いが何を見ているのかが分かる。業務担当者はエンジニアが「構造化」の視点で聞いていることを知る。エンジニアは、担当者がストーリーで語ることには理由があると理解する。お互いの頭のなかをイメージできれば、もう少し歩み寄れるのではないか。

大げさな解決策を提示したいわけではない。まずは、このギャップの存在を双方が知ること。それだけで、要件定義の場でのコミュニケーションは少し変わると期待している。

まだ途上の考えとして

正直に言えば、この考えは思いついてからまだそれほど日が経っていない。現場で感じたことを自分なりに言語化してみた段階で、裏付けが取れていない。書籍も調べ始めてはいるが、まだ読み込めてはいない。自分が考えるくらいのことだから、すでにどこかで体系的に論じられているだろう。

それでも、「なぜ話が噛み合わないのか」を説明するための、ひとつの切り口にはなるのではないか。この先、同業の方や現場の方からも意見をもらいながら、もう少し考えを深めていきたい。