techbeans / Industry Pains
it-services-05情報通信業 ・ 要件定義・PM

要件定義・PM疲弊

強度頻度引用24件

要件定義・PM疲弊

一行要約

受託SIer・受託開発・SES現場のPM／PMO／PdMが、要件定義フェーズで「ユーザー自身が何を欲しいか言語化できない」「エッジケースが組織内で身体知化していて引き出せない」「システム刷新は7〜14年に1回で発注者側の経験ゼロリセット」という構造的不可能性を抱え、上流の見積甘さと正常化バイアスが時間差で結合テスト・受入テストで一気に表面化し、PMが寝落ち・救急搬送・月400時間労働の炎上対応に追い込まれる。営業（PL／売上）と開発（BS／資産）の対立、機能要望リストを開くのが怖い心理、ガントチャート崩壊、デイリースクラム形骸化、「完璧な要件定義など諦めて漏れと変更に覚悟を決める」という諦めの境地までが、25年以上同じパターンで繰り返されている。

ペインの核

受託開発・SIer・自社開発それぞれの現場で、要件定義フェーズは「日々葛藤と自己嫌悪が止まないのが要件定義フェーズ」（ponzu）であり、「正直エンジニアなんだから開発だけさせてくれよ、エクセル開きたくないよ」（ponzu）と現場のフリーランスエンジニアが嘆き、「要件定義がたいして進まず1日が終わった日なんかには、実質の成果はエクセルでちょっとお絵描きしたくらいなので『私何やってんだろ』」（ponzu）と1日の徒労感がそのまま自己効力感の毀損につながる。原因は「要求元が作る資料がかなりふわっとしていて何を作ってほしいのかわからない、また要求元自身も実際に何がほしいか明確でない」（ponzu）構造で、これは個別企業の問題ではなく、独立系システムコンサルが指摘するように「ユーザー（業務部門）の人間であっても、システムに実装したい要件を明確に語れ」ない（goza）という根本的不可能性に基づく。「業務内容をシステム構築のために必要なメッシュで分析できるわけがなく、利用体験をイメージさせるしか方法がございません」（goza）。さらに「エッジケースって5%ぐらいしか発生しないんだけど、天災と同じで発生する確率がある以上、準備が必要。でも、誰もエッジケースを語れない」（goza）。なぜなら対応者が「身体で覚えているので、ルールとして整理できないから、引き出せないわけ」（goza）。情シス目線でも「システム刷新のタイミングはだいたい７年から１４年くらい」（keita）であり、「この要件定義に関わることなんて、人生の中でそうそうない」（keita）ため、業務担当者にとって反復学習の機会が一生に1〜2回しかなく、「反省が生かされない」「学習されない」（keita）。外部コンサルや受託SIerは「部外者は、基本的に部外者でしかありません」（keita）。受発注関係の中では「ヒアリング相手の心象を悪くするようなツッコミ」（keita）も難しい。結果として「うわべだけの現状把握」（keita）にとどまり、「結局『現行システムのままでお願いします』というざっくりリクエストとなり、現システムの仕様書や、ひどいときにはソースコードを解析し始めることになる」（goza）。「詳細設計をやるべきフェーズで、1年以上前に終わっているはずの現状調査に時間を取られることだ。当然スケジュールは崩壊する」（goza）。情シス系の論者は「完璧な要件定義など諦めて、むしろ漏れや変更に覚悟を決めて備えたほうが良い」（keita）「金かけてコンサル雇って要件定義するくらいなら、諦めて柔軟に対応するお金を準備するほうが賢明な気がします」（keita）と、要件定義の本質的不可能性そのものを前提化する諦めの境地を提示する。一方で受託SIer側は競争入札で「営業的に通しやすい数字ではなく、『実現可能性のある数字』」（ヤマダ）でない見積を強要され、「鉛筆なめなめ」で楽観的な工数とスケジュールを通す。「詳細は後で詰めればよい」「まずは前に進めよう」（ヤマダ）の前のめりな空気で要件合意プロセスは形骸化し、「『何かがおかしい』と気づいていながら、それを明確に言語化できず」（ヤマダ）対応が後手に回る。「最終的にはなんとかなるだろう」「正常化バイアス」（ヤマダ）の根拠なき希望が漂う。だが「上流工程での判断ミス、要件の不明確さ、リスクの過小評価といった問題は、すぐには姿を現さず、実装や試験という『結果が出る』段階で初めて表面化」（ヤマダ）し、時間差で炎上として表出する。プロジェクトの失敗の50%は要件定義に起因し、スコープ定義を含めると「要件定義はプロジェクト失敗原因の約2/3を占める」（Takashi Suda）が、「エンジニアの多くが『要件定義』にすべきことが理解できていません」（Takashi Suda）。エンジニアは「すぐにプログラムに起こす選択を取りがち」（Takashi Suda）で、「設計と大差ないことしかできていない実情が後を絶ちません」（Takashi Suda）。要件定義の失敗は「デザインやプログラム開発する工数だけを見積りに入れており、要件定義にかかる工数をスケジュールにも見積書にも含んでいない」（tamachang）という入口の見積もり段階から始まる。掘り下げ不足は「あれもやらなきゃいけなくなった」「スケジュールが間に合わない」「この予算じゃこの機能は作れない」（tamachang）→「赤字のプロジェクトになる」「不眠不休のデスマーチ」「スケジュール遅延で顧客の信用を失う」「デザイナーさん、エンジニアさんにしばかれる」（tamachang）の連鎖で結末する。炎上が決定的になった現場では、PMが「クライアントへ報告しながら寝落ちしてしまった」（柴田秀夫）ほどの寝不足、「クライアントとマネジメントからの矢のように鋭い『どうするのか？』の問いの連続」（柴田秀夫）でPMの精神は限界を超え、新卒で大手会計パッケージ導入PJに配属された担当者の現場では「チームは限界寸前。連日のタクシー帰りが続き、ついにPMが過労でダウン。救急車で運ばれていきました」（すぅ）「間もなく、PLまでもが倒れ、再び救急車のサイレン」（すぅ）が響き、結果としてアサイン2ヶ月の新卒が「PLの代役を務める」（すぅ）羽目になる。受託開発では「月残業300時間という極端な働き方」（Sasamori）の経験が現役執行役員から語られ、「不確実性に対する責任が、特定の個人に集中していた」（Sasamori）「現場のエンジニアが『不確実性の吸収係』になることで疲弊」（Sasamori）「不確定な未来の責任を背負わされる職種」（Sasamori）と表現される。2010年代以前のSIerでは「9時に出社して翌日の9時まで寝ないでプログラミングして、さらに寝ないで18時までコードを書く」（George）月400時間級のデスマーチが当たり前で、「社員がそこらじゅうに転がっている」（George）状態だった。デスマーチの定義は「プロジェクトメンバーがいくら残業してもまるで終わりが見えない」（内田吉則）状態で「残業が100時間/月を超える」（内田吉則）労働環境を指し、エドワード・ヨードンが整理した発生条件は「与えられた期間が一般の半分以下」「エンジニアの必要な人数が半分以下」「予算が通常の半分以下」「機能や性能などの要求が倍以上」（内田吉則）の4つ。「人数だけではなく」「追加人員が環境を把握するための時間がない」「エンジニアのスキルが不足している」（内田吉則）まで考慮しないと、火を噴いた現場に未経験者を投入することで「Aさんが教育対応に追われ、さらに業務負荷増加→過労で倒れる→後任も理解が浅く事態悪化→プロジェクト崩壊」（内田吉則）の負のループへと深まる。さらに開発組織と営業組織の対立は構造的に避けられない。営業時代「なんでこれまで慣れてきた画面を変えるんだ！」「せっかく俺たちが（売上を）作っているのに・・・」（井原真吾）と感じていた人物が開発側に配属されると「営業から上がってくる機能要望リストを開くのすら怖くなっていた」（井原真吾）と立場が反転する。根本原因は「それぞれが重視するものが『PL（売上/利益）』と『BS（資産）』で違う」（井原真吾）こと。営業はPL目標で「カスタマイズも許容してどんどん要望通りの機能を追加」したいが、開発は「資産価値低減につながりそうな個別対応」を避けたい。ガントチャートは「希望の幻影」（深沢隆司）であり、「納期に合わせた日付だけが並んだ表。それは計画ではなく、ただの『願望表』」（深沢隆司）にとどまる。「タスク管理の問題」「予実管理の欠如」「手作業による非効率」（おだゆきえ）の3つが進捗が遅れているプロジェクトの共通点で、「計画を立てることが目的になってしまい」（おだゆきえ）計画通り実施し結果を分析することをしないまま進むのが典型。アジャイル／スクラムの導入も解にならず、「ユーザーストーリーは書いているのに、具体的に何を作ればいいかわからない」「デイリースクラムは毎日やっているのに、いつもスプリントゴールを達成できない」（業界一般／竹野たけのこ等）「ゾンビスクラム」「カーゴカルトアジャイル」と呼ばれる形骸化が再現性を持って各組織で発生する。日本のSIerでは要件凍結のタイミングが法的にも契約形態（請負／準委任）と紐づいているため、請負契約では「要件と設計が明確に定義されていなければ仕様変更を理由に追加費用を請求できない」「変更管理プロセスが契約書に明文化されていないと地獄になる」（実務法務ノート）状態で、PMは法務リスクと現場リスクを同時に背負う。情シス出身者の論考では「ITプロジェクトの失敗を引き起こすケースはありませんでした」（goza）「システムニーズを整理しきれていない、どういう整理をすればITプロジェクトを推進できるかわからない状況に陥ったクライアントの準備不足が主因」（goza）と、エンジニア責任ではなく発注者側の準備不足とその責任を吸収させられるPMの構造的疲弊が問題の本質と整理される。

