本郷さんのアドバイスを参考に、千石夫妻はもう一度話し合い、制限の範囲で以下のような合意に至りました。
| 寝室（2人で共同) | 12.0畳 → 8.0畳 | 寝室は1つに |
|---|---|---|
| 書斎 | 4.5畳 → なし | 当面は子供部屋を利用 |
| 風呂 | 6.0畳 → 3.0畳 | 縮小 |
| トイレ＋洗面（1階） | 2.0畳 → 2.0畳 | 変更なし |
| トイレ（2階） | 2.0畳 → 1.0畳 | 洗面なし |
| LDK | 40.0畳 → 20.0畳 | 大幅縮小 |
| クローゼット | 3.0畳 → 1.0畳 | 縮小 |
| 趣味の部屋 | 4.5畳 → 4.5畳 | 変更なし |
| 子ども部屋1 | 6.0畳 → 6.0畳 | 将来のために確保 |
| 子ども部屋2 | 6.0畳 → なし | 当面子供2人で共用 |
| 両親用個室 | 8.0畳 → 6.0畳 | 来客用と兼用 |
| 来客用個室 | 8.0畳 → なし | 不要 |
| 廊下、玄関、階段 | 0畳 → 6.0畳 | 漏れていたため追加 |
| 合計 | 102.0畳（169平方m）→57.5畳（95平方m） | |
この間取りで大筋合意に至ったようです。よかったですね。なお、千石夫妻は、後々もめないように、理由も含めて整理したこの決定内容を記録し、保管しておくことにしました。
システム開発編：ステークホルダーからの要求を取りまとめる
業務拡大に向けたネット通販サイトの立ち上げで「要件定義」を任された千石君。巣鴨課長にアドバイスをもらいながら、「カスタマイズ前提のパッケージ」を導入し、システムを構築するという方針を決定するところまでこぎ着けました。その後、システム開発のための手続きや作成文書など、社内ルールを規定した「システム開発標準」に基づいて「自社ネット通販システム化計画書」を作成しました。
さて、システム化計画書が経営会議で議論される中、要件定義が初チャレンジの千石君は、「システム開発標準」の要件定義部分を熟読しました。そして、「過去に自社がどんなドキュメントを作成してきたのか」「どのように役割分担をしたのか」など、これまでの実施内容を頭に叩き込みました。その上で、要件定義を着実に進めるためのポイントと手順を理解し、次のように実施計画を具体化しました。
- 構築する業務の全体が把握できるドキュメント類を作成する
- そのドキュメント類をもとに各ステークホルダーから要求を引き出す
- 得られた要求リストを取りまとめる
対象業務の可視化--ステークホルダーを確定し、確実に要求を引き出す
巣鴨課長：千石君が作成したシステム化計画書だけど、経営会議で無事に承認されたよ。おめでとう。
千石君：ありがとうございます。では、これから販売部門に行って、ネット通販システムへの具体的な要求を聞いてきます。
巣鴨課長：販売部門だけ？ 他の部門は？ 構築するシステムに関わる利害関係者（＝ステークホルダー）を洗い出してごらん。
千石君：製造部門とかコールセンターも関わってきます？
巣鴨課長：まずは自分の頭で考えようか。それと「システム構築の最終ゴール」は何だったかな？
千石君：会社としてのビジネスの成功です。
巣鴨課長：その通り。そうなると、ビジネスに関連する全ての部門に話を聞かないといけないよね。ビジネスやシステムの関係者を漏れなく洗い出すためには、「ステークホルダー俯瞰図」を描いてみると分かりやすいよ。まずはステークホルダーをリストアップしてごらん。
千石君：こんな感じですかね。
巣鴨課長：ツボを押さえているね。素晴らしい。じゃあ次に、これらのステークホルダーが関わる「概略業務フロー図」を書く必要がある。これをやってみようか。
千石君：ヒントをください。
巣鴨課長：「概略業務フロー図」は、例えば、サイトを訪れた顧客が商品の比較検討から商品購入までに至るといったビジネスの“シナリオ”を想像し、そこに「どのステークホルダーが」「どのタイミングで」関わってくるのかを可視化するものだ。
「概略業務フロー図」は関係者から要求を聞き出すときにとても役に立つ。具体的なフローがビジュアルで示されると、人間は考えやすくなるからね。もちろん、この時点で全てのシナリオを考える必要はなく、また、完璧なものを作る必要はない。代表的なものをいくつか考えて、徐々に膨らませ精緻化していけばいいんだ。場合によっては、「ステークホルダー俯瞰図」を更新していくこともある。
千石君：「ステークホルダー俯瞰図」や「概略業務フロー図」は、システム設計にとって必ず通る道なんですか？
巣鴨課長：いい質問だね。この2つの図は「抜け漏れ防止」に有効なんだ。要求に抜けや漏れがあると、設計や製造の段階で気付くことはほぼ不可能だ。総合テスト段階で「ごめん。○○が抜けてた」というケースは意外と多い。でも、それでは開発し直すにしろ、不完全な状態でリリースするにしろ、ビジネス上の影響は甚大だからね。
千石君：課長には何か苦い経験がありそうですね？
巣鴨課長：鋭いね。実は、要件定義段階でのステークホルダー間のコミュニケーションが十分でなく、関係者が立ち合う総合テストの時に重大な機能間インターフェースの不整合が見つかったことがあった。
あの時は大変だったなぁ。修正のために1カ月間サービスの開始を遅らせたよ。重要なことは、検討段階の状況を見える化し、常に関係者間で共有することであって、そのためには俯瞰図や概略図が有効なんだ。
千石君：体を張ったご教訓、ありがとうございます。
早速、千石君は1人で会議室にこもりました。そして、かつて在籍していた事業部門での経験に基づいて、想定するパッケージのサポート機能も念頭に置きつつ、ネット通販システムが使われて自社商品が購入されるシナリオなどを想像し、その業務の流れをラフスケッチしながら「概略業務フロー図」を作り上げたのです。
千石君が最初に作成した概略業務フロー図
