要件定義で発注側がやること｜ベンダー任せにすると何が抜けるか

進め方としては普通です。ただ、その形だと合意の中身が変わります。レビューで指摘しなかった箇所は、合意したものとして扱われます。発注側は決めたつもりでいて、実際には否定しなかっただけ、ということが起きます。

契約上はそうなります。半年後に「そこは要件定義で合意済みです」と言われて、こちらに反論する材料がない。よくある形です。

ベンダーが悪いわけでもありません。相手は聞いた内容を書いているだけで、聞かれなかったことは書きようがない。

書いてある部分ではなく、書かれていない部分です。要件定義書を読むとき、発注側が探すのは誤りではなく空白のほうになります。

具体的には、現行業務のうち資料に一度も出てこない作業を数えてください。月末だけ動く処理、特定の取引先にだけやっている手順、システムの外でExcelを使って回している部分。この三つはだいたい抜けます。

聞かれないまま進みます。ベンダーは現行業務を知らないので、質問の対象にできません。要件定義で抜けるのは、難しい要件ではなく、社内で当たり前すぎて誰も口にしない業務のほうです。

足りていない、という自己認識のほうが多数です。JUASの調査では、工期、予算、品質のどれが悪化した場合でも、その要因の最上位に「要件定義の難易度向上」が挙がっています。回答の割合は47.2%から51.0%で、次点の項目を上回ります。「要件定義の時間不足」も3割前後で挙がっています。

延ばした会社が楽になっているかというと、そうでもありません。日数が増えた分だけ会議が増えて、決まる件数は変わらない現場をよく見ます。足りていないのは日数ではなく、決められる人が会議に出ている時間のほうです。

機能一覧は埋まります。埋まらないのは、いまの業務のうち何をやめるかです。ここは発注側にしか決められません。

新しいシステムに合わせて手順を変える範囲のことです。パッケージを入れるなら、製品の標準に業務を合わせるのか、いまのやり方に合わせて作り込むのか。この線引きが決まらないと、要件は増え続けます。

どの現場もそう言います。だから、この判断は現場に投げると必ず「全部残す」に着地します。そして作り込みが増え、金額と工期が膨らむ。

決めるのは、業務を変える権限を持っている人です。部長でも課長でもいい。とにかく、要件定義の会議の中で「それはやめます」と言い切れる人が要ります。

そこが要件定義の実態です。技術の話は相手が持ってきますが、この四つは持ってきません。持ってこられないからです。

逆のことが起きます。300ページの要件定義書を、業務部門の誰も読んでいない現場をよく見ます。読まれない資料は、承認されても合意になりません。

2種類に分けてください。ベンダーが設計に使う本体と、発注側が判断するための決定事項の一覧です。後者は10ページに収まります。

決定事項の一覧に載せるのは、何を決めたか、誰が決めたか、決めた前提は何か、の三つだけです。前提を書いておくと、前提が変わったときに、その決定を見直す理由が説明できます。

「初年度の取引先は300社を想定」「拠点は5か所のまま」といった数字です。これが変わると設計が変わる。書いていないと、変更が起きたときに誰も気付かないまま進み、テストの段階で表面化します。

全部を読む必要はありません。ただ、非機能要件と呼ばれる部分だけは目を通してください。同時に何人が使うか、夜間の処理は何時までに終わるか、障害のときにどこまで戻せるか。この三つは、あとから直すと作り直しになります。機能の追加は後からでも足せますが、性能と復旧の前提は後から変えられません。

要件定義の会議では通常の流れだけが語られます。受注して、出荷して、請求する。実務の負担は、その外にある例外のほうに寄っているのに。

そういうものが10個も20個も出てきます。要件定義でこれを洗い出す方法は一つです。担当者に、直近3か月で「いつもと違う対応をした件」を挙げてもらう。手順書からは出てきません。手順書に載っていないから例外なので。

入れません。分けます。システムで扱うもの、手作業で残すもの、この機会にやめるもの。例外は洗い出しても減りませんが、扱いを決めておけば追加費用にはなりません。決めていない例外だけが、後半で仕様変更として出てきます。

なります。その扱いはシステム開発の追加費用の記事に整理しました。要件定義の段階でできるのは、変更の総量を減らすことではなく、変更が出たときに「当初範囲に入っていたか」を判定できる資料を残しておくことです。

その進め方だと、後半で戻ります。共有された側は決めた実感がないので、動くものを見てから「これでは業務が回らない」と言います。悪気はなく、そのときに初めて具体的に見えるからです。

3種類の人が要ります。

この3種類のうち2番目が欠けると、会議は情報交換で終わります。論点は出るのに決まらない。決まらないまま次の議題に移り、3か月後に同じ論点がまた出てきます。

毎回でなくて大丈夫です。決める会議だけ分けてください。週次の定例で論点を溜めて、月に1回か2回、決める場に持ち込む。持ち込むときは、選択肢と、それぞれを選んだときに何が起きるかを1枚にして出します。

判断する人に必要なのは資料の量ではなく、選択肢の数です。3つ以内に絞ってあると、その場で決まります。

経験のない人が任されるのは珍しくありません。むしろ多数です。問題は経験そのものではなく、専任かどうかのほうです。通常業務と兼任でこの規模を回すと、決める会議の準備が後回しになり、そこから崩れます。

頼む相手の役割を先に決めることです。要件定義書を書いてくれる人を探すと、資料は増えますが、社内の決めごとは止まったままになります。頼むべきは、業務部門と経営から判断を引き出して、期限を切って決めさせる役割のほうです。

見極め方はPMO外注の選び方に、費用の目安はPM代行の費用相場に書きました。

間に合う場合と、そうでない場合があります。ベンダーの報告が「順調です」で止まっているだけなら、ベンダーコントロールのコツで挙げた聞き方の変更で戻せます。関係者が遅れの理由を別々に説明し始めているなら、それは通常の管理ではなく、プロジェクト炎上の立て直しの手順に切り替える段階です。

そこは減らせます。現行の業務資料と過去の議事録から、決まっていない論点を抜き出して一覧にする作業や、複数の会議で出た同じ論点を1件にまとめる作業は、いまはAIに寄せられます。手が足りない会社ほど、この部分を仕組みにしてから人を足すほうが効きます。判断そのものは人が出しますが、判断に必要な材料をそろえる時間は短くできます。

次の要件定義の会議で、決まっていない論点を数えてください。10件を超えていて、それぞれに担当者と期限が付いていないなら、まだ要件定義は始まっていません。