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

エンジニア部門は多くの企業にとってエンジンとなりうる存在です。うまく組織が回るようになれば、各メンバーの生産性は足し算ではなく掛け算となって企業に利益をもたらします。
しかし、CTOへのキャリアを歩んだ方から、「そもそもどのようにして構築すべきか」「具体的なゴールイメージがなく途方も無い作業に感じる」というご相談をいただきます。そこで、今回の記事では、CTOがエンジニア組織をどのようにしてつくるのか、注意点などについてもお伝えします。

まずは前提条件として、
・基本的に社内に技術部門がなく、これから組織をつくる
・何名かの社員エンジニアがいる、もしくは採用予定がある
という想定で話を進めます。

これらの条件を元にエンジニア組織の作り方について解説します。ちなみに業務委託のエンジニアばかりの組織でも評価のやり方を工夫することで（契約の延長がある種の評価のバロメーターになることもある）強い組織を作ることが可能です。

【目次】

1. 骨子を定義
2. 組織構造をデザインする
3. コミュニケーションを設計する
4. 行動指針を定義
5. 採用方針を定義する
6. エンジニアの成長スパイラルを設計する
7. エンジニアのキャリアパスを設計する
8. 人事考課を設計
9. ミドルマネジメントを作る
10. 参考：よくある失敗例

骨子を定義

これはエンジニア組織に限りませんが、組織には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へのキャリアに関する記事

“スタートアップCTO”の「よくある苦労」と「乗り越え方」
https://www.axc.ne.jp/media/careertips/startup_cto_case

エンジニア（SE）からCTO、CIO、CDOへのキャリアパス【志望理由～必要なスキル～転職事例まで】
https://www.axc.ne.jp/media/careertips/SE_CTOCIOCDO

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

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