2024年4月17日〜19日の3日間にわたり、日本最大級*¹のエンジニアコミュニティ「Qiita」では、オンラインテックカンファレンス「Qiita Conference 2024」を開催しました。
*¹「最大級」は、エンジニアが集うオンラインコミュニティを市場として、IT人材白書（2020年版）と当社登録会員数・UU数の比較をもとに表現しています
当日は、ゲストスピーカーによる基調講演や参加各社のセッションを通じて、技術的な挑戦や積み重ねてきた知見等が共有されました。
本レポートでは、ファインディ株式会社 取締役CTOの佐藤 将高氏によるセッション「開発生産性向上サービスを作るFindyが自分たちで開発生産性を爆上げした組織づくりの歩み」の様子をお伝えします。
※本レポートでは、当日のセッション内容の中からポイントとなる部分等を抽出して再編集しています
登壇者プロフィール
取締役CTO
エンジニア組織の開発生産性向上に貢献する「Findy Team+」
佐藤：本日は「開発生産性をCI/CD、開発フロー、コミュニケーションの3つで爆上げした話」をファインディ株式会社（以下、ファインディ） CTOの佐藤から発表させていただきます。
過去の弊社に関しては、開発生産性の伸びしろがあった状況でしたが、現在はユーザーに多くの価値を届けられているような状況です。
開発生産性を高めることは、自分と組織の双方を幸せにすることだということをお話ししたいなと思っております。
佐藤：改めてファインディについてですが、2016年に創業した当初は僕と代表の2人で、エンジニアとしては僕のみという状態でした。
そこから2020年にはフルタイムが25名でエンジニアも10名ほどになり、2021年にはフルタイムが25名でエンジニアが15名、現在はフルタイムが226名でエンジニアが36名いるような組織になっています。
急成長ではあるのですが、事業が増えていっている中なので、採用も加速しております。もしも募集に興味ある方がいらっしゃいましたら、ぜひご連絡いただけたらなと思います。
佐藤：ファインディのプロダクトはエンジニアに向けて提供しており、現状はこちらの5つの事業があります。この中でも最近問い合わせが増えている「Findy Team+」について簡単にご説明します。
「Findy Team+」は、「最速で最高の開発チームへ」というところで、GitHub、GitLab、Bitbucket、Jiraと自動でデータ連携し、生産性を可視化しながら改善を進め、生産性向上を実現することで自分たちの日々の開発サイクルをより良くしていくという、そんな継続的な生産性向上サイクルの実現を支援するプロダクトになります。
佐藤：実際の画面イメージも見ていただきたいのですが、このように、どういったアクティビティを日々チームでやっているのかを可視化して、前の期間と比べてどのような変化が起こっているのかをチェックすることができます。
佐藤：また、レビューの状態がどのようになっているのか、負荷が誰か人に偏っていないか、時間がかかりすぎていないか等を確認することもできます。
佐藤：短期的には開発生産性を上げるプロダクトではあるのですが、長期的には開発者体験を良くするプロダクトというところで作っております。
開発生産性の定義
佐藤：次に、開発生産性って何でしょうね？というところなのですが、皆さんはどんな印象を持たれるでしょうか？
ネットで調べてみると、「開発生産性＝アウトプット ÷ インプット」と書かれているのですが、ここでいうアウトプットとは、開発によって生み出された価値、すなわち機能や品質、ユーザー満足度などが該当します。またインプットとしては、開発に投入したリソースということで、時間や人員、コストなど様々です。
このように多様な組み合わせがあり、人によって定義も違うところなので、ズレが発生してくるところが開発生産性の難しいポイントかなと思っております。
佐藤：ファインディでは短期的に「爆速顧客価値提供」というものを掲げており、その中で僕らは開発生産性の定義としてこちらを定めています。
もちろん、売上やユーザーの課題解決数なども大事だとは思いますが、これらはエンジニアでコントロールしにくいというところが難しいポイントかなと思っております。
他にも「どれくらいの時間で開発できるかは本質ではないのでは？」とか「施策どれくらいこなせたかは本質ではないのでは？」というところが気になるかなとも思うのですが、もちろんそれらを十分に理解した上で進めてきました。
なので、まずは自分たちでできる範囲を改善する、すなわち「作るものが決まってからユーザーの手元に届くまでの時間と施策数」というところで作っております。意図的に全部をやらず、絞ることでアクションをシャープにすることを大事にしてきました。
過去を振り返って
佐藤：では過去を振り返ってどんなことをしてきたかということですが、ここで1つ質問です。「皆さんのチームではリリース作業を1ヶ月にどれくらい行っていますか？」
2020〜21年、会社としてフルタイムが30〜50名くらいでエンジニアも10〜15名くらいだった当時のファインディで、エンジニア5名程度が開発していたもののリリースプルリクがどんなものだったかというと、こんな感じになってます。
佐藤：これをパッと見て読み取れることとしては、1回のプルリクでコミット数が62と多く、プルリクを作成してから2日ぐらい経過していて、変更ファイル数も46と多いような状況になっていました。
もちろん、最善を尽くしてくれた当時のメンバーにはとても感謝しているのですが、プロダクトの進化に対して技術的負債が解消できていなかったという状況で当時の開発生産性はあまり高くありませんでした。
当時大変だったポイントは、大きく7つあります。
- デプロイ頻度は週1回程度
- CIが回るのに1時間ほどかかる
- ビッグバンリリース
- 不確実性が高い状態（ちゃんとQAしないと本当に動いているかどうかがわからない）
- リバートされると全部撤回される
- アーキテクチャーがフロントエンドとバックエンドで密結合
- フロントエンド1文字直すのにdocker buildをする必要があった
佐藤：「開発がちょっとハードモードだよね」というところに、さらにコロナ禍が訪れて、不慣れなリモートワークを全員で開始しました。
個人のタスクが分かりにくいところがあって、テキストレスポンスをしまくる時もあれば、逆にログが残らない時もあるという感じでした。
では、「あるべき姿」とは何なのかというところですが、当時の議論では以下のような論点がありました。
- 人が増えても開発スピードが遅くならない
- 顧客にすぐに価値が届く状態
- 「なにもわからない」不定な状況を減らし、状態をわかりやすくする
- 技術的負債は常に生まれる。負債が大きくなる前に気づき、解消できる状態にする
- なによりも、 前向きに誠実に切磋琢磨できるチームビルディングが大事
取り組みと結果
佐藤：「あるべき姿」に向けて、フィンディでは大きく3つの取り組みに注力して、改善を進めていきました。
トライ1：CI/CDの改善
佐藤：1つ目のトライはCI/CDの改善です。とあるCI/CDでは、それまではビルドしてテストするのにおよそ40分ほどかかっている状況でした。ここに対して、以下の施策を実施していきました。
佐藤：これらを経て実際にCI/CDがどう変わったかでお伝えすると、結論としてはだいたい5分くらいに短縮できました。
佐藤：もともと「本当にリリースして大丈夫なのか？」という心配が多かったところから「テストが守ってくれるので問題ない」というマインドになったことが、開発生産性向上に寄与したと言えます。
トライ2：開発フローとマインドの変化
佐藤：2つ目は開発フローとマインドの変化です。最初の頃にやっていたような大きなプルリクを作って多くの行数やファイル数を一気に更新するやり方だと、得をしないことが多いことが分かってきました。
例えばレビューの範囲が広すぎると、レビューにも時間がかかりやすくなり、結果として「ランチ食べた後にやろう」みたいに気持ち的に後回しになりやすいことが起こっていました。
そして、それが全部やり直しになった時はさらに辛いということが起こるので、改善しなくてはと考えていました。
佐藤：取り組みの方針としては大きく3つ、プルリク作成計画を作って、プルリクの粒度を細かくし、レビューを最優先することを掲げました。
佐藤：こちらは、とあるプルリクのIssueのTo Doリストです。このような形で箇条書きでリストを作っていって、どこまで終わったかを見えるようにしました。こうすることで手戻りが防げますし、どこまで誰が進めているのかも分かるようになります。
また、プルリクはなるべく粒度を細かく作るということで、こちらの施策を進めていきました。特に4つ目に記載した通り、チーム全員が同じやり方をしていくことで、「なんでこうレビューたくさん来るんだ！」みたいな状況が減ってくるので、チーム全体で遮られる回数も減っていきました。
例えばこちらはマイグレーションのプルリクになるのですが、ファイルの変更数でいうと5つ、変更行数も230くらいで、ボリュームとしてはそんなに多くないものをすぐに作って、すぐにレビューしてもらって、すぐにデベロップに取り込む。それによってテストも回るし安全かどうかも分かる、という状況です。
まとめると、僕らが開発フローとマインドの変化に向けてやったことに関しては、プルリクの粒度を細かくして、レビューを最速にして開発生産性を向上させるということになります。
トライ3：コミュニケーション方法の改善
佐藤：3つ目はコミュニケーション方法の改善です。まずは目標設定と期待値調整というところで、具体的にはこちらに記載した内容を進めています。
特に大事なところでお伝えすると、オープンクエスチョンにしない、ということですね。やはりテンプレートやフォーマットなどを整えておくことによって毎回聞いている質問等が分かってくるので、「今日はどうですか」みたいなオープンなことはなるべく聞かず、もっと具体的に聞くようにしていました。
佐藤：あと、これは少しトリッキーかもしれませんが、出社を一定にすることも有効かなと思います。特にフルリモートでもたまに出社してもらうことで、どうしてもコード書く時間が減って生産性は一時的に落ちますが、腹を割って話せる機会を設けて、そのチームの特性などをキャッチアップすることで後々の生産性が上がってくるのかなと思っています。
佐藤：僕自身の大学であまり話さずにいたら友達があまりできなかったという体験をベースに、多くの人と最初に話せる環境を作ることが大事かなと思って作りました。具体例としては以下の要領です。
佐藤：自分を知ってもらうことによって、相手のことも知ることができますし、直接的というよりも、間接的な生産性の向上につながると思っております。
結果
佐藤：これらの結果として、2020年と2023年末の比較がこちらです。特にデプロイ頻度を見ると、2020年と比べて6.3倍に上がっています。
佐藤：その他で言うと、上図は2020年2月から2024年3月までのデータを持ってきたのですが、薄い棒グラフのプルリク数が右肩上がり増えているのと、折れ線グラフのマージ／レビューまでの時間が早くなっていることが読み取れるかなと思います。この4年間で、平均PRマージまでが約23倍、プルリク数については約32倍にまで進化しています。
佐藤：稼働してる人数に関しても、メンバーも増えてきて一人当たりのプルリク数も増えているので、一人当たりだいたい1日平均で4.3プルリクを出すという状況になっています。
佐藤：レビューのリードタイムに関しても、土日も含めて平均1.3時間ほどで必ずレビューがされています。ちなみに、これらの可視化は、冒頭でご紹介した「Findy Team+」でもできます！
佐藤：改めて、僕らは「爆速顧客価値提供」を掲げて、その定義を「作るものが決まってからユーザーの手元に届くまでの時間と施策数」と設定したことで、開発がとても早くなって量も増えた、というところが本日お伝えしたい内容でした。
これからのファインディと開発生産性
佐藤：ここまでで爆速で何かを作るための土台は作れたかなと思っていまして、これからは、「挑戦するエンジニアのプラットフォームをつくる」というところにさらにチャレンジしていきたいと思ってます。
具体的には、メンバーが爆速で走るための育成環境を整えてきておりまして、例えばGitHub Copilot Enterpriseを全エンジニアに貸与しています。他にも、元メガベンチャーのEM経験者やVPoE経験者、マネジメントレイヤーも増えているという状況なので、皆さんが自走するための仕組みづくりについても常々考えています。
また技術的負債を常々解消するというところもタスクに入れていまして、平均すると2〜3割くらいは、生産性を上げるような施策やリファクターなどに取り組んでいます。
さらに開発者体験を良くするために、アンケートを取ったりしながら日々いい環境で働けてるかを調査したり、開発生産性が上がった分2倍の開発ができるようにしたり、ドメインのキャッチアップをしたり、エンジニアチーム間及び職種間でのコミュニケーションがもっと取れるようになっています。
佐藤：そういったところを進めていく上で、ユーザーの価値やKPIにヒットする施策をエンジニアも一緒にやっていけるような状況ですし、事業に貢献できるエンジニアは市場価値も高く、エンジニアプラットフォームを作りたい我々としても嬉しいところです。
特に一番嬉しいポイントとしては、課題を持つエンジニアの方に爆速で価値提供をできることだと考えています。
まとめ
佐藤：本日の内容をまとめるとこちらの通りです。僕らとしては、これからも「挑戦するエンジニアのプラットフォームをつくる」というところを実現したいなと思っておりますので、ぜひ、アンケートにもご回答いただけたら嬉しいです。
Qiita × Findy連動企画！エンジニアの転職に関するアンケートを実施中
また、「開発生産性Conference 2024」というイベントを6月28〜29日に虎ノ門ヒルズフォーラムで予定しており、テスラの元CTOや、書籍『LeanとDevOpsの科学』の著者にもご登壇いただきます。テスラの方はオンラインのセッションにはなるのですが当日限定になりますし、Qiitaにもスポンサードいただいておりますので、ぜひ皆さんにお越しいただきたいなと思っています。ご静聴いただきましてありがとうございました！
文：長岡 武司