@yuhattor 1 AI と共創する未来へ備えよ！ Platform Engineering と GitHub を使った開発 服部 佑樹 @yuhattor Board Member, The InnerSource Commons Foundation Customer Success Architect, GitHub

@yuhattor 本⽇のお話 • 他のチームで使⽤できる再利⽤可能なサービスおよびツールをどう提供するのか = GitHub でのコラボレーションをいかに成功させるのか。インナーソースのお話 (15m くらい) • 開発環境の統⼀化に役⽴つ GitHub ツール = GitHub のツールでどうやって Platform Engineering を簡単にするのか (5m くらい) • Platform Engineering の実装をどうやって加速するのか = GitHub Copilot でどうやって「組織」を加速するのか (10m くらい) 2

@yuhattor 他のチームで使⽤できる 再利⽤可能なサービスおよびツールをどう提供するのか 3

@yuhattor 4 プラットフォーム エンジニアリングは 「プラットフォームをプロダクトとして扱う」

@yuhattor プロジェクトとプロダクト 5

@yuhattor 顧客が求めるものを作り、継続的に使われる必要 プラットフォームエンジニアの主要顧客 ⇨ 社内のアプリ/サービス開発者 6

@yuhattor 作るべきもの 7 おれがかんがえた さいきょうの プラットフォーム 顧客が欲しい “使える” プラットフォーム

@yuhattor 作る対象 8 サービス ツール プラットフォーム ポータル 抽象化 • ソフトウェアテンプレート • ソフトウェア • ドキュメンテーション • IaCやAPIで作られる諸々の環境 • CI/CD 環境 • 監視、レポーティング…

@yuhattor DevOps チームのつらみ 9 全部をやらなければいけない… •Infrastructure as Code •CI/CD •テスト •リリースマネジメント •アプリパフォーマンスの監視…

@yuhattor いい感じの プラットフォームができた。 10 ヨシ！

@yuhattor 管理対象 – ツールも含まれる 11 サービス ツール プラットフォーム ポータル 抽象化 • ソフトウェアテンプレート • ソフトウェア • ドキュメンテーション • IaCやAPIで作られる諸々の環境 • CI/CD 環境 • 監視、レポーティング…

@yuhattor 開発者ポータルの管理対象は多岐にわたる 12 インフラ ライブラリ ソフトウェア API サービス テンプレート

@yuhattor インフラを作るだけだと⽚⼿落ちになる可能性がある 13 プラットフォーム エンジニアリングは、ソフトウェア エンジニアリング組織が⼀ 貫性を⾼め、⼀般的なタスクを⾼速化するためのワークフローとツールを設 計、構築、維持するプロセスです。 https://thenewstack.io/platform-engineering/platform-engineering-what-is-it-and-who-does-it/ Backstage ソフトウェアカタログは、エコシステム (サービス、Web サイト、ラ イブラリ、データ パイプラインなど) 内のすべてのソフトウェアの所有権とメタ データを追跡する集中システムです。 https://backstage.io/docs/features/software-catalog/

@yuhattor プラットフォーム提供後の運⽤が重要 14 ユーザーは無限の欲求を持っている • 「テンプレートにないアプリを乗せたい…」 • 「個別要件としてプラットフォーム側にないものを使う必要がある…」 その結果⾒える将来 ⇨ 無限にテンプレートが増える ⇨ 顧客のカスタマイズ領域が増える ⇨ プラットフォームエンジニアリングが破綻する ⇨ プラットフォームエンジニアリングチームが、開発側に「強制」する ⇨ プラットフォームが使われない

@yuhattor もたらされる可能性のある結果 1 15 プラットフォーム チーム 認知や運⽤の負荷をすべて受け取る 開発チーム 開発チーム 開発チーム 開発チーム

@yuhattor もたらされる可能性のある結果 2 16 プラットフォーム チーム プラットフォームを押し付ける 開発チーム 開発チーム 開発チーム 開発チーム

@yuhattor 開発者ポータルを管理する = ⾃律的な開発者エコシステムを作る • 顧客の有⽤なカスタマイズをプラットフォームに戻してもらう⽂化も同時に作り上げる • そうしないと⾃律的にプラットフォームが作られずプラットフォームチームが 「常にプラットフォームを提供する側」になる。 17 開発者 ポータル 👀 ない! • 共有ライブラリ • GitHub Action • GitHub Actions テンプレート • アプリケーションテンプレート • Infrastructure as Code テンプレート 作成 / メンテナンス ソフトウェアカタログに登録 顧客 開発者

