この記事は カオナビ Advent Calendar 2023 24日目です。
はじめに
こちらのカンファレンスに参加してきました！
Findy株式会社主催のイベントで、オフライン200人、オンライン600人規模の、大規模な勉強会です。
GitHubやGoogleなど名だたる企業の方々がご登壇されていました。
視聴セッション
CTOが語る、ビジネスグロースに向けた開発生産性向上への道すじ
「株式会社はてな」の大坪様と、「株式会社ユーザベース」の文字様が登壇されていました。
「株式会社ユーザベース」開発生産性への取り組み
「株式会社はてな」開発生産性への取り組み
「リードタイムの可視化」
可視化をすることで新たな気づきに繋がる。
また、チーム間で可視化された数値を比較することで、よりチームの練度が上がっていく。
私自身、リードタイムをもっと速くできるんじゃないか？と感じることはあり、
なんとなく体感はしていても、自身の作業のどの部分が、遅いのか？
どの部分はむしろ早いのか？わかっていません。
高速化対応する時とか、どこが遅いのかボトルネックを探りますよね。
可視化をすることで、適切な改善活動ができるというところに共感しました。
「質の重要性」
可視化を行い改善を重ねることで開発速度が上がりました。
ただ、事業やサービスの成長につながっているかと言うと、そう言うわけでもない事実もありました。
プロダクトを届ける先を見つめつつ開発速度を上げることが重要だと考えています。
開発生産性を上げつつ、品質は落とさないことがとても重要だと私も考えています。
この品質は、コーディングの品質もありますが、お客様の価値という意味もあります。
私自身は、企画当初からなるべく関わるようにして、お客様が何を求めているのか？を
把握しながら、設計、実装に向かうようにしています。
組織拡大フェーズにおけるペインと開発生産性向上の推進
「株式会社BuySell Technologies」の今村様と、「Chatwork株式会社」の田中様が登壇されていました。
組織拡大フェーズのエンジニア組織のペインとは？
拡大のたびに発生しやすいこと
エンジニアのアウトカムが見えづらくなる
エンジニア一人一人のアウトプットも見えづらくなる
50名程度までは一人一人の顔とか性格が把握できるが、それ以上は難しい
開発に対する定量化が求められるが、現実難しくなっていく
「文化づくり」
開発以外のところにも注力している。
各制度ごとに、CTO室と各部のEM達でペアになって、文化を醸成していく
一番最初に取り組んだのは、中途採用と評価で
目標を見せることと、行動を適切に評価することで、エンジニア組織全体を望む方向に舵を切る
開発生産性を上げる と考えた時、エンジニアの作業ベースで高速化を考えていたので、はっとしました。
エンジニア組織全体の文化醸成を行うことで、各エンジニアが生産性に意識を向けるようになったり
アウトカムに意識を向けるようになることが先ず大事という気付きを得ました。
投資側に関わっているところを全て可視化することにトライ中
また、アウトカムの指標の可視化も見える化することで、開発生産性の全容を把握
アウトプットのみの見える化をすると、アウトプットにしか目がいかなくなることがあり
早い方が優秀 どやっ みたい話になるのは避けたい。
アウトカムに目が行くように、数値化することが重要。
爆速でプルリクを上げたとしても、無駄機能だったらお客様の価値は０なので、
お客様の価値ベースで、価値をどれだけ速くあげられるか？
ここが本当に重要だと感じました。
受託開発組織におけるメンバー、チーム育成を促進する開発生産性可視化
「クラスメソッド株式会社」の髙橋様と、「株式会社ゆめみ」の桑原様が登壇されていました。
いままでの問題点、課題感
メトリクス測っていなかった
測るにしても、受託会社のため、
始点と終点がお客様都合で変わったりする点
不具合修正期間は、プルリクの上がる速度が速いけれど
不具合修正なので、そりゃそうなる。
フェーズによっての計測が難しい。
素敵だなと思ったところ
- Approveした人に責任がある雰囲気 → 「コードにおける責任はチーム」を明文化
- メトリクスを測ったことで、アウトプットが平均的に現時点で0.4ポイント上がった
- 数字が見えると、やる気につながるのかもしれない。
開発生産性を測る新たなフレームワーク「SPACE」の定義と実践
「株式会社ワンキャリア」の宇田川様が登壇されていました。
「SPACE]フレームワークとは
「SPACE]フレームワークとは
Microsoftの研究チームにより提唱された生産性を測定するためのフレームワーク
従来の生産性測定より、広範囲を対象とすることが特徴
Eはスクショし漏れたので、ググってください！
SPACE運用
わかりやすさと、計測のしやすさをベースに指標を選定しました
SPACEは、具体的な指標例を定めていないようなので、企業や開発体制によって指標を考える必要がある。
また、指標に対して、基準を設けることが難しいので、時間軸で１ヶ月、３ヶ月などでの振り返りをすることが重要。
改善活動のフレームワークにFour Keysや、SPACEというものがあるのを初めて知りました。
これらフレームワークをベースに活動を行うことで、エンジニアにも受け入れられやすいし、
経営層の合意も取りやすいところが良いポイントだなと思いました。
運用では、時間軸で、チーム毎に計測、改善する形は素敵だなと思いました。
ウォーターフォール開発における開発生産性向上
「株式会社viviON」の松永様が登壇されていました。
DLsiteの運用会社です。
開発生産性向上に本格的に取り組む前にやっていたこと
- Googleカレンダーから会議の時間を引いてみた
- PRの変更行数を比較してみた
etc...
取り組み始めて明るみになった課題
- PRの規模が大きくてレビューに時間がかかる
- PRの指摘が多い
- PR開始までの時間が長い
PRを小さくすることで解決しようとしました
ただ、こう言う問題も出る
そう言う問題はこのように解決している
- UnitTestを書く
- 動作確認を行う
- レビューアーの固定化で、コンテキストを維持しながらレビューしている
※ただ、固定化されたレビューによるボトルネックの解消はできていない
※社内背景として、頻繁なデプロイを必要とする組織ではない
PRは小さい方がレビューしよう！って気になりやすいのは事実だし
見やすいのも事実だけれど、コンテキストを見落としやすい問題を
どのように解消するか？が難しいと思ってました。
動作確認で解消するというのはその通りだけれど、シフトレフトしたい気持ちもあります。
今日の公演を聞いて思ったのは、
企画〜リリースの規模感にポイントを振りアウトプットを計測しつづけることで
後戻りしてもPRを小さくするほうが速いか、
全体像を見れるレビューを密に行う方が速いか、
検証できるんじゃないかな？と思いました。
大事なのは、やっぱり可視化だと感じた。
海外エンジニア拠点の開発生産性マネジメント
都合上、最後の公演は見れませんでした。
まとめ
弊社でも開発生産性を上げるためには、どのようにすればいいか？
模索しながら進んでいます。
今日の公演を聞いて、 アウトプットの見える化や、アウトカムの見える化 の重要性を感じました。
個人的にはPRが大きくなりがちなので、PRを小さくした時の検証をしてみたいです。
手間をかける時間より、レビュー速度が上がることにより、最終的な速度の向上に繋がるかもです。
先ずは、今の速度を測り、変えた速度を測ることをしていくことで、成果へのスピードが上がるかも？と期待感があります。
総じて学びが多く、とても楽しいカンファレンスでした！