【内製開発Summit 2025】プロダクトの価値は始まりにすぎない！事業から組織へ拡がるダイキンのアジャイル化

2024年に創業100周年を迎えたダイキン工業

谷尾：谷尾虎之介と申します。よろしくお願いいたします。私は新卒4年目で、普段はアジャイル内製化チームでスクラムマスターをしています。DX人材の育成を目的として2017年に設立された社内大学「ダイキン情報技術大学」の4期生として入社しています。

本日は、私の先輩であり、ダイキン情報技術大学2期生で、プラットフォームエンジニアとしてアジャイル内製化チームを支える基盤関係周りの仕事に従事している角田とともにお話しさせていただきます。本セッションでは、下記のような流れでお話しします。



谷尾：なお、ダイキン工業がどのようにしてアジャイル・内製化を作り上げたか、については、時間の都合上省略いたします。2024年2月に開催されたイベントで「大手製造業のアジャイル開発促進」と題して、弊社の社員が登壇していますので、気になる方はこちらをご確認いただけますと幸いです。

またセッションに入る前にダイキン工業についてもご紹介させてください。

ダイキン工業は、昨年で創業100周年を迎えました。売上比率の83%が海外であるという特徴があり、エアコンをコア事業としながらソリューション事業も手がけています。ソリューション事業では「空調機の遠隔監視や故障予知」「空調データを活用した省エネ化」をコアドメインとし、複数のソリューションを展開しています。

ちなみに、今回お話しするアジャイル内製化チームでは「空調データを活用した省エネ化」に力を入れています。電気料金は一年間のうちでピークの電力に大きく影響されるため、空調機の負荷に応じて温度を制御してピークの電力を抑制することが重要です。それを踏まえて、快適性を損なわずに空調機を省エネルギーかつ長期的にご利用いただけるソリューションを提供しています。

アジャイル内製化チームの取り組み

谷尾：本題に入ります。まずは開発チームについてご紹介します。

ダイキン工業のアジャイル内製化チームは三つの独立したスクラムチームを持っており、それぞれに異なるプロダクトを持っております。POについても権限を委譲されているため、スクラムチームに決定権がある状態です。そんなスクラムチームを大きくしていく上で、強化している取り組みについてお話しします。

一つ目が「スクラムチームの垣根を超えた各ロールの連携」です。具体的には、POミーティングとして、テーマの方向性や優先度について意見交換する機会を設けています。このようなミーティングを開催している理由は、各スクラムチームが異なるプロダクトを持っているからです。それぞれのドメイン知識を共有して、新しいサービスやソリューションの提案・価値の創造につなげていくため、定期的に開催しています。

またスクラムマスターミーティングも行っています。各スクラムチームでの振り返りを共有・議論しているほか、組織全体の課題や改善点を検査して、スクラムチームで取るべき対応についても検討を重ねています。

二つ目は「スクラムチームの垣根を超えた開発チームの連携」です。Learning Dayと題して、開発チーム全員が集まり、週に1度のペースで半日ほど時間を確保しています。具体的な内容としては、各スクラムチームのプロダクトゴールに向けた取り組みやスプリントを通して得られた技術的な知見を共有しています。




谷尾：全員参加型の15分間のチームLTも開催しており、コミュニケーションを促進するとともに、メンバーのソフトスキルを鍛える目的もあります。導入背景や効果についての詳細は、画像右下にあるQRコードからご確認いただけますと幸いです。

またチームLTなどが終了したあとに3～4時間ほど時間が余るため、その全てを技術研鑽にあてています。個人で技術を磨くのではなく、他のチームのメンバーとペアプロやモブプロのような形で、優先度の低い技術的負債を解消したり、最新技術を試したりしています。

三つ目は「スクラムチームの垣根を超えた新メンバーの教育」です。技術的な部分でいうと、各種申請の情報や技術スタックに関する情報を、GitHub上にマークダウン形式で管理するようにしています。

加えて、私たちのチームではドメイン知識を集約することにも力を入れており、GitHub ProjectsのBoard上にISSUEとして情報を一元管理しています。そこでサービス商材やソリューションに関する解説を残すことで、オンボーディングを効率化しています。

このような取り組みを通して、スクラムチームは徐々にスケールしていきました。



谷尾：プロダクトを成長させるとともにチームも育てていく過程で、アウトプットの生産性を徐々に向上することができています。以前は未経験のメンバーが多いことからバグを量産してしまっているのに対応できない状態でしたが、現在はPOやスクラマスターを含めてチーム一丸で品質に対して向き合っていくことができるようになりました。品質面においても、アウトプットの部分で目に見えて指標が良くなっていて、成長を感じられるようになりました。

チーム拡大に向けてアジャイルを広げていく

最初は順調だったものの、少しずつ出てきた課題

谷尾：スクラムチームが徐々にスケールするようになり、今度はステークホルダーにアジャイルという考え方を広げていくフェーズに突入しました。

スクラムのなかでは、ステークホルダーと協働する必要のあるイベントが多々ありますよね。例えば、スクラムを円滑に回してプロダクトの価値を高めていくためには、インセプションデッキの作成やプロダクトゴールの策定を進めるほか、ステークホルダーにスプリントレビューに参加してもらう必要があります。

またドメイン理解を深めて開発チームが価値を創造できるようにするためには、ドメイン駆動の文脈ではイベントストーミング、ユビキタス言語の探求が必要です。

ダイキン工業でもそういったイベントに取り組んでいて、最初はうまくいっているように見えていたのですが、徐々にほころびが出始めました。



谷尾：一例を挙げると、開発チームはプロダクトの価値や効果の検証を重視したいけれど、営業部門は今年度の数値目標を達成するための施策を重視したい、といった「プロダクトゴールに対する認識のズレ」がありました。同じプロダクトゴールを掲げてスプリントレビューを継続的に実施していたにも関わらず、根底の部分で認識のズレが生まれていたのです。

社内受託のような関係が払拭しきれないという側面もありました。開発チームはプロダクトのためになると思って提案するものの、ステークホルダーからすると目的がよくわからないと。つまり、一連託生で取り組めているわけではなかったのです。

こういった状況に陥ってしまった原因は何だったのか？ 我々としては、根底にある理念や考え方の共有と共感ができていなかったことが原因だったと考えています。



谷尾：例えば、皆さんのチームにスクラム未経験者が加入したとして「スクラムのイベントの内容や目的」「スクラムにおける三本柱や価値基準」などを伝えると思います。

ただ、私たちのチームでは前者については共有していたものの、後者については意図的に隠蔽していました。なぜ隠蔽していたのかというと、開発チームの都合をステークホルダーに押し付けるのは良くない、と考えていたからです。

しかし、スクラムは「スクラムチームとステークホルダーの共同作業」ですよね。スクラムガイドにおけるスクラムの五つの価値基準の一つの「公開」という文脈においては、スクラムチームとステークホルダーは、作業や課題を公開する、とあります。

これはスクラムチームだけが公開すればいいというわけではありません。ステークホルダーが把握していないところでモノが出来上がっていくのは、プロジェクトにとっても良いことではないはず。ステークホルダーと一緒にスクラムガイドを読んで、価値観を共有して共感することが、非常に重要なのだと実感しました。

コミュニケーションを増やし、ステークホルダーとの関係性を構築

谷尾：こういった状況を改善するため、アジャイルを体験できるワークショップや社外交流の場に、営業部門のメンバーを積極的に招待するようにしました。最近だと、東京ガス様の内製開発チームとの意見交流会に営業部門のメンバーを招待して、議論に参加していただきました。ちなみに、この内製開発Summitにも営業部門のメンバーに参加していただいています。

このような取り組みを通して、POと同じ視座を持ったステークホルダーが増えたことで、プロダクトゴールを見据えた本質的な議論や指摘がなされるようになりました。

また営業部門が高いアジリティを発揮できるように、開発部門として組織体制の改革にも挑戦しています。この背景にあったのは、営業部門がお客様にソリューションを提案して高速なフィードバックループを回すためには開発部門が請け負っている複数のプロダクトの優先度を調整する必要がある、という課題です。

このような状況下では、開発部門にとっては最適な優先度であったとしても、営業部門は施策や変更のベストタイミングを逃してしまう可能性があります。



