連載

2015年5月19日

要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション：明日から使えるシステム開発プロジェクトの進め方再入門（2）

本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、要件定義の準備作業について解説する。要件定義をスムーズにこなすためには作業に着手する前に綿密な計画を立てる必要がある。

[横山芳成（ウルシステムズ），＠IT] PC用表示関連情報

LINE

Hatena

連載目次

要件定義へ拙速に突入してはいけない

　システム開発プロジェクトの進め方をあらためて解説する本連載。前回の「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」では、今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介した。今回からプロジェクトの進め方についてから具体的なノウハウを解説していく。

　今回は、要件定義の準備作業について解説する。要件定義は開発するシステムの仕様を決める重要なステップだ。プロジェクトの最初の工程でもある。出だしでつまずくと、以後のプロジェクト運営にも支障を来す。要件定義をスムーズにこなすためには作業に着手する前に綿密な計画を立てる必要がある。

　「要件定義の準備」と聞いて、首をかしげた方もいるだろう。「プロジェクトのスタートとともに、要件定義に着手している」という現場は少なくないはずだ。特に最近は、開発期間が短縮傾向にある。「設計や製造の期間を確保するため、早めに要件定義に着手したい」と考える気持ちは分からなくもない。しかし、見切り発車で要件定義を始めると泥沼に陥る可能性が高い。例えば、次のような感じだ。

プロジェクト開始後、何となく要件定義が始まり、打ち合わせを重ねる。検討範囲が明確でないため仕様を決められず、役割分担も明確にできない。途中で進捗（しんちょく）が思わしくないことに気付き、スケジュールの都合から課題を後工程に先送りする。期日までに何とか「要件定義書」という名の成果物を作り上げる。

　こうしたプロジェクトを目にしたことは一度や二度ではない。もし、「要件定義を成功させたい」と本気で考えるなら、実際の作業を開始する前に一息ついて、綿密な計画を立てるべきだ。具体的には4つのポイントを明確化する。【1】インプット評価【2】ミーティングスケジュール【3】アウトプットの内容【4】役割分担である。以下、それぞれについて解説していく。

【1】インプットの精度を評価する

　業務改革やITコスト削減などプロジェクトの目的はさまざまだが、何もないところにゼロからシステムを導入することはほとんどない。大半のプロジェクトでは、すでにシステムが稼働しており、それを利用した業務フローが回っている。そこにある何らかの課題をシステム刷新によって解決したいというのが一般的だ。

　現状を正しく理解しなければ、プロジェクトの目標達成はおぼつかない。要件定義を始めるに当たって最も重要なインプットとなるのが「既存の業務フロー」と「既存システムの設計書」である。開発者は2つのドキュメントから過去の経緯を理解する。要件定義がスムーズにいくかどうかの鍵を握る重要な存在だ。

　残念ながら、これらのドキュメントが当てにならないケースは珍しくない。業務フローにしても設計書にしても、システム開発時に担当者が作成したきりでメンテナンスされていないようなケースは頻繁に目にする。最初から情報が不足しているお粗末なドキュメントもよく見掛ける。業務フローや既存システムの設計書の品質が低いと、要件定義は難航する。

　要件定義の見通しを立てるためにも、これらのドキュメントには事前に必ず目を通したい。記載されている情報が実態と合っているか、関係者にヒアリングして確認する。差異がある場合は、関係者にアップデートを依頼する。「更新の時間が取れない」「どう整理すればよいか分からない」と言われた場合は、業務とシステムの現状を説明してもらう。とにかく、業務とシステムの実態を整理する場を設ける必要がある。

　ただし、こうした作業は時間がかかる。スムーズに進んだとしても最低1週間は要するだろう。要件定義の工程内に持ち込むとスケジュール遅延の原因にもなりかねない。要件定義の期間外で現状把握の作業をこなせるよう調整するのも1つの手だ。例えば、「情報の品質が悪い」と判断した時点で、関係者に説明会を開催してもらい、業務の実態について口頭で説明してもらう。

　もし、読者がユーザー企業の管理職ならば、自社の主要なシステムの業務フローやシステム設計書がどこに保存されているのかを棚卸ししておこう。「各ドキュメントが最新の状態にメンテナンスされているか」「情報の精度が十分に記載されているか」などを都度評価する。システムはいつか刷新するものだ。既存の情報整理を軽視していると、次のシステム開発で失敗することになる。

【2】「ミーティング回数は何回が妥当か」を考え抜く