誰が困っているか

業態別の発信者層

業態 発信者の立場 規模感の典型例 PM疲弊の特徴
大手SIer（NTTデータ・富士通・日立・NEC等） 元請PM・PMO・アーキテクト・SE 100人〜数百人体制、ウォーターフォール、マルチベンダ 要件定義5人→基本設計10人→詳細設計20人→開発100人の階段型増員、ドキュメントレビュー連鎖、結合テストで一気に火を噴く
中堅・独立系SIer プロジェクトマネージャー・PL 5〜30人規模、複数案件並走、業界25年級ベテラン多い 営業との見積バトル、上流の鉛筆なめなめ、正常化バイアス、現場違和感の不報告
小規模受託開発会社 経営者兼PM・社長 5〜30名、Webアプリ・業務システム、社長が現場PM兼任 顧客ガチャ、認識齟齬、無限修正、月残業300時間の経営者体験
Web制作会社 ディレクター・PM・経営者 数名〜数十名、コーポレートサイト・LP・受託CMS 要件定義工数を見積りに入れ忘れ、デザイン・開発工程に皺寄せ
ITコンサル・SI企業 コンサルタント・PMO 大手SIer・外資系・国内系総合コンサル DX推進案件、レガシー基幹刷新、ステークホルダー多数の調整、影の実力者
自社プロダクトSaaS PdM／PjM／VPoE スタートアップ〜中堅SaaS 営業vs開発、機能要望リスト、技術的負債、エンタープライズ個別カスタマイズ
情シス・社内SE（顧客側） 情シス担当・部長 数名〜数十名、基幹系・ERP・人事給与 7〜14年に1回の刷新、経験ゼロリセット、ベンダーとの認識合わせ、業務担当者引き出し
フリーランスPM／PdM／エンジニア 個人事業主・業務委託 単独参画、複数案件兼務 営業力ゼロ、エージェント頼み、PMの孤独、案件途中での引き継ぎ
新卒〜若手のSE／PL 入社1〜3年目 大手SIer・コンサル・SES 救急搬送されたPM／PLの代役、知識ゼロでの炎上対応、知識ガチャ

共通する立場

  • 元請SIerのPM・アーキテクト（業界歴10年以上、見積もり責任、QCD責任、契約責任）
  • 受託開発会社の経営者兼PM（営業・要件定義・PM・コードレビュー・経理を一人兼務）
  • 客先常駐PM／PMO（複数顧客の同時並走、プロパー社員より一段下の扱い）
  • PdM／PjM兼務者（スタートアップ・中堅SaaSで両役割を兼務、時間配分困難）
  • 情シス／社内SE（発注者側、業務部門と開発ベンダーの板挟み）
  • 新卒〜若手で炎上案件に投入された担当者（PL／PMが救急搬送された後の代役）
  • フリーランスPM（孤独な意思決定、家庭・健康と並走、アサイン途中の引継ぎ）
  • PMP保有者（標準論を学んでも現場の不可能性に直面、「修羅の道」体験）
  • 業界25年以上のベテランアーキテクト（同じパターンの炎上を25年見続け、構造的諦めに至る）
  • 元請から二次請けへ抜けたコンサル（独立後、上流の判断ミスが下流の地獄を作る構造を客観視）

受託開発・SIerの業務フロー（時系列：見積→要件定義→設計→実装→結合テスト→受入→運用）

ウォーターフォール型の典型的な進行と、各フェーズで蓄積されるPM疲弊：

  • 提案・見積フェーズ（営業主導）：競合コンペ、RFP（提案依頼書）への回答、概算見積を提示。「営業的にこれ以上の見積もりは通らない」（ヤマダ）の圧力下で、「鉛筆なめなめ」（ヤマダ）で楽観的な工数を通す。「見積りが甘い」の根本理由は「想像が足りないこと」（柴田秀夫）。「見積りした人のこれまでの見積り回数から結果が正しかった割合を導き出せたら、その割合が、今回の見積りの妥当性と言っても良いほどです。技術力があるから見積りが正しいということではありません。重要なのはホームラン数ではなく、打率です」（柴田秀夫）。営業はPL目標、開発はBSへの影響を懸念する分断（井原真吾）。「営業リードタイムが長く、稼働率100%でないと売上が立たない」「初回提案からクロージングまで長いもので1年かかる案件」（既存pains.mdカテゴリ3）

  • 要件定義フェーズ（ビジネス要件→業務要件→機能要件→非機能要件→運用要件）：5段階フレームワーク（あにき）。「要求元自身も実際に何がほしいか明確でない」（ponzu）状態で、「要件定義がたいして進まず1日が終わった日なんかには、実質の成果はエクセルでちょっとお絵描きしたくらい」（ponzu）。SIer6年→情シス5年→独立コンサルとなったgozaは「ユーザーであっても実装したい要件を明確に語れない」「エッジケースって5%ぐらいしか発生しないんだけど、誰もエッジケースを語れない」「身体で覚えているので、ルールとして整理できないから、引き出せないわけ」（goza）と本質的困難を整理。情シス側のkeitaは「システム刷新のタイミングはだいたい７年から１４年くらい」「人生の中でそうそうない」「反省が生かされない」「学習されない」「部外者は、基本的に部外者でしかありません」「完璧な要件定義など諦めて、むしろ漏れや変更に覚悟を決めて備えたほうが良い」（keita）と諦めの境地に至る。「徹夜でヒアリングメモを清書したり、膨大な要件定義書を一人で抱え込んだり…正直、心身ともにクタクタで、『SE辞めたいな…』と本気で悩んだ時期もありました」（業務効率化サポータ@たく06）。「ヒアリング中に頭が真っ白」「想定外の質問に詰まり、焦ってしまう」「相手の言葉の意図が読めず、うまく返せない」「雰囲気にのまれて言いたいことが言えない」（IT職人の道具箱）といった現場の困難。柴田秀夫は「システム化要件定義とは、基本設計以降の見積り諸元を確定させること」（柴田秀夫）と本質を整理するが、見積り諸元が確定するまでに発注者側が「自分が何を欲しいか」を言語化できない構造そのものが問題

  • 基本設計・詳細設計フェーズ：要件定義から設計へ。SIerでは「要件定義5人→基本設計10人→詳細設計20人→開発100人」（花岡宏明）の階段型増員でドキュメント生産が中心。「ドキュメントのフォーマットや記述内容の詳細さに加えて、ドキュメントのバージョン管理もソースコードレベルで行われている」（花岡宏明）が、「実際に動くものを見ていないのに」（天野久弥）要件定義と設計のサインオフを強行する慣行が「要件定義・設計に莫大なコストをかけることを正当化」（天野久弥）してきた。1970年のロイス論文（ウォーターフォール創案者）すら本来は「テスト段階で初めて実際の動作を確認する」ことの問題点を指摘し、「イテレーティブなアプローチ」（天野久弥）を提唱していたという皮肉

  • 実装・単体テストフェーズ：開発100人体制が稼働。「ふわっとした要件をつめてる時って自分自身もこれから何を作るのか明確ではない」（ponzu）状態のまま設計が進んでいるため、開発で初めて要件不整合が露呈する。「現場では違和感が少しずつ積み上がっていき、どこかの時点で一気に表面化します」（itchie）。「途中の前提が少しずつ現実とズレていったプロジェクトだった、ということがほとんどでした」（itchie）

  • 結合テスト・システムテストフェーズ（炎上の発火点）：「ウォーターフォールで前半はドキュメント作業中心で、問題が表面化しないままスケジュール上は『順調』に見える」が、「後半のプログラミング段階で、根本的な誤解や設計ミスが結合テストで顔を出し、収拾不能な状況」（業界共通理解）。「上流工程での判断ミス、要件の不明確さ、リスクの過小評価といった問題は、すぐには姿を現さず、実装や試験という『結果が出る』段階で初めて表面化」（ヤマダ）。「『出遅れ』→『場当たり的に作業指示』→『検討事項頻発』→『実績がでない』→『レビューで指摘続出』→『残業で対応』→『リカバリ策を考える』→『WBS見直し』」（柴田秀夫）の典型的な炎上フロー

  • 受入テスト・本番リリースフェーズ：「『最初に言っていたじゃないか』『○○みたいなアプリを作れって言ったよな？』」（受託社長）の認識齟齬がここで噴出。「一定規模のサービスとなるとバグは数百個程度は出るのが常」（受託社長）「現場が疲弊するケースも多い」（受託社長）。請負契約では完成責任が受注側にあり、追加見積も通らず、PMが個人で吸収する

  • 炎上収束（火消し）フェーズ：①徹底的な現状把握、②迅速かつ正直な報告と期待値調整、③優先順位付け（すぅ）の3ステップが定石だが、現実には「PMが過労でダウン。救急車で運ばれていきました」「PLまでもが倒れ、再び救急車のサイレン」（すぅ）。「クライアントへ報告しながら寝落ちしてしまった」「クライアントとマネジメントからの矢のように鋭い『どうするのか？』の問いの連続」（柴田秀夫）。月100時間超え残業、月400時間労働、9時出社→翌日9時→さらに18時（既存pains.md）の深夜労働

  • 運用・保守フェーズ（次の刷新まで7〜14年）：「PHP5など10年前のEOL環境を保守、新技術に触れず塩漬け」（既存pains.mdカテゴリ9）。次の刷新は7〜14年後で、また同じ業務担当者は経験ゼロからリセット（keita）

