シェア
はてブ
2024年6月28日（金）より2日間、ファインディ株式会社が主催する「開発生産性Conference2024」が虎ノ門ヒルズフォーラムにて開催されました。
初日の28日（金）の夕方よりスタートしたセッション「開発トップのマネジメント：採用からオンボーディングで始まる一貫した生産性向上戦略」では、保険会社向けサービスを展開する株式会社hokanより、取締役副社長CTOの横塚出さんと、エンジニアリングマネージャーの前島治樹さんのお2人が登壇。エンジニア組織が大きくになるにつれ課題となるコミュニケーションや開発生産性について、自社で取り組んできた施策をご紹介いただきました。
■プロフィール
横塚 出（よこつか いずる）
株式会社hokan 取締役副社長CTO
東京工業大学社会工学科卒。
大学在学中にシステム開発会社、教育系会社を創業。ダイアログにて、アパレル、介護、、物流業界等でITコンサルとシステム開発を担当。リクルートにて飲食店向けSaaSサービスの新規プロジェクト立ち上げに参画。2018年2月にhokan参画し、プロダクト開発・開発組織のマネジメントを行い、2019年6月に取締役CTOに就任。2024年4月24日付けで現職。
前島 治樹（まえじま はるき）
株式会社hokan エンジニアリングマネージャー
愛知県名古屋市出身。1989年生まれ。これまでに、ビジネスエンジニアリング株式会社、タイムチケット、MUGENUP（システム部長）、D2Cスタートアップを経て、2021年9月にエンジニアリングマネージャーとしてhokan入社。エンジニア採用も担当する。2022年12月に全社の人事責任者。2024年6月に再びエンジニアリングマネージャー。趣味はボクシング。SNS：@tonarinoharuki
保険業界に向けたInsurTech事業を担うhokan
横塚：我々hokanについて、会社と事業の説明を少しさせていただきます。「保険業界を更新(アップデート)し、革新(アップグレード)する」するというミッションで、銀行や証券を含むFinTechの中でも、保険業界に注目した保険とテクノロジーの融合を目指したInsurTech事業を進めています。
国内では50兆円ほどの大規模なマーケットであり、私が見る限りは銀行、証券、保険の中で最もレガシーな領域だと考えています。昨年には、企業ぐるみの不正受給といった大きなニュースもありました。その中で、まずは保険流通の領域にフォーカスし、テクノロジーを通して正しく保険を人々に届けたい、といった思いで事業を進めています。
会社は7期目で、従業員数は70名ほど。事業のスタート当初は保険というバーティカルな領域に苦戦もしましたが、継続的に深くダイブしていったことで、今では保険の契約管理やCRMの根幹部分などから、複数のプロダクトを提供しております。
我々は、比較的少数のエンジニアで、CRMやダッシュボード、出納など周辺領域のプロダクトを複数展開し、徐々に積みあげております。前島と私の2名で、その部分の経験をご紹介していきます。
自己紹介させていただきますと、私自身はこれまでに中小企業やリクルートで新規サービスの立ち上げをしてきました。2018年2月にhokanへ参画し、当初は自分でもソースコードを書きながら、開発組織をマネジメントしていました。
前島：株式会社hokanでエンジニアマネージャーをしている前島治樹と申します。新卒ではITコンサルの企業へ参画し、製造業に向けたERP導入の領域で要件定義から運用保守フェーズまで、Javaによるスクラッチ開発で実装しました。その後スキルシェアのプラットフォームであるタイムチケットというサービスの創業期に携わり、MUGENUPでエンジニアのマネジメント、D2Cのスタートアップを経て、2021年にhokanに参画しました。当初はエンジニアの採用とマネジメントに従事し、2022年からは全社の人事責任者を経験しましたが、2024年の5月にふたたびエンジニアリングマネージャーに戻りました。
どのようにエンジニアの生産性を高めるか？
前島：ここから本題に入ってきますが、ここにいる皆さまは、『エレガントパズル』を読まれましたでしょうか。2章にて、次のような記述があります。
エンジニアが増えるほど問題も増える
生産性を高めるために、多くのエンジニアをまとめ上げるのは難しいものである。
その難しさは、自走できるエンジニアをどれだけ早く育成できるかにより決まる。
生産性の高め方を課題と感じている方は多いのではないかと思います。この部分におけるhokanの課題と取り組みを、下記の順で紹介していきます。
・開発組織が抱える問題
・採用～オンボーディングの仕組みとその効果
・スキルマトリクスの作成と活用
・生産性指標の可視化と活用
横塚が管轄しているTech Div.は、メインプロダクトであるCRMチームや、出納、新規プロダクトチーム、QA、CRE、SRE、また、私が担当しているEMで構成されています。
前島：開発組織が抱えていた問題点は、POやテックリード、メンバーの間のコミュニケーションギャップです。ドメイン理解の差により意思疎通や要件把握の理解が不足する中、スプリント内に間に合わせる必要性が各エンジニアのプレッシャーになっていました。そこから、システム設計の生産性低下につながりかねないという状況を生んでいたのです。
システム設計はコミュニケーション構造に従うと言われています。ただ、これまでに自走してきたエンジニアの方々であれば、環境適応できるだろうという認識の甘さがあったのかもしれません。そこで、マネジメントの領域の中でも、土台であるピープルマネジメントに目指すべき姿を形成し、その後で全体の生産性を高めるよう取り組むことにしました。
横塚：会社創業期には、少人数のトップエンジニアの方と一緒に作ってきたため、コミュニケーションに困った経験はあまりありませんでした。ところが、採用を加速していく中でいろいろな気づきがあったのです。
入社後になかなかうまくいかなかった場合、必ずしも採用したエンジニアの方に問題があるわけではないでしょう。エンジニアの方としっかり向き合えていたか。そのために整理した情報をお渡しできていたか。――そう考えると、十分ではなかったという反省点があります。『エレガントパズル』に書かれていた内容を頭では理解していましたが、身をもって体感しようやく重要性に気づけた、という失敗体験でもありました。
生産性向上のために、コミュニケーションの効率化から着手する
前島：この問題を放置しておくと、プロダクトの品質低下や、エンジニアのスキルやナレッジ定着の遅れ、開発組織の成長鈍化など、中長期での大きなリスクとなり得ます。まずは、やはりコミュニケーションの効率化に重きを置いて改善していく必要があると考えました。その後でようやく、社会的に価値あるサービスを安定的に提供し続けられる開発組織を目指せると考えています。
そのための取り組みが、この「生産性向上に向けたジャーニーマップ」です。
前島：非常に長い道のりではありますが、まずは「hokan入社前～入社3ヶ月」「入社3ヶ月以上」を2つのセグメントとして設けました。スタートアップという特性上、入社後3ヶ月における環境へのスムーズな適応が大きな勝負となってきます。3ヶ月以降は、スキル向上やキャリア構築を達成し、生産性の高いチームを作っていきます。
まずは「hokan入社～3ヶ月」の部分。採用は、強いエンジニアを連れてくればいい、と単純に考えられるかもしれませんが、何を持って「強い」とするのでしょうか。hokanでは、Four Keysの指標にもあるとおり、「Elite」「High」「Middle」というバリュー基準を設けました。
例えば、入社1ヶ月ですぐにパフォーマンスを発揮できる方は、Eliteにセグメントさせていただきます。2ヶ月くらいであれば、HighあるいはMiddleというイメージです。環境適応性と開発スキルを分けて考え、採用要件の解像度を上げていきました。
前島：当然、セグメントに応じたオンボーディングを設計していく必要があります。例えば、入社1ヶ月で早期にパフォーマンスを発揮できる方に懇切丁寧なオンボーディングをしても、重荷や邪魔になる可能性があります。一方、丁寧なオンボーディングを提供したほうが早くパフォーマンスを発揮できる方も当然いらっしゃいます。オンボーディングのプログラムを一律化するのではなく、個々のスキルやバックグラウンドに合わせていくようにしました。
エンジニアのバリューや投資回収期間を緻密に設定
前島：そもそも、エンジニアのバリューとは何でしょうか。この認識を、経営陣とマネージャーで合わせる必要があります。我々のようなスタートアップの場合、投資回収に2～3年かかるようでは、事業成長に追いつきません。投資回収期間を11ヶ月～1年未満としたときのオンボーディングや育成を考えていかなくてはならないのです。経験があるエンジニアなら育成が不要というわけではなく、見極めが大切になります。
横塚：これは決して悪い部分を見極めるためのカテゴリー分けではありません。例えば、1ヶ月でスムーズに適応できると期待した方が実際には2ヶ月かかるとしたら、そのギャップが一番の問題だと考えています。その場合、例えば3ヶ月しっかりオンボーディングして、その後ご活躍していただくほうが理想的で、それをご本人やメンバーとすりわせていくべきでしょう。
3ヶ月で区切りを設けたのは、やはりスタートアップとしては、エンジニアの早期の立ち上がりが必要と考えたためです。
前島：生産性向上を考えるにあたり、エンジニア生涯価値（ELTV）を定めています。1エンジニアあたりの利益×勤続年数として、ざっくりスライドのようなグラフになります。
前島：左から右へ時間経過していくうえで、入社当初はパフォーマンスがマイナスとなりますが、オンボーディングを経てパフォーマンスを発揮し、そこから生産性が上がっていくことになります。
生産性を上げようとすると、赤い枠で囲った部分に注目しがちですが、我々は入社前の時期のプレボーディングからオンボーディングの部分に注力して施策を打ってきました。早期にバリューを創出するためには、早い段階からの会社理解や業界知識が非常に重要となります。また、1on1や定期的なトレーニングを通じた継続的な教育とサポートで開発理解を深めていただき、早期に高いパフォーマンスを発揮できるようにしていきます。
スムーズに開発へ入るために、会社の戦略やミッション・バリューの理解、メンバーの人間関係の把握など、各方面への解像度高いサポートをやりきるしかないと考えています。
オンボーディングには、企業文化や人間関係などの理解が最も重要
前島：オンボーディングにおいては、会社の理解がもっと重要だと考えています。まずは企業文化への適応です。この部分がわかっていないと、疑問が生まれた時に「誰に質問すればいいんだっけ」「あの人かもしれないけど、話しかけにくい」といった現象が積み重なります。その結果、パフォーマンスが発揮しにくく、エンゲージメントが向上しにくくなります。
また、目標設定や優先順位の付け方といった会社のカルチャーがわかっていないと、優先度の低い部分に着目してしまい「頑張っているのに評価されていない」という気持ちになりがちです。
それらを解消するため、コミュニケーションパスを円滑化していきます。聞くべき相手や人間関係まで理解できれば、社内のコミュニケーションがスムーズになり、不安感や誤解、摩擦を減らして効率的な業務遂行を支援できるのです。
人材のセグメントごとにオンボーディングの主軸とゴールを変えていますが、さらに、入社中社員（試用期間後）も「自走」「要教育」のセグメントに分け、コミュニケーション設計を別に設けています。
前島：コミュニケーションを改善した後には、その影響を見ていきます。オンボーディング後のリードタイムまで見る必要があるでしょう。最初に参画したスプリントのストーリーポイント、サーベイによる満足度も確認していきます。
入社前のプレボーディングにより、自走までをスピーディに
前島：我々は、入社前のプレボーディングに着目しました。横塚と一緒に作成したプレボーディングブックを共有し、会社の基本的な情報をあらかじめインプットしていただきます。それを入社日に「どんな福利厚生に興味がありますか」といった形で確認します。全く読んでいない人、ちゃんと読んだ人、しっかりと内容を理解した人……いろいろな方がいらっしゃいますが、それに応じてオンボーディングのプログラムを変えなければ、その時点でギャップが生まれます。これまでにどれだけ自走してきたエンジニアの方でも同じだと考えています。
プレボーディングブックには、プレボーディングの目的や、会社のミッション、カルチャー、業界知識、開発のプロセスなどを記載し、引き出しを増やしていただきます。ここまでの情報があると、入社前にもかなりの安心感があるでしょう。読むのに何時間もかかるような資料ではなく、最低限インプットしていただきたい内容になっています。
横塚：保険業界は非常に歴史が長いため、業界を知らずに入社して、さらにCRMという複雑なシステムを早期にキャッチアップするのはかなり難しい。3ヶ月で活躍してください、というのは無茶ぶりだというのは自覚しています。1ヶ月に20日働くとして、3ヶ月というと60日しかありません。そうなると、その前の期間に戻るしかない。内定で「Yes」と答えていただいてから、机に座るまでの「Yes to Desk」という期間を、できるだけ活用したいと考えました。
もちろん、入社前にしっかりと羽を伸ばす期間は重要だと理解しています。大量な資料を渡すことには疑問もあり、今も試行錯誤しています。入社日までにお渡しする簡潔で重要な情報になるよう、見直し続けてきたという背景です。
オンボーディングのプロセスの基本・詳細設計
前島：ここからは、オンボーディングのプロセスを説明します。目指すべきは、インプットからアウトプットへの変換率向上です。まず、共通のオンボーディングフローを初回の1on1から設計しました。
前島：コミュニケーションのガイドラインから作成し、マネージャーや開発の部門長なども含め、まったく同じクオリティでコミュニケーションできるようにしていきます。同じ質問ではなく、同じクオリティというのがポイントです。この1on1において過去の経験やファクトの収集をして、オンボーディングのプランを作成します。このプロセスを経て、情報の共有・連携をスムーズにしていきます。
オンボーディングの具体的なアウトプットも相談して決めていき、こちらをオンボーディング期間の評価指標としています。1ヶ月の場合、2、3ヶ月の場合でそれぞれ評価指標の粒度を変えています。
前島：例えば、こちらは1ヶ月の場合の評価指標のひな型例です。プレボーディングの理解度や、初期タスク完了のリードタイム、完了率、完了時間、チームへの統合などが項目としてあります。チーム間の1on1は実施率や時間など、仮説検証しながら測り、その前後でのSlackやDiscordのコミュニケーション変化を本人のフィードバック含め収集しています。さらに、GitHubのプルリクエストのリードタイムも計測し、成果検証をします。
横塚：私の反省点として、入社後は「とりあえず現場に入って、翌日にでもスクラム入ってスプリント入ってソースコードを学んでいけばいいし、コミュニケーションや人間関係も知っていけばいい」という勝手な考え方がありました。ところが、当然ながら人によって向き不向きがあり、最初にしっかり学んでからスプリントに入ったほうが早期に活躍できるという方もいらっしゃいます。そこで、最初の理解度や本人の特性により、人によって進め方を分けて取り組んでいます。
オンボーディング後のスキルマトリクスと評価
前島：オンボーディングが終わって開発へスムーズに入っていけるようになっても、「あとは頑張ってね」と任せきりにするわけではありません。現在のスキルを可視化して、今後の目標となる理想の姿を描き、チームの生産性向上につなげていかなくてはなりません。
そのために、スキルマトリクスを定義しています。バックエンドやフロントエンドといった区分けから、チームのコミュニケーションなどの項目も作り、各グレードのエンジニアに求めるレベルを設定し、自ら振り返る形にしています。それをレーダーチャートとして表示します。
前島：各エンジニアの目標設定の時には、開発に対する目標だけでなく、自分の目指すスキルや期間、必要なことをエンジニア自身が自分の言葉で語れるようになっていきます。とはいえ、このようなスキルマップやキャリアマップに必ずしも従ってほしいという意図ではなく、テックリードやエンジニアマネジメント、技術などを行ったり来たりしたりしながら、自身のキャリアを描いてもらいたいと考えています。
エンジニアの方が自らの評価を実感できるためにも、全社共通のグレード制度に従った等級や役職なども定めています。それぞれ、細かすぎず、大まか過ぎないように設計しています。
これまでのプロセスを積み重ねたうえで、やっとこのグラフの赤枠の中、生産性の向上につながっていきます。
前島：ストーリーポイントの合計、サイクルタイムの改善、レビューの対応スピードなど、Findy Team+を使って集計し、生産性を測る指標としています。チームの平均値と、パフォーマンスを出しているエンジニアの方の平均値を比べて差を出し、エンジニア自身の現在地を把握するような試みもしています。
このような可視化は楽しいものの、データで考えすぎないことも大切です。指標はあくまで指標であり、組織の状態すべてを表すものではありません。問題解決の解像度を上げ続ける努力を惜しまず、チームだけでなく経営陣も巻き込んで取り組むからこそ、さらなる生産性の向上につながっていくでしょう。
横塚：定量化や可視化を進めていると、どうしても数字にとらわれすぎるきらいがあります。私も含めたマネージャー陣、リーダー陣は、数値の向上を目的とするのではなく、あくまでも施策の正しさを測るものであると考える必要があります。
例えば、消化したストーリーポイントが30から25に減少した場合、「5落ちたじゃないか」というコミュニケーションは最もよくないと我々は考えています。数字は、「全社会議やミーティングが多くて実装時間が取れなかった」「技術負債の中につまずくポイントがあった」「そもそも見積もりが甘かった」など、落ちた原因を解像度高く振り返るためのツールであると考えるべきでしょう。全面的に真に受けないよう強く意識しています。
エンジニアの生産性を経営指標につなげていく
前島：ここからは、今後の戦略を考えるにあたり、生産性の向上指標とARRなどの経営指標の関係性、今後の開発組織の展望について説明させていただきます。
横塚：各エンジニアの生産性とチームの生産性は基本的に上げ続けなければならないという前提のもと、勤続年数、勤続月数も伸ばしたいと考えています。パフォーマンスの高いエンジニアには、会社に長くいていただきたい。もちろんいろいろな会社に移りさまざまなシステムを見るのは楽しいですし、本人のキャリアにつながることは大いにあり、それを否定するものではありません。とはいえ、我々としてはリテンションしていただくために、働きやすい環境を作れるよう心掛けています。
我々のプロダクトは一応SaaSになりますので、経営として追っているARRやChurn Rate、LTVといった14メトリックスと生産性向上の結びつきを見ていきます。
例えば、「新機能開発が新たなセグメントへの顧客導入につながるのか」「お客様の使いにくいポイントの改善が解約率の変化につながるのか」といった視点です。整理している途中ではありますが、つなぎ合わせて考えたいと思っています。
横塚：さらに、経営としてのBS/PLに加え、SaaSの14メトリックスを分解して、エンジニア生産性の向上が接続する部分を分解して見ていきます。
例えば、わが社でもChatGPTやCopilotを導入していますが、そこでエンジニアの生産性向上への影響を意識します。例えばR&D比率によって「これくらいの予算で製品を作りたい」となったとき、人数を考えると生産性を10パーセント伸ばす必要があるとしましょう。「そのための施策としてChatGPTやCopilotの採用は正しいのか」と議論し、共通認識を持ちやすい形にしたいと考えています。
ここからは、hokanの開発組織の未来を考えていきますが、昨今はコロナもあり、スタートアップも資本市場からの見え方が変化しています。昔のようにSaaSでエンジニアを大量採用してひたすら広げていく……といったやり方も、ここ数年で見え方が変わってきました。理由として、ChatGTPの登場はもちろん、一昨年ごろからの開発の生産性を爆増するようなプロダクトの進出もあるでしょう。また、売上成長率だけでなく、粗利や営業利益率で評価されるケースも増えてきました。
hokanとしては、さまざまなエンジニアの皆さまに参加していただき、コンバウンドで複数のプロダクトへ提供していきたいと考えています。まずは、5人ほどのチームの生産性をマックスにするため、Findy Team+さんも用いて見える化し、議論の解像度を高め、メンバーと共通認識を取りやすい形を探っていく次第です。
前島：最後のまとめになりますが、最初の導入を思い出していただけますでしょうか。「エンジニアが増えるほど問題も増える」という言葉です。改めて、生産性を高めるために多くのエンジニアをまとめ上げるのは難しいものです。
スタートアップは事業成長が早いため、些細な部分でも投資対効果が議論の対象になります。その些細な部分に解像度高く取り組むことが大切です。細かく実行するというより、細かく見たうえで全体の設計をする必要があります。これから先にあらゆる事業を作っていくうえで、hokanのエンジニアは再現性高く自走でき、高い市場価値を保てるように取り組んでいきたいと思っています。
40分という長い時間、最後までご覧いただきありがとうございました。少しでもhokanに対する理解を深めていただければ幸いです。一緒にドライブしてくださる仲間を募集しておりますので、よろしくお願いいたします。ありがとうございました。
