POLプロダクト Advent Calendar 2020 の15日目、担当の高橋です。
昨日の @yonedaaa さんの鋭い記事がバズっているのでプレッシャーを感じて書いてます。
今回は1年を通じて「技術負債」や「エンジニアの生産性向上」というテーマで色々とやってきたことについて書きます。技術負債については松岡さんが8日目に記事を書いてくれているので、そちらも是非読んでください。
この1年でやったこと
テストカバレッジ率、システムエラー頻度の改善
去年の今頃はシステムのリプレイスを秋頃に実施した事による余波もあり、日々の機能開発をスケジュール通り進めていくだけでも相当難しく大変な状況でした。当時は相当困っていて、技術顧問の方に相談して技術負債を解消していく必要があると助言を頂き、手始めに下記の項目から改善に着手しました。
- テストコードもほぼ存在しないところからテストカバレッジを上げていく
- APIやフロントエンド側でエラーが頻発しているところから、システムのエラーの数を減らしていく
改善していく際には項目毎にその目標値を定めて週次で現状の数値を報告するようにしていました。例えばテストカバレッジであればC0 60%を目標値にして、JacocoやJestのテストカバレッジレポートの出力値をスプレッドシートに記載し、隔週で開かれる技術顧問との定例会で報告していました。数値が悪化すると何故悪化したか説明できることが求められ、プレッシャーだったのを思い出します…
もう少し具体的にわかりやすいものとして、以下のようなスプレッドシートを作って数値の管理と報告を行っていました。
初期はテストカバレッジとシステムのエラー数だけでしたが、改善が軌道に乗って他にもやれそうなことがあったので、最終的に以下の範囲まで週次で数値を管理、改善するようなところまでいきました。
- テストカバレッジ
- 各APIサーバーのC0テストカバレッジ
- フロントエンドのC0テストカバレッジ
- E2Eテストのシナリオ数
- システムのエラー発生頻度
- 各APIサーバーのException発生数
- フロントエンドのエラー発生数
- リリース頻度
- リリース数
- サイクロマティックコンプレキシーが15以上のソースコード数
- パフォーマンス
- スロークエリ件数
- API処理時間
- フロントエンドのレンダリング時間
開発の実績時間/見積もりのズレの改善
技術負債を改善して一定成果がでて次の改善点は何か考えた結果、「エンジニアの生産性向上」をテーマにして取り組むことに方針決定しました。「エンジニアの生産性向上」と一口に言っても色々ありますが、日々の機能開発をスケジュール通り進めていけないことに対して課題感を強く感じていたので、開発の予実を±10%内に収めることを目標に、3ヶ月程度掛けて改善を行いました。
誰がどういった作業にどの程度時間を掛けているか全くわかっていない状況だったので、手始めにSlackで日々の作業を開発作業以外も含めて予実を共有するところからはじめました。
共有した内容から雑務の時間、ミーティング時間が多そうなことが定性的にわかってきたので、各自の日々の予実の共有を元に全社のミーティング時間、開発作業に費やしている時間、開発系のミーティングに費やしている時間で分類し、それをスプレッドシートで集計して開発作業時間の割合をチームごとに計測しました。
定量的な目標として開発作業時間平均70%を設定し、どうすれば開発作業時間をより多く取れるか、マネージャーとテックリードで打ち手を検討し実施していくことで改善をし続けました。改善の結果、最終的には平均で70%近くまで開発業務時間をとれるようにできました。
予実管理についても、チームごとにJIRAを使ったりスプレッドシートでガントチャートを作成する等やりやすい方法で予実管理を行い、進捗遅れの把握と何故遅れたのかの振り返りをチーム単位や技術顧問の方とのミーティングで実施し、予実が合わなくなる原因の気付きと、その改善を実施していきました。
リリースまでのリードタイムの改善(をしたかった)
技術負債も解消できたし予実も合うようになってきたので、「エンジニアの生産性向上」の一環として、次はリリースまでのリードタイムの改善に取り掛かりました。
まずは現状CIの実行時間が長いなと言う肌感から現在の所要時間を確認し、DX Criteriaの定めているCIの所要時間を参考に目標を設定しました。
また定性的に開発着手からリリースまでの各工程で何処に時間がかかっているか以下のように検討し、会社での働き方がフルリモートになったこともありレビューのリードタイムがかかっていそうと見当をつけました。レビュー完了までのリードタイムを減らせる可能性のある打ち手としてモブプログラミングを思いつき、社内にモブプログラミングを導入しようとしています。
※「をしたかった」となっているのは現在WIPだからなのと、「リリースまでのリードタイムをX%改善する」といった風呂敷を広げたが数値を計測しづらいものから目標としたため、定量的な結果はまだできていないからだったりします。定性的には多少成果が出ていて、例えばカナリアリリースができるようにインフラに変更が行われていたり、@mizno さんがアドベントカレンダー初日に書いた記事で紹介いただいたルールはリードエンジニア内でのモブプログラミングによって作成されています。今後どうやって定量的に計測するか検討中です。
わかったこと
少ない工数でも実施しし続けても成果が出る
プロダクト部の工数の最大20%までで進めるという合意をプロダクト部のマネージャーと取った上で1年間改善を続けていましたが、1年間を振り返ってみると普段の開発業務の合間に少しずつ進めていくだけでも年間で見るとかなり大きな変化を生み出せることがわかりました。
可視化して変化を計測する、管理することの重要性。目標設定して可視化しないと上手く行かない
技術負債解消の様な作業はどうしてもサイドワークとして少しずつ進めていく必要もあって、そういった場合において常に状況を可視化してモチベーションを維持する、目標を設定してやることをぶれないようにすることはかなり重要だとわかりました。実際に目標を設定しても状況を常に可視化しておかないと上手く行かないということも体験もしました。これまでエンジニアとして働いていて工数以外の数字を管理することはこれまで稀でしたが、今後はテーマ性のある仕事をする際は成果を常に確認できるように可視化することを心がけて行きたいです。
権威のある人(技術顧問)に後押ししてもらう、お尻を叩いてもらうことの重要性
自分がやろうとしていることの妥当性を助言によって後押しして頂いたり、経営サイドに現状を説得力ある形で伝えて頂くなど、技術顧問の方の存在に助けられた1年間でした。技術負債の解消や生産性向上はどうしても後回しにしがちな仕事で、それを定期的に報告するプレッシャーも確実に継続できる上でプラスに働いていたと振り返ってみると感じています。
終わり
以上、振り返りでした。後1回アドベントカレンダーの担当があるので頑張って書きます。
次は @guevara-net が記事を書いてくれます！ゲバさんよろしくお願いします！
アドベントカレンダーを書くのが遅れてごめんなさい！