私たちエンジニアは、コードやプロダクトに集中しているとき一番力を発揮できます。それ自体はまったく悪くありません。しかし、その視野のままだと見えにくいものがあります。たとえば「なぜ自分で目標を立てることが大事なのか」「言われたことをきちんとこなしているのに、なぜそれだけでは評価されにくいのか」。あるいは「なぜチームの体制は、ときに急に組み替えられるのか」。私はマネージャーを経てプレイヤーに戻った今、これらが別世界の話ではないと感じています。今回伝えたいのはシンプルで、組織とマネジメントは、どちらもソフトウェアアーキテクチャと同じ概念で考えることができる、ということです。その概念を持つと、自分の評価や目標が組織の設計と地続きに見えてきます。

開発の外側を見るとき、エンジニアは何に困るか

エンジニアとしてのキャリアの最初は、ほとんどの時間をコードに向けて過ごします。良い設計を考え、バグを潰し、レビューで指摘し合う。この世界には手応えがあります。インプットとアウトプットの距離が近く、自分が何をすれば何が良くなるかがはっきりしている。

一方で、その外側にある「組織」や「マネジメント」は、しばらくのあいだ別世界の話に見えていました。私自身、以前は自分がマネージャーに向いていないと思っていましたし、組織の話は自分の仕事から遠いところで決まるものだと感じていました。

しかし、会社という組織には明確なアーキテクチャが存在しています。部長と部下の関係、マネージャーという枠組み、プレイヤーとの違い、その上にある役員や株主との関係。役職や階層や役割ははっきり設計されて存在しているのに、なぜその形なのかを私はよく分かっていませんでした。コードの設計なら「なぜこの構造か」を当然のように問うのに、組織の設計については問うことすらしていなかったのです。

そして、マネージャーとして働きながらマネジメントの本を読むうちに、少しずつ腑に落ちてきました。会社という仕組みは、コンピューターが生まれるよりずっと前から存在しています。つまり、ソフトウェアがコンピューター駆動で動く設計物だとすれば、会社は人間駆動で動く設計物だということです。動かしているものが違うだけで、どちらにもアーキテクチャがある。そう捉え直した瞬間に、組織が急に「読めるもの」に見えてきました。

組織はソフトウェアアーキテクチャと同じ概念で考えることができる

組織を「人間駆動で動く設計物」と捉えると、ふだんコードで使っている語彙がそのまま組織にも当てはまることに気づきます。

モジュール分割 ↔ チーム分割

関心ごとに責務を分けて、内側を凝集させ、外との接点を絞る。チームを分けるときに考えていることは、モジュールを切り出すときの判断とよく似ています。同じ組織でも、チームを 1 つの関心ごとに集中させたいのか、複数の視点を横断して持ってほしいのかで、どこに線を引くかは変わってきます。

インターフェース ↔ 役割と責務

「このチーム（人）に何を渡せば、何が返ってくるのか」。役割定義とは、人と人との間のインターフェース契約です。たとえば開発と運用を工程ごとに別々の人へ分け、その間で契約を結ぶのか、それとも DevOps のように機能単位で責務を分割し、その機能については開発から運用まで同じ役割が引き受けるのか。同じ仕事でも、どこに契約の境界を置くかで役割の形は変わります。

責任の委譲 ↔ 抽象化・カプセル化

呼び出す側は「何をしてほしいか」だけを渡し、「どうやるか」は相手に委ねる。上司が部下に仕事を任せるのは、内部実装を隠したモジュールに処理を委譲して、結果だけ受け取るのとよく似ています。委譲がうまくいくほど、上位は細部を気にせず全体へ集中できる。逆に、上司が部下の仕事をいつまでも肩代わりしている状態は、隠したはずの内部実装が外へ染み出す「抽象化の漏れ（leaky abstraction）」そのものです。抽象化ができていない、と言い換えてもいいでしょう。

結合度 ↔ 依存関係・連携コスト

あちこちのチームに確認を取らないと前に進めない状態は、密結合そのもの。連携コストの高さは、設計の結合度として読めます。この結合度を下げる手立てにも幅があります。たとえばチームの責任者が定例を設けてその場で擦り合わせる、という同期的なやり方があります。あるいは問い合わせ窓口の責任者を決めて依頼の入り口を一本化し、そこへの依頼が自動でアラート通知されるようにする、という非同期なやり方もあります。

リファクタリング ↔ 組織再編・仕組みの変更

