---
title: AI駆動開発の「便利」を、組織の成果に変えるためには - 個別活用の先にある、開発基盤・人材・組織の課題
tags:  #graat #ai駆動開発  
author: [Graat](https://image.docswell.com/user/graat)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LJ1RV9WKJG.jpg?width=480
description: 2026年11月10日に開催したGraat主催「エンタープライズDXセミナー」の講演「AI駆動開発の「便利」を、組織の成果に変えるためには」の資料です。 https://www.graat.co.jp/blogs/cmv8xtcd08hot07zszoc55lgk/ https://event.graat.co.jp/aidriven-seisanseinikaeru
published: November 10, 26
canonical: https://image.docswell.com/s/graat/K27691-edx202611_add
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LJ1RV9WKJG.jpg)

エンタープライズDXセミナー
AI駆動開発の「便利」を、
組織の成果に変えるためには
個別活用の先にある、開発基盤・人材・組織の課題
2026/11/10


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GJW1LQ6PE2.jpg)

組織とチームを”仕組み”でつなぎ、エンタープライズDXを実現する


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4EZPMWY6J3.jpg)

自己紹介
鈴木雄介
• Graat（グラーツ）
» 正式名称：グロース・アーキテクチャ＆チームス(株)
» 代表取締役社長
• (株)アイムデジタルラボ
» 三越伊勢丹グループ DX推進機能子会社
» 取締役
• JACK
» 正式名称：ジャパンアジャイルコラボレーションカーネル
» 代表理事
• 日本Javaユーザーグループ
» 社団法人CCC協会 代表理事
• SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
2


# Page. 4

![Page Image](https://bcdn.docswell.com/page/Y76MNGDLEV.jpg)

アジェンダ
AI駆動開発とは
組織とAI駆動開発
• 組織とハーネス
• 組織と人材
• チームの成熟
• SDLCとAI駆動開発
• 組織の意思決定
まとめ
3


# Page. 5

![Page Image](https://bcdn.docswell.com/page/G75Z5V3MJ4.jpg)

AI駆動開発とは


# Page. 6

![Page Image](https://bcdn.docswell.com/page/9J2RN3ZR7R.jpg)

AI駆動開発とは
AIエージェントとは
• AIモデルとAIハーネスを組み合わせたもの
» AIモデル：LLMなど、入力に基づいて確率的に推論・生成を行う
» AIハーネス：特定の目的・組織・業務に合わせて望ましい形で働かせるために
、その周囲に設計・維持する仕組みと設定の総体
• ソフトウェア開発に特化したのがコーディングエージェント
AIモデル
AIハーネス
＋
AIエージェント
＝
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/DEYDP1R5EM.jpg)

AI駆動開発とは
AIエージェントが得意なこと
• 言語・記号操作として実行可能であること
» 失敗許容性：AIが間違えても捨てられる、戻せる、再試行できるか
» 検証可能性：AI生成物の良否・正誤を、生成とは独立して判定できるか
» 現時点で人間を超えつつあるといわれる分野
▸ ハッキング・脆弱性探索：大量に失敗しても一度だけ成功すればいい
▸ 数学・定理証明：膨大な証明経路を探索し、形式検証で正誤を判定できる
▸ 100m走：フィジカルとして計測と改善が可能
▸ 将棋：特定のルールの中で勝負を決めることができる
• プログラミングも比較的得意だが、人間の判断は必要
» 過去の膨大な学習素材、外部検証性の高さなど
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJN652D4J8.jpg)

AI駆動開発とは
AI駆動開発の現在位置
• 仕様駆動開発(Spec-driven Development /SDD)
» ビジネス要求を人間とAIで分析してSpecに具体化し、そのSpecを基準にAIが
設計・実装計画を立て、実装・検証まで進める開発手法
▸ 良いSpec：要求が明示的・構造的に表現され、人間とAIの双方が同じ意味として解釈できる
✓ 従来の「良い仕様書」と本質的には同じものだが、AIにとって読みやすいことが重要
計画の立案
AIと要求分析
ビジネス要求の理解
評価と調整
生成
Spec
(仕様)
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YE9LY1G473.jpg)

