プラットフォームエンジニアリングに思いを馳せる

本記事作成に至った経緯(Background)

ITD2-1-2のH.Tです。内製開発を頑張っています。
今回はプラットフォームエンジニアリングについて考えつつ、同時にTeam Topology概念からどういった方向性を目指すか、目指すべきかの検討ができるかなと思ったのがモチベーションです。

Platform Engineeringとは

• 開発者の生産性を高めるために、標準化されたツール、自動化されたワークフロー、一貫した環境を備えたプラットフォームを作成および管理する分野です。

IBM: プラットフォーム・エンジニアリングとは

• ソフトウェアの開発とデリバリを目的とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専門分野です。プラットフォームとは、専任のプラットフォーム・チームによりプロダクトとして維持される、ツール／自動化／情報から成るレイヤである。

Gartner: プラットフォーム・エンジニアリングとは

Platform Engineeringの目的

• 開発者に降りかかる認知負荷の軽減と、生産性の向上を目指し、開発者向けのセルフサービス型の基盤を提供する活動

platform-engineeringの目的

Team Topologyとは

「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」という書籍があります。この本の中では、「4種類のチームタイプと3種類のインタラクションモードを適切に組み合わることでハイパフォーマンスな組織を実現することができる。」というのが言及されている重要なポイントの一つです。4種類のチームタイプと3種類のインタラクションモードは何か見ていきましょう。
参考: Team Topologyで色々なものを読み解いてみる

4種類のチームタイプ

どこまでの組織で見るかによって異なると思いますが、ベースはITDの中で見ていきます。

ストリームアラインドチーム

• ビジネスの価値の流れに沿って編成され、顧客に価値を提供することに責任を持つチーム

ITDはここの領域にいますね。具体的には設計とアーキテクチャーや開発コーディングやメトリクスとモニタリングなどは責務になります。厳密にはITDのみではないと思いますが、こういった枠があるんだなと捉えてもらえると良いかなと思ってます。

イネーブリングチーム

• 特定のテクニカル（またはプロダクト）ドメインのスペシャリストで構成され、能力ギャップを埋めることを支援するチーム

「技術的なスペシャリストチームを作りましょうよ。」といった動きがあるとかないとか。なのでこの領域はもしかしたら埋めることができるかなと思います。

コンプリケイテッド・サブシステムチーム

• 特別な知識に大きく依存しているシステムを構築、維持する責任を持つチーム

例えばMCIDやGOD連携といった各アプリケーション側の責務外だが特定の外部連携に必要な開発を支援するチームをITDとしては持ってはいないので埋まってないと思います。

プラットフォームチーム

• ストリームアラインドチームに内部的なサービスを提供することで下位のサービスを開発する必要性を無くし、認知負荷を下げる役割を担うチーム

開発標準化といったPJは存在します。これはアプリケーション構築手法の領域においては認知負荷を下げることができるので埋まっています。ただそれ以外はないので埋める必要がありそうです。

3種類のインタラクションモード

コラボレーション

• 他チームと密接に協力して作業すること。

責任境界が曖昧になったり、コラボ時にチーム数を増やしてはいけないといったところに注意

X-as-a-Service

• チームが別のチームにサービスを提供するモード。（開発者向けツールなど)

責任の所在が明確。チーム間連携もコラボレーションモードよりコミュニケーション部分が限定されるので認知負荷が下がる。サービスを提供するチームは優れたサービスマネジメントが求められます。

ファシリテーション

• 他チームの学習と改善を支援すること

別チームから積極的に作業の一部をファシリテーションまたはコーチしてもらう

認知負荷について

認知負荷というワードがキーになってくるので見ていきましょう。
認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介

認知負荷

• 人間の認知機能の構造と限界に注目して、効果的な学習デザインを考案するための理論

認知負荷理論は上記のような思想で確立されてきた理論です。ではモチベーションはなんでしょう。

• 認知負荷理論の目的は、人間の認知アーキテクチャの能力と限界を考慮することによって、学習成果を予測することである。

はい、冒頭で提示したPlatform Engineeringの概念と類似の概念となっていますね。起源はこちらかもですね。

• 開発者がタスクを完了するためにどれだけ考える必要があるか

エンジニアの業務に落とし込んで考えるなら上記のように捉えるとシンプルです。

本題

さて、ようやく本題になります。「開発者がタスクを完了するためにどれだけ考える必要があるか」という部分について考えます。プロジェクトアサイン時に認知負荷を下げて、業務の開発生産性を上げるにはどうしたらいいでしょうか。組織構造を変えるには莫大なパワーと時間がかかります。組織構造ではなく仕組み構造を作るのが興味を持つポイントです。まずはITDの業務と認知負荷を考えましょう。プラットフォームエンジニアリングのヒントがあるやもしれません。

余談ですが、システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーションという皆大好きO’reillyの本にパターナリスト症候群について言及されていて参考になります。

ITDの業務における認知負荷について

まずは内製開発の仕事についてみていきましょう。
業務を端的に言えば「開発をする」になりますが、開発の性質はかなり異なります。
「要件定義からITDが参入し開発を全部ITDでやる0→1のアプリ開発」「要件定義はベンダーなどITDの外で行い開発から全部ITDでやる0→1のアプリ開発」「アプリ開発をITD以外と協力する開発」「アプリ開発をベンダーが行い、開発業務を引き継いだ開発」
仕事の性質の違いをリスト化できました。これらの認知負荷はかなり異なるように思えます。自分が良く担当する範囲でどんなことが難しかったかを考えてみると良いでしょう。

