Synamon’s Engineer blog

Synamonでは、VR空間に複数人が同時に接続可能で、多彩な標準機能を搭載している『NEUTRANS』という独自のVRシステムを開発しています。ビジネスなどの現場でも使いやすいよう、独自の機能や技術を日々追究しています。このブログでは、『NEUTRANS』開発の裏側にあるVR技術と、それを支えるUnityやC#といった技術の話を書いていきます。

開発チームの生産性・健全性を可視化できるgilotを触ってみた

こんにちは。

株式会社 Synamon でエンジニアをしております、渡辺匡城(@mochi_neko_7)と申します。

今回はソフトウェアの開発チームの生産性・健全性を可視化できる gilot というツールを触ってみたのでレポートします。

ツールの作者の広木大地さん(@hiroki_daichi)は エンジニアリング組織論への招待 の著者であり、EM.FM などでも開発組織の話を発信されています。

そんな広木さんがツールを作成したと目にしたので、実際に触ってみて、弊社のプロダクトに適用してみました。

日本語での使い方やグラフ、指標の解説は Qiita にもまとめられていますので、こちらも参照ください。

qiita.com

上記の内容の補足として、環境のセットアップや Windows 環境ではまったところ、弊社のプロダクトの簡単な解析結果の紹介をします。

gilot

gilot(ジロー)は Git のログをもとに開発チームの生産性や健全性を可視化できるツールです。

GitHub のリポジトリはこちらになります。

github.com

環境セットアップ

簡単にですが、gilot の利用に必要な環境のセットアップを補足します。

なお、今回の検証に使用した環境は以下になります。

  • OS:Windows10
  • gilot:0.2.3

Python

gilot は Python のプログラムのため、実行には Python の環境が必要です。 環境自体はいくつかあり何でも構いませんが、公式はこちらです。

www.Python.org

環境変数のパスを通すのを忘れないでください。

Git

Git のログ解析をするので、Git Client の環境も必要になります。

Git を使っているリポジトリが解析対象になるので、基本的には既にセットアップされているはずです。

GUI 系の Git ツールで内部に Git Client をインストールしている場合にはその環境変数のパスを通すか、新しく公式からインストールしてしまっても構いません。

Git-scm.com

gilot

gilot のインストールは、コンソールで以下のコマンドを入力して行います。

$ pip install gilot

解析方法

GitHubQiita にも紹介がありますが、ここでも簡単に紹介します。

log

まず log コマンドを使って Git のログを解析します。

$ gilot log [repository] -o [log].csv
  • [repository] には解析対象のリポジトリのディレクトリを指定してください。

  • [log] には解析結果の出力先を指定してください。

直接グラフなどを出力するコマンドもありますが、解析にはやや時間がかかりますので、一度ファイルに書き出しておくことをお勧めします。

デフォルトでは master ブランチを対象に解析します。 これを変更したい場合には、--branch [branch_name] のオプションを追加してください。

後で紹介する hotspothotgraph の解析をしたい場合には、--full のオプションを指定して解析する必要があります。

$ gilot log [repository] --full -o [log-full].csv

こちらも少々時間がかかりますので、エラーが出ていない場合にはしばらく待ちましょう。

plot

plot コマンドを使うことで、4つの指標のグラフを作成できます。

$ gilot plot -i [log].csv -o [plot].png
  • [log] には log コマンドで作成した解析結果を指定してください。

  • [plot] にはグラフの画像の出力先を指定してください。

グラフの見方は Qiita の記事を参照してください。

hotspot

hotspot コマンドを使うことで、変更されやすいファイルを解析できます。

$ gilot hotspot -i [log-full].csv
  • [log-full] には --full オプションを追加して解析したログファイルを指定してください。

変更されやすいファイルのランキングがコンソールに出力されます。

変更されやすいということは、バグの温床になりやすいコードであり、リファクタの良い対象になりやすいと考えられます。

hotgraph

hotgraph コマンドを使うことで、同時に変更されやすいファイルのネットワークグラフを作成できます。

$ gilot hotgraph -i [log-full].csv -o [hotgraph].png
  • [log-full] には、-full オプションを追加して解析したログファイルを指定してください。

  • [hotgraph] には、グラフの画像の出力先を指定してください。

--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
  • [log] には log コマンドで作成した解析結果を指定してください。

  • [author] にはグラフの画像の出力先を指定してください。

結果

弊社のプロダクトである NEUTRANS BIZ のリポジトリの plot の結果だけ少しお見せします。

f:id:mochinekos:20200711162725p:plain

簡単な考察

上記の結果の考察を簡単にですが行ってみました。

グラフの詳細な説明は Qiita を参照してください。

Gini Coefficient

50%を下回っているので、それほど格差が大きいわけではなさそうです。

これも時系列で追って変化を見てみたいですね。

Hisgram of Code Output

ややピークが大きいでしょうか。

このグラフの使い方はまだピンと来ていないです。

Code Output and Productivity

insertions と deletions が交互に出ていて、定期的にメンテナンスしているのが分かりやすい印象です。

リリースサイクルとの連動がありそうですね。

最近追加された Productivity がまだどのような指標なのか分かっていないです。

Numer of Actual Authors

数値と実体はおおよそ一致している印象です。

数値が落ち込んでいる部分は、おそらくプロダクトの方向性を決めていた時期で手が止まっていたのかなと推測できます。

開発の安定性の参考になりそうです。

おわりに

今回は手でコンソールにコマンドを打って検証しましたが、CI に組み込んで自動で定期的にグラフを出力するのもできそうですね。

ソフトウェアの生産性や健全性は目に見えづらいものですが、ソフトウェアのコードそのものではなく、活動(Git のログ)を用いると数値で解析することできます。

と作者の方が EM.FM でおっしゃっていました。

このような指標を自分で見出したり解析するツールを作るのはなかなか大変ですよね。

その点 gilot はお手軽に可視化までできてとても便利です。

開発チームの生産性や健全性を可視化するツールの1つとして、開発チームのデリバリーパフォーマンスを測る指標 などと併用しながらうまく利用していきたいです。