エンジニア行動指針を作った話
この記事は、Feedforce Advent Calendar 2019 10日目の記事になる。
遂に5回目。 去年までのカレンダーも是非。 – [2018年](https://adventar.org/calendars/3235)
– [2017年](https://adventar.org/calendars/2155…
9日目は採用マーケティング兼エンジニア中途採用担当の @love による「会いたくなる」レジュメの書き方＜社会人編＞」だった。
自分も最近はエンジニア採用の書類選考やカジュアル面談、そして面接もやっているのでこれは非常に納得のいくものだった。CV の行間から何が読めるか、自分の場合だと例えば趣味で書いたコードやサービスなどが何か、そこからどういう知見を得ていそうかは見るようにしている。
Table of Contents
2019年も去りゆく中
さて、2019 年は公私ともに激動だった。年始に実父が他界した一方、12 年にわたって勤務してきた株式会社フィードフォースが東証マザーズに上場し、自分も東証でのセレモニーの末席を汚してきた。それに関連して、IT 基盤の責任者として IT 視点で見た上場に関する話をする機会も増えてきた。
12年前、バックエンドエンジニアとしてジョインした (当時は「バックエンドエンジニア」という呼称はなく、「Web エンジニア」などと呼ばれていた覚えがある) 自分で、ここ最近まではチームビルディングやマネジメントなどではなく Facebook などのプラットフォーム側のアップデートを中心に追いかけてきた。
ところで、調査によると、人間は30代半ばには音楽の好みが成熟してしまい、最新ヒット曲に興味を失ってしまうらしい。
自分の場合、大まかなジャンルは10代からブレないものの、新しいものもそれなりに聴いてはいるつもりではある。
一方で仕事に目を向けた場合、弊社 CTO 退職以降、執行役員・開発本部長という組織図上の肩書きはあるものの、ここ数年に至るまで敢えてチームマネジメントに目を向けずに来たのも事実だった。
組織が大きくなるに従い、規模に応じた問題が出てくる。例えば採用時のミスマッチから発生する様々な問題が典型例だろうし、様々なものに対する温度感の差もそうだろう。
現職の場合はこれらに加えて上場企業としての組織や制度作り、そしてそれらの維持も必要で、2018年後半からほぼハンズオフでそちら側に注力することにした。
行動指針を作った背景
なぜ行動指針が必要か
なぜ行動指針が必要か、端的に言えば、スタートアップ期の自律的な雰囲気を残したかったからかもしれない。社内で「凄いエンジニア」判定される人間は入社期にかかわらずスタートアップ期にいた共通の臭いがする人間なのは間違いない。
一方で、「その共通の人間とはどういう人間か」の言語化ができていないが故に、既存の社員や採用時の候補者にそれをうまくそれを伝えられず、お互いに不満を抱える局面が出てきた。
また、半期ごとの納会・忘年会で活躍したメンバーが表彰されてはいるが、
- どうしても直近に目立った成果を出したら表彰されるパターンが多い。
- インシデントを起こさないことも継続した努力が必要で、エンジニアとしてのタスクとしては重要だが、それには脚光が当たらない。
- マネジメント層はビジネス側に寄りがちなので、エンジニアがノミネートされる確率が有意に低い。
と感じることもある。特に2つめに脚光が当たらないのはエンジニア組織としては危機感を感じていた。
こういうモヤモヤを抱えているときに、東洋経済オンラインで「日本と真逆､英名門校の知られざる教育の中身 | 学校・受験 | 東洋経済オンライン | 経済ニュースの新基準」という記事を目にした。
これによると、
この行事では多種多様な賞が大勢の生徒に授与される。
賞の種類は低学年がそれぞれ約40種、高学年が50種以上で、すべての賞の種類は250種を超える。生徒を評価するものさしが多いことに、驚きを禁じえない。
受賞者が複数人いる賞も多数ある。7～8種もの賞を1人で授かる生徒が全校で5～6人見られる。受賞者はたいてい図書券などのギフトをもらえる。
らしい。これにインスパイアされて、フィードフォースらしいエンジニアの言語化 (= 行動指針) と、それに最もマッチしたエンジニアをお互いに認め、称え合う何かをやろうと決めた。
行動指針から得られるもの
また、行動指針を作ることによるメリットは以下だと考えている。
- フィードフォース技術チームのカルチャーの言語化。
- フィードフォースで求められるエンジニアの行動様式の言語化。技術スタックではなく、どういう振る舞いが賞賛されるか。
- 言語化されたカルチャー、望ましい振る舞いの各軸において最大限に発揮しているのは誰かの相互認知。
- 古くからいるメンバーが感じているカルチャーギャップのキャッチアップ。
- 採用時にのカルチャーミスマッチの防止。
- 積極的に発信していくことで、共感してくれたエンジニアがジョインしてくれるといいな……
ボトムアップで作るとなると相当なコスト感になるが、色々と考えた結果、そのコストに見合うと踏んで策定に移った。
Feedforce Engineer’s Principles; 6つの行動指針
今回の行動指針は会社からの押しつけではなく、エンジニア総意のものとして作りたかった。そのため、@pokotyamu にファシリテーションを依頼し、3 ヶ月近くかけて合意を取りつつ決定にこぎ着けた。
ファシリテーションのプロセスそのもの、気をつけたことなどの詳細は@pokotyamu が Feedforce Advent Calendar 13 日目でまとめているので、そちらも参照されたい。
こうして決定した行動指針は以下 6 つになる。
- Broaden Yourself; 己の限界を広げるべし。
プロフェッショナルとしての知識・技術の習得に限界や終わりはない。常に最新のトレンドから枯れた知見まで幅広く意識を向け、実際に手を動かしながら己のものとすべし。 - Prepare Yourself; 次の機会に万全であるべし。
機会を掴み取れるのは、それに備えている者のみである。来たるべき機会に何が必要か、何が期待されているかを考え、常に万全であるべし。 - Be Positive & Proactive; 常に肯定的・主体的であるべし。
受け身であること、否定的に捉えることは誰でもできる。顧客への価値を最大化するため、次に何をできるか、よりよくするためにさらに何ができるかを常に考え、自ら行動すべし。 - Know Yourself; 己に求められているもの、 そこまでの道筋を知るべし。
己が何を求められているか、求められているものまでの道筋はどうか、そして己は今どこにいるかを常に知り、求められているものを完遂すべし。 - Stay Humble; 常に謙虚であるべし。
他者は異なった立場や文脈、背景を持っており、自分と全く同じではない。相手の立場、文脈を尊重し、かつ自分の伝えようとしていることを相手がどう理解しているか踏まえつつ行動すべし。 - Share Everything; 己の知見は遍 (すべから) く共有すべし。
己の学んだ知見の価値を決めるのは己ではなく、その知見に接する者全てである。共有する前に己でその価値を過小評価せず、遍く共有すべし。
結果的にはあるが、昔からありそうなものになったように感じる。だがしかし、これを上から下に押しつける形ではなく、ボトムアップで作ったところに意味があると思う。
また、「Engineering Principles」ではないかと思うかも知れないが、今回は敢えて人にフォーカスを当てて「Engineer’s Principles」にした。
「Engineering」だと例えば「テストは必ず書く」といった、コードを書く上でのルールに感じてしまうのがその理由となる。
「〜らしさ」の言語化の必要性
今回の話はフィードフォースに限った話ではなく、成長しているベンチャーならあるあるだと思う。フィードフォースの場合は創業から上場まで13年書けた緩やかな成長だったが、それでも古くからいるメンバーと成長期に入ってからジョインしたメンバーとでは温度感の差があった。
これが創業から数年で上場するようなスピード感のある会社であれば、なおさらカルチャーの分断が起きているのだろう。
最後に、フィードフォースの成長過程では何があったか、何を感じたかを自分目線で書いたポエムを置いておきたい。
スタートアップ期
自分が入社した当時のフィードフォースは全社員でも15人前後の組織だった。
15名程度の組織にわざわざ入社するような人間は良くも悪くも癖がある。当然ながら自律的なプロフェッショナルがほとんどだし、聞いたこともないような技術ネタを深掘りしていたりして、入社当時はキャッチアップできるかどうかの危機感があった。
成長期〜上場前期
それが50人を超えて新卒採用のサイクルが回ってきたり人的リソースのニーズが激増した結果として新しいメンバーが増えてくると、それまでいたメンバーが醸成してきたカルチャーが徐々に変わってくる。もちろん、変化そのものは不可避であるし、カルチャー自体規模感に合わせて変わっていくべきなのは言うまでもない。
この時点で、残すべきカルチャーと変えるべきカルチャーを見極め、残すべきカルチャーを残す努力をするべきだったと思う。少なくとも自分にはそれができただろう。
それをしなかった結果、
- 「古い」が良いカルチャーに期待して入社したメンバーの期待に応えられなかった。
- 残すべきカルチャーに合わないパターンが徐々に発生し、その結果としてチーム全体に問題が広がった。
- スタートアップ期からいるメンバーの期待とそれ以降に入社したメンバーとのミスマッチが広がった。
といった問題も発生した。
マネジメントを始める〜行動指針
たまたまこのタイミングで自分がコーチングを受け始めたこと、上場を控え組織体制も考えないといけない状況になったこともあり、例えば 1on1 などを始めたりエンジニアの採用プロセスに手を入れたりしたものの、これらはすべて対症療法でしかない。
根本解決には
まさに Simon Sinek が言う Why や How の言語化、共通認識化が必要だろう。
もちろんバリューが How に当たるのではあるが、バリューは全社的なものであり、エンジニアの文化は職能に対して期待されていることに沿ってもう少しブレイクダウンされていた方が分かりやすいし、何より認め合う軸は多い方が分かりやすい。
そういう意味では、ここまでは成功していると思う。本当に成功したかは、3年後にこれがまだ機能していることだと思っているが、それはまた別の話だろう。
Feedforce Advent Calendar 2019 11日目は、EC Booster 井形さんによる「新サービスの提供開始21ヶ月で24の導入事例を公開した理由とは」。
カートベンダと連携した SMB 向けの Google ショッピング広告プラットフォームというこれまでになかったプロダクトについて、自社のマーケティング目線だけではなく、顧客、特に担当者に寄り添うという視点は結構見落とされがちだが重要だと思う。
