テクノロジーマネジメントとビジネス成長と自己組織化の罠
この記事は Engineering Manager Advent Calendar 2023 19日目の記事です。
以前書いた記事が思いの外伸びてしまいびっくりしたのですが、以前の話題にも続く話を書こうと思います。
ビジネスの成長に組織が追いつかない！を回避したい
私が初めてマネジメントにチャレンジした時感じた学びとして最も大きかったのがこの観点でした。
読んでくださっている方の中にも会社として成長を作り出したいのに舵を切ろうとしても組織がなかなかついてこないという悩みをもったマネージャーもいるかと思います。
いくつか要因がありますが、最も難しいのが「信頼されていない」という課題です。
（魅力的に伝える発信力などはスコープアウトします）
ブレークダウンすると、「リーダーの言葉が形骸化している」や「リーダーの方針のもと頑張っても報われない」といった感情が組織に広がっている場合組織を動かして成果を出すことは難しい状況と言えます。
私自身過去メンバーから「何を話しているのか自分でもよくわからなくなっているのでは？」「頑張りは認めてもらえるけど報われている感はない」という声をリアルでもらったことがあり、力不足を痛感したことがありました。
こうした問題は個々人のマネージャーの力量によっても解決しうるものですが、点の解決策になるので再現性は生まれません。根本解決の観点では、組織全体の問題と考える必要があります。
しかしながら、ある時からいきなりそういう状態になるものではなく、何年もかけてじわじわ醸成されるものだと感じています。
組織内に発生する負の引力というのは人が集まって仕事をしていれば自然に発生するものだと思いますが、状態のいい組織ではそれが自浄作用によって自然治癒していきます。
しかし、組織の状態が悪くなったり、特に組織に対して責任を持つポジションの人がその対処をやり切れないとその問題は負債となってどんどん大きくなっていきます。
それに対処するための基盤としてのマネジメント組織については以下の登壇でお話ししているので関心があればみてください。
ビジネスの成長にテクノロジーが追いつかない！を回避したい
さて、ビジネス成長に耐えられる組織があればその会社は安泰と言えるでしょうか？
いくらいいマネージャーがいても、いくら組織エンゲージメントが高くても、組織全体として技術的課題*1の増大に対抗する力を持っていない場合は厳しい、という話を次にします。
ビジネス成長に対して組織が安定的に追従したとしても、技術的課題が大きくなるスピードがビジネスの成長速度を上回ることはあり、この状態になるとその時点からビジネスを継続するための技術的課題への対処が発生し続けるためビジネスの成長角度に対して大きく影響を与えてしまいます。
技術的課題の内訳はいろいろありますが、最も事業に影響のある課題を一言で言うと「開発生産性が落ち、機能リリースが思うようにいかなくなる」が最悪の状態として言えるのではないでしょうか。
- コードの保守性・可読性・変更容易性
- パフォーマンス
- セキュリティ
などが具体例として挙げられるかと思います。
私のマネジメントの考え方
少し横道に逸れます。
私は現在はマネジメントを主な責務として担っていますが、バックグラウンドとしてはスクラムで改善をゴリゴリ回すのが好きなエンジニアです。
2018年頃にCope先生のCSM研修を受けたときの言葉が今でも記憶に残っており、（文脈は割愛しますが）「マネージャー？チームにマネージャーは要らない！」と力強く言っていた（笑）のが今でも私のマネジメントの考え方に大きな影響を与えています。
つまり、チームが自己組織化し、必要な知識や情報が揃っていれば究極的にはマネジメントは必要なくなるという考え方です。
現実的には会社という箱の中で活動するので評価などピープルマネジメント要素は残るのですが、それでもプロダクトマネジメント、プロジェクトマネジメント、テクノロジーマネジメントはチームで完結できるはずです。
自己組織化を推進した結果としての機能不全アンチパターン
話を戻しますが、自己組織化を推進してマネージャーがチームから離れていき、さらにそうしたチームをスケールさせていくとします。
その時にチームがテクノロジーマネジメントの観点をしっかり強化できていればいいのですが、上の図で書いたように技術的課題が急激に増大するとチームの内部では対処が難しい状況が生まれてしまいます。
結果的にマネジメントとチームの間に大きな問題が残り、組織全体の機能不全に陥っていきます。
この問題に対処するためには、戦略的にテクノロジーマネジメントに投資し続けることが必要です。
結局プロダクト戦略・技術戦略・組織戦略を紐付けて回していきましょうという当たり前の話になってしまうのですが、具体的な問題構造の整理が進んだので記事として言語化してみました。
いろんな会社のやり方・考え方も聞いてみたいのでX的なところで感想いただけたらうれしいです。
*1:この文脈で出てくるワードとして技術負債というものもありますが、意識的・意図的なネガティブ影響というよりかはビジネス成長によって順当に発生する課題も含めて純粋に技術的課題と表現します。
