2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
SUZURIチームのパフォーマンスをfour keysで可視化してみる話(全1記事)
リンクをコピー
記事をブックマーク
近藤宇智朗氏(以下、近藤):では、お願いします。「生産性を可視化したい」と題して発表します。ということで、自己紹介します。私は技術部に所属している、近藤といいます。ふだん、インターネットなどでは“うづら”と呼ばれているので、お気軽にうづらと呼んでください。現在、技術基盤チーム兼データ基盤チームという感じで働いていて、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事業部もそうですが、データ基盤チームとしての採用枠もあるので、興味があればお声がけください。ということでお話は以上です。ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには