個人のスキルを会社全体の資産へ — コミュニティが育てたダイキン工業の技術文化

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

「傭兵」のような動きを続けるなかで、同じような質問が部署を変えて何度も寄せられることに気づきました。私たちの頭の中にある知見が、組織のなかで共有されていない状態だったのです。

そこで、これまで暗黙的・散逸的だった知識を、社内向けの AWS 設計指針として体系化することにしました。章立ては、サービス選択 / ネットワーク / データ保護 / ログ管理 / 認証認可 / 外部接続のセキュリティ/ 運用監視 / コスト最適化など。単に技術情報をまとめるだけではなく、ダイキンの社内文脈で書き直すということに気をつけて記載しました。

こだわったのは「自分たちで書くこと」でした。外部に委託せず自分の言葉で書ければ、その後の説明展開も自分たちでできます。社内のセキュリティレベル (情報セキュリティ 3 要素 = CIA) と AWS 設計をマッピングし、社内ルールとの整合性も担保しました。

仕組みも工夫しました。AsciiDoc と GitHub を組み合わせて ドキュメントをコードのように管理する形にし、textlint で日本語の静的チェック、PR でのレビュー、GitHub Actions によるリンク切れの検知、GitHub Pages での自動公開、と一通りの CI/CD パイプラインを敷きました。ドキュメント運用そのものが DevOps/SRE 文化を体験する場になったのです。バージョン管理、PR でのレビュー文化、自動化 — 普段ドキュメントを書かないメンバーでも、PR を出しながら自然にこれらの文化に触れることができます。

ただ、こうやってドキュメントを作成したのはいいのですが、その展開先はやはり自分たちが知っている人のみで、なかなか大きく広がっていく形にはなっていませんでした。

そうした課題感を抱えていた頃、社内から「AWS のコミュニティを立ち上げてほしい」という協力要請が私たちのチームに舞い込みました。コミュニティの意義は理解できますし、ドキュメント化で蓄えた知見を広げていく場としてもちょうど良いタイミングだったので、引き受けることにしました。

進めた歩みはこのようなものです。

• 2023 年 6 月 : 企画着手 (とりあえずの仕切りを引き受ける)
• 2023 年 9 月 : 社内 AWS カンファレンスを開催し、コミュニティの立ち上げを告知
• 2023 年 10 月 : 正式に立ち上げ。Microsoft Teams 上で相談受付を開始
• 2024 年 12 月 : ACDC 主催で AWS カンファレンスを開催

名前は ACDC (AWS Community for Daikin Co-workers) としました。電気回路の AC/DC 変換になぞらえて、社内の異なるエリアの人たちが交わる場にしたい、という思いを込めています。空調を主力とする製造業として、ハードウェアに近い言葉を入れたかった、という理由もあります。

立ち上げ直後は手探りでしたが、活動を続けるうちに「ちょっと聞いてみたい」が言える場として認知が広がり、最終的に参加者 200 名を超える組織に育ちました。

ACDC を介して AWS 設計指針などの技術情報を共有していくに従い、AWS を活用していくなかでの全社に対する課題にも取り組む機会が増えてきました。

最初に取り組んだのは、社内セキュリティルールの自動化でした。製造業として保守的なルールが多く、それを AWS 向けに翻訳したチェックリストを IT 部門と合意のうえで作成しました。そのルールを AWS Config に載せ、必要な機能だけに絞った自前のダッシュボードを AWS のマネージドサービスで構築しました。商用の CSPM (Cloud Security Posture Management : クラウド環境のセキュリティ設定を継続的に監視・評価するサービス) を導入するよりはるかに安価で、運用しやすさと拡張性を両立できます。IaC 段階からも検知できるため、セキュリティプロセスを大きくシフトレフトできる仕組みになりました。(こちらの取り組みは、過去の builders.flash 記事にて詳しくご紹介しています)

次に取り組んだのは、AWS アカウントのユーザーや権限の管理です。AWS IAM Identity Center 標準の権限管理だけでは、非エンジニアも多い大企業では一覧化や社内で必要な別情報 (アカウントごとの予算管理情報など) との紐づけが大変でした。そこで私たちが出した答えは、申請フローの GitOps 化です。Microsoft Forms → GitHub Issue → YAML → GitHub Actions → AWS の流れで申請から反映までを自動化し、存在しない予算番号などは YAML スキーマで即弾くなど、社内の運用にも沿った機能を実現できる構成にしました。同じパターンは GitHub 自身の管理にも応用できると気づき、GitHub Copilot などの新規ツール導入時にも活用しています。

これらの仕組みも、コミュニティを通じて広がりつつあります。これは、コミュニティが「なぜこれが必要か」「これで何が楽になるか」を共有できる場になっていたからだと感じています。仕組みだけ作っても使われない、という大企業でのジレンマを乗り越えるヒントがここにあるのではないかと考えています。

3 年前、私たちのチームは「傭兵」のような個人活動で動いていました。今は、社内開発者コミュニティ D2 Lounge を軸に、AWS をはじめとする技術活用が「組織の文化」として根付き始めています。

振り返って言えるのは、少しずつでも「知識の蓄積」を進めてきたことが、今の状況につながったということです。個人活動で積み上げた信頼の貯金、自分たちで書いた設計指針という議論の種があったからこそ、ACDC が立ち上がり、そこから少しずつ DevOps などの高度な仕組みが「みんなのもの」になり、D2 Lounge へと発展していけました。

もう一つ気づいたのは、コミュニティが社内外の橋渡しになるということです。研究所内で閉じていた仕組みが、コミュニティを介して全社 IT 部門と連携し、全社標準として採用されていく。社内で温めた熱量が、AWS Japan の伴走や社外コミュニティとの共創を引き寄せていく。「困りごとを共有できる場」があったからこそ、つながりが生まれたのだと思います。

大企業のなかで何かをボトムアップで広げようとする方に、もし伝えられることがあるとすれば、それはコミュニティを軸に置くという選択肢があることです。仕組みを配るのではなく、議論できる場を先に作る。設計指針のような共有物が議論の種になる。AWS の機能や支援はコミュニティ運営にとってのフックの宝庫なので、遠慮せず使う。そうすれば、製造業のような事業のなかでも、技術文化は少しずつ広がっていきます。

私たちの取り組みも、まだ途中です。これからも、コミュニティを軸に置きながら、少しずつ波を広げていきたいと考えています。