要件定義をうまくこなすためのポイント――要件定義の完了条件と要求の引き出し方：明日から使えるシステム開発プロジェクトの進め方 再入門（3）

連載目次

皆、悩んでいる――そもそも、要件定義とは

　システム開発プロジェクトの進め方をあらためて解説する本連載。連載第1回の「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」では、今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介した。前回の「要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション」から、プロジェクトの具体的な進め方を解説している。前回は、要件定義の前の段階の話だったが、今回は要件定義そのものについて解説する。

　要件定義はシステム開発の最初の工程である。ユーザー部門から要求を引き出し、システムに実装するべき機能を整理する。整理した内容を基に業務フローや業務シナリオ、データモデルなどを作成し、ユーザー部門と認識に食い違いがないかを確認する。言葉にすれば単純だが、それでも要件定義は難しい。

　筆者は事業会社の情報システム部門を対象としたシステム開発のトレーニングを開催している。受講者は部長クラスから現場の担当者まで職位も年代もさまざまだ。ただ、一つだけ共通していることがある。それは「皆、要件定義に悩んでいる」ということだ。筆者はトレーニング後に自部門の課題を問うアンケートを必ず実施する。その回答で、「要件定義スキルの不足」が常に突出しているのだ。アンケートを取り始めて7年以上たつが、この結果には変化がない。要件定義がいかに難しい問題であるかが分かる。

　情報システム部門長の多くは、要件定義を重視している。自分たちがビジネスや業務を理解し、ユーザー部門に対して価値あるシステムを提案したい。ユーザー部門の要求を“うのみ”にして、言われた通りにシステムを作るだけの「御用聞き」にはなりたくない。単なる伝言役ならば、ユーザー部門とSIerが直接話す方が、ずっと効率的にシステムを作れる。それでは情報システム部門の存在価値がない。

　SIerも、情報システム部門が要件定義を主導することを望んでいる。ほとんどのプロジェクトは予算も限られており、開発期間も短いため、ユーザー部門の全ての要求に対応することは難しい。機能がもたらす効果を踏まえて要求を取捨選択したいが、ユーザー部門と交渉できるほどSIerは業務を知らない。業務とシステムの事情を理解している情報システム部門に調整役を担ってもらいたいと考えている。

　では、どうすれば要件定義をうまくこなせるのだろうか。ポイントは、「要件定義の完了条件」と「要求の引き出し方」である。まずは、完了条件を考えてみよう。

要件定義のゴールは要求の解決策を決めること

　下記の表は、システム開発における「要望」「要求」「要件」を定義したものだ。似通った言葉だが、内容は全く異なる。要件定義は「要求を明らかにする作業」と意識している方は多い。しかし、それは間違いだ。要求を明らかにするのは当たり前。その先の解決策を考えるのが要件定義である。

　例えば、ユーザー部門との打ち合わせで、A〜Dの4項目を帳票に出力することが決まったとしよう。一見すると要件定義は終わったように見える。しかし、実際にはこれだけではシステムを設計できない。各項目を「どう計算するのか」「どう集計するのか」が分からないからだ。結局、設計工程でユーザー部門に問い合わせる羽目になる。これでは「要件定義が完了していた」とは言えないだろう。

　実際には、ユーザー部門からの要求を確認するだけで終わっている要件定義が本当に多い。「成果物が、補足説明のない業務フローと、名称を列挙しただけの機能一覧だけ」というケースも間々ある。もっとゆるいプロジェクトでは、要望をまとめただけで、具体的な解決策を設計工程で考えるといった場合もある。繰り返すが、「要件定義」＝「要求の解決策を考えること」である。

　「要求は変化するため厳密に定義しても仕方がない。走りながら詳細を詰めていくのが効率的である」という考えを持つ人もいる。確かに、機能一覧や機能構成といった文章をベースにシステムの具体的なイメージを持ってもらうことは難しい。しかし、機能仕様が曖昧なまま後工程に突入するのは危険過ぎる。やはり、仕様を明確化するための努力はするべきだろう。ユーザー部門と話す時間を作り、業務面の悩みや手間を開発側が理解し、具体的な解決策を提言できるようにしてほしい。以後、その方法を解説する。

　なお要件定義では、「できないこと」も明らかにする。特に、既存システムのリプレースの場合、ユーザー部門は今ある機能は当然のごとく踏襲されると考えがちだ。打ち合わせで話題に上らなかった機能は、そのまま実現されると考えてしまう。既存システムの機能を削減する場合は必ず明示すること。例えば、システムの全機能について新旧の対応を表にまとめるのも有効だ。

　要件定義を終えるタイミングを見極めるのは簡単だ。要求に対する解決策が明示されており、設計できるレベルまで文書化できていること。これさえできていれば設計工程をスムーズにこなせる。設計や製造、テストなどの工数も見積もれるはずだ。