外から見た振る舞いは保ったまま、内部構造を組み替えて最適化する。組織の再編も、本質的には「設計変更による最適化の検証」です。たとえば特定の部署や人にだけ仕事が集中して回らなくなり、隣の部署は手が空いている。こうした忙しさの偏りがボトルネックです。人数の配分や責務を組み替えて負荷を平らにするのは、処理が詰まる部分を切り出して負荷を分散させるリファクタリングと同じ発想です。

私がこの見方を強く意識したのも、まさにこの委譲の場面でした。部下が全員忙しくなってしまい、コアな変更を自分がプレイングマネージャーのように引き取ってしまったことがあります。当時は「手が足りないから仕方ない」と思っていましたが、いま振り返れば、あれは委譲関係のミスに直面していたのだと分かります。本来は、部下が抱えていた緊急性の低い仕事を削り、コアな変更を任せられる余白を作るべきでした。あるいは、自分だけに属人化していた作業を他のメンバーへレクチャーし、実際に手を動かして覚えてもらう。そうやって任せられる相手を増やしておくことも、委譲のための備えでした。

こうして並べてみると、組織の議論は決して感覚的なものでなく、私たちが日々やっている設計判断と地続きだと分かります。

マネジメントはプログラミングの観点で読める

組織が「構造」だとすれば、マネジメントは組織を動かす「振る舞い」です。こちらも、プログラミングの観点でかなり読み解けます。

KGI / KPI ↔ 目標とアサーション・テスト

何を満たせば成功と言えるのかを先に宣言し、それが満たされているかを継続的に検証する。テストの無いコードを信用しないのと同じで、検証できる目標の無い仕事は良し悪しすら判断できません。私自身、目標設定の相談を受けるたびに何よりも「どの指標を置くか」が一番のキーになると感じてきました。指標がずれていると、評価そのものが成り立たなくなる。これは、本当に重要な振る舞いこそユニットテストになっているべき、という構造とよく似ています。間違ったものをテストしていれば、どれだけ緑になっても意味がないのと同じです。「自分で目標を立てる」とは、自分の仕事に自分でアサーションを書くことなのです。

レバレッジ ↔ 再利用性・抽象化

同じ労力をかけても、一度きりで消える仕事と、仕組みになって何度も効く仕事があります。言われたことをこなすだけでは前者にとどまりやすい。評価されやすいのは、抽象化して再利用可能にする、レバレッジの高い仕事のほうです。そのレバレッジは、何人に効くかでも測れます。自分一人の作業が楽になるだけの仕事より、チームや他のメンバーにまで恩恵が広がる仕事のほうが、何度も再利用される分だけ評価につながりやすいのです。

スプリント・役割 ↔ 実行サイクルとインターフェース契約

一定の周期で「入力 → 処理 → 出力」を回し、各メンバーは役割という契約に沿って噛み合う。短い周期で回して改善する発想は、トヨタ生産方式を源流とするリーン開発に始まり、スクラムをはじめとするアジャイル開発全体へ広がっています。スプリントのような型は、組織の実行ループそのものです。日報や週報も同じで、決まった周期で進捗を出力し、次の動きの入力につなぐ実行ループの一部です。

マネージャーのアウトプット ↔ チームのアウトプット

この見方を教えてくれたのが『HIGH OUTPUT MANAGEMENT』です。Intelを率いたアンドリュー・グローブが、マネジメントを「生産（プロダクション）」の問題として捉え直した古典です。その中心にあるのが「マネージャーのアウトプットは、自分の手で出した成果ではなく、自分が率いるチームの出力の総和である」という考え方です。組織とは、いくつもの関数を合成した1つの大きな関数だと考えると腑に落ちます。

そして、この「出力は合成された総和」という見方は組織の最上位まで再帰的に続きます。役員もまた、株主という存在に対して業績という出力を返す責任を負っている。プレイヤーから見れば株主は一番遠い存在ですが、そこにあるのは私たちと同じ依存構造です。誰かが目標を委ね、誰かがそれに応える。その関係が層をなして積み重なっているだけなのです。最下層のプレイヤーから最上層の株主まで、同じパターンが繰り返されている。

自分で目標を立てることが大事なのは、それが自分の仕事の合否を決めるアサーションだから。言われたことをこなすだけだと評価されにくいのは、それがレバレッジの低い、再利用されない処理になりがちだからです。それに、あらかじめ決められた仕事はたいてい「最低限ここは満たしてほしい」という下限として設定されています。会社は株主に向けて業績予想を公表していて、そこから大きく下振れすると信頼を失うからです。決められたことをこなすのはその下限を守っているだけ。評価が伸びるのは下限を越えてレバレッジを効かせた部分なのです。

