開発は速くなっていく。では、組織は何をすべきか？ - Enterprise Agilityが問い直す企業の動かし方

エンタープライズDXセミナー 開発は速くなっていく。では、組織は何をすべきか？ Enterprise Agilityが問い直す企業の動かし方 2026/10/6 グロース・アーキテクチャ＆チームス株式会社

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

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

• https://twitter.com/yusuke_arclamp
• http://arclamp.hatenablog.com/

アジェンダ • なぜ開発は早くならないのか • 歴史的経緯 • Enterprise Agility • Graatの考え方 • まとめ • クロージング 3

Q＆Aについて 進め方 • 適宜、会場からの質問を拾いなが ら進行します » Zoomの「Q&A機能」を使って、ぜひ 質問をしてください 4

なぜ開発は早くならないのか

なぜ開発は早くならないのか 11,500人のアジャイル変革参加者を調査 • 変革がうまくいく組織の特性 » ①学習する組織であること ▸失敗から学ぶ文化、専門性の育成、知識共有、継続的改善などの整備 ✓ 成功している組織では93％で「構造的な仕組み」が存在した » ②データを使って学習・優先順位付け・成果測定できること ▸チームの稼働や価値の測定、指標化、評価ができている » ③既存組織のやりとりがチームを阻害しないこと ▸「社内基準、リスク評価、管理要件によってリリースを遅らせる」がYESの 場合、68％がアジャイル変革に満足していない What 11,500 Employees Say About Agile Transformation - BCG https://www.bcg.com/publications/2022/what-employees-say-about-agile-transformations 6

• https://www.bcg.com/publications/2022/what-employees-say-about-agile-transformations

なぜ開発は早くならないのか チームの外側に問題がある • チームは早くなった » AI駆動開発でもっと早くなる • では、チームの外側は？ » プロダクトレベルの問題 » 企業/組織レベルの問題 企業/組織 プロダクト チーム ▸エンタープライズ では、何に取り組むべきか？ 7

歴史的経緯

歴史的経緯 アジャイル • アジャイルソフトウェア開発宣言 » 2001年に「不確実なソフトウェア開発」 の進め方として提唱 ▸長期計画、フェーズ、変更管理への懸念 » 時代背景としてのインターネット ▸いわゆるウォーターフォール型管理の限界 » 手法：Scrum、XP、Crystal、Adaptive Software Development… https://agilemanifesto.org/iso/ja/manifesto.html 9

• https://agilemanifesto.org/iso/ja/manifesto.html

歴史的経緯 大規模アジャイル • Scaling Agile手法の登場 https://less.works/ » 巨大化するサービスにおいて、複数の アジャイルチームをどうやって協調・ 整合させるか ▸2005：LeSS、2011：SAFe、2012： Disciplined Agile、2015：Nexus、2018 ：Scrum@Scale ▸チームの外側の問題にも意識的ではある が、それが主題ではない https://framework.scaledagile.com/safe-6-0-configurations https://scruminc.jp/scrum-at-scale/guide/ 10

• https://scruminc.jp/scrum-at-scale/guide/
• https://framework.scaledagile.com/safe-6-0-configurations
• https://less.works/

歴史的経緯 プロダクト思考 • 2007『INSPIRED』 » ビジネス側が「どう価値を発見するか」 ▸アジャイルを前提にするとマネージャーの責任が機 能を作ることから、成果を改善することへ ▸プロダクトマネージャー、プロダクトマネジメント » プロダクトディスカバリー ▸本当にそのプロダクトを欲しがるユーザーがいるの かを発見・検証すること ▸ユーザーの問題に対して、使えて、価値があり、実 現可能な解決策を発見すること 11

歴史的経緯 リーン • 2014『Lean Enterprise』 » 2011『Lean Startup』 ▸Build → Measure → Learn » 企業そのものが継続的に仮説検証し、学習で きる仕組みをつくる https://speakerdeck.com/jezhumble/lean-enterprise?slide=13 ▸Explore：価値を小さく仮説検証する ▸Exploit：継続的に顧客へ価値を届ける ▸Portfolio：学習結果に応じて投資を増減する ▸Organization：目的を共有した自律的チームを作る 12

