前回のコラム「CTOが０から開発チームを作る前にかならず考えておきたい”5W”のコツ」では、５Wを整理することによって開発チームを作り始める準備、すなわちなぜ開発チームが必要か、どのような開発チームであるべきか、を明らかにする方法についてご説明しました。この内容がクリアであればあるほど、実際に開発チームを作っていく過程で効率よく、起き得る問題を最小限にしながら進めることができると思います。
今回のコラムでは、実際に開発チームを作る過程（How）について説明します。開発チームを作る過程は主に採用、オンボーディング、チームビルディングに分けて考えることが出来ますが、それらの具体的な方法論よりも、全ての過程を通して共通して活用できるコツをご紹介したいと思います。
チームづくりの基本となる「チーム憲章」
チーム作りの過程を通して常に共通した指針となるもの、それは「チーム憲章」です（実は今まで特に名付けたことがなかったので色々考えました。
最も近い呼び名としてこれを選びましたが皆さんがしっくりする名前で運用していただければと思います）。このチーム憲章をしっかり作ることで、チーム作りの全てのフェーズにおいて拠り所となり、マネジメントにおけるあらゆる問題への対処する際に一貫して同じ考え方で接することが出来ます。
このチーム憲章には何を記すべきでしょうか。開発チームを作るための５Wは前回のコラムで整理しましたので、それを元に次の３点へ集約します。
- 我々は何者か？今何をしていて、これから何をしていくのか
- それはなぜなのか
- そのために、今何が必要なのか
１．我々は何者か？今何をしていて、これから何をしていくのか
ここでは会社、事業の全ての前提となる情報を明確にしていきます。
- 会社が目指すものや、創り出したい世界（ビジョン）・存在意義（ミッション）
- そこに向かっている中での現在地、現在の事業の状況と今後の計画
これらは企業WEBサイトや会社説明資料、ピッチブックなどによく記載されている内容です。この部分を明確にすることは重要ですが、あまり力を入れすぎると何のためのチーム憲章かわからなくなってしまいますので、できるだけ簡潔に書きましょう。たくさんの情報は必要ありませんし、数字だけが上滑りする内容はあまり説得力がありません。想いと実感がこもった内容が一番伝わりやすいのではないかと思います。大きな組織の場合は会社のビジョンなどではなく、開発チームそのもののビジョンやミッションでも良いと思います。組織のサイズに合わせてメッセージの目線を調整した方が実感を伴って伝えることが出来ます。
2. それはなぜなのか
１の内容に対して、「なぜならば」という説明で補足します。
- なぜそれを目指したいのか
- なぜそのような想いを持っているのか
- なぜそのような計画になっているのか
などです。
１をシンプルに記載する分、理由をしっかり補足することで、読む人が興味を持ち、また自分に何ができるかを能動的に考え始めたりすることが期待出来ます。もちろん、文書化するのが難しい場合もありますので、口頭でも話ができるようにしっかりと考えておくと良いと思います。
3. そのために、今何が必要なのか
ここが最も重要です。開発チームを作るための各フェーズに繋げていきます。例えば、
- 採用：「だから今こういうエンジニアが必要です」
- オンボーディング：「だからあなたに入社してもらいこういう業務を担当してもらいます」
- チームビルディング：「だから今のチーム編成をこういう風に変えていきます」
などです。
次に、それぞれのフェーズでこのチーム憲章がどのように活用されていくのか、もう少し詳しくご紹介します。
採用：チーム憲章による社内外への情報発信
採用の準備は皆さんどのように始めるでしょうか。求めるスキルと経験、働き方、条件などを記載して、採用媒体に掲載したり人材紹介会社へ依頼したり、あるいはエンジニアの知り合いが多い人はSNS経由で自ら募集したり、直接狙い撃ち、ということもあると思います。
どのような方法で採用をするとしても、このチーム憲章は次の２点で役に立ちます。
1.チーム憲章が募集要項そのものとなる
例えば採用媒体に記事を出す場合や自社WEBサイトに掲載する場合、スカウトメールを送る場合など、単に求めるスキルや職務内容だけを記載した場合に比べて、チーム憲章の内容を記載することによって、よりビジョンやミッションに興味を持ってくれたり、想いに共感してくれるエンジニアが集まる可能性が高まります。
同じように、社内の人事担当者や人材紹介会社の担当者にとっても、なぜこのポジションを募集しているのか、どのような人が適切なのか、という理解を深めることができます。その結果、採用候補者のソーシングの精度が上がり、大量に履歴書は来るけど会ってみると全くピンと来ない、ということが減ります。それ以外に会社を応援してくれる人（友人、投資家、顧問など、味方は多ければ多いほどよいです）も共感をもって周囲の人を推薦してくれるかもしれません。
2. 社内向けの意識統一効果
CTOとして開発チームを作ろうという時、すでに社内で他部門や、別プロジェクトチームの社員がいる場合があると思います。普段から社内に向けて適切に情報発信をしていればよいのですが、なかなか出来ていないケースも多いと思います。採用のタイミングで、ぜひ社内向けのメッセージも意識しながらチーム憲章を作ることをおすすめします。他の経営メンバーや他チーム社員の意識を統一することで、一緒になって開発チーム作りを進めたり、応援してもらうことが出来ます。
余談ですが、私自身気になる会社がある時、まず採用情報を見ます。どんなエンジニアを採用しているのか、どんなメッセージングをしているのか、どんな工夫で候補者を惹き付けようとしているのか、などです。海外でもGAFAに代表されるシリコンバレー企業の新規事業や新規サービスを採用職種から推測している記事をよく見かけますね。競合に知られたくないからあまり色々書きたくない、ということもあると思いますが、少なくとも候補者にはその情報がしっかり届くように真摯に対応すべきだと思います。
オンボーディング：チーム憲章に基づく採用フェーズからの一貫性
採用後のオンボーディングでは、入社する側も受け入れる側もこの入社1日目を心待ちにしているはずです。そして、エンジニアとしては１日でも早く成果を出そう、貢献しよう、という気持ちで入社してくることと思います。
この際に、採用プロセスの中で説明をした内容と入社した実際の会社の状況にどれだけ乖離が少ないか、が成果を早く上げるために重要なことです。ここでもチーム憲章が役に立ちます。事業の状況は日々変わりますし、常に意思決定を迫られて突っ走っている時は数週間経って聞くと全く違う内容になっていることもあると思います。しかし、その本質としてのチーム憲章にブレがなければ、それを土台にしてコミュニケーションすることで理解を進めてもらうことができるはずです。つまり、オンボーディングフェーズでもチーム憲章に基づいて、採用時に説明した内容から進展・変化した部分をしっかりインプットすることで、すぐに走り出すことができます。
このようなことを考えると、採用プロセスにおいて嘘偽りや誇張なく、正確な内容を正直に伝えることが最も重要だと私は考えます。その真摯さこそが、またさらに人を惹き付ける要素となります。逆に見栄や虚勢を張って採用をしても、そのメッキはすぐに剥がれてしまい、その際の失望は取り返しがつかない事が多いです。
チームビルディング：チーム全員で「チーム憲章」をアップデートすることでの自分ゴト化
チームビルディングでもチーム憲章の重要性は変わりません。それどころか、常にチーム憲章を会社や事業の状況に基づいてアップデートし、社員に共有して意識の統一をはかり、一人ひとりのタスクやゴールを設定したり微調整したりすることが、先々の採用やオンボーディングにも役立ちます。
例えば人数が増えてきて、チームメンバー間の絆を深めようと何らかのイベントを企画するとします。飲み会でもかまいませんし、開発合宿や何かディスカッションをする議題を設定したオフサイトミーティングでも良いでしょう。そんな時にも、チーム憲章をあらためて見直して、CTO自身が書き表すだけでなくチームメンバー全員でディスカッションして定義しなおしてもよいかもしれません。そのように主体的に作業を行ってこそ参加意識が強まり、会社そのものを自分ゴト化として捉えることができ、はじめてアントレプレナーシップ、経営者意識が社員にも芽生えてきます。
CTOには、エンジニアが最大の成果を発揮するための環境づくりが求められる
新しい技術や難易度の高い技術的チャレンジに興味を持って取り組むことはエンジニアが成長するために必要な事ですが、それ以上に大事なことは何のためにものづくりをしているのか、どのように役に立っているのか、などを自分で理解をしてそれに向かって技術力を発揮することだと思います。そのようなエンジニアをチームに迎え入れて最大限の成果を挙げてもらうには、チーム憲章を定義して自らそれを意識しながら開発してもらう事が重要です。
エンジニアを採用し、成果を出してもらえるよう環境を整えていく事。これはCTOが「マネジメント」として求められる事だと思います。細かな手法を考える前に、まずこのチーム憲章をしっかりと考えてみてください。最初の１人を採用する時からこれを行うことによって、人が増えていっても芯の強い、軸のブレない、素晴らしい開発チームを作っていけると思います。
最後に
前回と今回のコラムで「開発チームを作る上での5W1Hに基づいたコツ」についてご紹介しました。もっと具体的な方法論の方が参考になるのかな、と思いましたが結局のところはケースバイケースで良いやり方は変わります。各フェーズにおける様々な具体事例は、CTOの経験談をまとめた「OCTOPASS内のCTOインタビュー」で読むことが出来ますので、そちらも参考にしてみてください。
どんな場合でも５WやHowの土台となるチーム憲章によって常に本質に立ち戻って何をすべきかを自分で整理すること、そして他の経営メンバーと同じ視点に立ちながらCTOとしての役割を遂行していくことがこれによってできるようになると思います。
