🧭 はじめに

Agileを導入したのに、プロジェクトがうまく進まない
スプリントは回っている。Storyは書かれている。ツールも整っている
──それなのに、なぜか成果が出ない。現場は疲弊していく。仕様は迷子になる。

なぜなのか？

この問いに対して、プロセスやツールのせいにする声は多い
だが、小生から見れば答えはひとつだ

構造がない。構造を考えていない。構造という発想が、現場に存在しない

この記事は、
Agileという手法が“なぜ破綻するのか”を、
技術や理論ではなく、“視座と構造”の欠如という観点から断言するものである

表面的な手法ではなく
システムを支える“骨組み”の話を、これから始めよう

🧱 第一章：Agileの説明 ― やり方の前に「前提」を理解せよ

🔹 1. Agileとは“価値観”であって、手順ではない

Agileとは、「こうやって開発しなさい」というレシピではなく
「こういう価値観を持って、こういう姿勢で開発に臨もう」 という考え方を捉える

それを示したのが、2001年の「アジャイルソフトウェア開発宣言（Agile Manifesto）」

🔹 2. その価値観はこれ：

個人と対話 > プロセスとツール
動くソフトウェア > 包括的なドキュメント
顧客との協調 > 契約交渉
変化への対応 > 計画への固執

つまり、“人間中心・現実優先・変化許容”が本質 ということ
幾らやり方だけ覚えてもこの本質が何かを理解しない限りAgileは炎上する

🔹 3. Agileの前提条件は「考える力」と「構造があること」

Agileは「考えなくていい仕組み」ではない。むしろ逆

ユーザーが何を求めていて
それをどう実現し
どこで改善する余地があるか

これを 自律的に判断できる“思考体”を持ったチーム” が前提にある
それはスクラムで到底理解できるものではない

🔹 4. だからこそ、Agileを使う前に「構造」が必要

機能の全体像
データの構造
非機能要件の制約
異常系のルール

これらがわかっていなければ、Agileを回しても「何をどう変えるか」が判断できない

🧱 第二章：User Storyとは？ ― Agile手引きに欠けている視点

🔹 1. 「User Storyを書けば要件定義は不要」という勘違い

多くの現場では、「User Storyを書いてスプリントに入ればAgile」と思っている
手引きにもそう書かれている。だが、それは要件の“姿”であって、“中身”ではない

例：「ユーザーとして、私は〇〇をしたい。なぜなら××だから」
→ これ、構造も設計も背景も、何も書かれていないただの主張

🔹 2. User Storyは“仕様の出口”であり、設計の代わりではない

あなたの言うUser Storyが本来求める姿は：

操作 → データ処理 → サーバ動作 → 応答まで一連の流れ
正常系と異常系を含む振る舞いが文脈付きで記述されている
CRUDが明確で、処理の意図と対象が一致している

これがなければ、設計・開発・テストの全てがブレる

🔹 3. Agile手引きにおけるUser Storyの欠陥

手引きが推奨すること	欠けているもの
役割・目的・理由を簡潔に記述	データ構造、処理構造、エラー処理
POが優先度をつける	技術的依存性、システム整合性
分割可能な単位で書く	機能単位の全体設計と連動がない

→ 結果、「Storyはあるが、仕様はない」という地獄に突入する

🔹 4. User Storyは“構造から導出された結果”である

User Storyは「書くもの」ではない「導き出すもの」である

機能要件が明確になり
利用者の操作とシステムの応答が定義され
状態遷移やデータの構造が設計されて
→ その上でようやくひとつのUser Storyになる

🧱 第三章：要件分析 ― 差分が見えなければ、構造は語れない

🔹 1. Agileを始める前に「今」と「あるべき」が見えているか？

要件を語る前に、
その機能が“何を変えたいのか”を理解しているか

既存業務
システムの限界
ユーザーの動き
データの流れ

これらが“今どうなっているか”が見えていなければ
「こうしたい」も「こうあるべき」も意味を持たない

🔹 2. 差分を取らずにTO-BEを語ると現場は壊れる

TO-BEの設計図だけ描いてもAS-ISとの乖離が把握されていなければ
それはただの“理想のお絵描き”

現場が混乱するのは、既存の業務と接合できていないから

操作の導線
業務の粒度
移行の前提
運用の制約

これらがTO-BEの“背景”にない限り、誰も動けない

🔹 3. AS-ISとTO-BEの差分こそが構造を定義する

差分の中にこそ、以下が現れる：

何が変わるのか
どこが壊れそうか
誰が影響を受けるか
どんな制約が出てくるか

つまり、構造とは差分の中から浮かび上がるものであり
設計とは“TO-BEの図”ではない。“差分の線”を書く行為である

🧱 第四章：非機能要件とは？ ― Agileでは探せない、本当の要件

🔹 1. 非機能要件は、見える仕様の“裏”にある

画面にもコードにも書かれていない
でも存在しなければプロダクトは動かないか、壊れる

それが非機能要件
“使い勝手”でも、“パフォーマンス”でもない
「どうあってほしいか」という期待の姿勢そのもの

🔹 2. Agileのテンプレには存在するが本質はそこにない

可用性：99.9%
レスポンス：2秒以内
セキュリティ：認証あり
ログ：記録する

──書いてある。でも、なぜ？何を？いつ？誰に？ が書かれていない

テンプレートを埋めることはできる
けれど構造の中で語られていなければ、それは“飾り”にすぎない

🔹 3. 非機能要件は“導出”するものであって、“定義”するものではない

非機能要件は、こうして生まれる：

日次で集計されるデータ → 夜間処理の安定性
一人で使う管理画面 → 監査ログの粒度の調整
APIに連携する外部サービス → 疎通とリトライ設計

つまり機能の構造から自然に浮かび上がるもの
先にリストがあるわけではない

🔹 4. Agileではこの“流れ”が抜け落ちる

スプリントに追われ、Storyに分解され、開発が進む
その中に構造の余白も、制約の根拠も、残らない

非機能要件は「考える余白」であり、構造の奥に埋もれている仕様である
それを取り出すには、テンプレではなく、構造に対する経験と問いが不可欠である

🧱 最終章：炎上は、構造を知らない者が引き起こす

🔹 1. スプリントが回っていても、プロジェクトが進まない現場

バグが減らない
Storyが終わっても、仕様が決まっていない
Reviewで揉める
保守が地獄

──これは偶然ではない。
構造がなく、構造を見ようともしない人間が、手法だけを回しているからに他ならない

🔹 2. 技術力ではなく、「構造の視座」の有無が炎上を分ける

ユーザーと機能の距離
機能とデータの流れ
状態とエラーの網羅
運用と設計の連動

これらが“考慮された痕跡”のないプロジェクトはどんなメンバーで回しても炎上するものだ

🔹 3. 手順ではなく、構造を読む力が必要である

教科書の順序を護るのはやめよう。大事なのは現場の力学を読む視点である
Storyを作る前に、構造を描けるか？
テンプレを埋める前に、差分を読めるか？

それがなければ、Agileは必ず失敗する

✅ ご相談について

🔥 炎上している、あるいは構造が見えないまま進んでいるプロジェクト
📋 User Storyが分解できていない、Backlogが仕様になっていない
🔍 設計と運用、機能と非機能の整合が取れなくなっている

──そうした現場の再構成・レビュー・支援、承っております

炎上案件のご相談は当方まで
技術と経験豊富な視座で構造全体を見直し立て直すお手伝いをさせていただきます

👉 詳細・お問い合わせはこちら：
🔗 https://jdotsystem.com/jpn/service