@yuhattor インナーソース オープンソースの原則を社内のソフトウェア開発に適⽤すること 18 開発者 ポータル 👀 ない! • 共有ライブラリ • GitHub Action • GitHub Actions テンプレート • アプリケーションテンプレート • Infrastructure as Code テンプレート 作成 / メンテナンス ソフトウェアカタログに登録 顧客 開発者

@yuhattor インナーソースはプラットフォームの運⽤を 「⾃律的なもの」にする鍵 19 XP ソースコードの共同所有 DevOps 組織のサイロを削減する Team Topologies チーム間の相互作⽤ Platform Engineering ⾞輪の再発明をしない InnerSource

@yuhattor The InnerSource Commons Foundation InnerSource Commons は、InnerSourceの実践者の世界最⼤のコミュニティです。 組織という枠の中でソフトウェア開発にオープンソースのベストプラクティスを活⽤する InnerSourceに関するナレッジの創出と共有に特化しています。 2015年に設⽴された InnerSource Commons は、現在 750 以上の企業、学術機 関、政府機関から2000⼈以上の個⼈をサポートしつないでいます。 20

@yuhattor 21

@yuhattor InnerSource Commons Japan InnerSource のワーキンググループ InnerSource リソースの翻訳 InnerSource の勉強会開催 / 動画作成 22

@yuhattor InnerSource の4つの原則 Openness - オープンなプロジェクト リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって⼗分にドキュメント化され発⾒できるようになって いなければなりません。 Transparency - 透明性 プロジェクト/リポジトリとその⽅向性未解決の機能要件機能要件の進捗ホストチームの意思決事項を透明にします。 Prioritized Mentorship - 優先的なメンターシップ Trusted Committer によるホストチームからゲストチームへの優先的なメンターシップにより、ゲストチームの コントリビューター は、ホストチームの プロジェクト/リポジトリについて⼗分理解し、変更できるようにレベルアップされます。 Voluntary Code Contribution - ⾃発的なコードコントリビューション ゲストチームとホストのチームの両⽅からInnerSourceに参加することが、彼らの⾃由意志に基づいて⾏われること 23

@yuhattor よくある誤解 GitHub を使ってるからInnerSourceはできてるでしょ？ 24 InnerSourceの実現には GitHub が必要だという意⾒は、私達が毎⽇戦っている概念です。 GitHub は組織におけるコードの透明性を上げますが、それだけで組織の縦割り問題が解決するわけで はありません。 ほとんどの⼈々は、GitHub の活⽤よりもはるかに⼤変なことに気づいていません。 それは、社内におけるオープンソースの源を⾒つけ、コミュニティとし て育ててゆくことなのです。 コミュニティがソフトウェアを作るのであって他の何者でもないのですが、 ⼤企業にはそれに気づくための全体的なコミュニティに対する センスがないのです。 From “Understanding the Innersource Checklist” by Silona Bonewald, the founding member of the InnerSource Commons.

@yuhattor プラクティス集 - InnerSource Patterns (⼀部) 25 ソフトウェアライフサイクル全体で参加型システムを作成し、デザインドキュメントを公開して早期のディスカッションを促進する。 30⽇の保証期間 社内兼業コントリビューター インナーソースライセンス インナーソースベースドキュメント インナーソースポータル インナーソースデザインドキュメント 基本原則ガイダンスの⽂書化 トラステッドコミッター コントリビューターが30⽇間のサポート付きでバグ修正や機能提案をすることで、両チームの信頼を向上させる。 ボランティアではなく、組織内で正式な契約と合意をすることによって、InnerSourceへの貢献を促す。 組織内でソースコードを共有するための法的枠組みを提供し、新たなコラボレーションオプションを提供する。 InnerSourceプロジェクト情報をインデックス化し、コントリビューターが興味を持つプロジェクトを発⾒しやすくする。 継続的なコントリビューターの仕事を認識し、報酬を与える⽅法を定義する 標準的なプロジェクトドキュメントを提供し、新規コントリビューターに⾃⼰サービスプロセスを提供する。 InnerSourceの主要原則を⽂書化し、広く公開する。 パターン名 パターンの概要

@yuhattor インナーソースのプラクティスはプラットフォームチーム側にも適⽤可能 26

@yuhattor 27 GitHub 上でのコラボレーションを 加速させ、安定させる環境が必要

@yuhattor 開発環境の統⼀化に役⽴つ GitHub ツール 28

開発環境準備の負荷を下げる GitHub Codespaces

