さあ、いよいよ聞き込みです。まずはリストアップしたステークホルダーの内からビジネスに関わる部門を対象に、「業務要件」から取りかかりました。そして、ステークホルダーと議論する内に、千石君が最初に描いた「概略業務フロー図」は、徐々に正確さを増していきました。
例えば、要求については販売部門や製造部門と議論する過程で、最初に作成した概略業務フローに対して以下のような点が詳らかになりました。
- 商品情報は在庫状況にかかわらず提示したい
- 注文があったら在庫状況を確認したい
- 在庫データは総在庫数に加え、引当済数の管理も必要
これらの要求を受け、千石君は以下のように「概略業務フロー図」を変更していきました。
ステークホルダーと議論した後の概略業務フロー図
要求の定量化、基準の決定、優先順位付け--要件の絞り込み
さて、順調に滑り出したかのように見えた千石君ですが、すぐに壁にぶち当たってしまいます。
巣鴨課長：どうした？ 頭から湯気が出てるよ。
千石君：いろんな人が好き勝手に要求を出してくるので、まとめるのが大変です。それにまとめたとしても、今の予算とスケジュールの中には到底、収まりそうにありません。
巣鴨課長：要求が出ないよりいいじゃないか。集めた要求をうまくまとめるのが腕の見せどころだよ。要求を整理するためは「その要求は何を実現するのか」を考える必要がある。
千石君：プロジェクトチーム内でも議論してるんですが、どの要求も必要に思えてきて……。
巣鴨課長：まあまあ落ち着いて。優劣を決めるんじゃなくて、異なる観点からその要求を客観的に評価するんだ。具体的には次のような評価観点だね。
- システムの目的に対する妥当性
- システムの目的に見合う効果
- 必要性（時間の観点を含む）
- 技術的実現性
- 実現費用
巣鴨課長：これらの観点で評価し、集まった要求に優先順位を付けてみればいい。優先順位付けの際には、評価観点ごとにスコアを付けて定量化すると分かりやすいよ。ただし、技術的実現性と実現費用の評価は、もう少し後の方がいい。この2つは、システム要件を議論しないと評価できないからね。ところで、このイノベーション戦略室とやらからは、どんな要求が上がってきた？
千石君：「ビッグデータ、モノのインターネット（IoT）時代は、データドリブンなビジネスに舵を切らないと生き残れない。そのためには、顧客のサイト内行動データなどを収集し、人工知能（AI）で分析できるシステムを導入すべきだ」と言われましたよ。
巣鴨課長：へー……。もちろん、データドリブンなビジネスは重要だけど、評価観点に照らし合わせて検討する必要がある。なぜAIによる分析が必要なのか、分析結果をどう使おうとしているのか、それらをきちんと文書化してもらおうじゃないか。各ステークホルダーには自身の要求に責任を持ってもらう必要があるからね。
千石君：分かりました。あと1つ教えてください。システム利用者の要求はどうやって聞き込みをすればよいのでしょう。
巣鴨課長：いい質問だね。これに関してはさまざまなやり方があるし、「王道のやり方」は存在しないんだ。
千石君：以前、課長はどんなやり方で、利用者の要求を聞き込みしたのですか。
巣鴨課長：大前提として、自分ひとりで抱え込まないことだ。社内や販売代理店で使用するシステムについては、早い時期に操作画面のプロトタイプを作成し、システムの想定使用者に確認してもらったことがある。いわば「お試し画面を作って意見を言ってもらう」方式だね。
千石君：それなら利用者も要求を出しやすいですね。
巣鴨課長：顧客（エンドユーザー）が利用するシステムは、システム稼働後にフィードバックを得る仕組みを設けるというワザがある。お客さまに対して「これプロトタイプなんですが……」とは言えないだろう。その代わり、フィードバックに対しては迅速に反映できるような仕組みを用意し、システムの運用体制を整えてもらったよ。
千石君：そのやり方、いただきます。
巣鴨課長：システムだけで全ての要求を満たすことは難しい。大事なのは、システム開発プロセスや運用とのバランスだ。
千石君：はい。また「プロジェクト要件」や「運用要件」も今の段階で整理しておくことが重要なのですね。特に、フィードバックの仕組みについては、早速、販売部門や販売代理店などとも話し合ってみます。
巣鴨課長：そういうこと。話し合いはなるべく穏便にね。
かくして、千石君のプロジェクトチームは、プロジェクト計画で定めた期限内に、「システム開発標準」に基づくステークホルダー会議を開催して関係者が合意した、優先順位の付いた業務要件を整理し、「業務機能構成表」を取りまとめたのでした。
●要件定義に悩むユーザー企業担当者必携の一冊
ユーザのための要件定義ガイド ～要求を明確にするための勘どころ～
ユーザのための要件定義ガイド（1574円＋税）
要件定義についてもっと詳しく知りたい人は、IPA/SEC編の『ユーザのための要件定義ガイド ～要求を明確にするための勘どころ～』を入手してほしい。
本書は、主にユーザー企業でITシステムの要件定義を実施する読者を対象に、要件定義において発生する問題と、その解決方法をまとめたガイドブックだ。
システム開発で発生する問題の半分は、「要件定義」の不備に起因していると言われている。要件定義の不備は、工程が進めば進むほど修正に多大な労力が必要となる。要件定義を行う課程では、明確な目標の設定、膨らむ要求のコントロール、業務の複雑性の軽減、多様なステークホルダーとの合意など、さまざまな課題に直面する。これらを適切に対応すれば、「工程進行後に多大な修正が発生する」といった問題の発生を抑制できる。
本書では、こうした問題について、熟練した有識者がこれまでのプロジェクト経験から「ありがちな間違いとその解決策の勘どころ」を、具体例を挙げて分かりやすく解説している。
本書は一般書店にて、1574円（税別）で販売しているほか、IPA/SECのサイトからもPDF版を無償でダウンロードできる。本連載と対応させながら、ぜひ読んでほしい。
- 山下 博之
情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター システムグループ グループリーダー
1981年、京都大学大学院修士課程（情報工学）修了。同年、日本電信電話公社（現NTT）入社。以後研究所において、データ通信等に関する研究開発と標準化活動に従事。2003年10月、NTTデータに転籍。2004～2008年、科学技術振興機構（JST）に出向。2009年4月、NTTデータアイ入社、同時にIPAに出向し、現在に至る。ソフトウェアエンジニアリング、高信頼化システムの構築運用に関する技法の取りまとめとそれらの普及展開に取り組む。情報処理学会シニア会員、電子情報通信学会、IEEE各会員。