谷尾：そこで、まずは営業部門にPOを置く体制に変更することにしました。ゆくゆくはDev人材も営業部門に置いて、プロダクトを部門単独で回せるようにしたいと考えています。

アジリティのあるチームを支える基盤づくり

開発チームを支えるプラットフォームチーム

谷尾：ここまでは、アジャイル内製化チームの取り組みについてお話ししました。ここからは、こういったアジリティのあるチームを支える基盤について触れていきます。

先ほどお話しした、ステークホルダーの理解・協力については、開発チームが築いた信頼貯金（安定的な開発体制・アウトプットの指標の実現）が重要だと考えています。このような開発チームを支えるプラットフォームとして、ダイキン工業にはプラットフォームチームがあります。



谷尾：具体的にいうと、アジャイル内製化チームがチームトポロジーでいうXaaSのような形でAWS環境やセキュリティの支援を行っていて、プラットフォームチームでは全社IT部門とコラボレーションしながら開発プラットフォームや全社ルールの整備を担当しています。詳細については、角田からお話しします。

角田：角田と申します。私はプラットフォームチームにて、ITインフラエンジニアとしての役割を担いつつ、AWSやGitHubの管理などを担当しています。私からは、プラットフォームのこれまでの実績と、今後対応したいことについてお話しします。

実績1：AWSアカウント払い出しのシステム化

角田：プラットフォームチームの実績としては「AWSアカウント払い出しのシステム化」や「AWSセキュリティルールの改訂／ルールのレビュー支援システム構築」などを行ってきました。前者について、なぜシステム化が必要だったのかというと、AWSアカウントの払い出し申請フローが煩雑化していたからです。




角田：というのも、以前はAWSのアカウントの払い出しをベンダーにご協力いただいて、メールで申請できるようにしていました。私を含めてチームメンバーにAWSに関する知識がなかった頃はこれでも良かったのですが、勉強を重ねていくうちに「申請フローを自動化すれば、一週間も必要ないのではないか？」と気がつきました。

そこでベンダーにも相談してみたのですが、自動化は難しいという話だったため、AWSアカウントをベンダーに作っていただく手順を省略することにしました。



角田：ポイントは「開発者の方が使いやすいシステム」を意識した点です。編集しやすいように、GitHub上にリストを置いてActionsでCI/CD環境を構築。GitHubリポジトリでYamlのリストを調整してプルリクエストを作成するか、Formsのどちらで申請できるようにしました。また以前は入力した欄の費用周りのIDに入力ミスがあり手戻りが発生するケースが多発していたため、そこを自動チェックするような仕組みを導入しました。

結果として、申請しやすく、かつ遅くても1～2日でアカウントを提供できるようになりました。

また、Github Actionsによる自動実行は現状不安定で、まれに失敗することもあります。確実な成功を求める形で、ベンダーにシステム開発を依頼していたら、独自のシステムを開発することになっていたでしょう。しかし内製したことで「まれな失敗については手動の再実行で許容する」という判断ができたのは良かったと思っています。

ちなみに、AWSアカウント管理システムについては、メンバーが作成したGitHub自体のアカウント申請・リポジトリ権限申請システムに着想を得て作成しています。

実績2：AWSセキュリティルールの改訂／ルールのレビュー支援システム構築

角田：続けて、DevSecOpsの実現に向けて行った「AWSセキュリティルールの改訂／ルールのレビュー支援システム構築」についてお話しします。

プラットフォームチームは、開発チームからセキュリティの相談を受けることがあり、その内容が煩雑であるという課題がありました。背景にあったのは、Excelにチェックリストとしてまとめられた難解な全社セキュリティルールです。

というのも、オンプレやベンダー委託を前提としたものだったため、AWSやAzure上で内製開発する際に、適宜ルールの読み替えが求められる状態だったのです。またダイキン情報技術大学が始まったことで社内にITエンジニアが急増したものの、内製領域を拡大できないという課題がありました。

