こんにちは！ ケップルで Creator Success を推進している池浦（ @pr1v4t3_ ）です。
2024年5月30日に株式会社Another works（以下、Another works ）主催のもと、株式会社SmartHR（以下、SmartHR ） 、株式会社ケップル の3社でオフラインイベント「麻布台ヒルズ TECH TALK - 開発生産性を高める組織の取り組み - 」を開催しました。
今回のイベントでは各社が取り組んでいる開発生産性を高める取り組みについて、パネルディスカッション形式でお話ししました。
本記事では、イベントの様子やパネルディスカッションの内容についてご紹介します。
イベントの概要
昨今では、ただ開発を行うのではなく、その生産性に注目する企業が増えています。開発生産性を高めることによってプロダクトやサービスの価値をより迅速に届け、高い品質を担保することができる一方で、開発生産性を高める取り組みのデファクトスタンダードが無く、各社手探りで取り組んでいることがほとんどです。
今回のイベントでは、規模やプロダクトの性質が異なる3社が、それぞれ何を考え、どのような取り組みを行ったかを紹介し、開発生産性の向上に悩んでいるマネージャーや、開発生産性に興味を持つエンジニアに知見を提供することを目的として開催いたしました。
パネラーとモデレーター
パネラー①： 株式会社 Another works 取締役CTO 塩原 基弘さん
大学時代にプログラミングに興味を持ち、エンジニアとして2年間インターンを行う。その後、株式会社ビズリーチ(現.ビジョナル株式会社)に新卒入社し、2019年5月、代表の大林と株式会社Another worksをCTOとして共同創業。 2019年9月に「複業クラウド」(当時はAnother works)という複業したい方と企業や自治体をマッチングするためのサービスをリリース。
パネラー②： 株式会社 SmartHR 技術統括本部 テクノロジーマネジメント本部 ダイレクター すがわら まさのりさん
2020年5月SmartHR入社。 2023年まではSmartHRの基本機能と呼ばれるモノリシックアプリケーションの開発やマネジメントに従事していました。2024年からは新設された部署でSREやDPEといったプロダクトを開発しているチームの支援を行うチームのマネジメントをしています。 個人の活動としてパーフェクトRubyやパーフェクトRuby on RailsなどRuby/Railsに関する書籍の執筆も行っています。
パネラー③： 株式会社 ケップル エンジニアリングマネージャー 石野 純
2015年に新卒で大手Slerに入社。2019年に株式会社ケップルに入社し、エンジニアとして自社のプロダクト開発に従事。2023年より開発組織「KEPPLE CREATORS LAB」のエンジニアリングマネージャーとして、エンジニアリング組織のパフォーマンスを最大化する施策を推進している。
モデレーター： 株式会社 Another works 開発グループマネージャー/PdM 宮内 北斗さん
2019年にサーバーサイドエンジニアとしてSES企業に入社し、Webエンジニアのキャリアをスタート。同時期にフロントエンドエンジニアとして3社で複業。2021年にAnother worksと出会い、現在はPdMに転身し複業マッチングプラットフォーム「複業クラウド」のグロースを担当。開発グループのマネージャーも兼任している。
会場は麻布台ヒルズ Tokyo Venture Capital Hub
今回のイベントはケップルが入居している麻布台ヒルズの Tokyo Venture Capital Hub で開催しました。夜になるとライティングが綺麗で、とても居心地のよい空間です。
いざ、パネルディスカッションへ
パネルディスカッションでは、参加者が聞きたい内容にフォーカスして Slido を利用しながら進められました。Slido に上げられたテーマの中で最も関心が高かったのは「開発生産性の評価」でした。
イベント冒頭の自己紹介・会社紹介の中で Four Keys という言葉が出てきたので、そういった評価の話からディスカッションが始まりました。
開発生産性の評価について
モデレーター 宮内さん「まずは投票が多かった開発生産性の評価から話していきましょうか。具体的な取り組みや、これからこうしていこうと考えていることなどお聞きしたいと思います」
ケップル 石野さん「評価というよりモニタリングに近いと思いますが、ケップルでは Four Keys の値や Jira のレポートでリードタイムやレビューに要した時間を見たり、あとは Wevox というサービスでエンゲージメントスコアを見ています。開発生産性に関する施策を行った時に Four Keys や Wevox のスコアが上下に振れるので、その変化を見ることによって施策の評価を行っています」
Another works 塩原さん「Another works では一週間に一度の KPT で 定性的に評価しています。この取り組み良かったよね、良くなかったよねという意見を挙げてもらっています。私自身はその会に参加していないのですけど。現場メンバーのちょっとしたモヤモヤを挙げてもらいつつ、現場で何が起きたのかという事実にも着目し、定量的に評価できるところは定量的に評価して、改善に繋げています。実際のところはほとんど定量的に評価できないのですが、定量的に評価できるところは評価していく、というスタイルですね。定量的な取り組みの話をすると、 ChatGPT に Google App Script を書いてもらって、数値化しているところがあります」
SmartHR すがわらさん「私たちもガチガチの定量化はしていないですね。というのも、こういう機能を作りたいという着想からリリースするまでの間に、ユーザーヒアリングやスコープの変化など、さまざまな変数があるからです。そのため、どこを評価しますかという話になると思いますが、チームによっては VSM (Value Stream Map)を作ってここからここまでこのくらいの期間だったなど分析しているチームもあります。とはいえ再現性があるわけではないので、スクラムのスプリント単位の振り返りを交えながら、定性的な評価を行っています。定量的な評価としては、Findy Team+ を利用しています。Findy Team+ で Four Keys やサイクルタイムを確認し、プランニングの段階で認識が揃っていなかったよね、といった改善ポイントを見つけています」
各社、やはり定量的な評価には苦労している様子でした。定性的な取り組みとしては KPT ベースで話すことが多いようで、これはスクラムとの親和性も関係しているように思います。
ツールとしては Findy Team+、Jira、Wevox を利用しているようですが、Findy Team+・Jira は文字通りの意味で開発生産性を定量的に測ることができ、Wevox は心の開発生産性を測ることができるようなイメージが近いと考えています。単純にワークフローとして洗練されていても、開発者たちの心の負担が大きくなってしまうシーンは多くあり、その負担が最終的には開発生産性に紐づくように思うので、そのどちらも測っていくことが大切だと思います。
開発生産性における AI 活用
モデレーター 宮内さん「先ほど ChatGPT の話も出てきましたが、開発生産性に関して AI の活用は行っていますか？活用事例があれば教えてください」
SmartHR すがわらさん「GitHub Copllot は使いたい人に使ってもらっています。特にテストを簡単に書けることからとても助かっています。実際に使い倒している人に聞くと、GitHub Copilot が無いとやってられません、という話を聞いたりもします（笑）」
ケップル 石野さん「ケップルも GitHub Copilot を導入していて、似たような話だと PR-Agent という AI がプルリクのレビューをしてくれるツールを導入しています。的を得ているレビューは体感 2, 3 割なのですが、中には参考になるレビューもあるので、考えるきっかけになっています。レビュワーとレビュイーのキャッチボールが減るのもいいですね」
AI 活用は各社手探りの状態だと感じました。とはいえ、GtiHub Copilot にテストを書いてもらうのは想像以上に体験が良いので、みなさん試してみるとよいかもしれません。GitHub Copilot Enterprise（旧 GitHub Copilot X）が登場してから約 1 年が経過し、これからさらに開発生産性の観点で AI の活躍の幅が広がっていくと思います。
開発生産性の定性的な評価を深掘り
Slido では定性的な評価に関する質問を多くいただいたので、さらに深掘りしていきました。
モデレーター 宮内さん「定性的な評価を行う時は、何かフレームワークを使っているのでしょうか？」
SmartHR すがわらさん「いわゆるスクラムの振り返りの話になりますが、基本は KPT ベースで振り返っており、少し改造して GKPT にしているチームもあります。チームによってやりやすい形式は異なるので、KPT をカスタマイズしたものを中心に、スターフィッシュという別のフレームワークを使ってKPTとは別角度で振り返りをしているチームもあります。振り返りやすくする工夫は、例えばプロブレムという言葉は少し強すぎるので四象限を用いて重要だと感じていること・共有したいことという重みづけをしているチームもあります」
Another works 塩原さん「Another works ではトライを絶対に達成するぞ！っていうトライオーナーがいます。ただ、トライが重すぎて開発に手が回らないこともあるので調整中ですね」
SmartHR すがわらさん「トライを考えたけど、一週間何もしなかったとかありますよね。そういうときは深掘りが足りなかったり、なんとなくふわってしていることが多いので、ネクストアクションを具体的に決めたり、誰が進めるのかをチームで話して共通認識を作っています」
ケップル 石野さん「KPT から少し離れますが、定性的な課題を見つけるという観点だとケップルでは 1on1 を通して見つけてます。1on1 も色々なやり方があって正解や裏技はないと思っていて、どれだけ話してる相手に向き合えるかだと考えてます。向き合っているうちに、ちょっとしたモヤっとポイントや課題が出てきますね」
KPT ベースで話して最後トライを出すと何か明るい気持ちで終わることができるのですが、トライを達成できないことってよくありますよね。トライを推し進めるトライオーナーという取り組みは、とても素敵に感じました。
効果のあった取り組み
モデレーター 宮内さん「開発生産性の評価の話からさらに深掘って定性的な評価の話をしましたが、この取り組みを行ったら変わったというものはありますか？」
SmartHR すがわらさん「この質問は答えるのが難しいなと思っていたんですよね。チーム単位で振り返ってちょっとずつ改善しているので、これに取り組んだら劇的に変わりましたみたいなものがあんまりないです。とはいえ最近使っててよかったと感じるのは、回し者ではないですが、 Findy Team+ ですね（笑）。数字が見えるとあんまり良くない面もあって、これって本当に改善すべきかの判断に時間だけを使ってしまう時がありますけど、それぞれの数字の意味を理解して、その数字に向き合ったチームとそうでないチームでは明確に差が出ていますね」
Another wokrs 塩原さん「スプリントオーナー制度は良かったですね。スクラムマスターがいないとスクラムに積極性がなくなってしまうと思うのですが、4週間に 1 回くらいに担当が回ってくると、残りの 3 週間もどう過ごすかが重要になってきて、結果的に担当じゃないときも積極的に参加するようになりました。社外のスクラムマスターの人にこの取り組みを話すと、いいねと言っていただけるシーンもあり、この取り組みは始めてよかったなと思います」
ケップル 石野さん「技術領域に一貫性を持たせることの効果が大きかったと感じています。技術的な要件的に統一することができないケースも必ずあると思いますが、可能であれば統一したほうがいいですね。技術がバラバラだとそれぞれを担当できるメンバーが限られますし、スイッチングコストが高くなります」
Another wokrs 塩原さん「確かにそうですね。新卒の時に Java の研修が 3 ヶ月間あったのですが、現場に言ったらなぜか Go 言語でアプリケーションを 1 ヶ月で作るということがって（笑）今思えば、めちゃくちゃかわいそうだなと思うのですが、言語が統一されているとそういったことも起きないんだろうなと思いますね」
SmartHR すがわらさん「言語特性的に Go がいいとかあれば、もちろんそういう選択をしていいとは思うのですが、例えば Ruby と PHP であればどちらを選んでも決定的な違いはないと思うので、一貫したほうがいいですね。人の移動もしやすいですし、知見も貯めやすいので。一貫する話の前に出てきたスプリントオーナー制もいいですね。 SmartHR だと（任意で）各チームから 1 名が代表でスクラムマスターとして振る舞って、複数のチームのスクラムマスターが集まって今週の取り組みを共有してディスカッションする交代制スクラムマスターという制度があります。基礎レベルを上げるという観点では全員スクラムマスターを経験するのはいいですね」
スプリントオーナー制や開発言語の統一など、取り組んでいる内容はさまざまですね。スプリントオーナー制のように参加者の理解度の水準を合わせる取り組みは、開発生産性に限らず他の取り組みにも流用できるノウハウだと感じました。
続けて、 Findy Team+ を利用していると現れる差について、すがわらさんにお話しいただきました。
SmartHR すがわらさん「一番わかりやすいのはサイクルタイムですね。レビューから Approve までにたくさんコメントがついたり、手戻りが発生してしまうと、その時間が長くなってしまうのですよね。そのサイクルタイムを短くするためにはどうしたらいいかと考えた時に、タスクを細分化するとか、実装方針の合意形成をしっかり行うという解決策になると思いますが、それらが数字として出ているとプランニングが上手くできていなかったからサイクルタイムが長くなっているよね、と振り返られます」
技術的負債に対する取り組み
Another works さんには技術負債解消デーの具体的な取り組みについて話していただきました。
モデレーター 宮内さん「参加者のみなさんが気になっているトピックとして上位にあるのは負債への取り組み方ですね。Another works では技術負債解消デーを設けているとお話しされていましたが、実際のところ効果はありましたか」
Another works 塩原さん「やっぱり 1 日を技術負債に充てると、しっかり 8 時間確保できるのがよいですね。 1 日 1 時間だと小さい文言修正しかできないですが、8 時間取れると Sentry のエラー通知を全部消すみたいな割と大きな負債も解消することができます 」
ケップル 石野さん「実はケップルも週 1 でカイゼン活動日っていう日を設けていて、週 1 で毎週金曜日に技術的な負債やエラーの解消をしています。Another works さんが話していた良かった点ももちろんありますが、スプリントプランニングの時に負債のことを考えなくて済むようになったことが大きいと思います。カイゼン活動日がないと、プランニングの段階でいつやるか話す必要がありますが、カイゼン活動日があればとりあえずこのエピックに追加しておけば消化される安心感があります。潜在的な課題も負債として消化しやすくなりますし、心理的安全性が高まっているように感じます。週 1 でも改善できないものは経営レベルの判断かなと考えているので、 CTO と相談しながら意思決定して数ヶ月単位で取り組むこともあります」
SmartHR すがわらさん「SmartHR の場合は週 1 日とかそういう明確な時間の確保はしていないですね。当時の私が担当していたプロダクトだと、スクラムでスプリントの開発をする傍ら、サイドプロジェクトとして有志で集まった改善活動グループがありました。例えばパフォーマンスやライブラリアップデートの課題など、少し重かったり持続的に取り組んでいく必要があるものはサイドプロジェクトで消化していました。それとは別に、ソースコード上のコメントがもはや嘘になっているみたいな、ちょっとした修正って気がついたら直せばいいじゃん直していこうね、っていう組織文化を作るのも重要だと思ってます。そういったことを気づいた時に直せるように、週に 30 分のソースコードやPRを眺める時間を設けて、隣のチームが何しているのかを理解し、何か障害が起きた時にあのチームはこの辺り触っていたよねという勘所をつけていました。また、アーキテクチャレベルの大きな負債ってやっぱりありますよね。当時は最善だと思われていたが、今となってはちょっと違うよね、みたいな。そういうのはやっぱり経営判断になりますし、そういった負債の大きさに合わせて異なるアプローチを取ることが重要ですね」
時間をしっかり確保して解消する技術負債解消デーやカイゼン活動日という取り組みに加えて、組織文化の醸成やサイドプロジェクトという形式での解消方法も紹介いただきました。組織やプロダクトの性質によって解決方法は様々なので、このあたりはチームやチームに属するメンバーの特性を見極めて選択していく必要がありますね。
ビジネスチームが納得感を得るために
モデレーター 宮内さん「技術的負債にどれくらいコストをかけるかというのはすごく説明が難しいところだと思いますし、実際現場で悩んでいる人も多いと思います。どのように説明したり、コミュニケーションを行うと良いかお話聞いてもよいですか？」
SmartHR すがわらさん「SmartHR では 1 スプリントまるまる使って何か大きな負債の解消をしないので、ビジネスチームと交渉してリファクタリングのためにスプリントの開発を止めるというのはやっていません。ただ、チームを作って大きな負債を解消する場合には、当然そのチームに充てる人をどこから集めるのかを検討する必要があり、このまま放置するとバグが出やすくてユーザーからの問い合わせも増えてソフトウェア開発が遅くなるので解決したほうがいいよね、みたいな合意を得てから進めています」
Another works 塩原さん「Another works の場合は現時点で交渉するシーンはないのですが、仮に今後必要となった場合には他の経営陣に説明する機会を設けますし、判断材料となる数字を用意してこの数字がこうなります、という説明をすると思います」
ケップル 石野さん「KEPPLE CREATORS LABとビジネスサイドのチームはプロダクトグループという一つの組織なので、密にやりとりしていますし、何か負債を解消するようなイベントが発生するときは、必ず共有もしています。もちろんビジネスチームとしてはこの機能を早く出してほしいと思っているのですが、開発側としても早く出すためにやっていますと目線を揃え、結果として変わったことやわかったこともちゃんと伝えています。例えば、デプロイの回数が増えたとか表示速度が改善された、とか。そういう成功体験を一緒に経験して、理解してもらっているイメージです」
Another works 塩原さん「Another works でもビジネスの方針を考える時に使うバランスシートに技術負債を載せていて、その解消がアセットやプロフィットに貢献していますよね、と話しています。ビジネスチームから要望がくるわけじゃないですが、そのように先んじて数値課題を出しています」
「技術的負債の解消は一見すると価値を生んでいないように見えるが長期的な観点で効いてくる」という部分をどのように伝えるかが難しいところですね。丁寧な合意形成に向けて、負債解消による恩恵をビジネスチームと共に分かち合ったり、定量的に測っていくことが重要だと感じました。
失敗した取り組みたち
モデレーター 宮内さん「ここまでは上手く行った取り組みについて話してもらったと思いますが、失敗とまでは言わないけどこういった取り組みはやめました、みたいな話があればお聞きしてもいいですか？」
SmartHR すがわらさん「先ほど FIndy Team+ を使ってよかったという話をしたと思いますが、実は Findy Team+ の導入を検討したものの、数ヶ月保留期間を設けていて、その後改めて導入を決めたという経緯がありました。なぜ期間が空いたかというと、やっぱり数字だけ見ても何のためにやっているのかわからないとか、開発ってもっと幅広いし変数も多いのでその数字にフォーカスすることが開発の改善に繋がるのか、といった疑問の声がありました。ツールを使う人が知識を蓄えないと上手く使えないだろうと思ったので、Four Keysについて述べられている「LeanとDevOpsの科学」の読書会を開き、時間をかけてディスカッションして基礎知識を身につけた上で導入し、この数字を見ていきましょうね、というのをやりました。ツールの導入を一旦止めて、下地を作ってから導入したという話ですね」
ケップル 石野さん「やめた話で言えば、ケップルは一度スクラムをやめました。アジャイルのやスクラムの理解が浅いときに、とりあえず始めてみようというノリでスクラムを導入しましたが、何のためにこのイベントをやるんですかみたいな声が上がったり、前のワークフローの方が良かったよね、みたいな雰囲気になりました。この反省として、スクラムに関わるメンバーの理解が浅い状態で進めてしまうのは非常に良くなかったことがわかりました。そのため、Atlassian のアジャイルコーチというドキュメントを使って輪読会したり、スクラムの教科書通りにまずはやってみて、何かフィットしない部分があればちょっと変えてみる、といった方法で進めています」
Another works 塩原さん「技術負債の話があったと思いますが、負債として UI 崩れがあるじゃないですか。UI の崩れを解消する時間が取れなくて、 UX 遊撃隊みたいなのを作ったのですが、ちょっとした修正でもサーバサイドの知識が必要になったり、Figma を見る能力が求められたり、逆にフルスタックなエンジニアにお願いするにしても少し小粒な課題になってしまうため、なんだか UI / UX の改善は絶妙なラインだな、と感じました」
各社、試行錯誤しながら取り組んでいる様子が伺えました。スクラムをやめた話、ツールの導入をやめた話、片手間で UI / UX を解消することをやめた話など個性が強く出ていると感じます。共通点として、チームで何かを取り組む時には先ほども話した通り理解度の水準を合わせることが重要に感じます。
ストーリーポイントの難しさ
モデレーター 宮内さん「スクラムの話が出てきたので、最後にお聞きしたいのですが、ストーリーポイントやプランニングの難しさがスクラム導入の難易度を上げているという話があると思いますが、どのような取り組みを行っているのか、あるいは失敗談などがあればお聞きしたいです」
Another works 塩原さん「関数名まで決めないとストーリーポイントをつけられないみたいな状況に陥ると多くの時間を要してしまうので、塩梅がとても難しいですね」
SmartHR すがわらさん「プランニングポーカーとかストーリーポイントをつけるのって、タスクの大きい小さいを理解するものなんですよね。人間って絶対評価が難しいので、 A と B を比べたら A の方が大きいよね、という比較の方がわかりやすいです。なので、先週やったこのタスクに比べて今回のタスクはこれぐらいだよねっていう基準を作っていって、それを繰り返しているとだんだんこれくらいのタスクだったら自分たちのチームのケイパビリティからするとこのくらいで実装できるよねっていう土台ができていきます。それが行えるようになると、ベロシティも安定していったり、今の開発リソースだと 2 週間後にできる 1 ヶ月後にできるというのが見えてきます。とても難しいんですけど、やっていくしかないですね。あとは相対評価なのであまり難しく考えずにやりましょうというのとポイントの基準を見つけられるかが大事なところかなと考えています。何よりも認識のずれがないことが望ましいですね」
ケップル 石野さん「つい先日もエンジニアメンバーと 1 時間ぐらい語り合ったのですが、やっぱり 1 回やっただけでは上手くいかないので繰り返しやっていくしかないよね、という話になりました。一方で、絶対値の見積もりの方が良くないかという声も上がったりします。ただ、絶対値の見積もりってかなり時間がかかると考えてて、見積もりを出すために結局のところ詳細設計まで行う必要が出てくるんですよね。なので、このタスクは大きい・小さいみたいな粒度から初めて行って、徐々にメンバーの認識を合わせていくのが正解なんだろうな、と思います」
SmartHR すがわらさん「リファインメントの時にストーリーポイントを出すにあたって、情報が足らないシーンもありますね。技術的に可能かどうかわからないといった場合には、スクラムでいうところのスパイクを行って、不確実性を減らすために一段かますといった工夫をしています」
ストーリーポイントが難しいという話はスクラム導入したばかりのチームでは必ず話題にあがりますね。見積もりという具体性のある数値が急に抽象的な数値に置き換わることから、拒絶感や不信感を抱くのは当たり前のことだと感じています。チームとしてスクラムの理解を深め、試行錯誤しながら取り組んでいく必要がありますね。
おわりに
パネルディスカッション後の懇親会は大盛り上がりでした。
今回のイベントでは開発生産性というテーマからスクラム・ツール・AI活用など幅広い領域のディスカッションが行えました。イベントの満足度も非常に高かったので、開発生産性というテーマで他の企業の取り組みも聞きたいですね。
