AI 開発への未来へ備えよ！Platform Engineering と GitHub を使った開発

「AI 開発への未来へ備えよ！Platform Engineering と GitHub を使った開発」
Platform Engineering Meetup #2 (2023/05/15) でお話しした内容です。

https://platformengineering.connpass.com/event/280339/

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

13. @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/
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. @yuhattor 21
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. @yuhattor
    Actions Runner Controller
    

    View Slide

34. @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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

40. @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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide