株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです．
Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。
本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコンテキストで特に意識しているトピックやセオリーを，エンジニアリング組織構築に馴染みの無い人へ動機なども含めて説明することを主眼に記述しています．*1 この記事の内容は所属する企業の公式見解ではなく，個人的に仕事をする上で大事にしていることにとどまっていることにだけご留意ください．
この記事は，Engineering Manager Advent Calendar 2018 の13日目の記事です．どちらかと言うとソフトスキルとかピープルマネジメントとかエンジニアリングマネージャーのキャリアとかの話が多い今回の Advent Calendar ですが，僕の記事はどちらかと言うとセオリーの棚卸しって感じですね．
目次
- 目次
- リソース効率とフロー効率, 制約理論
- 職能組織と機能チーム*2
- 組織の寿命，プロダクトとプロジェクト
- プロダクトの境界とコミュニケーション
- SoE と SoR によるバイモーダル戦略
- これらを実際の組織運営・組織構築に応用すると？
リソース効率とフロー効率, 制約理論
プロセスを設計する上で，「効率の良さ」を求める際に，その「効率の良さ」はどういう側面のものなの？という話．今年の頭に前職の後輩たちにレクチャーした話をこのブログに書いた けど，昨年くらいからよくエンジニアリング組織のマネージメントをやってる人の文脈で聞くようになった概念かなと思います．
リソース効率とは，プロセスを構成するパーツの稼働率の高さを指し，一方でフロー効率とはプロセスを流れる価値を付加する対象 (flow unit) に価値が付与される活動が完了するまでの時間の短さを指します．
非常に単純化した例を挙げれば，1人で取り組めば3日かかり，3人で取り掛かれば1.5日で終わるタスクがあったときに，3人が別々のタスクに3日間取り組み続けるのがリソース効率を重視した配置です．この場合，すべてのタスクが3日目に完了します．また，すべてのタスクを一人で行うので知識移転も発生しません．
一方で，5日間かけて，3人一緒になって1つのタスクを順々に消化していくのがフロー効率を重視した配置です．タスク A は2日目に完成しています．
もちろん現実世界ではこんな単純に話がいくわけではありません．今回の例だと3倍の人を一つのタスクに投入しても1.5倍の速度しか出ませんでしたが，人数を投入するのが有効なのか，一人で淡々と取り組んだほうが早く終わるタスクなのかも場合によります．
リソース効率とフロー効率どちらを取るかのゼロイチの話でもなく，また，単純にタスクを完遂するという観点以外にもメンバーの感情面や育成という観点も考慮する必要があります．今回の例だと複数タスクの依存関係なども考慮していません．
事業やプロダクトによってどちらの側面をどれくらい重視するかが異なるかと思いますが，何も考えずにリソース効率を上げるアプローチを取っても，プロセスのボトルネック自体を解消せずにフロー効率を向上させないと，プロセス全体の生産性は上がりません．このことを「制約理論」と呼びます．
エンジニアリング組織の設計と運用も，プロダクトを生み出すためのプロセスを設計するという話なので，制約理論やリソース効率とフロー効率の違いはしっかりと意識するべきです．
職能組織と機能チーム*2
チーム・グループを作る上で何を軸とするかの話です．リソース効率・フロー効率とも綿密に結びつく話です．
職能組織
似た技能を持っているメンバーを集めて作られたチームを職能組織と呼びます．*3
似た技能を持つメンバーが集まるので，メンバー同士の切磋琢磨がワークして技能スキルが上がりやすいというメリットがあります．また，労働市場で希少性のある技能や，特殊性のある技能，会社内の複数部署やチームに横断して仕組みを整えることが効果的だと判断されるケースでこの形態が取られるケースが多いのではないでしょうか．例えばデータ分析や機械学習，人工知能に基づいた技能を持つエンジニアの特殊部隊や，ITインフラの構築・運用に長けたエンジニアのチームといったものを想像すると良いかもしれません．
職能組織が多かったり，職能組織間の境界がしっかりと設定されていると，複数の職能チームが必要なプロジェクトを完遂するためのリソース効率は高めやすい反面，チームの間での情報伝達のオーバーヘッドがかかるなどの理由でフロー効率は下がりやすい傾向があるかと思います．
機能チーム
職能を横断し，顧客に提供する価値を作る単位に基づいて組成する組織を機能チーム (Feature Team) と呼びます．
顧客に提供する価値の最大化にフォーカスが当たりやすいのでフロー効率は高く保ちやすい一方で，チームの中のすべての職能が常に必要とされるとは限らないという点でリソース効率が落ちがちであるという特徴があります．
また，一言で「職能を横断する」と言っても，どの程度まで横断するかも重要になります．例えば，エンジニアの中でフロントエンドもバックエンドもインフラエンジニアもデータ分析も合わせるというレベルもあれば，さらにビジネスサイドのメンバーまで一つのチームとする，という職能横断も考えられます．職能横断の範囲が広ければ広いほど最終的な顧客の価値にフォーカスした組織が作れますが，その分マネジメントの難易度は上がるでしょう．
マトリクス組織
職能組織と機能チームの両方のメリットを享受するために，両軸を兼ね備えたマトリクス組織という構造がしばしば見られます．
マトリクス組織は，人事評価や指揮系統などの点で難易度が高く，しっかりとした制度設計や取り決めがないと難しいとされます．
例えば上述の図の場合，赤い ☆ の部分に属しているプロダクト A のエンジニアは，プロダクトAのマネージャーとエンジニア組織のマネージャーの両方から評価や指示を受けたりしますが，マネージャー同士の評価や指示が矛盾したときにはどうすればよいかはどう判断すればよいでしょうか？また，メンバーの配置はどちらのマネージャーが主導権を握ればよいでしょうか？決まりが明確になければ社内政治や縄張り争いのようなものに発展してしまうのも想像に難くありません．
組織の寿命，プロダクトとプロジェクト
組織の寿命を長くするためにどうするか？そのために，極力 プロジェクトではなくプロダクトで思考しよう ，という話です．
Stable Team
ここでいう Stable つまり「安定」とは，比較的長い時間に渡って顔ぶれが大きく変わらないことを指します．なるべくメンバーの増減が起きないようにする動機は様々あります．
- ステークホルダーを含むチームの外部が，チームの誰にコミュニケーションを取ればよいかがわかりやすくなる
- 将来の予測を立てる上での不確実性を減らすことが出来る
- メンバー同士の関係も長く存続するので，チーム内のコミュニケーションコストが下がる傾向がある
- ブルックスの法則*4 に遭遇することを防ぎやすくなる
もちろん，そういうことを言っていられないような状況も多々発生しますが，なるべく組織の寿命を長くし，その組織に属するメンバーの顔ぶれを安定させるにはどうしたらよいか，がソフトウェア開発の文脈では重要になるのではないかと思います．
プロジェクトに基づく組織
プロジェクトとは，ある事業の中で期限と範囲を決めて完遂するための計画と言えます．事業が続いても，事業の中のある計画が完了すればプロジェクトは終了します．
基本的に，プロジェクトのために組成された組織は，プロジェクトが終了すれば解散します．上手に組織を設計しなければ，プロジェクトが終了した後のことはプロジェクトにおける考慮から外され，部分最適が生じることもあるでしょう．逆に，何より完遂することが大事なときにはプロジェクトベースの組織を作れば良いとも言えます．
極めて単純化した例を示すと，「地球を出発し，月の周りを周回して地球に帰還する」という活動は，どのようにこの宇宙旅行を完遂させるかが最も重要なので，プロジェクト組織が適すると言えます．
一方で，宇宙ステーション開発は，宇宙ステーションを構築して終わりではなく，その後の宇宙ステーションを活用した宇宙開発が安全に安定して行われることが重要なので，宇宙ステーションを作り切ることだけに特化した組織にならないことを注意しなければいけません．
プロダクトに基づく組織
ここで，プロダクト とは，事業を行う上で顧客に届ける価値と定義します．事業が存続する限り，プロダクトは存続します．
プロダクトに基づいた組織は，もちろんプロダクトが存続する限り存続するでしょう．基本的に，プロジェクトに基づいた組織よりも長く存続する傾向があるということができます．長く存続する可能性がある組織であるということは，プロダクトの長期的な価値や組織の生産性などにフォーカスがあたり，技術的負債の管理にも責任を持つ動機づけが働きやすい傾向があるのではないでしょうか．
ここまで，プロジェクト組織とプロダクト組織を対比的に書きましたが，プロダクトとプロジェクトは，対立関係ではありません．プロダクトに基づいた組織は，その時々のプロジェクトに取り組むことができます．
プロダクトに基づいた組織を構築する際に難しいのは，プロダクトの範囲や組織の裁量の範囲を定義することでしょう．プロジェクトに基づく組織は，プロジェクトの定めるスコープが明確に決まっているはずなのでこの部分にはあまり苦心しません．一方で，プロダクトに基づく組織は，定義を一言で表すことは簡単でも，色んな事情があって境界付けが難しいこともあります．求められるミッションと組織の持つスキルセットに差があって苦心することなどもあるでしょう．
プロダクトの境界とコミュニケーション
境界の話
プロダクト組織のところでも出ましたが，職能横断チームやプロダクトの定義は，広く取れば取るほど最終的に提供される価値にフォーカスしやすい組織となるが，その反面コミュニケーションのオーバーヘッドがかかったり，価値判断の難易度が上がったりするなど，高度なマネジメントが求められる傾向があります．
以前に私が書いた 組織境界の話 や プロダクト定義の話 でも取り上げましたが，現実的には以下の3つが重要になるのかなと思っています．
- 境界を広げ続ける努力
- 適切に境界を設定して「望ましい部分最適」が働くようにすること
- 必要に応じて境界を見直すこと (一度設定して満足してはいけないし，フェーズが変われば最適化するべき KPI も変わる)
「コンウェイの法則」と「逆コンウェイ戦略」
コンウェイの法則とは，「組織の設計するシステムには，その組織のコミュニケーション構造をそのまま反映した設計になるという制約がある」という有名な法則です．
コンウェイの法則はもともと，組織の成果物を分析した結果であり，組織の構造を所与として成果物のアーキテクチャの傾向を説明するものでした．これを逆手に取り，プロダクトの構造を変えたり，新しくプロダクトを作る際に，どのような設計を実現するかから逆算して組織のコミュニケーションフローをデザインすることを「逆コンウェイ戦略」といいます．
SoE と SoR によるバイモーダル戦略
「逆コンウェイ戦略」では，どのような設計の青写真を描くが重要になります．ではどのような設計を目指せばよいのか？その答えはもちろん事業や組織の特色に依存しますが，一つのヒントになるのが SoE と SoR によるバイモーダル戦略です．
System of Engagement (SoE)
System of Engagement とは，プロダクトと顧客のつながりを確立し，強化することを主眼としたシステムです．
一般的な toC のサービスで言えば，インターネット上に展開されるサービスサイトや，モバイルアプリ，メールや郵送物などによる CRM チャネルなどが SoE に当たります．
特に toC 向けプロダクトの場合，どのような改善施策が効果があるかや，潜在市場がどこに潜むかは経験主義をもとに探し当てる必要があります．「リーンスタートアップ」や「アジャイルなプロダクト開発」が特に効果を発揮する分野と言えるかもしれません．小さく高速に実験して学習することが求められます．
System of Record (SoR)
System of Record (SoR) とは，出来事が正しく起きることを保証し，起きた出来事を正確に記録し管理するためのシステムを言います．
金銭管理や，法令や規制に基づいた報告義務のあるようなドメインなどがこれに当たります． SoE と比べれば，情報の取りこぼしやシステムダウンはより致命的であり，リスクを抑えて安定稼働することが求められます． 事前に要件を明確化してコーナーケースなどを慎重に考慮することが求められるので，いくら「アジャイルなソフトウェア開発」を標榜しても，大きな設計を洗い出し*5，正しくシステムが稼働するかの検証にも力を入れる必要があるでしょう．
バイモーダル戦略
SoE / SoR の特性を理解し，開発するプロダクトや，システムを構成する全体の中でも特定のエリアの性格に対応したチーム構成やプロセス設計などのアプローチを取る戦略を「バイモーダル戦略」といいます．比較的大規模なシステムを開発するとき，そのシステムの中にも SoE の特性を持つ部分と SoR の特性を持つ部分があるので，そのことを自覚しましょう，という話です．
これらを実際の組織運営・組織構築に応用すると？
ここまでが，今の自分が意識している組織構築・運営を行う上でのセオリーやパターンでした．エンジニアリングマネージャーそれぞれの取るアプローチは，当然所属する組織の文脈によって変わってくると思います．皆さんは普段どのようなことを考えていらっしゃいますか？
FOLIO Advent Calendar 2018 にて明日公開する記事 では，FOLIO のこの1年半くらいの開発組織の変遷や，今抱えている課題についてご紹介する予定です！ (このブログで紹介します)
*1:世の中には エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング という，より網羅的に，さらに発展的な内容まで網羅した書物があります
*2:『エンジニアリング組織論への招待』では機能別組織と機能横断型組織と記載されていますが，本稿では LeSS における Feature Team を一つの道標にしているため，このような用語を使っています
*3:呼び方はいろいろありますが，FOLIO ではこう呼んでいます．
*4:プロジェクトの後期に人員を追加投入することは，開発速度を向上させず，むしろプロジェクトの遅延を引き起こす
*5:Big Design Upfront と呼ぶことがあります
