https://tech.findy.co.jp/entry/2025/09/22/070000

こんにちは。Findy Tech Blog編集長の高橋（@Taka-bow）です。

「要件がまた変わった」「会議ばかりで開発時間がない」「あの人に聞かないと進められない」──こんな悩みを抱えていませんか？

前回の記事では、アジャイル実践者の59.6%が開発生産性に前向きだという意外な事実をご紹介しました。しかし、前向きでも実際の取り組み率は47.8%に留まっています。

今回は、798名の調査から明らかになった開発生産性を阻害する要因と、その改善への道筋を探ります。特に、技術的な問題よりも深刻かもしれない「組織の3大課題」がどのように連鎖し、どこから手をつければ効果的なのかを考察します。

【調査概要】

調査対象：ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など
調査方法：インターネット調査
調査期間：2025年4月2日(水)～2025年5月21日(水)
調査主体：ファインディ株式会社
実査委託先：GMOリサーチ&AI株式会社
有効回答数：798名（95%信頼区間±3.5%）
統計的検定力：80%以上（中程度の効果量d=0.5を検出）
調査内容：
- 開発生産性に対する認識
- 開発生産性に関する指標の活用状況
- 開発生産性に関する取り組み
- 開発環境・プロセス評価
- 組織文化と生産性

調査結果から、開発生産性を阻害する要因には明確な優先順位が存在することが判明しました。ここで注目したいのは、上位3つの課題がいずれも技術的な問題ではなく、組織運営やプロセスに関する点だということです。

上位3つは技術的な要因ではなかった

開発生産性を阻害する要因について尋ねたところ、次の結果が明らかになりました。

開発生産性の主要な阻害要因（複数回答）

順位	阻害要因	回答率	回答者数	分類
1位	不明確な要件	53.5%	427人	組織プロセス
2位	会議が多い	38.7%	309人	組織プロセス
3位	コミュニケーションの問題	33.6%	268人	組織プロセス
4位	技術的負債	30.5%	243人	技術的要因
5位	開発環境の制約	19.2%	153人	技術的要因
6位	その他（具体的に）	2.8%	22人	-

（N=798、複数回答可）

また、上位3つの阻害要因はいずれも組織プロセスに関連しており、技術的負債（30.5%）を上回っています。

この結果は、技術的な改善だけでは開発生産性の問題を解決できないことを示唆しています。むしろ、組織の仕組みやプロセスの見直しこそが、生産性向上の鍵となるのです。

それでは、これらの3大課題について、順に詳しく見ていきましょう。

課題1 - 「不明確な要件」（53.5%）

半数以上が直面する根本的問題

回答者の53.5%が指摘するこの課題は、上流工程における要件定義の品質に関わる根本的な問題です。

不明確な要件は、手戻りや追加開発を引き起こし、プロジェクトの効率性と開発チームの生産性を著しく低下させる要因となっています。

要件が不明確になる3つの側面

この問題には大きく3つの側面があると考えられます。

▼ 第一の側面 - 文書化・情報伝達の問題

要件自体は顧客や関係者の頭の中では具体的になっているものの、それを適切に言語化・文書化できていない可能性があります。

この問題の本質を理解するため、要求仕様化の専門家の知見を参考にしてみましょう。

私の恩師である清水吉男氏は、要求の仕様化手法「USDM（Universal Specification Describing Manner）」を開発し、著書『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』でその手法を体系化したコンサルタントでした。

作者:清水吉男
技術評論社

長年の実践を通じて日本のソフトウェア開発現場を見てきた清水氏は生前、「なぜ仕様が書かれないのか」について、次の3つの問題を指摘していました。

問題点	詳細
"要求"が表現されていない	そもそも実現したいことが明確に表現されていないため、その要求を満たすための仕様を拾いきれない
要求と要求仕様の関係性の理解不足	要求と要求仕様の関係や違いを認識していないため、両者が混同される
"機能仕様書"への偏り	機能面ばかりに注目することで、品質要求などの非機能要件が漏れてしまう

これらの問題に加え、日本語の曖昧性も状況を複雑にしています。清水氏は「要求」「要件」「仕様」といった用語の混同についても警鐘を鳴らしていました。これらは英語と照らし合わせることで、それぞれの意味がより明確になります。

用語	英語	意味
要求	Requirement	実現したい（Require）ことが書かれたもの
仕様	Specification	特定（Specify）できた状態で表現されているもの

そして、清水氏が特に強調していたのは、要求には必ず「理由（Why）」が存在するという点です。

