要件定義は経営目的から始めよ。システムは現場の道具ではなく、経営リソースである
聞いたはずなのに、後から「全然違う」と言われる。要求が次から次へと増えて、いつまでもまとまらない。現場からうまく聞き出せている自信がない——。要件定義のこうした悩みは、別々の問題に見えて、根っこはひとつです。要件の採否を判断する物差しを持たないまま、現場の要望を集めてしまっていること。物差しになるのは経営の目的だけです。だから本連載は、この一文から始めます。システムは「現場の道具」である前に「経営リソース」である。
この記事は、要件定義を任された情報システム部門・PM・発注側の担当者、そしてシステム投資を決裁する経営層に向けて書いています。読み終えると、「現場要望の積み上げ」がなぜ失敗するのかの構図が分かり、要件の採否を一瞬で仕分ける一行判断基準と、経営ヒアリングの冒頭で明日そのまま使える質問5つが手に入ります。あわせて記事の終盤で、冒頭に挙げた悩みのそれぞれをどの回で解決するのか、全25回の連載マップを示します。
経営リソースとしてのシステムとは（定義）
経営リソースとしてのシステムとは、ヒト・モノ・カネ・情報と並び、経営目的の達成に貢献させることを前提に投資・評価されるシステムのことである。
対になる考え方が「現場の道具」観です。現場の道具と捉えれば、要件定義のゴールは「現場が使いやすいこと」「今の業務がそのまま回ること」になります。経営リソースと捉えれば、ゴールは「投資に見合うリターン（売上・利益・スピード・リスク低減）を生むこと」に変わります。どちらの視点に立つかで、同じヒアリングをしても、採用される要件はまったく別物になります。
誤解のないように言えば、現場の使いやすさが不要だという話ではありません。順番の問題です。経営目的という「幹」を先に立て、現場の使いやすさは幹を太らせる「枝葉」として設計する。この順番が逆転した瞬間に、システム投資は迷走を始めます。要件定義とは、要望を集める作業ではなく、経営の意思をシステムの仕様に翻訳する仕事なのです。
なぜ現場要望の積み上げは失敗するのか
失敗の構図はいつも同じです。「要件定義＝現場の要望を漏れなく集めること」と考えた担当者が、各部署にヒアリングをかける。現場は善意で「あれも欲しい、これも必要」と答える。断る基準を持たない担当者は、集まった要望をそのまま要件一覧に積み上げる。結果、開発費は膨らみ、納期は延び、出来上がったのは「現場の今のやり方を高いお金で焼き直しただけのシステム」——経営が期待した効率化やスピードは、どこにも実装されていません。
原因1：要件の採否を判断する物差しに「経営の目的」がないことが原因です
要件の採用・不採用を決める基準がなければ、集まった要望はすべて要件になります。基準の不在は担当者の性格の問題ではなく、プロジェクトの設計の問題です。
要件定義を「全社で取り組むべき経営の仕事」と位置づけていないことが、物差し不在の根本にあります。この点は、国の機関も明確に警告しています。
要件定義はシステム部門だけの仕事ではなく、経営層や業務部門も参画して全社で取り組むべきものであり、現行システムの再構築における「現行踏襲」「今と同じでいい」という要求はトラブルの元となる（要旨）
原因2：要望が「声の大きさ」と「現状維持バイアス」で膨らむことが原因です
物差しがない現場では、要望の量は経営インパクトではなく発言力に比例します。声の大きい人の要望から順に要件化され、静かな部署の重要な業務は漏れていきます。
さらに、要望には現状維持バイアスがかかります。現場にとって最も安心なのは「今と同じ」であり、放っておけば要件は現行踏襲に引き寄せられます。要件定義の失敗が珍しい事故ではないことは、統計にも表れています。
システム開発の工期・品質の遵守率は低下傾向にあり、予定どおりにいかなかった要因として「要件定義の時間不足」「要件定義の難易度向上」が工期・予算・品質のいずれでも上位に挙げられている
【実例】要望の2割は、経営とも業務効率化とも関係がなかった
私たちは小売・アパレル業界を中心に、受発注・在庫管理といった基幹システムや顧客管理システムの構築を数多く手がけてきました。その経験から言える実感値があります。現場要望として挙がるカスタマイズ・新規開発要件のうち、およそ2割は、経営の目的とも業務の効率化とも関係がありません。
典型的なのは「年に一度しか使わない業務のための専用機能」です。発生頻度も金額インパクトも小さいのに、声の大きい担当者が強く主張するために要件一覧に載り、開発費だけが積み上がっていく。しかも要件がいったん確定した後でも、現場は「変えると業務が回らない」と言って、設計を現状のやり方へ引き戻そうとします。効率化のために業務フローを変える設計にしても、気づけば元の形に戻っている——これが現場要望主導のプロジェクトで実際に起きることです。
注目すべきは、こうした要件の「その後」です。私たちは判断に迷う要件の優先度を下げ、2次開発（稼働後の追加開発）に回すことにしています。すると1次開発のシステムが稼働した後、その多くは「やっぱり不要」と判断されます。本当に必要なものなら、稼働後に真っ先に現場が困るはずです。困らなかったということは、最初から経営リソースとしての価値がなかったということです。
経営リソース起点の要件定義のやり方：最初の5ステップ
手順は次の5ステップです。要望を集める前に、仕分けの物差しを先に作ります。
ステップ1：経営目的を一文で確認する
最初のヒアリング相手は現場ではなく決裁者です。「このシステム投資で、何がどう変われば成功か」を一文で言えるまで確認します。
一文で答えが返らない場合、要件定義を始めてはいけません。曖昧さ自体が、経営に持ち帰るべき最初の報告事項です。
ステップ2：目的を測れる数字に翻訳する
「効率化」のままでは判断基準になりません。「出荷リードタイムを2日短縮」「棚卸工数を月20時間削減」のように、効果を測る数字を1つ決めます。
数字が決まると、以降のすべての要件を同じ物差しで測れるようになります。
ステップ3：現場要望を3つに仕分ける
集めた要望を「目的に貢献する／中立／無関係」の3分類にかけます。仕分けの物差しは使いやすさではなく、ステップ2の数字への貢献です。
各要望には「発生頻度×金額インパクト」のメモを添え、数字で並べ替えてください。発言力と経営インパクトは比例しません。
ステップ4：迷う要件は2次開発リストに落とす
判断に迷う要件をその場で切ると、現場との関係がこじれます。「1次稼働後に再評価する」と約束してリスト化すれば、角を立てずに、時間がふるいにかけてくれます。
実際、2次開発リストに落とした要件の多くは、1次稼働後に「不要」と判断されます。
ステップ5：採否の理由を経営と現場の両方に説明する
「なぜ載せたか・なぜ落としたか」を経営目的に紐づけて説明します。この一手間が、後の「言った・言わない」問題の予防線になります。
やってはいけないNGパターン
NG1：全部署に「要望をお寄せください」とアンケートを配る 判断基準を決める前に要望を集めると、断る理由がないまま母数だけが膨らみます。集める前に、仕分けの物差しを先に作ってください。
NG2：声の大きい人の要望から要件化する 発言力と経営インパクトは比例しません。要望は必ず「発生頻度×金額インパクト」の数字で並べ替えてください。
NG3：「現行と同じにしてほしい」を要件として受理する 現行踏襲は要件ではなく、要件定義の放棄です。「今のやり方の、どの結果を守りたいのか」まで分解して初めて要件になります（この深掘りの技術は連載第2回で扱います）。
よくある質問
現場の要望は聞かなくていいのですか？
聞きます。むしろ徹底的に聞きます。ただし目的が違います。要望を「集めて載せる」ためではなく、業務の実態と制約を「理解して、経営目的に照らして仕分ける」ために聞くのです。
現場の声に共感することと、現場の要望に同調することは別物です（第2回で詳しく扱います）。
経営目的が曖昧な場合はどうすればいいですか？
要件定義を始めてはいけません。決裁者に「この投資で3年後に何が変わっていれば成功ですか」と聞き、一文で答えが返るまで確認してください。
ここが曖昧なままのプロジェクトは、要件の採否を判断する物差しがないため、要望が膨らみ続けます。
現場が使いにくいシステムでは、結局定着しないのでは？
そのとおりです。だからこそ「順番」が重要です。経営目的で要件の骨格を決めた後、その骨格の中で操作性や画面設計を現場と磨き込みます。
使いやすさは、経営リソースとしての価値を高める重要な手段ですが、目的そのものではありません。
あなたの悩みは、どの回で解決するか（全25回の連載マップ）
この連載は「思想 → 問題提起 → ヒアリングの技術 → 成果物 → 実践」の順で、冒頭に挙げた悩みをひとつずつ型に落としていきます。ブックマークして、必要な回から読んでください。
「要求が後から増え続けて、まとまらない」 → 本記事の一行判断基準と、第2回「現場に流されない技術」、第19回「要件が膨らみ続けて終わらない」で解決します。
「現場からうまく聞き出せない。本音が出てこない」 → 第2部・ヒアリングの技術（第6〜10回）。仮説検証型の聞き方、本音の引き出し方、深掘りの作法、例外の発掘までを扱います。
「聞いたはずなのに、後から『全然違う』『そんな業務もある』と言われる」 → 第9回「業務フロー図をその場で描く」、第12回「議事録と合意形成」、第18回「帳票・データ起点の裏取り」で解決します。
「そもそも要件定義に自信がない。何が正解か分からない」 → 第3〜5回で失敗の共通パターンと「業務要件と機能要件の違い」という基礎の型から固めます。
「現場と経営の板挟みがつらい」 → 第2回・第15回・第16回。判定基準を経営目的に置くことで、板挟みは構造的に解消できます。
各回の公開にあわせて、この一覧に記事リンクを追記していきます。
明日使えるボックス：経営ヒアリング冒頭質問5選＋一行判断基準
次の経営ヒアリング（またはキックオフ）の冒頭で、そのまま使ってください。
経営ヒアリング冒頭質問5選
「このシステム投資で、3年後に何が変わっていれば成功だと言えますか？」
「この投資に踏み切る判断材料になった経営課題は何ですか？」
「効果を測る数字を1つだけ挙げるとしたら、何ですか？」
「逆に、このシステムで『やらなくていいこと』は何ですか？」
「現場の要望が対立したとき、最後は何を基準に決めますか？」
一行判断基準（要件の採否に迷ったら）
その要件は、経営リソースとしてのシステムの価値を上げるか？
Yesと言えないものは、2次開発リストへ。1次稼働後の再評価で、本当に必要なものだけが残ります。
まとめ：今日の1アクション
この記事の要点は次の3つです。
システムは「現場の道具」である前に「経営リソース」。要件定義は要望収集ではなく、経営の意思の翻訳である
現場要望の積み上げが失敗するのは、採否の物差し（経営目的）の不在が原因。要望の約2割は経営とも効率化とも無関係になりがち
手順は「経営目的の一文化→数字への翻訳→3分類の仕分け→迷ったら2次開発→採否理由の説明」の5ステップ
まずは、いま関わっているプロジェクトの経営目的を一文で書いてみてください。書けなければ、それが決裁者への最初の質問です。
この連載について
要件定義と業務ヒアリングのスキルを「センス」ではなく「型」として学ぶ全25回の連載です。
次回：「変わりたくない」に流される要件定義担当へ ― 現場の味方と御用聞きは違う
連載マガジン：
アストロラボのほかのマガジン
noteでは、この連載のほかにも実務直結のマガジンを公開しています。
マガジン一覧はこちら：
業務調査からシステム開発まで、一気通貫のアストロラボ
私たちアストロラボは、小売・流通を中心に企業のDXを支援してきた会社です（2012年設立）。「レガシーを、セクシーに。」を合言葉に、いきなりシステムを作るのではなく、まず現場の業務を調べて流れを描き直す「業務設計」から入り、システム選定・ベンダー選定、そして最適な既製品がなければ自社での開発まで、一気通貫で伴走します。
この連載で紹介している質問の型やヒアリングの技術は、私たちが業務調査と要件定義の現場で実際に使っている考え方です。私たちはシステムを「現場の道具」である前に「経営リソース」だと考えています。現場の声を丁寧に聞きながらも、要件の採否は常に経営目的に照らして判断する。この軸があるからこそ、投資に見合うシステムを定義できると考えています。
「要件定義から手伝ってほしい」「今受けている提案や見積もりが妥当か見てほしい」「そもそも何から手をつければいいか分からない」といった入口の段階からご相談いただけます。
自社の業務に合わせた進め方を相談したい方は、お気軽にお問い合わせください。
ともに挑戦する仲間を募集しています（長期インターン）
「レガシーを、セクシーに。」——使いづらい仕組みを、思わず触りたくなるものへ変えていく。アストロラボは、その挑戦を本気で面白がれる長期インターンを募集しています（短期の受け入れは行っていません）。クライアントワーク（クライアントの現場にも足を運びます）、システム開発、営業、マーケティングまで、職種やフェーズの垣根を越えて、事業づくりの最前線をまるごと体験できます。任されるのは雑用ではなく、プロジェクトの一翼を担う本物の仕事です。腰を据えて打ち込むほど見える景色は変わり、実際に約2年のインターンを経て関連会社の社長に就任した先輩もいます。デザインやUI/UX、AI活用をはじめ、アパレル・小売・食品といった業界のDXに現場の当事者として関わりたい方を待っています。
応募はこちらのフォームからお願いします。
執筆：アストロラボ株式会社 代表取締役CEO 日下ヤスユキ
業務調査からシステム開発までを一気通貫で手がけるアストロラボの代表。小売・アパレルの基幹システムを中心に、大手30社以上のシステム導入・刷新に携わる。
#要件定義 #システム開発 #アストロラボ
#経営戦略 #DX #ITコンサル #システム導入 #業務改善 #情シス #IT投資
【概要】
「聞いたのに違うと言われる」「要求が増え続ける」——要件定義の悩みの根は、採否の物差しの不在にあります。一行判断基準と経営ヒアリング質問5選、全25回の連載マップを掲載。「型」で学ぶ連載第1回（代表執筆）。
