「推測するな、計測せよ」の時代に突入
石垣氏の講演は、開発生産性に関する主要なレポートの紹介から始まった。石垣氏は「State of DevOps Report」と「Developer Productivity Engineering（DPE）」を挙げ、メトリクスや時流については「この2つを抑えておけば大丈夫」としている。
特にメトリクスのサービスの発展は目覚ましく、ログ収集やCI/CDにおいてはGithubでソースコード管理を行うことで、プルリクエストまでの時間やデプロイ回数の計測が可能になった。コード品質やチームパフォーマンスに貢献するツールも増えており、生産性に関するさまざまな要素が数字として可視化されている。
こうした状況を背景に、"推測するな、計測せよ"というワードは現実的な位置まで来た。「開発以外の部分も含めたソフトウェアライフサイクルの計測が現実的なラインが出てきている」と石垣氏は実感を語る。パイプラインも充実し、現在ではDMMに所属するエンジニア約1200名の生産性データが集積されたリポジトリと連携することで、組織全体の生産性を向上させている。
ここでいう開発生産性の範囲は、（1）組み込みやミドルウェアを含まないソフトウェアであること、（2）DevOps周辺の生産性であること、の2点だ。Four Keysについての議論はDevOpsがその中心となるが、歴史をたどると2001年ごろにアジャイルや後を追うようにクラウドの概念が出てきて以降、「小さいチームでオーナーシップを持ちながら適切なプロダクトサイズで改善サイクルを回していく」という流れが起きたことが、今日まで続く大きな技術革新の源泉だという。
2009年ごろから「DevOps」といったDev（開発）とOps（運用）が対立せずエコシステムで連携しながら、1日10回のデプロイが実現できる時代になったというメッセージから始まり、その後マイクロサービスの考え方の浸透、NetflixのFull Cycle Developersという1つのチームで設計からオペレーションまでを実行する流れができました。これが昨今のDeveloper Productivity Engineering（DPE）に繋がってきます。
このように歴史を振り返ったうえで、石垣氏は開発生産性にまつわる議論を順に確認する。具体的には、（1）生産性の測りづらさ、（2）Four Keysの指標を「改善」したことによる悪影響、（3）DevOpsの生産性＝組織の生産性「ではない」ために生じる、「何をもって生産性とするか」という議論だ。
（1）生産性の測りづらさについて、たとえば以前では、ソースコードの行数をもとに開発生産性を測るような時代もあった。しかしこの手法には言語の違いやソースコードの効率といった要素が含まれておらず、適切な指標といえないのは周知の事実だ。
（2）Four Keysの指標を「改善」したことによる悪影響については、一例として、デプロイ回数を増やしてインターフェースを頻繁に変更するようなケースが挙げられる。このような取り組みを続けていると、ユーザーの使い心地は損なわれ、コミュニケーションコストが上がってしまう。
最もクリティカルな議論は、（3）「何をもって生産性とするか」だ。開発生産性を語るにあたり、DevOpsの生産性と組織全体の生産性は同一視されがちだ。しかし実際には、デプロイ開発のサイクルタイムと組織が仮説を立ててそれをリリースするまでのリードタイムは一致しないことも多く、「何を、誰のために計測すべきかを見極めなければ無意味な指標になってしまう」と石垣氏は警鐘を鳴らす。
こうした議論のもと、石垣氏は「何を計測するべきかについては、デプロイ回数などのアウトプット量ではなく、時間単位でのプロセスの推移を見るべき」と語る。また、誰のために計測するかという部分では、「『プルリクからマージまでを高速化したい』といったチーム内部での課題なのか、『開発組織のかける予算が適切か』『意図したタイミングでリリースされないことへの疑問による生産性への問い』といったチーム外への働きかけなのか、目的意識の明確化が不可欠だ」とする。
さらには、Four Keysをはじめとする開発生産性の計測に注力しすぎないことも重要なポイントだという。データ化はあくまで課題解決のための手段に過ぎないため、「メトリクスを取るのにリソースをかけすぎず、手を動かして改善するという課題解決に時間をかけるべき」というのが、上記の議論に対する石垣氏の答えだ。
そしてDevOpsの生産性と組織の生産性について、DMMではこれらが一致しているかを判断するため、プロダクト開発時に現状把握と将来像の明確化を目的としたプロセス図「バリューストリーム」を作成することが多い。
石垣氏はさらに、「変更承認の合理化」について話を進める。諸々の議論があるとはいえ、ソフトウェア開発においてスピード感を持った開発が競争優位性を高めることは一定の合意を得ている。しかしながら実際の現場においては、経営層や事業責任者の承認を得るまでに時間がかかり、「開発は2日で終わったのに、リリースまでに2週間かかる」ような状況もざらだ。原因として考えられるのは社内での「承認」に関する課題が多く存在する。こうした状況を改善しなければ、いくらDevOpsが生産性を高めようとも組織に与えるインパクトは限定的になる。
そこで改善の指針となるのが、「変更承認の合理化」4か条だ。「手動による変更承認なしで実稼働環境にプロモートできるか」「運用上の変更は、展開または実装前に外部機関の承認を受ける必要があるか」……これらのポイントを先ほどのバリューストリームと突き合わせながら自己点検することで、DevOpsと組織の生産性をイコールに近づけていくのだ。
