エンジニアリングチームの課題を解決！TTJお悩み相談室・第6回「エンジニア組織を成功に導くための『4つのマネジメント』」

マネジメント、採用、育成、意思決定……エンジニアリング組織を率いるCTOやVPoEの方々は、日頃から大小さまざまな課題に向き合っています。このコーナーでは、エンジニアリング組織のお悩みを読者の皆さまから募集。UUUM株式会社の元CTOで、現在Repro株式会社の執行役員CTOを務める尾藤正人さんがアドバイスします。

第6回のお悩みはエンジニア組織のマネジメントの役割とその切り分け方についてです。

お悩み：エンジニア組織のマネジャーの人材配置が難しい

技術力のあるエンジニアにマネジャーを担って欲しいと思うのですが、あまり乗り気でない場合が多く、実際にプロジェクトを適切に回せないことも多いようです。エンジニア組織や開発プロジェクトの適切なマネジメントのためには、人材配置を含めどういったことに気をつけるとよいでしょうか。

尾藤さんからの回答

開発組織で「ピラミッド型組織」がうまくいかない理由

旧来の日本的な組織は「ピラミッド型組織」と呼ばれる構造をしており、少数の上位者が意思決定をおこなうトップダウン方式です。このような組織ではマネジメントを担う人はマネジャーという肩書きで実作業はせず、全体の管理をするのが役割です。マネジャーは進捗管理やコスト管理、社内外の関係各所との調整などを一手に引き受けます。

しかしシステム開発のプロジェクトは非常に複雑で、マネジャーの役割をひと言で表すことはできません。たとえば大きく分けても「技術（テクノロジ）マネジメント」「プロジェクトマネジメント」「プロダクトマネジメント」の3つの異なる役割があります。

上に挙げた各マネジメントは専門分野がまったく異なり、それが役職名にも現れています。一例として順に言うと「テックリード」「プロジェクトマネジャー（PM）」「プロダクトマネジャー（PdM）」です。つまり別の職種として存在しているとも言えます。

さらにエンジニア組織でチーム開発をするのであれば、技術にかかわるマネジメントとは別に、組織マネジメント（ピープルマネジメント）も必要になります。

ここまで挙げた4つのマネジメントは求められる役割や業務内容が異なるだけでなく、向き不向きも一様ではありません。そのため企業のフェーズや規模も関係してきますが、それら方向性の違うマネジメントをひとりが担うことにそもそも無理があるのです。

専門領域ごとに役割を分ける重要性

実はマネジメントの領域を分けることは、適切なエンジニアの評価にもつながる話です。旧日本的な組織構造の場合、開発組織のトップの人は自分の専門領域とまったく異なる人を人事評価しなければならないことがよくあります。しかしエンジニアという仕事の特性上、それぞれの専門分野の人にしか正しい評価はできません。

それらを踏まえるとシステム開発のプロジェクトを従来の日本のピラミッド型組織でうまく回していくのは難しいどころか、個人的にはほとんど不可能に近いと思っています。その結果が昨今よく見られる「なぜかいつも開発プロジェクトがうまくいかないから、とりあえずCTOを探してどうにかしてもらおう」という発想です。

さきほど挙げた職種で、テックリードとPMとPdMの3つの役割が違うことはだいぶ浸透してきていると思いますが、それぞれとピープルマネジメントは重なっていると考える人（もしくは組織）は多いようです。実際に日本では多くの場合、その人たちが本来の役割とピープルマネジメントを兼ねています。

私は本来はこれらもきちんと役割を分けるべきだと思っています。専門性が異なるとお伝えしましたが、エンジニアの中には技術はものすごく立つけども、口ベタだったり人をリードしたりするのが苦手だというタイプもいますよね。アーキテクトをリードするのが得意で、エンジニアとしての技術力が高くて有名な人が、チームメンバーひとりひとりと向き合い、その人のキャリアや成長をサポートできるかというとやはり少し違う気がします。そもそも開発が好きなのであって、マネジメントにはそれほど関わりたくないという人もいます。

よってシステムのアーキテクチャの設計や技術的なリードを十分やってくれる人をテックリードに置いたときに、その人にピープルマネジメントまで求めるのは適切とは言えません。ピープルマネジメントは技術的スキルとはまた別の専門性やテクニックが必要で、誰でもできるわけではありません。

また、役割分割は専門職であるエンジニアが開発業務に集中し、成果を出せる環境を作ることにもつながります。

仕事をする上で発生する技術周りや組織運用に関する雑用を現場のエンジニアにやらせると効率がどんどん落ちます。それをエンジニアリングマネジャー（EM）が積極的に巻き取って、エンジニアが開発以外の仕事に時間を取られないようにすべきだと考えています。

たとえば、開発業務のかたわら会社のホームページ運用をやるだとか、本来情シスを設置してやるべきツール系の運用だとか、そういったものを「現場のエンジニアにはやらせたくない」という感覚を持っている人がマネジメント側にいるかは重要です。

役割を分けないとエンジニア採用のハードルが上がる

少し前まではCTOがエンジニアに関するマネジメントをすべてカバーしていた時代もありました。ただ、現在は専門性や役割に合わせて分化していくのが健全だという考え方が浸透しつつあります。

もちろん悪いところばかりではなかったと思いますが、エンジニア組織もといIT業界も経験の積み重ねによってある程度方法論が生まれて進化してきました。最初はエンジニア組織のトップと言えばCTOという役職しかなかったのが、VPoEが出てきて、CIO（Chief Insights Officer：最高情報責任者）は別に置こう、セキュリティ周りはCTSO（Chief Testing Solution Officer）に任せようとかですね。

システム開発も近いところがあって、開発をやっていてうまくいかない部分ががあるからこそ、そこに対して体系的な方法論が出てくるんだと思います。