すべての要求には、それが存在する背景や理由があります。この「理由（Why）」を明確にすることが、適切な仕様を導き出すための重要な鍵となります。

要求の背後にある理由を探ることで、顧客が本当に実現したいことを正しい位置に誘導でき、仕様を外さない開発が可能になります。

理由が曖昧なままでは、要求の範囲を正しく認識できず、開発の方向性を見誤る可能性があります。

また、理由を理解することで、要求の変化の方向を予測し、将来の変更に備えた柔軟な設計が可能になります。

この「理由（Why）」への配慮が、最終的には保守性、パフォーマンス、機能拡張性、操作性、メモリー使用効率など、システム全体の品質に大きな差をもたらすのです。

このような概念の混同や、要求の背景にある「理由（Why）」への配慮不足が、文書化の質を低下させ、結果として「不明確な要件」という問題を生み出している可能性があります。

▼ 第二の側面 - ソフトウェア開発の本質的な不確実性

より根本的な問題として、そもそもプロジェクト初期段階ですべての要件を確定できるという前提自体が非現実的である可能性があります。

書籍『アジャイルサムライ』では、この現実を端的に示しています。

ソフトウェア開発の3つの真実
1. プロジェクトの開始時点にすべての要求を集めることはできない
2. 集めたところで、要求はどれも必ずといっていいほど変わる
3. やるべきことはいつだって、与えられた時間と資金よりも多い

出典：Rasmusson, J. (2011).『アジャイルサムライ──達人開発者への道』（西村直人・角谷信太郎・近藤修平・角掛拓未訳）. オーム社. (原著出版年：2010)

作者:Jonathan Rasmusson
オーム社

これらの「3つの真実」は、多くの開発現場で日々体感されている現実ではないでしょうか。

要件の変更に振り回され、限られたリソースで山のようなタスクに向き合う。そんな経験は、きっと多くの読者の皆様にも共感いただけるはずです。

重要なのは、この不確実性を前提として受け入れ、それに対応できる柔軟な体制を構築することなのだと思います。

▼ 第三の側面 - 優先順位と価値の曖昧さ

多くの開発現場では「やりたいことはたくさんある」状態です。

しかし、どれから着手すべきか、なぜそれが重要なのかが曖昧なまま、要件リストだけが膨張していきます。

さらに深刻なのは、関係者同士が「合意が取れている」と思い込んでいる状況です。

会議では皆頷いていても、実際には各人が異なる成果物をイメージしており、後になって「思っていたものと違う」という事態が発生します。

出典：Jeff Patton "Glad we all agree" - https://jpattonassociates.com/glad-we-all-agree-2/

そして最も本質的な問題は、顧客にとっての価値（アウトカム）が不明確であることです。

「何を作るか」ばかりに注目し、「なぜ作るのか」「それによって顧客がどう変わるのか」という視点が欠如していると、要件自体が迷走してしまいます。

これらの問題に対する有効な解決策の1つが「ユーザーストーリーマッピング」です。

作者:ジェフ・パットン,川口恭伸,長尾高弘
オライリージャパン

ユーザーの行動を時系列で可視化することで、全体像と優先順位が明確になり、関係者全員が同じ地図を見ながら議論できます。

また、ユーザーの体験に焦点を当てることで、自然とアウトカムを意識した要件定義が可能になるのです。

要件定義を阻害する組織的構造問題

これらの3つの側面（文書化の問題、不確実性への対応、優先順位と価値の曖昧さ）がなぜ改善されないのでしょうか。

そこには、次のような組織的な構造問題が潜んでいると考えられます。

阻害要因のカテゴリー	具体的な問題	影響
文書化・情報伝達の阻害	決定権限や責任の所在が不明確	誰が最終決定権を持つのか曖昧なため、要求の「理由」を確認する相手が特定できない
	ステークホルダー間での認識の不一致	要求の背景や優先度について、関係者間で共通理解が形成されていない
不確実性への対応の阻害	完璧主義的な組織文化	「最初から完全な要件定義ができるはず」という非現実的な期待が根強い
	変更を失敗と捉える風土	要件変更を「計画の失敗」と見なし、柔軟な対応を躊躇する

実際、調査では開発フレームワークについて「よくわからない」が18.2%、「ウォーターフォール」が36.8%と、合わせて過半数（55.0%）が変化への柔軟な対応を前提としていない、または開発手法自体を明確に理解していない状況でした。