なぜ組織は変わり続けるのか

ここまで「組織は設計できる」という話をしてきましたが、そもそもなぜ組織は、こうも頻繁に作り替えられるのでしょうか。その根っこには、会社が成長を求められ続ける構造があります。

会社は社員を抱えています。そして社員は評価に応じて給与が上がっていく。もし会社の稼ぐ額がその給与の総額に追いつかなくなれば、社員へ還元できなくなります。つまり会社は、社員へ報いるために常に一定の成長責任を背負っているのです。

視野を市場に広げても同じです。たとえば日経平均のように、市場全体が平均して年に数%成長しているのに、自社がそこに届いていなければ、相対的に置いていかれていることになる。さらにインフレが進む状況では、売上が立ち止まっているだけで実質的には後退してしまいます。だから資本主義のもとでは、会社は成長を求められ続けます。

私はときどき、会社の組織は人間の細胞に似ているな、と思います。細胞は新陳代謝を繰り返すことで体の寿命を延ばし、変化に強くなっていく。組織もまた、再編や仕組みの変更という新陳代謝を通じて環境の変化に適応し続けます。そしてソフトウェアも、変化を求められ続けるからこそ、機能改善やリファクタリングを止められない。先に「組織再編は設計変更による最適化の検証」と書きましたが、その検証を止められないのは、新陳代謝をやめた組織が止まった瞬間から少しずつ老いていくからです。

対応表を実際の組織変更に当てはめてみる

ここまでの対応表は並べただけでは使えません。実際に私が経験した組織変更に当てはめてみます。

以前、複数のプロダクトを抱える開発組織が「ディスカバリー（何を作るかを探る）」と「デリバリー（実際に作る）」の2チームに分かれていた時期がありました。一見きれいな分割です。ここでの責務は、ディスカバリーチームが要件を整理してデリバリーチームへ渡す、というインターフェースのような関係でした。でも、どちらのチームも全プロダクトを横断して見ていたので、あるプロダクトの意思決定を進めようとすると、別のプロダクトの事情がいちいち絡んでくる。1つを変えようとすると、無関係なはずのところまで影響範囲が広がって、確認と調整が増えていく。言ってみれば、コードでいう密結合とまったく同じ状態です。マネジメント側から見ても扱う範囲が広すぎて、一人の頭に載せるには変数が多すぎる関数のように、認知負荷が高くなっていました。

しかも、チームとしては一緒でも、エンジニアは結局それぞれが担当プロダクトに集中していました。同じチームにいる恩恵といえば、ライブラリ更新や共通基盤の変更、設計方針のすり合わせといった技術的な共通認識を合わせるくらい。名目上はまとまっていても、実態はプロダクトごとにばらばらだったのです。

ここで下敷きにしたのが『チームトポロジー』です。マシュー・スケルトンらがチーム構造を「認知負荷（人やチームが一度に抱えられる情報量の限界）」を軸に設計し直すための型を示した本です。これを参考に、組織をプロダクトごとのストリームアラインドチーム（特定の価値の流れに、最初から最後まで責任を持つチーム）に切り分け、それらを下支えする横断的なプラットフォームチームを分離しました。やったことはまさにモジュールの再分割です。プロダクトという関心ごとで凝集させ、共通基盤を別のレイヤーに括り出す。

結果として、リリース速度が上がり、課題の分離ができ、マネジメント側の認知負荷も下がりました。対応表に照らせば、結合度を下げて凝集度を上げ、各チームのインターフェースを明確にしたことで、意思決定までの距離が縮んだということです。組織再編というと大げさですが、やっていることはコードのリファクタリングと同じ。外から見た価値の流れは保ったまま、内部構造を最適化しただけなのです。

もちろん、いいことばかりではありません。プロダクトごとに閉じた分、隣のプロダクトが今何をやっているのかはマネージャーレベルでないと見えにくくなりました。モジュールを分割してカプセル化すれば内部が外から見えなくなるのと同じで、これは構造を変えた代償です。私たちはこのリスクを意識的に受け入れています。エンジニアリングに銀の弾丸が無いのと同じで、組織構造にも銀の弾丸はない。どの設計を選んでも、何かを得れば何かを手放す。そのトレードオフを理解したうえで選ぶことが大事なのだと思います。

視差が広がると、自分のポジションが見える

