前書き
みなさん、ご無沙汰しております。株式会社カナリーのCTOをしておりますどらです。暑い日が続きますが🌞 みなさんいかがお過ごしでしょうか。
前回記事を書いてからカナリーの時が経っていたようです（およそ1年ほど）。思い出してみるとこの1年で色々なことがありました。
- CTOとしてやるべき事の整理
- 大きな技術的負債の返済
- エンジニアの責務の整理
- より気持ちよく働ける環境作りへの取り組み
- 採用の強化
- 等級制度のアップグレード
それぞれしっかりお伝えしようとすると内容としてはどれも濃いものになるのですが、「エンジニアの責務の整理」に関してはカジュアル面談や面接の中でも「これは公開した方がいいんじゃないですか？」「もったいないです」といったご意見を頂くことが多いので、きっと需要があるのだろう、ということで今回改めて記事化してみようかと思います。
大前提として我々の大事にしたい価値観や置かれている状況などを整理した後、具体的にどの様な結論に至ったのかをご説明します。また、最後に今後どの様な拡大の可能性がありそうか、という部分にも触れられればと思います。 エンジニアの責務を考える上で多少なりとも参考になれば幸いです。
背景
1年ほど前、以下の様な課題感がありました。
- エンジニアの業務が多岐にわたる中で、誰が何を担当するのかが分かりにくい
- エンジニアの数が多くなりすぎると目標設定や評価が難しくなる
そこで、どの様な役割があり、それはどこまでを責務の範囲とし、どの様な相互作用をするのか、それらがスケーラブルであるためには何が必要か、といった事を考えようという流れになりました。
当初、私はあまり細かく「あなたはこれ」「あなたはこれ」と明文化するのはあまり積極的ではありませんでした。そうしてしまう事で「いや、それは僕の仕事じゃないんで。」や、あるいは「もっと自由にやりたいのになぁ。。。」といった様に必要以上に硬直化した組織になってしまうのではないかという懸念があったためです。各人がプロダクトがどうあるべきなのか、あるいは会社がどうあるべきなのか、自分が立ち上げた会社のつもりで考える、あるいは考えて行動できるという環境が最も力を発揮できる状態なのではないかと考えていました。 その様な議論があるからこそ、ティール組織[1]という考え方が出てきたり、あるいはGoogleも一時期マネージャーを廃止[2]していたりするのだと思います。
一方で、あまりにやるべき事が多いとそういった形では落ちるボールも出てきてしまいますし、逆に自分が「やってもいい範囲」が分からないと改善策に思い切って取り組むという事もやりにくくなってしまうかもしれません。また、事業にとって必要な仕事というのは必ずしも美しく楽しいものだけではなく、泥臭く面倒なものも含まれる中で、そういった仕事を誰もやらないという形になってしまっては事業が成り立ちません。
この様な状況の中、「できるだけオーナーシップを損なわずに、かと言って無秩序ではなく、一定の責務の範囲で自律的に動けるチームの形」を探求しました。なお、この議論はカナリーの各プロダクトのエンジニアリングの責任者（当時はこの役割に名前がなかった）やVPoE、私などが参加して通称 「責務論」 として議論したものになり、その内容を改めて記事に起こしたのがこのポストになります。
前提
具体的な内容に入る前に、いくつかの前提について整理しておきたいと思います。
- ソフトウェアエンジニアとしての働き方
- マネジメントという言葉の定義
- プロジェクト制
ソフトウェアエンジニアとしての働き方
カナリーではドメインを深く理解しユーザーの体験を第一に考えるエンジニアリングを行っていきたいと考えています。「バックエンド的にはこうだから」とか「フロントエンド的にはこうだから」ではなく、ユーザーに届ける体験としてベストな形を全体最適で考えた上で個別の技術的要素での実現方法がある、という捉え方です。
プロダクトエンジニアという概念
最近では似たような概念として「プロダクトエンジニア」という捉え方がある様です。アセンドさん、hacomonoさんなどの記事を探して頂くとよいかもしれません。参考までに主だったところを貼り付けておきます。
- プロダクトエンジニアとは何者か アセンドさん
- 「プロダクトエンジニア」という役割を定義しましたというお話 hacomonoさん
一方で、「ユーザー体験が第一です」の様に強調すると「まぁ、技術は手段だから」と品質への言い訳の様に聞こえてしまいます。そうではなく、以前の記事でも書いた様に目的志向と技術志向はお互いに欠く事のできない両輪であり、「技術は手段だからてきとーな実装をしてもいい」という話では全くありません。目的を継続的に達成しえる、メンテナンス可能でスケーラブルなシステムを構築していくためには高い技術とそれを実現していく組織・仕組みが必要だと考えます。この点も、議論には組み込む必要がありました。
マネジメントという言葉の定義
いわゆる「マネジメント」という言葉が、私はあまり好きではありません。あまりにふわふわしているし、それ故「あなたは何をマネージしているのですか？」と言われて直球で答えられる人はいないのではないか？と思えてしまうためです。
また、そもそもの話として「人をマネージ（管理）する」という捉え方をした時に、あまりに尊大すぎる概念だと感じるためです。人は誰かが思っている以上に創造的になれますし、私はそういった人の可能性を信じています。それを誰かが「管理」しようなどとすれば逆にボトルネックになりかねません。
話がやや逸れましたが、そんな訳で主にエンジニアリングの文脈で「マネジメント」という言葉を使った時に我々は何を指しているのかというところを明らかにしたいと考えました。
結論として、「マネジメント」は主に以下の項目にブレークダウンできると考えています。なお、こちらの定義は濱田孝治さんのエンジニアリングマネージャーの理想と現実を大いに参考にさせて頂きました。ありがとうございます！🙏🏻
- 人材マネジメント
- 採用、評価、キャリアデザイン
- プロジェクトマネジメント
- 品質、コスト、デリバリー、スコープ
- プロダクトマネジメント（主にエンジニアリングの観点。以下はこの但し書きは省略）
- 品質、生産性
- 技術マネジメント
- 技術的方針、技術選定、セキュリティ、運用ポリシー
- 組織マネジメント
- リーダーシップ、目標設定、役割や責務の設計
- コミュニケーションマネジメント
- チーム内外のコミュニケーション、情報共有、コンフリクトの解消
エンジニアリング観点でのプロダクトマネジメント
プロダクトマネジメントはPdMの責務であるという整理をしている会社も多いと思いますが、こと広い意味での内部品質に関してはPdMはなかなか肌感を持ちづらいという側面はあると思います。例えばコードの品質がどうであるとか、運用がどの程度大変であるか、といった部分に関してはエンジニアの方が実情を把握していると思います。そういった意味で内部品質に関してはエンジニア起点で課題提起をした方が現実味があると考えるので、エンジニアリングのマネジメントの一種としてリストアップしています。
もちろん、それらをどう改善していくか、という部分のリソースの割り振りに関してはPdMと議論していく必要はあると思います。そこにリソースを割けば他の事柄が進まなくなるので、いつ時点で何をやるかというのはプロダクトの方針に大きく影響するためです。
おそらく、会社によってはこれらのうちの何個か、もしくは全部を行う様な方がおり、いわゆるEM（エンジニアリングマネージャー）の様に呼ばれていると思います。会社によってはグループリーダーや部長、といった呼称になっている場合もあるでしょう。より細分化された範囲でエンジニアリングリードやテックリードの様に呼ばれている事もあると思います。
「マネジメント」や「マネージャー」という言葉はこの様に状況によってあまりにブレがあるため、この言葉を使う時は「何の」マネジメントなのかを確認しておく必要があると思います。また、この様にブレークダウンして捉え直して、人の行動を管理するというよりは人がより能力を発揮し最大限プロダクトを伸ばしていくための仕組みや方向性を管理する、と考えれば溜飲も下がる思いです。
この様に捉え直した上で、役割と責務を検討しました。
プロジェクト制
カナリーではプロジェクト制を基本として仕事をしています。簡単に言うとPdMが実現したい事を定義して、そこからプロジェクトが立ち上がり、エンジニアがアサインされて進めていくという流れです。プロジェクトは基本的には一定期間で終了するため、終了したらまた別のプロジェクトがアサインされる形になります。プロジェクトはプロダクトのために実現したい事が起点になり、場合によってはバックエンドをいじったりフロントエンドをいじったりということが発生するため、特定の技術領域内で人員のツリー構造（例えば"フロントエンドチーム"の様な形）を作っていくという考え方とは相性がよくないという側面があります。
プロジェクトにはプロジェクト責任者（簡単に言えばプロジェクトマネージャ）とプロジェクト技術責任者（プロジェクトの実装について責任を持つ人）がおり、場合によって別々の人がアサインされたり、プロジェクトによっては同じ人がアサインされたりしています。
役割と責務を考える上ではこの様な特性も考慮に入れる必要がありました。
役割と責務と権限の概観
以上の様に前提を整理した上で、どの様な役割と責務がよいのかを前述のメンバーで7回ほど議論しました。結論として、以下の様な形に落ち着きました。
役割としては以下の4つを定義しています。
- プロダクトリードエンジニア = Product Lead Engineer = PLE
- コ・プロダクトリードエンジニア = Co-Product Lead Engineer = Co-PLE
- テクニカルリードエンジニア = Technical Lead Engineer = TLE（いわゆるテックリード）
- ソフトウェアエンジニア = Software Engineer = SWE
他に検討した形
なお、他の選択肢としては以下の様なものがありました。部分的にはメリットもあったりはするのですが、総合的に考えると上記の様な形がよいだろうという結論になりました。
- 技術領域基準の階層型
- 技術領域毎のテックリードにSWEが所属し、テックリードが人材マネジメントを行う
- メリット
- 上長が明確で一人あたりの担当SWEの数が限られる
- デメリット
- プロジェクト制と相性が悪い
- ソフトウェアエンジニアとしての働き方と相性が悪い
- チームの状況によって評価者になれる人が不足する可能性がある（テックリードはどちらかと言うと技術領域に強みを持つメンバーを想定しているため）
- 技術領域基準の階層型（横のコミュニケーションあり）
- 1をベースにするが必要に応じてTLEでコミュニケーションを取り目標設定・評価・育成などのすり合わせをする
- メリット
- （1に準ずる）
- プロジェクト次第で複数の技術領域に関わった場合に技術領域毎の評価を拾いやすい
- デメリット
- （1に準ずる）
- 目標設定や評価でコミュニケーションコストが増大する可能性
簡単に言うと、プロダクトリードエンジニアはプロダクトのエンジニアリング全般に責務を持つ人です。コ・プロダクトリードエンジニアは拡大過程にあるチームにおいて、一時的にプロダクトリードエンジニアの責務を分担して補佐する役割です。テクニカルリードエンジニアは特定の技術領域に責任を持ち、品質を担保する役割です。ソフトウェアエンジニアはプロジェクトを推進する主体になります。
基本的には 「プロダクトのエンジニアリング全般に最終的な責任を持つ人は必要だが、一人で前述の全てのマネジメントを行うのは無理なので部分的に委譲・分担する」 という考えで構成しています。
以下、それぞれの概要を記します。
プロダクトリードエンジニア
1サービス（プロダクト）に対して基本的に一人とし、責務の範囲はプロダクトのエンジニアリング全般になります。つまり最終的な責務の範囲としては前述のマネジメント全てになります。しかし、チームのサイズによってはこれは現実的には持続性のないものになる事は想像に難くないと思います。そこで、以下の様に部分的なマネジメントを別のメンバーに委譲・分担します。
- 技術マネジメント→TLE
- プロダクトマネジメントの一部（品質）→TLE
- プロジェクトマネジメント→SWE
- 組織・人材マネジメントの一部→Co-PLE（Co-PLEを置かないパターンもあり得る）
残った部分が、PLEが直接的に担当する部分になります。
- 人材マネジメント
- 組織マネジメント
- コミュニケーションマネジメント
- プロダクトマネジメント
また、これらの責務を全うするため、以下の権限を持つものとします。
- アサイン
- 志向性踏まえた育成と評価の一貫性の観点から、アサインを調整できることは必要と考えます
- 技術領域を横断した方針（設計・実装・運用等）の最終的な決定
- 技術領域を横断した最終的な意思決定に責任を持てる人は必要と考えます
- ただし基本的には各技術領域のTLEに委譲しているので、必要に応じて最終的な意思決定をするイメージです
コ・プロダクトリードエンジニア
チームが拡大の途上にある場合、「ん〜ギリギリ一人だけでもいけるんだけど、近い将来難しくなってきそうだな…」というタイミングがあると思います。具体的にはチームが10人を超えようか、というタイミングではこの様な状態になるのではないかと思います。その様な場合、Co-PLEという形でPLEのマネジメントの一部を補佐する役割を置く事も想定しています。
どの部分をどの様に分担するのかはPLE次第となりますが、分かりやすいケースとしては人材マネジメントの一部を分担する、などが考えられます。目標設定、評価、キャリアデザインなどを補佐するイメージです。
コ・プロダクトリードエンジニアを置く事で、実質的には数十人程度まで対応できる可能性があります（ただこれは弊社で実施した訳ではありません）。
テクニカルリードエンジニア
各技術領域に対して一人とし、責務の範囲は、特定の技術領域の技術マネジメントになります。例えば、以下の様な形になります。
- テクニカルリードエンジニア（バックエンド）
- テクニカルリードエンジニア（フロントエンド）
- テクニカルリードエンジニア（アプリ）
技術マネジメントとは簡単に言えば担当の技術領域の品質を担保する行い、になります。具体的には後ほど見ていきましょう。また、技術マネジメントを行うために以下の権限を持つものとします。
- 技術領域内の方針（設計・実装・運用等）の決定
- 技術領域内の意思決定をリードし責任を持てる人は必要と考えます
- ただし全ての実装方針を自分自身で決める必要はなく、プロジェクトを推進するSWEが主体的に提案をします
- 技術領域を横断してしまいどうしても決めかねるものはPLEと相談します
ソフトウェアエンジニア
1プロジェクトに対して1〜数人がアサインされます。責務の範囲は担当のプロジェクトの実装などのプロジェクトの推進になりますが、前述の通り、場合によってはPLEによってプロジェクト責任者として指名されることがあり、この場合はプロジェクトマネジメントの責務を負うことになります。また、場合によってはPLEによってプロジェクト技術責任者として指名されることがあり、この場合はプロジェクトに対する技術マネジメントの責務を負う事になり設計・実装の提案を行いますが、最終的には各技術領域内の意思決定についてはTLEが行います。
責務の詳細
各役割についてどの様な責務が期待されるか、イメージしやすいようにもう少し詳細に記してみたいと思います。
プロダクトリードエンジニア
人材マネジメント、組織マネジメント、コミュニケーションマネジメント、プロダクトマネジメントの観点から、主な責務は以下の様になると考えています。これ以外の業務を全くしない（してはいけない）という事ではなく、他の責務を他の人に委譲・分担した上で重点を置くべきものは以下になるという整理です。
例えば、カジュアル面談は通常はTLEやSWEに任せるものの、どうしてもアトラクトしたい候補者のカジュアル面談に出席するなどはあり得ます。
| 責務 | 具体的な例や補足 |
|---|---|
| プロダクトの技術的戦略 | • 機械学習の活用などプロダクトに関係する技術的戦略をPdMと協力しつつ検討 |
| 最終的なプロダクトの品質担保 | • 技術領域を横断する技術的指針の決定 • QA（最終確認） • エラー対応（トリアージ、音頭を取る、PdMとのコミュニケーション） |
| プロダクトの生産性 | • トイルの削減 • サービス運営に関わるオペレーション改善 |
| 育成 | • アセスメントと学習計画の立案 • 中長期のキャリアデザインのサポート |
| 目標設定・評価 | • 各メンバーの目標設定サポート • リファレンスを取る • 1次評価の決定 |
| 採用（面接） | • 主に技術面接 |
| プロダクトのオンボーディング | ・チーム新規加入のメンバーに対するオンボーディング |
| リソースの管理 | • 稼働状況の管理 • アサイン |
| コミュニケーションマネジメント | • 問い合わせ対応（トリアージ、音頭を取る、PLE が一次受けをするかどうかは PLE の裁量に任せる） |
| （プロジェクトの推進） | （プロジェクトを担当する場合には自身で実装や設計を行う事もある） |
コ・プロダクトリードエンジニア
基本的にはプロダクトリードエンジニアに準じますが、どこをどの様に分担するかはPLEと相談の上決定します。
テクニカルリードエンジニア
技術領域内の技術マネジメントの観点から、主な責務は以下になると考えています。面談・面接に関しては組織マネジメントにはなるものの、技術マネジメントの観点からも重要だと考えるので、TLEの責務として置いています。
なお、TLEがプロジェクト責任者になる場合もあるし、プロジェクト技術責任者になる場合もあり、設計・実装を全く行わない（行ってはいけない）という事ではありません。プロジェクトを持って他技術分野の実装を含めて行う事自体は問題はないが、責任を持つべきレビューなどが滞らない様に注意すべきという整理です。
| 責務 | 具体的な例や補足 |
|---|---|
| 技術領域内の品質担保 | • 技術領域内の設計・実装方針の決定 • QA（最終確認） • エラー対応 • 設計レビュー • 実装レビュー • モニタリング |
| 技術領域内の生産性 | • 共通コードの整理 （結果として開発におけるトイル削減につながる） ・開発ドキュメントの管理 |
| 採用（面接） | • 主に技術面接 |
| 採用（面談） | • 主に担当領域 |
| 採用（スカウトジャッジ） | • 主に担当領域、領域を跨いでしまうものは適宜、他TLEやPLEと相談 |
| 採用（広報） | ・テックブログ投稿、採用イベント登壇など （TLEメンバーには、より技術的/専門的な内容も期待） |
| 副業/業務委託/インターンメンバーマネジメント | ・チケット進行にあたり、ブロック要因などがないかの把握・サポート ・1on1などにより信頼関係の構築 + アトラクト |
| 各技術領域のオンボーディング | ・チーム新規加入のメンバーに対するオンボーディング |
| （プロジェクトの推進） | （プロジェクトを担当する場合には自身で実装や設計を行う事もある） |
| （評価） | （評価は基本的には行わないが、必要に応じてリファレンスを提供する） |
| （育成） | （PLE に依頼された場合は、必要に応じて育成の一部を担う） |
ソフトウェアエンジニア
プロジェクトを推進するのが主な役割です。PLEに指名された場合はプロジェクト責任者やプロジェクト技術責任者になる場合もあります。
これ以外にも志向性など踏まえて以下の様な責務を持つことがありますが、PLE/TLEと相談して決めます。PLE/TLEは本人のキャリアやキャパシティなど考慮して、適切にストレッチ量を管理します。
- 実装レビュー・設計レビュー
- 採用（面談）
なお、モニタリングに関しては TLE+PLE の責務ではないかという議論も出ましたが、オーナーシップ、ソフトウェアエンジニアとしての働き方など鑑みてリーダー陣で議論した結果、全員でやるべきという結論に至ったのでTLE + PLEのみが行うという形は想定していません。
| 責務 | 具体的な例や補足 |
|---|---|
| プロジェクトの推進 | • QA（テスト、デバッグ） • エラー対応 • 設計 • 実装 • モニタリング • （場合によって、プロジェクト責任者、プロジェクト技術責任者） |
| 運用 | • 手動オペレーション対応 • 問い合わせ対応 |
| 採用（広報） | ・テックブログ投稿、採用イベント登壇など （幅広いトピックの内容を期待） |
拡大の方向性
今後、プロダクトの成長に応じて1プロダクト内にいくつかのサブチームの様なものが発生してくる可能性があると思います。 プロダクト毎に状況が違ったりする可能性があるので現時点で明確な指針までは設けていませんが、以下の様な要素を考慮しながら、拡大に応じてチームを分割していく必要があると考えています。
- 〜10名程度で構成される
- 人数があまりに多くなると組織マネジメントに難が出てくるため、一定の規模感でチームを保つ必要があると考えます
- ただしCo-PLEを置いている場合は評価や育成を分担する事で実質的にはこれ以上のサイズにも対応できる可能性はあります
- 数ヶ月といった期間で終了しない（一定期間存続する）
- 数ヶ月といった単位で開始したり終了したりせず、中長期的に信頼関係を築きノウハウを蓄積して生産性を上げていける様な業務のまとまりに対してチームを構成するのがよいと考えます
- ドメインや業務に凝集性がある
- バックエンドチーム、あるいはフロントエンドチームの様な形で構成してもカバーするドメインは拡大の一方となってしまうので認知的限界があり、ドメインや実際の業務の凝集を考慮して分割していくのがよいと考えます
Co-PLEを置いているプロダクトは拡大過程にあるので、必要に応じてCo-PLE以下をチームとして構成する可能性があります（図中の人数比はただのサンプルで深い意味はありません）。
責務論とアーキテクチャ論の類似性
余談ですが、この様な議論をする中で改めて組織とソフトウェアアーキテクチャの類似性について考えさせられました。みなさんもソフトウェアを構築する際にはクラスやパッケージの責務について考えを巡らすと思います。それらは一体何であって、何に責務を持っていて、何を知っているべきで、何を知るべきではないのか、それらはどうインタラクトすべきなのか、この様な要素はまさに組織の構成を考える上でも全く同じ思考を経ると思います。
また、「凝集」という考え方についても類似性がある様に思います。コアなビジネスロジックに関してはエンティティ層、リポジトリ層、サービス層などシステム上の役割に応じたパッケージングをするのは悪手と言われます[3]。そんなことをしてしまうと業務の凝集が分解され、各システム上の都合によるパッケージにバラバラに配置されてしまい、業務の全体像を把握することが困難になってしまいます。そうではなく、ドメインやコ・ドメインによって分割すべきです。これはチームにおいても同様だと思っており、私がバックエンドチームやフロントエンドチームの様な構成にあまり積極的でない理由も同じです。
システムと人間の大きく違う点としては、「ソフトウェアは責務が理路整然と整理されているのが認識しやすく拡張しやすくデバッグしやすく正義」である一方で、「人間は可能性を限定されると一気に仕事が面白くなくなる」という点があると思います。人間はちょっとくらい難しい方が、ちょっとくらい知らないことの方が、ちょっとくらい人間くさいタスクの方が、ちょっとくらい自分の役割を飛び越えていたとしても目的に即した仕事の方が面白いと感じる、そんなものではないでしょうか？
だからと言って一気に「じゃあティール組織や！」や「じゃあホラクラシーや！」というような話をするつもりはないのですが、全てを厳密に限定していくやり方だけが正しいとは限らず、世の中にはそれらを乗り越えて人間的な働き方をしていこうとしている人たちがいることも認識し、よりよいやり方を模索していく必要もあるのではないでしょうか。
おわりに
いかがでしたでしょうか。みなさんもチームの拡大や業務の増加によって責務のデザインやチームの分割に頭を悩ませることも多いのではないかと思います。冒頭でもお伝えしたようにここに書かれているものは唯一絶対の「答え」の様なものではないですが、多少なりとも皆様の参考になれば幸いです。それでは、また次回お会いしましょう👋🏻
-
詳しくは Reinvent Organization や ティール組織 をご参照ください。 ↩︎
-
詳しくは Lessons From Google's Failed Quest to Run a Business Without Managers をご参照ください。彼らはその後、マネージャーはやはり必要だとして再度導入している様です。 ↩︎
-
詳しくはエリック・エヴァンスのドメイン駆動設計P108〜、あるいは実践ドメイン駆動設計のP319〜などを参照してください。 ↩︎
Discussion