• https://speakerdeck.com/jezhumble/lean-enterprise?slide=13

歴史的経緯 プロジェクトからプロダクト型 • 2018『Project to Product』 » 企業のIT投資・ソフトウェアデリバリーの 運営モデルを変える ▸継続的に価値を生み出すものを、一時的な Projectとして管理していることが問題 ▸仕事の管理単位をProjectからProduct Value Streamへ変える ▸顧客・事業にとって意味のある仕事が、Value Streamをどのように流れているかを計測する 13

歴史的経緯 プロダクト運営モデル • 2024『TRANSFORMED』 » Product Operating Model(POM)とは ▸会社がテクノロジーを使って顧客価値と事業成果を 継続的に生み出すための“組織運営モデル” ✓ 経営が事業目標を示す ✓ リーダーが「解くべき問題」を選ぶ ✓ チームが「どう解くか」を探索する ✓ 小さく継続的にデリバリする ✓ 成果を測って次の判断につなげる 14

歴史的経緯 まとめ • チームの外側に広がってきた歴史 » 開発チームが変化に適応する：Agile » 複数チームを整合させる：大規模Agile » 事業成果を目指す：プロダクト思考 » 価値の流れを意識する：リーン » 企業運営も流れを意識する：プロジェクトからプロダクト型へ » 企業運営モデルを作る：プロダクト運営モデル • エンタープライズの悩みは世界共通 15

歴史的経緯 世界の上場企業400社を調査 • POMの成熟と企業成果に強い相関がある » 成熟企業と未成熟企業で差が大きいのは以下ような項目 項目 少し詳しい説明 プロダクト・開発・ プロダクト企画部門、開発部門、運用部門が分断されず、共通の目標や優先順位のもとで 運用の連携 連携して進められているか プロダクトマネジメ 顧客ニーズや事業成果を起点に、ユーザー調査、ロードマップ策定、成果測定、意思決定 ントの実践 などを継続的に行えているか バックログの優先順 市場・顧客ニーズや事業目標を踏まえて、何を先に実行するかを明確に決め、バックログ 位付け へ反映できているか 予算配分 固定的なプロジェクト単位ではなく、優先度や成果に応じて、プロダクトや施策へ継続的 に予算・資源を振り向けられているか 技術的負債の管理 短期的な開発を優先した結果として蓄積する技術上の問題を把握し、将来の開発速度や品 質を損なわないよう計画的に解消できているか The bottom-line benefit of the product operating model https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-bottom-line-benefit-of-the-product-operating-model 16

• https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-bottom-line-benefit-of-the-product-operating-model

Enterprise Agility

Enterprise Agility Manifesto for Enterprise Agility • 2026年3月3日、PMIとAgile Allianceが共同で公開 » “This is not a rewrite — it’s an extension.” ▸アジャイル宣言の書き直しではなく、拡張 ▸https://www.pmi.org/learning/agile/manifesto-for-enterprise-agility • なぜ、今なのか » 企業に必要なのが計画遂行能力から、変化適応能力へ ▸問題は「変わらないといけない」と分かっているのに、組織、予算、意思決 定、ガバナンスが追いつかず、戦略を実行に移せないこと ▸チームがアジャイルになっても、企業全体としてアジャイルにならない 18

• https://www.pmi.org/learning/agile/manifesto-for-enterprise-agility

Enterprise Agility Enterprise Agilityとは • 企業が一貫性を失うことなく、大規模に”適応”する能力 » 素早く意思決定する » 意図的にリソースを再配分する » 現実の変化の中でも戦略を実行可能な状態に保つ • 定義されたこと » 4つの価値と9つの原則 19

Enterprise Agility 4つの価値 • Clear purpose realized through adaptive plans » 明確な目的を、適応的な計画によって実現する • Shared enterprise outcomes over functional optimization » 部門・機能別の最適化より、企業全体で共有する成果を重視する • Continuous reinvention over preservation » 現状維持より、継続的な自己変革を重視する • Human centricity amidst change » 変化の中でも、人間中心であることを重視する 20