PM／PdMの孤独と決定の重圧

「プロジェクトの最終的な決断を、PMが一人で下さなければならない状況で感じる孤独」「多くの選択肢の中から、最善の道を選び、その結果の責任を一人で背負う重圧」（Tom.Msn）。「PMは、プロジェクトチームの『一員』でありながら、同時にプロジェクトの『管理者』という二つの異なる立場を担います。この中間管理職的な役割から生まれる、どちらの陣営にも属さない感覚」（Tom.Msn）。「PMが抱えるストレスや不安、プロジェクトの失敗への恐怖などを、チームメンバーや上司に打ち明けられないことから生じる内面的な孤独感」（Tom.Msn）

note引用（IT受託・PM／PMO／PdMの生声）

引用1：要件定義しんどい――エクセルでお絵描き1日、自己嫌悪と葛藤

「要件定義がたいして進まず1日が終わった日なんかには、実質の成果はエクセルでちょっとお絵描きしたくらいなので『私何やってんだろ』」「ふわっとした要件をつめてる時って自分自身もこれから何を作るのか明確ではない」「要求元が作る資料がかなりふわっとしていて何を作ってほしいのかわからない、また要求元自身も実際に何がほしいか明確でない」「日々葛藤と自己嫌悪が止まないのが要件定義フェーズです」「正直エンジニアなんだから開発だけさせてくれよ、エクセル開きたくないよ」

引用2：要件定義は誰も出来ない――ユーザー自身が何が欲しいか言えない、エッジケースは身体知

「ユーザー（業務部門）の人間であっても、システムに実装したい要件を明確に語れ」ない。「業務内容をシステム構築のために必要なメッシュで分析できるわけがなく、利用体験をイメージさせるしか方法がございません」「エッジケースって5%ぐらいしか発生しないんだけど、天災と同じで発生する確率がある以上、準備が必要。でも、誰もエッジケースを語れない」「身体で覚えているので、ルールとして整理できないから、引き出せないわけ」「結局『現行システムのままでお願いします』というざっくりリクエストとなり、現システムの仕様書や、ひどいときにはソースコードを解析し始めることになる」「詳細設計をやるべきフェーズで、1年以上前に終わっているはずの現状調査に時間を取られることだ。当然スケジュールは崩壊する」「本来は発注者側が果たすべき責任なので、費用負担をどうするかで揉める。双方にとってしんどい」

引用3：システム刷新は7〜14年に1回――発注者側が経験ゼロリセット、完璧な要件定義は諦めるべき

「システム刷新のタイミングはだいたい７年から１４年くらいと言われています」「業務担当者にとって、この要件定義に関わることなんて、人生の中でそうそうないのです」「反復がないため『反省が生かされない』『学習されない』ため、改善されない構造です」「部外者は、基本的に部外者でしかありません」「時にはヒアリング相手の心象を悪くするようなツッコミも必要」だが「受発注関係の中ではそんなヒアリングをするのはなかなか難しいでしょう」「完璧な要件定義など諦めて、むしろ漏れや変更に覚悟を決めて備えたほうが良いと思います」「金かけてコンサル雇って要件定義するくらいなら、諦めて柔軟に対応するお金を準備するほうが賢明な気がします」

引用4：PMが寝落ち、報告中に意識を飛ばす――矢のように鋭い「どうするのか？」の連続

「寝不足でクライアントへ報告しながら寝落ちしてしまった」「クライアントとマネジメントからの矢のように鋭い『どうするのか？』の問いの連続」「QCD（品質・コスト・納期）を満たすこと」が成功条件で、この3つの条件のいずれかが目標から大きく乖離している状況が炎上と定義

引用5：上流の見積甘さ・正常化バイアス・なんとかなるだろう――時間差で炎上が表出

「営業的に通しやすい数字ではなく、『実現可能性のある数字』でプロジェクト」の計画が必要。競争圧力下での「鉛筆なめなめ」により、楽観的な工数やスケジュールで見積もりが通される。「詳細は後で詰めればよい」「まずは前に進めよう」といった前のめりな空気に支配されている。「『何かがおかしい』と気づいていながら、それを明確に言語化できず」対応が後手に回る。「なんとかなるだろう」の根拠のない希望的観測。「上流工程での判断ミス、要件の不明確さ、リスクの過小評価といった問題は、すぐには姿を現さず、実装や試験という『結果が出る』段階で初めて表面化」。「炎上は『なるべくしてなった』。そう思えるほど、炎上にはパターンがあると思います」

引用6：営業（PL）vs 開発（BS）対立――機能要望リストを開くのが怖い

営業時代「なんでこれまで慣れてきた画面を変えるんだ！」「せっかく俺たちが（売上を）作っているのに・・・」と感じていた。開発側に配属後「営業から上がってくる機能要望リストを開くのすら怖くなっていた」と述懐。開発側は「いかに技術的負債を貯めないか」「いかに今後のビジネスに沿った機能開発ができるか」という異なる文脈で思考。根本原因は「それぞれが重視するものが『PL（売上/利益）』と『BS（資産）』で違うから」。営業はPL目標で「カスタマイズも許容してどんどん要望通りの機能を追加」したいが、開発は「資産価値低減につながりそうな個別対応」を避けたい

引用7：受託開発はつらい――月残業300時間、不確実性の吸収係、特定個人への集中

