ここで開発体験（DX: developer experience）はおおむね次の記事で説明されている概念とする。digital transformationではない。
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
2021年になり、担当するWebサービスのDXの改善を任務とするチームに所属しはじめた。こういうチームができるぐらいなので、開発体験を悪化させるという感覚を開発者に与える課題はいくつかわかっている。それらを一つ一つ解決していけば、改善業務をある程度は進められそうだと考えてはいた。一方で、あくまで各開発者の感覚に依存して課題を把握していることが多いので*1どれぐらいよく／悪くなっているかはわかりにくく、改善がどの程度Webサービスのビジネスそのものに影響するのかというのもぼんやりとしていた。
こういう不安感はDXの改善についての体系的な知識に疎かったのにも原因があるだろうと思い、そのようなテーマに関連しそうな書籍や記事を読んでみた。
わかったこと
ソフトウェア開発に科学を持ち込むという考えが大事なことがわかった。といっても難しい話ではなく、バリューストリームのうち、開発者が大きく関わる部分（つまりDXが効果を発揮する部分）に測定可能なメトリクス
- リードタイム
- デプロイ頻度
- MTTR (Mean Time To Repair)
- 変更失敗率
があり、上記のメトリクスを参考にしてDXの改善をめざすことで、結果的にバリューストリームの先にいる顧客がサービスで価値を得られるまでの時間を短くできるということだった。これは市場におけるサービスの競争力が上がることにつながる。さらに、開発者が効率的に開発できる方法も突き詰めていくことになるので、結果として障害発生率の低下や燃え尽き症候群の防止にも効果がある。
読んだリソース
Maximizing Developer Effectiveness
2021年に入ってDXの改善を担当するチームに入ってからTwitterのタイムラインを眺めていたときに、タイミングよくMartin Flower氏のツイートで知った記事。Fowler氏のWebサイトに載っているThoughtWorksのメンバーTim Cochran氏による記事。
開発効率の最大化におけるマイクロフィードバックループの重要性について説いている。例えば、マイクロフィードバックループの一例として、実装中のコードのテストを手元で実行して結果を見たいとする。このテストの実行速度が数十秒遅いだけでも、手元でのテストは1日に何度も実行することがあるので、塵も積もれば山となり開発者の効率は長期的にかなり下がってしまう。しかも、そのようなマイクロフィードバックループの劣化は気づきにくいので、そのような問題を解決していくことが、より上位のメトリクスの改善のために重要だという。
他にも、Spotifyが技術情報ポータルのシステムを自作し、そこにサービスカタログなどを置くことで、情報を探す時間を削減している事例が紹介されている*2。
この記事で次に紹介する"Accelerate"について言及されていたので、次はそれを読むことにした。
Accelerate
書籍。邦題は『LeanとDevOpsの科学』。
この本はDevOps界隈では有名な本のよう。その目的として、統計的に有意な方法でパフォーマンスの改善を促すケイパビリティ*3を特定・理解する方法を確立すると述べられている。ソフトウェアのデリバリー速度を改善するには何が必要かを先に述べてから、その科学的な検証プロセスを具体的に説明した本。なので、後半は統計学や計量心理学の話がかなり出てくる。
要点は、上述したケイパビリティを表すメトリクスとしてリードタイム、デプロイ頻度、MTTR、変更失敗率を改善すれば高速なデリバリーが可能であることを特定したので、これを強化していってください、という内容。それぞれのメトリクスの詳細は次のとおり:
- リードタイム
- コードのコミットから本番稼働までの所要時間
- デプロイ頻度
- バッチサイズ（一度にやる作業の量）を減らすとサイクルタイム短縮／変動の低減、高速なフィードバックの取得などメリットがあるが、バッチサイズの測定が難しいのでデプロイ頻度で考える
- MTTR
- パフォーマンスの高い組織が安定性を犠牲にしているかどうか調べたい
- サービスをやっていたら絶対に失敗するので、サービス停止や機能障害の復旧速度をモニタリングする
- 変更失敗率
- デプロイ後になんらかの修正が必要だった場合の比率
また、「デリバリ速度とシステム安定性／品質はトレードオフである」という言説はハイパフォーマーには当てはまらないことがわかった、ということも述べられており、重要な点だと思う。他には、ソフトウェアがビジネスそのものになりつつあるなか、ソフトウェアデリバリーの速度を改善すると組織の業績も向上するという結果が出ており、ソフトウェア開発能力を会社の中核として据えるべき根拠と言えるという。
著者の一人Forsgren博士は現在GitHubのVP, Research & Strategyに就いている。この本で紹介されている上述のメトリクスを測定する機能がGitHubのロードマップにも入っている。実装されるのが楽しみ。
Insights: Engineering Leader and Organizational DORA Reports · Issue #127 · github/roadmap
Forsgren博士は最近だとコロナ禍でのリモートワーク環境における開発者の生産性の分析記事を書いていた。
The DevOps Handbook
Accelerateの参考文献からたどって読んだ書籍。邦題は『The DevOps ハンドブック 理論・原則・実践のすべて』。
The DevOpsシリーズはいくつか本があって、これは2作目らしい。1作目はDevOpsをテーマにした小説っぽい感じ"The Phoenix Project"*4だがこちらは未読。
DevOpsは2009年から始まったムーブメントで、私はその当時一介の学生だったので、業界のなかでそのムーブメントを体験したわけではないが、そのときに出てきた数々のプラクティスのうちいくつかは実際にいまも取り組んでいるものであった。しかし、この本で説明されているように
- バリューストリームのフローを速くする
- カンバン、アンドン、WIP制限、独力でバリューストリームを完遂できる職種横断（devとops）で市場指向な組織編成、デプロイパイプライン、自動テスト、トランクベース開発
- バリューストリームの末端から先頭へフィードバックが回るようにする
- 本番環境やデプロイパイプラインからのメトリクス収集、問題発生時にチームですぐに復旧に取り組みMTTRの短縮、デベロッパーのオンコール参加、コードレビュー依頼時のバッチサイズの小ささの意識
- バリューストリームの途中でも細かくフィードバックが得られるようにする
- 一部門の発見を共有リポジトリなどを通じて全社に広める、セキュリティや品質に関するメトリクスをバリューストリームの前段階へ、技術的に社内統制の課題を解決することでDevOpsと統一
という三つの観点でそれぞれのプラクティスが存在している、という背景まで踏み込んで考えたことはなかった。背景を含めて体系的に説明されていて、それなりに長い本だが考えが整理されて役に立った。あと、このあたりの話はトヨタ生産方式に端を発するリーン運動の話も多く出てくるので、そちらに関するテーマの本も読んでみたいところ。
Bliki
Bliki*5はMartin Fowler氏のWebサイトで公開されているソフトウェア開発プラクティスのシリーズ記事…という認識で合っているのだろうか*6。
最近公開されていた記事2件がAccelerateやDevOps Handbookでの内容とも関連していると思ったので読んだ。
Pull Request
GitHubやGitLabが備えるpull request/merge request（以降"PR"とする）という機能はソフトウェア開発に欠かせないものとなっているが、PRをデフォルトと思い込んでいないか？ということを問うている記事のように感じた。主に次のようなことが書かれている。
- 本来の意味での継続的インテグレーション、つまりできるだけトランクベースで開発するためにPRを使うなら、十分に小さいPRにしよう
- 毎日、個人がメインラインに1回は統合できるようにチームとしてPRに反応していこう
- PRだけがコードレビューの場ではないことを思い出そう
PRだけがコードレビューの場ではないという点については、例えばペアプログラミングでナビゲータ側が継続的にコードをレビューすることや、refinement code reviewという手法について言及している。refinement code reviewは次で説明する。
Refinement Code Review
おおまかな内容としては次のとおり。
- ソフトウェアは建築で例えられてきたが、どちらかというと都市計画ではないか
- by Erik Dörnenburg
- ソフトウェアの価値に対する理解が深まるにつれて変化し続ける
- 例えば開発中に一見してよくわからないコードを理解したら、その理解をコードに反映させる責任がある
- by Ward Cunningham
- あとの人が困らない
- コードを読むたびにコードレビューが発動するようなものである
- PRでのコードレビューだけでは、PRで入れる変更が既存コードベースで今後どのような状態になっていくかを見逃してしまう
これができればメリットは多そうと思うが、既存の開発フローにどう組み込めそうかについては、すぐにいい解は思いつかない…。このプラクティスにはテストコード、継続的インテグレーション、リファクタリング、（弱い）コードの所有権という4点が必要とのこと。
所感
これまでコードをどう書くかということばかり考えていて、メタな視点でソフトウェア開発を捉えることはあまりしてこなかったが、いろいろなリソースを読んで少し慣れてきた。"Accelerate"ですら、まだまだ消化し切れていないところがあるが、ほかにも『継続的デリバリー』なども読んでみようと思う。
あと、いろいろ読んだ結果、どうやるのがよしとされているかはなんとなくわかったが、それが自分の頭の中にしかないので、理想像を描いてチームメンバーに見てもらったり、一緒に実践していくなどの行動を起こす必要があると常々感じている。
*1:個人の感想
*2:Backstage Service Catalog and Developer Platform · An open platform for building developer portals
*3:組織の保持する能力
*4:邦題が『The DevOps 逆転だ!究極の継続的デリバリー』…
*5:本来はWiki機能をあわせ持ったブログのことを指すようだが、少なくともFowler氏のサイトではそのような機能はなさそう