Enterprise Agility アジャイル宣言との比較 » 明確な目的と適応型の計画 » 部門最適よりも全社最適 » 現状維持よりも継続的変革 » プロセスよりも人間中心 ▸学習、自律性、適応力、共感、信頼 変化する時代における 企業のマネジメント 不確実性が高まった状況での 開発チームのマネジメント 21

Enterprise Agility 9つの原則 • 企業のあり方 → 組織運営の仕組み → 区分 原文 Create clarity of purpose and align on Leadership enterprise outcomes Behavior リーダーシッ Expand agility across partners and ecosystems プ Embrace technology and distributed talent 現場の仕組み 日本語訳 目的を明確にし、企業全体の成果に向けて足並みをそろ える アジリティをパートナーやエコシステムにまで広げる テクノロジーと分散した人材を積極的に活用する Organization Govern with clear guardrails, not gatekeepers 承認者ではなく、明確なガードレールによって統治する Fund purpose and intent, not execution activity 実行活動ではなく、目的と意図に対して資金を配分する Design 組織設計 Design for adaptability, not just efficiency 効率性だけでなく、適応可能性を重視して設計する Execution 実行 Move authority and decision-making to where value is created 価値が生み出される場所へ、権限と意思決定を移す Deliver value frequently and make work visible 価値を頻繁に届け、仕事を可視化する Sense early, learn quickly, act with confidence 兆候を早期に捉え、素早く学び、確信を持って行動する 22

Enterprise Agility 9つの原則：企業のあり方 • 1. 目的を明確にし、企業全体の成果に向けて足並みをそろえる » 企業として何を実現したいのかを明確にし、部門や個人の目標を、その成果に結びつ ける。各組織が個別最適に陥らず、共通の目的に向かって判断できる状態をつくる • 2. アジリティをパートナーやエコシステムにまで広げる » 自社だけでなく、顧客、取引先、サプライヤーなど、価値提供に関わる外部組織との 関係も含めて変化への対応力を高める。企業内部だけを速くするのではなく、価値提 供のつながり全体を適応可能にする • 3. テクノロジーと分散した人材を積極的に活用する » AIやデータなどの技術と、社内外・地域を越えて存在する人材や専門性を活用し、企 業の能力を広げる。既存の組織や働き方にとらわれず、必要な能力を柔軟に組み合わ せる 23

Enterprise Agility 9つの原則：組織運営の仕組み • 4. 承認者による統制ではなく、明確なガードレールによって統治する » 一つひとつの判断を上位者が承認するのではなく、判断の基準や制約をあらかじめ明 確にする。その範囲内では現場が自律的に判断できるようにし、統制とスピードを両 立する。 • 5. 実行活動ではなく、目的と意図に対して資金を配分する » 個別の作業や固定された計画に予算を付けるのではなく、実現したい目的や成果に対 して投資する。状況や学習結果に応じて、資金や人材をより重要な領域へ動かせるよ うにする。 • 6. 効率性だけでなく、適応可能性を重視して設計する » 現在の業務を効率よく回すことだけを目的にせず、環境変化に応じて組織や役割、資 源配分を変えられるようにする。平常時の効率と、変化時の柔軟性の両方を組織設計 に組み込む。 24

Enterprise Agility 9つの原則：現場の仕組み • 7. 価値が生み出される場所へ、権限と意思決定を移す » 顧客や現場に近く、必要な情報を持っている人たちが判断できるようにする。意思決 定と実行の距離を短くし、変化への対応を速める。 • 8. 価値を頻繁に届け、仕事を可視化する » 大きな成果を一度に届けるのではなく、小さく価値を提供しながらフィードバックを 得る。また、進捗や課題、依存関係を見える状態にし、必要な調整を早く行えるよう にする。 • 9. 兆候を早期に捉え、素早く学び、確信を持って行動する » 顧客、市場、技術、リスクなどの変化を早い段階で捉え、得られた情報から素早く学 習する。その学習を判断につなげ、変化が大きくなる前に行動する。 25