　要件定義では、業務やシステムのあるべき姿を定め、要望や要求を整理して具現化の方法を検討する。そのための場として、業務や機能といった単位でミーティングを設けることになる。ここで悩みの種となるのがミーティングの回数である。何回開催すれば要件が固まるのか正確に見積もるのは難しいものだ。

　実際のプロジェクトでは、具体的な根拠がないままミーティング回数が決まることも多い。例えば、「業務部門の都合で、週に2時間2回しかできない」とか、「過去の経験から見積書と受注処理は4回、出荷は3回でいい」といった具合だ。ただ、こうした見積もりは後々の苦労を生むことになる。「ミーティング回数が足りず、要件を決めきれなかった」「途中で回数を増やしたが、関係者が出席できずキャッチアップできなかった」という話はよく聞く。

　簡単ではないとはいえ、何らかの根拠を持ってミーティング回数を算出することが必要だろう。実は、コツがないわけではない。ポイントは業務や機能で分解し、ミーティングで検討する範囲を狭くすることだ。業務や受注処理といった粒度で考えると、対象が広過ぎて検討事項の量がイメージできない。「業務を構成しているモノ」「業務で必要とされている考え」といった単位で分解すると、どれぐらいの議題があるのか目処を付けやすくなる。

　業務や機能を分析する上で気になったポイントについても打ち合わせの場を設ける。例えば、見積書の発行業務であれば、「入力内容を簡素化すると業務効率化できそうだ」「発行から承認までのワークフローが形骸化しているので、廃止や一括承認を検討できないか」「全てを見積書形式で発行する必要はないのでは」といったポイントを発見するかもしれない。このような“気になるポイント“についても、それぞれ検討の場を設定する。

　全体最適化の観点から影響度や実現性や優先度、手間を考えて、各業務での要件を取捨選択する場も必要だ。全体共通のミーティングと、個別の業務や機能のミーティングとは分けて考える。次の図は、業務機能のミーティング構成例である。

既存業務、既存システムの説明

　まず、業務部門から要件定義チームに対して、既存業務の全体像と既存システムの課題を説明してもらう。業務とシステムの規模によるが、多くても2回の開催で全体感を把握したいところだ。

個別業務、個別機能のミーティング

　利用者の作業環境や業務内容、システムの課題といった個別のテーマを掘り下げる。回数は内容次第だ。初回は、業務部門に議題について説明してもらう場とする。その後、具体的な検討に入る。テーマごとに2回ぐらいレビューの場を設定しておく。ミーティングの予備日も1回は設定したい。

　業務の機能を整理した後、マスター関連の設定項目や画面遷移、画面イメージ、権限管理などを検討する。マスター関連の検討回数は単純な参照であれば1回、ロジックが関連する場合は2、3回が妥当だろう。

　画面遷移と画面イメージは、既存システムの画面数を参考にする。2画面で1回の開催で考える（帳票の検討も同じように考える）。権限の整理は10画面で1回の開催を目安にする。

全体の調整

　個別の機能を検討した後、機能間の影響と採用可否を整理する。複数の機能にまたがる要件は、個別の機能を検討している際に処遇を定めているはずだ。しかし、全体を整理するために2回はミーティングを開催する必要があるだろう。

　どんなミーティングを開催したいかを定義すれば、後は誰が参加すべきか、いつ開催すべきかを調整するだけだ。議題が決まっているので、業務部門に参加要請しやすい。ここでは業務について述べたが、非機能やインフラを含むアーキテクチャや運用についても同様だ。全体と個別で分けて、個別の中を具体的に考えるアプローチが有効である。

【3】成果物のイメージを合わせる

　要件定義の成果物は「要件定義書」である。しかし、その体裁には共通の定義がない。イメージするものは人によってまちまちだ。Google検索で「ユースケース」を画像で検索すると似たような画像が表示されるが、「要件定義書」は目次構成や表、スケジュールなどバリエーションに富んでいる。

　要件定義で作成する資料も同様だ。例えば、画面の仕様を伝えるドキュメントについて、「設計図で十分」と考える人もいれば、「モックアップが必要だ」という人もいるだろう。仮にモックアップを作成するとして、「ワイヤーフレームでよいのか」「実際に動くものが必要なのか」も人によって異なるはずだ。

　共通で認識できるイメージがないのであれば、自らが定義するしかない。要件定義で決めるべきは、設計工程で必要となる項目である。つまり、システム化の仕様である。それに加えて、仕様で定めた機能の複雑性も明確化する必要がある。要件定義で設計フェーズ以降の作業規模を見積もるからだ。

