リードタイムを60時間から3.7時間に短縮。働くひとの健康を創るiCAREが取り組む開発パフォーマンス改善の可視化とは？
クラウド型健康管理システム「Carely（ケアリィ）」の開発・運用を行う株式会社iCAREでは、個人の振り返りやエンジニア組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用頂いています。
今回はiCAREにてCTO/Development部部長を務める工藤大弥さんと、クラウド産保(さんぽ)支援開発チームでリーダーを務める澁谷恭平さんにインタビュー。「Findy Team+」を導入した背景や、計測を浸透させるための取り組み、開発生産性の数値をOKRに組み込んだ結果等について伺いました。
目次
「働くひとの健康を世界中に創る」ことを掲げるiCARE
――まず最初に、お二人の主なご経歴や現在の役割について教えてください。
工藤：ずっとWebエンジニアをやってきて、今年で15年目になります。スタートアップやベンチャーで新規プロダクトの開発に携わることが多く、いわゆるゼロイチを得意とするエンジニアとして、サーバーサイドからフロントエンド、インフラも含めプロダクトを世に送り出すための技術を幅広くやってきました。
そんな中、プロダクトの開発よりも次第にエンジニア育成や組織づくりに関心が移ってきたタイミングで、iCAREから声を掛けてもらいました。そして、iCAREの「働くひとの健康を世界中に創る」というパーパスへの共感もあり入社。昨年8月からは、CTOとDevelopment部の部長として開発組織全体のマネジメントを担っています。
澁谷：以前はエンジニアではなく営業の仕事をしていたのですが、昔からパソコンが好きだったことがきっかけで、エンジニアに転身しました。エンジニア歴は5～6年で、アプリケーションエンジニアをしています。iCAREには、もともと長く業務委託で携わっていて、1年半ほど前に正社員として入社しました。今はクラウド産保支援開発チームのリーダーをしています。
――澁谷さんはどのようなきっかけから、正社員としてジョインされたのでしょうか？
渋谷：業務委託として働く中で次第にフルコミットしたいという気持ちが強くなったことが1つ。それから、iCAREの人たちが一緒に働いていてとても安心感があったことも正社員になろうと思った大きな理由の1つでした。
――お二人の現職での役割やミッションについて教えてください。
工藤：CTOとして経営と技術をつなぐ役割や、開発の投資対効果を最大化させるところを担っています。開発生産性や開発者体験をいかに高めていくかという組織づくりであったり、中長期の技術戦略を考え事業を飛躍成長させるためのビッグピクチャーを描いていったりすることが、主なミッションです。
Development部の部長としての組織マネジメントでは、稟議や勤怠、予算などの承認系の業務もありますね。また、もし調子が悪くなってしまったメンバーがいれば、人事労務の部門と連携して対策を考えるといった役割も担っています。
澁谷：チームリーダーとしての役割は、メンバーのピープルマネジメントが1つ。加えて、現在動かしているプロジェクトがあるので、そのプロジェクトマネジメントも担っています。
プロダクトマネージャーや品質管理のQAチームなど、他チームとも連携を取りながら開発を進め、私自身も開発者としてコードを書いています。また、他チームのリーダーと一緒に、生産性を高めるための議論なども行っています。
――御社の開発組織では、「開発者が誇れる実績をたくさん生み出せる組織」という方針を掲げていると伺いました。この背景について教えていただけますか？
工藤：iCAREで働くエンジニアやデザイナー、プロダクトマネージャーなどを含め、開発プロセスに関わるすべての人にとって、良い体験ができる組織をつくりたいという思いが根底にあります。その背景として、これはiCAREのパーパスに共感した理由の1つでもあるのですが、過去に私自身が働きすぎて体を壊してしまい、休職した経験があります。
また、これまでエンジニアとして業務委託でプロジェクトに関わったり、シード期のスタートアップで立ち上げをしたりするなかで、自分が頑張って書いたコードが世に出なかったり、サービスがクローズしてしまった経験もしてきました。iCAREで働く人たちには、そういう悲しい思いをさせたくないという気持ちがあり、そういった方針を掲げ始めました。
――この方針について、澁谷さんの実感としてはいかがでしょうか？
澁谷：弊社は8月から今年度が始まっているのですが、そこから明らかに開発者が誇れる実績を出せるようになりました。その要因の1つには、「Findy Team+」の導入があると思います。
――「Findy Team+」のどんなところが、そうした実感とつながっているでしょうか？
澁谷：たくさんありますが、一番はわかりやすさですね。例えば、オープンからマージまでの時間が「Findy Team+」を導入してから数値化され、「何時間まで減らしていこう」と目標を立てられるようになりました。その結果として、実際に改善していることやチームの努力が数字として見えることが大きいです。
「開発生産性をもっと誇れる組織」を目指し、計測を開始
――開発生産性の計測を始めたのには、どのようなきっかけや背景がありましたか？
工藤：弊社は2022年から2023年にかけて、事業が急成長する中で全社的にかなり積極的に採用を進めていました。開発組織も20人くらいから40人くらいまで、約1年で倍増するペースで組織が拡大していたんですね。その間に私はVPoEに就任し、開発組織を広くみる役割を担い始めました。
ありがちな課題だと思いますが、そのとき経営陣から「人は増えたけれど、開発は速くなっているのか？」という疑問が投げかけられたんです。そして、それに対して説明するために、生産性を見える化しようと取り組みを始めました。
――「Findy Team+」の導入前は、どのように計測をされていたのでしょうか？
工藤：導入する前は、そもそも何をどうやって測るべきかというところから、当時のDevelopment部の部長と私で意見を交わしつつ、探り探りでやっていました。例えば、勤怠管理ツールでメンバーに工数入力をしてもらっているので、その工数のデータを分析して、そもそも開発業務に時間が使えているかを調べたりとか。
あとは、プルリクエストの状態を分析するために、GitHubのAPIを駆使して集計する仕組みを作りました。ただ、なかなか工数がかかるんですよね。少し条件を変えたいだけでも、すごく手間がかかり自分のマネジメント工数が奪われ大変だなと。そういった背景もあって、「Findy Team+」の導入検討を進めました。
――「Findy Team+」の導入にあたって、経営陣などへの説明が必要になる場面もありましたか？
工藤：ありましたね。やはりなぜそれが必要なのかということが、経営会議の場でも議論になりました。そこで私が伝えたポイントとしては、先ほど触れたように集計に手間がかかっていて、それを効率化をしたいということが1つ。
さらに、ツールを入れることでプルリクエスト数が伸ばせて、開発のパフォーマンスを1.5倍くらいにできる可能性がある、という仮説を立てて導入を提案しました。最終的には、私の熱量で押し切った部分もあります（笑）。
――開発生産性の計測を通じたゴールはどのように設定されていましたか？
工藤：私がCTOに就任することが決まり、今期の開発組織の方向性をどうしていくかに向き合っていくなかで、「開発生産性を、もっと誇れる組織へ」というテーマを掲げることを決めました。それにあたって、「Findy Team+」を上手く活用していくこともセットで組み込んでいきました。
――開発生産性の可視化を進めるにあたって、現場のメンバーからネガティブな反応はありませんでしたか？
澁谷：少なくとも自分のチームでは、可視化への反発は全然なかったですね。もともとGitHub APIとGASを使って計測したものをスプレッドシートで見る運用をしていたので、それほど違和感はなかったのかなと思います。
ただ、数値目標達成のための方法に違和感を覚えるメンバーは何名かいました。リーダーとしては、そこに対する納得感を持ってもらうことが難しかったですね。
――メンバーの方が感じた違和感とは、どのようなものだったでしょうか。また、それに対してどうアプローチしていきましたか？
澁谷：例えば、計測にあたって正確な数字を出すためには、まだレビューしてほしくないプルリクエストを、ドラフトプルリクエストにする必要があります。そうすると、もともとドラフトにする意識がなかった人は、しなければいけないことが1つ増えたような感覚になるんですね。
他には、金曜日の夕方にレビューを依頼すると、土日を挟むことで2日間のロスが発生してしまい、計測上あまり良くありません。なので、週末ギリギリになるようなら、月曜日の朝にレビュー依頼を出してほしい。でも、レビュー依頼を出して週末を迎えたかったのに、という人もいるんですよね。
ただ、どちらにも共通して言えるのは、結局のところ正しい計測をしようとしたほうが、お互いにWin-Winな関係になるということです。ドラフトプルリクエストに関しては、ドラフトにしていれば、まだレビューしてほしくないんだということが、きちんとレビュアーに伝わります。
そして、金曜日のレビュー依頼に関しては、レビュアー側の負担が増えてしまうんですよね。金曜日にそろそろ上がろうかなと思っていたらレビュー依頼が来て、「これも終わらせておかなければ……」となってしまう。そう考えると、翌週の朝にレビュー依頼したほうが健全です。
もしレビューでコメントをもらった場合も、金曜日に指摘をもらって月曜日に直そうとするより、月曜日にまとめて一気にやったほうが、おそらく生産性が高いと思うんですよ。そういったことを説明したり実際にやってもらったりして、メンバーの納得感を得ていきました。
プルリクエスト数をOKRに組み込み改善、その後の定着も
――開発生産性の数値をOKRに組み込んだとお聞きしましたが、その意思決定の背景について教えてください。
工藤：部署のKRにはプルリクエスト数を組み込んでいて、これについては私がリーダーやマネージャー陣と相談しながら決めました。組み込んだ理由としては、ただツールを導入するだけでなく、それを強く推進しなければ浸透していかないと思っていたからです。なので、ややトップダウン気味ではありますが、しっかり浸透させていくという意図を込めて意思決定しました。
結果として、最初にプルリクエスト数を掲げたことは良かったと思っています。チームでのアウトプットの粒度がそろってきて、リードタイムの改善につながったり、各チームの基準となるプルリクエスト数が見えてきて、チームの健全性が確かめやすくなったりしました。
――プルリクエスト数の目標を設定した後、澁谷さんのチームではどのような変化がありましたか？
澁谷：クォーターで200プルリクエストを目標に掲げて、達成するためにどうするかから始まりました。それを考えていくと、やはり今のプルリクエストの粒度では無理だというところに行きつきます。次第に粒度が小さくなっていき、プルリクエスト数はどんどん増えていったので、とても良いKRだったと思います。
実際に以前と比べると、平均変更行数は400行くらい減りました。今クォーターでは、もう200プルリクエストをKRに置いていないのですが、数字が変わらないんです。つまり、定着しているということです。このKRは様々な要素に影響をもたらしたと思っています。
――リードタイムの変化についてはいかがでしょうか？
澁谷：サイクルタイム分析の数値を、週次で追うようにしていました。サイクルタイム平均の合計値を見ると、導入当初の8月は60時間くらいあったのですが、それが10月になると3.7時間にまで短縮されています。
――すばらしい変化ですね。他にも大きく改善した指標などはありますか？
澁谷：オープンからレビューまでの平均時間は、自分でも信じられませんが、チームメンバーの努力もあり、ここ数ヶ月ずっと0.1時間をキープしています。
――プルリクエスト数の粒度を小さくしたり、レビュー依頼を出すタイミングを考慮したりする以外にも、工夫された取り組みがあれば教えてください。
澁谷：直接的に数字に影響するものではありませんが、チームリーダーだけが「Findy Team+」を触っていても自分ごとにならないと考え、メンバーにも触ってもらうことを意識していました。1on1でKRの状況を報告してもらう際、事前に各自「Findy Team+」で確認して、数値を出してもらうようにしています。
感覚とデータのギャップを意識し、チームの状態を把握
――開発生産性の計測によるベネフィットを感じる部分について教えてください。
工藤：私の目線では、チームの状態がつかみやすくなったことは、かなり助かるポイントですね。実際の私の「Findy Team+」の使い方としては、チーム比較の画面で各開発チームのマージ済みプルリクエスト数を選んで、それを朝確認するところから1日を始めています。
その推移を見ていくと、チームの状態として「今プロジェクトがこういうフェーズだから、プルリクエスト数が変化しているな」と察知しやすくなります。このとき、単純にプルリクエスト数の増減を見るのではなく、自分の感覚と実際のデータにギャップがないかを意識しながら見ています。
そこにズレがあったとき、私が認知していないことが起きている可能性が高いので、気づくためのヒントとして活用しています。「Findy Team+」を導入する前、私がVPoEだったころはこういうことができなかったので、非常にありがたいですね。
また、経営会議の場でも、開発組織の状態を問われたときに、すぐに回答しやすくなりました。何か課題感がある場合も定量的なデータで示せるので、説明コストがとても下がったと思います。
澁谷：やはり数値化すると、見えてくるものがたくさんあると感じています。特に、メンバーの負担がわかりやすくなったところが良かったですね。「Findy Team+」のレビュー分析をよく使っているのですが、すごくシンプルな画面で、ひと目見れば誰にレビューの負担がかかっているかわかります。
さらに相関図もあるため、どこまでレビューに携わっているのかまで、すぐにわかります。評価するときにも、例えばその人が1つのプロジェクトだけでなく、開発全体に携わるレビューをいつもしているとか、そういったことも見てとれます。
――改めて「Findy Team+」を使って良かったポイントを挙げるとしたら、どんなところでしょうか？
工藤：私がトライアルで使ってみたときの第一印象として、かゆいところに手が届くプロダクトだと感じた記憶があります。CTOやエンジニアリングマネージャーなどの管理職にとって、「こういうものが見たい」と思うところが上手く導線として設計されていて、シンプルにすごくクオリティの高いプロダクトだなと思っています。
澁谷：「Findy Team+」は開発組織内だけでなく、全社に向けて開発者の動きに納得感を持ってもらいやすくなるツールだと思います。全社定例で「Findy Team+」のグラフを公開したことがあるのですが、どれくらい生産性が上がったのか、ひと目でわかりやすく伝えることができました。
工藤：それに関して補足すると、「Findy Team+」はコミュニケーションツールとしてもすごく有用だと思っています。実際に、社内で関心を持ってくれた人からリクエストをもらい、カスタマーサクセス部のマネージャー2名にも「Findy Team+」のアカウントを発行したことがあるんです。
生産性向上に力を入れていることを社内で発信し続けていたので、実際に使ってみたいと思ってくれたそうなんですね。そして、「Findy Team+」でデータ面を直接見てもらい、「生産性を上げるのって難しいですね」と実感を持ってもらったエピソードがあります。その上で部門の垣根を超えてどうプロダクト開発に向き合っていくのか、考えてもらえるきっかけになったことがすごく嬉しいです。
アウトカムの見える化、プロダクトの重要指標を模索していく
――開発生産性の計測に関して、今後のトライとして考えられていることがあれば教えてください。
工藤：昨年8月に「Findy Team+」を導入してから、各チームのアウトプットにおけるパフォーマンスの改善や維持は順調に進んでいて、いわゆるレベル1生産性は改善が進んだ状態だと思っています。
今は、レベル2生産性のアウトカムをどう見える化していくかに、まさに向き合っている最中。プロダクトマネージャーと、改めてプロダクトにおける重要指標は何かという部分を再設計しています。
アウトプットの指標とアウトカムの指標との関連性について、弊社なりのロジックを整理して、アウトプットのどこを伸ばしていけるといいのかといった議論を、より活発にしていけたらいいなと思っています。
澁谷：ここまでに挙げたレビューのリードタイムなどの他にも、プロジェクトの進捗とともに追える良い指標を見つけたいですね。実際に取り組んでみて、より良いものがないかと次のクォーターのOKRを立てるときに悩みました。
それから、「Findy Team+」では新機能の「チームふりかえりβ」をまだ使っていないので、これから使ってみたいと思っています。チーム活動を促進してくれる機能が増えることは、嬉しいですしワクワクします。
――それでは最後に、御社の組織のアピールポイントや一緒に働きたいエンジニア像を教えてください。
工藤：我々は開発生産性や開発者体験の向上に力を入れて取り組んでいます。そこに向き合うことが好きなエンジニアの方にとって、すごくやりがいを持てる環境だと思いますし、そういうエンジニアの方と一緒に働きたいという思いがあります。
自分たち自身も含めて、働くひとの健康を創るというのは、とても難しいことだと改めて日々感じていて、悩みながら取り組んでいる部分もたくさんあります。そういう過程も一緒に楽しんでいける、より良くすることに前向きに取り組める方と、一緒に働けたらいいなと思っています。
澁谷：プロダクトも組織も、まだまだ成熟しているわけではないので、ぜひ一緒につくっていっていただける方をお待ちしています。どんどん挑戦してみたいという方には、すごく良い環境だと思います。
――工藤さん、澁谷さん、ありがとうございました！
※iCAREでは、エンジニアを募集しています。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
