Future Tech Blog
フューチャー技術ブログ
Managementカテゴリ

サステナブルなエンジニア組織デザイン（後編） ～デザインパターンと10のリファクタリング～

サステナブルなエンジニア組織デザイン 後編

前編ではエンジニア組織のよくある設計とジレンマについて紹介しました。

後編ではサステナブルなエンジニア組織に向けたデザインパターンとリファクタリングのプラクティスについて紹介します。

対象者

エンジニアに敬意を払える正しい認識を持ってることを前提として以下のような方々を対象としています。

  • スタートアップなどでエンジニア組織をこれから作っていこうとされている方
  • エンジニア組織駆動でビジネスをスケールさせていこうと思っている方
  • 他、エンジニア組織に対して様々な課題認識を持っていられる方
    • エンジニアの獲得がうまくいかずに組織が大きくならない
    • エンジニアがどんどん離れていってしまっている
    • エンジニアのモチベーションがアップするような仕事環境を与えられていない
    • エンジニアが好き勝手やるので収益に結びつかない
    • エンジニアのキャリア形成がうまくいっていない
    • エンジニアのレジェンド達が新しいチャレンジを許さない
    • エンジニアとは名ばかりでベンダーコントロールするだけの組織になっている

エンジニア組織のデザインパターン

今まで試行したことのある主だったエンジニア組織のデザインパターンを整理してみました。

組織全体への適用だったり、部分適用だったりと多少の違いはありますが、いずれかのパターンの組み合わせでリファクタリングしています。それぞれのパターンに特徴があり、万能な組織デザインは存在しません。組織デザイン検討にあたってはリファレンスになるデザインパターンとして適宜組み合わせてみたりしてもらえるとよいかと思います。前編で少し触れたティールは遠目で見ればホラクラシーに分類できるので以降はそう読み替えてもらっても大きくミスリードはしないかと思います。

アーキテクチャ型組織デザインパターン（A型）

技術領域カットで組織を構成し技術専門性の強化を重視します。技術領域を細分化すると専門性を強化できるメリットがあります。また組織機能重複もなく合理的な組織デザインです。ただし、特定の技術領域だけでは成り立たないようなプロジェクトでは分業制が進みやすくなり、プロジェクトのオーナーシップやカルチャー形成が分断されていく課題が頻発します。またフルスタック志向のエンジニアのキャリア形成にはこの分業制が足枷になりやすい構造です。

プロジェクト型組織デザインパターン（P型）

事業領域のテーマやプロジェクトカットで組織を構成し機動性を重視します。一気通貫でプロジェクトに携わることによって個人の裁量も増え、個人のオーナーシップが醸成しやすいです。一方で各プロジェクトに組織機能が重複するためノウハウ蓄積が課題になりやすい構造です。目に見える形での成果は出しやすい一方で技術領域の専門性などが犠牲になりやすい構造とも言えます。

マトリックス型組織デザインパターン（M型）

技術領域とプロジェクト領域のマトリックスで組織を構成し、A型とP型のいいとこどりを狙った組織デザインパターンです。それぞれの弱点を補完する組織として個々のエンジニアの思考やスキルセットに応じてバランスがとりやすい構造です。プロジェクト型よりも組織機能の重複が減り合理的な組織デザインでもあります。一見すると万能な組織デザインに見えますが、エンジニア個人からみると技術領域とプロジェクト領域の2つのレポートラインが存在するため負担増になり、優先順位が明確でなければ組織のガバナンスに歪みが出やすい構造です。また技術領域を細目に分けてしまうことは余計に負担増が発生してしまうためアンチパターンになります。

ホラクラシー型組織デザインパターン（H型）

ヒエラルキーを排除し、エンジニアや小チームが有機的につながりプロジェクトを遂行する組織デザインパターンです。ミッションや価値観が共有されていてゴールイメージが明確であれば、チームワークは活性化され成果を最大化しやすい構造です。エンジニア個人のキャリアにも効果的であり、組織的なノウハウ蓄積に加えノウフー（Know Who）による集合知形成がしやすくなります。ただし、個人に多くの判断を委ねられることが多くなるため属人化が進み、結果的に組織機能の重複が多くなる傾向があります。組織全体にボトルネックやグレーゾーンが生まれやすくなり、関係者が増えれば増えるほど共有すべき価値観は希薄化し、大きなプロジェクトを遂行するには無理が生じやすい構造でもあります。

