DevOpsDays Tokyo 2026 軽量な仕様書と新たなDORA AI ケイパビリティで実現する、動くソフトウェアを中心とした開発ライフサイクル / DevOpsDays Tokyo 2026

● セッション概要
タイトル：軽量な仕様書と新たなDORA AI ケイパビリティで実現する、動くソフトウェアを中心とした開発ライフサイクル / SDLC centered on working software through lightweight spec documents and new DORA AI capabilities
スピーカー：久保 仁詩（株式会社ジークス GitLabパートナー事業責任者）
日時：2026年4月15日(水)　13:00～13:45

AIがコーディングを担う時代において、「仕様書を先に書く」従来のアプローチがかえってボトルネックを生む「AIパラドックス」の問題を取り上げます。本セッションでは、「動くソフトウェアを先に作り、そこから仕様を抽出し、製品版を実装する」4ステップのフローと、DORA AI ケイパビリティを組み合わせた実践知を共有します。開発期間70%短縮・ドキュメント工数85%削減を実現した事例もご紹介する予定です。
エンジニアリングマネージャー・テックリード・DevOpsエンジニア・アーキテクト・プロダクトマネージャーの方々にぜひご参加いただければと思います。

セッション詳細はこちら
https://confengine.com/conferences/devopsdays-tokyo-2026/schedule/rich#session-34338-info

● イベント概要
名称：DevOpsDays Tokyo 2026
開催日時：2026年4月14日(火)～16日(木) 9:30～16:00
主催/運営：DevOpsDays Tokyo 実行委員会
開催場所：大崎ブライトコアホール＆オンライン　ハイブリッド同時開催
イベント詳細・チケット購入は公式サイトをご確認ください。
https://www.devopsdaystokyo.org/

Transcript

1. 動くソフトウェアを中心とした開発ライフサイクル SDLC centered on working software through lightweight spec documents and new DORA AI capabilities. 久保 仁詩 (Niishi Kubo) | 株式会社ジークス 軽量な仕様書 DORA AI ケイパビリティ と で実現する DevOpsDay Tokyo 2026
2. AIを入れたのに、 開発が速くならない
3. AIパラドックスの実態 90% 業務の一部に AIを使用している開発者 チームのリードタイムが 明確に短縮されたチーム この差が AIパラドックス 多くの開発チームがぶつかっている壁 引用元: DORA 2025 State of AI-assisted Software Development report
4. 自⼰紹介
   株式会社ジークス GitLabパートナー事業責任者
   GitLab Champion‌ ‌ (GitLab認定エバンジェリスト)
   Friends of Figma Tokyo Leader‌ ‌ (Figma認定コミュニティ)
   GitLabというDevSecOpsプラットフォームを武器に、 大手企業の開発組織変革や組織のDevOps成熟度を高め る活動を推進。戦略立案からAI活用、CI/CDパイプライ ン構築、セキュリティシフトレフト実装、移行支援、 DevOps文化定着まで、一貫した導入支援・コンサルテ ィングサービスを提供。
   (Niishi Kubo) 久保 仁詩 @n11sh1_
