要件定義ってそんな簡単ではないです。

まずは見える化の定義が、根本的に人による属人的なもので、経験によるところは大きいです。何をどのように見えるようにするのか？

システムの要件定義では、要求を元にシステム化の範囲を明確にしていきます。その中で実現する機能、画面、ユーザインタフェースなどを決めていきます。また、業務の流れや業務独自のルール、データなどの業務分析を行ったうえで、構造に関わる業務フローとシステムのかかわりを決めていきます。

中にはフォーマットあれば埋めるだけでいいなんて頓珍漢な人もいるけど、これはそんな程度でも作れるシステムしか作ってこなかったという証でもありますね。

要件定義をやるひとによっては、聞いたこと、つまり要求ををただただ要件として定義するなんてビギナーも多いですが。その場合の問題は、矛盾満載な要点定義ができあがったり、業務分析ができていないので現場で使いもにならないなんてことになる場合もあります。

既存システムや連携するシステムがあれば、特に調査分析したうえでないと定義できない部分が多いです。しかし現実的には資料やドキュメントだけもらって、それが正しいという前提で定義する場合も多いですが、その結果！痛い目に合うという場合も多いでしょう。

ドキュメントが正しく保守されている場合であっても、やはり動作させた結果を見て判断するという調査分析をおこなうことは重要です。

その点新規であれば、その負担は大きく減ります。

誰が、何をするシステムなのか？そして、その結果何を得ることができるのか？　つまり、実のことを言うとシステム的ではなく人間的にどうなのかをまず決めるところからはじめるのです。

素直に、最初に何が欲しい！だけがあると話もスムーズです。

結構、仕組みを語る人も、実装レベルの詳細な話から始める人とかもいますが、

その前に、

何が欲しい。なぜ欲しい。

要件定義で決めたいのは、

「システム化の背景や目的」と「そのシステムの機能一覧、および機能概要」なのです。　

ここが不明だったり曖昧だったりするのに、詳細にはいっても、ちょっと意味不明で私たちも理解が追いつけない場合が多いです。

よくシステムのことはよくわからないからと言う人がいますが、それでいいんです。下手に中途半端に知って混乱を招くよりも、何を実現したいのかを言ってくれるだけでよいのです。それをどのように実現するとかのやり方は、無数にありますし、こちらで考えて提案いたします。。

今の時代では、なんでもWEBにしたがる傾向もありますが、WEBアプリケーションにする必要性もないのにWEBアプリにしたり、わざわざ一枚岩のシステムにして使いにくく保守し難くしなっていたりとか、お客様のシステムをみるとそういった場合のものも多くありますね。

できるだけ短納期で実現するために、よく設計されていないシステムというのは、実装レベルでゴリゴリの制御をコードとして書いてあれば、その後の保守性は悪くなりますし、拡張しにくい、運用しにくいシステムになります。

ですので、機能実現だけでなく、それを誰が、どこで、どのように使うのか。も大きく影響します。

１社だけで利用するWEBアプリケーションシステムなのか、

マルチテナント化で複数社が利用するのか。

１社で使えるものができたら、それを横展開とか安易に言っている人も多いですが、横展開したいという要求になり、それをどのように実現するかというパタンによって要件は異なります。

この場合、データベース自体を分離するのか、データベースは共通でテーブルに会社idでわけるのかとかいったそういった構造にかかわる要件です。

これらは、実際に稼働した場合のパフォーマンスや利用者アクセスに対してのセキュリティなどといった、非機能要件にも大きく影響してきます。

予算感もまったく変わってきますので、この辺を抑えたいがために、安易に考えているとあとあと余計にコストになることが多い事例をたくさんみてきました。

やるやらないは別として、やりたいことは要求としてだしておくのがよいです。フェーズをわけて将来やるのであれば、そのための準備をさきに用意しておくことができれば作り替えにはならず改修で済みます。システム構造の根幹に影響するような大改造は、改修ではなく、別システムの開発になるのです。

前置きが長くなりましたが、要件定義では、つくるべき機能をユースケースとして定義していきます。

取り扱うデータを拾い上げテーブルやデータファイルの対象としていきます。

それらを実現するために、画面や機能を決めていきます。まだこの段階では一覧と概要レベルで、要求を網羅しているかどうかの判断です。

要求の中で、不明確なポイントは、調査します。

例えば、新しいインタフェースの実現であれば、プロトタイプをつくって動作検証した方が早いです。

画面遷移やデータモデルは、決まった時点で生成させてモックレベルでの確認をしてもらったほうが早いです。

このあたりを先にドキュメントを書いてやっているところからすると、圧倒的に早いです。しかも動くもので確認できたあとにユースケース図、ユースケース一覧、論理レベルのテーブル構成、ER図などは用意します。

