“生産性向上に投資するため”のデータの可視化　生産性測定から組織の仕組み作りをサポート

自己紹介

近藤宇智朗氏（以下、近藤）：では、お願いします。「生産性を可視化したい」と題して発表します。ということで、自己紹介します。私は技術部に所属している、近藤といいます。ふだん、インターネットなどでは“うづら”と呼ばれているので、お気軽にうづらと呼んでください。現在、技術基盤チーム兼データ基盤チームという感じで働いていて、SUZURIの事業部には直接所属していませんが、お手伝いという感じで今回はお話しします。

ちなみに、福岡市のエンジニアカフェという施設があるんですけど、私はそこのサポーターもやっているので、Twitterなどで福岡の相談があればお気軽に絡んでください。趣味はZumbaです。あとは書いてあるとおりな感じです。

生産性の測定することになった背景

今日は生産性を計測する話をしますが、具体的にどういうやり方をして、どういう対象を見て、ツールとかは何を使っているかという話と、具体的な値をちょっと見て、サンプルを出して、今後のやっていき、なんかをお話ししようと思います。

まず、生産性を計測します。どうして今この話が出ているかの背景があります。例えば、Google Cloudのブログに『エリートDevOpsチームであることをFour Keysプロジェクトで確認する』という記事があります。これは、要するにソフトウェアの開発チーム、たぶんDevOps系に限らず、ソフトウェア開発チームのパフォーマンスを実際にいろいろな指標を使って計測することが重要ですよ、ということを紹介した記事です。

少し前になりますが『LeanとDevOpsの科学』、英書では『Accelarate』といいますが、その本でもチームの生産性をなんとかして計測することを非常に重要だと説いていて、具体的な方法などを紹介しています。

以前からSREのプラクティスの1つに、自分たちが使った時間を計測するなどがあったりするのかな、と思います。具体的なところをすぐには思い出せませんが（笑）。そんな話があった記憶があります。

最近『ユニコーン企業のひみつ』という本が出ました。この中に、プロダクティビティスクワッドの組織の話があります。この組織は早く進めるようにすること、つまり、生産性向上に投資するための組織であると説明されています。

こういう組織が、これからWebの企業では非常に重要になると思っていて、私が所属している技術基盤チーム、データ基盤チーム、どちらもいわゆる早く進めるようにするための仕組みづくりにコミットする組織です。その一環としてSUZURIの支援を行なっています。

そのため、私たちのOKRの説明は省略しますが、目標の中にはSUZURI事業部を含めた生産性の指標が入っているとすごくわかりやすいとなり、こういった計測の仕組みにあらためて注目している、というところです。

もちろん、実際にやったことをちゃんと計測するのは、やはりエンジニアリングの基本なので、そういうことをやっていきたい面もあります。

ちょっと堅い話が続いてしまった感じがありますが（笑）。生産性に投資をするのはすごく重要で、ガンガン投資したいので、その効果をちゃんと測定したい、という話です。

具体的にどうやって測定するのか？

では具体的にどうやって計測するかという話です。計測対象として、昔からあった指標としては、いわゆるスクラムのベロシティみたいなのもありますが、最近はみんなSaaSを使っていたりとか、あとはGitHubやRedmineなど。APIで活動、アクティビティが取れるプラットフォームをみんなが使っていることもあり、そこの値を使うことは考えられます。

どういうことを計測するかというと、具体的には、例えばデプロイの頻度、変更のリードタイム、変更に対する障害の確率。あとはサービスの復元のための時間が考えられます。

例えば、デプロイ頻度については、SUZURIはHerokuを使っているので、リリース数を取るとよさそう、とか。リードタイムはちょっと難しいですが、例えばプルリクエストのマージ時間はよさそう、とか。

あと、変更障害率はサーバーのアクティビティログなどを組み合わせる。サービス復元時間はあとで説明しますが、インシデント対応用のbotのデータを使うことを考えました。

その上で、これはちょっとデータチームっぽい話ですが、考えたのが、データソースとしてGitHub EnterpriseのAPI、Heroku PlatformのAPI、あとはアプリケーションログ、sssbotという社内のbotのデータでした。それぞれ対応は色で書いています。

これらのデータを、データ基盤がもっているBigfootと呼ばれているデータ共通基盤にExtractして、Loadして、Data Lake的に内部でBigQueryの中にもっておいて、Outputとしては一応グラフにして出すことをやっています。

このBigfootというものが、一応社内データ基盤として、私たちデータ基盤チームが運営しているものになります。

また、可視化周りはいろいろ選択肢がある状況ではありますが、まだ具体的なとこはこれからというところです。ただ、Google Workspaceを使っていることやBigQueryとの相性から、基本的にはデータポータル、いわゆるGoogleのDataStudioを使おうと考えていますが、このあたりの選択肢はいろいろ検討できるかなと思っています。

データの抽出

いろいろデータソースはわかりましたが、ではどうやって抽出するのかの話をします。ここからは、もう少しテクニカルになっていくと思います。

