こんにちは、freee株式会社 の @hiraguri です。
この記事は freee Engineers Advent Calendar の24日目です。
明日25日目はいよいよfreee advent calendarの最終日として弊社CTO @yokoji が登場します。
そんな大団円を控えた今日は、これまでとは少し毛色を変えてfreeeのエンジニアチームについて話そうと思います。
マネジメントの話をガッツリしてもおもしろくないと思うので、freeeのユニークな点についていくつかご紹介します。
エンジニアチームの責任者が2人いる
freeeには現在50人のエンジニアがいて、エンジニアチームの責任者が2人います。
CTO と vp of engineeringです。
CTO を @yokoji が、vp of engineering をぼくがやっています。
CTOは「最高技術責任者」の名の通り、技術に責任を負う人。
vp of engineeringは、ざっくり「技術以外のすべて」に責任を負う人。
技術以外のすべてとは、プロダクトリリースや採用、チーム運営などのもろもろで、freeeでは「開発本部長」と呼んでいます。
なぜか
世間ではCTO一人体制が多いのに、なぜ二人体制にしたかというと、それは会社として明確に「技術」に投資したかったからです。
CTO一人の場合、CTOが一人で技術もリリースも採用もチーム運営もすべての責任を負わなければいけません。
すると、どうしても日々出てくる問題（そしてそれは技術以外の話が多い）に追われてしまい、技術への問題意識が疎かになってしまいます。
実際に世のCTOの主な悩みは採用、評価制度、チームビルディングなど、組織運営上の課題が多いように思います。
そこでCTOは明確に「技術」のみにフォーカスするロールとして、それだけ「技術」に投資することにしました。
最新の技術を広く知り、社内で使われている技術、ソースコード、アーキテクチャに精通していて、圧倒的な武力（coding力）を誇るスーパーギーク。
正しい技術的判断を高いスピード感をもってこなし、あらゆる難題をエンジニアリングでねじ伏せ、進化の激しい技術の先を読み、一人で50人分のインパクトをだす。
ソフトウェアエンジニアの栄光の存在である。
そんな人がCTOだと思っています。
一方、vp of eng はCTO含めすべてのエンジニアが最高のパフォーマンスを出せるために技術以外の全てに万事を尽くせる人。
この記事とかこの記事とかが、わかりやすくまとまってるので、興味があれば見てみてください。
gunosyさんもCTO & vp of engineeringの二頭体制でやっているようです。
メリット
実際に二人でやってみて、技術に対する投資以外にも、大きなメリットがありました。
責任者の冗長化
大抵CTOの人はかなり多忙で、なかなか捕まらない、予定も入れられない、出張で物理的にいないなど、すぐSPOF化します。
ところが二人いると、片方が出張してももう一人はいるし、大規模障害でかかりきりになっても、もう一人は冷静に事後対応を考えられるし、偶然同じ日にすごく重要な用事が重なっても対応できるし、体がもう一つあったらなぁ、というのがまさにその通り叶います。
どちらかが不在にしてもお互いに頼れるので、体調不良時にも無理しすぎなくて済むし、とてもいい感じです。
デメリット
「船頭が二人いたらどうたら」の故事の通り、二人の意識がずれていたり、信頼関係がない場合は最悪な事態になります。
うちは割りと愛し合ってるのでいまのところ大丈夫です。
この二人体制はけっこう思い入れがあって、色々考えながら書いていたらあっという間に12/24まであと2時間になったので、ここからは駆け足でお送りいたします。
巨匠システム
始めたばかりで絶賛お試し中ですが、こんな感じのシステムです。
- 1ヶ月間、お題からなにからなにまですべてを巨匠に任せる。
- 巨匠はエンジニアチーム内で「だれの1ヶ月が見たいか」を投票し、決める。
- ただ、1ヶ月後の成果のみ、全員できっちり判断する。
巨匠システムの目的は3つ
- プロダクトを非連続的に進化させる
- エンジニアチームをexciteさせる
- スペシャリストのロールモデルとなる
「ピュアにギークなエンジニアのキャリアパスってなんだろう」というのが出発点でした。
エンジニアは職人気質ではあるものの、チームで開発する以上は、必ずコミュニケーション能力やマネジメント能力は求められる。
しかし、その前提を一旦取っ払ってみて、本当にピュアなエンジニアリング力（coding力、なのかな）が突き抜けている人が認められてもいいじゃない。
そういう人ってどういう人なんだろう。どう評価すればいいんだろう。
そうして生まれたのが 巨匠システム でした。
コミュ力なんか知らん、マネジメントなんか知らん。
ただただ腕力に物を言わせ、だれにも邪魔されず、自分にしかできないイノベーションを起こす。
そしてその結果、人の何倍もの価値をユーザーに届ける。
それが職人のゴール、巨匠。
年明けには第一弾の面白いものができてくるはずで、今からワクワクしています。
フィーバー
ベンチャーのプロダクト開発の初期などは、とにかく生き残るための機能開発が最優先です。
そのため、技術的負債よりも機能開発スピードを優先して、とにかく「最速でユーザーに価値を届けること」に重きをおいていました。
しかし、開発を初めて2年も経つと、だんだん技術的負債が溜まってきて、じわじわと開発スピードにも影響を与えてきます。
エンジニアとして、技術的負債を育てていくしかない精神的な不健全さ。
「負債を撲滅したい！」「自らの手で健康を取り戻したい！」
と生まれたのがフィーバーでした。
フィーバーは単純に言うと、5％ルールです。
3ヶ月間のうちの1週間、価値あることなら好きなことをしていい。
エンジニアの高いモチベーションがあれば、5％の範囲で10％にも20％にもなる成果を出せるだろうし、それはエンジニアチーム全体にとってもいいことだと思っています。
実際に、フィーバーを使って、たくさんの技術的負債にメスが入れられました。
僕の使命はこれを105％ルールにしないことです。
変な用語集
freeeでは、既存概念にとらわれないために、用語にこだわっています。
アジャスター
今年（2015年）の初めころ、ちょうどエンジニアが30名を超えてきて、そろそろマネージャーを置こうかとなりました。
しかし、「マネージャー」という単語はエンジニアにとってさまざまな色がつきすぎているし、求められているのはチーム間の調整が主だったので、「アジャスター」という名前をつけてみました。
見事「おまえマネージャーだろ死ね」的な悪即斬は免れたのですが、一方で「アジャスタァー？！、？？？」という混乱を招き、トータルではトントンだったかなと思ってます。
3ヶ月経つころには「ｱｼﾞｬｽﾃｨﾝｸﾞ、ｵﾅｼｬｽ」「ｳｨｽｳｨｽ」など日常会話に取り入れられるまでに育ったんですが、半年後には知らぬ間に闇に葬られてしまい、今ではぼくの名刺上にしかその痕跡が確認できなくなっています。
ハッピー
freeeではバグのことをハッピーと呼んでいます。
3年前のリリース当初、あまりにもバグが多すぎてチーム全体が憂鬱になっていたときに、「バグじゃなくてハッピーて呼べばいいんじゃね？」と安易に導入されました。
ちょっとヤバメな感じも受けますが、不思議なものでいまでは「いまハッピー何件です」「すぐやるハッピーでました」「ハッピーであふれてます」という会話が誰もニコリともしない状況下で何の違和感もなく行われています。
結果として、バグに幸福感を感じるのではなく、「ハッピー」という単語につらみを感じる逆転現象が起こりました。
革命
よこじ（概念）
弊社CTOの @yokoji は、本名も横路（よこじ）と言います。
「そのままCTOと呼んでも面白くないっしょ」ということで、社内ではCTOのロールのことを「よこじ（概念）」と呼ぶことにしました。
実体と区別するために、「概念のほう」「初代よこじ」「初代」などと呼ばれています。
最後に
以上、いかがだったでしょうか。
自分たちなりに工夫しているポイントをいくつか上げてみましたが、freeeのエンジニアチームに少しでも興味を持ってくれたら幸いです。
もとむ、二代目よこじ
弊社では二代目三代目よこじを担うスーパーエンジニアを募集しています。
日本中の法人を悩ましている「バックオフィス業務の煩雑さ」という難題を一緒にぶち破っていきましょう。
（開発本部長も募集しています! 一緒にチームについて考えましょう!）
次回はいよいよ最終回、初代よこじ @yokoji の登場です。