キャリア最初の4年間を受託開発に費やし「月残業300時間という極端な働き方」を経験。「仕様変更による差し戻し、スケジュールと現場のギャップ、顧客からの無茶な要求」が存在。「不確実性に対する責任が、特定の個人に集中していた」ことが本質的問題。「現場のエンジニアが『不確実性の吸収係』になることで疲弊」。当時のエンジニアは「不確定な未来の責任を背負わされる職種」だった。「ゴールが共有されていない」「期待値の調整役が不在」「営業と開発が分断」されていた

  • 出典: 受託開発はつらい? by Sasamori
  • 著者の立場: セルプロモート株式会社 執行役員、エンジニア歴20年
  • 投稿日: 2025-12-11
  • ペインの強度: ★★★★★

引用8：受託開発、Googleサジェストに「つらい」――顧客ガチャ・無限修正・バグ数百個

「受託開発と調べると、Googleのサジェストで『つらい』と出てきますよね。結論から言うと、本当です」。要件への認識齟齬：「『最初に言っていたじゃないか』『○○みたいなアプリを作れって言ったよな？』」。集客「単純に難しい」、商談獲得単価「10万円程度になってしまいます」。「一定規模のサービスとなるとバグは数百個程度は出るのが常」「現場が疲弊するケースも多い」

引用9：新卒2ヶ月でPL代役――PMが過労ダウン、PLも倒れ救急車のサイレン

新卒アクセンチュア入社後、会計パッケージ導入プロジェクトで「ボタンを押しても次の画面が出るのに数分かかる始末」というシステム機能不全。「チームは限界寸前。連日のタクシー帰りが続き、ついにPMが過労でダウン。救急車で運ばれていきました」「間もなく、PLまでもが倒れ、再び救急車のサイレン」が響く。プロジェクトアサインわずか2ヶ月で「PLの代役を務めることになっていました」とストップウォッチで全ボタンの反応時間を計測し、SQLコードを解読する泥臭い現状把握を実行

引用10：プロジェクト失敗の50%は要件定義――2/3はスコープ含めて要件起因

「プロジェクトの失敗の原因の 50% が要件定義にある」。スコープ定義を含めると、「要件定義はプロジェクト失敗原因の約 2/3 を占める」。「エンジニアの多くが『要件定義』にすべきことが理解できていません」。エンジニアは「すぐにプログラムに起こす選択を取りがち」で「設計と大差ないことしかできていない実情が後を絶ちません」。階層化：要件定義は「やりたいことのためにシステムは何を実現するのか」を決める／基本設計は「具体的に何を作るのか」を決める／詳細設計は「どう作るのか」を決める

引用11：要件定義の失敗例――工数を見積もりに入れ忘れ、デザイナー・エンジニアにしばかれる

「デザインやプログラム開発する工数だけを見積りに入れており、要件定義にかかる工数をスケジュールにも見積書にも含んでいない」。掘り下げ不足により「あれもやらなきゃいけなくなった」「スケジュールが間に合わない」「この予算じゃこの機能は作れない」が生じ、その後「赤字のプロジェクトになる」「不眠不休のデスマーチ」「スケジュール遅延で顧客の信用を失う」「デザイナーさん、エンジニアさんにしばかれる」「心配性なくらい確認を入れるのがちょうど良いです」

  • 出典: 要件定義の失敗例 by tamachang
  • 著者の立場: 株式会社Futurize取締役、IT企業マネジメント職
  • 投稿日: 2019-08-27
  • ペインの強度: ★★★★

引用12：見積りの根本理由は「想像が足りない」――炎上の典型フロー

「『見積りが甘い』の根本理由は、想像が足りないことに尽きます」。炎上時の典型的なプロジェクト進行フロー：「『出遅れ』→『場当たり的に作業指示』→『検討事項頻発』→『実績がでない』→『レビューで指摘続出』→『残業で対応』→『リカバリ策を考える』→『WBS見直し』」。「見積りした人のこれまでの見積り回数から結果が正しかった割合を導き出せたら、その割合が、今回の見積りの妥当性と言っても良いほどです。技術力があるから見積りが正しいということではありません。重要なのはホームラン数ではなく、打率です」

引用13：システム化要件定義とは「基本設計以降の見積り諸元を確定させること」

「システム化要件定義とは、基本設計以降の見積り諸元を確定させることです」。業務要件定義の成果物は「業務一覧／新業務フロー／業務要件一覧」。システム化要件定義の本質：「見積り手法が決まっていなければ、システム化要件定義の成果物を決めることは出来ません」。「この要件が誰にとってどれくらいの効果があるかも定義しておくことが重要」

引用14：SE辞めたい――徹夜でヒアリング清書、要件定義書を一人で抱え込む

「またヒアリング…準備と議事録作成で一日が終わっちゃうよ…」「要件定義書、書けども書けども終わらない地獄…」「顧客との認識合わせが大変で、手戻りばかり…もう嫌だ…」「徹夜でヒアリングメモを清書したり、膨大な要件定義書を一人で抱え込んだり…。正直、心身ともにクタクタで、『SE辞めたいな…』と本気で悩んだ時期もありました」

引用15：ヒアリング中に頭が真っ白――想定外の質問に詰まり、相手の意図が読めない

「想定外の質問に詰まり、焦ってしまう」「相手の言葉の意図が読めず、うまく返せない」「雰囲気にのまれて言いたいことが言えない」。焦る主な原因：準備不足／時間管理の甘さ／想定外の反応への対応困難／相手のペースへの巻き込まれ／記録の欠如

引用16：今日からPM――そもそも作れない、KPIなし、ビジネス要件未確定

炎上プロジェクトの主な原因「①そもそも作れない(笑) ②KPIが定まっていない ③ビジネス要件が固まっていない ④ヒト....に恵まれなさすぎる」。「特に厄介なのが②ですかね。リカバリが効きづらいという意味では」。著者が引き継いだ案件の前任PMは「『認識率ガー』『意味が伝わらないー』と騒ぐ客の圧に耐えられなくなり、PMが離脱(!!???)」した

引用17：炎上案件の最初の一言「この案件、ちょっと事情がありまして…」

炎上案件で冒頭で発される一言：「この案件、ちょっと事情がありまして…」。パターン①「要件が固まりきっていない段階で実装が進んでいるケース」。パターン②「計画の前提が更新されないケース」「開発が進むにつれて作業量の認識は変わっているのに、計画だけが更新されない状態」。「現場では違和感が少しずつ積み上がっていき、どこかの時点で一気に表面化します」。「途中の前提が少しずつ現実とズレていったプロジェクトだった、ということがほとんどでした」

引用18：日米の炎上カルチャーの違い――納期は伸ばせるパラメータか否か

日本：「受託開発、内製双方ともに物凄く『大問題』になっていた。上位のマネジメントも連日のように進捗の会議を行い、人が追加投入され、エンジニアは時には泊りで一日も早く後れを取り戻すために皆遅くまで、そして土日も働き」。米国：「当初予定していた日程が一か月以上伸びても、みんな慌てる様子もなく」「早くリリースできるように頑張ろうという急かすムードすらまるでなかった」。本質的な違い：「納期はいじり易いパラメータ」「品質でないと納期はどこまでも伸ばす雰囲気」

引用19：デスマーチ4条件（エドワード・ヨードン）――納期半減・人員半減・予算半減・要求倍増

デスマーチの定義：「プロジェクトメンバーがいくら残業してもまるで終わりが見えない」状態で「残業が100時間/月を超える」労働環境。エドワード・ヨードン著『デスマーチ』からの発生条件：「与えられた期間が一般の半分以下」「エンジニアの必要な人数が半分以下」「予算が通常の半分以下」「機能や性能などの要求が倍以上である」。営業が技術側に相談せず受注→現場の反発→根性論で強行→エンジニア体調悪化・退職→繰り返し→プロジェクト完成できず崩壊

引用20：人員不足デスマ――経験ゼロ増員でAさんが教育に追われ過労で倒れる

「人数だけではなく以下の点にも考慮が必要で、ここが考慮されていないとデスマポイント：追加人員が環境を把握するための時間がない／エンジニアのスキルが不足している」。具体的な悪循環：「既存エンジニアAさんが過負荷状態で、未経験者3名が投入される→Aさんが教育対応に追われ、さらに業務負荷増加→過労で倒れる→後任も理解が浅く事態悪化→プロジェクト崩壊」。「どんな優秀な人でも、配属後2～3か月で戦力化が一般的。火を噴く案件ではさらに時間要する」