🧭 要件定義の本質を伝える流れ

① 問いを立てる ― 「なぜ作るのか」を掘り下げる

• 背景・課題・目的を言語化する
• 現場で何が困っているのか、何を良くしたいのかを聴く
• 「誰のためのシステムか」「何を達成したいのか」を共有する

🔹ここでのゴール：
「目的」と「成功の定義」が、関係者全員で一致すること。

注意しなければならないのが、目的やゴールが、役割によって異なることが多いです。役員と現場では違うことを考えているとか、とりあえず会社の方針に合わせてはいるが、本音が違うところにあるとか。

この「目的やゴールの多層構造」を理解できていないと、どんなにロジカルな要件定義をしても現場で崩壊します。
以下に、その構造と注意すべきポイントを整理します。

🎯 目的とゴールのズレを理解する ― 要件定義における“最初の地雷”

「目的」は一つではない ― 立場によって“関心や目的”が違う

💡ポイント：

同じ「目的」という言葉でも、立場によって意味が違う。
だから「何をもって成功と言えるか」を、全員で言語化して共有する必要がある。

1.1 表面的な“合意”が、のちの“分裂”を生む

要件定義の序盤でありがちなパターン：

• 「会社方針だから」と全員がとりあえず賛同する
• しかし実際のヒアリングでは「現場は反対」「本音は違う」
• そのまま開発に入ると、テスト段階で大炎上

📉つまり、「賛同しているようで、腹落ちしていない」状態が最も危険。
要件定義者は、“合意”ではなく“納得”を引き出すことが求められます。

1.2 “本音”を引き出すには、ヒアリングの構造を変える

単に「何が困っていますか？」では、表層的な回答しか得られません。

効果的なのはこの順序：

1. 現状の事実を確認する
   　「今の業務フローでは、どこに時間がかかっていますか？」
2. 感情を聞く
   　「そのとき、どんなストレスがありますか？」
3. 理想を聞く
   　「もし制約がなかったら、どういう形が理想ですか？」
4. 経営視点をつなぐ
   　「それが実現すると、組織全体にはどんな効果がありますか？」

この４層のヒアリングで、**建前（toC）と本音（toMe）**の両方を抽出できます。

1.3 ズレを“可視化”して、対話の材料にする

立場ごとの目的・懸念・価値観を「対立」ではなく「差異」として見せるのが要件定義者の仕事です。
そのために、関係者マップ＋目的マップを描くと効果的です。

👆 このように、全員がどの視点から話しているかを見える化することで、
「言っていることは違うけど、目指している方向は同じ」という安心感が生まれます。

1.4要件定義者の役割：ファシリテーターであり翻訳者

要件定義は「要望をまとめる作業」ではなく、
異なる立場の“目的言語”を翻訳して、共通理解をつくる行為です。

• 経営語（ROI・KPI・コスト最適化）
• 現場語（操作性・負荷・リアル運用）
• 技術語（API・DB設計・運用性）

この３つを橋渡しできる人が、本当の要件定義者です。

要件定義とは「目的の共通言語化」である。
立場ごとのゴールの違いを可視化し、共通の“成功像”を描けるかどうかが勝負。

② 現状を把握する ― 「いま何が起きているのか」を理解する

• 現行業務・既存システムの流れを可視化する
• ドキュメントだけでなく、実際に動かして観察する
• ヒアリングでは「形式」より「実態」を重視する

🔹ここでのゴール：
事実を確認し、“思い込み”を排除する。～のはず。～だと思う。とか言われたらその根拠を示せるように動作確認しておくことです。動いたものしか、もしくは動いた結果のデータなどで確認しましょう。

③ 課題を整理する ― 「どこにギャップがあるのか」を明確にする

• 現状（As-Is）と理想（To-Be）の差分を洗い出す
• 技術課題・運用課題・組織課題を分けて整理
• 「なぜそれが課題なのか？」を何度も問い直す

🔹ここでのゴール：
課題の“本質”を特定する。
（＝対症療法ではなく原因にアプローチする）

④ 目標像を描く ― 「どうなったら成功か」を定義する

• システム導入後の理想的な業務・ユーザー体験をイメージする
• 関係者間で合意を取る（スケッチやモックでも可）
• 「実現したい未来像」を共有し、方向を一本化する

🔹ここでのゴール：
関係者全員が同じ未来を思い描ける状態をつくる。作る人任せになっているケースでは、もうやりきれなくなって、だんだん作ることが目的になりますね。そうなるとなんとなくうまくいっているとおもったら、ぜんぜん目的とは違うシステムができあがる結果になったなんていうプロジェクトも多くみてきました。

