こんにちは！エムスリーキャリアの薬剤師採用支援チームでチームリーダーを務めている諸岡です。
私たちのチームでは現在、少数精鋭の体制でフェーズや技術スタックの異なる複数のプロダクトを運用・開発しています。限られたリソースでこれらを安定成長させるため、私は頑張りすぎないプラットフォームエンジニアリングというアプローチを採用しています。
- 認知負荷を制御し、エンジニアリングの醍醐味を取り戻す
- 頑張りすぎないプラットフォームエンジニアリングとは
- 「外在課題」と「内在課題」の境界線
- 立ち上げ期におけるチーム内プラットフォームエンジニアの役割
- 具体的な活動内容
- 成果：ビジネスロジックへの集中と、AIと共に自走する現代の開発体験
- おわりに
認知負荷を制御し、エンジニアリングの醍醐味を取り戻す
認知心理学において、認知負荷は大きく以下の3つに分類されます。
- 課題内在性認知負荷： ビジネスロジックやドメインの複雑さなど、解決すべき問題そのものの負荷。
- 課題外在性認知負荷： インフラ構成、煩雑なデプロイ手順、ライブラリ更新など、本質に関係のない環境や手順の負荷。
- 学習関連認知負荷： 知識を構築し、新しい技術を自分のものにするためのポジティブな認知活動。
以前の記事 公式noteから紐解く、エムスリーキャリアのエンジニア組織が目指す事業貢献の「本質」 - M3Career Techblog でも発信しましたが、弊社には「課題の本質に向き合って事業そのものを伸ばしたい」と考えるエンジニアが多く集まっています。
そして、ユーザーの課題を解き、複雑なドメインモデルを組み上げている瞬間 -つまり課題内在性認知負荷に向き合っている時こそ、エンジニアの創造性が最も発揮されると私は考えています。
私たちのチームでは、課題外在性認知負荷を極限まで減らし、本質的課題にフルコミットできる環境を創る取り組みを行っています。
頑張りすぎないプラットフォームエンジニアリングとは
少人数のチームにおいて、壮大な社内基盤の構築にリソースを割くことは現実的ではありません。本記事における「頑張りすぎない」の定義を、話さないこと・話すこととして改めて整理します。
本記事で話さないこと
- 基盤構築の具体的な手法： Terraformの書き方や特定のクラウドサービスの構築手順といった技術的な詳細。
- 重厚な内製ツールの開発： 社内専用ポータル（IDP）の構築や、プラットフォーム自体の巨大なプロダクト化。
本記事で話すこと（実践していること）
- 認知資源の適正配置： 限られたチームの「脳内メモリ」を、いかにして事業価値に直結する課題へと割り振るか、という組織設計。
- 解決すべき「外在課題」の選定： 何をプラットフォームエンジニアリングで解決し、何を各エンジニアの裁量として残すべきかという境界線の引き方。
- チーム内のセルフサービス化： プラットフォームエンジニアリングで得た知見をチームの集合知とするためのプロセス。
私たちが実践しているのは、ツール開発そのものではなく、エンジニアの創造性を最大化するための戦略です。
「外在課題」と「内在課題」の境界線
頑張りすぎないプラットフォームエンジニアリングにおいて最も重要なのは、どこに境界線を引くかという意思決定です。私は以下の基準で、プラットフォームエンジニアリングで解決すべき「外在課題」を選定しています。
- 共通性と再現性： 複数のプロダクトで共通して発生し、かつ同じ解決策が適用できるか。（例：CI/CDの基本構成、セキュリティ設定）
- ドメイン知識不要な専門性： ビジネスロジックの理解がなくても、技術スタックの知識だけで解決可能か。（例：インフラのコード化、ライブラリのパッチ適用）
逆に、プロダクト独自の複雑なビジネス要件や、それに伴う新たな技術選定などは、プロダクト担当エンジニアが向き合うべき課題内在性認知負荷としてあえて残します。
立ち上げ期におけるチーム内プラットフォームエンジニアの役割
現在のチーム体制は以下の通りです。
現在は立ち上げフェーズであるため、チームリーダーである私がチーム内SREとして横断課題を吸い上げています。
※SRE（サイト信頼性エンジニアリング）は厳密には誤用ですが、活動内容は似ており、社内で既に浸透している役割のため、このように呼称しています。
一般的にチームリーダーが仕事を巻き取ることは、知識がブラックボックス化するサイロ化のアンチパターンとされることがあります。しかしプラットフォームエンジニアリングの立ち上げ期においては、「何が外在課題で、何が内在課題か」の境界線を見極める意思決定を最速で実行する役割が必要です。
私はこの役割を「作業の代行」ではなく、将来的な委任とセルフサービス化のための先行投資と位置づけています。
具体的な活動内容
単に保守を行うのではなく、各エンジニアが迷わず駆け抜けられる舗装された道路（Paved Road）を作るために、以下の2段階で活動しています。
1. 基盤構築：不確実性とメンテナンスコストの排除
まずは、エンジニアの足を止める「外在性負荷」を徹底的に削ぎ落とすための基盤を整えています。
- レガシーインフラのIaC (Infrastructure as Code) 化： 秘伝のタレ化していた手動設定をTerraformでコード化し、インフラを誰もが触れるツールへ解放。
- セキュリティの標準化： 各プロダクトで個別に検討が必要だったセキュリティ設定を共通化。プロダクト担当エンジニアが意識せずとも、デフォルトで安全な状態を実現可能に。
- DevOpsツール設定の標準化： CI/CDパイプラインや、Sentry・Dependabot等の設定を共通化。
- ライブラリ更新の先行事例： メンテナンスが困難になったライブラリのバージョンアップやリプレースを主導し、モデルケースを作成。
2. チームへのインストール：セルフサービス化への道筋
構築した基盤を「プラットフォームエンジニアだけの持ち物」にせず、チームの集合知に変えていくプロセスです。ここが「サイロ化」を防ぎ、ゴールデンパスを構築するための鍵となります。
- 課題解決プロセスの相互レビュー： 私が作り上げた設定やIaCのコードは、必ずチームメンバーにレビューを依頼します。「なぜこの構成なのか」を他者に説明し、納得してもらうプロセス自体が、知見の移譲になります。
- チーム内共有会での発信： 「次はどう触ればいいのか」というコンテキストをチーム全体にインストールします。単なるマニュアル共有ではなく、背景思想を伝えることで、学習関連認知負荷をポジティブに高めています。
- コードそのものをドキュメントとする： 綺麗に整えられたIaCやCI/CD設定は、それ自体が最高のマニュアルになります。「これを見れば自分でもできそうだ」と思える状態を作ることで、属人化を排したセルフサービス化を促しています。
成果：ビジネスロジックへの集中と、AIと共に自走する現代の開発体験
最大の成果は、プロダクトの年次や経験に関わらず、チーム全員が課題内在性認知負荷、つまり事業を伸ばすための本質的な問いにワクワクしながら取り組めていることです。
特に象徴的だったのは、2025年4月入社の新卒エンジニアの活躍です。彼は外在性負荷に阻害されることなく、入社間もない時期からビジネス議論の最前線に参画しました。
さらに、適切にIaC化されたコードがドキュメントとして機能したことで、彼は現在のコードをコンテキストとしてAIに渡し、AIと壁打ちしながら自力でインフラ設定変更を完遂するという、現代的な自走を見せました。
彼のエントリー プログラムコードは腐るのか？ - M3Career Techblog にもある通り、認知負荷がコントロールされた環境だからこそ、早い段階でエンジニアリングの本質に向き合うことが可能になります。
おわりに
プラットフォームエンジニアリングは、事業価値を最大化し、エンジニアが本来の創造性を発揮するための手段です。最初から巨大なシステムを目指すのではなく、チームのフェーズに合わせ、メンバーが最高に面白い課題に集中できる環境を泥臭く整えていくこと。そのプロセスこそが、強いチームを創ると信じています。
エムスリーキャリアでは、技術を武器にビジネスの深掘りに挑戦したいエンジニアを募集中です。興味を持ってくださった方は、ぜひ採用サイトをご覧ください！