引用21：PMの孤独――最終決定の重圧、どちらの陣営にも属さない感覚

「プロジェクトの最終的な決断を、PMが一人で下さなければならない状況で感じる孤独です。多くの選択肢の中から、最善の道を選び、その結果の責任を一人で背負う重圧を伴います」「PMは、プロジェクトチームの『一員』でありながら、同時にプロジェクトの『管理者』という二つの異なる立場を担います。この中間管理職的な役割から生まれる、どちらの陣営にも属さない感覚です」「PMが抱えるストレスや不安、プロジェクトの失敗への恐怖などを、チームメンバーや上司に打ち明けられないことから生じる内面的な孤独感」

引用22：ガントチャートは「希望の幻影」――WBSは成果物中心、ガントは願望表

「WBS（Work Breakdown Structure）は『成果物中心の階層構造』である」「WBSの Work は作業ではなく、作品、成果の意味で使われている」「多くの現場では、ガントチャートが『WBS』と呼ばれ、『計画』だと信じられている」「納期に合わせた日付だけが並んだ表。それは計画ではなく、ただの『願望表』だ」「高品質な計画が先。プロジェクトマネジメントの意味は、そこに生まれる」

引用23：ガントチャートが進捗管理を救うは幻想――3つのイケてないポイント

「進捗に遅れが出ているプロジェクトが、進捗管理に使っているガントチャートの共通点として３点」：①「大きな項目から行動レベルの細かいタスクにまで落とし込まない」と実行できず、「作業の関連付けができず、他の作業の完了待ちでスケジュールが遅れる」②「スケジュールは実行するためのもの」で「実績もしくは現状が把握できなければ意味がありません」③「塗りつぶす作業が手作業の場合、日にちがずれてしまったり、塗りつぶすを忘れてしまったり」して正確性が失われる。「計画を立てることが目的になってしまい」、計画通り実施し結果を分析することをしないまま進む

引用24：ITプロジェクト失敗はエンジニアのせいではない――発注者の準備不足が主因

「失敗する要因はだいたい決まっています。プランニング不足です」「エンジニアがITプロジェクトの失敗を引き起こすケースはありませんでした」「システムニーズを整理しきれていない、どういう整理をすればITプロジェクトを推進できるかわからない状況に陥ったクライアントの準備不足が主因」「IT企画力はエンジニアが適切な情報を提供すれば上がっていくものなのだと感じました」「エンジニアを活用するには、まずはプランニングです。どんな価値が欲しくて、それはどういう手段で実現できるのかを、定義しないと始まらない」

引用25：受託PjMから自社PdMへ転換――「線引き」から「自分ごと化」へ

受託開発では「自分たちは期日内に求められたものを納品できればいいんで」と線を引くことが多かったが、事業会社では「我が子のように思ってnoteに接し」られるようになった。従来の受託では「QCD内でプロダクトを開発し、納品することが最重要事項」だったが、現在は「クリエイターにとって価値があること」を優先する。受託では「ベースとなる考え方や目的意識が大きく異なる人々」の調整が必要だったが、noteではMVVが浸透していることで「より課題に向き合うことを重視」できている

引用26：ステークホルダー調整は「板挟み」でなく「ベストへの巻き込み」――誤解で精神的に消耗

「調整事がうまくできなくて苦手」とか「調整事はめんどくさいからいやです」と若手PMから聞く声。誤解：「誰かと誰かの間に入って板挟みの状態で折衷案を考えること」。その危険性：「コトを収めるために間を取り持っているだけだと、精神的に消耗してしまい、調整がいやだという印象につながってしまう」。あるべき姿：「今考えられる最高のゴールにステークホルダーを引っ張っていくための一連の行為」「ステークホルダーの意見を聞き、課題に対する自分なりの仮説を持って、自分が考えるベストな方向性にステークホルダーを巻き込んでいくこと」

引用27：プロジェクト失敗の本当の理由は「影の実力者」――関係ないと判断した40%が後に重要に

大手製造業のDXプロジェクトで「『影の実力者』の存在に気づくのが遅すぎた」「影響力は低いと判断していた人物が、実は全社的な意思決定に強い影響力を持っていた」。「プロジェクト初期段階で『関係ない』と判断したステークホルダーが、後に重要な役割を果たすケースが全体の約40%で発生」。「本当に関係ないか？」を3回自問することを推奨

引用28：SIerウォーターフォール――要件定義5人、基本設計10人、詳細設計20人、開発100人

「ウォーターフォール型はシステムを受託開発する多くのSI企業に採用されています」「お客様の要望を叶えたシステムを開発して納品する必要があるわけなので、『お客様の要望』が途中で変わってしまうと大量の手戻りが発生」「ドキュメントのフォーマットや記述内容の詳細さに加えて、ドキュメントのバージョン管理もソースコードレベルで行われている」「上流工程のPMは給料が高めで、下流工程を担当するエンジニアは給料が低めという風習がある」「『詳細な設計書がないとコードがかけません』という思考は捨てたほうが良い」

引用29：ウォーターフォールvsアジャイルの宗教論争――1970年ロイス論文ですらイテレーティブ提唱

「アジャイルもウォーターフォールもどちらもアプローチであり、神や真理ではないので、絶対ではありません」。ウォーターフォール創案者とされるロイス氏（1970年論文）は、実は「テスト段階で初めて実際の動作を確認する」ことの問題点を指摘し、「イテレーティブなアプローチ」を既に主張していた。「実際に動くものを見ていないのに」要件定義と設計でサインオフを取得する慣行が「要件定義・設計に莫大なコストをかけることを正当化」してきた

引用30：プロジェクトマネジメントの目的は「不確実性の早期排除」――形式運用で機能不全

プロジェクトマネジメントの具体的な目的を「不確実性の早期排除」と定義。「不確実性の早期排除との目的が意識されていないと、プロジェクトマネジメントが機能せず、不確実性（＝リスク）が残り続け」る。機能しないプロジェクトの現場：「ＷＢＳが作成されていなかったり、進捗・課題管理されていなかったり、そもそも起点となる『不確実性』が摘出されてなかったり」。根本原因：PMBOKが「不確実性の早期排除」に結びつけて説明されていないため、プロセスが「手段として形式的な使われ方に留まり、目的の観点では実践できていない」

このペインの構造的原因

