エンジニア組織の拡大に必要不可欠な「テックコンパス」の制定
こんにちは、株式会社ユニラボのシステム部で部長を務める田中です。ありがたいことに、2021年でユニラボのエンジニアメンバーは20人を超え、大幅な人数増加を経験しました。
できることが増えてきた一方で、一人一人の個性や考えを微細に捉えることが難しくなってきたことも痛感しています。ユニラボでは、昨年の夏から秋にかけて、改めて「あるべきエンジニア組織の姿」を定義しロードマップを引くことに尽力してきました。
▼その時の取り組みについて、佐藤さん（エンジニアマネージャー）が語ってくれています
今後のユニラボのエンジニアチームの発展を思うと、今このタイミングで自分たちが持っている「理想のチームの状態」を言語化する必要があると考えました。そこで生まれたのが、ユニラボの「テックコンパス」です。
今回は、自分自身の振り返りなども踏まえつつ、「急拡大するエンジニア組織（もしくはここからエンジニア組織を大きくしていきたい会社）に必要な、”暗黙知の言語化”」とそのやり方についてまとめていこうと思います。
そもそも「テックコンパス」とは
テックコンパス、という言葉自体がユニラボの中で生まれたものなので、これを読んでくださっているユニラボのメンバー以外にとっては新しい言葉だと思います。テックコンパスとは一言で言うと、会社のバリューをエンジニア風に翻訳したもの。会社の文化を技術サイドに特化した形で新説として定義したもの。といえばわかりやすいでしょうか。
そもそもユニラボには、社員全員の行動指針である「コンパス」というものがあります。所謂「バリュー」ですね。もともとユニラボには、以下の3つのコンパス（以下”バリューコンパス”）がありました。
顧客にまっすぐ
チームにまっすぐ
なすべきことにまっすぐ
この3つの「まっすぐ」は、社員にとって日頃の仕事の行動指針であり、定期的な振り返り（評価・人事評価）の基準にもなっています。もちろんこのバリューコンパスは社員全員が意識しつつ仕事を行っていたという自覚はあるのですが、エンジニア目線からすると「より技術の視点を取り入れたバリューが必要なのではないか」と思う場面に直面することが増えてきました。
当然ですが、ビジネスサイドのメンバーの評価と、エンジニアサイドのメンバーの評価はそれぞれ方法が異なります。バリューをベースに評価を行うのであれば、「エンジニア独自に解釈を加えた」バリューがあってもいいのではないか？ ……という考えを反映させたのが、ユニラボのテックコンパスです。
また、事業会社としてプロダクトを作っているにもかかわらず、「エンジニアチームがビジネスサイドから受託されて開発をするような動きになってしまう」という大きな課題の解消も今回のテックコンパス制作の目的の一つとなりました。
事業成長とチームの成長に向けて、会社の中でエンジニアはどういう役割でどういう位置付けなのか、エンジニア自身が考え明文化して行くタイミングとして、チームが拡大している今、取り組みを開始しました。
実際の「テックコンパス」のアウトプット
具体的なイメージがわきにくいと思うので、実際に私たちが辿り着いたアウトプットをご紹介します。
以上の3つが明文化されたユニラボのテックコンパスです。最終的なアウトプットをみると、会社のもともとのバリューコンパスに照らし合わせた形になっています。ただ、最初からバリューコンパスを参考に作ったわけではありません。エンジニアチームの中で大切にすべき価値観、目指すべき姿を話し合い探していったら、最終的に会社のバリューコンパスと照らし合わせる形に落ち着きました。（※弊社の場合はそうなりましたが、これからテックコンパスを作る他の会社さんの場合だと、もともとのバリューとは違ったものができるかもしれません。それは全く悪いことではないと思っています）
まず一つ目の「自律的に動ける組織・会社への当事者意識」という言葉は、エンジニアチームが持っている課題から生まれたものでした。
先ほども少し触れましたが、ユニラボのエンジニアチームの中では、「ビジネスサイドから依頼されて作る」という社内受託っぽさが課題として挙げられることがありました。会社のメンバーの指向性的に、どちらかというと「プロとしてきっちり依頼されたものを作り切る」というより、「自分からもどんどん提案してプロダクトに踏み込んでいきたい」という人が多かったため、それは組織として解消して行くべきだと考えていました。エンジニアは技術に強いビジネスマンである、という思想から生まれた言葉です。ビジネスチームの指示を待つのではなく、自分たちから主体的に、当事者意識を持って取り組んでいこうという思いを言葉にしています。
二つ目は、「チーム主義」。副文として、「適切なフィードバックをするとともに相手からのフィードバックにも耳を傾ける」という言葉を入れました。チームや仕事を良くしていきたいのであれば、必要な時に自ら発言していうべきことをいうのはとても重要です。一方、アンチパターンとして「いうことはいうけど言うだけ」「肝心な部分では他の人に遠慮して言わない」という推奨されない行動も見据えて文章を作っています。
三つ目の「プロダクト視点」は、やはりエンジニアのテックコンパスには技術の視点や要素を入れたいよね、と言う話から生まれた内容です。ユニラボの理想とするエンジニア像は、「技術を手段にできる人」です。もちろん、誰よりも技術に詳しかったり最新の情報を知っていることもエンジニアとしては重要なのですが、ユニラボ内では技術はビジネスに活かすことが前提、という考え方を言葉にすることにしました。
以上から見えてくる通り、テックコンパスは「現状の課題の解決」と、「理想の状態の言語化」を目的としたものです。もともとチームの中で良いとされていたけれどなかなかできていなかった行動などの「暗黙知」をチーム全体で議論し出し合いこの形に至りました。
テックコンパスが必要なのはどのような組織か？
結論から言うと、「人数が増えて、文化が次のステージにいく組織」にとって必要だと考えています。
私にとって、今回エンジニアチームのバリューであるテックコンパスを作るというのは初めての取り組みでした。過去に所属していた組織にも、エンジニアだけのバリューというものが存在していた記憶はありません。
ビジネスが強い会社で作られたバリューと言うのは、基本的にビジネスの文化を元に作られています。今までの経験から「エンジニアにとっての“バリュー”と、ビジネスの“バリュー”のズレ」は多くの企業に存在している問題だと感じています。ユニラボでも似たような問題がありました。
なぜそのようなズレが生じたのかというと、一番大きいのは、人数の増加だと思います。
まだまだエンジニアチームの人数が少なかった頃は、CTOがチーム全体を見ることができていました。もともとユニラボのサービスであるアイミツは、CTOである菅原さんが作ったオリジナルのフレームワークで構築を行なっていたのもあり、原則として菅原さんが管理することによって全体の統制が取れていました。
とはいえ、エンジニアチームを拡大する過程で、モダンで標準的なフレームワークに変更していくことも必要になってきました（時代に合わせた変化、優秀なエンジニアに来てもらうため……などさまざまな理由はありますが、一旦割愛します）。過去にプロダクトを作ってきた技術を否定することではありませんが、無理にフェーズを進めることによって社内のスタンダードが複数出来てしまうことは今後の開発を考えると芳しくないというのが事実です。その時のフェーズに合った適切な動きを自分たちの中で言語化し、スタンダードを揃えていく必要を感じたからこそ、今回のテックコンパス制作に乗り出したわけです。
人が増えれば、考え方も変わります。文化は常に移り変わり、ステージが変わることもあります。もし、エンジニア組織がそういうフェーズに差し掛かっている、もしくは人数を大幅に増やす予定があるのであれば、「自分たちが本当に大切にして、スタンダードにしていきたいことは何か？」をしっかりと言語化して共有すべきだと考えます。
テックコンパス制定の手順
最初に行うべきは課題の特定です。今のエンジニアチームが抱えている課題を明確にした上で、その課題がどのような性質のものなのか見極めるところから始めるのが良いと思います。組織やチームの課題は大きく分けて二つあります。
・制度を作って解決する課題
・意識を変えることで解決する課題
テックコンパス制定を通じた言語化が効果を発揮するのは、２つ目の「意識を変えることで解決する課題」に対してです。チームの中で、みんながそれが課題だと感じているものがあれば、そこがテックコンパスを作る最初の足掛かりになります。
課題が明らかになったら、エンジニア組織のあり方を考える立場の人（チームのマネージャー、VPoEなど）がテックコンパスの素案を作るのが良いと思います。意識を変えれば解決する話題に対して、どのような意識を持つことで解決するかを考え、最初のアイディアを作ってみましょう。
もちろん、テックコンパスはエンジニア全員の指標になっていくものなので、少人数の独断で決めるわけにはいきません。ユニラボでは、エンジニア全員を対象としたワークショップを行いました。
このワークショップでは、テックコンパス制作に賛同してくれたエンジニアが主導して、ひたすら付箋に「テックコンパスに盛り込みたい言葉や考え方、意識」を書き出していきました。
出てきた付箋を集計してグルーピングすると「たくさん出てきたキーワード」「ほぼ全員が出したワード」「少人数が出したワード」などの特徴が見えてきます。意見をまとめた後はエンジニアのマネージャー陣で集まり、どのワードや考え方を重視すべきか議論していきます。
例えば、
・このキーワードはかなり多くの人が出してくれたし、課題解決の上で重要そうだ
・ほとんど全員が共通意識として持っていることは、すでに文化として馴染んでいるから明文化する必要はなさそうだ
・意見として出てきた個数は少ないが、しっかり議論する余地がありそうだ
こんな感じで、意見を吟味していきます。
ちなみにユニラボでは、エンジニア全員の意見を聞くために多くの手順を踏みましたが、最後はほとんど、最初に作った素案に”戻ってきた”という印象でした。
最終的に明文化する際の言葉選びにも細心の注意を払います。重視したことは以下の三つ。
・わかりやすい言葉を使うこと
・アンチパターンを想定しやすくすること
・文章の癖は消しつつ、抽象的にならないようにすること（具体の行動がイメージできるレベルに落とし込むこと）
例えば、テックコンパスの素案では「フィードバックを受け入れる」と書いてあったところを、最終稿では「フィードバックに耳を傾ける」に変更しました。受け入れる、と、耳を傾ける、ではかなりニュアンスが違います。誤解を招かず、すっと伝わり、分量としても多すぎない塩梅を目指してワーディングしていきます。
テックコンパス運用の想定
実際にアウトプットが完成しても形骸化しては意味がないので、テックコンパスの運用方法についても同時に考えていく必要がありました。テックコンパスは、以下の三つの場面において指標となると考えています。
・人事評価
・行動の決定時
・行動の振り返り
まず一つ目は、エンジニアの人事評価に効果を発揮します。
ユニラボにはもともと「まっすぐ賞」というMVP制度があり、クオーターを通じて最も行動がバリューコンパスに沿っていた（社内的に言えば「まっすぐだった」）人を社員の投票で決めています。今回制定したテックコンパスは、エンジニア的まっすぐ賞の指標になると思っています。
ユニラボのまっすぐ賞は、会社全体に「まっすぐ」というバリューが共通認識としてあるからこそ、社員同士が投票し称え合う表彰システムとして機能していると感じています。会社全体でバリューに対する同じイメージを持てていれば、表彰されたメンバーも自分のどんな行動が周囲から「まっすぐ」だと表彰されたのか、納得感を感じられますよね。
評価も同様で、チーム内で評価の指標の共通認識として持つことによって、お互いに評価への納得感が高まると思います。それゆえに評価の指標を共通認識として開示していることはとても重要であり、またテックコンパスを評価基準として据えるのであれば、評価する側とされる側、双方が「良い状態、あるべき姿」だと思えるようなものを作ることが大切だと考えています。
二つ目は、何かのプロジェクトを起こすときの指標として、共通認識をもった上で意思決定するツールになります。目の前にある課題に対して、「テックコンパスに従って考えたらこっちが正解だよね」という明文化された方針を全員で持つことができます。
現時点でユニラボでも、マネージャーやリーダー等がテックコンパスを引用し、「この考え方に照らして考えたらこうだよね」という話をしているのを耳にします。ここからもっと浸透させていきたいです。
三つ目は、自分自身やチームメンバーの行動の振り返りとして機能させていきます。二つ目の運用方法では「良い方法を共通認識を持って決定するため」でしたが、テックコンパスがあることによって「よくなかった時の振り返り」がしやすくなります。
マネージャーを経験した方は感じられたことがあるかもしれませんが、メンバーに対して悪かった点や及ばなかった点のフィードバックをするのってすごく難しいですよね。怒るのも違う、凹ませたいわけではない、とはいえ、軽く認識して欲しいわけでもない。そんな時に、全員の共通認識であるテックコンパスが役に立ちます。こういう考え・背景を持って作ったテックコンパスであり、このレベルに達して欲しいということを「個人の裁量」ではなく「組織の基準」として伝えることができます。
長期的な運用を見据えて作ってきたテックコンパスですが、実際ユニラボでもまだまだ百点満点の運用ができているわけではないので、ここからもしっかり定着させていきたいと思っています。
一度作って終わりではなく、組織の過渡期ごとに見直しを
会社のバリューがフェーズごとに見直されるように、当然テックコンパスも定期的な見直しが必要です。やはり、「人が増えた」などの要因で大きく何かが変わる時には必ず見直しを行なっていく予定です。
変化がなくても、定期的（最低でも一年に一度くらいのペースで）に見直していきましょう。随時チームのエンジニアの声を聞いて、新たなテックコンパスに据えるべき課題や目標を見定めておくのも重要です。「テックコンパスに定めたけれど、これはもう組織の当たり前になったよね」、「これはまだ全員できていないことだよね」ということをしっかり見ることで、常にアップデートしていけるはずです。
テックコンパスを作るときに、テックコンパスを作ることが目的になってしまっては意味がありません。組織の暗黙知（＝当然このようにしたほうがいいよね、とみんなが思っていることや、やるべきだけれどできていないと感じていること）を明文化し、メンバー全員が意識できるようにすること、また、それによって人事評価や振り返りなど、組織を良くする機能の一部となれることを目標に制作すると、エンジニアチームの要になる素晴らしいテックコンパスが出来上がると思います。
【PR】ユニラボ に興味がある方へ
今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！