そもそも、チェックリストを手動で見なくてはいけないというやり方にも問題がありました。それによりリリース前に専門家のレビューが必須でしたし、DevOpsを通した継続的なチェックができていませんでした。そこで私たちは、オンプレやベンダー委託を前提としたルールを見直し、全社IT部門と共同でセキュリティルールを改訂しました。



角田：具体的なAWSサービス名を盛り込み、オンプレ経験のない若手エンジニアでも理解しやすいように、具体的な手順やそのルールを制定した理由なども盛り込みました。

改訂したあとは、そのルールが各アカウントの運用実態に即しているかを検証するために自動チェックのツールを使って、漏れがないか／妥当性があるかどうかも確認するようにしていました。セキュリティベンダーに委託している部分もあったのですが、実装の部分を内製することでスピード感を持って検証できました。

また、この時に使用した自動チェックのツールは、ルールのレビュー支援システムとして開発者側にも解放しています。



角田：そのままでは少し使いづらいコマンドラインツールだったため、ダッシュボードのような形をイメージして、各アカウント情報を自動で表示してくれるようなWebページを作りました。

これにより、日々の簡易チェックができるようになりました。アジャイル内製化チームか、そうでない開発チームかによって、自動チェックが見れる範囲の権限が異なるため、手動レビューは残しています。ただ手動レビューでもこのツールは使えますし、レビュー資料の作成が省略化できたのはとても良かったのではないかと思います。

実際に運用中のダッシュボードがこちらです。



角田：一目見ただけで、何がルールに違反しているのか、脆弱な設定になっているアカウントがどれくらいあるのかを確認できます。こちらは毎日更新されるため、情報を都度追えるような形にしているのがポイントです。



角田：今後は、アジャイル内製化チーム単独でセルフチェックできるようにしていくとともに、ベンダー側の開発チームにも活用していただいて、全体のセキュリティ意識を高めていきたいなと考えています。

また新しい領域として、インフラを超えてプロダクトコード側のセキュリティチェックをすることも目指しています。その上で、プロダクトの新規開発をセキュアに始められる仕組みを整えていくつもりです。

内製の価値観や領域を企業全体へ波及するために

ダイキン工業の内製化を阻む「移管」

谷尾：最後に、内製の価値観や領域を企業全体へ波及するために、アジャイル内製化チームが取り組んでいる「組織変革を伴う内製領域の拡大運動」「全社の人材教育への貢献」「社内コミュニティの展開・運用」といった三つの取り組みについてお話します。

そもそも、ダイキン工業の全社的な課題は、多くの事業部が外注に頼っていることです。アジャイル内製化チームでは内製化が徐々に進みつつあるのですが、会社全体ではほとんどが外注に頼ってしまっています。

それにより、社内に技術的なノウハウが蓄積されず、意思決定や実行のスピードが低下するといった課題を抱えています。内製開発Summitで登壇されている他の企業様と比較しても、ダイキン工業は競争力が低下している部類なのではないでしょうか。

そのような状況を打破するためにも、現在はコアドメインの内製領域の拡大を目指しています。特定の事業部からスモールスタートで内製の領域を少しずつ広げていくように、アジャイル内製化チームとして支援を行っております。

そして、そういった支援を通して、ダイキン工業が抱えている課題の根本的な原因が明らかになってきました。それは「移管」という仕組みです。ダイキン工業では、研究開発組織で開発したものを事業部で運用しています。ちなみに、アジャイル内製化チームも研究開発組織から派生した部門です。

移管の何が問題なのかというと、開発と運用が分離することでスピードと品質の低下を招くだけでなく、追加機能が難しくなるということです。また事業部には開発の知見がないため、内製で開発したものであっても運用を外部委託に依存してしまいがちになってしまいます。

移管による評価制度にも課題がありました。開発チームがどれだけ事業部門にソフトウェアやプロダクトを投げれられたかという移管率が評価指標だったため、ソフトウェアの品質やプロダクトの価値が蔑ろにされる傾向にありました。

組織変革を伴う内製領域の拡大運動

谷尾：このような背景を踏まえて、開発運用体制の変更を目指し、現在取り組みを進めています。



谷尾：具体的には、開発フェーズから事業部の運用担当者を巻き込むことで継続的に改善できる体制を整えるために、上層部や事業部のメンバーに提案をしているところです。