まとめると、こんな感じでしょうか。いずれも相対的な評価です。

観点 内容 A型 P型 M型 H型
オーナーシップ 仕事に対してオーナーシップが育まれやすいか？ △ ◯ △ △
オペレーション 組織のオペレーションに重複がないか？ ◯ × △ ×
モビリティ 個人やチームの機動性はあるか？ × ◯ △ ◯
カルチャー 生まれたカルチャーが維持されやすいか？ △ ◯ ◯ ◯
ノウハウ ノウハウが蓄積されやすいか？ ◯ △ ◯ ？
プレッシャー 個人やチームの負担はあるか？ ◯ △ △ ×
パフォーマンス 個人やチームの成果がでやすいか？ △ ◯ △ ？
モチベーション 個人のモチベーションが維持されやすいか？ △ ◯ △ ◯
キャリア キャリア形成がしやすいか？ △ △ ◯ ◯

ホラクラシー型に「？」があるのはうまく機能させるには前提条件があるからです。ホラクラシー型には行動指針といった価値観の共有が不可欠です。それらが価値基準として各個人まで血の巡りのように隅々までいきわたっていることが前提条件です。

参考までに2010年頃に当時30名ぐらいだったメンバーに対して共有した一枚を紹介します。

当時は20代の頃でプロジェクトが佳境の中、勢いで書いたペーパーなので今みるとちょっと恥ずかしいですが、、、当時のメンバー各人が強烈な「課題認識」をもち、課題に対して「自発的行動」を促し、エンジニア同士が「有機的協調」して、課題の根本解決に向けた「技術（自己）投資」を継続しながら成果に「コミットメント」する。そのサイクルが更に新たな成果を生んでいく、といったことができていた組織でした。過去を美化している感はありますが、当時は言葉の定義もなかったホラクラシー型組織のいくつかの要素を満たしていたのではないかと思っています。

ホラクラシーとマズロー

非常に有名な「マズローの5段階欲求」の最上位欲求「自己実現欲求」は知的好奇心が旺盛なエンジニアには特に強い傾向があると思います。この欲求を刺激することはエンジニアのキャリア形成にとっても非常に大事です。ただし、それだけではエンジニアのサステナブルな組織化は難しいというモヤモヤがずっとありました。それに対してマズロー自身が晩年になって更に上位に6段階目の欲求「自己超越欲求」について言及していたことを恥ずかしながらつい最近知りました。

ホラクラシー型を目指すことは「自己超越欲求」に応えることだと勝手解釈して個人的に納得してます。エンジニア個人の自己実現という狭い視野からチーム成長を通して自己超越したいという欲求を満たすこと、つまりはチーム＝自分自身という感覚を養っていくということではないかと整理してます。

10の症状とリファクタリング

エンジニア組織の様々なジレンマを解消できるような西洋医学的な特効薬は存在しません。組織としての成熟度や課題認識に応じて適切なタイミングで東洋医学的に組織デザインをリファクタリングし続ける継続力が重要です。

リファクタリングのタイミングを見計らうのに利用したのがチームビルディング理論として有名な「タックマンモデル」です。

タックマンが提唱したこの理論はチームが機能的に進化する過程を表しているもので、あまりに普遍的なモデルなのでチームビルディングを志す人なら目にされた方も多いかと思います。

タックマンモデルの説明は他に任せるとして割愛しますが、ここでお伝えしたいことはエンジニアに異変を感じた時に即リアクションして必要に応じてリファクタリングすることの重要性です。組織が成長するタイミングで起きる歪みはエンジニアの行動変化から始まります。変化に敏感に気がついて早期にリアクションして適切な処方をしないと機能的な組織デザインには進化しません。

