きれいなPCが整然と並ぶ高層階のオフィス。そこでは「VPoE」「アラインメント」「ステークホルダー」「エンゲージメント」など、いつの間にか難しそうな横文字が飛び交っています。
求人サイトを見れば、「エンジニアを100人採用しました」「開発組織を大幅に拡大しています」といった言葉が並びます。
もちろん、事業が成長すれば人材が必要になることもあります。大きなサービスを運営するために、多くのエンジニアが必要になるケースもあるでしょう。
しかし、IT業界で長く開発や組織を見ていると、ときどき強い違和感を覚えることがあります。
「本当に、そんなに人が必要なのだろうか？」
そしてもう一つ気になるのが、組織が大きくなるほど増えていく「不思議な資料」と「不思議な横文字」です。
人が増えることが、いつの間にか目的になる
会社に外部から資金が入り、事業を拡大するフェーズになると、「採用を増やそう」という話が出てきます。
これは一見すると、とても健全な成長戦略に見えます。
しかし、いつの間にか「何人採用したか」が組織の成果として扱われるようになると、少しずつ話が変わってきます。
エンジニアを採用する。
チームを作る。
マネージャーを置く。
マネージャーを管理する人を置く。
さらに組織を横断して調整する人が必要になる。
そして、気がつけば「システムを作るための組織」だったはずが、「大勢の人を動かすための組織」になっている。
ここで本末転倒が始まります。
そもそも、そのシステムを作るために本当にそれだけの人数が必要だったのでしょうか。
少人数で作れるものを、組織の都合によって大人数で作ってはいないでしょうか。
エンジニア組織が肥大化すると何が起きるのか
人が増えるほど、単純に開発力が増えるわけではありません。
むしろ、ある規模を超えるとコミュニケーションコストが急激に増えていきます。
誰が何を担当しているのかを確認するための会議が必要になります。
チーム同士の認識を合わせるための会議が必要になります。
さらに、その会議の内容を共有するための資料が必要になります。
資料を確認するための会議が始まり、その会議について説明するための資料まで作られる。
こうなると、エンジニアがコードを書く時間は少しずつ削られていきます。
本来ならプロダクトを改善したり、バグを修正したり、新しい機能を作ったりするために使うはずだった時間が、社内調整や会議、資料作成に消えていきます。
そして皮肉なことに、開発速度が落ちるほど、さらに管理や調整が必要になっていきます。
「なぜ開発が遅れているのか？」
「なぜ予定通り進まないのか？」
「どうすれば組織として改善できるのか？」
こうした問いに答えるため、さらに会議と資料が増えていきます。
「不思議な資料」はなぜ増えるのか
組織が大きくなると、動いているプロダクトよりも「説明するための資料」が重要になる瞬間があります。
実際にコードを書いて、サービスを改善して、ユーザーに価値を届ける。
本来なら、それが最も分かりやすい成果です。
ところが、大きな組織では「何をやったのか」を説明すること自体が仕事になってしまうことがあります。
経営層に説明するための資料。
上司に報告するための資料。
他部署と認識を合わせるための資料。
会議で説明するための資料。
そして、その資料を作るための資料。
もちろん、すべての資料が不要という話ではありません。
複雑なシステムを扱う以上、設計書や仕様書、意思決定の記録など、必要なドキュメントは存在します。
問題なのは、成果を生み出すためではなく、「仕事をしていることを証明するための資料」が増えてしまうことです。
動くコードよりも、きれいなPowerPointのほうが評価されるようになったら、組織は少し危険な状態に入っているのかもしれません。
「不思議な横文字」が増える理由
そして、資料と一緒に増えていくのが横文字です。
アラインメント。
ステークホルダー。
エンゲージメント。
ガバナンス。
オーナーシップ。
もちろん、これらの言葉そのものが悪いわけではありません。
専門用語には、複雑な概念を短く伝えるという重要な役割があります。
問題は、言葉だけが立派になり、中身が伴わなくなったときです。
「関係者とのアラインメントを取ります」と言っているけれど、実際に何をするのか分からない。
「ステークホルダーとのエンゲージメントを高めます」と言っているけれど、具体的な成果が見えない。
こうした言葉が増えるほど、仕事の実態が見えにくくなります。
本当は「この人と話して、この仕様を決めます」で済む話なのに、難しい言葉を使うことで、仕事そのものが大きく見えてしまう。
結果として、実態のない社内調整に権威が与えられてしまいます。
誰もやりたがらない仕事こそ、本当に重要なのではないか
考えてみれば、これはIT業界に限った話ではありません。
人間は誰だって、できれば楽な仕事をしたいものです。
責任が重く、失敗すれば怒られ、成果が出ても当たり前だと思われる仕事よりも、きれいなオフィスで会議をして、資料を作って、もっともらしい言葉で説明する仕事のほうが魅力的に見えることがあります。
しかし、会社やサービスを本当に支えている仕事は、意外と地味です。
バグを直す。
古いコードを読む。
障害対応をする。
ユーザーからの問い合わせに対応する。
遅いシステムを改善する。
誰も見ていない部分の技術的負債を返済する。
売れるものを作る。
そして、実際にそれを使ってもらう。
こうした仕事には、派手さがありません。
SNSで「組織を拡大しました」と発信するような華やかさもありません。
それでも、こうした地味な仕事の積み重ねが、実際のプロダクトと事業を作っています。
本当に強いエンジニア組織は「大人数」なのか
もちろん、すべての会社が少人数で運営できるわけではありません。
巨大なサービスを支えるには、大規模なエンジニア組織が必要になる場合もあります。
ただし、「大きい組織＝強い組織」と考えるのは危険です。
重要なのは人数ではなく、必要な人が必要な場所にいることです。
優秀なエンジニアが少人数で集中して開発できる環境と、何十人もの人間が会議と調整を繰り返しながら開発する環境では、同じ人数でも生み出せる価値は大きく変わります。
少数精鋭のチームには、大きなメリットがあります。
意思決定が速い。
コミュニケーションがシンプル。
責任の所在が明確。
そして何より、「誰のために何を作っているのか」が見えやすい。
必要以上に人を増やさず、本当に必要な仕事に人と時間を集中させる。
これは、エンジニア組織の生産性を考えるうえで、とても重要な視点だと思います。
「忙しい」と「価値を生み出している」は違う
組織が大きくなると、「みんな忙しく働いている」という状態は簡単に作れます。
会議があります。
チャットが飛んできます。
資料を作ります。
レビューをします。
進捗を確認します。
さらに会議があります。
一日が終わるころには、誰もが「今日は忙しかった」と感じるでしょう。
しかし、忙しかったことと、価値を生み出したことは同じではありません。
一日中会議をしていても、ユーザーの課題が何も解決されていないのであれば、プロダクトは前に進んでいません。
何十枚もの資料を作っても、売上が増えたり、サービスが改善されたりしなければ、それは成果とは言いにくいでしょう。
だからこそ、IT組織の生産性を考えるときには、「どれだけ人を増やしたか」ではなく、「どれだけ価値を生み出したか」を見る必要があります。
少数精鋭のモノづくりを取り戻す
個人的には、ITの仕事にはもっとシンプルな美しさがあっていいと思っています。
必要な人が集まる。
必要なものを決める。
コードを書く。
動かす。
問題があれば直す。
ユーザーに使ってもらう。
そして、また改善する。
本来のモノづくりは、とてもシンプルです。
もちろん現実には、セキュリティやコンプライアンス、法務、品質管理など、無視できない仕事もあります。
しかし、そうした必要な仕組みと、「組織を維持するためだけの仕組み」は分けて考えるべきです。
必要のない会議を減らす。
意味のない資料を減らす。
中身のない横文字を減らす。
過剰な管理を減らす。
そして、コードを書く人、ユーザーと向き合う人、事業を前に進める人に、もっと時間を戻す。
それだけでも、エンジニア組織の生産性は大きく変わるはずです。
きれいなオフィスより、動くプロダクトを
高層階のきれいなオフィス。
最新のPC。
増え続けるエンジニアの人数。
立派な肩書き。
難しそうな横文字。
きれいに整理されたPowerPoint。
これらは、会社が成長しているように見せるには非常に分かりやすいものです。
しかし、本当に重要なのは、そこではありません。
ユーザーが困っている問題を解決できているか。
実際に使われるプロダクトを作れているか。
売上や利益といった事業の成果につながっているか。
そして、そのために必要な仕事を、必要な人がきちんとやれているか。
そこが本質なのだと思います。
「人を増やすこと」が目的になった瞬間、組織は少しずつ本来の目的から離れていきます。
「資料を作ること」が成果になった瞬間、モノづくりから遠ざかっていきます。
「横文字を使うこと」が仕事の価値を高めるようになった瞬間、実態よりも見せ方が重要になってしまいます。
だからこそ、時々立ち止まって考えたい。
「この仕事は、本当に必要なのか？」
「この会議は、本当に必要なのか？」
「この資料は、本当に必要なのか？」
「このポジションは、本当に必要なのか？」
そして何より、「今、自分たちは本当に価値を作っているのか？」
無駄な組織肥大化のレースから降りて、本当に必要な仕事に集中する。
少数精鋭で、シンプルに、確実に、価値のあるものを作る。
それこそが、ITにおけるモノづくりの本来の姿なのではないでしょうか。