こうした対応表が頭に入ると、視差が広がります。同じ職場を、プレイヤーの視点と、組織を設計として見る視点の両方から眺められるようになる。すると、マネージャーが求めてくる動きが、好みや精神論ではなく、設計上の必然として読めてきます。たとえば「チームの責務をはっきりさせてほしい」「他チームへの依存を減らしてほしい」「目標を自分の言葉で立ててほしい」といった要望です。結合を下げたい、インターフェースを明確にしたい、検証できるアサーションが欲しい。そう翻訳できれば、納得して動けるし、自分から提案もできます。

私はマネージャーを経て、今はテックリードとしてプレイヤーに戻っています。たぶん根っこはプレイヤー寄りの人間です。それでもこの視点を持っているおかげで、ただコードを書くだけでなく、マネージャーを助けるポジションを意識して動けるようになりました。大事なのは、マネージャーになる必要はない、ということです。プレイヤーのままでも、組織を設計として読めることは確実に効いてきます。自分の評価や目標が組織の設計と地続きに見えてくる。冒頭でお話ししたことは、こういう意味でした。

まとめ

組織も、マネジメントも、ソフトウェアアーキテクチャと同じ概念で考えることができる。モジュール分割、インターフェース、委譲、結合度、リファクタリング。私たちがコードに対して使ってきたこれらの語彙は、人間が動かす設計物に対してもそのまま効きます。逆に言えば、経営のフレームワークのように一見遠く感じるものも、エンジニアリングのアーキテクチャを当てはめてみるとぐっと理解が進みやすくなります。

そのうえで、一番持ち帰ってほしいことがあります。マネージャーを忙しくさせないプレイヤーこそ、委譲がうまくいっている証であり、価値を出せるエンジニアだ、ということです。課題を見つけて共有するだけでなく、その先の改善策まで自分で考える。エンジニアリングはつい「与えられた課題をどう解くか」に集中しがちですが、そもそもその課題は正しいのか、ほかにどんな打ち手があるのかを試行錯誤すること。さらに、あるべき姿を思い描き、そこへ近づくために自分から課題を見つけにいくこと。デザインが求められるのです。解くだけでなくデザインも一緒にできるエンジニアは、間違いなく評価が上がります。

もっと具体的に言えば、自分のKPIやKGI、個人の目標設定を「自分のため」だけでなく「マネージャーを成功へ導くため、自分はどこをどう手伝えるか」という観点でデザインしてみてほしいのです。組織が関数の合成だとすれば、自分の出力はそのまま上位の出力の一部になる。だからこそ、自分の目標を上位の成功と噛み合う形に設計できるプレイヤーは強く評価されやすくなります。

それに、組織構造を変えるというと大げさに聞こえますが、自分のすぐ近くの構造なら実は誰にでも変えられます。自分の役割の切り方、チーム内での連携の仕方、誰に何を委ねるか。こうした身近なところから始められます。テストの無いコードにユニットテストを一本足して足元を担保するのと同じで、手の届く範囲から小さく始めればいい。大切なのは、与えられた仕事だけでなく、自分の担当の外側へ少しだけ越境してみることです。一人でうまくデザインできないと感じたら、マネージャーや周りに相談する。言われたことの先へ一歩踏み出すことで、イノベーションは生まれます。越境してみること自体が、視差を広げる成長の始まりです。

コードを読むように、組織を読む。設計するように、自分の仕事を設計する。

最後に、次に書きたいことを少しだけ。AIエージェントは、いわば「探索の自動化」を実現しつつあります。会社が目標を掲げ、人がその実現方法を探り、人が機械に作業を委譲してきました。その「探索」の一部を、いま機械が引き受け始めています。そうなったとき、人はどこに集中すべきなのか。組織を設計として読む視点は、この問いを考える土台にもなります。その話は、また次の記事で。

参考文献

グローブ, アンドリュー・S. HIGH OUTPUT MANAGEMENT: 人を育て、成果を最大にするマネジメント. 小林薫訳. 日経BP, 2017.
スケルトン, マシュー; パイス, マニュエル. チームトポロジー: 価値あるソフトウェアをすばやく届ける適応型組織設計. 原田騎郎, 永瀬美穂, 吉羽龍太郎訳. 日本能率協会マネジメントセンター, 2021.
ケーガン, マーティ; ジョーンズ, クリス. EMPOWERED: 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ. 二木夢子訳. 日本能率協会マネジメントセンター, 2021.
ドラスナー, サラ. エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門. 岩瀬義昌訳. 日本能率協会マネジメントセンター, 2024.