大企業でもできる！ボトムアップで拡大させるプラットフォームの作り方

大企業でもできる！ボトムアップで拡大させるプラットフォームの作り方  Platform Engineeringの進め方とコミュニケーション～組織の壁への向き合い方～  ダイキン工業株式会社前川博志  

自己紹介  所属、職位   • ダイキン工業テクノロジー・イノベーションセンター主任技師  • （いわゆる『課長級』）
    これまでの経歴   • IoTプラットフォーム「DK-Connect」のSRE チーム  • サービスエンジニア支援プラットフォームのアーキテクト  • AWSを始めとした開発インフラの標準化  • それらの開発プラットフォームを活用するアジャイル開発チームのアジャイルコーチ  • 技術情報の情報交換を行うコミュニティ運営 

最近の外部登壇  • DevOpsDays Tokyo 2025  ◦ Effectuational DevOps: "エフェクチュエーション"で駆動するDevOps組織変革
    • AI Engineering Summit by Findy Tools  ◦ 研究開発部門で生成AIを一年間追いかけて学んだたった一つのこと     • JaSST関西 2025（基調講演）  ◦ DevOpsを加速させるテスト、DevOpsで加速するテスト     • Developer's Summit 関西 2025  ◦ 技術とともに進む、ダイキン工業のソフトウェア開発 

ダイキン工業紹介 

今日お話しすること  Platform Engineeringを進める上での組織の壁   • DevOps組織の意義が理解されず、エンジニアや予算が十分に与えられない  • 基盤を広げていくのが難しい、押しつけ基盤となってしまう  •
取り組みが組織全体に広がらず、活動が頭打ちになる  • 直接的な事業インパクトを生み出せないため、予算削減対象になりやすい      これらにどう向き合ってきたか？   • 「エフェクチュエーション」という考え方を軸に振り返る 

エフェクチュエーションとは不確実な状況での意思決定アプローチ

エフェクチュエーションとは  未来を予測して目標から逆算するのではなく、手持ちの資源から可能なことを考え行動し、偶然を取り込みながら目的を創造していくアプローチ      • 特に新規事業など変化の激しい環境
の意思決定に有効とされる  • バージニア大学ダーデン経営大学院のサラス・サラスバシー教授によって提唱  • 日本では書籍「エフェクチュエーション優れた起業家が実践する5つの原則」が有名 

エフェクチュエーションの5つの原則  • 手中の鳥: 目的ありきではなく、手持ちの手段から始める  • 許容可能な損失 : 失っても許せる範囲で挑戦する  • レモネード
: 予期せぬ出来事を機会に変える  • クレイジーキルト : 関係者との相互作用で未来を共創する  • パイロット : 未来は予測せず、コントロール可能な範囲に注力する      ⇒ この5つの原則でダイキンでの取り組みを振り返る  

ダイキン工業での「エフェクチュエーション」事例手中の鳥: 自分たちの持つ武器をどう定義するか？

手中の鳥: 自分たちの持つ武器をどう定義するか？  目的ありきではなく、手持ちの手段から始める原則   • 「自分は何者か？」「何を知っているか？」「誰を知っているか？」  • 今あるリソース（技術、人、知識、ネットワークなど）を最大限に活用して何ができるかを考え、行動を起こす   
  「もっとXXがあれば、、、」を捨て、今ある武器を探す   • 技術: これまで曲がりなりにも大規模なAWSプロジェクトを進めてきた  • 人: 一緒に難しいプロジェクトをくぐり抜けてきた仲間が一人  • つながり: 色々目立つ社内活動（火消しの傭兵）のおかげで、信頼貯金有り 

とっかかりのプロジェクト: AWS設計指針  • いままで暗黙的、散逸的だった知識をまとめた  • 自分たちで説明展開できるように、自分たちで書くことにこだわった   • 今考えると、生み出したモノ自体を「手中の鳥」にしたかったのかも 

社内ルールも参照し「ダイキン」としてのルールを意識  • 社内のセキュリティレベルと、情報セキュリティの3要素（CIA）についてマッピング  • どのような情報源に対して、どのような対応を行うべきかを記載 
• 社内ルールとの整合性を取ることで、説得力のある「手中の鳥」に  

モダンなドキュメントシステムの試行  • AsciiDocとGitHubを活用し、ドキュメントをコードのように（テキストベースで）管理  ◦ textlintなどの日本語に対する静的チェック  ◦ PRを利用したドキュメントのレビュー  ◦ Web/PDFなどの複数の出力形式の管理 
• CICDの仕組み構築  ◦ リンク切れを自動検知  ◦ GitHub Pagesで各PR毎にサブディレクトリが構成され、確認できるように 

ダイキン工業での「エフェクチュエーション」事例許容可能な損失: 小規模だからこそできる取り組みを活かす