この結果から、不確実性への対処方法が組織的に確立されていない可能性が高いことが見て取れます。ただし、ウォーターフォール型開発であっても、適切なリスクマネジメントが実施されていれば、ある程度は対処可能だと考えられます。

「不明確な要件」への改善アプローチ

これまで見てきた問題構造を踏まえ、要件定義の改善には段階的なアプローチが有効と考えられます。

▼ 第1段階 - 文書化・情報伝達の改善

清水吉男氏が指摘した「要求の理由」を明確にすることから始めましょう。

清水氏が開発したUSDM（Universal Specification Describing Manner）は、まさにこの問題を解決するための手法です。USDMの特徴は、要求と仕様を階層的に整理し、それぞれに「理由」を明記する点にあります。

USDMの基本構造

要求：「〜したい」という形で記述し、必ず「理由」を併記
仕様：要求を実現するための具体的な振る舞いを「〜する/〜である」と記述
階層化：要求を段階的に詳細化し、抜け漏れを防ぐ

例えば「ログイン機能が欲しい」という要求に対して、

理由：セキュリティを確保し、ユーザーごとにカスタマイズされた体験を提供するため
仕様：3回ログインに失敗したらアカウントをロックする、パスワードは8文字以上とする、など

このように構造化することで、「なぜ」が明確になり、手戻りが激減します。

ユーザーストーリーカードという選択肢

アジャイル開発では「ユーザーストーリーカード」も有効な手法です。これは要求を次の形式で記述します。

「〜として（Who：誰が）、〜したい（What：何を）、なぜなら〜だから（Why：理由）」

例

Who：「ECサイトの利用者として」
What：「過去の購入履歴を簡単に確認したい」
Why：「なぜなら、リピート購入を素早く行いたいから」

ユーザーストーリーカードの利点は次の通りです。

視点が明確：誰のための要求かが一目瞭然
価値が明確：「なぜなら」で理由と価値を必ず記述
対話を促進：カードを使って関係者と議論しやすい
受け入れ条件：裏面に具体的な仕様（受け入れ条件）を記載

USDMとユーザーストーリーカードは、どちらも「理由（Why）」を重視する点で共通しています。組織の文化や開発スタイルに合わせて選択するとよいでしょう。

実践的な改善策

要求テンプレートの導入：USDMやユーザーストーリー形式を活用し、要求記述時に必ず「理由・背景」欄を設ける
ステークホルダーマッピング：各要求の提案者と承認者を明確化し、決定権限の所在を可視化
共通言語の確立：要求・要件・仕様の違いを組織内で統一し、認識のズレを防止

▼ 第2段階 - 不確実性への適応力向上

アジャイルサムライの「3つの真実」を受け入れ、変化を前提とした体制を構築します。

段階的な要件確定（Progressive Elaboration）：初期はMVPレベルで要件を定義し、フィードバックを受けながら詳細化
ユーザーストーリーマッピングの導入：ユーザーの行動を時系列で可視化し、全体像を共有しながら優先順位を決定。Jeff Patton氏が提唱したこの手法は、要求の「理由」と「文脈」を自然に表現でき、ステークホルダー間の認識を合わせる強力なツールとなります
変更管理プロセスの確立：要件変更を「失敗」ではなく「学習」と捉え、影響分析と承認フローを明確化
プロトタイピングの活用：動くモックアップで早期に認識を合わせ、手戻りを最小化

▼ 第3段階 - 組織文化の変革

過半数を占める「ウォーターフォール」「よくわからない」層への働きかけが重要です。

段階的な移行戦略：いきなり全面的なアジャイル化ではなく、小規模プロジェクトから試行
教育・研修の充実：開発手法の理解促進と、変化への対応力向上
成功体験の共有：柔軟な要件対応で成功したプロジェクトの事例を組織内で展開

課題2 - 「会議が多い」（38.7%）

開発時間を奪う会議の実態

回答者の38.7%が指摘するこの問題は、開発に集中する時間を大幅に削減する要因となっています。

会議は必要な情報共有の場である一方、過剰な会議は開発者のフロー状態を妨げ、集中して作業できる時間を奪っています。

さらに深刻なのは、会議の連鎖的発生です。

明確な結論が出ない会議は、確認のための追加会議を必要とし、さらにその調整のための会議が発生するという悪循環に陥ります。

本来、効率化のための議論であっても、会議自体が目的化してしまうと、開発時間の確保という本来の目的から離れてしまう恐れがあります。