Team Topologyのプラットフォームチーム部分で触れた開発標準化PJがあるので、特に開発資料整理や開発言語などの統一化の要素はここでは言及しません。それを抜きにしてコーディングに至るまでにいくつ認知負荷を高めるフィルターがあるかワークフローから考えます。自分は以下のように整理しました。
「事業部」→「デジ戦」→「PJチーム」→「コードベース」

まずは事業部です。これはUMUに纏められている事業部ごとの資料があります。ある程度のビジネス理解はここで完了できると思います。またサービス概要は資料として連携させてくるので良いですね。

次にデジ戦です。サイロ解消の動きは自分が入社した当時(2024年2月)からすでに言われていますが、このdocbaseやPJごとのシェアポイントがあります。何を目的にするかで欲しい情報が異なりますが、コーディングという意味ではまだまだ埋めるべき領域があると感じます。ドキュメンテーション戦略が属人的(こういう情報性質の時はこういった資料にするという指針や、docbaseは任意投稿)になっているので、事実としてプラットフォームエンジニアリングできてないと思います。各分野のエキスパートチームはそれぞれ存在していて直接MTGをしてコーディングまで到達していますが、これをどのドメインでも同じようにやって、各組織は各組織で引継ぎしてチーム内で頑張れという運用はHealthyとは言えないですね。「人間の単一障害点をつくらない」という格言がGoogleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセスのバス係数であります。

ITDとしては、社内の基盤システムがどのくらいあり、それに接続するにはどういう仕組みや制約・障壁があって、どういう目的で使えるか。といった網羅的な情報は、アプリ側で使う使わない問わずに整理するべきかと思ってます。

次にPJチーム層の分析です。PJには固有の文化があり培ってきたものが他PJとは違うことはよくあります。PJチームに求める要求・速度が異なるので統一的なルールを築くのが難しいのと同時にITDでは一人が複数のPJに所属しているので複数の運用ルールを実行するジレンマがあるかなと思っています。
これはブランチの運用方法もそうですし、チケットの切り方からレビュー方法まで広範囲の領域になりますね。ここは開発標準化に委任できるかなとも思います。(レビューカルチャーの組織的な醸成も思想バトルが起きそうですがやる必要ありかな)

最後にコードベースの分析です。課題内在性負荷に当たります。課題を解決するにあたり必要となる基礎的な知識（例：プログラミング言語、フレームワークなど）と捉えることもできます。
さてコーディングに到達できました。具体的にどういった要素がエンジニアに負荷を与えるのでしょう。
テストコードの認知負荷 ( WEB+DB PRESS Vol.135 )のコラムの記事を持ってきます。
面白いなと思ったのは、アンチパターンで「情報が少なすぎる」「情報が多すぎる」という点です。
ツッコミを入れたくなりますが、適切な情報量、構造、テストの名前がポイントだと述べられてます。
なにかリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック に通ずるポイントですね。リーダブルコードはエンジニアの中でバイブル化されていてます。(個人的には結構思想強めだし現代に対応できてない部分も出始めているのでアップデート必要かなと思ってます。)
こういった部分を意識するだけでもコードベースの認知負荷は下がります。利用する言語やフレームワークの特徴、どういったディレクトリ構成で、どこまでの責務をどこに持たせて、リーダブルな実装をどうやっていくかという部分は常に勉強していきたいですね。

脱線:面白い話
Cursorにリーダブルコード準拠のルールを設定しようとして上手くいかなかった話
最近のAIコーディング、やりたいことをかなり高精度にやってくれてアプリが完成してしまう。という意味で素晴らしいけど、人間が読みやすいコードか？そもそも人間が読みやすいコードであるべきかという所から議論の余地はありますが、この分野の深堀りが気になってます。

開発における認知負荷の測定方法について

• Once you onboard new people on your project, try to measure the amount of confusion they have (pair programming may help). If they're confused for more than ~40 minutes in a row - you've got things to improve in your code. If you keep the cognitive load low, people can contribute to your codebase within the first few hours of joining your company.
• プロジェクトに新人が加わったら、まずペアプログラミングを行うなどしてどの程度混乱してしまうかを測定するといいとのこと。2人が40分以上混乱している場合、コードに改善の余地があるということです。認知負荷を低く保てば、新入社員でも入社後数時間以内にコードベースに貢献できるようになります。

認知負荷の高いプロジェクトかどうかは、新人にペアリングすてばいい。とInktech CTOのZakirullin氏の考えです。これはとても良いアイデアだなと思ったので、自分がリーダーを務めるチームでは導入していきたいなと思いました。

参考: Cognitive load is what matters

さいごに

エンジニアにとってのPlatform EngineeringはMCPの文脈の凄い近いところにあるのかもしれないと思ってます。解にどういう設計思想でどういったコーディングをして仕様を実現しているかまでを置いた時にどの層のどのドキュメントが必要なのかリバースで考えていけば、Platform Engineeringのヒントになるかもしれませんね。ITDにおいてどういったPlatform Engineering的な概念で資料整理していくと効果的か思いを馳せてみました。

プラットフォームエンジニアリング周りの他会社の事例等はカンファレンスで見ることができるかなと思ってます。

https://www.cnia.io/pek2024