LIFULL Creators Blog

「株式会社LIFULL(ライフル)」の社員によるブログです。

生産性・技術的負債をMetabaseで可視化した話

技術開発部の清水です。好きな食べ物は広島風お好み焼きと広島県産牡蠣と広島県産穴子です。

拡張に次ぐ拡張でサービスは便利なものに成長していく一方でソースコードは次第に複雑になっていきます。 そのまま放っておくと積み上げた技術的負債により開発コストが上がっていき、最悪の場合にはサービスの発展を停止させてしまう可能性もあります。 このような理由から、弊社では技術的負債を着実に返済していくべく生産性・技術的負債の可視化をMetabaseで行っています。 可視化する情報元はGithub API、CodeClimateQuality APIの2つのみです。

生産性の可視化

本流ブランチにマージされたPR数(生産数)

開発者にとって生産性とは何でしょうか。様々なご意見が予想されますが、生産性ではなく生産数ということであれば本流ブランチにマージされたPR数は開発者が身近に感じやすい一つの指標かと思います。

f:id:LIFULL-shimimi:20210120140315j:plain
本流ブランチにマージされたPR数
PRは「ある要件を満たすためにまとまったソースコードの変更」であると言えますし、本流ブランチにマージされて初めて価値を生み出すという特徴があります。但し、これを「生産性」と結びつけるためにはいくつかの要素が加味されていません。PRの規模は大小様々ですし、PRをレビューした人員のコストも様々で、期間内に何名のコミッターが活動したのかも様々です。これらを可視化していきます。

本流ブランチにマージされたPRによる意味のある変更行数(生産規模)

意味のある変更行数というのは、空行やコメントなどを除いた行数です。 変更行数の多いPRは切り戻しの難しさもありますが、レビュアーのレビューコストを増幅します。 適切な粒度に分割できるようになると、レビュアーは少ない変更に集中してレビューすることができ、ひとつの生産にかける時間の総合を短縮することにつながります。

f:id:LIFULL-shimimi:20210120140706j:plain
本流ブランチにマージされたPRによる意味のある変更行数

本流ブランチにマージされたPRの平均レビュー応答数(生産を助けた人員の労力)

PRをマージするまでの期間に、コミッター・レビュアー間でコメントの応酬を行った回数です。

f:id:LIFULL-shimimi:20210120141021j:plain
本流ブランチにマージされたPRの平均レビュー応答数
レビュアーが即座には受け入れられない疑問や質問の余地のある実装は、レビュアーのレビューコストを増幅するものです。 少ないレビュー応答数でPRがマージできるようになるような、わかりやすい実装やレビュー依頼は、レビュアーの労力を下げますし、ひとつの生産にかける時間の総合を短縮することにつながります。

本流ブランチにマージされた「1コミッターあたりの」PR数(1生産者あたり生産数)

前述した「本流ブランチにマージされたPR数(生産数)」をその期間アクティブであったコミッター数で割った値です。 生産数が順調に増えていたとしても、人員が増えたことによる結果なのであれば、アプリケーション起因の生産効率は変わっていないと考えられます。

f:id:LIFULL-shimimi:20210120141240j:plain
本流ブランチにマージされた「1コミッターあたりの」PR数

100人で100PRをマージできる状態と、50人で50PRをマージできる状態では、生産効率はともに1とし 100人で200PRをマージできる状態は2であり、100人で100PRをマージできる状態に比べて2倍の生産効率であるという考え方です。 (=少ない人数でも多くのPRをマージできる状態が生産性の高いソースコード)

この値がより大きく「本流ブランチにマージされたPR数(生産数)」も大きいのであれば「生産量・生産性ともに上がった」と言えるではないでしょうか。 (ただし、その変更の内容が設定ファイル・READMEの変更のみである可能性もあるため、PRの変更内容から判定し、それらを除外する必要はあります。)

開発者のコミッター・レビュアーとしての行動バランス

ある開発者は実装ばかりを、ある開発者はレビューばかりをしているという状況はよくあると思いますが、そのような状況が続くと属人化の可能性が高まります。 コミッターの集中、レビュアーの集中を避けられるように、開発者のコミッター・レビュアーとしての活動バランスを、全体の開発者における相対的な分布図で表しています。

f:id:LIFULL-shimimi:20210120141414j:plain
開発者のコミッター・レビュアーとしての行動バランス
水色の丸ひとつひとつが開発者で、X軸がコミッターとしての生産活動数、Y軸がレビュアーとしての生産活動数になります。丸の大きさは変更行数に比例し、コミッターとしての活動数が少なくても、その1つの開発が巨大である場合には大きく表示されます。実際にはカーソルをあわせると開発者名が表示されますが、ここでは伏せています。よりバランスの良い状態(左下から右上への直線に近似する状態)を、チーム全体で目指していくとチームとして開発者の活動バランスが高く、属人化がされていないと予測されます。

ここまでが「生産性」に関する指標です。いかがでしょうか。 これらの情報は全てGithub APIから取得した情報を元に可視化が可能です。 続いて「技術的負債」に関する指標です。

技術的負債の可視化

技術的負債の情報はCodeClimateQualityのAPIから取得した情報を元に可視化しています。

codeclimate.com

