Slide 1
Slide 1 text
大企業でもできる！ボトムアップで拡大
させるプラットフォームの作り方
Platform Engineeringの進め方とコミュニケー
ション ～組織の壁への向き合い方～
ダイキン工業株式会社 前川博志
Slide 2
Slide 2 text
自己紹介
所属、職位
● ダイキン工業 テクノロジー・イノベーション
センター 主任技師
● （いわゆる『課長級』）
これまでの経歴
● IoTプラットフォーム「DK-Connect」のSRE
チーム
● サービスエンジニア支援プラットフォーム
のアーキテクト
● AWSを始めとした開発インフラの標準化
● それらの開発プラットフォームを活用する
アジャイル開発チームのアジャイルコーチ
● 技術情報の情報交換を行うコミュニティ運
営
Slide 3
Slide 3 text
最近の外部登壇
● DevOpsDays Tokyo 2025
○ Effectuational DevOps: "エフェクチュエーション"で駆動するDevOps組織
変革
● AI Engineering Summit by Findy Tools
○ 研究開発部門で生成AIを一年間追いかけて学んだたった一つのこと
● JaSST関西 2025（基調講演）
○ DevOpsを加速させるテスト、DevOpsで加速するテスト
● Developer's Summit 関西 2025
○ 技術とともに進む、ダイキン工業のソフトウェア開発
Slide 4
Slide 4 text
ダイキン工業紹介
Slide 5
Slide 5 text
ダイキン工業紹介
Slide 6
Slide 6 text
今日お話しすること
Platform Engineeringを進める上での組織の壁
● DevOps組織の意義が理解されず、エンジニアや予算が十分に与えら
れない
● 基盤を広げていくのが難しい、押しつけ基盤となってしまう
● 取り組みが組織全体に広がらず、活動が頭打ちになる
● 直接的な事業インパクトを生み出せないため、予算削減対象になりや
すい
これらにどう向き合ってきたか？
● 「エフェクチュエーション」という考え方を軸に振り返る
Slide 7
Slide 7 text
エフェクチュエーションとは
不確実な状況での意思決定アプローチ
Slide 8
Slide 8 text
エフェクチュエーションとは
未来を予測して目標から逆算するのではなく、手持ちの資源から可能なこ
と を考え行動し、偶然を取り込みながら目的を創造 していくアプローチ
● 特に新規事業など 変化の激しい環境 の意思決定に有効とされる
● バージニア大学ダーデン経営大学院のサラス・サラスバシー教授によっ
て提唱
● 日本では書籍「エフェクチュエーション 優れた起業家が実践する5つの
原則」が有名
Slide 9
Slide 9 text
エフェクチュエーションの5つの原則
● 手中の鳥: 目的ありきではなく、手持ちの手段から始める
● 許容可能な損失 : 失っても許せる範囲で挑戦する
● レモネード : 予期せぬ出来事を機会に変える
● クレイジーキルト : 関係者との相互作用で未来を共創する
● パイロット : 未来は予測せず、コントロール可能な範囲に注力する
⇒ この5つの原則でダイキンでの取り組みを振り返る
Slide 10
Slide 10 text
ダイキン工業での「エフェクチュエーション」事例
手中の鳥: 自分たちの持つ武器をどう定義するか？
Slide 11
Slide 11 text
手中の鳥: 自分たちの持つ武器をどう定義するか？
目的ありきではなく、手持ちの手段から始める原則
● 「自分は何者か？」「何を知っているか？」「誰を知っているか？」
● 今あるリソース（技術、人、知識、ネットワークなど）を最大限に活用して
何ができるかを考え、行動を起こす
「もっとXXがあれば、、、」を捨て、今ある武器を探す
● 技術: これまで曲がりなりにも大規模なAWSプロジェクトを進めてきた
● 人: 一緒に難しいプロジェクトをくぐり抜けてきた仲間が一人
● つながり: 色々目立つ社内活動（火消しの傭兵）のおかげで、信頼貯金
有り
Slide 12
Slide 12 text
とっかかりのプロジェクト: AWS設計指針
● いままで暗黙的、散逸的だった知識をまとめた
● 自分たちで説明展開できるように、自分たちで書くことにこだわった
● 今考えると、生み出したモノ自体を「手中の鳥」にしたかったのかも
Slide 13
Slide 13 text
社内ルールも参照し「ダイキン」としてのルールを意識
● 社内のセキュリティレベル
と、情報セキュリティの3要
素（CIA）についてマッピン
グ
● どのような情報源に対し
て、どのような対応を行う
べきかを記載
● 社内ルールとの整合性を
取ることで、説得力のあ
る「手中の鳥」に
Slide 14
Slide 14 text
モダンなドキュメントシステムの試行
● AsciiDocとGitHubを活用し、ドキュメントをコードのように（テキストベー
スで）管理
○ textlintなどの日本語に対する静的チェック
○ PRを利用したドキュメントのレビュー
○ Web/PDFなどの複数の出力形式の管理
● CICDの仕組み構築
○ リンク切れを自動検知
○ GitHub Pagesで各PR毎にサブディレクトリが構成され、確認できるように
Slide 15
Slide 15 text
ダイキン工業での「エフェクチュエーション」事例
許容可能な損失: 小規模だからこそできる取り組みを活か
す
Slide 16
Slide 16 text
許容可能な損失: 小規模だからこそできる取り組みを活かす
失っても許せる範囲で挑戦する原則
● 「この挑戦に失敗した場合、失っても許容できる損失はどれくらいか」を
自問し、その範囲内で行動を選択
● 大きなリスクを取らずに新しい試みを始めやすくなる
● 特に リソースの限られる状況 で有効とされる
短期的な利益がみえなくても、とりあえずやってみよう
● 相談ベースの支援をとりあえず沢山うけてみる
● 「そんな事一々やってたらキリないよ」は無視！！
● これが実は「手中の鳥」となっていた
Slide 17
Slide 17 text
開発インフラの効率化も「許容可能な損失」で
● AWS標準の権限管理だと、アカウント=人のアクセス権を一覧化するの
が大変
● 管理権限をユーザーに渡しすぎると危険、渡しすぎないと煩雑、、、
⇒ 小さく始められる範囲で ユーザーや権限をYAMLで記述できる仕組み
を開発
Slide 18
Slide 18 text
GitHubの管理効率化とセキュリティ強化
● GitHubにもAWSと同様のYAML管理の仕組みを導入
○ この仕組みをCopilotなどの新規ツール導入時にも効果的に活用
● さらにGitHubのアクセスを分析する仕組みも構築
● 失敗しても影響範囲が限定される領域から始めた
Slide 19
Slide 19 text
コミュニティも「許容可能な損失」で立ち上げ
ダイキン工業AWSコミュニティ ACDC
● AWS Community for Daikin Co-workers
● ACDC変換のように、異なるエリアの人たちが交われる場に
● メーカーとして、ハードウェアに近いような言葉を入れたかった
Slide 20
Slide 20 text
ACDCのあゆみ
● 2023年6月くらい: 企画 ⇒ とりあえずの仕切りを引き受ける
● 2023年9月: 社内でのAWSカンファレンスを実施 + 告知
● 2023年10月: 正式立ち上げ、Teamsなどでの相談うけつけを開始
● 2024年12月: ACDCカンファレンスを開催
● 最終的には200名を超える組織に
⇒ 「許容可能な損失」の範囲で始めたことが、大きな「手中の鳥」に成長
Slide 21
Slide 21 text
ダイキン工業での「エフェクチュエーション」事例
レモネード: どんな課題（レモン）も見方を変えればレモネー
ドに
Slide 22
Slide 22 text
レモネード: どんな課題（レモン）も見方を変えればレモネードに
予期せぬ出来事を機会に変える原則
● 計画通りに進まないことや、予期せぬ問題・失敗（酸っぱいレモン）が発
生した場合の考え方
● 単なる障害と捉えるのではなく、学びや新しい方向転換の機会（美味し
いレモネード）として積極的に活用する
どうせやらないといけない面倒事なら、楽しむ
● 社内規定は守らないといけない、、、それは仕方ない
○ ⇒ だったら単にルールを決めるだけにしない、自動化する
● 誰も彼もが生成AIほしいと言ってるんだけど、、、これどうしよう
○ ⇒ みんな使いたいなら使ってもらう環境を用意すればいいじゃん！
Slide 23
Slide 23 text
なんでも自動化すれば（ちょっとは）楽しい！
● 守るべき規定に対し、自分から動いて変えていく
● 自動化前提で考えていくことで、自分たちの領域に持ち込む
● 社内のセキュリティルールをAWS向けにアレンジしたチェックリストをIT
部門と合意、作成
● そのセキュリティルールをAWS Config上で検知する仕組みを構築
○ IaC実装からも検知可能なので、セキュリティプロセス自体を大幅にシフ
トレフト
Slide 24
Slide 24 text
結局自分たちでプチCSPMつくっちゃった
● AWSマネージドでダッシュボードを自作し、必要な機能を実装
● ある程度の運用しやすさを担保しつつ、高い拡張性・安価なランニング
コストを実現
● ⇒ PoC段階で致命的なセキュリティインシデントを発見！！
Slide 25
Slide 25 text
どうせみんな生成AIを使うんだから、先に作っとこう
● 技術の動向は決まってないので、ある程度流用できる構成に
● やはりキラーコンテンツになり、社内で続々引き合い
● 生成AIは関わるだけ会社に詳しくなれるので、爆アド
RAGテンプレート
● リファレンスアーキテクチャの延長としてRAGテンプレートを整備
● インターフェースの導入により、サービスに依存せず柔軟な処理実装が
可能
Slide 26
Slide 26 text
ダイキン工業での「エフェクチュエーション」事例
クレイジーキルト: 社内外を有機的につなぐ
Slide 27
Slide 27 text
クレイジーキルト: 社内外を有機的につなぐ
関係者との相互作用で未来を共創する原則
● 事業を進める中で出会い、関心を示してくれた人々（ステークホルダー）
と自発的なパートナーシップを築く
● 相互作用 を通じて、当初は想像もしなかったようなゴールや事業内容
を 共に創り上げていく
前提を持たずにコミュニケーションして発見を繰り返してく
● セキュリティ周りで全社IT部門と多く会話するように
○ お互いの事情がわかり、建設的な議論 ができるようになった
● 生成AIの事例の中で営業で技術を尖らせているメンバーを発見
○ RAGテンプレートに巻き込み、想定以上のスピードで事例創出
Slide 28
Slide 28 text
ちょっとでも確実に起きている変化
IT部門
● AWSのガードレール環境の導入が進む
○ そのグループのメンバーがAWSコミュニティでも積極的にうごいている
● 規定を定めるときにも、「チェックが自動化できること」を前提に考える
● アジャイル開発どうやって進めればいい？という相談も！！
営業部門
● 実際に生成AIをビジネスとして考えるように
● シーズ駆動ではあるが、コラボレーションによって新しい動きにつながる
Slide 29
Slide 29 text
コミュニティの統合も「クレイジーキルト」
AWSコミュニティとシステム開発コミュニティを統合し、ダイキンのあらゆる開
発者を対象としたコミュニティに変更 ⇒ Daikin Developers' Lounge: D2
Lounge
● 参加者約400名の巨大コミュニティに
○ WAUも200名近い、生きたコミュニティ
● 異なるバックグラウンドの人たちが有機的につながる場に
Slide 30
Slide 30 text
実践的な勉強会の開催
● AWS様のご協力の元、実践型ワークショップであるGameDaysを開催
● 製造業としては異例（AWSさん談）の、60名を超える参加者が集まる
● 外部パートナーとの「クレイジーキルト」も積極的に
Slide 31
Slide 31 text
ダイキン工業での「エフェクチュエーション」事例
パイロット: 大きなことを一気に見すぎない
Slide 32
Slide 32 text
パイロット: 大きなことを一気に見すぎない
未来は予測せず、コントロール可能な範囲に注力する原則
● 市場予測や競合分析といった 外部環境の予測に頼るのではなく 、自
らがコントロール可能な活動に焦点を当て、行動する
● 予測ではなく 未来を形作っていこう とする考え方
コントロールできる範囲で動き、少しづつ波を大きくする
● 少しづつ広がる内製開発の取り組み
● 進化と合わせて進む生成AI取り組み
Slide 33
Slide 33 text
内製開発の取り組み
● 組織を大きく変えるのは難しくても、実績を積めば少しずつ
● 個々の登壇実績でチームが成長し、ここまできた！！
● （もちろんまだまだこれがスタート）
アジャイル開発チームの成長
● 立ち上げたばかりの内製アジャイル開発チームのアジャイルコーチ
● 人数は倍以上に成長、高度なアジャイル実践者集団に
● お互いに刺激を受けながら、チームを引っ張りメンバーに引っ張られて
います！！
Slide 34
Slide 34 text
生成AIに向き合うのも「パイロット」
コントロール出来ないものが多すぎる...
● 1年以上、生成AIを活用した仕組みを取り組んできたが、技術の進歩は
あまりにも早い！
● これまで苦労して作ってきたものが一夜にしてAPIになる恐怖
● では取り組みは無駄なのか？技術的にトライしなくていいのか？？
コントロールできるものに向き合う
● 新しいAIサービスの「本当の価値」がわかる ⇒ 「目利き力」が非常に
重要
● いかに、どこを疎結合にするのかを常に考えるようになる ⇒ モジュー
ル化、パーツ化を意識
● サンクコストをおそれず、やっていく
● 陳腐化しない「経験」を人間にストアする
Slide 35
Slide 35 text
コードレビューシステム 「D-Arc」
● 組み込みシステムを対象と
したレビューシステムを試
作しトライアル実施
● 生成AIに丸投げするので
はなく、構文解析など決定
論的な手法と組み合わせ
● 最近流行の 「AIエージェン
ト」の考え方を先取り する
形に
Slide 36
Slide 36 text
D-Arc VSCode拡張 で使いやすく
● コマンドラインだけ！のよ
うな人を選ぶツールのみ
ではなかなか使ってもらえ
ない…
● フィードバックを得るため
にもVSCode拡張を内作
● コントロールできる範囲
で、着実に前進
Slide 37
Slide 37 text
まとめ
エフェクチュエーションでPlatform Engineeringの壁を越え
る
Slide 38
Slide 38 text
Platform Engineeringの課題にどう向き合うか？
課題
● DevOps組織の意義が理解されず、エンジニアや予算などが十分に与えられ
ない
● 基盤を広げていくのが難しかったり、押しつけ基盤となって前向きに利用して
もらえない
● 取り組みが組織全体に広がらず、活動が頭打ちになる
● 直接的な事業インパクトを生み出せないため、予算削減対象になりやすい
エフェクチュエーションでの向き合い方
● 意義が理解されるまでは 許容可能な損失 で地道に頑張り、クレイジーキル
ト を紡いで 手中の鳥 を育てていく
● 困難な状況をうまくフックに使い、レモネード で一気に加速させる
● パイロット のように今ある状況を理解し、活かすことが重要
Slide 39
Slide 39 text
「エフェクチュエーション」していく中でも必要なこと
これっていわゆる「行き当たりばったり」じゃないの？？？
ビジョン = 実現したい絵姿なしにこれをやると、みんな混乱する
● ビジョンは大きくは「ソフトウェアを製造業においてビジネスを加速する
手段とすること」
● そのために、DevOpsで質とスピードを上げる。内製も取り入れる。生成
AIも活用する。
⇒ 目指したい姿を常に示し、アップデートすることが必要
「高度の柔軟性を維持しつつ、臨機応変に対処することになろうかとおもいます」 「要するに、行き当たり
ばったりじゃな」 ― 銀河英雄伝説 「黎明篇」より
Slide 40
Slide 40 text
No content