AI駆動開発とは
ハーネスの整備が重要
• Spec：今回、何を作りたいか
• AIハーネス：毎回、どんなやり方・制約の中で生成させるか
» ハーネスが適切にメンテナンスされていないと適切な生成物にはならない
1.エンジニアリング規約
コーディングルール、命名、エ
ラー処理、ログ、テスト規約、API
規約
2. 業務・システム知識
ドメイン知識、既存仕様、既存シ
ステム知識、用語、データの意味
3.開発プロセス・作業方法
調査→計画→実装→テスト→レ
ビュー、デバッグ手順、レビュー
方法、Skills / Runbooks
4.アーキテクチャ
システムアーキテクチャ、モ
ジュール境界、依存方向、設計パ
ターン、技術スタック
5.ガードレール
利用可能ツール、アクセス権、編
集禁止領域、セキュリティポリ
シー、データ境界、操作上限
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GE8X64VVJD.jpg)

AI駆動開発とは
ハーネスエンジニアリング
• AIエージェントを、意図した品質・制約・進め方で安定して働かせ
るために、ハーネスを設計・調整・改善すること
• ハーネスがチームや組織の資産となる（多少は製品依存するが）
AIプロダクトベンダー
ハーネス基盤の購入
Anthropic、OpenAI…
Claude Code、Codex
AIモデルの選択と、
ハーネスの組み上げ
どんな道のり
なのか
誰が乗るのか
どんな特性の
馬なのか
前回の実行結果
からの改善は？
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LEL8965R7R.jpg)

AI駆動開発とは
ハーネス整備のトレードオフ
• ハーネス整備のトレードオフ
» メリット：生成物の修正やレビューが減る、複雑な
ことも任せられるようになる
» デメリット：既存コードの整理、暗黙知の文書整備
、ハーネスの維持管理…
• 段階的に整備はしていける
» 完璧に整備しなくても、十分に便利。ただし、人間
のレビューは必須
» (いつも通り)用法と容量を守って適切に使うべし
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4JM6Z53PEW.jpg)

AI駆動開発とは
AI駆動開発とアジャイル
• アジャイルソフトウェア開発宣言(2001)
» プロセスやツールよりも個人との対話を、
» 包括的なドキュメントよりも動くソフトウェアを、
• 価値を実現するための手段が変わった
» AIをチームメンバーにするためには、プロセスやツ
ール・ドキュメントの意味が相対的に高まった
» 価値あるプロダクトを作る、ことに変わりはない
▸ AIを使って開発をすることを目的にしてはならない
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/PJRP63QYE9.jpg)

AI駆動開発で何が変わるのか


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PEX3M454JX.jpg)

AI駆動開発で何が変わるのか
クラウド、DevOps、プラットフォーム 1/2
• クラウド(2006)による仮想化がインフラ作業を自動化した
• DevOps(2009)：開発者が運用まで実施するようになる
» インフラ作業も運用作業も自動化ツールと設定ファイルに置き換えられた
• プラットフォームエンジニアリング(2021)
» マイクロサービス（2014)の影響による行き過ぎた個別最適の反省
▸ PaaSの普及により個別サービスごとにインフラ整備や運用が可能に
▸ 一方で、全社視点での効率化、統制、保守性の観点では負の遺産に
» 全社共有基盤を整備し、その上で個別システムの仕組みを整備する
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/3EKYGZ6PJD.jpg)

AI駆動開発で何が変わるのか
クラウド、DevOps、プラットフォーム 2/2
• 全社視点で運用基盤を整理する職種の登場
» プラットフォームエンジニア：開発者向け開発・運用基盤を整備する役割
» SRE：本番サービスの信頼性を維持するための基盤整備と判断する役割
運用監視
設計
実装
ビルド
デプロイ
インフラ構築
監視ツール
(オブザーバビリティ)
設計
実装
CI/CDツール
プラットフォームエンジニア
SRE
IaCツール
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/L739ND6475.jpg)