Enterprise Agility まとめ • 変化に適応できる企業になるには？の原理原則 » アジャイルチームを増やしても、企業の適応能力は上がらない » 企業方針や組織運営が旧来のままでは無理 ▸企業そのものの意思決定、資金配分、ガバナンス、組織設計など • ただ「では、どうするの？」には答えていない » 世の中の「適応する企業」についての言説を集めて整理したもの 26

Graatの考え方

Graatの考え方 なぜ変革は進まないのか 意思 決定者 • 組織とチームのズレ » 組織の意思決定とチームの実践が 整合しない ▸チームが求めている判断スピードに対 して組織の判断が遅い ▸組織の求める判断基準がチームから上 がってこない » 権限委譲では解決しない ▸組織の中の多様な視点を、誰か一人で 決定することはできない 説明責任 価値設計 顧客/ ﾕｰｻﾞｰ 実現調整 変革 リーダー 現場 チーム 業務調整 社内 社内 社内 関係部署 関係部署 関係部署 28

Graatの考え方 構造的無能化

Graatの考え方 構造的無能化 • 構造的無能化 » 大企業では、合理的な判断で分業が進み、 業務がルーティン化している ①断片化 ②不全化 ③表層化 各部門がサイロ化し、個別最適が優先される 各部門では会社全体の環境変化を捉えきれず、 全体像が捉えられない 表層的な問題解決を繰り返し、変革を伴う全体 最適に取り組めない 「わからない」壁：何が問題なのかが決まらない 「進まない」壁 ：問題が複雑で、進め方が決まらない 「変わらない」壁：施策を示しても人や組織が動かない 企業変革のジレンマ 「構造的無能化」 はなぜ起きるのか 宇田川元一 (著) 出版社 : 日経BP 日本経済新聞出版 発売日 : 2024/6/22 30

Graatの考え方 構造的無能化 • 構造的無能化は、慢性疾患 » 急性期であれば手術するか、死ぬか » 慢性疾患は、自己調整能力の回復が必要 ▸診断能力・代謝・免疫・生活習慣を取り戻すこと ▸明確な改善効果は中長期的にしか現れない • 組織で言えば » 社員の能力が失われたわけではない » 組織が自分たちの問題を認識し、考え、調整し、 自ら変化できる状態を取り戻すこと 企業変革のジレンマ 「構造的無能化」 はなぜ起きるのか 宇田川元一 (著) 出版社 : 日経BP 日本経済新聞出版 発売日 : 2024/6/22 31

Graatの考え方 構造的無能化からの回復 • 変化に応じて自身を継続的に更新できる能力を回復する » 回復の4つのプロセス ① 全社戦略を考えられるようになる 経営が外部環境や現場の問題を踏まえて「どこへ向かうか」を考える能力を取り戻す ② 全社戦略へのコンセンサス形成 経営陣・各部門が、方向性だけでなく「自分たちの役割」を理解する ③ 部門内での変革の推進 全社戦略を現場の具体的な問題と接続し、各部門が自ら変化を起こす ④ 全社戦略・変革施策のアップデート 現場で分かったことを経営へ戻し、戦略や施策自体を修正する » 組織が自らの「思考の循環」を取り戻す ▸現場で起きている違和感を拾う → 複数の立場から見る → 背後の構造を考え る → 戦略との関係を考える → 実際に動く → 分かったことから戦略を修正 する 32

Graatの考え方 アジャイルを取り込む

アジャイルを取り込む なぜ「アジャイル」がうまくいかないのか？ » 日本に存在した方法論：『The New New Product Development Game』竹内・野中 ▸現場の人々が、(必要に応じて)部門や工程を越えて知識を持ち寄り、実践し ながら答えを作っていくことで、アジリティを実現 ✓ 前提：現場に蓄積された共通知識・人間関係・横断調整能力 » 北米に輸出された結果：Scrum ▸チームの役割と責任、イベントをルール化してアジリティを再現可能に ✓ 前提：人が変わっても対応できる職務・責任・権限による組織運営 » 逆輸入で起きること ▸「チームの役割と責任」が再現できない（組織側の役割・責任とぶつかる） 34

