Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。

フォースを感じる

自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。

ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ込んできます。このフォースがどのように伝搬してくるかを見る能力がとても大事であり、これが無いと、本来、事業を加速させようとした意思決定も現場に伝わるころには、まったく逆のフォースを発生させてしまい、スピード感を失ったディフェンシブなものにすり替わってしまったりします。

具体的な例で話したほうがイメージ付きやすいと思うので以下に想像ベースで書いてみます。

スタートアップや社内新規事業のアーリーステージにおいて過度な売上目標をチームに持たせようとした場合

例えば、スタートアップや社内新規事業のアーリーステージにおいて、さらなる成長の加速を願い、過度な売上目標をチームに持たせようとした場合なにが起こるのか。

サービス初期のプロダクトの価値が実証されていない状態（バケツに穴が空いた状態）においては、例えば売り方（売上）ではなく売り物（プロダクト）の力のみで結果をコントロールできる数値（継続率や成長率)を目標にすべきなのですが、ここで強い売上目標を組織に持たせると、チームは売上の単価やグロスをあげるために、売り物(プロダクト)ではなく売り方側をチューニングしアップセルやクロスセルをどうしてもしたくなります。そのほうが短期的に数字を作りやすいから。くどいですが、本来であればこのフェーズは売り方ではなく売り物をチューニングし、顧客の課題を確実に解決できるプロダクト(バケツの穴を塞いだ状態)に仕上げたほうが全体的には手戻りが減り事業成長の点で効率が良いです。売り方(水の流し方)のチューニングはそのあとの話。

しかしながら、売上を目標に持ってしまっているので、そうもいかず。仮にtoC向けサービス(薄利多売)であった場合は、急速にtoB(顧客単価高)へと販売戦略を変えたりすることもあります。ここで現場で発生することは、プロダクトのフェーズ（バケツに穴あいているtoC向けサービス）と、ビジネスの強いられているフェーズ（アップセルクロスセルによる売上最大化）にミスマッチを起こします。どんなに送客しても、toCプロダクトをtoBに売ったところでチャーンレートが高い状態(バケツに穴あいたまま)なので顧客は継続せず漏れていきます。また、それを防ぐために焦って、toBむけエンタープライズな仕様や機能がどんどん追加されていきます。ベースがtoCであったシンプルなサービスはあとから十徳ナイフのように機能がもりもりにされていき、コードベースは肥大化していき、開発のフットワークはどんどん悪くなっていきます。そして悲しいことにこの肥大化したコードベースの6割は使われない機能だったりします。P/L上もシステム投資における資産が積み上がり残存簿価まみれになり、減価償却費が根雪構造的に積み上がり自分たちのできることが徐々に制限されていきます。この最初の力学を発生させたポイントは、「アーリーステージの組織にフェーズに見合わない売上目標を課したこと」になります。

そのため、最初の組織の目標設定のタイミングで、どのような力学が発生するかを解像度高く想像を巡らせる必要がありますし、わかる限りその段階で正すことが求められます。まさにエンジニアリングマネージャーの嗅覚が必要とされる部分だと思います。

サービスの能力以上の資金調達する場合

同様なものに、例えば次の例もあります。サービスの能力以上の資金調達(社内|社外)するというケースです。基本的には前述と同じ構造ではありますが、調達額（投資家からしたら投資額）に対して、どうしても期待が高くなります。すると、期待値に見合うように目標を高く設定するバイアスが発生します。「こんなに投資してそのリターン？」となってしまうので。そして、チームはそのゴールに向けた数値の積み上げが始まります。そこから逆算した無理なエクセル上の計画が立てられ、プロダクトはそれにそった計画駆動型の開発モデルになっていきます。

開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。プランニング「側」と開発「側」の壁が強くなっていきます。どうしても、プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディフェンスしたくなる。ギスギスしだす。開発「側」は「仕様が決まってないので作れません」となる。更に開発「側」は計画を守るために、バッファを計画上にたくさん盛り込みだす。つまりは、やれることをバッファ分だけ自ら減らしていく構造を作り上げる。そして、基本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長をスローダウンさせていくことになる。仮にスタートアップだったら、最終的にダウンラウンドを招くことにもなります。これも、最初の力学を発生させたポイントは「サービスの能力以上の資金調達」するという決定によって発生する組織力学です。起点は、ちょっと背伸びしたかっただけなのかもしれないのですが、巡り巡ってこんなはずじゃなかったという結果につながるかもしれません。

スクラム開発において個人のベロシティをモニタリングする場合

若干上記の例が、ビジネスビジネスしてたので、もう少し開発現場よりの例も上げてみます。より開発現場の生産性をあげるために、チームのベロシティだけでなく個人のベロシティも日々モニタリングするようにしようという提案があった場合。例えば、エンジニアは自身のベロシティが自身の業績評価につながると思ってしまうかもしれない。そうなると、多めに見積もったほうが生産性は高く見えるようになる。もしくは、見積もりよりも時間が掛かりそうな場合に、低品質でもおわりにしてしまえという考えが出てくることもある。さらに、相互のメンバ間の助け合いもおきなくなっていく。人のこと助けても自分のベロシティあがりませんし。と。流石にこれらは極端な例だとは思いますが、正しく合意形成や目的の共有がなされていない状態でこの決定を下すと、現場には少なからず間違った力学が発生してしまうことがあります。

エンジニアリングマネージャーとしてフォースを間接的にコントロールする

最初から上記にあげているような構造のパターンを知っていたわけではないので、実際にはシステム思考をベースに複数の類似した経験から因果のパターンを抽出して自分の引き出しとしています。（無意識的にやっていて、同じような事象に遭遇したときにひらめく感じ。）なんでも構造として捉えるのがもともと好きなので、その思考方法が癖になっていて、iPadで日々お絵かきをしています。ただ、自分は別にパターン・ランゲージの熟練者でもなんでもないので、なんとなくやってます。

エンジニアリングマネージャーとしては、ビジネス上の判断が力学としてエンジニアリングの現場にどのような形で伝搬するのか、逆に伝搬させないようにするのかを見極め、ビジネス上もっともアウトカムへのスループットを最大化させるように対策を講じる必要があると思います。基本的に構造によって発生する力学なので、その流れるフォース自体はコントロールしにくいですが、力学を発生・加速・減衰させる構造側はコントロール可能なので、構造をコントロールしてマネジメントしていくことになると思います。例えば、ビジネスモデル、目標の構造（KGI-KPIs）、予算の構造（ポートフォリオ）、それに紐付いて作られる組織構造、それに紐づくシステムアーキテクチャ、開発プロセスなどです。例えば、経営層が経営指標をEBITDAにするとメッセージングしたときに、開発の現場では何がおこるかとか考えてみると面白いかもしれません。

また、自分が大切にしているのがこの力学を逆手にハックして利用していくことです。その力学を逆にうまく使って自分のやりたいこと、都合のよいことをフォースの流れに混ぜ込んでのせてしまう。そうすると施策が一気に進んだりします。デメリットがない場合、コトを前進させるのにはフォースの流れを利用してしまえと思っています。

こんなことを考えながら日々、エンジニア組織をマネージメントしています。