会議が減らない本質的な理由

会議が増殖し続ける最大の要因は、異なる目的の会議が混在してしまうことにあります。

会議には、次の4つの目的があると言われています。

会議の目的	会議の例	ディスカッションの種類
報告や情報共有を行い、次の活動に活かす	日常の進捗報告	情報交換型
多くの視点から、新しいアイデアを生み出す	新企画の洗い出し	洗い出し型
事実を論理的に組み立て、因果関係を整理する	現状課題の共有と整理	分析・考察型
ゴールを実現するために判断し、結論を出す	新企画の決定	意思決定型

しかし現実には、これらの異なる目的が1つの会議に混在し、「情報共有のつもりが議論になり、結論も出ないまま時間切れ」という状況が頻発します。

この問題は、課題1で見た「要件の不明確さ」と密接に関連しています。

要件の不明確さと組織構造の問題が複合的に作用し、会議を増やす負の連鎖が生まれています。

問題の種類	具体的な事象	結果
要件の不明確さ	要求の「理由」が共有されていない	同じ説明を何度も繰り返す
	決定権限が不明確	意思決定型の会議なのに決定できない
	目的が曖昧	「とりあえず集まって話そう」という会議が増える
組織構造	権限委譲の不足	同一部門内で多階層が参加（上司も部下も全員）
	「全員参加」の誤解	議論には4-5名が理想なのに大人数を集める
	責任回避の文化	「みんなで決めた」形にして個人の責任を曖昧化

実際、5人以上の会議になると「私1人ぐらい参加しなくても」という心理が働き、居眠りや内職、発言しない人が出てきます。

これは参加者個人の問題ではなく、会議設計の失敗なのです。

興味深いことに、アジャイル開発を導入した組織でも会議過多の課題は残っています。

デイリースクラム、スプリントプランニング、レトロスペクティブなど、本来は目的が明確なはずのセレモニーが、形骸化してしまうケースも見受けられます。

この問題は、物理出社でもリモートワークでも共通して発生しています。

むしろリモートワークの普及により、「とりあえずオンラインで集まる」ハードルが下がり、会議数が増加する傾向も見られます。

場所を問わず、会議の本質的な設計と運用の見直しが必要なのです。

「会議が多い」への改善アプローチ

会議の問題を解決するには、まず「会議の目的を明確に分離する」ことから始める必要があります。

▼ 第1段階 - 会議の目的別再設計

前述の4種類の会議それぞれに適した運営ルールを設定します。

ディスカッションの種類	運営ルール
情報交換型	タイムボックス設定、資料事前配布、質疑は最小限
洗い出し型	参加者を4-5名に限定、個人思考時間を確保
分析・考察型	分析手法を事前に決め、全員が手順を理解してから開始
意思決定型	決定権者を明確化、判断基準と選択肢を事前準備

▼ 第2段階 - 組織構造の見直し

会議過多の根本原因である組織構造にメスを入れます。

権限委譲の推進：同一部門内の多階層参加を避け、適切なレベルに決定権を委譲
参加者の最適化：議論は4-5名、情報共有以外は必要最小限のメンバーに限定
権限レベルの明確化：デリゲーションポーカーなどを活用し、各メンバーがどのレベルで意思決定に関わるかを明確にする

デリゲーションポーカーはManagement 3.0で開発されたプラクティスです

▼ 第3段階 - 会議依存からの脱却

すべてを会議で解決しようとする文化から脱却します。

ドキュメント文化の構築：議事録・決定事項を確実に文書化し、共有する仕組みを確立
非同期ツールの活用：SlackやTeamsのスレッドで議論を進め、会議は意思決定のみに
時間制限の厳格化：すべての会議に明確な終了時間を設定し、延長を原則禁止

課題3 - 「コミュニケーションの問題」（33.6%）

曖昧な「コミュニケーションの問題」が示すもの

回答者の33.6%が「コミュニケーションの問題」を生産性低下の要因として挙げています。しかし、この「コミュニケーションの問題」が具体的に何を指しているのかは、統計的な分析を行っても特定できませんでした。

興味深いのは、「会議が多い」（38.7%）とは別項目として挙げられている点です。会議もコミュニケーションの一形態であるにもかかわらず、別の問題として認識されているということは、ここで言う「コミュニケーションの問題」は会議以外の何か別の問題を指していると考えられます。

Flow Stateから見える「見えない中断」

この問題を理解するには、DevEx（Developer Experience）の観点、特にFlow State（フロー状態）の概念が有効かもしれません。