許容可能な損失: 小規模だからこそできる取り組みを活かす  失っても許せる範囲で挑戦する原則   • 「この挑戦に失敗した場合、失っても許容できる損失はどれくらいか」を自問し、その範囲内で行動を選択  • 大きなリスクを取らずに新しい試みを始めやすくなる  •
特にリソースの限られる状況で有効とされる      短期的な利益がみえなくても、とりあえずやってみよう   • 相談ベースの支援をとりあえず沢山うけてみる  • 「そんな事一々やってたらキリないよ」は無視！！  • これが実は「手中の鳥」となっていた 

開発インフラの効率化も「許容可能な損失」で  • AWS標準の権限管理だと、アカウント=人のアクセス権を一覧化するのが大変  • 管理権限をユーザーに渡しすぎると危険、渡しすぎないと煩雑、、、  ⇒ 小さく始められる範囲でユーザーや権限をYAMLで記述できる仕組みを開発 

GitHubの管理効率化とセキュリティ強化  • GitHubにもAWSと同様のYAML管理の仕組みを導入  ◦ この仕組みをCopilotなどの新規ツール導入時にも効果的に活用  • さらにGitHubのアクセスを分析する仕組みも構築  • 失敗しても影響範囲が限定される領域から始めた  

コミュニティも「許容可能な損失」で立ち上げ  ダイキン工業AWSコミュニティ ACDC   • AWS Community for Daikin Co-workers 
• ACDC変換のように、異なるエリアの人たちが交われる場に  • メーカーとして、ハードウェアに近いような言葉を入れたかった 

ACDCのあゆみ  • 2023年6月くらい: 企画 ⇒ とりあえずの仕切りを引き受ける   • 2023年9月: 社内でのAWSカンファレンスを実施
+ 告知  • 2023年10月: 正式立ち上げ、Teamsなどでの相談うけつけを開始  • 2024年12月: ACDCカンファレンスを開催  • 最終的には200名を超える組織に       ⇒ 「許容可能な損失」の範囲で始めたことが、大きな「手中の鳥」に成長 

ダイキン工業での「エフェクチュエーション」事例レモネード: どんな課題（レモン）も見方を変えればレモネードに

レモネード: どんな課題（レモン）も見方を変えればレモネードに  予期せぬ出来事を機会に変える原則   • 計画通りに進まないことや、予期せぬ問題・失敗（酸っぱいレモン）が発生した場合の考え方  • 単なる障害と捉えるのではなく、学びや新しい方向転換の機会（美味しいレモネード）として積極的に活用する 
    どうせやらないといけない面倒事なら、楽しむ   • 社内規定は守らないといけない、、、それは仕方ない  ◦ ⇒ だったら単にルールを決めるだけにしない、自動化する   • 誰も彼もが生成AIほしいと言ってるんだけど、、、これどうしよう  ◦ ⇒ みんな使いたいなら使ってもらう環境を用意すればいいじゃん！ 

なんでも自動化すれば（ちょっとは）楽しい！  • 守るべき規定に対し、自分から動いて変えていく   • 自動化前提で考えていくことで、自分たちの領域に持ち込む   • 社内のセキュリティルールをAWS向けにアレンジしたチェックリストをIT 部門と合意、作成 
• そのセキュリティルールをAWS Config上で検知する仕組みを構築  ◦ IaC実装からも検知可能なので、セキュリティプロセス自体を大幅にシフトレフト 

結局自分たちでプチCSPMつくっちゃった  • AWSマネージドでダッシュボードを自作し、必要な機能を実装  • ある程度の運用しやすさを担保しつつ、高い拡張性・安価なランニングコストを実現  • ⇒ PoC段階で致命的なセキュリティインシデントを発見！！  

どうせみんな生成AIを使うんだから、先に作っとこう  • 技術の動向は決まってないので、ある程度流用できる構成に  • やはりキラーコンテンツになり、社内で続々引き合い  • 生成AIは関わるだけ会社に詳しくなれるので、爆アド  RAGテンプレート   •
リファレンスアーキテクチャの延長としてRAGテンプレートを整備  • インターフェースの導入により、サービスに依存せず柔軟な処理実装が可能 

ダイキン工業での「エフェクチュエーション」事例クレイジーキルト: 社内外を有機的につなぐ

クレイジーキルト: 社内外を有機的につなぐ  関係者との相互作用で未来を共創する原則   • 事業を進める中で出会い、関心を示してくれた人々（ステークホルダー）と自発的なパートナーシップを築く  • 相互作用を通じて、当初は想像もしなかったようなゴールや事業内容
を共に創り上げていく       前提を持たずにコミュニケーションして発見を繰り返してく   • セキュリティ周りで全社IT部門と多く会話するように  ◦ お互いの事情がわかり、建設的な議論ができるようになった  • 生成AIの事例の中で営業で技術を尖らせているメンバーを発見  ◦ RAGテンプレートに巻き込み、想定以上のスピードで事例創出 