GitHub Enterpriseの活動を抽出するために、専用のコマンドラインツールを書いちゃいました。それが、octxというツールです。

これはRustで書いています。octocrabというライブラリを使うと勝手に非同期になって、やたら速いクライアントができるのでそれを使っています。なおかつRust製のrustlsを使うことで、ワンバイナリで（opensslなどへの）依存なく動くバイナリを作れるということで、かなり取り回しがいいので、Rustを採用しました。

これはCSVを出力することしか行わず、APIにアクセスしてCSVを出す。そこから先はbqコマンドやembulkに投げるというふうに、やることを割り切ってできます。

抽出する対象として、Issue APIを叩いて、Issue、Comment、User、Label、あとIssueEventといって、マージやクローズのイベントも取るようにしています。というのも、プルリクエストやマージというタイミングがIssueEventを使わないとわからないので、急遽対応した感じです。一応、時間を絞っての抽出もできるようになっています。

octxはちょっと注意事項として、github.comのほうにコマンドを投げると、たぶんけっこうレートリミットなどが厳しいと思うので、Enterpriseのユーザー向けのツールという感じで今のところは考えています。そのため、このようなoctxツールを作りました。

あと、サービスの500や503など、ステータスコードも取りたいところがあって。これは一応、minneなどで使っている、rack-bigfootと呼ばれる、RailsのRack Middleware。Railsを知らない方向けにいうと、アクセスごとのフック処理を簡単に記述できる仕組みがあり、それを使ったrack-bigfootを使って、アクセスごとのログをほぼ漏れなく送りつけています。ステータスコードが取れるので、失敗したリクエストを集計することができるというわけです。

Herokuは、これもHerokuのPlatform APIを使えば簡単に取れますが、既存のRust実装がページネーションをサポートしないことに気づいたので（笑）。ほぼフルスクラッチで書いてしまった経緯がありますが、一応Herokuのリリースログも取れます。

あと、障害対応については、実は全社的に障害やインシデントの対応をSlackのBotOpsで行っています。そのため、SUZURIの各種対応もこのbotを使っているという経緯があり、そのbotのバックデータをロードして利用することにしました。このbotもすごくよくできているものなので。よければ、GMOペパボのセキュリティ対策室の資料も見てください。

という感じで、ひととおりロードができました。データが揃ったので、「可視化して運用していくぞ」というところまでもっていきました。というのが、実はこの話の終わりです。

グラフから見る今後の運用方針

運用はこれからですが、一応、簡単な集計結果をちょっとグラフとして出しておこうと思います。例えば、マージとデプロイの回数を週ごとに比較して並べています。このグラフを見る限り、マージに対してデプロイが極端に少ないとか、あるいはデプロイの数がちょっと減っていってるということがあれば、たぶんチームとしてなにかがボトルネックになっている兆候なのかなと思います。直近だと、あまりそういうことはないように思えます。

デプロイの回数も、たぶん月に40回から50回はいっているので、この調子を続けていこうぜ。もしくは、もっと増やせたら増やそうという感じかなと見ています。ただ、こういうのをトラッキングしていくのが大事なんじゃないか、というのはあります。

もう1つが、横軸がデプロイの時間で、縦軸がデプロイ後6時間でのエラー数をプロットした図です。これを見る限り、こういったものをプロットしておくと、例えばデプロイ直後に100回とか1,000回とかエラーが出ているようなデプロイを可視化できるのかなと思いました。これを見る限り、基本わりと優秀といえば優秀かなと思います。これのベースラインを下げるとかができれば、もっといいのかなというところです。

ただこれはちょっとざっくり出しただけで、もっといい可視化の方法があるかもと思うので、データチーム内で揉んでみようと思っています。

今後は他事業部への展開も

という感じで、いろいろデータが揃ったので可視化ができて楽しい、というところもあります。今後はやはりこういった生産性の計測の運用を載せていくのが大事で、データチームだけでなく、もちろんSUZURIの開発チーム、運用チームとも連携して進めたり、データソースを増やしたりをやっていく必要があるかなと思います。

あと、他事業部に当然展開していきたいと思っています。特にデプロイ周りのトラッキングは、もっといい感じに標準化した方法があるとやりやすくなると思うので、そういうのも考えられるといいかと思っています。

プロダクティビティスクワッドと読みますが、今後も、早く進めるための仕組みづくりや工夫を、SUZURIに限らず手伝っていこうと思っています。

我々はデータチームとして、データサイエンスやオペレーションの技術や、基盤チームとしていろいろ整備の部分に特化したノウハウがあるので、それらをどんどん出していくとともに、技術的にはドメインに特化しつつも、コミュニケーションはドメインレス、事業部やそういう組織の壁をまたいでどんどんやっていくことを心がけて、今後もSUZURIの生産性に貢献していければなと思っています。

最後に、SUZURI事業部もそうですが、データ基盤チームとしての採用枠もあるので、興味があればお声がけください。ということでお話は以上です。ありがとうございました。