AI駆動開発で何が変わるのか
AI駆動開発による変化
• 手作業による設計と実装を不要にした
» 設計から実装の流れが「人間＋AIエージェント」に置き換えられる
• AI駆動開発エンジニアとAI基盤エンジニアという職種が登場する
※職種名は揺れているので、今後、一般化されるものは違うかも
設計
実装
AI駆動開発エンジニア
AI基盤エンジニア
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/87DGWPV57G.jpg)

AI駆動開発で何が変わるのか
補足：AI駆動開発で登場する職種
• どちらもハーネスエンジニアリングには関わる
» 外側(共通)のハーネスと内側(個別)のハーネス
AI基盤エンジニア
AI駆動開発エンジニア
主目的
AI駆動開発の共通基盤を整備する
AIを使ってプロダクトを開発する
主な仕事
コーディングエージェント環境、共通 要求分析、設計、AIによる実装、検証、
ツール、権限、ガードレール、知識基 レビュー
盤、標準設定などの設計・運用
対象
開発環境・開発基盤
対象ハーネス
組織・チーム共通部分を整備・改善す プロジェクト固有部分を開発の中で整
る
備・改善する
一言で
AI駆動開発の土台を作る人
プロダクト・サービス
AIを使って実際に開発する人
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/VJP39NVDE8.jpg)

組織とAI駆動開発
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/2EV4MKZGJQ.jpg)

組織とAI駆動開発
• 組織とハーネス
• 組織と人材
• チームの成熟
• SDLCとAI駆動開発
• 組織の意思決定


# Page. 20

![Page Image](https://bcdn.docswell.com/page/57G1GQMDEL.jpg)

組織とAI駆動開発
組織とハーネス


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4EQDXKRXJP.jpg)

組織とハーネス
AIモデルは競争力にならない
• 汎用AIモデルは、企業固有の持続的な競争優位になりにくい
» お金さえ出せば競合他社も同じモデルを使える
» モデル性能差は時間とともに縮まりやすい
» 持続的に競争力になるのは、AIモデルの扱い方
▸ AIに何をさせるか、どのような制約やルールの中で動かすか、実行結果からどう学ぶか…
▸ むしろ、安いAIモデルを使いこなすことのほうが価値が出るかも
＜
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/KJ4Z6P8271.jpg)

組織とハーネス
ハーネスは「資本」になりえる
• 資本：将来の生産や価値創出に使える蓄積物
» 資本を所有し、そこから利益や価値を生み、その利益を
さらに再投資して資本を増やしていく
» 金融資本、物的資本、人的資本、知的資本…
• 「トークン資本」 by サティア・ナデラ
» 企業が自ら構築し、所有するAI能力
▸ 企業固有の知識・判断・評価基準・仕事の進め方などを、
AIが利用できる形で資産化したもの
» AI駆動開発では広義のハーネスにあたる
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LE1RV92KEG.jpg)

組織とハーネス
トークン資本は人的資本から生まれる
• 人的資本：人の中にある知識、判断基準、関係性、
創意工夫、パターン
» 人の中の暗黙知を、AIが利用できる形に変換する
• 「学びのループ」を回す
» 暗黙知を形式化する
» 既存のハーネスに組み込んで、AIが利用できるようにする
» それを実際に利用してみて学びを得る
» その結果を、新たな形式知としてAIに組み込む
• 人的資本とトークン資本は複利的に増える
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GEW1LQRP72.jpg)

組織とハーネス
ハーネスは「負債」にもなりえる
• 何度も来た道ですよね
» 統制されない資産は、陳腐化し、維持コストが増加し、
リスクを生み、容易に負債となる
▸ レガシーシステム、技術的負債…
• AIのセキュリティリスク
» プロンプトインジェクション
» サプライチェーンアタック
» 過度な権限委譲
• とはいえ、過度な抑制は時代遅れになる危険
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/47ZPMWR6E3.jpg)

