こんにちは!freeeの kakkunpakkun と言います。 freeeでは開発人事部長とかエンジニアとかやってます。
freee Developers Advent Calendarの7日目として、今回はfreeeの開発力を可視化してみた話を書いていきます。
開発の現状を可視化する
freeeの開発組織は優に100人を超え、リポジトリも調べてみたところ200近くありました!組織・プロダクトが大きくなり、なかなかプロダクトの隅々まで理解することは難しくなって来ました。
そうなってくるとfreee全体として開発はうまく進んでいるのかということはよく分からなくなってきます。
我々は順調に開発が出来ているんだろうか?
という疑問が湧いてきました。(もちろんうまくいっていると思いたいですが)
そこで何か参考になるものがあったら良いと思い、つい最近開発力の可視化というものをやってみました。
調子が悪いと思った時に体温を計ってみる人は多いですよね。それと同じようにfreeeの開発の現状を体温みたいにざっくりとでも把握出来るものがあると良いなと思いました。
そういうものがあれば調子が悪いなら対策が取れるし、対策の影響も分かりそうです。
というわけで、freeeにはアウトプット→思考という価値基準もあるので一度アウトプットをしてみてから考えることにしてみました。
アウトプット→思考
まず、アウトプットする。
そして考え、改善する
なにを見たらチームとして順調なのか
開発と言っても指し示す範囲がものすごく広いので「これさえ見ればOK!」なんてものはないだろうと思っています。
なので割り切りも必要そうだと思いました。
いくらアウトプット→思考と言っても何も考えずに行動することも出来ないのでまずどんなものが欲しいか考えました。
- 現状が異常かどうか知りたい
- 施策が有効だったか知りたい
- 体温や血圧と同じようなものが欲しい
- 異常な状態かどうか分かるのでは
- 人間が風邪を引いたりすると熱が出るのと同じようになにか指標に影響するのでは
- 順調に開発が出来ていそうかどうか知りたい
- 絶対的な指標ではなく相対的なもので良い
- 人事的な評価に繋げない
こんなところでしょうか。
以上から、
- PullRequest(PR)数
- デプロイ回数
を可視化してみることにしました。
人が増えている中でPRは順調に作られているのか、デプロイは順調にできているのかなどを見てみようということです。
結局のところプロダクトにはPRがレビュー、マージをされてリリースされてユーザーへ提供されるということでPRの数を見てみるというのは無意味ではなさそうです。
PRの大小はあると思うんですが、最近ではある程度PRを細かく切るようにしてたりするし、平均すればそんなに粒度に違いもないのではという仮定で進めてみます。
また、デプロイをする回数もユーザーに価値を届けた回数、フィードバックループが回った回数と考えると重要そうです。これも取ってみましょう。
一方で、こういう可視化でありがちなのは開発チームの管理に使ってしまって「数字が下がっているからエンジニアの評価下げるべきじゃないか」とかなって安心して開発をしていられなくなったりすることですね。これは絶対に避けようと思いあくまで開発チーム全体での指標でプロジェクトや個人レベルに落とし込むのはしないことにしました。
そもそも開発というのはエンジニアがコードを書くだけでなく、UXデザイナーやPM、QA、レビューなど多くの支えがあって進むものなのでエンジニア1人のPR数などに落とし込むのは無理がありそうです。
使い捨て感覚のアプリケーションで可視化する
ちょうど先日freeeでは開発合宿というものがあり、そこで一回取ってみたらどんな感じか見てみようということになりました。
開発合宿についてはこちらに書いているので是非どうぞ
さて、まずはデータの取得です。最終的には棒グラフか折れ線グラフが出てきたらなんとなく良さそうです。
今回使ったツールは以下の通り
- Rails
- Octokit.rb(GitHubクライアント)
- Jenkins
- Excel
- google spreadsheet
なんとも見慣れたものというか、ちょっとつまらないくらいですね。 まあでも使い捨てなのでそんなものです。
GitHubへの接続も利用者の多そうなOctokit.rbを使うことにしました
ちなみにRailsを使ったのは特にRailsに思い入れがあるわけではないのですが、使い慣れたActiveSupportやconsoleがあって進めやすいと思いました。PR、デプロイ数など幾つかの数字を取るつもりだったので最低限のコードの構造化もしたかったのでRailsの提供するディレクトリ構成もありがたかったです。
まずは動くようにするためにGemをなにを入れようかとか考えるのも面倒なのでRailsはありがたかったです。 Rails使うなんてヘビー過ぎると思ったんですが使い捨てなのでそんなものです。
グラフ化も社内で分析に使っているRedashやData Studioなども選択肢としてあり得たのですが、データをGoogle BigQueryなりRedshiftなりに入れるのも面倒だったので普通にgoogle spreadsheetを使いました。 まあでも使い捨てなのでそんなもn(ry
JenkinsはCIとしてではなく、デプロイをJenkinsで行っているのでそこからデータを簡単に取得出来そうと思い、データ取得先として使いました。
ちなみにExcelも使ったのは中間データを作るのときにspreadsheetを使いたかったのですがデータが大きすぎて無理だったのでローカルにインストールしてたExcelを使ったという経緯です。
ここではきれいな構造とかかっこいい仕組みなどは目的ではなくあくまでアウトプットをして考えるための材料づくりなので徹底して yak shaving になるのを回避しました。
可視化してみた結果
とりあえずグラフは出来ました!
デプロイ回数
デプロイ回数累計
PR数
PR数累計
可視化してみた感想
グラフ化してみたら思った以上に面白かったです。なんとなく順調な時期やそうではなかった時期など見えてきた感じもして、体温的な指標として見れる予感もしてきました。
いくつかトピックで感想を書いていきます。
たくさんのリポジトリでPR数を押し上げる
最初は会計のプロダクトのみの1リポジトリで成長していっていたのが、人事労務freee(当時は給与計算freee)や裏側の基盤系、会社設立freeeなど次々とリポジトリが立ち上がり、PRが積み上げられていく様子がわかりました。
freeeはたくさんのリポジトリから構成される大きなシステムなのだなと改めて感じました。
これまでの歴史を感じる気がしてちょっと感動してしまいました
PR数は全体としては伸びてる
PR数は全体的には伸びてそうです。
人が増えているので当然と言えば当然ですが、人が増えるということは非効率になりやすいことでもあるので安心といえば安心です。
ただ、2015年は結構伸び悩んでるように見えたりするのでこの辺りの原因は探りたいところです。
デプロイ高速化の影響が大きそう
一番面白かったのは2016年10月頃に本番デプロイ処理の高速化が行われ飛躍的に速くなったのですが、その後はデプロイの回数がグッと増えているところです。
デプロイの回数が多ければそれだけユーザーに価値を提供するチャンスも増えますし、エンジニアもデプロイが終わるのを気にしている時間も減って効率が良くなると思います。
freeeの分析基盤に乗せて定常的に見れるようにする
これだけ面白い結果が出たのでワンショットのデータだけではなく今後も定常的に見れる仕組みが欲しくなってきました。
これはまだ作り終わっていないのですが、freeeが持っている分析基盤に乗せることにしました。
使うツールは以下の通りです
- embulk
- Redshift
- S3
- Redash
全然違う構成ですね。
ざっくりとしたフローはこんな感じです。 データ取得部、データインポート部、閲覧部の3つのパートから成るシステムです。 (いい加減なシーケンス図でごめんなさい!)
早く動いてデータが見れるところまで持っていきたいところです
全体的な感想
私はデータ分析が得意な人間というわけではないのでこんな感想ですが、今後はちゃんと分析してみたらもっと面白い事実が分かったりするのではと思いました。
開発力というのはものすごくふわっとしているけど組織としては実際のところどうなのか気になるものだと思います。
こういうふわっとしたことはずっと考えていても「それだけじゃ分からないよな」とか「意味あるのかな」となって尻込みしがちなので、まずはワンショットでも良いからアウトプットを出してみるというのは次のアクションにつながるので良いと思いました。
実物を見ると思いがけない気付きもあるものです。
プロダクト開発においてもまずアウトプットを出してみるというのはオススメです!
おわりに
お約束ですがfreeeでは共に開発力を高めてくれる仲間を募集しています! 開発人事に興味がある人もぜひぜひ
明日はfreeeのプロダクトの成長を支える新人プロダクトマネージャー、にこやか詩人、poeさんの出番です。お楽しみに!