こんにちは、KDDI ソフトウェア技術部の御田です。 実は私、昨年度まで社内の情シスにいたのですが、異動で今月からKDDIアジャイル開発センター（KAG）への出向兼務をしています！

DevOps Days Tokyo 2023にKAG社も出展！

今月4/18(火)・19(水)の2日間、DevOps Days Tokyo 2023という国際カンファレンスにKAGもスポンサーとして出展しており、私は1日目にスタッフとして参加してきました。場所は大崎です。

https://www.devopsdaystokyo.org

ブース対応の合間にセッションも覗いて来ましたので、印象に残った内容をいくつか抜粋して紹介させてください！

GitHub Actions & オートスケールするSelf-hosted runnerで実現する KAGのみんなのCI/CD / 三宅 潤也（KDDIアジャイル開発センター株式会社）

自社メンバーのセッションです。私も異動してきたばかりということもあり、実は初めて知る内容が多く新鮮でした。

https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18400/github-actions-amp-self-hosted-runner-kagcicd

• KAG社内では「スターターズ」という契約案件に紐づかないスクラムチームを組成しており、みんながサッと使えるCI/CD基盤が欲しかった。そこで社内のデファクトスタンダードである「GitHub Actionsのセルフホストランナー」を共用で立ち上げスケールさせることを目論んだ。

• 実現手段としては「actions-runner-controller（k8s方式）」と「terraform-aws-github-runner（ピタゴラ方式）」の2種類ある。

• 現状は有志のコミュニティ活動としてピタゴラ方式でスモールスタートし、並行して大規模利用に向くk8s方式のトライ＆エラーを実施中。

資料も既に公開されていますので是非ご覧ください！

https://speakerdeck.com/jnymyk/cd

DevOps, Development Cadence and the Product Life Cycle / Michael Feathers（R7K Research & Conveyance）

初日の基調講演です。Working Effectively With Legacy Codeという有名な書籍を執筆された方で、会場での著書販売＆生サインも好評のようでした。

https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18187/devops-development-cadence-and-the-product-life-cycle

• ウォーターフォール開発の反省を活かしてアジャイル開発が登場した。少数名のチームで自律的に開発すれば他組織との余計なコミュニケーションも不要。ただし小さなチームでは大規模な開発に対応できない。チームが拡大していくとコミュニケーションコストが増える。コミュニケーションパス（経路数）はチーム人数の2乗になってしまう。

• プロダクトが大きくなった場合、複数の小さなチームを作り、それぞれが開発だけでなくプランニングや意思決定も行うとよい。これにより開発以外のタスクも発生し、緩急ついた「エピソード的な開発」になる。例えばアスリートだってレースの前に休んだりと、常にフル回転しているわけではないのと一緒。

• 開発者が燃え尽きないことが重要。開発チームを機会のように扱ってしまうと上手くいかない。頻繁にリリースしたい気持ちも分かるが、開発者がコーディングに集中できるよう緩急のリズムを作る必要がある。また、たくさんのバックログがある状態は危険。いずれ燃え尽きてしまう。

会場で行われたQAも印象的でした。

Q. 既存のプロセスや古い考え方の残るレガシーなエンタープライズ組織でDevOpsやアジャイルを効果的に浸透させるには？

A. なぜレガシーについて私に質問するんだい？ハハ冗談さ（注：アメリカンジョークです）。ソフトウェアは人のように入れ替わらないため組織よりも長く残りレガシーになりやすい。戦略的に行動し、価値の高い対応を優先すべきだ。何が理解されていないのか見極めること。最初は既存システムに手を入れることから始めるが、摩擦が発生するだろう。小さなチームでの開発と同じように考えることが大事。修正に必要な知識を得てリファクタリングしていくことだ。

肥大化・モノリス化するプロダクト開発組織を自律的で小さなチーム群に変えていく ―kintone開発チームの事例― / 太田 絵一郎さん（サイボウズ株式会社）

前述のマイケルさんの基調講演にも通ずる内容ですが、より泥臭い現場事例にフォーカスしたようなセッションとなっていました。

https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18276/kintone

• キントーンの開発規模が大きくなり、何となく「開発がスムーズに進まない」「チームの魅力が薄い」等の課題が出てきた。具体的に整理すると根本にあったのは「モノや組織の肥大化、モノリス化」「技術のレガシー化」だった。

• いくつか改善を試みたが、中でも「チームを小さく分けた」ことについて紹介。それまで全員で全部を把握するスタイルだったが機能ごとの分業に変えていった。価値提供スピードを高めることが目的のため、技術カットでの分担にはしなかった。また分担するだけでなく、チーム内で決められることを増やした。この段階ではシステム自体のアーキテクチャには手を入れず分業化のみ。

• 結果、各チーム内で自律的な改善が進んだりオーナーシップが強くなったりとメリットもあったが、全チームと横串連携が必要なデザイナーやドキュメント担当の負荷が増えたり課題もあった。ただ分割自体は方針として良さそうだと見えてきた。

質疑応答では、複数チームが同じ基盤を触る場合の線引き方針など、まだまだ模索中の課題も多いというお話もありました。

さいごに

私はこれまでインフラやクラウド系のコミュニティに関わる機会が多かったものの、今回のような開発・アジャイル関連のカンファレンス参加は初めてで新鮮でした。 こういった機会にどんどん参加し、たくさんアウトプットもしていこうと思います！