ユーザー部門の要求はカカシを使って引き出す

　要件定義の終わりは開発側が決める。プロジェクトマネジャーが宣言すれば、そこで要件定義は終わる。ユーザー部門が口を挟むことは、まずない。たとえ要件が漠然としていて、仕様を詰め切れていないと感じていたとしてもだ。ユーザー部門はこう考える。「開発側はリリースまでに帳尻を合わせ、最終的には要求を全て満足してくれる」と。その態度は、仮にリリースが1週間後に控えていても変わらない。

　システム屋からしてみればたまったものではない。そもそも問題はユーザー側にあることも多い。「3カ月に仕様は確定したはず」「追加事項は変更管理に載せて採用可否を判断すべき」といった不満もあるだろう。とはいえ、しゃくし定規に考えても問題は解決しない。ユーザー部門が求めるシステムができなければシステムの価値はないのだ。完成後に不満がでないよう、要求を事細かく合意しておく必要がある。

　要求を精緻に把握するには、「発掘活動」が必要だ。文字通り、開発側がユーザー部門の中に眠っている要求を掘り起こすのだ。「業務のどの範囲をシステム化の対象とするか」「どのような機能を作るか」「それが本来のもくろみを満足させられるのか」「過剰にシステム化をしていないか」といった観点を確認する。

　ポイントは、いかに効率的にユーザー部門から必要な情報を引き出すかである。例えば、下図のように請求書をシステムから発行する取り組みがあったとしよう。開発側では、いろいろと確認したい事項が出てくるはずだ。しかし、これら全てについて逐一問い合わせて、話を整理すると相当時間がかかる。全てが必要な情報とも限らない。ただでさえ短い要件定義の時間を浪費するのは避けたいところだ。

　また、要求の整理も難しい。情報システム部門であればともかく、SIerの場合はユーザー部門の実業務の全てを知っているわけではない。「欲しい」と言われると、その通りに受け取ってしまいがちだ。一見、必要なさそうに見える機能でも、業務を知らないためユーザー部門へ論理的に反論することは難しい。

　そこで「カカシ」を使う。カカシとは、トム・デマルコ共著の『アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン』（日経BP社刊）に紹介されているアイデアである。資料が生煮えの状態で「これでどうだろう？」とユーザー部門へ聞いてみるのだ。人は白紙から答えを作り出すのは嫌がるが、すでにあるものは平気で批判するものだ。アイデアを提示すれば、間違えを指摘してもらいやすい。その分だけ早く正解にたどり着ける。

　ポイントは、あえて批判を覚悟で仮説を立ててしまうことだ。例えば、「請求書の送付形態」を決めるとしよう。まず、「請求書は送付せず、システムからのPDFダウンロードだけにします」と言い切ってしまう。すると、ユーザー部門は反論する。「それは困る。FAX送信をする機能が必要なんだ。なぜなら……」と背景まで含めて説明してくれる。この理由を説明してもらうところが重要なのだ。

　「どうしますか？」と聞いてしまうと理由が出てこない。例えば、「請求書の送付形態は？」をユーザー部門に聞いたとしよう。「PDFをダウンロードできるようにししたい」「メールで送付もしたい」「紙も郵送するのでバッチも印刷したい」「ある加盟店へはFAXを送信していたかもしれない……」。おそらく、「こうしたい」「ああしたい」という意見があふれ出すだろう。理由が分からないと仕様の確定が難しい。

　人は「これは違う」と感じたときに自分が欲しいものを理解するものだ。それを利用して、批判から必要な理由を聞き出すのだ。理由の背後には要求が隠れている。生煮えの資料を見せるのは抵抗があるだろう。人は誰しもよく思われたいし、怒られたくもない。「クレームが出ないように100点の資料を作りたい」と考えるのは当然だ。それでも、覚悟を決めてカカシに取り組めば見合うリターンは得られるはずだ。

5W2Hを意識して、とにかく文章をひたすら書く

　とにかく文章にすることも重要だ。一般的なプロジェクトでは、業務フローやユースケース、シーケンスを要件定義の成果物とすることが多い。これらの資料は見た目が良いので、要件が整理できている感覚に陥りやすい。図版の位置調整やコネクターの置き換えなど、見た目を整えるために時間がかかる。その割には説明のスペースが少なく、実際には作成者しか意図が分からない場合も珍しくない。

　こうした成果物にいきなり取り掛かるのではなく、まず業務仕様を文章にすることを勧める。実際に、弊社でも若手にも同様の指導をしている。仕様や機能をとにかく文章で書き出すのだ。行間にこっそり仕様を滑り込ませるようなことはしない。全て包み隠さず文章化する。こうすれば足りていないものがすぐに分かる。書かれていない要求は「ないもの」とみなせる。