アジャイルを取り込む Enterprise Agilityへの向き合い方 • Enterprise Agilityの4つの価値に同意できる » 明確な目的を、適応的な計画によって実現する » 部門・機能別の最適化より、企業全体で共有する成果を重視する » 現状維持より、継続的な自己変革を重視する » 変化の中でも、人間中心であることを重視する • それを実現する9つの原則は濃淡がある 35

アジャイルを取り込む Enterprise Agilityとの向かい方 • 9つの原則への意見 区分 日本語訳 目的を明確にし、企業全体の成果に向けて足並みをそろ Leadership える Behavior リーダーシッ アジリティをパートナーやエコシステムにまで広げる プ テクノロジーと分散した人材を積極的に活用する Organization 承認者ではなく、明確なガードレールによって統治する 実行活動ではなく、目的と意図に対して資金を配分する Design 組織設計 効率性だけでなく、適応可能性を重視して設計する Execution 実行 現場から実践を変えて、後か ら組織と経営を変えていく 価値が生み出される場所へ、権限と意思決定を移す 価値を頻繁に届け、仕事を可視化する 兆候を早期に捉え、素早く学び、確信を持って行動する 小さく実践し、学びをながら、 目的や価値を具体化していく チームの成果を、組織の成果 に繋げていく チームで決められないことを 定め、必要な関係者を集めて 合意形成する 36

Graatの考え方 Graatの実践

Graatの実践 現場の実践を通じて、組織を変えていく • 対話を増やす » 「部門同士の横連携」「マネジメントと現場の縦の合意」を増やす » そのタイミングを意識的に設計する 実践ポイント 何をするのか 部門を横断した コミュニケーションを推進する 関係部門を早い段階から議論に巻き込み、それぞれが持つ事情や見方を出し合いながら、 目的や実現したい価値を具体化する 最初から完成を求めず、 段階的に改善する すべての要求を盛り込んだ完成形を待たず、まず必要な範囲を形にする。実際に使って 分かったことを取り込みながら、段階的に完成度を上げる チームの実践と 組織の判断を連動させる チームが次に進むために必要な判断は、適切なタイミングで組織として行う。実践で得 た成果や失敗も共有し、次の方針や優先順位の判断に活かす 組織／顧客の視点で チームの成果を検証する チーム内の完成判断で終わらせず、組織として受け入れられるか、顧客に期待した価値 を届けられるかを確認し、次の改善につなげる 38

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

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

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

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

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

事例 45

事例

事例 概要 • 顧客：大手ゼネコン • 状況 » 建設業務を支える業務システム群（数十個）を見直していきたい » 要件調整の相手は複数部門に跨るので、スピード感を持って調整し ていきたい • 解決の方向 » プラットフォーム型開発と組織プロセスの整備 レポート：パネルディスカッション－大成建設：8000社／9万人が利用する業務システム群における開発サイクルについて https://www.graat.co.jp/blogs/cm7d2izyt6nxo07zm0569ed49/ 47

• https://www.graat.co.jp/blogs/cm7d2izyt6nxo07zm0569ed49/

事例紹介 プラットフォーム型開発 社内外のユーザー • 建設業務に関わる業務システム群を開発 ・統合するデータ管理プラットフォーム » 2019年 検討開始、2020年 開発開始、2021 年運用開始し、段階的に機能拡充中 » 現在、15システムがプラットフォーム上で開 発され、15の外部システムと連携中。全体の ユーザー数は8000社/9万人 » 認証認可の統合、フルクラウド、業務システ ムに必要な共通機能の提供など Ａ サービス B サービス SaaS D 運用 管理 データ ベース 共通 機能 システム運用担当者 48

