「要件定義が何の問題もなく進むわけがないじゃないですか」――。日経SYSTEMS 11月号の特集「難航した要件定義 苦境からの脱出法」の取材を進めているときのことだ。要件定義を担当する、あるエンジニアから聞いたこの一言は、昨今の事情をよく表していると思った。

　誤解のないように補足しておくと、冒頭のエンジニアのスキルが低いというわけではない。「ベテランのエンジニアでも要件定義で難航することが少なくない。それだけ要件定義が難しくなってきた」といった意見は多くの要件定義担当エンジニアから聞くことができた。

　ちなみに、ここで言う要件定義とは、現状の業務とシステムの分析、新しい業務フローを定義する業務要件定義、それに基いて概要レベルのシステム要件をまとめるシステム要件定義などを含む。

要件定義が難航する三つの理由

　要件定義が一筋縄ではいかないのは以前から指摘されてきたことだが、それでもなお多くの要件定義担当エンジニアが「難しくなってきた」と考えるのには理由がある。取材を基にすると、大きく三つの理由に分類できた。業務面、技術面、プロジェクトマネジメント面からくる理由である。

　一つめの業務面については、新しい業務フローを定義しにくいということだ。既に企業は多くの情報システムによってその活動を継続している。以前のような手作業の置き換えを目的としたシステム構築プロジェクトは相対的に少なくなった。

　代わりに、抜本的な業務改革を伴うシステム刷新や、新事業を担うためのシステム構築、海外子会社を含めたグループ企業を横断する情報基盤の構築、といったプロジェクトが多くなる。これらのシステムに実装する業務フローはユーザーでも明確に定義することが難しい。

　二つめは技術面だ。あるシステムを新規に構築する、もしくは刷新する場合、そのシステムに連携する既存システムの存在がネックになる。もはや重要な企業システムになるほど、部門ごとに単独で動いていることは少ない。すると、データ型、コード体系、連携先の既存システムの処理タイミング、インタフェースなど、連携先の既存システムの仕様が制約になるのだ。にも関わらず、既存システムのドキュメントがなくなっていたり不備があったりすることが多く、現状分析に時間がかかってしまうという。

　三つめのプロジェクトマネジメント面は、上記二つの理由に関係している。業務面、技術面で難しくなったプロジェクトを舵取りすることも難しくなったという意味である。例えば、グループ企業を横断する情報基盤を構築する際、範囲が拡大したステークホルダー（利害関係者）から出る要求を調整しにくくなった、といったことだ。

苦境からの脱出ノウハウを身に付けよう

　こうした理由によって難航する要件定義が増えているという。具体的には何らかの問題が発生し作業が進まなくなるのだ。今回の特集では、その状況を「苦境」と表現することにした。

　もちろん要件定義で苦境に陥らないように努力することは重要だが、それだけでは不十分。前出の理由から、要件定義自体の難易度が上がっているので「すんなり進むわけがない」という前提に立った対処が必要なのだ。苦境に陥ったとしても、そこから素早く立て直すノウハウやスキルを身に付けることが求められている。

　一例を挙げよう。「要件定義書や中間成果物について、プロジェクトオーナーや利用部門の承認が得られない」という苦境に立たされた場合だ。このために行き詰まったプロジェクトの立て直しを経験した、富士通の森田 功氏（SI技術本部 システム技術統括部 シニアマネージャー 上流工程技術担当）は「作成した要件定義書だけで、プロジェクトオーナーや利用部門のレビューを受けようとしていたが、承認が得られなかった。要件定義書の内容を判断できなかった様子だった」と話す。

　そこで、森田氏は要件定義書を基にプロジェクトオーナー向けに特化したドキュメントを作成。このドキュメントを中心に説明することで、この苦境を乗り切った。

　ドキュメントには「プロジェクトの狙い」「予測効果」「現状の業務」「現状の問題点」「変更後の業務」「前提条件/要検討事項」の6点を記載した。このドキュメントはテンプレート化され、ノウハウとして以降のプロジェクトに生かされている。

　特集では、森田氏が作成したテンプレートを掲載した。このほかにも、「要求が膨らんでしまう」「利用部門のキーパーソン同士が対立する」「開発側メンバーが利用部門からの信頼を失っている」など、よく起こる苦境を類型化し、そこから脱出するための現場の工夫を紹介している。

　要件定義の不備によってプロジェクトが行き詰まり、再度要件定義からやり直したリコーの事例や、苦境からの立て直しの手順も掲載している。要件定義の“立て直し”を“すんなり”と進めるための一助になれば幸いである。