管理職のためのエンジニア組織構築マニュアル

はじめに

クラスメソッド株式会社 AWS事業部長の佐々木です。

私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。

そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。

エンジニア組織構築マニュアル

骨子を定義する

これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。

• ポリシー
• ビジョン
• ターゲット

ポリシーは、その組織が最もこだわる一番大事な理念を定義します。その組織に所属すること自体が高いモチベーションになるようなメッセージ性を含めます。また企業理念と同様に、社会に貢献するものであることが望ましいと考えます。

ビジョンは、その組織の存在意義、つまりビジネスの方向性を具体的に定義します。何を持って誰に貢献するのかを定義することで、ビジネスの軸が定まります。

ターゲットは、明確なビジネス目標です。現時点でのゴールを明示することで、組織のメンバーが「今どこに向かって走っているのか」をはっきり意識出来ます。なお到達出来なければ意味がないので、短期間で更新される(基本的には常に高いものに更新され続ける)ものです。

弊部を例にあげると、ポリシーは「技術者が、技術することを楽しみ、技術によって世界を変えていく」であり、ビジョンは「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことをまるっとお任せしてもらうことで、顧客に価値を提供する」です。このようにそれぞれの骨子は1行程度で収め、組織のメンバーが常に意識出来るようにします。

組織構造をデザインする

骨子によって、その組織が行うべきビジネスが定まりました。次に組織構造をデザインします。必要なスキルセットと人数を定め、必要に応じてチームやグループを作ります。

組織構造は組織によって様々なため一概には言えませんが、チームやグループについては以下のようなルールを持っています。

• 頻繁にコミュニケーションを取るチームの人数は5名以下に抑える。
• 5名を超える場合は2チームに分けた上で1つのグループとして扱う。
• 1人のマネージャーの管理範囲は8人以下に抑える。

これはコミュニケーションパスの増加を抑制するためのルールです。コミュニケーションパスの数はn*(n-1)/2となるため、5人のチームではコミュニケーションパスは10ですが、10人になるとコミュニケーションパスは45と大幅に増加します。このため1チームは5名までとし、複数のチームをグループにまとめた上で、チーム間はリーダーによってコミュニケーションパスを繋ぎます。

また、Amazonの2 pizza ruleと同様、僕自身の経験からも、1人のマネージャーの管理範囲が8人を超えるとコミュニケーションが疎かになりがちです。このため8人を超える場合はマネージャーを増やして組織を分割します。

なお、ビジネスや社会状況が早いスピードで変化するのは必然であるため、組織構造も柔軟に変わるべきです。Elasticに変化出来るように、SPOF(Single Point of Failure)となる人が生まれないよう注意してください。テクニカルノウハウはもちろんリーディングやマネジメントのノウハウについても、社内でオープンに共有される仕組みを考慮しておきましょう。

コミュニケーションを設計する

次にコミュニケーションを設計します。良く使われるコミュニケーション手段は以下のようなものです。

• 朝会 ... 同じ案件を行っているメンバーで、その日の予定や課題を共有する。
• チーム週報会 ... 別々の案件を担当しているなどの理由で毎日の共有が不要な場合は、週1回、チーム内で案件の状況や課題を共有する。
• 組織週報会 ... 組織内の各チームリーダーが集まり、案件の状況や課題を共有することで、チームを跨ぎ横串で課題を解決する。
• 組織月報会 ... 組織のメンバー全員が集まり、組織の状況や課題やアクションを共有する。

コミュニケーションはコストではなく、組織にとって非常に重要な要素です。しかし大勢のメンバーが揃って行うものである以上、浪費すると大きな無駄となります。このため進め方は事前にしっかりと定義した上で、早く終わった場合にはすぐに解散するなど、効率的にコミュニケーションを行うようにします。また形骸化したコミュニケーション手段は迅速に廃止します。

行動指針を定義する

組織のメンバーの人数が少ないうちは雰囲気で共有できるのですが、人数が多くなってくると、メンバーに対してどのような行動を求めているのかが伝わりにくくなります。このため「この組織のメンバーにはこういった行動を期待したい」という行動の指針を、文章で明示化し共有します。

例えば弊部の行動指針を一部抜粋します。

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

行動指針をメンバーが共感し実行することによって、組織の文化が作られます。

採用方針を定義する

組織において文化は非常に重要ですが、文化は人によって作られますので、採用の方針がブレて文化の違う人が入ってくると、文化もブレます。文化に則った採用方針を明文化し共有することで、文化の違う人が入ってくるリスクを防ぐと共に、組織がどのような人を求めているかを社内外に伝えることが出来ます。

弊部の採用方針については過去にブログ化しましたので、以下の記事をご参照下さい。

• AWS事業部の採用方針について

エンジニアの成長スパイラルを設計する

組織のメンバーが同じことを同じだけしか出来ないと、ビジネスはスケールしません。組織の設計には組織のメンバーの成長を設計することも含まれます。

私はエンジニアの成長スパイラルを以下のように考えています。

• モチベーション ... 成長したい、という気持ち。
• インプット ... 学習。
• アウトプット ... 業務遂行、社内ノウハウ展開、イベント登壇、ブログ執筆、外部媒体執筆。
• 評価 ... 人事考課。

何故サイクルではなくスパイラルかというと、実際には以下のような構造だからです。螺旋状に上昇していくイメージです。

最初のモチベーションは何でもよく、例えば上長に指示されたから、というレベルでも構いません。そのモチベーションに対してインプットの機会を与え、アウトプットしてもらい、そのアウトプットを評価することで、次のモチベーションが生まれます。設計が必要なのはインプットの提供、アウトプットの定義、評価の設計です。