なぜこのペインが消えないか、IT受託・SES・自社開発のIT業界固有の制度・契約・人月モデル・組織構造から分析：

  • 発注者側のシステム刷新が7〜14年に1回というメタ周期：「システム刷新のタイミングはだいたい７年から１４年くらい」（keita）。業務担当者は一生に1〜2回しか要件定義に関わらず、組織として学習できない。前回のPM／PMOは退職、業務知識は別のベテラン社員の暗黙知、文書化された要件は陳腐化。ベンダーは新規一括見積で受託、業務担当者は経験ゼロから始める

  • ユーザー自身が「何を欲しいか言語化できない」根本的不可能性：「ユーザー（業務部門）の人間であっても、システムに実装したい要件を明確に語れ」ない（goza）。利用体験をイメージさせる以外に方法がない。「業務内容をシステム構築のために必要なメッシュで分析できるわけがな」い（goza）

  • エッジケースの暗黙知化：「エッジケースって5%ぐらいしか発生しないんだけど、誰もエッジケースを語れない」（goza）。「身体で覚えているので、ルールとして整理できないから、引き出せないわけ」（goza）。組織の身体知として組み込まれた業務ルールは、文書化されていない以上要件として表に出ない

  • 競争入札と「鉛筆なめなめ」見積文化：「営業的にこれ以上の見積もりは通らない」（ヤマダ）の圧力下で、見積りを楽観化。「『見積りが甘い』の根本理由は、想像が足りないこと」（柴田秀夫）。見積担当者の打率を計測する文化がない

  • 要件定義工数を見積に入れ忘れる初歩的誤り：「デザインやプログラム開発する工数だけを見積りに入れており、要件定義にかかる工数をスケジュールにも見積書にも含んでいない」（tamachang）。Web制作・小規模受託で頻発

  • 正常化バイアスとなんとかなるだろうの希望的観測：「『何かがおかしい』と気づいていながら、それを明確に言語化できず」（ヤマダ）「最終的にはなんとかなるだろう」（ヤマダ）。現場の違和感が報告ライン上で減衰し、上層部に届く頃には炎上の只中

  • 時間差で表出するウォーターフォールの構造的炎上：上流のドキュメント作業中心フェーズでは表面上「順調」に見えるが、結合テスト・受入テストで「上流工程での判断ミス、要件の不明確さ、リスクの過小評価といった問題は…『結果が出る』段階で初めて表面化」（ヤマダ）。1970年のロイス論文ですら「テスト段階で初めて実際の動作を確認する」（天野久弥）の問題点を指摘済み

  • 「実際に動くものを見ていないのに」サインオフを取る慣行：要件定義・設計に莫大なコストをかけることを正当化（天野久弥）。プロトタイプ・モック・MVPアプローチが受託契約構造とフィットしない

  • 請負契約と準委任契約の構造的差異：請負は完成責任が受注側、要件と設計は契約前に明確化が必須。仕様変更は追加見積を要するが、変更管理プロセスが契約書に明文化されていないと「指揮命令系統がない準委任で勝手に追加要望を受ける」「変更責任が曖昧」（実務法務系のnote記事）。準委任は柔軟だが完成責任なしで、PMが品質責任のみ吸収する

  • 営業（PL）vs 開発（BS）の構造的対立：営業は売上目標達成のためカスタマイズ要望を受けたい、開発は技術的負債を蓄積させない資産価値維持を優先。「機能要望リストを見るのが怖い」（井原真吾）心理。BizDev機能の分離（井原真吾）が解の一つだが、組織変更が容易ではない

  • ガントチャート崩壊：WBSは本来「成果物中心の階層構造」（深沢隆司）だが、現場では「ガントチャートが『WBS』と呼ばれ、『計画』だと信じられている」（深沢隆司）。「納期に合わせた日付だけが並んだ表。それは計画ではなく、ただの『願望表』」（深沢隆司）。予実管理欠如・手作業更新・タスク粒度不適切（おだゆきえ）の3つで進捗管理が機能不全

  • アジャイル／スクラムの形骸化（ゾンビスクラム・カーゴカルトアジャイル）：「ユーザーストーリーは書いているのに、具体的に何を作ればいいかわからない」「デイリースクラムは毎日やっているのに、いつもスプリントゴールを達成できない」（業界一般）。受託でアジャイルを導入しても契約形態（請負・準委任）と整合しないため、要件凍結ができず無限変更を受ける

  • PMP／PMBOK標準の形式運用：「PMBOKが『不確実性の早期排除』に結びつけて説明されていないため、プロセスが『手段として形式的な使われ方に留まり、目的の観点では実践できていない』」（APDX）。PMPは「修羅の道」（PMP合格体験記複数）と表現される高難度資格で、合格しても現場の不可能性は解消されない

  • ステークホルダー調整の重圧と影の実力者：「『関係ない』と判断したステークホルダーが、後に重要な役割を果たすケースが全体の約40%で発生」（下町ぷろまね）。新人PMが「板挟みの折衷案探し」と誤解すると「精神的に消耗してしまい、調整がいやだという印象につながってしまう」（さとじゅん）

  • PMの孤独な意思決定と中間管理職的立場：「プロジェクトの最終的な決断を、PMが一人で下さなければならない」「どちらの陣営にも属さない感覚」「ストレスや不安、失敗への恐怖を打ち明けられない」（Tom.Msn）。フリーランスPMほど孤独感は強い

  • 不確実性の吸収係としての特定個人集中：「不確実性に対する責任が、特定の個人に集中していた」（Sasamori）。「現場のエンジニアが『不確実性の吸収係』になることで疲弊」（Sasamori）。受託では「不確定な未来の責任を背負わされる職種」（Sasamori）

  • デスマーチ4条件と人員不足デスマ：エドワード・ヨードン整理の発生条件「期間半減・人員半減・予算半減・要求倍増」（内田吉則）。経験ゼロ増員は「Aさんが教育対応に追われ、過労で倒れる」（内田吉則）の負ループ

  • 月100時間超え・月400時間労働の慢性化：労基法36協定の特別条項上限月100時間（過労死ライン）を超える受託・SES現場が依然存在。「9時に出社して翌日の9時まで寝ないでプログラミングして、さらに寝ないで18時までコードを書く」（George）の月400時間級は2010年代以前ほどではないが、納期直前に局所発生

  • 救急搬送・寝落ち・精神疾患の発生：「PMが過労でダウン。救急車で運ばれていきました」「PLまでもが倒れ、再び救急車のサイレン」（すぅ）「クライアントへ報告しながら寝落ちしてしまった」（柴田秀夫）が業界の実話として共有される

  • 米国型の「納期はいじり易いパラメータ」文化が日本SIerに根付かない：「品質でないと納期はどこまでも伸ばす雰囲気」（牛尾剛）の米国に対し、日本は「人が追加投入され、エンジニアは時には泊りで…皆遅くまで、そして土日も働き」（牛尾剛）の労働力で納期固定を維持

  • 生成AI時代の人月モデル崩壊と要件定義の重要性増大：「人月単価モデルは、生成AIの普及によって完全に過去のものになりつつある」（既存pains.md・風鳥冴達）が、要件定義は「やりたいことのためにシステムは何を実現するのか」（Takashi Suda）を決める作業でAIに代替されにくい。エンジニアがコードを書く比率は減るが、要件定義の苦痛は残るか増大する

  • 発注者責任とエンジニア責任の混同：「ITプロジェクトの失敗を引き起こすケースはありませんでした」（goza）「クライアントの準備不足が主因」（goza）。発注者準備不足の負担を受託側PMが個人で吸収する構造