組織とハーネス
ハーネスのプラットフォーム化
• 現時点で実証が進んでおり、今後、重要になっていく
» どこまで共通化すべきかは、まだ曖昧
» まずは統制（セキュリティ、認証、認可、監視、承認など）が中心
» ツール間の標準化、チーム同士の共有方法などは急速に整備が進んでいる
» 1年後ぐらいを目指して準備をしているといいかも？
特定のシステムに依存する部分
個別ハーネス
AI駆動開発エンジニア
企業として共通する部分
共通ハーネス
ツール
ハーネス
AI基盤エンジニア
コーディングエージェント基盤が提供する部分
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/YJ6MNGRL7V.jpg)

組織とAI駆動開発
組織と人材


# Page. 27

![Page Image](https://bcdn.docswell.com/page/GJ5Z5V8ME4.jpg)

組織と人材
AI駆動開発は、どんな人材をブーストするのか？
ビジネス理解度
ビジネスは理解している
ビジネスも技術も理解している
事業会社のIT企画
ドメイン特化コンサル
デジタルサービス開発など
→AI基盤エンジニアが用意した
基盤の上で実装をしていく
→AI駆動開発でx10
技術理解度
ジュニア人材
技術は理解している
ビジネス理解も技術理解もこれから
SIerのエンジニア
→AIによって育成の機会を奪われた
→短期的にはいいけど、
長期的には移行していく必要あり
※定型化した業務であればジュニア人材の生産性を底上げをして、熟練者の生産性を下げるという研究もあります
https://www.nber.org/digest/20236/measuring-productivity-impact-generative-ai
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/9E2RN3KRJR.jpg)

組織と人材
AIがもたらす人材育成の問題
• ワークスロップ問題
» それっぽいが、実際には役に立たないAI生成物
▸ 企業では半数近くの人が受け取った経験がある
▸ 他の誰かが修正作業をすることで組織としての生産性が低下する
» 成果物に対する適切な理解と知識がなければAIを使いこなせない
• 成果物に習熟する機会をAIが奪っている
» 成果を生み出すプロセスそのものが、人材を育成する仕組みになっていた
▸ AIは過去の知的成果物から、いきなり成果を出してしまう
» AIがいきなり成果を出してしまうと、その意味を理解することをサボりがち
▸ 実はジュニア人材だけの問題ではないかもしれない
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/D7YDP1N57M.jpg)

組織と人材
熟練者とジュニア人材とAI
• 仮説：AIを通じて育成を加速できるのは？
» 熟練者の「仕事の仕方」をAIエージェントに埋め込む
» ジュニア人材がAIエージェントを使って実践
▸ そこでジュニア人材は実践知を得る
▸ わからないことは熟練者に聞くことで「暗黙知」を認識する
AIハーネス
AIモデル
» 人の代替ではなく、人を拡張する使い方
• 事例：要件定義支援エージェント
» 要件定義工程を支援するためのシステム
▸ au PAY開発を支える、EBAADによるAIエージェント活用
✓ https://www.graat.co.jp/case-study/ebaad-aupay
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VEN652X4E8.jpg)

組織とAI駆動開発
チームの成熟


# Page. 31

![Page Image](https://bcdn.docswell.com/page/Y79LY184J3.jpg)

チームの成熟
AI組織定着指標とは
• 各チームおけるAIの定着レベルを指標化したもの
• 各部署によって目指すべきレベルは異なって良い
» 既存システムとの適合性、メンバーのスキル、案件状況など
» 大事なことは「チームとして成果を出す」という視点の共有
• 使い方としては、
» 定着レベルを理解する
» 現在位置を認識合わせする
» 今後の目標を合意する
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/G78X648VED.jpg)