開発者が「フローに入る」「ゾーンに入る」という状態は、完全に集中し、生産性が最大化される状態を指します。研究によれば、この状態を頻繁に経験する開発者は、より高いパフォーマンスを発揮し、質の高い製品を生み出します。

フロー状態を妨げる主要な要因は中断や遅延です。会議は「見える中断」として明確に認識されますが、「コミュニケーションの問題」は「見えない中断」を生み出している可能性があります。

「見えない中断」の正体

会議とは異なる形で開発者のフロー状態を阻害する要因として、次のようなものが考えられます。

中断の種類	具体的な問題	開発者への影響
非同期コミュニケーション	Slackやメールの返答待ち	作業が停滞、待機時間が発生
	チャットツールの頻繁な通知	集中が途切れ、再集中に時間がかかる
	複数の会話を並行処理	思考が分散し、効率が低下
情報探索	ドキュメントがどこにあるか不明	探し回る時間で開発が中断
	Wiki、チャット、メール等に情報が分散	情報収集に時間を取られる
	「あの人に聞かないと分からない」	属人化により作業がブロック
チーム間連携	他チームの作業完了時期が不明	依存関係で作業が止まる
	決定権者が不明確	承認待ちで進捗が遅延
	仕様の詳細が曖昧	何度も確認が必要になる
生成AI活用	AIの高速な生成に人間の判断が追いつかない	レビュー待ちが常態化、判断疲れ
	複数のAIタスクを並行して依頼	自己マルチタスク化で集中力が分散
	AIの処理待ち時間に別タスクを開始	コンテキストスイッチが頻発

これらの「見えない中断」は、一つ一つは小さくても、累積すると開発者が集中できる時間を大幅に削減します。研究によれば、中断から再び集中状態に戻るまでに平均15〜30分かかるとされており、頻繁な「見えない中断」は生産性に深刻な影響を与えます。

特に生成AI活用においては、AIの処理速度と人間の判断速度のミスマッチが新たな中断を生み出しています。AIが瞬時に生成するコードや文書を適切にレビューするには時間がかかり、その間にAIに別のタスクを依頼することで、結果的に人間側が複数のコンテキストを同時に管理する「自己誘発的マルチタスク」状態に陥るのです。

「コミュニケーションの問題」への改善アプローチ

もし「コミュニケーションの問題」が上記のような「見えない中断」を含んでいるとすれば、Flow Stateを守るための対策が効果的でしょう。

▼ 「見えない中断」を減らすための具体策

改善カテゴリ	具体的な施策
非同期コミュニケーション	• 返答の期待値を明確にする（今日中、明日中など） • 通知のルールを設定し、集中時間帯を確保 • 非同期で解決できることと同期が必要なことを区別
情報の構造化	• ドキュメントの一元管理と検索性の向上 • 技術的な意思決定の理由と経緯を文書化して残す • FAQやナレッジベースの整備
チーム間連携	• API仕様の文書化とバージョン管理 • 依存関係の可視化とタイムラインの共有 • ブロッキングポイントの事前特定と対策
AI活用の最適化	• AIタスクを順次処理する（並列依頼を避ける） • AIの出力をバッファリングし、まとめてレビュー • AIとの協働時間を時間枠で区切る

これらの施策は、「会議を減らす」という目に見える対策とは異なり、日常的な開発作業の中で発生する「見えない中断」を減らし、開発者がフロー状態を維持できる環境を整えることを目指しています。

まとめ - 共通認識から始まる改善

調査で浮かび上がった3つの阻害要因──「不明確な要件（53.5%）」「会議が多い（38.7%）」「コミュニケーションの問題（33.6%）」は、実は互いに連鎖する1つの問題群です。

問題の連鎖構造

プロジェクト開始時に「なぜ」「何を」「どう進めるか」の共有が不足すると、次の連鎖が起きます。

要件が不明確になる理由	会議が増える理由	コミュニケーションの質が低下する理由
プロジェクトの目的や背景（理由）が共有されていない	共通認識がないため、都度確認が必要になる	前提となる情報が共有されていないため、毎回説明が必要
成功基準やトレードオフの優先順位が定まっていない	会議の目的も不明確になり、4種類の会議が混在する	判断基準が不明確なため、議論が収束しない
結果として、要求の「理由」が分からず、仕様が定まらない	決定権限が不明確なため、全員参加の非効率な会議が増える	情報が構造化されず、属人化してしまう