業界が試している既存の解決策と限界

  • PMBOK標準（PMI／米国基準）／PRINCE2（英国基準）／PMP資格

    • PMP合格は「30日の学習で落ちた」（複数体験記）「修羅の道」と表現される高難度
    • 「PMBOKが『不確実性の早期排除』に結びつけて説明されていないため、プロセスが『手段として形式的な使われ方に留まり、目的の観点では実践できていない』」（APDX）
    • 標準論を学んでも現場の不可能性（ユーザーが言語化できない、エッジケース身体知）は解消されない
    • 受験料・更新料は8万円程度、3年ごとPDU更新が個人負担

  • アジャイル／スクラム／カンバン／LeSS／SAFe

    • 「ゾンビスクラム」「カーゴカルトアジャイル」（業界一般）の形骸化が再現性高く発生
    • 受託契約（請負）との整合困難、要件凍結ができないとPMが無限変更を吸収
    • デイリースクラムは「ほぼ日で状態確認するまでもないかな」「毎日やるなんて、とてもできない（兼務もあるし）」（市谷ら）で省略されがち
    • スクラムマスター・アジャイルコーチの育成コスト、認定資格（CSM・PSM）の更新コスト

  • PMO（プロジェクトマネジメントオフィス）

    • 「役割の考察」「振り回されないために」（柏木誠ら）と存在意義の議論が継続
    • 「上司からはむちゃぶりされ、現場からは突き上げられる」（業界記事）の板挟み構造で離職率高い
    • 「PMOってきつい」「やめとけ」（エンジニアスタイル等）の声、コスト削減対象になりやすい

  • 要件定義書テンプレート・5段階フレームワーク

    • ビジネス要件→業務要件→機能要件→非機能要件→運用要件（あにき）の体系化
    • 「業務一覧／新業務フロー／業務要件一覧／システム化要件定義」（柴田秀夫）の成果物定義
    • テンプレートを埋めても「ユーザーが何を欲しいか言語化できない」根本問題は解消されない

  • モック／プロトタイプ／MVP（Minimum Viable Product）

    • 「ワイヤーフレーム→モックアップ→プロトタイプ」（Saori等）の段階的検証
    • 動くモックを早期に見せることで「実際に動くものを見ていない」（天野久弥）問題を緩和
    • 受託契約（請負）の見積根拠が要件定義書中心の慣行と相性が悪い、プロトタイプは「成果物」として認められにくい

  • デザインスプリント／Lean UX／Fit&Gap分析（ERP導入）

    • イテレーティブなアプローチで要件不確実性を早期排除（天野久弥）
    • 大規模SIerの慣行（要件定義5人→詳細設計20人→開発100人の階段型）と整合困難
    • 顧客側の経営層が「ウォーターフォールでないと意思決定できない」傾向

  • AI（ChatGPT・Claude等）による要件定義支援

    • 「AIで要件定義が劇的に変わる！ヒアリングからドキュメント作成まで」（業務効率化サポータ）の活用事例
    • Notion×AI要件定義レビュー（すぅ）、AI駆動PM（複数）
    • 個人情報・社外秘情報の取り扱い、AI出力の妥当性確認、最終責任は人間PMに残る

  • ガントチャート／WBSツール（Backlog・Jira・Trello・Asana・Microsoft Project）

    • 「ガントチャートを使えば進捗管理はうまくいく」は幻想（おだゆきえ）
    • 「納期に合わせた日付だけが並んだ表。ただの『願望表』」（深沢隆司）
    • 予実管理欠如・手作業更新で実態と乖離

  • Notion／NotePM等のドキュメント共有ツール

    • 議事録・要件定義書・設計書の中央集約
    • 兼務PMにとって全項目の更新負担、検索性は向上しても要件定義そのものの困難は解消されない

  • BizDev機能の分離（Sales / Business Development / PdM）

    • 営業のPL目標と開発のBS（資産）目標の対立を緩衝（井原真吾）
    • 中堅以上の組織でないと専任配置できない、受託では発注者と一体運用しないと機能しない

  • ITコンサル・PMO代行サービス

    • 大手SIer・外資系コンサル（Accenture・PwC・Deloitte等）が要件定義から伴走
    • 「金かけてコンサル雇って要件定義するくらいなら、諦めて柔軟に対応するお金を準備するほうが賢明」（keita）の本質的批判
    • 単価1人月150〜300万円級、中小受託案件では費用対効果合わない

  • 準委任契約への移行（請負からの転換）

    • 仕様変更柔軟性、現場のリアルに即した契約
    • 完成責任不在で発注者側は不安、受託側は時間制で売上頭打ち
    • 偽装請負リスク（指揮命令系統の曖昧化）

  • 生成AIによる要件定義・コード生成

    • 「AIで自社開発するから発注減らすよ」（既存pains.md・風鳥冴達）
    • 1〜2人のエンジニアで従来の10人規模PJを完遂する事例急増（既存pains.md）
    • 要件定義の苦痛は残る／増大、コード生成より上流の言語化が新たなボトルネック

  • 健康管理・労務管理の強化（働き方改革・36協定）

    • 月100時間規制、過労死ライン80時間／月平均
    • 違法な長時間労働でアクセンチュアが書類送検（過去事例）
    • 納期直前の局所的長時間労働は依然温存、PMが帳簿外で吸収するケース

関連ペイン

IT業界内

  • 多重下請け構造・中抜き（pains.mdカテゴリ1）――上流SIer元請のPMが下請けPMOに作業を振り、責任は上流PMに集中、報酬は下流ほど薄い構造
  • SES／客先常駐の働き方（pains.mdカテゴリ2）――客先常駐PMは複数顧客を同時並走、プロパー社員より一段下の扱いで意思決定権限なし
  • 受託開発会社の経営（pains.mdカテゴリ3）――顧客ガチャ・無限修正・営業リードタイム1年・月残業300時間が経営者兼PMに集中
  • Web制作会社の経営（pains.mdカテゴリ4）――2徹3徹、見積→修正→請求の手間、Web制作PMも要件定義の困難を共有
  • SaaS事業者の経営（pains.mdカテゴリ5）――エンタープライズMVP、個別カスタマイズの技術的負債、PdMとPjMの兼務
  • フリーランスPM／エンジニア（pains.mdカテゴリ7）――フリーランスPMは紹介・人脈・エージェント頼み、案件途中での引継ぎ、孤独な意思決定
  • IT人材採用・組織（pains.mdカテゴリ8）――中堅PMが採用市場から消失、エンジニア採用無理ゲー化、2030年45万人不足
  • システム保守・運用・SRE（pains.mdカテゴリ9）――要件定義の漏れが運用フェーズの障害として表出、深夜オンコール、社内SE評価されない構造

横断ペイン

  • 生成AIによる人月モデル崩壊――要件定義の重要性は逆に増大、PMの言語化スキルがボトルネックに
  • 業務知識の暗黙知化・組織内身体知（横断）――エッジケースの言語化困難、ベテラン依存の単一障害点
  • 承継・後継者問題――前回の刷新を担当したPM・業務担当者が退職、業務知識が失われる
  • 健康・メンタル（労務横断）――月100時間超え残業、救急搬送、寝落ち、精神疾患、PMの孤独
  • DX人材不足（経産省・各業界共通）――DX推進のためのPM／PMO／PdM人材の絶対的不足

IT受託・PM業界用語の前提知識

  • PM（Project Manager／プロジェクトマネージャー）: プロジェクトのQCD（品質・コスト・納期）責任を負う役割。PMI／PMBOKの定義
  • PdM（Product Manager／プロダクトマネージャー）: プロダクトの「何をなぜ作るか」を決める役割。プロダクトの成功責任
  • PjM（Project Manager／プロジェクトマネージャー）: PdMと区別する文脈で「どう作るか」「いつ作るか」を担う役割
  • PL（Project Leader／プロジェクトリーダー）: PMの下で実行を担う、現場監督的役割
  • PMO（Project Management Office）: プロジェクトマネジメント支援組織。標準化・横串管理
  • PMM（Product Marketing Manager）: プロダクトのGo-to-Market戦略担当
  • 要件定義（Requirements Definition）: 何を作るかを合意するフェーズ。ビジネス要件・業務要件・機能要件・非機能要件・運用要件の5段階
  • 基本設計（Basic Design／外部設計）: 要件をシステム化するための画面・帳票・データ設計
  • 詳細設計（Detailed Design／内部設計）: モジュール設計・関数設計・データベース物理設計
  • WBS（Work Breakdown Structure）: 「成果物中心の階層構造」（深沢隆司）。本来は作業ではなく成果物
  • ガントチャート: 横軸時間・縦軸タスクの工程表。WBSと混同されがち
  • PMBOK（Project Management Body Of Knowledge）: PMI（Project Management Institute）が定めるPM標準。10領域・5プロセス群（最新版は7版で原則ベース）
  • PMP（Project Management Professional）: PMI認定資格。PM実務経験必須、合格率約60%、3年でPDU更新必要
  • PRINCE2: 英国政府発祥のPM標準
  • QCD（Quality／Cost／Delivery）: PM3大制約
  • ステークホルダー: プロジェクトの利害関係者（顧客・経営層・業務部門・開発・運用・取引先・法務・コンプライアンス等）
  • WBS辞書: WBS各項目の詳細記述（PMBOKで規定）
  • クリティカルパス: スケジュール上の最長経路。遅延がプロジェクト全体に波及
  • ウォーターフォール開発: 上流→下流の一方向開発。要件定義→基本設計→詳細設計→実装→単体・結合・システム・受入テスト
  • アジャイル開発: 反復的・段階的開発。スクラム・カンバン・XP・FDD・DSDM等
  • スクラム: アジャイル代表手法。スプリント（1〜4週間）でプロダクトインクリメントを開発
  • デイリースクラム（朝会）: スクラムの日次15分イベント。形骸化しやすい
  • スプリントレビュー／レトロスペクティブ: スクラムの振り返りイベント
  • ユーザーストーリー: アジャイルの要件記述形式「○○として、××したい、なぜなら△△だから」
  • MVP（Minimum Viable Product）: 最小限の機能で市場検証するためのプロダクト
  • MSP（Minimum Sellable Product）: 最小限の販売可能プロダクト
  • PoC（Proof of Concept）: 概念実証
  • モック（モックアップ）: 静的な見た目の試作品
  • プロトタイプ: 動的な体験できる試作品
  • Fit&Gap分析: ERPなどパッケージ導入での既存業務とパッケージ機能の差分分析
  • OKR（Objectives and Key Results）: 目標管理手法。プロダクト運営で多用
  • KPI（Key Performance Indicator）: 重要業績評価指標
  • BA（Business Analyst／ビジネスアナリスト）: 業務要件定義の専門家
  • SE（Systems Engineer）: 日本独特のIT職種。要件定義から設計・開発まで担当
  • SIer（System Integrator）: 受託SI企業。NTTデータ・富士通・日立・NEC・大塚商会・伊藤忠テクノソリューションズ等
  • SES（System Engineering Service）: エンジニアの技術役務提供契約。準委任が多い
  • 請負契約: 完成責任あり、受注側が完成責任を負う
  • 準委任契約: 善管注意義務はあるが完成責任なし、時間ベースの対価
  • 派遣契約: 派遣先の指揮命令、労働者派遣法の規制対象
  • 偽装請負: 形式は請負・準委任だが実態は派遣の状態。違法
  • デスマーチ（Death March）: 過重労働で終わりが見えないプロジェクト。エドワード・ヨードン著書
  • 炎上: プロジェクトがQCDのいずれかで大きく崩壊した状態
  • 火消し: 炎上プロジェクトのリカバリ作業
  • 正常化バイアス: 危険信号を「いつものこと」として軽視する心理
  • 基幹系システム: 業務の中核を担うシステム（人事給与・財務会計・販売・購買・在庫・生産管理）。COBOL・メインフレーム・SAP等
  • 情シス: 情報システム部門。発注者側のIT担当
  • EOL（End of Life）: 製品・フレームワーク・言語のサポート終了
  • 技術的負債（Technical Debt）: 短期的な実装の積み上げが後の改修・改善を困難にする状態
  • 過労死ライン: 月80時間以上の残業（複数月平均）または月100時間以上（単月）
  • 36協定（さぶろくきょうてい）: 労働基準法36条に基づく時間外労働協定。特別条項で月100時間まで例外的に可