チームの成熟
AI組織定着指標の観点
観点
説明文
具体的な指標例
AX後業務プロセスの定義有無、新プロ
AX後に目指す業務の姿を基準として、
セスへの移行率、AI前提で見直した業
現状の業務がその姿に向けて移行・変
AX推進
務工程数、AI活用を前提に変更された
化できているかを確認する。
役割・手順の数
開発環境、AIエージェントのコンテキ
開発環境理解率、コンテキスト情報整
AIハーネスの スト情報、Skillsなど、AI活用を支える 備率、Skills整備・納品数、再利用可能
要素がKDDIの資産として整備・継承さ な資産として管理されている構成要素
資産化
れているかを確認する。
数
AIハーネスを継続的に管理するための
管理プロセス定義有無、管理対象一覧
AIハーネスの プロセスが明示され、その管理にKDDI 整備率、更新手順整備率、KDDI関与タ
管理プロセス が主体的に関与できる状態になってい スク比率、定例レビュー実施率、変更
るかを確認する。
管理ルール適用率
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/L7L896RRJR.jpg)

チームの成熟
AI組織定着指標のレベル
Lv
名称
主導者
AX推進
改善対象
業務見直し
AIハーネスの AIハーネスの
資産化
管理プロセス
1 個人試行
-
個人作業
-
なし
なし
2 個人定常利用
個人
個人作業
-
個人
なし
3 チーム業務活用 個人
チーム作業
-
チーム
個人
4 部署内試行
チーム
部署業務
あり/試行
チーム
チーム(一部)
5 部署標準化
部署
部署業務
あり
部署
部署
6 部署間連携
会社
部署横断業務 部署横断
部署
部署
7 組織定着
会社
全社横断業務 全社横断
部署
部署
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/4EM6Z5RP7W.jpg)

チームの成熟
AI組織定着指標の管理例
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/PERP63RY79.jpg)

組織とAI駆動開発
SDLCとAI駆動開発


# Page. 36

![Page Image](https://bcdn.docswell.com/page/P7X3M4R4EX.jpg)

SDLCとAI駆動開発
開発工程とAIの活用
• AI-DLC（AI-Driven Development Lifecycle）
» AWSが代表的で、手法として公開している
▸ AI Powered Execution with Human Oversight：AIが計画・作業・提案を主導し、人間が重
要な意思決定と監督を行う。
▸ Dynamic Team Collaboration：関係者がその場に集まり、AIの提案を検証しながら、部門
や役割を横断して意思決定する。
» 小さく、自律的で、開発対象を自分たちでコントロールできる組織向け
• エンタープライズでの適用には限界がある
» 複雑なシステム間連携、組織横断の合意形成、品質保証、人間の責任など
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/37KYGZRPED.jpg)

前提/制約
SDLCとAI駆動開発
AIハーネスに織り込む
工程に合わせた専門AIの登場
要求
ﾁｹｯﾄ
人とAIが共同で整理 AIが生成し、人間がレビュー
企画
業務テスト
企画書
要求整理
プロダクト特性
ドメインナレッジ
要求
品質保証支援AI
要件定義
要件定義支援AI
受入テスト
組織品質要求
テストポリシー
マスターテスト計画
システムテスト
ﾁｹｯﾄ
ﾃｽﾄ要求
IF設計
コーディング関連
既存の仕様書
Spec
ﾃｽﾄ戦略
詳細設計
コーディング
エージェント
Code
結合テスト
単体テスト
実装
ユニットテスト
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/LJ39ND84J5.jpg)

組織とAI駆動開発
組織の意思決定


# Page. 39

![Page Image](https://bcdn.docswell.com/page/8JDGWPM5JG.jpg)

組織の意思決定
チームの成果を組織の成果にする
• チームの実装だけが早くなっても、
業務
設計
組織の価値創出サイクルは早くならない
• ボトルネックが移動するだけ
» ビジネス側：企画、業務の変更…
» IT側：品質保証…
• これもいつか来た道
企画
実装
運用
» アジャイル、クラウド、マイクロサービス…
» AI駆動開発は、さらにギャップを拡大する
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/VEP39NRD78.jpg)

