開発組織のリーダーの、広大すぎる責務

あなたがエンジニアリング組織の「マネージャー」としてチームを任された日を覚えているでしょうか。あるいは、仲間と共に立ち上げたばかりの会社で、いきなり「CTO」という肩書を与えられた人もいるかもしれません。

コードを書き、アーキテクチャを設計し、メンバーと1on1で対話し、採用候補者と面接し、事業計画の会議に参加し、プロダクトの障害に対応し、来たる監査に備える……。技術、組織、事業、運用、全てが自身の責任です。日々の開発に追われながら開発体制と事業の足元を固めなくてはならないというやることの多さ、そして「どこかに穴があって将来に顕在化するのではないか」という不安に悩まされるのではないでしょうか。

企業と開発組織の時系列順に、このようなリーダーを悩ませるトピックを眺めてみましょう。

混沌とした立ち上げ期

開発組織の最初の仕事は、MVP（実用最小限の製品）を作り、世に出すことです。この時期のリーダーは誰よりもコードを書き、インフラを構築し、そして時には制作したプロダクトのプレゼンも行う「マルチタスク・プレイヤー」となるでしょう。

同時に、この時期の判断が、今後の開発組織を左右します。どの技術スタックを選ぶのか？　開発基盤はどの程度整備するか？　2人目のエンジニアはどうやって採用し、3人目、4人目にどうやってオンボーディングするのか？

最初のチームを「全員野球」で運営しつつも、将来を見越した意思決定が常に求められます。

地盤固めの成長期

サービスが軌道に乗り、エンジニアは5人、10人と増えていきました。必然的にかつてのスピード感は失われ、チーム間の調整コストは増大していきます。リーダーがプレイヤーとして活躍するだけでは、もはや組織はうまく回りません。プロダクトのアーキテクチャを意識した組織設計や、再現性のある採用のしくみ、エンジニアのモチベーションを上げる適切な評価制度など、明確な意思に基づいた組織作りが必要になります。

さらに、技術的基盤の強化も行わなければなりません。CI/CDパイプライン、テスト戦略、安全なリリース戦略など、複数のチームが自立して開発するための体制の整備が重要になります。一部のシステムをマイクロサービス化するなど、アーキテクチャの見直しも選択肢として考えます。

運用、サポート、そして監査に備える安定期

組織が安定し、事業が成長しても、リーダーの戦いは終わりません。開発するサービスが事業の要になればなるほど、その安定性と信頼性は会社の命運に直結します。エンジニアが疲弊しない持続可能なサポート体制、インシデントマネジメントとそこから学習するPoMo（Postmortem：事後検証）の実践など、SREの思想に基づいた運用体制によってサービスと事業が支えられるでしょう。

上場を目指す企業であれば、監査も避けては通れません。しかし監査への対応は、そのためだけに何か特殊なことをやるわけではありません。日々の優れたエンジニアリングプラクティスが、そのまま強固なガバナンスに繋がります。

将来を見据えた組織運営のためのハンドブック

このように、さまざまな領域をまたいでサービスと組織を開発・運営し、さらにこの先の事業フェーズも見据えなければならないのが開発組織のリーダーです。

『エンジニアリング組織開発　―サステナブルな組織とプロダクト運営の手引き』では、このような縦にも横にも広がる責務を、「⁠サステナブルな開発組織」という1本の軸を通して理解できます。書籍は大きく4つのパートに分けられます。

• 組織作りとリーダーの役割（1・2章）
• 開発組織の設計と運用（3・4章）
• プロダクトの開発と運用（5・6・7章）
• ガバナンスと会計（8章）

初めから通して読めば開発組織を立ち上げるにあたって向き合うべき課題を時系列順に学べますし、自身や所属する組織に不足していると感じているところをつまみ食い的に読むこともできます。新しい組織、新しい事業という、進むべき道が見えない状況の中であなたに並走してくれる、心強いハンドブックになるはずです。