自分の枠を超えサービスの非連続的進化を生み出すfreeeの「巨匠制度」の歴史（連載第1回）

DevBrandingのellyです。freeeのエンジニアには”巨匠”という「1ヶ月間通常業務から離れ非連続的な成長をもたらす成果を考え実行する」制度がありました。現在、その巨匠制度はマジ価値DeepDiver・ワンマンNavyという2つの制度に生まれ変わっています。今回は、これらの制度が生まれた背景とその歴史についてご紹介します。

なお、3部構成の連載形式で掲載していきますので、今後公開される記事についてもぜひご覧ください。

※ 日程、タイトルは一部変更になる可能性があります

日程	タイトル	執筆者
10/13	自分の枠を超えサービスの非連続的進化を生み出すfreeeの「巨匠制度」の歴史	elly
10/18	初代・二代目巨匠が考えるエンジニアキャリア	terashi/ebi/ichien
10/25	マジ価値DeepDiverを終えて	liao

巨匠とは

巨匠制度は、2015年12月からはじまりました。制度は、「ズバ抜けた技術力をもつ人が、本気で取り組んだらどんなマジ価値が生まれるか」という議論から生まれました。最初の巨匠制度では、以下をミッションとして与えられました。

投票で選ばれた「巨匠」は1ヶ月、通常業務から離れ自由を与えられる巨匠は、サービスや会社に「非連続的な成長」をもたらす成果を考え、実行する

そうしてエンジニアからの投票で初代巨匠に選ばれたのがterashiさんでした。

f:id:elly_nskw:20211011121543p:plain — 巨匠制度が始まった当初、取材を受けるCTO横路さんとterashiさん

初代巨匠 terashi 「もっと自動で経理」

「自動で経理」の推測精度測定の自動化・プロセス化性能の定量評価を導入

二代目 ebi 「未来のfreeeのデータモデル」

取引ネットワーク & ビジネスコラボレーションプラットフォームのためのデータモデルを一からあるべき姿に再設計

f:id:elly_nskw:20211011121048j:plain — 発表中のebiさん

課題の継続検討体制、成長支援要素を追加し再スタート

当初の巨匠制度は投資的リソースの一点集中投下という側面がありましたが、次第にチームで投資的プロジェクトに取り組めるようになってきたのもあり、四代目の巨匠以降はしばらくの間巨匠は選出されていませんでした。

せっかくのユニークな制度として始まった巨匠を何か活用できないかと模索していたところ、freeeでのエンジニアのキャリアパスについての議論の中で、マネジメントを担うJM(ジャーマネ: freee におけるマネージャー）方面のキャリアステップはAJM（アソシエイトジャーマネ）という形で用意できているものの、スペシャリスト方面のステップが明確になっておらず何か作れないかということで、その中で巨匠制度が活用できるのではないかと話題に上がりました。

このために成長支援を軸足に据えて、制度の見直しを行いました。また、これまでの巨匠制度では、課題設定が投資的側面の強いもので後に引き継がれず宙ぶらりんになってしまったり、選ばれたチームとそのJMに負荷が偏ったりするという課題感もありました。

そこで、取り組む課題をメンバーから公募しきちんと親和性の高いチームに引き継ぐ、巨匠に選ばれた人への成長支援の要素を強めることで、チームサポートするチームやJMにとっても結果としてメリットが生まれるように改善しました。

この刷新された制度の元で巨匠の応募を行ったところ、当初は巨匠というものに壁を感じている人が多くなかなか応募が集まらなかったですが、他のエンジニアに推薦をしてもらった候補者に直接コミュニケーションをとる形で壁を低くする運動を行いました。その結果として多くの応募が集まり、無事五代目巨匠をスタートすることができました。

六代目 terasawa「サービス間通信にメッセージングを導入する」

信頼性の低い分散トランザクション、結果整合性、レスポンスタイムの劣化をメッセージングで解消

f:id:elly_nskw:20211011121052j:plain — 発表中のterasawaさん

若手、シニア両方が挑戦できる制度へ

巨匠の運営を行っていく中でだんだんと応募が少なくなっていく傾向がありました。そこで運営で応募が少なくなった背景の分析と、巨匠制度で達成したいことを改めて再定義を行いました。まず応募が少なくなった背景ですが、エンジニア全体にアンケートを取ったところ、やはり巨匠という制度に壁を感じている人が全体の1/3を締めていることがわかりました。

壁を感じているポイントとして、非連続的進化だったり、過去の巨匠が残した成果をみて全員が同じ成果を残すことを期待されていると間違った解釈で伝わってしまっている点などがあります。

制度としてはシニアエンジニアが取り組むのであれば一定の成果を出してくれることは期待に含まれますが、若手エンジニアが取り組む場合は、挑戦して良い失敗をして成長してくれることはある意味成功といえます。

候補者によって期待値は変わるが、制度としては１つにまとまっていることで候補者が不要なハードルを感じてしまっているのではないかという仮説のもと、制度自体を若手・中堅とシニアという形で2つに分けることで期待値を明確にし最初の一歩を踏み出しやすくしようと考えました。またそれぞれの制度について何が得られるかも明確にし、制度設計を行いました。2つの制度の概要はこちらです。

マジ価値DeepDiver（若手・中堅向け）

2週間～1ヶ月、圧倒的主体性をもって組織の課題を発見〜解決まで経験してもらい、自分の成長のブレークスルーポイントを創出してもらうことを狙いとしています。チャレンジした結果としての失敗は問題ないので、保守的にならず「理想ドリブン」「失敗して攻めろ」の気持ちでチャレンジするのを推奨しています。

対象者

freeeをもっと良くするためのアイディア・取り組みたい課題を持っていて、それをやりきりたいと考えている若手〜中堅

プロジェクトの内容

自分が集中してやりたい、やるべきだと思うこと

e.g.「僕の考えた最強の〇〇」共通基盤、フロントエンド、負債返却、速度改善なんでもあり

サポートチームについて

プロジェクト決定後、プロジェクトに関係ありそうなチームリードに声をかけ選出、このチームをサポートチームとする
サポートチームはアイデアの壁打ち、コードレビュー、期間終了後の引き継ぎに適切なリソースを割く (想定5人日程度)

期間中の進め方（2週間~1ヶ月）

期間前

DesignDocをまとめ、サポートチームとの壁打ちは先にやっておくことを推奨

期間中

あらゆる割り込みを無くし、プロジェクトに専念する（チャットツール等の通知はOFF、ミーティングは参加しなくてOK）
元チームとJMを中心に開発チーム全体としてフォローする
開発したコードのPRレビューは基本的にサポートチームが担当する

期間後

サポートチームへの引き継ぎ
元チームに復帰しつつ20%くらいのリソースを2-4週間割いて、ドキュメント整備や手順のスクリプト化などを行う

ワンマンNavyの制度（シニア向け）

1ヶ月+αで、freeeに非連続的進化をもたらすことを目標に据えて、今できる最大のアウトプットをひたすら考え抜いた上で実行してもらい、自分の枠を広げて成長のブレークスルーポイントを創出してもらうことを狙いとしています。プロジェクト内容は応募の段階では決めず、構想期間に自分が最大のインパクトを出すにはどうしたらいいかをひたすら考える時間を取ってもらいます。