ちょっとでも確実に起きている変化  IT部門  • AWSのガードレール環境の導入が進む  ◦ そのグループのメンバーがAWSコミュニティでも積極的にうごいている  • 規定を定めるときにも、「チェックが自動化できること」を前提に考える  • アジャイル開発どうやって進めればいい？という相談も！！ 
    営業部門  • 実際に生成AIをビジネスとして考えるように  • シーズ駆動ではあるが、コラボレーションによって新しい動きにつながる 

コミュニティの統合も「クレイジーキルト」  AWSコミュニティとシステム開発コミュニティを統合し、ダイキンのあらゆる開発者を対象としたコミュニティに変更 ⇒ Daikin Developers' Lounge: D2 Lounge  
• 参加者約400名の巨大コミュニティに  ◦ WAUも200名近い、生きたコミュニティ  • 異なるバックグラウンドの人たちが有機的につながる場に  

実践的な勉強会の開催  • AWS様のご協力の元、実践型ワークショップであるGameDaysを開催  • 製造業としては異例（AWSさん談）の、60名を超える参加者が集まる  • 外部パートナーとの「クレイジーキルト」も積極的に  

ダイキン工業での「エフェクチュエーション」事例パイロット: 大きなことを一気に見すぎない

パイロット: 大きなことを一気に見すぎない  未来は予測せず、コントロール可能な範囲に注力する原則   • 市場予測や競合分析といった外部環境の予測に頼るのではなく、自らがコントロール可能な活動に焦点を当て、行動する  •
予測ではなく未来を形作っていこうとする考え方      コントロールできる範囲で動き、少しづつ波を大きくする   • 少しづつ広がる内製開発の取り組み  • 進化と合わせて進む生成AI取り組み 

内製開発の取り組み  • 組織を大きく変えるのは難しくても、実績を積めば少しずつ  • 個々の登壇実績でチームが成長し、ここまできた！！  • （もちろんまだまだこれがスタート）      アジャイル開発チームの成長
  • 立ち上げたばかりの内製アジャイル開発チームのアジャイルコーチ  • 人数は倍以上に成長、高度なアジャイル実践者集団に  • お互いに刺激を受けながら、チームを引っ張りメンバーに引っ張られています！！ 

生成AIに向き合うのも「パイロット」  コントロール出来ないものが多すぎる...   • 1年以上、生成AIを活用した仕組みを取り組んできたが、技術の進歩はあまりにも早い！   • これまで苦労して作ってきたものが一夜にしてAPIになる恐怖  •
では取り組みは無駄なのか？技術的にトライしなくていいのか？？      コントロールできるものに向き合う   • 新しいAIサービスの「本当の価値」がわかる ⇒ 「目利き力」が非常に重要  • いかに、どこを疎結合にするのかを常に考えるようになる ⇒ モジュール化、パーツ化を意識   • サンクコストをおそれず、やっていく  • 陳腐化しない「経験」を人間にストアする 

コードレビューシステム「D-Arc」  • 組み込みシステムを対象としたレビューシステムを試作しトライアル実施  • 生成AIに丸投げするのではなく、構文解析など決定論的な手法と組み合わせ 
• 最近流行の「AIエージェント」の考え方を先取りする形に 

D-Arc VSCode拡張で使いやすく  • コマンドラインだけ！のような人を選ぶツールのみではなかなか使ってもらえない…  • フィードバックを得るため
にもVSCode拡張を内作   • コントロールできる範囲で、着実に前進 

まとめエフェクチュエーションでPlatform Engineeringの壁を越える

Platform Engineeringの課題にどう向き合うか？  課題  • DevOps組織の意義が理解されず、エンジニアや予算などが十分に与えられない  • 基盤を広げていくのが難しかったり、押しつけ基盤となって前向きに利用してもらえない  •
取り組みが組織全体に広がらず、活動が頭打ちになる  • 直接的な事業インパクトを生み出せないため、予算削減対象になりやすい      エフェクチュエーションでの向き合い方   • 意義が理解されるまでは許容可能な損失で地道に頑張り、クレイジーキルトを紡いで手中の鳥を育てていく  • 困難な状況をうまくフックに使い、レモネードで一気に加速させる  • パイロットのように今ある状況を理解し、活かすことが重要 

「エフェクチュエーション」していく中でも必要なこと  これっていわゆる「行き当たりばったり」じゃないの？？？       ビジョン = 実現したい絵姿なしにこれをやると、みんな混乱する   •
ビジョンは大きくは「ソフトウェアを製造業においてビジネスを加速する手段とすること」  • そのために、DevOpsで質とスピードを上げる。内製も取り入れる。生成 AIも活用する。  ⇒ 目指したい姿を常に示し、アップデートすることが必要   「高度の柔軟性を維持しつつ、臨機応変に対処することになろうかとおもいます」「要するに、行き当たりばったりじゃな」 ― 銀河英雄伝説「黎明篇」より

大企業でもできる！ボトムアップで拡大させるプラットフォームの作り方

大企業でもできる！ボトムアップで拡大させるプラットフォームの作り方

ファインディ株式会社（イベント資料アップ用）

Transcript