　まずは業務仕様を作成する。以下は賃貸情報サイトの加盟店登録に関する要求を文章にしたものだ。業務フローを使わなくても業務の流れやアクターを記述できることが分かるだろう。

　「混沌としている」と感じた読者もいるだろう。加盟店登録という1つの業務の中で、審査やアカウントの払い出しなどの機能も考えている。加盟店登録とは別のくくりで考えた方が良さそうな箇所も散見される。それでも構わない。とにかく気にせず書いていく。整理は後からすればよい。その時点での仕様を文書化し、いつでも関係者に確認できる状態にすることが大事なのである。

　記述する時点で考えてほしいのは、5W2Hの意識である。それぞれの文章が「いつ、どこから、誰が、何の情報を、どういう理由で、どれぐらいで、どうするのかが明確かどうか」を織り込んでいるかを意識する。

　特に「誰が」「どういう理由で」「どれぐらいで」には注意する。

• 「誰が」――ユーザー部門は自分たちの業務に慣れきっている。説明の際に「誰が」が漏れ落ちることが多い。その結果、開発側が行動の主体を特定できずに困るケースはよくある
• 「どういう理由で」――要求の妥当性を判断するためのものだ。開発側はユーザー部門へのヒアリング時に要求が必要な理由を確認せずに「要求されているので必要だ」と考えてしまいがちだ
• 「どれぐらいで」――利用頻度や量はヒアリングから漏れ落ちることが多い。ユーザー部門への確認を繰り返すと煙たがられると考えてしまい、遠慮してしまうためだ

　書いて確認、書いて確認をくり返し、齟齬なくユーザー部門と仕様を詰めていく。業務仕様をレビューする側も5W2Hを意識してレビューしていただきたい。当たり前で分かりきったことも記述するよう指摘する。「書いていない事項はシステム化されない」と思った方がよい。できないことも書くべきである。文章がある程度固まったらそこから業務フローやユースケースなどの各種成果物へと展開する。

　「どれぐらい文章を作成するのか」と気にしている読者もおられよう。あくまでも目安だが、とある100人月規模のアプリケーション開発では専用Wikiに10万文字を書き込み、ユーザー部門とともにメンテナンスした。規模が小さくてもせめて1万文字は書いて仕様を明らかにしていただきたい。

ボールは渡して終わりではない

　「期限までに、この仕様でよいかどうかの回答がユーザー部門からありませんでした。このため、この箇所の仕様が確定していません。困っています」。要件定義中によく耳にする発言である。「資料をユーザー部門へ渡して決断してほしい旨を依頼したが、回答がなかった。このため終わらない」というのだ。

　これは、考え方を変える必要がある。「期限までに依頼事項の回答を回収するのもスキルの一つである」と考えるべきだ。「それができないとプロフェッショナルとして恥ずかしい」と思わないといけない。

　ユーザー部門側にも事情があるかもしれない。例えば、資料の内容が分かりにくいかもしれない。現業の作業が忙しくて時間がとれないのかもしれない。われわれはシステム化のことだけを考えているが、ユーザー部門は現業がある。事情を無視して「責任はユーザー部門にある」と放言してしまうと、プロジェクトでのコミュニケーションに亀裂が入る。今後の協力が取り付けられなくなる可能性もある。

　やり方はいくらでもある。一緒に考える時間を作ってもよいし、ユーザー部門の上長に依頼して担当者の手を空けてもらうこともできるはずだ。開発側のプロジェクトマネジャーはユーザー担当者の負荷も気にしながら、作業の進行を阻害する要因を共に解消していかなければならない。

手間を惜しまず丁寧に対応する

　要件定義のゴールは要求の解決策を決めることである。要求をはっきりさせるだけで終わってはいけない。要求だけあっても仕様や背景を掘り下げる活動ができていないと、後の設計で時間をとられてしまう。失敗プロジェクトを振り返ると、要件定義で作成した成果物の品質が十分でなかったケースがほとんどである。そうならないよう、ユーザー部門自身も気付いていない要求を引き出す活動を実践する。

　要件定義中に仕様は都度変化するため、書いても次々と変更が入る。メンテナンスの手間も掛かる。後からまとめて文書化したい気持ちにもなるが、丁寧に対応すればシステムの品質は必ず良くなる。要求を掘り出すスキル、文章を書くスキルは簡単には身につかない。手間が掛かっても「スキルアップのチャンスだ」と考えて率先して経験するべきだ。管理者は、そのように担当者に意識付けしてほしい。

　次回は設計である。外部仕様を固める基本設計に焦点を当ててノウハウを解説する。