技術的負債の現況と現在に至るまでの推移

下記はあるプロダクトにおける技術的負債の推移を月次・週次・日次・PR別という粒度で推移グラフを出力したものです。

f:id:LIFULL-shimimi:20210120141530j:plain
技術的負債の現況と現在に至るまでの推移
上段は現況を表し下段は現在の数値に至るまでの月・週・日・PRマージ別の推移を表しています。 ここではまず、そのRepositoryの技術的負債に関する現況と現在に至るまでの推移を把握することに努めています。

推移グラフの赤線は、REMEDIATION_TIME(推定修復時間)です。これは健全な状態に直すまでにかかる時間の想定値であり最重要視しています。

緑線はIMPLEMENTATION_TIME(推定実装時間)です。これはこの状態になるまでにかけられた時間の想定値です。

灰線はTECHNICAL_DEBT_RATIO(技術的負債比率)です。これは規模の異なる複数のリポジトリを比較する際に有効な値です。

このRepositoryでは5月から9月まで順調にREMEDIATION_TIMEを減らしていき10月に微増した。 まず、このようなことが言えるかと思います。

なお、これらの指標はCodeClimateQualityの下記の記事で説明されています。

codeclimate.com

REMEDIATION_TIMEを自分ごとにできるようにする

多人数で開発するRepositoryの場合、いくら技術的負債を可視化しても自分ごととして考えづらいという難点があります。 また、その改善結果が正しく見えないことには、モチベーションは上がりづらいと思います。

本流ブランチにマージされたPR別のREMEDIATION_TIMEの推移

「あるPRでは1時間増加、次のあるPRでは13時間削減した」というPR別のREMEDIATION_TIMEの推移をみることができるようにしています。 ここまでくると、どのPRにより、負債が削減・増加したのかは明らかで、それが自分の実装・レビューによるものであるのかも明らかです。 (画像では説明に不要な具体的な情報は伏せております)

f:id:LIFULL-shimimi:20210120141734p:plain
本流ブランチにマージされたPR別のREMEDIATION_TIMEの推移

コミッター別REMEDIATION_TIME変動累積値

「ある開発者が一定期間内に複数の開発を繰り返すことで、ある開発時には100時間増加させたけど、後日別の開発時には200時間削減し総合的にこれまで100時間の削減をおこなった。」 このようなことが後でわかるように、コミッター別REMEDIATION_TIME累積を出力しています。 左は、よりREMEDIATION_TIMEをより大きく削減したPR、右は、コミッター別REMEDIATION_TIME累積を示します。 (画像では説明に不要な具体的な情報は伏せております)

f:id:LIFULL-shimimi:20210120142136p:plain
コミッター別REMEDIATION_TIME変動累積値

効果の高いリファクタリング対象ファイルの選定

いよいよ技術的負債に問題意識が生まれ、技術的負債の返済に時間をとれることになったとします。 では、限られた時間でまずどのファイルを変更すればいいのでしょうか。 CodeClimateQualityでは静的コード解析上のボトルネックは教えてはくれます。 しかし、当然のことですが静的コード解析であるため開発プロセスや組織構造、実行順序などを考慮した物ではありません。

その結果、単純に静的コード解析上のボトルネックに従うばかりでは「コードは複雑だけどほぼ誰も触らないファイルを全力でリファクタリングしてしまう」可能性があります。 静的コード解析上の大きな改善とならないとしても、できることなら限られた時間で、より改善効果を感じられるファイルをリファクタリングしたいものです。

高頻度で変更されたり、多くの人に変更されるファイルは、小さな改善数値でも大きな改善結果を感じられるはずです。 このような理由で、変更回数の多いファイル、変更者の多いファイルを各種指標に添えて可視化しています。 (画像では説明に不要な具体的な情報は伏せております)

f:id:LIFULL-shimimi:20210120142228p:plain
効果の高いリファクタリング対象ファイルの選定

弊社ではこのようなダッシュボードを様々なRepositoryを対象に出力しています。 複数のRepositoryをこのような同じ測りで比較してみると次第に面白い傾向が見えてきます。

  • 実装量が増えるにつれてREMEDIATION_TIMEも増えるRepositoryばかりではない。
  • X年しか経過していないがREMEDIATION_TIMEがX年以上増えてしまうRepositoryが存在する。
  • 特定の開発者が物凄い勢いでREMEDIATION_TIMEを返済しているRepositoryが存在する。

特に最後の「特定の開発者が物凄い勢いでREMEDIATION_TIMEを返済しているRepositoryが存在する」このケースの気づきは、技術的負債を返済してくれた人と功績を可視化することだと思います。 同じRepositoryを開発する皆に恩恵がある尽力の結果ですので、称賛されるような文化醸成がされていくことでモチベーション向上にも繋がりますし素晴らしいことと考えています。

おわりに

エンジニア職以外の方には技術的負債返済にコストをかけるメリットが伝わりにくいと言う声をお聞きしたことがあります。 上記のような重視する指標を提示し、交渉相手の重視する指標を提示してもらい、どのような影響を与えるのかを示すことができれば 技術的負債返済の必要性を理解していただき、交渉が円滑になるのではないでしょうか。

最後までお読みいただきありがとうございました!