事例紹介 組織プロセスについて • 2024年より協議会制に移行 » プラットフォーム上の案件が、様々な部署からの同時並行で発生す る状況になってきたため、管理を一元化するために協議会を設置 ▸スクラムガイドとしてはアンチパターン » 3ヶ月おきに案件を取りまとめ、3ヶ月検討、その後の開発 部内要件整理 建築/設計 土木 全体調整 協議会 案件管理 開発管理 開発実施 情報企画 システム 子会社 ベンダー① ベンダー② 調達本部 ベンダー③ 子会社 ※スクラムで実施 49

事例紹介 協議会の実施プロセス例 3月 1週 マイルストーン 各事業本部 協議会 情報企画部 2週 3週 4週 4月 1週 2週 3週 4週 5月 1週 夏季 休暇 3週 案件会議 2週 3週 4週 ★案件確定・見積承認 ★要望受付期限 ★要望 ★業務要件完成 ★案件候補選定 （7月検討対象） 受付開始 ★案件候補確定 ★案件起案 ★実施承認 ★検討対象決定 要望シート 記入 稟議 業務要件 仕様調整 承認 取りまとめ 要望シート 検討 準備 見積調整 ★協議会 ★協議会 対象 ★協議会 （案件候補決定） （案件決定） 選定 （検討対象決定） 案件資料取りまとめ IT子会社 開発ベンダー 4週 6月 1週 アーキテクチャ 検討 レビュー 概算 算出 概要設計 見積作成 案件審査 50

事例紹介 連携方法選択フロー 協議会設置に向けた準備 • 勉強会の実施 » 概要説明、業務サービスの紹介、 仕組みなどを説明 連携方法とコストイメージ » 連携方式とコストの説明 • 各事業部との調整 » 協議会出席者の設置依頼 » 要望シートの記入依頼など 51

事例紹介 協議会の成果 1/2 • 組織内でプロセスが共有できた » 3ヶ月おきに案件を募集し、3ヶ月で検討、その後の開発 ▸個別バラバラな依頼がなくなり、全て上記の流れに統一 ▸日程ゴールが明確ので、事前相談も適切なタイミングでされる » その「次のタイミング」があるので無理な押し込みがなくなる • 優先順位の調整がしやすい » 開発リソースは固定しているので、3ヶ月おきに、その時点の優先 度で開発対象を決めるのは公平性が保たれやすい 52

事例紹介 協議会の成果 2/2 • 開発チームとの調整がやりやすい » 3ヶ月間の計画が約束できるので双方にとって効率的 » 一方で新規開発の予算稟議は枠取りではないので、課題は残る • プラットフォームがあるのは重要 » 「簡単にできること」と「できないこと」が明確 » システムが増えても運用負荷が上がらない 53

クロージング 54

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

会社概要 略称 Graat（グラーツ） 正式名称 グロース・アーキテクチャ＆チームス株式会社 Growth Architectures & 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月期実績 56

• https://www.graat.co.jp/
• https://www.gxp-group.co.jp/

クロージング Graatの事業 市場の変化 想定ニーズ 新しい技術や働き方が、 急速に広がっている 個人やチームだけではなく、 組織として変革し、成果を創出 • アジャイルは、複数チーム・大規模案件へ • AIは、個人利用から業務・開発での活用へ • 変革を推進できる人材・組織の育成へ • • • チームの実践を、組織の意思決定につなぐ AIを、業務・開発プロセスに組み込む 顧客自身が変革できる能力を身につける エンタープライズアジャイル エンタープライズAX DX/AX人材・組織能力開発 チームのアジャイルな実践を、 継続的な組織の価値に繋げる仕組み AI活用を、業務・開発に 組み込んだ組織能力にする 組織を変革する能力を 備えた人材を育成する アジャイルPMO / 組織プロセス設計 PO支援 / アジャイル品質保証 EBAAD /ガイド型AIエージェント AI駆動開発の要件定義と品質保証 サービスデザイン /アジャイル AIフルエンシー / AI組織成熟度モデル 57