NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話

こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。

今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。

CTO最初のミッション

NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。

前任CTOの杉浦さん(今はグループ内でアメリカでの新規サービスの立ち上げをしています)からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅

結論から先に書くと、1年で大幅改善を達成することができました!(左が2020年末、右が2019年末)

f:id:edvakf:20210128185639j:plain
2019と2020のDX Criteria比較

DX Criteriaについて

日本CTO協会の発行しているDX Criteriaについて簡単に紹介します。

社会のありとあらゆる仕組みがソフトウェアで記述される変化が起こっていますが、我々ソフトウェアエンジニアは、2001年の『アジャイルソフトウェア宣言』に代表されるように20年以上もソフトウェア開発のベストプラクティスを追求してきました。そんなベストプラクティス集を、テクノロジーの面だけでなく組織文化やデザインなどの観点からも網羅的にまとめたのがDX Criteriaです。ソフトウェアエンジニアが当たり前にやってきたことを当たり前に取り入れる、つまりDX = Developer eXperienceを高めることが組織のDX = Digital Transformationに直結しているという意味が込められています。

DX Criteriaの発行に先んじて2018年に『LeanとDevOpsの科学』という良書が出版されました。僕自身も多大な影響を受けましたし、DX Criteriaからも参考文献として多く参照されています。入社前から『LeanとDevOpsの科学』を社内で啓蒙するのがベストだと確信し、メンバーに勧めていました。

「デプロイ回数」を定点観測

入社してすぐにやったことは、デプロイ回数の計測でした。

『LeanとDevOpsの科学』によると、収益性や市場占有率の高い「ハイパフォーマンスな企業」ほど、より高速に開発して頻繁にデプロイし、それでいて品質も下がらないそうです。そして、デプロイ回数はどんな組織であっても常に増やすことができます。数ヶ月に1回しかデプロイしない組織もあれば、1日に何十回もデプロイする組織もあり、その差は指数関数的です。そのため、システムのことを何も知らないで入社したばかりのCTOが「デプロイ回数を3倍に増やします」と言ってもまあ不可能な目標ではないだろうと楽観視していました。😉

早めに指標を決めて定点観測を開始するべきと考えていたので、右も左も分かっていなかった時でもすぐに計測できたのも良かったところです。また、入社から一貫して「デプロイ回数3倍」を言い続けたことで、チームのタスクが明快になり動きやすくなったと自負しています。

デプロイ回数ではなくタスク消化数やストーリーポイントで測るべきという意見もありますが、すぐに計測できて一貫して定点観測できるデプロイ回数で十分だと思っています。僕の持論としては、どのような指標を選んだとしても、「開発の健全性」を表す指標であれば相関していると思っています。

やってきたチャレンジ

まず最初にやったことは、定点観測指標の整備でした。特に、デプロイ回数とエラーの数をダッシュボード化して週次で確認するようにしました。

『LeanとDevOpsの科学』では開発効率に関する指標として、デプロイ回数と、コードがデプロイされるまでのリードタイムが、品質指標として、デプロイを切り戻した割合や、障害から復旧にかかる時間なども挙げられています。これらは一部のリポジトリについては計測しましたが、全リポジトリで統一的に計測するのが難しかったのと、週ごとにバラつきが大きくてあまり参考になりませんでした。

品質指標において重要なことは、リリースを急ぐあまり品質を疎かにする罠に陥らないということです。そこが担保できていれば指標は何でも良いと思っています。我々の場合、一番重視したのはエラー数です。エラーの数が増えないように意識できている組織であれば、品質を疎かにすることは無いと思います。

チームごとに担当箇所のエラーの数を毎週定点観測し、増加傾向にある場合は改善を促していました。チームによってはDebug Fridayなどを始めて自発的にエラーが増えないような取り組みを進めてくれました。

その他にも、セキュリティ観点でリスクアセスメントの自動化をしたり、スマホアプリのCrash Free Session率が下がったらPagerDutyに自動連携されるようにしたり、お問い合わせ報告されたバグの大きさや頻度を定点観測するようにしました。このあたりを整えるのにはそれなりに時間も手間もかかります。最初はデプロイ回数を増やすことだけを考えれば良いと思っていたのですが、振り返ってみると、品質指標が下がらないようにデプロイ回数を増やすというバランスを取りながらの挑戦だったのは大きな学びです。

ここまでやれば、あとはひたすらデプロイエンジニアリングです。今では信じられないことですが、僕が入社した1年前には「cronの実行中はデプロイできない」とか、「プッシュ通知の前後15分はデプロイを避ける」のようなルールがありました。そのような制約を一つ一つ解決し、誰もがデプロイで待たない・困らないようにしていくエンジニアリングです。ここは技術的にも非常に楽しい部分ですが、詳細は別のブログ記事に任せます。

1年前は1日に数時間のデプロイチャンスしかなく、1回のデプロイに40分ほどかかっていましたが、今ではいつでも誰でもChatOpsでデプロイできて、5分で作業完了です。デプロイ作業を開始してから速報プッシュ通知に譲ったりして、作業が終わったのが結局2時間後だったという辛い思い出が過去のものになって本当に良かったです。

1年経ってみて

1年で開発者一人あたりのデプロイ回数が定常的に2倍、多い週で3倍以上になりました。また、エラー数などの品質指標についてもSLOの範囲に収まっています。

元々DX Criteriaを上げるためにデプロイ回数向上プロジェクトに取り組んだことでしたが、これについても当初の目標を大幅達成していました!

DX Criteriaを上げるというミッションに対して、デプロイ回数をKPIとしてデプロイエンジニアリングに取り組むことは、僕の中では確証が持てていたものの、大外れする可能性もありました。そうなっては入社1年目のCTOとしては面目が保てません。ここでも意識したのは『LeanとDevOpsの科学』でした。うろ覚えですが、「まずは形から入れば組織文化は付いてくる」のようなことが書いてありましたので、迷わずにデプロイエンジニアリングに取り組んで良かったです。

最後に今後のことを書いて締めくくります。

組織としてDX Criteriaを上げることに取り組み、達成できたという自信が付きました。今後も同様に、定点観測指標を決めてモニタリングすることと、ベストプラクティスを取り入れていけば結果は付いてくるという考え方でやっていきます。デプロイ回数に関しては、今後も毎年倍々に増やしていくことを目指しています。どれだけ上げてもさらに倍を目指せる面白い性質を持った指標だと思っていますので。

今から1年前の我々のシステムのことを考えると、もう遠い過去のことのように思えます。しかし、当時はここまで到達できるなんて夢物語のようでした。今後も同じように「途方もなく彼方に見えたとしても、1年という時間をかけて地道に取り組めば案外到達できる」という考え方で着実に歩んでいくつもりです。

© Uzabase, Inc. All rights reserved.