5. 今日お話すること 1 AIパラドックスとDORA AIケイパビリティ AIを入れても速くならない構造的な理由と解決するための能力 2 実践現場での気づき チームのリードタイムが短縮できないのはなぜ？ 3 バリューストリームで考える 開発の流れを可視化してボトルネックの正体を知る 4 まず動かす、そこから仕様を生む 順序を逆転させた4ステップフロー 5 仕様書の軽量運用 AIによる逆生成でドキュメント工数削減
6. https://dora.dev/research/2025/d ora-report/ https://dora.dev/ai/capabilities- model/report/ 補足ガイド フルレポート 日本語の要約版が公開されました！ 2025年 DORAレポート
7. 何が起きているのか 個人の作業はめちゃくちゃ速くなった でもチーム全体のスピードは上がらない 例）AIが生成した未レビューコードの山、 AIコードの品質問題による手戻り ボトルネックを解消したのではなく、 　下流に押し流しただけ DORAレポートの知見 AIは魔法の杖ではなく増幅器 プロセスがしっかりしているチームなら AIがさらに強くする もろいチームだとカオスが広がるだけ 問題はAIというツールではなく、プロセスそのものにある AIパラドックスの構造
8. ツールの導入だけではなく、技術的・文化的な環境への投資が必要 AI 投資の最大の成果は、ツール自体からではなく、基盤となる組織システム（内部プラットフォーム の質、ワークフローの明確さ、チームの連携）に戦略的に焦点を当てることで得られる AIは増幅器である 引用元: DORA 2025 AI Capabilities Model report
9. Clear and communicated AI stance AIがアクセス可能な 内部データ AI-accessible internal data AIが内部ドキュメントやコー ドベースに接続し、組織固有 のコンテキストを理解できる AI導入成果を増幅する7つのケイパビリティ 小さなバッチ単位の作業 Working in small batches 変更を小さな単位に分割し、AIの大量生成 リスクに対抗して、迅速なフィードバック を可能にする ユーザー中心の視点 User-centric focus 正しい方向に速く進むために不可欠。欠如 するとAI導入がパフォーマンスを悪化させ る 質の高い内部プラットフォーム Quality Internal Platforms 自動化された安全な経路を提供し、AIの恩 恵を組織全体にスケールさせるための標準 化されたツールと基盤 明確で周知された AIスタンス AI利用の明確なポリシーと期 待値について組織の公式な見 解が周知されている 健全なデータエコシステム Healthy data ecosystems 高品質でアクセスしやすい統 合データ基盤 優れたバージョン管理プ ラクティス Strong version control practices AIが変更の速度を上げる中、 成熟したバージョン管理が心 理的なセーフティネット 引用元: DORA 2025 AI Capabilities Model report
10. ケイパビリティと成果の相関モデル 引用元: DORA 2025 State of AI-assisted Software Development report
11. 実践現場での気づき
12. DORA AIケイパビリティ だけでは上手くいなかった
13. なぜ1人では速いのにチームでは遅いのか 取り組んだ内容（2025年10月〜2026年3月） 開発体制 立ち上げ期：1名のみ プロジェクト中盤：計4名に増員 DORA AIケイパビリティの強化 明確で周知されたAIスタンス　→　具体的なAIユースケースを明確にして期待値を共有 小さなバッチ単位の作業　→　作業単位の見直し 質の高い内部プラットフォーム　→　プラットフォームエンジニアリング観点で整備 健全なデータエコシステム　→　データを戦略的資産として扱うまで昇華できなかった ユーザー中心の視点　→　チーム全体の視点を引き上げるのは難しかった AIがアクセス可能な内部データ　→　仕様書のマークダウン化（躓いたポイントは後半で紹介） 1人の場合はリードタイムを短縮できたが、開発者の人数が増えた途端にチームのリードタイムは遅くなった
14. なぜ1人では速いのにチームでは遅いのか 個人の考察 1人でAIを使うとき プロンプト→生成→確認→修正 ループが自分の頭の中で完結 バリューストリームに「待ち」がない コンテキストの引き継ぎゼロ 2人以上になった瞬間 「AIが書いたコードを別の人がレビュー」 が発生 引き継ぎ・手待ちが一気に出現 未レビューコードの山が積み上がる 工程間の「待ち」がリードタイムを支配 → 高いパフォーマンス → AIパラドックスの正体はここにあった
15. 基盤となる組織のシステムに目を向ける AI投資の最大の成果は、ツールではなく基盤となる組織の システムから 内部プラットフォームの質 ワークフローの明確さ チームの連携 ワークフローの明確さも「頑張る」のではなくシステムと して設計する AIを受け止める組織のシステムが整っていなければ効果は 出ない 引用元: DORA 2025 AI Capabilities Model report 開発の流れそのものを可視化する必要がある（バリューストリーム・マッピング）
16. バリューストリーム・マッピングとは 現状 ボトルネックの特定（手動タッチポイント、ハンドオフ） 引き継ぎによって待ち時間が5日以上発生し、 フロー効率が5.3%に低下している 理想像 ビジネスと技術的な成果を明確に理解し、定義する 引き継ぎが無い、完全に自動化されたプロセス フロー効率100％の状態 引用元: DORA 2025 AI Capabilities Model report
17. バリューストリームの起源 トヨタ生産方式――脱規模の経営をめざして 大野 耐一 (著), 1978 スクラム 仕事が４倍速くなる“世界標準”のチーム戦術 ジェフ・サザーランド (著), 2015 LeanとDevOpsの科学 Nicole Forsgren Ph.D., Jez Humble, Gene Kim (著), 2018 リーン開発の本質 Mary Poppendieck, Tom Poppendieck (著), 2008
18. 1 未完成の作業（在庫） AIが生成した未レビューコードの山、作ったけどまだ誰も見ていない 2 作りすぎ（過剰生産） AIが速いからと不要な機能まで量産、顧客が求めていないものを速く作る 3 不良（手戻り） AI生成コードの品質問題、動くけど仕様と違う・性能が出ない 4 タスク切り替え 効率化によるマルチタスクのコンテキストスイッチ、人間の集中力が分断される 5 引き継ぎ（情報ロス） 開発者↔AI↔レビュアーの意図伝達コスト、コンテキストが失われる 6 再学習 AI生成コードの理解コスト、書いていないコードの理解は数倍かかる 7 手待ち（待機時間） レビュー待ち、承認待ちの時間。AIがどれだけ速くても変わらない 7つのムダ（AI時代の再解釈） AI時代に意識すべきボトルネック
19. まず動かす そこから仕様を生む 軽量な仕様書とDORA AI ケイパビリティで実現する 動くソフトウェアを中心とした開発ライフサイクル
20. 動くソフトウェアを中心とした開発ライフサイクル モックアップ→プロトタイプ Figma + AIでプロトタイプ作成 評価ゲート プロトタイプ品質レビュー 仕様書作成 コードから逆生成して整備 製品版実装 GitLab + AIでDevSecOps実践 「合意してから作る」から「動かしながら合意する」へ、動くソフトウェアを中心とした開発ライフサイクル (SDLC centered on working software) として品質を担保。この反復可能なプロセスにより、AI による高速開発と人間によるレビューのバランスを実現。 動くソフトウェアで合意形成 人間が設計意図を補完 プロトタイプ 製品版実装
21. 顧客満足を最優先し、価値のあるソフト ウェアを早く継続的に提供します。 動くソフトウェアこそが進捗の最も重要 な尺度です。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限 にすること）が本質です。 アジャイル宣言の背後にある原則 より引用 アジャイル宣言からの学び
22. 再掲：実践現場での気づき 開発体制 立ち上げ期：1名のみ プロジェクト中盤：計4名に増員 DORA AIケイパビリティの強化 明確で周知されたAIスタンス　→　具体的なAIユースケースを明確にして期待値を共有 小さなバッチ単位の作業　→　作業単位の見直し 質の高い内部プラットフォーム　→　プラットフォームエンジニアリング観点で整備 健全なデータエコシステム　→　データを戦略的資産として扱うまで昇華できなかった ユーザー中心の視点　→　チーム全体の視点を引き上げるのは難しかった AIがアクセス可能な内部データ　→　仕様書のマークダウン化（躓いたポイントは後半で紹介） 取り組んだ内容（2025年10月〜2026年3月）
23. ユーザー中心の視点を持たない チームでは、AI導入がむしろ パフォーマンスを悪化させる 引用元: DORA 2025 AI Capabilities Model report
24. なぜプロトタイプ起点が効くのか 「AIに丸投げ」ではなく、人間がUI/UXの設計意図を持った上でAIにコーディングを任せる分業が鍵 従来 レビュアーは静的な仕様書を読んで、頭の中で 動作を想像しなければならない 判断に時間がかかり、曖昧な承認（ 「多分これ でいいと思う」 ）になりやすい プロトタイプ起点 動くソフトウェアを先に作ることで、レビュー の対象が「文書」から「動くもの」に レビュアーは触って直感的に判断できる。5分 で「ここが違う」と具体的に言える → 開発の流れの中に「仕様書レビュー待ち」が構 造的に埋め込まれていた → フィードバックの質が上がり、手戻りが減 り、承認待ちの滞留が消える 仕様書 → レビュー → AI実装 → 確認 プロトタイプ with AI → 評価ゲート → 仕様書 生成 with AI → 製品版実装 with AI
25. 仕様書の軽量運用
26. 形骸化しないドキュメントの3条件 1 軽量性 必要最小限、分厚い仕様書はAI時代の負債 2 最新性 コードと常に同期、コードが変われば仕様も追従 3 実用性 AIと人間どちらも読めるフォーマット。次の実装のインプットになる コーディング = ロジック思考 + ドキュメンテーション 先にコードを書いて（= 思考して） 、そこから仕様を抽出する方が思考の自然な流れに沿っている
27. プロトタイプのコードから仕様書を逆生成 プロトタイプのコードをもとに、AIが仕様書 を自動生成 人間は「考慮漏れ」や「整合性の確認」など レビューに集中 ドキュメント作成にかかる負担を大幅に軽減 AGENTS.md による 軽量ドキュメンテーション → 仕様書を軽量にすることで、形骸化されていな いドキュメントで運用できる
28. 逆生成の実験と限界 成果 社内2ヶ月間プロジェクトで計測 プロトタイプからAIに仕様書を自動生成 ドキュメント工数 55% 削減 限界（AIが拾えなかったもの） 設計意図（なぜこの実装を選んだか） ビジネスルールの背景 非機能要件 逆生成はあくまで「たたき台」 人間が設計意図（目的や制約など）を補 完する工程が不可欠 モックアップ→プロトタイプ Figma + AIでプロトタイプ作成 評価ゲート プロトタイプ品質レビュー 仕様書作成 コードから逆生成して整備 製品版実装 GitLab + AIでDevSecOps実践 動くソフトウェアで合意形成 人間が設計意図を補完 プロトタイプ 製品版実装
29. 実践事例: 90%以上を AI がコーディング 90% AI コーディング率 AIによる自動実装 70% 開発期間短縮 従来プロセスとの比較 55% ドキュメント工数削減 自動生成による効率化 技術スタック デザイン: Figma Make でモックアップ作成 AIプラットフォーム: GitLab Duo Agent Platform 仕様書管理: AGENTS.md による軽量ドキュメント CI/CD: GitLab Pipeline with DevSecOps 人間の役割 1.プロトタイプレビューと UI/UX 判断 2.仕様書の考慮漏れチェック 3.評価ゲートでの品質検証 4.アーキテクチャ上の重要な意思決定
30. まとめ
31. まとめ 1 AIパラドックスとDORA AIケイパビリティ AIを入れても速くならない構造的な理由と解決するための能力 2 実践現場での気づき チームのリードタイムが短縮できないのはなぜ？ 3 バリューストリームで考える 開発の流れを可視化してボトルネックの正体を知る 4 まず動かす、そこから仕様を生む 順序を逆転させた4ステップフロー 5 仕様書の軽量運用 AIによる逆生成でドキュメント工数削減
32. さいごに
33. 告知 来週 4/21(火) 12:00-13:00 ウェビナーがあります！ 登録はこちら ↓
34. ご清聴有難うございました