組織の構造とプロセス
チームと組織の関係を変える
意思
決定者
• チームの外側を整える
» 横と縦のリズムがあっていないことが問題
» 大組織で現場への権限移譲は非現実的
▸ むしろ、チームが欲しいタイミングで組織が意識
決定できるプロセスを作るほうがよい
顧客/
ﾕｰｻﾞｰ
変革
リーダー
開発
チーム
• 組織的意思決定プロセスを設計する
» 部門を超えてプロセスを可視化する
▸ 他部門の問題に興味を持つ
▸ 全員にとって効率的な方法を考えることはできる
▸ 現状の中で始めて、段階的にルールを変えていく
社内
社内
社内
関係部署
関係部署
関係部署
資料公開：エンタープライズDXセミナー：アジャイル導入が止まる3つの壁 ―― 文化・他部門・組織プロセスをどう乗り越えるか
https://www.graat.co.jp/blogs/cmkm2hbh4avkr07128zz9ua7x
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/27V4MKRGEQ.jpg)

まとめ
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/5JG1GQ6D7L.jpg)

まとめ
AI駆動開発の現在
• AIエージェント＝AIモデル＋AIハーネス
• 仕様駆動開発
» エンジニアが、ビジネス要求を理解した上で、AIエージェントと一緒にSpecを
作り、計画＋実装をさせながら、評価と調整を行う
• ハーネスの整備が重要になる（ハーネスエンジニアリング）
» ハーネス整備にはトレードオフがある
▸ 整備によって良くなる部分と、整備のコストのバランス
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/47QDXK4XEP.jpg)

まとめ
AI駆動開発がもたらす変化
• 過去に起きたことがAI駆動開発でも起きる
» 要求から実装までの極端な効率化
» AI基盤エンジニア：AI駆動開発の共通基盤を整備する
» AI駆動開発エンジニア：その基盤を使ってプロダクトを開発する
運用監視
設計
実装
ビルド
デプロイ
インフラ構築
AI駆動開発エンジニア
AI基盤エンジニア
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/KE4Z6PQ2J1.jpg)

まとめ
組織とAI駆動開発
• ハーネスは「資本」にも「負債」にもなる
» ハーネスを維持できなければ、負債になり、誰も使わなくなる
» ハーネスのプラットフォーム化が進んでいく
• AIが人材育成の機会を奪っている
» 成果を作る過程が成長の機会だったが、AIがいきなり成果を作ってしまう
» AIを利用して育成を高速化をしていくべき
• AIによる新たな合理性に組織全体を適応させる必要がある
» AI駆動開発で実装が早くなっても、組織の価値提供は早くならない
» 部門を横断して、組織的な意思決定プロセスを設計する必要がある
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/L71RV9PK7G.jpg)

さいごに
AI時代に適応する
• 今日の講演は「AI時代の自社を考える視点の提供」にとどまる
» どのように適応するのかは企業によって違う
• 「我々は何を変えるのか？」という議論へ進んでほしい
» どんな価値創出を実現したいのか
» どの業務に、どうAIを使うのか・使わないのか
» どんな判断基準が重要なのか
» どう組織構造やプロセスを変えなくてはならないのか
45


# Page. 46

