■現状の業務とシステムを棚卸しする９大フォーマット
業務系フォーマット
①現行業務フロー
②現行アクティブティ一覧
システム系フォーマット
③現行ファンクショナリティ・マトリクス
④現行システム一覧
⑤現行インターフェース一覧
⑥現行全体システム一覧
⑦現行システムの主要データ
⑧現行コード体系
共通フォーマット
⑨課題一覧
■将来業務フローを作成する６つのテクニック
①変化点を必ず書き出す
②まずはアナログで作る
③フォーマットを決める
④メインフローが先、イレギュラーが後
⑤詳細はとりあえず脇に置く
⑥１人で作らず、人を巻き込む
■システム要求の３大障壁
①完璧なリストアップができない
②常に予算オーバーになる
③立場が違えば、システムに求めるものが変わる
■システム構築スケジュールを精査する６つの視点
①MUSTな期限が守られているか
②業務繁忙期とシステム構築のピークは重なっていないか
③工程ごとのゴールが明確か
④成果物をチェックするマイルストーンはあるか
⑤各領域の整合が取れているか
⑥各フェーズの期間バランスが適切か
■良い開発チームを作る９原則
１．ユーザーが参加し続ける
２．保守をにらむ
３．エキスパートとのつながり
４．OneTeamにする
５．WhyやHowをきちんと伝える
６．言葉と進め方は明確に
７．ストレートに意見を言い合う
８．プロジェクトルームはできれば１つ
９．学び合う
■キーチャート７選
①ステータスマトリクス
②ステータス×操作可否
③機能×利用者権限
④BOMごとの管理情報
⑤採算管理における集計対象
⑥承認プロセスのキーチャート
⑦受注チャネルのバリエーション
2026/6/7
F章 システム要求 (What) を決めるプロセス
この章のレッスン
・システムを作る上で重要となるシステム要求定義の流れを理解する
・システム要求をまとめる上で難しい点を把握し、「なぜこのプロセス・成果物ならうまくいくか」がわかるようになる
これまでのフェーズでプロジェクトのWhyとHowが固まったので、ようやくWhat、つまり「どんなシステムを作るのか」を決める Scope フェーズを開始できる。一般的には要求定義、要件定義などと呼ばれる工程だ。 この章は要求定義の最初の章として、全体を俯瞰するための3点を説明する。
・要求定義とはなにか? (言葉の整理など)
・要求定義はなぜ難しいのか?
・要求定義(特に機能要求定義)のステップ
システム要求、要件、そして設計
要求定義と要件定義という言葉は一般に、「誰がその作業の主体か」に着目して、以下のように使い分けられる。そして設計はそれらに続く工程た。
要求定義
システムを作らせる人が、「システムはこんな風であってほしい」と、 システムに求めることを明確にする作業。システムに詳しくない人が定義するので、システム的な厳密性、網羅性には欠ける。
要件定義
システムを作る人が、システムに必要とされる性能や実装すべき機能などを明確にする作業。システムが果たすべき機能はすべて要件定義書に書かれるべきなので、例えば「どういうケースでエラー表示をするか?」の一覧表を作るプロジェクトもある。
設計
システムを作る人が、要件を実現する技術的な方法を決める作業。例えば「この機能は○○というソリューションを使う」 「データ構造はこうする」といった具合だ。ユーザーから目に見える画面レイアウトなどを固める設計を「外部設計」、目に見えない内部ロジックを考える「内部設計」 に分ける場合もある。
イメージしにくいと思うので、まずは住宅の例に当てはめてみよう。
要求
・キッチンは明るい方がいい
・トイレは2ついらない
・風通しの良さが重要
要件
・キッチンは2階に
・トイレは階段の下に作る。したがって天井は低くなる
・階段の上に、常時開けておける小さい窓を作る
設計
・実際の設計図
こう整理して書くと当たり前に見えるのだが、要求は家に住む人にしか言えない。トイレが2つあることが書斎よりも重要、という人も中にはいるだろう。どっちが正しいという話ではない。何を重視するか? という価値観で決めることだ。
そして要件は住む人と建築のプロとの共同作業になる。「キッチンは絶対に2階がいいんです!」と主張する施主もいるだろうし、「2階のキッチンは明るくて良いものですよ」とプロが提案し、それに施主が賛同する場合もあるだろう。
また、プロからの要件の提案を受けることで、施主が自覚していなかった要求が浮かび上がることもある。例えば「キッチンを2階にすると、子ども部屋に行くのにキッチンを通らない。思春期になったら親子の会話が減りそうでイヤ!」という具合だ。
それに対して、設計は完全にプロの領域だ。キッチンを2階に設置することで、水回りの配管をどう巡らせるべきか? といったことは専門家でなければわからない。それらを全て踏まえた上でベストな設計図を書く際に、中途半端に素人が口を出すとかえって悪くなるものだ。
ここで描いた施主とプロの建築家の関係は、そのままシステムを作らせる人と作る人の関係になぞらえることができる。要求/要件/設計それぞれについてシステム構築での例をあげると、
要求
・契約条件は同じ顧客との間では頻繁には変更されない。だから受注の際には条件を都度入力したくない
・上司は部下の職務経歴を自由に参照できるようにしたい
要件
・契約条件は契約マスターに登録する。受注の際には契約マスターから条件を自動で受注画面に表示することで、都度入力する手間を省 <
・上司が職務経歴を参照できる「部下」とは、同じ組織に属し、かつ職位が自分より低い社員のこと
設計
・受注データは契約データとリンクを張り、受注画面に条件を自動で表示できるようにする。ただし受注画面で条件を変更することもできる
・組織マスターの管理職情報と社員マスターの職位情報をプログラムが読み取り、参照権限を自動でコントロールする
といった感じになる。
設計について中途半端に素人が口を出すとかえって悪くなるのも、住宅と同じである。例えば「職務経歴を自由に参照できるように」を実装する方法は、何通りかあるかもしれない。その場合はITエンジニアが技術的なメリット/デメリットを踏まえてベストな方法を選ぶべきだ。ユーザーが良かれと思って「組織マスターの管理職情報を使え」と言うと、ITエンジニアは「使わなければならない」と捉え、足かせになってしまう。
まとめると、
「要求はお金を払うユーザーが出す。設計はプロのシステム開発者がやる」
となる。これが大原則だ。「システムを作らせる技術」をテーマとした本書で、要求定義について多くの章を割くのは、作らせる人が主役となる工程だからだ。作らせる技術のうち、要求定義はかなりの割合を占める。「欲しいシステムをもれなく、正確に表現する技術」と言ってもよい。
