こんにちは。
株式会社 Synamon でエンジニアをしております、渡辺匡城(@mochi_neko_7)と申します。
今回はソフトウェアの開発チームの生産性・健全性を可視化できる gilot というツールを触ってみたのでレポートします。
ツールの作者の広木大地さん(@hiroki_daichi)は エンジニアリング組織論への招待 の著者であり、EM.FM などでも開発組織の話を発信されています。
そんな広木さんがツールを作成したと目にしたので、実際に触ってみて、弊社のプロダクトに適用してみました。
日本語での使い方やグラフ、指標の解説は Qiita にもまとめられていますので、こちらも参照ください。
qiita.com
上記の内容の補足として、環境のセットアップや Windows 環境ではまったところ、弊社のプロダクトの簡単な解析結果の紹介をします。
gilot
gilot（ジロー）は Git のログをもとに開発チームの生産性や健全性を可視化できるツールです。
GitHub のリポジトリはこちらになります。
github.com
環境セットアップ
簡単にですが、gilot の利用に必要な環境のセットアップを補足します。
なお、今回の検証に使用した環境は以下になります。
Python
gilot は Python のプログラムのため、実行には Python の環境が必要です。
環境自体はいくつかあり何でも構いませんが、公式はこちらです。
www.Python.org
環境変数のパスを通すのを忘れないでください。
Git
Git のログ解析をするので、Git Client の環境も必要になります。
Git を使っているリポジトリが解析対象になるので、基本的には既にセットアップされているはずです。
GUI 系の Git ツールで内部に Git Client をインストールしている場合にはその環境変数のパスを通すか、新しく公式からインストールしてしまっても構いません。
Git-scm.com
gilot
gilot のインストールは、コンソールで以下のコマンドを入力して行います。
$ pip install gilot
解析方法
GitHub や Qiita にも紹介がありますが、ここでも簡単に紹介します。
log
まず log コマンドを使って Git のログを解析します。
$ gilot log [repository] -o [log].csv
直接グラフなどを出力するコマンドもありますが、解析にはやや時間がかかりますので、一度ファイルに書き出しておくことをお勧めします。
デフォルトでは master ブランチを対象に解析します。
これを変更したい場合には、--branch [branch_name] のオプションを追加してください。
後で紹介する hotspot や hotgraph の解析をしたい場合には、--full のオプションを指定して解析する必要があります。
$ gilot log [repository] --full -o [log-full].csv
こちらも少々時間がかかりますので、エラーが出ていない場合にはしばらく待ちましょう。
plot
plot コマンドを使うことで、４つの指標のグラフを作成できます。
$ gilot plot -i [log].csv -o [plot].png
グラフの見方は Qiita の記事を参照してください。
hotspot
hotspot コマンドを使うことで、変更されやすいファイルを解析できます。
$ gilot hotspot -i [log-full].csv
[log-full] には --full オプションを追加して解析したログファイルを指定してください。
変更されやすいファイルのランキングがコンソールに出力されます。
変更されやすいということは、バグの温床になりやすいコードであり、リファクタの良い対象になりやすいと考えられます。
hotgraph
hotgraph コマンドを使うことで、同時に変更されやすいファイルのネットワークグラフを作成できます。
$ gilot hotgraph -i [log-full].csv -o [hotgraph].png
--allow-files や --disallow-files のオプションで解析対象のファイルのフィルタができますので、プロジェクトによって適宜使用してください。
Windows を使っている方は注意が必要です。
内部で使用している signal.py のライブラリが Windows では使用できずエラーを吐いてしまいます。
(参考)
これは --stop-retry のオプションを使うことで回避ができます。
$ gilot hotgraph -i [log-full].csv -o [hotgraph].png --stop-retry
同時に変更されやすいファイルには何かしらの関連があると考えられます。
もし一見関係の薄いファイルが関連付けられている場合には、それらの責務が適切になっているか確認やリファクタをしたほうがよいと考えられます。
author
最近追加された author というコマンドを使うことで、コミットしている人のコミット量や全体での割合を時系列に解析できます。
$ gilot author -i [log].csv -o [author].png
結果
弊社のプロダクトである NEUTRANS BIZ のリポジトリの plot の結果だけ少しお見せします。
簡単な考察
上記の結果の考察を簡単にですが行ってみました。
グラフの詳細な説明は Qiita を参照してください。
Gini Coefficient
５０％を下回っているので、それほど格差が大きいわけではなさそうです。
これも時系列で追って変化を見てみたいですね。
Hisgram of Code Output
ややピークが大きいでしょうか。
このグラフの使い方はまだピンと来ていないです。
Code Output and Productivity
insertions と deletions が交互に出ていて、定期的にメンテナンスしているのが分かりやすい印象です。
リリースサイクルとの連動がありそうですね。
最近追加された Productivity がまだどのような指標なのか分かっていないです。
Numer of Actual Authors
数値と実体はおおよそ一致している印象です。
数値が落ち込んでいる部分は、おそらくプロダクトの方向性を決めていた時期で手が止まっていたのかなと推測できます。
開発の安定性の参考になりそうです。
おわりに
今回は手でコンソールにコマンドを打って検証しましたが、CI に組み込んで自動で定期的にグラフを出力するのもできそうですね。
ソフトウェアの生産性や健全性は目に見えづらいものですが、ソフトウェアのコードそのものではなく、活動（Git のログ）を用いると数値で解析することできます。
と作者の方が EM.FM でおっしゃっていました。
このような指標を自分で見出したり解析するツールを作るのはなかなか大変ですよね。
その点 gilot はお手軽に可視化までできてとても便利です。
開発チームの生産性や健全性を可視化するツールの１つとして、開発チームのデリバリーパフォーマンスを測る指標 などと併用しながらうまく利用していきたいです。