ペイン解消の難易度（仮説評価）

  • 発注者側の言語化能力: ★★★★★（ユーザー自身が「何を欲しいか言えない」根本的不可能性、エッジケースの身体知化、システム刷新7〜14年に1回で経験ゼロリセット――goza・keita）
  • 業界の見積もり文化変革: ★★★★（「鉛筆なめなめ」「営業的に通しやすい数字」（ヤマダ）の競争入札文化が固定化、見積打率の計測（柴田秀夫）が普及していない）
  • 正常化バイアス・現場違和感の不報告: ★★★★★（「『何かがおかしい』と気づいていながら、それを明確に言語化できず」（ヤマダ）「最終的にはなんとかなるだろう」（ヤマダ）の心理的構造、報告ライン上での減衰）
  • PM／PMOの孤独と意思決定重圧: ★★★★（「最終決定の重圧」「中間管理職的立場」「打ち明けられない孤独感」（Tom.Msn）。フリーランスPMほど顕著）
  • PMP／PMBOKと現場のギャップ: ★★★（標準論は学べるが現場の不可能性は解消されない、「修羅の道」（PMP合格体験記）と表現される）
  • アジャイル／スクラムの形骸化: ★★★★（ゾンビスクラム・カーゴカルトアジャイルの再現性、受託契約構造との不整合、デイリースクラムの省略・形骸化）
  • ガントチャート・WBSの誤用: ★★★（WBSは本来「成果物中心」（深沢隆司）だがガントチャート＝計画と誤解、予実管理欠如・手作業更新の構造）
  • 営業（PL）vs 開発（BS）対立: ★★★★（機能要望リストへの恐怖（井原真吾）、BizDev機能分離は中堅以上の組織しか実装困難）
  • 契約形態（請負・準委任）と仕様変更責任: ★★★★（請負完成責任 vs 準委任柔軟性、変更管理プロセスが契約書に明文化されていないと地獄、偽装請負リスク）
  • 健康と長時間労働: ★★★★（月400時間級は減ったが、納期直前の月100時間超えは依然存在、救急搬送・寝落ち事例、過労死ライン）
  • 生成AIによる代替: ★★★（コード生成は代替可能、要件定義・PMの上流業務はAI支援にとどまる、最終責任は人間PMに残る）
  • 業務知識の暗黙知言語化: ★★★★★（エッジケース5%の身体知、組織内ベテランの引退で失われる業務ルール、ヒアリングで引き出せない構造）
  • 発注者側のIT企画力育成: ★★★★（情シス・ユーザー部門のIT企画力不足、エンジニアからの情報提供で改善可能（goza）だが組織文化の変革が必要）
  • ステークホルダー多数の調整: ★★★（影の実力者40%の発生（下町ぷろまね）、ステークホルダーマップの体系化が普及していない、新人PMの「板挟み」誤解（さとじゅん））

引用元記事リスト

  1. 要件定義しんどいし、正直な気持ちを書く - ponzu（フリーランスエンジニア）
  2. 要件定義を誰も出来ないという不都合な真実 - goza（独立系システムコンサル）
  3. なぜ要件定義はろくな事にならないのか？〜情シス目線のプロジェクトマネージメントTips#08 - keita（情シス担当者）
  4. 地獄の炎上プロジェクトでPMはどう振舞うべきか？ - 柴田秀夫（株式会社ARAKADO代表、PMP®）
  5. なぜ僕たちのプロジェクトは炎上するのか？ - ヤマダ（元請SIerのPM・アーキテクト）
  6. なぜ営業組織と開発組織の仲は悪くなるのか？を考えて体制構築したらBizDevの重要さがわかった話 - 井原真吾（株式会社Graffer経営者）
  7. 受託開発はつらい? - Sasamori（セルプロモート執行役員）
  8. 受託開発はつらいって本当？開発会社の社長が解説してみた。 - 受託社長
  9. 【実録】炎上プロジェクトの火消し術：新卒でPLになった私が学んだ3ステップ - すぅ | AI駆動PM
  10. プロジェクトはなぜ失敗しやすい？ - Takashi Suda / かんた
  11. 要件定義の失敗例 - tamachang（株式会社Futurize取締役）
  12. 【システム開発プロジェクト炎上診断】 ～ ①見積り編 - 柴田秀夫
  13. 「要件定義とは？」にスパッと答えられる人は少ない - 柴田秀夫
  14. 【残業激減】AIで要件定義が劇的に変わる！ヒアリングからドキュメント作成まで現役SEが徹底解説 - 業務効率化サポータ@たく06
  15. ヒアリング中に焦らない！要件定義インタビューの進め方とその場対応術 - IT職人の道具箱
  16. 【技術関連】今日からPM(炎上プロジェクト①) - あにき
  17. 炎上案件に入ると、だいたい最初に聞く一言 - itchie@辰巳電子工業
  18. 日米で経験した炎上プロジェクトの違い - 牛尾剛（Microsoft）
  19. 【実話】IT業界の「デスマーチ」① 納期半減が招く炎上案件とエドワード・ヨードンの教え - 内田吉則
  20. 【実話】IT業界の「デスマーチ」② 人員不足が招く炎上案件と経験ゼロ増員の落とし穴 - 内田吉則
  21. 【プロマネの生きる道】「孤独」を力に変えるPMの流儀 - Tom.Msn
  22. 「WBS（ガントチャート）」は「希望の幻影」だった。 - 深沢隆司
  23. 「ガントチャートを使えば進捗管理はうまくいく！」は幻想。ガントチャートのイケてない３つのポイント - おだゆきえ
  24. ITプロジェクトの失敗はエンジニアのせいではない - goza
  25. 受託PjM→自社サービスPdMになって「変わった」4つのこと - Takuya Asako（note株式会社）
  26. PMにおける調整事との向き合い方 - さとじゅん（メルペイPdM）
  27. あのプロジェクトが失敗した本当の理由 ステークホルダーマップで防げた失敗 - 下町ぷろまね
  28. 最大手SIer出身者が語るウォーターフォールからアジャイルの会社に転職する時に意識すべきこと - 花岡宏明（NTTデータ出身）
  29. 【プロマネ】大規模システム開発での、ウォーターフォールとアジャイルの宗教論争 - 天野久弥
  30. なぜプロジェクトマネジメントが機能しないのか 02 不確実性の早期排除 - APDX
更新 2026-05-09 ・ 引用元 24記事
← 情報通信業のペイン一覧techbeansに相談する →