![Page Image](https://bcdn.docswell.com/page/G7W1LQ2PJ2.jpg)

クロージング
46


# Page. 47

![Page Image](https://bcdn.docswell.com/page/4JZPMWD673.jpg)

会社概要
略称
Graat（グラーツ）
正式名称
グロース・アーキテクチャ＆チームス株式会社
Growth Architectures &amp; Teams, Inc.
設立日
2018年11月1日
資本金
1,000万円（2020年9月）
代表者および経営陣 代表取締役社長 鈴木 雄介
取締役 渡邉 伸一
取締役 飯沼 克哲
取締役 北村 武明
住所
〒163-0524
東京都新宿区西新宿1-26-2
新宿野村ビル48階
ホームページ
https://www.graat.co.jp/
社員数
12名（役員除く）※2025年9月現在
事業内容
エンタープライズDX推進支援事業
売上高
397百万円
親会社
グロースエクスパートナーズ株式会社（東証グロース244A）
https://www.gxp-group.co.jp/
※2025年8月期実績
47


# Page. 48

![Page Image](https://bcdn.docswell.com/page/YE6MNG1LJV.jpg)

考え方
なぜDXは進まないのか？
意思
決定者
• チームと組織がつながっていない
» 横：チーム視点で開発を進めても、組織内で
合意されていなければ成果につながらない
» 縦：組織内調整ばかりしていても、良いプロ
ダクトが作れず、成果につながらない
• では、どうすべきか？
» 必要なのは権限移譲ではなく、組織とチーム
の関わり方を設計すること
» 個人に依存しない形で、組織とチームをつな
ぐための仕組みづくりをする
» 価値の設計から実現までを、様々な立場や役
割をこえて1つの流れにしていく
説明責任
価値設計
顧客/
ﾕｰｻﾞｰ
開発調整
DX
リーダー
開発
チーム
業務調整
社内
社内
社内
関係部署
関係部署
関係部署
48


# Page. 49

![Page Image](https://bcdn.docswell.com/page/GE5Z5V4M74.jpg)

Graatの実践
チームサイクルと組織サイクルをつなぐ
サービスデザイン
調整
チーム
サイクル
組織
サイクル
合意
設計
価値定義
監視
実装
評価
組織プロセス
設計
アジャイル
マネジメント
デリバリ
受入
継続的品質保証
検証
49


# Page. 50

![Page Image](https://bcdn.docswell.com/page/972RN3VRER.jpg)

Graatの実践
部門横断のコミュニケーション
サービスデザイン
• ①サービスデザイン
» 顧客の視点、業務のオペレーション、ITの仕組
みの関係性を可視化する
▸ その中に目的に向けて、必要なすべての部署と関係者を
含んで記載する
▸ それぞれの部署の目線を合わせていく
50


# Page. 51

![Page Image](https://bcdn.docswell.com/page/DJYDP135JM.jpg)

Graatの実践
段階的に改善していく
• ②アジャイルマネジメント
アジャイル
マネジメント
» マネジメントの仕組みを取り込む
▸ QCD：品質、コスト、期間
✓ 品質とやるべきことを固定し、必要なコストと期間をかけ
て実現する
▸ OQS：成果、品質、スコープ
✓ 目指すべき成果を定め、品質を守りながら、やるべきこと
を調整して実現し続ける
51


# Page. 52

![Page Image](https://bcdn.docswell.com/page/V7N652V478.jpg)

Graatの実践
チームを組織をリンクする
• ③組織プロセス設計
組織プロセス
設計
» 案件の種類に応じて関係者を洗い出し、必要な
リズムを定める
▸ 「早くすること」よりも「企業が適切に合意形成する期
間」を重視する
▸ それらを重ね合わせて必要なサイクルを定める
» 組織的な意思決定とチームの実践をつなげるこ
とが双方に透明性をもたらす
複層サイクル型アジャイル手法
52


# Page. 53

![Page Image](https://bcdn.docswell.com/page/YJ9LY164E3.jpg)

Graatの実践
部門横断のコミュニケーション
• ④継続的品質保証
継続的品質保証
» 従来型品質保証
▸ 最初に決めた仕様通りに機能が動く
» 継続的品質保証
▸ 段階的な機能改善の上で、製品品質を維持する
✓ 確認済みの品質をベースラインとして維持しながら、変更
ごとに影響とリスクを評価し、必要な品質保証を選択・実
施して、新しいベースラインへ更新する
53


# Page. 54

![Page Image](https://bcdn.docswell.com/page/GJ8X64ZV7D.jpg)

組織とチームを“仕組み”でつなぎ、
エンタープライズDXを実現する
https://www.graat.co.jp/