これまではエンジニアのマネジャーに技術的なリードもピープルマネジメントもすべて求めている面がありました。しかし、さきほども述べたとおり技術力が非常に高くてテックリードの素質がある人が、ピープルマネジメントも得意とは限りません。そのためそこは役割を分けて別の人に任せたほうがよいでしょう。

というのもそうやって分けていかないと、ひとりの人にベクトルが異なる専門スキルをいくつも求めることになり、それだけ採用のハードルが上がります。テックリードクラスの人を採用するだけでも難易度が高いのに、常に複数の専門スキルをカバーできる人材を採用するのがどれほど大変かは、読者の皆さんもよくご存知かと思います。そんな苦労をするよりも各分野の専門スキルを持った人材を集めて組織をスケールしていったほうが賢明です。

会社のフェーズによって柔軟な対応が必要

役割を分けるという話をしてきましたが、ベンチャー企業やスターアップの創業期のように人数が少ないうちからそうすべきかというのは悩ましいところだと思います。ただ、一つの役割に一人を専任でおけず兼任する場合でもなんとなくでカバーするのではなく、役割分担はしっかり決めたほうがよいのは間違いありません。

一方、少人数の組織で役割分担をすると属人化の温床になりがちです。フェーズに合わせて柔軟な変化をしながらリスクを低減・回避するといった対応が必要です。

第5回目にRACI図を用いたタスクの責任者とその役割、責任範囲などを明確化する手法をご紹介しましたが、これは企業規模に関わらずやるべきだと思っています。というのも責任領域が曖昧だと、問題が宙に浮いたままになったり、逆にひとりでタスクを抱え込んでしまう人が出てきてそこがボトルネックになるといったこともあります。

また、指揮系統を決めておくことも同じくらい重要です。開発に限らず物事をうまく回していこうと思ったときに、指揮系統と責任者が不明瞭のままでは絶対にうまく進みません。

事例として私がお手伝いした従業員10名ほどの企業で起こったことを簡単にお話します。組織図としては、創業者（CEO）がトップにいて、PMがいて、エンジニアがいてという形です。CEOは非常に情熱があって、「これをやりたい」「あれをやりたい」というのを常に思い描いている方でした。エンジニアはCEOから直接「これをやってくれ」と言われたらやらざるを得ません。本来順序立てて取り掛かっていた作業に割り込む形になるので作業が飛んでしまうこともありましたし、何よりPMがその状況を把握できていませんでした。

そこで私が「この状態では適切なプロジェクトマネジメントはできない」とお話して、まずはPMの役割と、PO（プロダクトオーナー）であるCEOの役割と、エンジニアの役割を明確にしました。つづいて、エンジニアに直接依頼をした際は、必ずPMに報告をするように取り決めました。なぜなら開発プロジェクトに対して責任を持つのはPMで、CEOはPOであって責任者ではないからです。

組織設計も「独立性」「連動性」を重視するべき

よいシステムを作るには、システム設計の段階でモジュールを分けることを考えます。役割を分けるという点から、組織設計とシステム設計はとても似ています。

ソフトウェア設計の5つの原則の頭文字を取った「SOLIDの原則」の中のもっとも知られている「単一責任の原則」では、ひとつのクラスは必ずひとつの責任を持って、与えられた役割だけをこなすと定められています。その原則に従うと仕様変更の影響を受けるのはそのクラスに閉じた仕様のみとなります。

組織でいえば、他との依存関係が少なく、関係各所に確認や問い合わせをする必要がないので、内部だけで改善を進めることができる状態です。独立性があると改善のサイクルが速くなります。そして組織設計でもシステム設計でも同様に大切なのは、分けた役割（モジュール）同士ががうまくコミュニケーションを取って連動できるかどうかです。

もちろん独立性と連動性を両立するのは簡単ではありません。どちらを優先すべきかと悩む場合もあるでしょう。役割を分けるとコミュニケーションがおろそかになります。その場合は会議体を設定するなど、意識的にコミュニケーションを取れる体制を作る必要があります。また、分けた役割同士の連携がうまくいっているかは前述のとおり定期的な1on1で状況をフィードバックすることも大切です。

個人的には役割を分けて独立性を持つことをまず徹底するほうが大切だと考えます。依存関係が強いと調整や確認作業など無駄が多く発生し、事業スピードが出せないからです。
独立性を優先していくと、当然専門スキルを持つ人たちは自身の得意分野に分化していくので兼任も減っていくと思います。

役割を与えられた人の動機付けも大切

私がRACI図でいう、役割を分けてアカウンタブルを設定するときには、そのアカウンタブルの人が持つ役割はその人自身に作ってもらいます。なぜなら人に決められた役割というのはやらされている感が出てしまい、本人の目標達成に対する意識が低くなってしまうからです。

人間は自分で決めたことならやり遂げようとします。私もある程度の方針は示しますが、そういった気持ちのコントロールもしながら、うまく役割を分けて、自然と自主性が出てくるように導きます。

現実的には、エンジニア組織で適切な場所に適切な人をしっかり配置できるほど、人材が潤沢な組織はなかなかないとは思います。ときにはやむを得ず兼務してもらうこともあるでしょう。本人のモチベーションよりもスキルを重視してマネジメント職に任命することも出てくるかもしれません。しかし今回お伝えしたとおり、「役割を分ける」そして「責任の所在を明確にする」を頭において組織設計をしていただければと思います。

尾藤さんに聞きたいお悩みを募集しています！

「TTJお悩み相談室」では、エンジニアリング組織のさまざまなお悩みについて、尾藤正人さんに相談したい内容を募集中です。

こちらのフォームより必要事項をご記入ください。

皆さまからのご質問をお待ちしております！