以下、組織のリファクタリングのきっかけとなる10の症状と処方箋を紹介します。

一、老害シンドローム

エンジニアから「俺らの頃は～」という表現がよく聞こえてくるようになったのなら絶好のリファクタリングのタイミングです。特にレジェンド達が過去の成功体験を語り続けているなら気を付けた方がよいでしょう。過去の経験は尊いものですが、成功体験による自信は行き過ぎると過信へと変わります。過信は停滞を生む大きな原因の1つです。成功体験しか言わないレジェンドには別の役割を与えた方がいいでしょう。書籍『チーズはどこに消えた？』でも渡しておくといいかもしれません。また、この症状の場合はヒエラルキーが深くなっていることが可能性が高いため、組織デザインをよりフラットにするような処方が効果的です。

　　→　処方箋：組織デザイン変更（P型、H型など）

二、安定シンドローム

エンジニアの「実績を重視して～」という表現がよく聞こえてくるようになったのなら絶好のリファクタリングのタイミングです。実績は非常に大事ではありますが、意思決定に実績しか選択理由がない場合は安定という名の思考停止をしている可能性がありますので気を付けた方がよいでしょう。現状維持の安易な選択は変化を拒んでいる証拠です。技術的負債の正体は現状維持バイアスです。これが続くとエンジニア組織の癌細胞になる可能性があります。まだ小さいうちに対処して取り除いておくことが大事です。

　　→　処方箋：組織デザイン変更（A型、M型など）

三、テクハラシンドローム

技術的な専門性で尖ったエンジニアが専門外の人に対してテクハラ（テクノロジー・ハラスメント）を見かけるようになったら注意喚起が必要です。チーム間に壁が生まれている可能性があります。一度築かれてしまった壁はなかなか崩れないので協調型に変えるなどといった大きなリファクタリングも必要になると覚悟した方がいいでしょう。

　　→　処方箋：組織デザイン変更（P型、M型など）

四、燃え尽きシンドローム

大きなプロジェクトが終わりそうなタイミングはリファクタリングを検討するタイミングにもなります。大きなプロジェクトが終わると達成感を超えて燃え尽きてしまうことがあります。一度燃え尽きてしまうとなかなか回復するのに時間がかかるので早い段階での検知が不可欠です。燃え尽き状態になるネガティブな要因の1つは、偏ったプレッシャーを長い期間与え続け、エンジニアを低温火傷のように思考停止状態にさせてしまった点が挙げられます。回避させるためには日頃から定期的なメンタリングやキャリア相談がしやすい組織デザインへとリファクタリングしましょう。

　　→　処方箋：組織デザイン変更（M型など）

五、内向性愚痴シンドローム

エンジニアから所属チームに対する不平・不満が増えてきたタイミングでは対症療法的に1つ1つ改善させていくことが先決です。大きなリファクタリング（異動・交代、方針転換など）はかえって傷を大きくしやすいため、目の前の不平・不満がコツコツと改善する様子をエンジニア自身に感じてもらうことが重要です。大きなリファクタリングによる荒治療は最終手段に取っておきましょう。

　　→　処方箋：チーム内改善

六、外向性愚痴シンドローム

エンジニアから所属チーム外に対する不平・不満が増えてきたタイミングでは、言う側と言われる側のどちらの問題なのかをきっちり見極めて大きなリファクタリング（異動・交代）を考えましょう。チーム外に対する不平・不満は多くの場合で周囲に一気に広がる進行性の癌になりえます。組織が若いうちは特に進行が早いため配置転換も早ければ早いほどよいでしょう。

　　→　処方箋：異動・交代

七、成長痛シンドローム

組織内の1つのチームに所属するエンジニア数が一定のラインを超えてくると、それまではうまくいっていたことがうまくいかない事態が起きてきます。ほとんどの場合は成長痛なので一度超えてしまえばチームの成長に繋がりますが、私自身の経験上ではチームあたり8名程度までが最適なメンバー数で30名程度になると直接的な指揮系統の限界を迎えます。限界を超えると必然的にヒエラルキーが深くなりやすく、それによるエンジニアに対する弊害が多くなるため、メンバー数が一定ラインを超えたチームはチーム分解を検討するのがよいでしょう。

