創業記念日なのでエンジニア組織のマネージャーについて考えてみた

佐々木大輔

2019.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本日7月7日はクラスメソッド株式会社の創業記念日です。クラスメソッドは16期目を迎えました。つまり15周年ですね。ばんざーい。

さて、最近すっかりテクニカルなブログを書く機会が減ってしまった僕ですが、創業記念日の今日も、マネジメントについてポエムりたいと思います。なお、マネージメント論やマネージャー論は人によって大きく想いや解釈が違うものであり、その組織の状況やフェーズや文化によってそれぞれ違います。以下のブログはあくまで僕個人の価値観であることをご理解ください。

マネージャーは不要なのか？

という話題をよく見かけるようになりましたが、まずそもそもエンジニア組織のマネージャーって何やってるの？というところを細分化したいと思います。エンジニア組織のマネージャーをロールに分けるのであれば、大きく以下の4つになると僕は考えます。

組織マネージャー
技術マネージャー
ビジネスマネージャー
ピープルマネージャー

組織マネージャー

組織をマネジメントするのが組織マネージャーです。組織のマネジメントとは大きく3つです。

ビジョンを掲げる
カルチャーを作る
採用をデザインする

ビジョンを掲げる

Google re:Workにも「ビジョンはチームの成功に不可欠である」と書かれているとおり、組織においてビジョンは一番重要です。ビジョンを制定することで、組織全員がそのビジョンを実現することに集中し、同じ方向を向いて進むことが出来ます。つまり組織における旗印がビジョンです。組織のマネージャーはこの旗を大きく掲げて、メンバーに「こっちに向かっていくんだぞ」と示して上げる必要があります。

クラスメソッドのビジョンとして掲げている経営理念は「すべての人々の創造活動に貢献し続ける」で、僕が部門長をしているAWS事業本部の活動理念は「世界最強のAWSエンジニア集団(として、すべての人々の創造活動に貢献し続ける)」です。

カルチャーを作る

ビジョンだけでは組織は出来ません。そのビジョンを達成するための組織には、カルチャーも不可欠です。カルチャーはどのように作られるのでしょうか？まず、こんなカルチャーがある組織にしたいんだ、というのを全員に共有しなくてはなりません。雰囲気だけではカルチャーと呼べません。僕はそれを行動指針としました。弊部の行動指針を一部抜粋します。

全員がリーダーでありマネージャーでありプレイヤーである
自由に提案しオーナーシップとリーダーシップを持って自分で遂行
週に1本以上ブログを書く
月に1回以上社内外の勉強会に参加する
月の稼働時間は200時間を超えない
お客様にファンになっていただく

この行動指針に則った結果が弊部のカルチャーになります。もしカルチャーを明文化するのであれば以下の3つだと僕は考えています。

セルフマネジメント
自学自習
アウトプットコミュニケーション

採用をデザインする

採用はビジネスによって行うものではなく、カルチャーによって行うものです。つまり、ビジネスとして必要な人を採るのではなく、カルチャーに合う人を採ることが重要です。

ビジネスは状況によって大きく変わるものなので、そのビジネスに必要な人を採用した場合、ビジネスの方向性が変わると与える仕事がなくなってしまうかも知れません。しかしカルチャーに合っている人であれば、ビジネスが変わっても違う仕事をしてもらうことが出来るでしょう。採用のデザインはカルチャーに従って行うべきです。

ビジネスマネージャー

その組織がどのようなビジネスを行うのかはビジョンに基づきます。逆に言えばビジョンを実現するために何のビジネスを行うのかを決める必要があります。そのビジネスを設計し推進するのがビジネスマネージャーです。

まずそのビジネスの要件定義を行い設計します。そのビジネスのためにセールスやマーケティングの組織を設計し、活動の指針を制定します。セールスのための営業資料やマーケティングのためのWebサイトを作成します。また、ビジネスの種類によっては運用保守も設計します。

技術マネージャー

技術マネージャーはその組織の技術の方向性をマネジメントする人です。つまりその組織で行っているビジネスで利用する技術の選定や、その技術を提供してくれるパートナーの選定です。

例えば我々はAWSに関するコンサルティングや環境構築、運用保守をビジネスとしていますが、そもそもは会社の企業理念である「すべての人々の創造活動に貢献し続ける」を実現するために、クイックかつ安価に情報システムを開発することが可能なパブリッククラウドサービス=AWSを選択しました。またAWSだけではお客様の期待する情報システムの機能を全て実現出来るわけではないため、セキュリティベンダであるTrend MicroやSumo logicなどとパートナーシップを結び、お客様に提供しています。

このような技術や技術パートナーの選定を行うのが技術マネージャーです。

ピープルマネージャー

所謂人の管理です。勤怠管理と指導、業務申請の確認と承認、1on1、人事考課、キャリア相談、経費精算の承認、などなど...

マネージャーのロールの中で一番嫌がられるケースが多いのがこのロールではないでしょうか。しかし人の管理ではなく人の育成として考えるととてもやりがいのあるロールです。

誰がマネージャーになるのか？

小さい組織の場合、マネージャーを細分化すると逆に合議を求めすぎて判断のスピードが落ちるため、組織、ビジネス、技術、ピープル、全てを一人の人が担うことが多いかと思います。

しかし組織が大きくなると、特にピープルについては大人数を一人で取りまとめるのは難しくなります。また組織が役割によって分割された場合、その少組織ごとに採用すべき技術の違いが出てくる場合もあります。このため、技術とピープルは少組織ごとに分担され、組織とビジネスのマネージャーのみを大組織のマネージャーが担うことが多いでしょう。つまり、本部長は組織とビジネスのマネージャー、部長は技術とピープルのマネージャー、のようにです。

更に、大きなビジネスになるとビジネスの品質管理やセールス及びマーケティングメッセージの統一など、やるべき仕事が増えてきます。この場合、組織マネージャーとビジネスマネージャーは分割され、事業企画組織がビジネスマネージャーを担います。

で、マネージャーは不要なの？

ビジョン、カルチャー、採用が高度に組織化されていれば、技術マネージャーとピープルマネージャーは不要になるだろうと僕は考えます。セルフマネジメントが徹底されていればピープルマネージメントなんてする必要がありません。またメンバーが全員ビジョン及びそのビジョンを達成するためのビジネスにコミットしていれば、自分たちで技術の選定や技術パートナーの選定は出来ます。事実、弊社の技術マネージャーとピープルマネージャーのロールはかなり簡素化しており、交代も容易です。

組織マネージャーとビジネスマネージャーは必要だと僕は考えます。世の中のビジネススピードの移り変わりは本当に激しく、そのスピードに合わせて組織やビジネスをリデザインしなくてはならないことが多々あります。組織とビジネスが固定化した組織は数年で化石化してしいます。ただしそれを担う人自体は交代が必要だと考えています。ロールに人が固定化すると、その人が組織運営のリスクになるからです。