devcontainer.jsonの⽣成 ● スクラッチから作成も可能ですし、テン プレートを利⽤することも可能

ポートフォワード ● Codespaces上に⽴てたサーバへのア クセス ● 利⽤例） 動作確認するためにローカルのブラウ ザからCodespaces上のサーバにアク セスする ● 複雑なコンテナアプリも起動可能 https://docs.github.com/ja/codespaces/developing-in-codespaces/forwarding- ports-in-your-codespace

CI/CD 環境の準備負荷を下げる GitHub ARC

@yuhattor Actions Runner Controller

@yuhattor Container Modes No Container Mode Use the runner container to run your workflows Docker in Docker Mode Creates a runner pod with a dind sidecar pod Kubernetes Mode Creates a runner pod and launches additional pod to execute job steps If you specify a container image your job will fail Allows both container and non- container workflows Requires privileged mode - A potential security risk By default if you do NOT specify a container image your job will fail (Set env variable to allow jobs on runner pod) Requires persistent volumes to pass work from runner to worker pod

@yuhattor 35 Platform Engineering を AI でどうやって加速するのか

@yuhattor 🤖 AIに関して、プラットフォームチームの観点 36

@yuhattor GitHub Copilot の活躍領域の例 37 ⾃然⾔語 ロー コンテキスト コメント to Code (テンプレーティングを含む) ドキュメント to Code (設計ドキュメント) コメント to Code (リファクタリング / 微調整) コーディング ⽇々のコーディングの補完 専⾨技術/ハイコンテキストな領域に おけるコーディング⽀援 調査 / デバッグ / 最適化 デバッグ / リファクタリング ハイ コンテキスト

@yuhattor ⽇々のエンジニアリング効率化で⼤幅な時間節約は可能 コメント ot Code /⽇々のコーディングの補完 / 繰り返し / 定型的な作業 などのコーディング業務および、 それらの作業の中での ドキュメントリーディング / 検索の時間を短縮可能 コンテキストがすべて ビジネスやプロジェクト・設計に関するコンテキスト: 背後にある事柄や⼈間関係・規制の把握 技術的なコンテキスト: フレームワークやライブラリ、現在のファイル内の変数、関連ファイルやスコープなどの要因 経験や知識が豊富な開発者はさらにブーストされる AI からの提案を評価する能⼒、AI に⽂脈にあった指令を出せる開発者は有利 38 GitHub Copilot は魔法のようだが、スキルも必要

@yuhattor コンテキストレスな設計 • API / ライブラリのモジュール化やパッケージ化 • Terraform のモジュール化 • システムのマイクロサービス化 39

@yuhattor • 裏で .csv を開いているだけで⼀瞬でコード化 • ビジネスサイドも PowerPoint や Excel ではなく Markdown や csv で保持する必要性 40 個⼈の開発が変わる ⇨ 組織の開発も変わらなければいけない 精度の⾼い提案のためには、AI が読めるファイルである必要がある。 参考DB 厚⽣労働省 「シームレスな健康情報活⽤基盤実証事業」 地域連携システム https://www.mhlw.go.jp/seisakunitsuite/bunya/kenkou_iryou/iryou/johoka/johokatsuyou/dl/tenpu03_06.pdf

@yuhattor 41 組織の開発も変わらなければいけない GitHub Copilot X = AI がエディタを⾶び出す = 開発プロセスにAIが⼊る GitHub Copilot for PR GitHub Copilot for Docs GitHub Copilot for PR

@yuhattor • 開発者個⼈の環境に AI が介在する • 開発プロセスの中に、AI が介在する • AI が読める内容を、AI がアクセスできる場所に格納する必要性 42 Copilot との協業はエンジニアだけにとどまらない チームとしてドキュメントドリブンな開発ができる組織が有利 Markdown, CSV などでコードと⼀緒に格納可能であると有利

@yuhattor プラットフォームエンジニアリングに GitHub のツールを活⽤しよう GitHub Codespaces, GitHub ARC は最適です。 プラットフォームを⾃律的に繁栄させるためにはインナーソースが鍵 ⼈を考慮した⽂化を育み、社内でオープンソースの源を⾒つけ、コミュニティとして育てよう AI と協業できるような開発スタイルを あなたの企業の競争⼒の源泉をコードに埋め込み、シナジーを⽣み出し、エコシステムを強化しよう 43 Key Takeaways

@yuhattor InnerSource Commons もよろしくお願いします 44 https://aka.ms/iscslack #jp-general