　　→　処方箋：チームの分解

八、血行不良シンドローム

エンジニアが同じチームに仲間が変わらない状況下で長期間所属している状況は、多くの場合チャレンジが減り現状維持バイアスという名の血行障害になるリスクがあります。この症状になると組織全体にいい影響を与えないことが多いため、日ごろからの心がけて血行を促進する必要があります。チームの所属期間をモニタリングするなどして、チームメンバーの流動性を維持管理していることが重要です。定期的な人材シャッフルなども有効でしょう。

　　→　処方箋：異動・交代

九、マンネリシンドローム

エンジニアに対して「何かやりたいことがないのか？！」「あなたの分身を育てようよ？！」という投げかけを頻繁に聞くようになったらチームが停滞しはじめている黄色信号です。ミッションや後継育成はリーダーが組織的にやることであって、エンジニアにそれを求めるようになってることはチームに成長の伸びしろがない証拠です。チームの可能性の幅を模索できないようならチーム解散も含む大きなリファクタリングを計画していく好機です。

　　→　処方箋：チーム解散

十、うわべだけシンドローム

エンジニアの真の声が聞こえなくなった、エンジニアからキャリア相談される機会が減った、ソースコードを書く/見る機会が減った、エンジニアの活動の評価を数字貢献だけでみるようになった、・・・などエンジニアとの距離感が遠くなったことに焦りを感じずにうわべだけのマネジメントになっている場合はもはや組織のリーダーシップとしては末期状態に近づきつつあります。リファクタリングの時期を逸している可能性が高いため、その時に考えるべきことは1つしかありません。

　　→　処方箋：あなた自身が退く

後編まとめ

サステナブルなエンジニア組織に向けたデザインパターンとリファクタリングのプラクティスについて紹介しました。

エンジニア組織デザインのヒント

  • 組織デザインパターンは万能ではなく各々にメリットとデメリットがある
  • 組織デザインパターンは適宜組み合わせることで組織のデメリットを補強できる
  • エンジニアの行動指針や価値観の共有は組織を強くする
  • エンジニア組織が成熟していく時間軸をコントロールしてレベルアップさせる
  • エンジニアに対して紳士に向き合った対話を心掛ける
  • エンジニアの行動変化や異変を素早く検知・予想する
  • 検知された異変に対して適切なタイミングで適切な処方をする
  • 組織デザインのリファクタリングを継続することがサステナブルな組織へと進化させる

リーダーがやってはいけないことリスト

  • 実態の伴わない組織デザイン
  • エンジニアとの心理的な距離感
  • チーム間の壁の許容
  • 深いヒエラルキーの許容
  • 変化に対する意思決定の遅延
  • 問題は時間が解決するという楽観主義
  • エンジニアの力を信じない悲観主義
  • 現状に甘んじて自身を律することをしない甘え

目次

おまけ

本稿のテーマに直接的に関連はしませんが個人的に組織デザインに影響を受けた書籍を紹介します。

2002年にダニエル・カーネマンがノーベル経済学賞を受賞して以来、脚光を浴びるようになった学問が行動経済学です。人間がかならずしも合理的には行動しないことに着目し、経済モデルに人間の心理を取り入れることで、トラディショナルな経済学ではうまく説明不能だった経済行動を実証的に捉えようとしたものです。

経済学の専門家でもないのでさらっと読める書籍の紹介になりますが、エンジニア組織デザインが経営学でいう組織論などとは合致しない点が多くてもやもやしていたのですが、行動経済の別視点で組織を眺めると多少なりとも参考になる点が多く応用できました。エンジニア組織に起きていた行動のいくつかが説明つくこともあるので予測可能な行動は先手を打つべく個人的に重宝しています。

何かの参考になれば。

『予想どおりに不合理』　ダン・アリエリード(著)

Yosuke Miyahara
Vice President/Technology Innovation Group/Future Corporation.
https://newspicks.com/user/147180