　さらに、仕様を検討した経緯や、それぞれの機能を実装するに至った理由もまとめておくべきだ。後から仕様を評価できるようにする。具体的には、現行の仕組みや将来のイメージ、業務フローやデータモデルなどをそろえておく。以下、要件定義と基本設計における成果物の定義例を示す。

　要件定義と基本設計での成果物を定義し、どのタイミングで何を作るかを明らかにする。基本設計の成果物まで提示しているのは、ドキュメントの網羅性を示しつつ、要件定義で作成するものを明確にするためだ。この例では、「画面仕様書は要件定義では作成しないが、外部設計で作成する」という意思を示している。

　各成果物のサンプルも添付して、内容についても関係者間で合意しておく。それを怠ると「違ったものを作成された」「この内容では記述が足りない」といったクレームが発生しかねない。

　なお、システム開発における成果物標準（サンプルも含む）を定義するのは管理職の仕事である。前もって成果物を定義し、システム開発が発生する場合には、標準の適用を促すのである。成果物品質の定義を現場任せにしてはいけない。それほど大変な作業ではない。既存のシステムを何個か評価し、優れたものを取り上げて「標準」とすればいいのである。一から作成する必要はない。

【4】役割分担を決めるときは遠慮してはいけない

　プロジェクトの役割分担はしばしば曖昧になりがちだ。特に、開発者は頼まれると「ノー」とは言えない人が多い。面倒な仕事も受け入れてしまいがちである（後で文句を言うが）。その結果、開発チームが役割外の仕事を抱え込んでしまうケースは多い。

　発注側と受注側の関係では、それが顕著だ。担当者が明確に決まっていない作業を開発側が引き取ることは珍しくない。プロジェクトによっては既存業務の突っ込んだ整理や、業務のあるべき将来像の策定、どのレベルで機能を実現するかの判断など、発注側でなければこなせないタスクを受注側に任せていることもある。

　受注側の内部でも役割外の作業が発生する。例えば、「プロジェクトでトラブルが発生したときに、上長から経営層への説明資料や品質リポートをまとめるよう指示された」という読者はいないだろうか。現場にしてみれば「資料が必要ならどうぞご自分で作成ください」と言いたいところだが、現実的には断ることは難しい。

　役割外の作業が発生すると、やるべき仕事ができなくなる。それを回避するには作業分担を明確にしておくしかない。具体的には、プロジェクト開始前に作業の概要レベルで一覧化すべきだ。例えば、「既存資料の提供」「既存業務の説明」「新業務の判断」「新業務を決定するための検討資料作成」「議事録の作成」「経営層への報告」「経営層用の報告資料作成」「打ち合わせ日時調整」といった具合だ。細かい作業に至るまで誰が実施するのか、支援止まりなのかをRACIチャートでまとめ、関係者全員で合意しておく。

　役割分担を決める際、遠慮は禁物だ。本来担当すべき人物に作業を割り振る。もし、やむを得ず開発側で引き取る場合は、スケジュールへの影響を必ず考慮すること。影響度合いが大きい場合はスケジュールの再考を申し出る。「悪いけどやっておいてよ」と言葉で丸め込まれると、やるべき作業がやれなくなる。とにかく役割を真剣に考えることが大切だ。決定事項は文書化する。それぞれの作業の責任の所在を明確にしよう。

　余談だが、「システムの受託開発が失敗する原因は要件定義にある」とよく言われる。筆者も同意見だ。特に、発注側が受注側に仕事を頼み過ぎているように思う。業務の内容は発注側で整理するべきであり、どう変えるべきかの判断も発注側が決断すべきだ。

　過度のベンダー依存は発注側のリスクでもある。情報システム部門や業務部門は使い勝手の良い受注側の開発者を重宝するが、ある日突然いなくなるかもしれない。不測の事態に備えるためには発注側が情報を整理し、考えるスキルを身に付けておくべきだ。発注側がこなすべき作業を意識して、実践するべきである。

見切り発車の要件定義は失敗する可能性が高い

　今回の内容をまとめよう。見切り発車の要件定義は失敗する可能性が高い。まずは、着手する前に何を決めるかを考え、関係者と合意しよう。インプットの準備、ミーティングの準備、事前のアウトプット定義、事前の役割分担定義は、スムーズな要件定義活動を支えるための最重要なアクションである。

　次回は要件定義について紹介する。どのように要件を考えるか、どこまで検討すべきかを紹介する。

「明日から使えるシステム開発プロジェクトの進め方再入門」バックナンバー

要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション：明日から使えるシステム開発プロジェクトの進め方 再入門（2）