（CTOが）エンジニア組織（体制）をつくる時に意識するべきこと

• 基本的に社内に技術部門がなく、これから組織をつくる
• 何名かの社員エンジニアがいる、もしくは採用予定がある

骨子を定義

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

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

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

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

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

組織構造をデザインする

必要なスキルセットと人数を定め、必要に応じてチームやグループを作ります。
最近は案件や事業ごとに小規模チームを構成して他部署とコミュニケーションするマトリクス型組織が一般的です。

組織構造は組織によってさまざまであるため一概には言えませんが、チームやグループについては以下のようなルールがあるといいでしょう。

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

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

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

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

■朝会 ・・・同じ案件を行っているメンバーで、その日の予定や課題を共有する。DailyScrumと言っているところもある。

■チーム週次定例・・・別々の案件を担当しているなどの理由で毎日の共有が不要な場合は、週1回、チーム内で案件の状況や課題を共有する。

■リーダー定例・・・組織内の各チームリーダーが集まり、案件の状況や課題を共有することで、チームを跨ぎ横串で課題を解決する。

■部門月次定例・・・組織のメンバー全員が集まり、組織の状況や課題やアクションを共有する。

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

行動指針を定義

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

以下は例です。コンピテンシーとして定義している会社もあります。

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

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

採用方針を定義する

組織において文化は非常に重要ですが、文化は人によって作られますので、採用の方針がブレて文化の違う人が入ってくると、文化もブレます。

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

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

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

一般にエンジニアの成長スパイラルは以下のようなものと考えられます。

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

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

インプットの提供は、どれだけ選択肢を用意するかです。会社によって許可の範囲は違うかと思います。インプットの提供が多ければ多いほど、エンジニアが効率的に学習できます。

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

評価についてはメンバーのアウトプットを正しく評価することが、次のモチベーションに繋がります。このため評価=人事考課を適切に行うことが、エンジニアの育成において重要です。人事考課については後ほど詳細を説明します。

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

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

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

人事考課を設計

人事考課についても、意義と手段と評価基準を以下のように明文化し共有します。

• なぜ人事考課を行うのか
• どのように人事考課を行うのか
• 何をしたら評価するのか

明文化しないと、メンバーから見たときに何を持って評価されているのか（あるいはされていないのか）が分からず、不信感が生まれます。

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

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

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

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

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

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

参考：よくある失敗例

スキルだけで計画性のない人材を採用してしまう

エンジニア組織を考える際、最初の一人は非常に大切です。スキルはもとより、組織のあり方や会社のビジョンに対する自分なりのポリシーを持っていない人を採用してしまうことで、エンジニアでない人も振り回されてしまいます。
社内にエンジニアリーダー的な人がいない場合は自社のことを理解している外部の企業からスポットで技術顧問を採用してもいいかもしれません。

強制的にエンジニアブログを書かせる

最近では技術広報という名で社外向けにエンジニアブログを書かせる企業も増えてきています。しかし、文書作成は苦手なエンジニアも多く、時間を消費してしまう作業です。ネタ探しひとつとってもリーダーの考える水準に満たなくなっていることが往々にしてあります。また、ブログが評価につながらない組織も多いので、やる気を失わせる要因になります。隙間の時間で書かせるのではなく、開発と同列と考えて、きちんと内容含めてプランニングするのが良いでしょう。

無制限に外部セミナー

社内での開発作業だけやっていてもエンジニアとしての視界を狭めてしまい、人材としての価値を下げかねません。社外でも通用する人材になるため、かつ社内の開発の質を向上させる目的で社外セミナーを推奨する企業があります。
非常に良いことではありますが、社内の開発スケジュールを阻害しないように計画的に組み込むべきと考えます。こういった相談がしやすい社内環境にすることも肝要で、外部セミナーがサボっている印象となりエンジニアが萎縮する原因にならないようにしましょう。

表面だけで20％ルールを採用してしまう

かつてGoogleが週のうち1日を自由研究のための時間に使えるようにした20％ルールが話題になりました。この活動から生まれたのがGmailであり、Googleの技術力の源泉でもあります。
しかし、上記の「無制限に外部セミナー」と同様、企業の生産活動の一環として計画的に組み込めないのであれば、実施しない方が良いでしょう。人材採用においてこういったわかりやすいPRは必要ですが、無理をする必要はありません。

エンジニア専用オフィスでビジネス部門と格差をつける

エンジニア部門だけ高価なアーロンチェアにするとかはあります。これはエンジニアにとっては特権と錯覚してしまいやすいところであるためバランスが肝要です。かつて大手ITベンチャーでも急激にエンジニア待遇を改善したことがありました。ただしこれはそれまで開発専用スタッフのような扱いで、営業が強い組織だったことからバランスを取りつつ、採用強化するという強いメッセージを出すことが目的でした。
本質を捉えないでこのような施策を行うのは危険です。どういう意義をもってエンジニア優遇するのか、よく検討することが大事です。

他にも失敗例を挙げれば枚挙に暇はありませんが、共通して言えることは会社の理念に沿ったポリシーを持ったリーダーを最初に用意した上でその人を中心にじっくり組織を作っていくことが長期的に大事であるということです。その過程で失敗があったとしてもコアとなるポリシーがあることできちんと原点回帰してぶれない組織を作ることができます。むしろ失敗も肥やしとして社内にノウハウを蓄積できる＝成長の機会と考えられます。

CTOはこういった全体像を俯瞰して統制していく仕事です。人数が増えるほど大変にはなりますが、やりがいはあります。色々な先輩の事例も参考に良い組織をつくっていけるように頑張っていきましょう。

=================

今回の記事では、CTOがエンジニア組織をどのようにしてつくるのか、注意点などについてもお伝えしました。
エンジニアのキャリアパスでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。