移管率については「アウトカム＝プロダクト利用による顧客の変化」／「ビジネスインパクト＝プロダクトが事業にもたらす成果」をKPIや目標として設定できるように、上層部に掛け合っているところです。

全社の人材教育への貢献

谷尾：そのほか、全社的なエンジニアのフォローアップにも力を入れています。アジャイル内製化チームでは人材の流動性があり、オンボードまでの時間が課題となっていたため、教育資産を重要視していました。

ダイキン情報技術大学を卒業したIT人材が一人で対応しなければいけないというケースが増えていることを受けて、彼らを手助けするためには、チームの中で閉じていた教育資産を全体に広げる必要があると考えました。



谷尾：そこで、OSSのような形で教育コンテンツの拡充・成長を図っています。社内の人間であれば誰でも利用できるようにすることで、教育資産自体の質も向上していきたいと考えています。OSS形式で教育資料を公開する意義としては、大きく三つの効果があると感じています。

一つ目は「継続的な改善」です。利用者からのフィードバックやコントリビュートにより、内容の誤りや不足部分が修正できるため、品質を向上できます。

二つ目は「透明性の確保」です。GitHub上に公開することで、変更履歴や作成者の追跡ができるようになるため、資料の信頼性・透明性が確保されます。

三つ目は「共同作業の促進」です。異なる技術領域や知識を持つ人々が1箇所に集うことで、多面的な教育資産を作ることができます。

社内コミュニティの展開・運用

谷尾：社内コミュニティも積極的に展開しています。ダイキン情報技術大学では、毎年100人前後のDX人材を育てていて、卒業生を各事業部門に配置しています。若手エンジニアをサポートするためには、組織を横断する形での活動が重要です。

そこで、支援活動の一環として、アジャイル内製化チームとプラットフォームチームを中心に、システム開発全般に関する社内コミュニティやAWSなどのクラウドに特化した社内コミュニティを立ち上げています。この二つのコミュニティには、400人以上の社員が参加してくれています。



谷尾：具体的に何をしているのかというと、ワークショップや輪読会、勉強会を開催しています。あとはAWSなどの他社との交流会を開催するほか、講演を依頼することもあります。社内カンファレンスも開催しています。

コミュニティの運営については、各領域でリードするエンジニアが主体となって活動してくれています。こういった活動では、他部門の実情を把握できることが重要だと考えているため、角田のいるプラットフォームチームや営業部門など、さまざまな部門のメンバーに参加してもらっています。

イベントの開催を通して、意欲的な若手をヘッドハンティングしながら、運営メンバーのスケールを目指しています。

仲間を増やして内製化を推し進めていく！

谷尾：更に仲間を増やすため、東京ガス様とコミュニティの立ち上げを進めています。活動のニーズを探るためにアンケートを実施していますので、もしご興味がありましたら、画像のQRコードからご回答いただけますと幸いです。



谷尾：またダイキン工業ではエンジニアの採用にも注力しています。まだまだ古い体制が残っており、外部委託に頼っている部分も多いです。アジャイル内製化チームの領域は、会社全体で見るとまだまだ伸び代があります。

ただ、単にプロダクトを開発するだけではなく、ソフトウェアの根幹ともいえる教育や他部門や他事業部を巻き込んだ事業的な変革にも挑戦できる環境です。

今回の話を聞いてご興味を持たれた方がいらっしゃいましたら、ぜひお気軽にご連絡いただけますと幸いです。というところで、セッションを終了したいと思います。

本日はご静聴ありがとうございました！

▼参考ページ
・コトへの転換で広がる、ビジネスとキャリアの可能性
http://bit.ly/4gPYISG
・世界で伸⻑する空調市場。今、R&Dから新しい価値を描く面白さ
https://bit.ly/4bfuUh1
・部門を越えたDXとデータ活用でソリューションビジネスは加速する
https://bit.ly/4hJKV1p
・テクノロジー‧イノベーションセンター 広報ページ
https://www.daikin.co.jp/tic

アーカイブ動画はこちら

https://findy-tools.io/events/f6c145f804712fc14c4f