データで振り返るエンジニア組織の生産性向上 〜NewsPicks & PR TIMESの事例、DevOpsの取り組みからデプロイ頻度の計測まで〜
2022年2月4日、ファインディ株式会社が主催するイベント「【NewsPicks×PR TIMES】2021年のエンジニア組織のパフォーマンスを振り返ってみた」がオンラインにて開催されました。
ファインディでは、エンジニア組織支援クラウド「Findy Teams」をリリースし、エンジニア組織の生産性可視化を通じたパフォーマンス最大化支援に取り組んでいます。
「エンジニア組織の生産性」は、計測に大きな手間がかかったり、何をもって生産性が高いとするのかわかりづらかったりと、非常に難しいテーマであると言えます。しかしながら、2022年はエンジニア組織の拡大に舵を切る企業が多く、上記の課題は今後より重要になっていくことが想定されます。
今回ご登壇いただいたのは、株式会社ニューズピックスの高山温さんと、株式会社PR TIMESの金子達哉さん。「Findy Teams」を活用して、2021年の開発組織のパフォーマンスを振り返りつつ、具体的な取り組みの内容や今後の展望についてお話しいただきました。
目次
登壇者プロフィール
株式会社ニューズピックス 高山温さん[@edvakf]
イギリス・カナダで物理を学び、2012年にピクシブ株式会社に入社。同社ではリードエンジニア、新規事業立ち上げ、福岡オフィス立ち上げ、CTOを歴任し、エンジニアリング組織づくりを務める。2020年2月にUzabaseのNewsPicksにおいて執行役員CTOとして入社し、事業の競争力となる重点技術分野として、主に開発生産性、セキュリティ、機械学習分野を担当。2022年からはNewsPicksのFellowとしてデータとアルゴリズム分野を担当。
株式会社PR TIMES 金子達哉さん[@catatsuy]
2021年4月より現職。ピクシブ株式会社・株式会社メルカリにて開発・インフラ両面からサービス運営に携わる。LINE株式会社主催イベントISUCONにてISUCON9予選・ISUCON6本選の運営として出題を担当。著書に「pixivエンジニアが教えるプログラミング入門（星海社新書）（単著）」がある。
登壇者の自己紹介と、本日のアジェンダ
佐藤： 本日は、NewsPicksの高山さんとPR TIMESの金子さんにお越しいただいています。よろしくお願いします。それでは、お二方の自己紹介をお願いします。
高山さん： NewsPicksの高山と申します。NewsPicksには2020年にCTOとして入社しまして、今年からはFellowとしてデータ基盤やアルゴリズム開発のチームを率いております。よろしくお願いします。
金子さん： PR TIMESで執行役員CTOをやっております、金子です。PR TIMESには2021年4月にジョインしたので、もう少しで1年になります。よろしくお願いします。
佐藤： お二方とお話できるのを楽しみにしておりました。本日のパネルディスカッションのアジェンダとしては、まず最初に2021年における開発パフォーマンスを振り返っていただき、生産性に対する考え方について伺っていきたいと思っています。
【NewsPicks】デプロイ回数の先行指標として、平均プルリククローズ時間を注視
佐藤： さっそく1つ目の質問、2021年における開発パフォーマンスの振り返りに移っていきたいと思います。まずこちらがFindy Teamsで出力される、NewsPicksさんの2021年1月から12月のグラフです。
グラフについて簡単にご説明すると、薄い水色の部分が平均プルリク作成数、3本の折れ線グラフが、それぞれ平均プルリククローズ時間、プルリク作成からレビューまでの平均時間、レビュー後クローズまでの平均時間となっています。
この1年間のグラフを見ていただいて、高山さんはどういった印象を持たれましたか？
高山さん： まず前提として、僕はCTOとして2年間、開発生産性まわりのところに重点的に取り組んでいました。そのチームはうまく走り出してきたので他人に譲って、今年はデータまわりのことをやっているのですが、去年取り組んでいたところの話をさせていただきます。
僕たちがFindy Teamsを使い始めたのは、去年の10月頃だったと記憶しています。もともとデプロイの回数を定点観測していて、それを最大化するような施策を打ってきていました。
僕が入社して1年目は、愚直にデプロイエンジニアリングを改善するために、CI/CDまわりを揃えたり、ChatOpsを揃えたりしていました。2年目はコンテナ化をして、NewsPicksはAWSのインフラの上で動いているんですが、ECSに切り替えて、より簡単に開発環境を作れるようになりました。
そうやって、開発者の声を聞きながら毎週のようにPDCAを回してきた後に、Findy Teamsを使い始めて、やってきたことの成果が出ているなという印象を持ちました。
佐藤： グラフを見ると、プルリクのクローズまでの時間が150～300時間くらいだったところから、5月以降は徐々に下がって150時間を切っています。ここに関して、何か取り組まれたことはありましたか？
高山さん： そこについては、正直あまり意識していませんでした。5月に大きく上がっているのは、おそらくゴールデンウィークが影響しているように思います。
ただ、振り返ってみると、レビュワーの数が足りていなかったような気がしますね。7月くらいからはメンバーが増えて、レビューがスムーズに回るようになったんじゃないかと思います。
Findy Teamsで平均プルリククローズ時間が見れるようになったので、去年まで追いかけていたデプロイ回数の先行指標として、今年はこのグラフを下げていこうと開発者たちに伝えています。
佐藤： その後、2022年に入って変わったことはありますか？
高山さん： 毎年、開発者体験や開発生産性まわりの目標を掲げていて、去年はコンテナ化と、開発環境で“待たない・困らない”ことを掲げていました。今年は、自動コードレビューや静的解析まわりであるとか、カバレッジを上げたり、テストを増やしたり、そのあたりを重点的にやっていこうとしています。
佐藤： プルリク作成数でいうと、6月以降に3つほど大きな山がありますが、7月頭や9月半ば、10月後半など、何か特徴的なことはありましたか？
高山さん： 10月後半は大きなリリースがあったのですが、時期的に、お盆やシルバーウィークの影響の可能性もありそうですね。10月後半は大きなリリース前の佳境で、修正するところも多かった実感があるので、それがこうしてグラフで見えるのは、とても使い勝手のいい定点観測だなと感じます。
【PR TIMES】開発スタイルを変更したことで、プルリク作成数が大きく増加
佐藤：
続いて、こちらがPR TIMESさんのグラフになります。4月以降、かなりプルリク数が増えていて、金子さんが入社された影響なのではないかと思うのですが、振り返っていかがでしょうか？
金子さん： 僕が入社したのが4月1日ですね。僕の入社前は、デプロイも週に1回するかどうかくらいで少なく、開発チームには「PR TIMESのソースコードはレガシーだから変更は無理だ」という諦めのようなものがありました。 僕が入社してからは「技術で頑張れば解決できるし、PR TIMESを技術で前に進めることはできるんだ」という話を何度もしました。その結果として少しずつプルリク数が増えていきました。
その後、大きなプルリクを一気にデプロイする運用をやめました。オフィスやVPN経由の時だけ使えて、お客様には見えないエクスペリメンタルな機能を、どんどんメインブランチにマージしていく開発スタイルに切り替えたんです。
それによって、短いスパンでマージしていく開発スタイルが社内で一般的になり、プルリク数が増えました。最近だとデプロイは金曜以外は毎日、しかも複数回行っています。
※PR TIMES開発者ブログ参考記事 本番環境で新機能・旧機能を自由に切り替えたい 1台のサーバーで複数のステージング環境を同時に使えるようにする
グラフ上の5月にある山については、5月1日にPR TIMESの料金プランの変更があり、それを4月末にデプロイしています。これは僕が入社前からあったプロジェクトで、1ヶ月以上かけてずっと開発していたものを、一気にデプロイしているんですね。1ヶ月以上かけているものがあると、これくらい大きくグラフが歪んでしまうことがわかりました。
佐藤： 7月くらいからグラフが右肩上がりで伸びていますが、このあたりで注力して取り組まれていたことはありますか？
金子さん： 僕の入社前から動いていたプロジェクトがだいたい終わって、新しい開発スタイルでデプロイできるようになったタイミングが、そのあたりなのかなと思います。「こうやって開発すればどんどん前に進んでいくんだ」という、メンバーの実感が出てきた時期でもあります。
佐藤： しっかり数値にも反映されているのが、すごく素敵だと思います。12月にかけて、もう一段階上がっているようにも見えますが、こちらも何か印象的な出来事はありましたか？
金子さん： それはあまりよくわかっていません。10月半ばにプルリク作成からレビューまでの平均時間が落ちているのですが、そこは企業ページのリプレイスを行ったタイミングです。
PR TIMESは、ほとんどjQueryで書かれていてレガシーな状況なのですが、今は企業ページだけがReactで、フルスクラッチで書き直されているんです。そのリリース後にあった変化というと、インターン生が入社したことくらいですね。
佐藤： インターン生がものすごく活躍されていたという可能性もありますね。
金子さん： インターン生が一気に4人くらい入ってくれて、稼働時間は少ないですが、頑張ってくれていますね。僕の入社前は「PHPのバージョンアップなんてできない」と言われていたんですけど、インターン生がそれを破壊していくのが、僕はすごい面白くて（笑）。
※PR TIMES開発者ブログ参考記事 インターンでPHPのレガシーコード改善を行いました
佐藤： なるほど。4人入って、1人1つずつでもプルリクを作っていれば、平均の数も徐々に上がっていきますよね。1月頭は平均プルリク数が4～5件だったところから、12月半ばでは15件と、3倍くらいになられていてすごいなと。
プルリクのクローズまでの時間も、5月頃は450時間くらいだったところから、直近は50～150時間くらいに収まっているので、ものすごく効率の良い開発をされている印象を受けました。
数値化されることで、開発生産性が他部署や経営陣にも伝わる
佐藤：
続いての質問に移ります。生産性に対する考え方として、「生産性が数値化されるのは良いことか？」という点について、いかがでしょうか？
高山さん： 数値化されるのは良いことだと思います。経営に関する重要指標が数値化されて、定点観測ができますし、開発生産性はその最たるものかなと思います。
開発生産性に関しては、ソフトウェア産業が始まってから長らく、なんとなくエンジニアの間では思っている理想があるけれども、重要指標として何をどう見ればいいのかわからない、自分たちの開発生産性が良いのか悪いのかわからない、という状況があったと思います。
それが、ここ3～4年でかなり改善されました。『LeanとDevOpsの科学』という良い本が出て、デプロイの頻度やプルリクのマージまでの時間、マージからデプロイされるまでの時間、変更失敗率や平均復旧時間など、見るべき指標のコンセンサスが得られてきたんですね。
感度の高い会社はそれを実践し始めていて、世の中的に「こう見ていけばいいんだ」と盛り上がっている状況だと思うので、開発生産性に関わる者としては、様々なことに取り組みやすい状況になってきていると思います。
金子さん： 僕が入社してから、以前より開発スピードが上がって、デプロイ回数が増えていると実感していましたが、数値化されていませんでした。デプロイ回数が増えたことは、他部署の人たちにもSlackを見ればわかってもらえていたと思いますが、本当に開発生産性が上がっているのかどうかは、ブラックボックスだったんです。
それがFindy Teamsを活用することで初めて可視化されて、他部署の人たちも開発メンバー自身も、ちゃんと開発生産性が上がっていることを実感できて、すごく良かったと思っています。数値化は難しいと思って逃げていた部分もあったので、それがわかりやすく出たことは嬉しかったですし、今後もしっかり見ていきたいと思っています。
佐藤： 開発メンバー自身だけでなく、他部署や経営陣に対してファクトで伝えられることも大きいですね。
高山さん： Findy Teamsのようなツールを使うことによって、自分たちだけが言っているのではなく、「世の中的にも、これを伸ばすことが良いとされていて、我々も前に進んでいるんだ」と、経営陣としてもより自信を持てるようになったと思います。
佐藤： ありがとうございます。続いて、「生産性が良い状態とは？」という質問です。生産性が良い状態として、お二方はどういったところを目指されていますか？
高山さん： 先ほど挙げた『LeanとDevOpsの科学』という本には、開発生産性は企業の収益性や市場占有率にかなり相関関係があり、生産性の高い会社の方が経営的にもよりハイパフォーマンスな会社である、と書かれているんですね。
より速くPDCAが回せて、やろうと思ったことをより速くユーザーさんに届けられることが、経営的にもより良い効果をもたらすことは明らかなので、これからも突き詰めていきたいと思っています。
金子さん： これまでPR TIMSでは、経営陣が「こういう機能が欲しい」と思っているのに、なかなか新機能が出ないという状況が続いていました。
でも、直近はプレスリリースに“いいね”が付けられるようになったり、サムネイル画像に高画質で綺麗な画像が配信されるようになったり、続々と新機能がリリースされています。それによって、ちゃんと開発の生産性を上げて頑張っているんだなと、他の部署からも安心してもらえていると思うんですよね。
そういったところは最近クリアできてきたと思うので、更に開発の効率やスピードを上げていくところに挑んでいきたいと思っています。
※PR TIMES開発者ブログ参考記事 新卒エンジニアがプレスリリース画像の画質改善に取り組んだ話 PR TIMESにいいね♡ボタンを機能追加しました！＆気になる機能が保存になりました
さらにパフォーマンスを高めるために、より根本的な改善へ
佐藤：
続いての質問です。今後もパフォーマンスが高い組織であり続けるために、取り組んでいきたいと考えられていることはありますか？
金子さん：
PR TIMESの開発パフォーマンスは、かなり上がってきたと思うのですが、最近はFindy Teamsを見ていても、やや頭打ち気味になってきました。僕としては、根性で解決できるのはここまでで、これ以上は根本的なところを改善しなければならないと考えています。
具体的に取り組んでいることは、PHPのバージョンアップとQAの自動化。それから、開発環境のデータに不備があったりするので、それを改善して開発しやすい環境を作って、もっとQAの戻し自体を少なくするとかですね。
あとは、今ユニットテストもほとんどない状態なので、しっかりと作ってデグレを減らしていくといったことに取り組んで、パフォーマンスが出せていない根本的な部分を解決していこうとしています。
高山さん： 僕が入社から2年取り組んできたチームは、今年から別の人に任せているのですが、僕がそのチームに度々伝えていることがあります。それは「ハイパフォーマンスな会社はデプロイ回数やプルリクのマージまでの時間が、指数関数的に良くなっていくことが世の中的な数字として出ているのだから、我々に目指せない理由はない」ということです。
例えば、毎年デプロイ数を倍にしていけるはずだ、という話をしています。そうしたらチームメンバーから、プルリクのマージまでにかかる時間を減らすには、人が見る時にはマージできる状態になっていた方がいいので、自動コードレビューや静的解析を充実させようという話が出てきて、「たしかに」と僕も膝を打ちました。
佐藤： 僕も去年、プルリクが200行を超えていると通知してくれる「Danger」というツールをメンバーが入れているのを見て、便利だなと思いました。本当に人が指摘すべき大事なところに、しっかりフォーカスできるのは良いことですよね。
【質疑応答】プルリクやレビューは月何件？ パフォーマンスの良し悪しの判断基準は？
佐藤： ここで、参加者の方からのご質問にも回答していければと思います。「エンジニアが作成するプルリクは月に何件くらいでしょうか？ また、レビュアーは月に何件くらいレビューしていますか？ 指標として増加させていくと、対応時間も増えそうです」とのことですが、いかがでしょうか？
高山さん： チームによって結構バラバラです。若手の多いチームだと、テックリードがずっとレビューしている状況になりやすいです。そういうレビューが滞っていそう、プルリクのクローズまでの時間が増えているところは如実に可視化されるので、人を増やした方がいいんじゃないかと話したりはしています。
Findy Teamsで見ている限り、テックリードの人たちは自分でプルリクを作るよりも、レビューを多くしている傾向がわかります。
金子さん： あまり追いかけていませんでしたが、Findy Teamsを見ると、誰が何件作っているかわかるので、それを見ると多い人だと1日1～2個くらい作っています。
PR TIMESは新卒1～2年目のメンバーやインターン生が多いので、レビューがシニアの人に偏っている傾向があります。これは将来的には分散したいですが、直近はある程度偏っていてもいいかなと思っています。
週によっては、僕のレビュー数が1番多かったりしますね。僕が仕様を考えてお願いしているタスクもあるので、そういうものは僕がレビューすることが多いです。
佐藤： 続いて、「パフォーマンスを定量的に評価していくにあたって、何をもって良い・悪いを判断していますか？ すべてのチーム平均から判断しているのでしょうか？」というご質問をいただいています。
高山さん： これは明確で、他チームや他社との比較はまったくしていません。過去の自分、あるいは自チームとの比較がすべてです。評価というのも考え方次第ですが、給料に反映する意味での評価というより、改善の種を見つけるため定量的に評価をしている感じですね。
金子さん： 具体的な例として、ある時期にほぼ何もできない状況に陥ってしまったチームがあったのですが、そのチームの開発リーダーがすごく頑張って復活させたことがありました。そういった状況も、プルリク作成数などFindy Teamsの数値で見えるようになったので、今後も見ていきたいと思っています。
佐藤： チームを横で比較すると、集まっているメンバーの経験年数が全然違ったりします。なので、過去の同じチームと比べてどう伸びているのか、過去の自分と比べてどう成長しているのかにフォーカスしないと、隣の芝が青くて仕方がなくなってしまうんですよね。
また、例えばプルリクを何件作るという目標を立てたとして、ある人が別の対応を頑張っていて全然プルリクを作れなかったけれども、しっかり組織に貢献していたという場合もあります。なので、数値がすべてなのではなく、そこからどう読み解くかが大事だと考えていますね。
今後の取り組みを加速するために、求めるエンジニア像は？
佐藤： それでは最後の質問になります。今後の取り組みを加速させるために、ジョインしてほしいと考えているエンジニア像について教えてください。
金子さん： PR TIMESというサービスは、いろんな会社さんに使っていただいている影響の大きなサービスなので、こうしたサービスを技術で前に進めたいと思っている人です。
先ほどもお話したように、フロントエンドがjQuery中心だったり、PHPのバージョンが古かったりするので、それをReactに置き換えて機能追加していくとか、PHPをバージョンアップして、どんどん開発スピードを出せるようにしていくとか。そうやって「技術でPR TIMESを伸ばしていくんだ」という人に、ぜひ来ていただきたいです。
高山さん： 開発生産性や開発者体験に注力して取り組んできたことによって、今はお客さんに価値を届けることがより大事になってきているフェーズだと思っています。ですので、開発生産性を高める開発者のためのエンジニアリングをする人も募集していますが、サービスをもっと良くしていくためのエンジニアも募集しています。
いろんな志向性を持った人が活躍できる会社だと思います。カジュアル面談を実施していますので、僕と直接話したい方はMeetyで気軽に声を掛けてください。
金子さん： 僕もMeetyをやっていますので、聞きたいことがあればぜひお声掛けください。
佐藤： もっとお話を伺いたいところですが、終了のお時間となりました。高山さん、金子さん、本日はありがとうございました！
■株式会社ニューズピックス
■株式会社PR TIMES