⑤ 要件を構造化する ― 「何を実現するか」を具体化する

• 要求事項を整理し、重複・矛盾を排除
• ユースケース（誰が・何を・どうする）を定義
• 機能要件と非機能要件に分解する
  　- 機能要件：実装すべき処理や画面
  　- 非機能要件：性能・セキュリティ・運用性・拡張性など

🔹ここでのゴール：
「やりたいこと」を「実現できる構造」に変換する。

プログラムもシステムも、どのようにでも実現できてしまうというのが怖いところです。一般の人からすると中身はどうでも良いと思いがちですが、どのように実現するのかは大事なことです。システムの構造が制約を生むのか、拡張性はどうなのか、構造によるメリット、デメリット、なぜその構造なのか？はしっかりと把握しておくべきです。

⑥ 検証と合意 ― 「本当にこれでいいか」を確かめる

• モックアップやプロトタイプで確認
• 要件ごとの実現性と優先度を確認
• ステークホルダーと正式に合意する（要件定義書にサイン）

🔹ここでのゴール：
「これを作れば目的を達成できる」と全員が確信している状態。

⑦ 設計への橋渡し ― 「どう作るか」に移す

• 要件を設計情報（ER図・画面一覧・処理フロー）に変換
• 開発チームが迷わないレベルまで明文化
• 要件定義者は「仕様の翻訳者」として設計者に伴走する

🔹ここでのゴール：
意図が正しく設計に伝わること。

🌱 要件定義の本質とは

「人の想いと技術をつなぐ、翻訳と設計のプロセス」

• 聞く力（傾聴・観察）
• 整理する力（構造化・抽象化）
• 伝える力（合意形成・言語化）
  この３つが揃って、はじめて“本当の要件定義”が成立します。

🧭 「〇〇さんがそう言ってたんで」を防ぐために ― 要件定義者の実践５原則

① 「言葉」を鵜呑みにせず、「意図」を聞き取る

人が発した言葉を**“そのまま仕様化しない”**こと。
本当の要件は、言葉の裏にあります。

❌ NG：

「帳票が出せるようにしてほしい」→ 帳票機能を作る

✅ OK：

「なぜ帳票が必要ですか？」→ 「取引先に毎月提出が必要」「監査証跡を残すため」

👉 真の要件：
「提出義務を満たすための証跡データ出力機能」
（帳票ではなく、CSVエクスポートでも十分かもしれない）

つまり、“言葉”を受け取るな、“背景”を掘れ。

② 記録するだけでなく、“確認”する

ヒアリングの議事録やメモを取るのは当然ですが、
その内容を顧客と一緒に再確認することが重要です。

「私の理解ではこういう意図でよろしいでしょうか？」
「こう実現した場合、お客様の目的に合致しますか？」

📄 この「理解確認プロセス」を要件定義の正式手順として組み込むことで、“聞き間違い”“思い違い”“想定の違い”を潰せます。

③ 断片ではなく「全体構造」で考える

顧客が話す内容は、必ずしも全体像を意識していません。
だからこそ、要件定義者は**“全体地図を描く役割”**を担います。

• 個別要望（木）を聞きながら
• システム全体（森）の構造に位置づける

🧩 部分最適の積み重ねが、全体最適を壊す。
だから要件定義者は「俯瞰と整合」を常に意識し、
「これは全体設計上、どの層の話か？」と考えながら聴くことが重要です。

④ “言われた通り”よりも、“納得して提案する”

「お客さんが言ってるんだから、そのまま作れ」
というのは、プロではなくオペレーターの思考です。

プロの要件定義者は、**「それは本当にお客様の利益につながるか？」を判断し、
必要であれば、“反論”ではなく“提案”**で返します。

例：

「ご要望のA機能は実現できますが、
目的が○○であれば、B案の方が運用コストが抑えられます。
比較してみましょうか。」

この「問い返す力」こそが、要件定義の本質的スキルです。

⑤ 「合意」を残す ― 言葉ではなく“証跡”で共有する

要件定義の最終目的は「全員の理解を一致させること」。
そのためには、口頭ではなく、合意文書として残す必要があります。

• 要件定義書（概要・目的・ユースケース）
• 合意メモ（顧客承認印 or 電子承認）
• モックや画面プロトタイプ（動く理解）

📝 文書化の目的は「責任回避」ではなく、
“共通の真実”をつくるためです。

💡 結論：

「お客さんがそう言ってた」は、
“聴き手の思考が止まった証拠”。

要件定義者がやるべきことは、
「言葉を聞く」ことではなく、「意図を理解し、価値に翻訳する」こと。

そして最終的に、

“顧客も気づいていなかった本当の要件”を明らかにすることこそ、
要件定義者の責任であり、醍醐味です。