インプットの提供は、どれだけ選択肢を用意するかです。細かい話で言うと業務時間内のインターネットの利用可不可、コンテンツフィルタ有無(動画やスライドサイトへのアクセス等)、業務時間内のセミナーやイベントへの参加可不可、外部セミナーやイベントへの登壇可不可、外部媒体執筆可不可、海外カンファレンスへの参加補助有無、等です。弊社では全て可ですが、会社によって許可の範囲は違うかと思います。インプットの提供が多ければ多いほど、エンジニアが効率的に学習することが出来ます。

次にアウトプットです。インプットした学習は身につけただけでは評価出来ません。業務遂行に役立てたり、社内にノウハウを展開したり、あるいは外部セミナーやイベントへの登壇したり、様々なアウトプットの場や形があります。その場や形を設計します。例えば登壇機会を用意したり、技術ブログを立ち上げたり、社内勉強会の企画を促したりです。更に、それぞれのアウトプットが評価の対象となることをメッセージとして伝えることも必要です。

評価については人事考課として後述します。

エンジニアのキャリアパスを設計する

組織のメンバーがその時々の技術習得や案件のクロージングだけを意識するのではなく、3年後や5年後の自分の姿を想像しながら効率的に成長出来るよう、エンジニアのキャリアパスを明確にします。キャリアパスに添ってメンバーとコミュニケーションすることで、何をやりたいのか、何になりたいのかが共有しやすくなります。

例えば弊部ではエンジニアのキャリアパスを以下のように定義しています。

上記の通り、エキスパートソリューションアーキテクトのネクストステップとして、マネージャーとスペシャリスト、そして新しいチャレンジとしての他部署への異動という3つの選択肢を用意しています。メンバーを型にはめること無く、個々人のやりたいことを活かして組織もメンバーも成長できるようなキャリアパスを設計しましょう。

人事考課を設計する

成長スパイラルにも書いたとおり、メンバーのアウトプットを正しく評価することが、次のモチベーションに繋がります。このため評価=人事考課を適切に行うことが、エンジニアの育成において重要です。

この人事考課についても、意義と手段と評価基準を明文化し共有します。つまり、何故人事考課を行うのか、どのように人事考課を行うのか、何をしたら評価するのか、です。明文化しないと、メンバーから見たときに何を持って評価されているのか(あるいはされていないのか)が分からず、不信感が生まれます。

人事考課のための面談は、時間を充分に確保し、原則としてオフラインでの対面で行います。オンラインによるコミュニケーションロスは、正しく人事考課するための足かせとなります。また無理に短い時間に留めることなく、必要なだけしっかりと時間をかけて会話します。

また、可能な範囲で全て情報共有します。例えば給与や個人/家庭の事情に関わる問題は共有出来ませんが、誰が何をしようとしているのか、何にチャレンジしたいのか、何に悩んでいるのか、をメンバー全員に共有しておくと、自分以外のメンバーが何をしているのかが分かりますし、場合によってはメンバー同士で課題を解決出来ることもあります。

給与改定方針を定義する

給与は多くの人にとって重要ですし、人事考課の結果である評価は給与または賞与に反映されなくてはいけません。この給与についても改定方針を明文化します。どんなタイミングで改定するのか、どんな基準で改定するのか、何をしたら昇給するのか、逆に何をしたら減給するのか、等です。マネージャーが気分やノリで決めているのでは無いと、しっかりメンバーに伝えます。

ミドルマネジメントを作る

組織が大きくなってくると、どうしても自分1人だけで全メンバーをケアするのは難しくなります。組織の拡大にはミドルマネジメントが必須です。エンジニア組織の場合、メンバーの中でマネジメントに興味を持っていたり、素養があると思われる人をピックアップし、マネージャーとなれるように育成します。

組織外からマネージャーを採用するという手段もありますが、エンジニア組織のマネージャーはメンバーから信頼を得ていないと難しいという実感があるため、その組織の中で育てるのが望ましいと考えます。またエンジニアではない人がエンジニア組織のマネージャーをするのは多くの場合困難です。エンジニアの行動を正しく評価出来ないことと、エンジニア側が「正しく評価されていないのではないか」と疑念を抱くことが多いからです。

キャリアパスで書いたとおり、エンジニアにも様々なタイプがいて、マネジメントに向いている人もいればスペシャリストに向いている人もいますので、しっかりと見定めることが重要です。またマネジメントは必ずしも一生やり続けなければいけないわけではないので、興味がある人にチャレンジしてもらい、合わなければスペシャリストに容易にチェンジできるようにしておきます。

ミドルマネジメントとなってくれた人には積極的に権限を移譲し、ミッションを提示します。移譲し任せた範囲には口出しをせず、主体的に行動してもらいます。

部長を交代する

組織構造のデザインにも書いたとおり、組織の中にはSPOF(Single Point of Failure)となる人がいてはいけません。その人自体がリスクになるからです。これは部長も同様で、例えば部長が事故や怪我で働けなくなったことで組織自体が成り立たなくなるのであれば、部長という大きなリスクを組織が抱えていることになります。

そこで部長の業務自体も明文化し、何のために誰と何をしているのかを明確にしておくことで、いつでも引き継ぎ可能なようにしておきます。属人化ポイントをゼロにするのは困難ですが最小限に抑えることは可能です。

「部長を交代する」と書きましたが、正しくは「いつでも交代可能なようにする」です。ミドルマネジメントが育っていれば、交代はそれほど難しくは無いはずですし、難しくない状況にしておくのも部長の大事な仕事です。

さいごに

社内外でこれからエンジニア組織の立ち上げを行う方々のご参考になれば幸いです。