スタートアップにおけるモダンなスタッフエンジニアリング
(chadxz.dev)- スタートアップ環境で DevOps、スタッフエンジニアリング、プラットフォームエンジニアリングの概念を効果的に適用した事例を共有
- 発表者の Chad McElligott は Smartrr のシニアスタッフエンジニアで、Shopify ベースのサブスクリプションおよびロイヤルティサービスを提供する企業に所属
- スタートアップ特有の文化と要件に合わせたエンジニアリング手法を提案
[中核概念]
DevOps
- DevOps の定義は人によって異なり、ある人にとっては職種であり、別の人にとっては働き方である
- "DevOps as No Ops" という概念は、ソフトウェアエンジニアが Ops 関連のあらゆる業務を自ら処理することを意味する
- DevOps とは、協調のマインドセット、反復的で手作業の多い仕事（ toil ）の自動化、最新ツールの活用を通じて、顧客に価値を素早く届けることである
- クラウド活用、インフラのコード化、CI/CD パイプライン構築といった技術的要素だけでなく、コミュニケーションと協業の障壁を取り払い、より良い結果を達成することが重要である
プラットフォームエンジニアリング
- Platform Engineering は、開発者の認知負荷を下げるための技術的アプローチである
- 目的は、プロダクト開発速度とシステム安定性を同時に高めることであり、開発者の活動を支える基本的な構成要素を提供する
- 大企業がプラットフォームエンジニアリングチームを構築し、効率を高めて開発者体験を改善する事例が増えている
- Manuel Pais と Matthew Skelton の著書 Team Topologies を通じて広く知られるようになり、エンジニアリング能力強化の事例もさまざまな媒体で確認できる
スタッフエンジニアリング
- Staff Engineering は、特定のマインドセットやスキルではなく、組織内でソフトウェアエンジニアが担う 役割 である
- Senior Software Engineer の次のキャリア段階であり、ソフトウェアエンジニアリングにおけるサーバントリーダーシップとも説明できる
- Staff+ エンジニアは、個人の作業だけでなく組織全体へと責任範囲を広げ、マネージャーや VP と協働しながら実行面と視点を提供する
- Will Larson の著書 Staff Engineer では、Staff の役割を 4 つのアーキタイプ（Architect、Right Hand、Tech Lead、Fixer）に分けて説明している
[スタートアップ文化]
- ベンチャー投資を基盤とするスタートアップでは、成長のために支出が収益を上回ることが多い
- 投資で確保した資本を "ランウェイ" として活用して急成長を目指し、ランウェイが尽きる前に成長と収益性を達成しなければならない
- このような環境は、2 つの重要な文化的特性を生み出す
- 無駄にできる時間がない
- スタートアップでは時間の浪費がとりわけ致命的である
- 開発チームは組織の戦略目標に焦点を合わせ、ランウェイの範囲内で実行しなければならない
- 各メンバーは、自分の活動が目標に合致しているかを随時確認し、必要であれば再調整する必要がある
- 実験が失敗しても、学習のための仕組みがあり、望んだ教訓を得られたのであれば、それは無駄ではない
- 全員が複数の役割を担う
- 小規模な組織では、やるべきことは多い一方で、それを担う人が足りない
- たとえばフロントエンド開発者が、プロダクトデザイナー、テクニカルライター、プロダクトマネージャー、品質保証、サードパーティ統合担当など複数の役割を兼ねることがある
- 顧客体験を改善する新しいアイデアが出た場合、その提案者自身がプロトタイプを作成したり、実現に責任を負ったりすることもある
- 無駄にできる時間がない
- こうした文化的特性は、プロダクト開発グループ、特にソフトウェアエンジニアリングリーダーに必要な能力を左右する
- また、DevOps、Platform Engineering、Staff Engineering がスタートアップ環境にどう適応すべきかについてのヒントも与えてくれる
[スタートアップ文化に自分のエンジニアリング原則（Tenet）を適用する]
スタートアップにおける DevOps
- スタートアップではプロセスを変更しやすい。
- 人数が少ないため、新しい行動様式を導入する際の大きな障害がない
- ツールを基準にプロセスを調整することが最適な結果につながる
- 硬直したプロセスを維持すると、ツールをカスタマイズしたり追加のソフトウェアを開発したりする必要が生じ、時間が無駄になる
- カスタムツールは可能な限り避けるべきである
- サーバーレスインフラ、SaaS ツール、オープンソースライブラリなどを活用するのが望ましい
- 技術の一般的な流れには合わせつつ、差別化された競争優位をもたらさない場合には技術をカスタマイズすべきではない
- 参考: Martin Fowler の Utility vs Strategic Dichotomy
- "退屈な技術" を選ぶべきである
- チームが不慣れだったり、コミュニティが小さかったりするソリューションに大きなリスクを賭けるべきではない
- 問題が起きたときに、オンラインで容易に解決策を見つけられる技術を選ぶべきである
- Dan McKinley の boringtechnology.club では、この考えを詳しく説明した講演を確認できる
スタートアップにおける Platform Engineering
- Rebecca Murphey の Engineering Unblocked podcast で言及されている内容:
- "企業の開発者体験は、それが設計されていようといまいと、1 つのプロダクトである"
- スタートアップ規模であっても、監視、デプロイ、エラー追跡、ログ確認、機能フラグの切り替えは依然として必要である
- 重要な問いは「これらの作業は苦痛か？」である
- Platform Engineering はスタートアップではパートタイムの役割である
- 初期には統合テスト環境が必要かもしれないが、後には優先順位が下がる可能性がある
- プラットフォームエンジニアリングの役割は、必要なときにだけ果たされることになる
- 長期的なプラットフォームプロジェクトを進める余裕はない
- その代わり、小さな単位の作業を通じて価値ある要素を実装しなければならない
- 大きな全体像とビジョンはチームと共有しつつ、小さなピース同士がどうつながるかを理解してもらうことが重要である
- スタートアップのプラットフォーム作業は、新しい生産性とアプローチを切り開く過程である
- 既存ソフトウェアから最新ツールへ移行するのではなく、そもそも存在しなかった要素を新たに構築する 作業が大半である
- 何ができるかよりも、何をすべきか を決めることが重要である
- 現在の組織の問題、または近い将来の問題を解決する作業に集中すべきである
- 実務経験、エンジニアとの対話、レトロスペクティブのフィードバック、SDLC（ソフトウェア開発ライフサイクル）指標の分析などを通じて、必要な作業を把握する必要がある
- ときにはプラットフォーム作業を後回しにして、ほかの必要事項に集中したほうがよい場合もある
- 柔軟にアプローチすることが鍵である
スタートアップにおける Staff Engineering
- Staff Engineer の役割はスタートアップ環境に適している
- 深い技術的専門性、広い影響力を求める志向、ビジネス課題を解決するために必要な場所へ進んで関わる姿勢が、スタートアップによく合う
- 大規模組織では、"どこに技術的負債が埋もれているかを知っている" という表現がある
- Staff Engineer は、その知識を持つ人を見つけて整理し、前進するための判断を導き出す
- スタートアップでは技術的負債や問題が明確に表れている
- Staff Engineer は、この混沌を整理し、長期的に組織の助けとなるソリューションを構築することで大きな影響を与えられる
- スタートアップでは Staff Engineer が 1 つの アーキタイプ にとどまることはできない
- 組織規模が小さいため、実行を含む多様な活動を担う必要がある
- アーキテクチャ設計、プロジェクトリード、戦術的な作業の遂行だけでなく、改善アイデアを自ら導き出して実行しなければならない
- 柔軟性と主体的な責任感が、スタートアップの Staff+ エンジニアに不可欠な特性である
- Staff+ エンジニアの重要な役割の 1 つは、メンタリングとスポンサーシップ である
- 特にスタートアップのジュニア人材にとって、重要な支援と方向性を提供する
- Staff Engineer は、このような支援を通じてチームの成長を促進し、組織の能力を強化する
[スタートアップにおけるモダンなスタッフエンジニアリングの適用]
ストーリー 1 of 2 - "Improving DevEx by Removing a Merge Freeze"
問題の状況
- 既存のQAプロセス:
- リリース前の2〜3日間、"merge freeze" を実施し、QAチームが手動でリグレッションテストを実行
- 発見されたバグは即時修正され、mainブランチにマージ
- 開発者は新しいパッチをビルドするが、マージリクエストはリリース後まで保留しなければならない
- 欠点:
- 手動リグレッションテストは遅く、予測不可能
- マージ遅延によって merge conflict の発生頻度が高い
- 開発者の生産性とコラボレーションが低下
解決策
- インフラコードをMonorepoに統合
- Terraformプロジェクトをアプリケーションコードと同じリポジトリに統合
- 自動化されたlintingおよび依存関係管理ツールに接続し、開発者がインフラをより扱いやすくする
- すべての環境をTerraformで管理
- 新しい環境だけでなく、既存のステージング環境と本番環境もTerraformで管理
- 同一のインフラ定義に異なる変数を適用し、環境間の一貫性を維持
- CI/CDプロセスの簡素化
- 既存のGitLab Auto DevOpsテンプレートはカスタマイズが多く複雑化していた
- Auto DevOpsを削除し、新しい
.gitlab-ci.ymlファイルを明確に定義 - コマンドの大半をMakefileに移し、手動実行も可能なように設計
- Secrets管理の改善
- GitLabとの結合度を下げるため、アプリケーションシークレットを Google Cloud Secrets Manager に移行
- Kubernetes ConfigMapを自動更新するようデプロイスクリプトを修正
- スコープ外の作業
- アプリケーションはmonolith構造でKubernetes上で稼働中
- これを変更する作業は遅延とリスクを招く可能性があるため維持
- Terraform自動化パイプラインは構築しない
- インフラ変更が比較的少ないため手動プロセスを維持
- Kubernetesネイティブのシークレットアクセス方式も保留
- アプリケーションはmonolith構造でKubernetes上で稼働中
結果と成果
- 新しいテスト環境をデプロイし、QAチームが独立してリグレッションテストを実行できるようになった
- merge freezeの撤廃 により、開発者は自由にmainブランチへ変更をマージ可能
- リリースプロセスが簡素化され、チーム全体のスピードが向上
適用された原則
- Staff Engineeringの原則
- さまざまなチームと協業しながらプロジェクトをリード
- "Tech Lead" の役割を担い、プロジェクトを完遂に導く
- CI/CDおよびインフラ改善により、チームの理解度とアクセスしやすさを向上
- Platform Engineeringの原則
- DevOpsプロジェクトをプラットフォームプロジェクトへ拡張
- すべてのインフラをコードで管理し、環境間の一貫性を確保
- 現実的なトレードオフ を通じてプロジェクトのスコープを調整
- DevOpsの原則
- インフラをコードで管理 することで、クラウドインフラを一貫して運用
- リリースプロセスを改善し、新しいツールで開発速度を高める
- RFC(Request For Comment)文書フォーマットを導入し、意思決定プロセスの包摂性を強化
結論
- QAチームはより安定した環境で自動テストを実行できるようになった
- 開発者は merge freeze なしで継続的な開発が可能となり、コラボレーションが強化された
- より良いツールとプロセスを通じて、組織の生産性が改善された
- 今後はプレビュー環境の構築やリグレッションテスト自動化のような作業も追加で進めたい
ストーリー 2 of 2 - "Iterating Towards a Productive Engineering Process"
問題の状況
- 既存のプロセス:
- すべてのチームメンバーが 1つのボード で作業し、毎日進捗を共有
- 多くの人が自分の順番でないときは集中せず、"チェックアウト" 状態になっていた
- 機能開発の責任が分散し、プロダクトマネージャーが最終責任を負うことが多かった
- 技術アーキテクチャに対する明確な理解も不足
- 目標:
- より良い協業とソフトウェア開発プロセスを構築するため、さまざまな実験を実施
- 実験1: 短命な機能チーム(Short-lived Feature Teams)
- 目的: 機能開発のライフサイクル全体に対する責任感をエンジニアに持たせる
- 方法:
- 各機能にリーダーを割り当て、バックエンド、フロントエンド、QAなどで構成されたチームを編成
- 結果:
- チームメンバーの責任感は改善したが、全員がリーダー役に適していたり望んでいたわけではなかった
- その後 "固定チームモデル" へ移行し、"Squads" を構成して各チームが自律的に計画とふりかえりを実施
- 実験2: Epic Kickoff Documents
- 目的: 要件を明確化し、プロジェクトのスコープとアプローチについてチームの合意を導く
- 方法:
- 提供されたテンプレートを使い、すべてのメンバーがミーティングで文書を作成
- 結果:
- チームのコミュニケーションが改善され、プロジェクト初期からより良く協業できるようになった
- チームメンバーはこのミーティングを 価値のある時間 と評価
- 実験3: グループコードレビュー(Group Code Review)
- 目的: コードレビュー時間の短縮、コードに関する議論の活性化、エンジニア間の技術共有
- 方法:
- 週2回の Slack Huddle で1時間のコードレビューセッションを実施
- 開発者が画面共有しながらPRを説明し、参加者がフィードバックを提供
- 結果:
- コードレビューに要する時間が大幅に短縮され、Inbox 0 状態を維持
- コードに関する議論を通じて、開発者同士が互いに学び尊重する文化が形成された
- コードレビュー以外でも ペアプログラミング の利点がチームに紹介された
適用された原則
- Staff Engineeringの原則
- エンジニアリングマネージャー不在時に プロセス改善をリード
- 継続的改善の文化をチームに導入し、アジャイルプロセス を通じて自律的な協業を強化
- チームが 停滞したプロセス を打ち破り、より良い方法を見つけられるよう支援
- Platform Engineeringの原則
- ツールだけでなく プロセスもプラットフォームの一部 と見なす
- 非効率なプロセスはチームの生産性を損なうため、これを改善することが重要
- 無駄を排除 するプロセス変更は、ツール改善と同じくらい大きな影響を持ちうる
- DevOpsの原則
- CALMSの原則: コラボレーション(Collaboration)、自動化(Automation)、リーン(Lean)、測定(Measurement)、共有(Sharing)
- リーン(Lean)プロセスを通じて 無駄を排除 し、価値を迅速に届ける
- アジャイルプロセスを通じて、チームが継続的に改善できるよう支援
- CALMSの原則: コラボレーション(Collaboration)、自動化(Automation)、リーン(Lean)、測定(Measurement)、共有(Sharing)
結論
- チームのプロセスを実験的に改善することで、生産性と協業が大きく向上した
- 低コスト・高効率 の改善によって、チーム全体の開発者体験が向上した
- 自分たちのプロセスを批判的に見直し、改善の余地を探ることを強く推奨
[締めくくり]
- スタートアップ環境で働きながら、多様な課題を解決し、ソリューションを実現する過程で、専門性と情熱の両方を発揮できる
- 時間的制約があるため、実用主義的なアプローチを養うよい機会となり、会社の初期段階で大きな影響力を発揮できる
- 現代的なソフトウェアエンジニアリングのアプローチを適用し、会社の成功の基盤を築くことができる
-
Staff Engineeringとスタートアップ
- Staff Engineerには、幅と深さの両方を備えた経験が求められる
- スタートアップはStaff+エンジニアが技術的知識を広げ、新しい領域を探求できる機会を提供する
- 例: バックエンドエンジニアがReactやBigQueryのような技術を学べる
-
Platform Engineeringとスタートアップ
- スタートアップにおけるPlatform Engineeringは、規模によって異なる
- 1:1コミュニケーションを通じて開発者のペインポイントを把握し、小さなプロジェクトで開発者体験（DevEx）を改善できる
- 迅速なフィードバックループを構築して開発プロセスを改善し、開発者が将来的に自力で問題を解決できるよう支援すべきである
- **ソフトウェア開発ライフサイクル（SDLC）**の基本事項を業界標準のツールと手法で満たすことが重要である
- スタートアップでは、Platform Engineeringは専任業務ではなく、必要に応じて適用する技術的アプローチである
- 「企業の開発者体験はひとつの製品」であることを念頭に置き、その設計に時間を割くべきである
-
DevOpsとスタートアップ
- DevOpsはスタートアップでも非常に重要な役割を果たす
- 文化、プロセス、ツールを通じて、顧客により速く価値を届け、より良い作業環境を作ることが核心である
- DevOpsを通じて会社の効率を高め、協業文化を定着させる過程は非常にやりがいがある
- スタートアップでDevOpsに情熱を持つエンジニアは、自身の技術と経験を通じて大きく貢献できる
- スタートアップ環境は新たな挑戦と学びの機会に満ちており、これを通じてエンジニアはさらに成長し、意義ある成果を生み出せる
3件のコメント
DevOpsへの追悼文
DevOpsエンジニアよりも多く稼ぐプラットフォームエンジニア
スタッフ（Staff）エンジニアとは何か？
今後スタートアップで必要となるエンジニアリングの役割が、うまく定義されていると思います。以前は明確な区分なく行っていたエンジニアリングが、きちんと整理されているように感じます。自分自身も、どのエンジニアリングを担当しているのか、今後どの分野を伸ばしたいのかを具体的に把握できそうです。スタートアップでも体系化されたエンジニアリング体制を整え、必要なエンジニアを適切に採用できそうですね。