「開発生産性の現在地を開発生産性の歴史と開発生産性Conference2024から振り返る」というタイトルでブログ記事を投稿しました。
こちらの記事は、2019年に「繰り返し開発を可能にするためのプロセスとしてのアジャイル」と「繰り返し作業のソフトウェア化」の２軸からアジャイル開発の歴史をまとめた下記の論文の続編であり、
品質が「1950年代の工業製品の不良管理」から、「現代のITサービス開発生産性」へと変わってきた変遷を振り返った上で、
開発生産性Conference2024での最新の開発生産性の議論についてまとめています。
ぜひご一読ください！
今年は自分の個人ブログではなく、食べログTech Blogにアドベントカレンダー記事を書きました。食べログのSETチームで経験したFlakyテストの事例をもとに、テスト自動化の分散システム設計について解説しています。
第18回Ques「スタートアップと品質 ~プロダクトの成長に伴う品質活動~」に私の所属企業から登壇します！
サービスがまだスタートアップだった時代から現在にかけての品質活動の変遷や、今のテスト自動化の取り組みについてお話しする予定で、6年前に書いたこちらのアドベントカレンダー記事の具体的な事例といった内容になるのではないかなと思います。
ご興味のある方是非ご参加ください！
Developer Productivityやテスト自動化についての勉強会を今月２件開催します。
test-engineers-meetup.connpass.com
ここ３年ほど外部勉強会にあまり参加できてなかったのですが、今年は色々仕掛けていこうと計画している第一弾です。
Developer Productivityやテスト自動化にご興味のある方、ぜひご参加ください！
こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity（開発生産性）が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。
私の所属する株式会社カカクコムの食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]！このブログエントリでは、まず ソフトウェア開発におけるDeveloper Productivity Engineeringの歴史 についてお話しした後、食べログでの取り組み についてご紹介します。
古くは"人月の神話"や"銀の弾などない"などの1970年代まで、ソフトウェアのDeveloper Productivity Engineeringについての議論は遡れます[5][6]。人月の神話では
遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
という、ソフトウェア開発の進捗はプロジェクト参加人数に対してスケールしないというブルックの法則を紹介しており、以前からソフトウェア開発の生産性については大きな課題感があったことが分かります。
近年では、職場環境がDeveloper Productivity Engineeringに与える影響についての論文 がマイクロソフトから発表されたり、Netflixなどのウェブ企業が積極的に生産性について発信したりと、 ソフトウェア開発業界ではDeveloper Productivity Engineeringが話題 となっています[2][3]。
近年話題のDeveloper Productivityですが、その源流は意外にも日本の製造業にあります[7]。日本の製造業では1970年代、品質と生産性を向上するための様々なプラクティスが提唱、実践されました。その中でも特に、自働化とJust In Time (JIS)による「徹底したムダの排除」を柱とするトヨタ生産方式(TPS)と、統計的な品質分析手法などを柱とするTQM/QCサークルは、日本で製造業の生産性を向上させるだけでなく、海外へとその考え方が輸出されました[8][9]。
アジャイルプラクティスの一つであるスクラムもTPSから影響を受けた手法の一つです[10]。スクラムではプロダクトバックログやスプリントなどを通し、ソフトウェア開発プロジェクトを繰り返し可能なプロセスとして管理します。繰り返しプロセスの中で、スコープを分割し少しずつ開発することで、少しずつ完成される、動くソフトウェアから受け取るフィードバックを元にソフトウェア品質を改善しながら継続的に開発します。また、ふりかえりなどを実施しプロセスの問題点や改善点などのフィードバックを定期的に得ることで、継続的に繰り返しプロセス自体の改善も実施できるようになります。
継続的デリバリー、DevOpsではアジャイルの繰り返しプロセスに含まれる様々な手作業を自動化することによって、フィードバックをさらに素早く頻繁に獲得できるようにしていきます[10]。例えばパイプラインや受け入れテストを自動化することで、テストを素早く高頻度で実行できるようになり、テストから設計への品質のフィードバックを素早く回せるようになります。また、クラウドやInfrastructure as Code (IaC)などを利用しデプロイを自動化することで、リリースを短縮しエンドユーザーからのフィードバック獲得も素早く実施できるようになります。
自動化によってDeveloper Productivityを改善できる手作業を分析、特定するためにはバリューストリームマッピングを活用します[11]。チームの垣根を越えて関係者で集まり、開発サイクルの各工程の作業を洗い出し「7つのムダ」の観点で分析することで、自動化によって効率的に削減可能な作業を特定します。
このように、アジャイルからDevOpsへと発展してきたソフトウェア開発の流れの中には「 繰り返し開発の中でフィードバックループを回すことで品質を継続的に改善する 」という思想があります。この思想を達成するため、スクラムなどのプラクティスによってプロセスを繰り返し可能なものとして管理し、バリューストリームマッピングなどによって非効率な手作業を特定し、それらの手作業をDevOpsの自動化技術によって素早く高頻度でフィードバックを獲得できるように改善していきます。
近年のDeveloper Productivity Engineeringの流れはこのアジャイル・DevOpsのフィードバックによる改善活動を、 リーンやその他の組織改善の手法によってさらに発展させていくもの です[7]。
"LeanとDevOpsの科学"や同著のレポートである"State of DevOps 2021"では、リーンマネージメントにもとづいた開発組織のパフォーマンス計測について紹介されています[12][13]。これらの著書では、開発組織の重要なパフォーマンスメトリクスとして
の4つが紹介されています。これらのメトリクスはそれぞれ[]内にある通り、フィードバックの「素早さ」または「信頼性」を表しています。ちなみにそれぞれのメトリクスの横の数字は、DevOps実践者を「エリート」「上級者」「中級者」「初級者」の4つにカテゴライズした際の、「エリート」の平均値であり、「初級者」に比べて数倍良い数字になっているとのことです。みなさまのチームはどのカテゴリに属していますでしょうか？
ちなみに2021年のYahoo! JapanさんのAdvent Calendarでも同様の枠組みを用いたDeveloper Productivityの分析が紹介されています[14]。ブログ内では言及されてませんが、分析結果を見る限り（Yahoo!さんのコンテキストでは）下記のDevOpsのプラクティスがDeveloper Productivityと相関が高そうですね。
Gradle社はこういったソフトウェア開発プロセスの改善活動を"Developer Productivity Engineering"として定義し、白書にまとめています[15]。こちらの白書ではDeveloper Productivity Engineeringは以下のように定義されています。
Developer Productivity Engineering is a discipline of using data to improve the developer experience and essential software development processes to ensure a high degree of automation, fast feedback cycles, and reliable feedback.
日本語訳：Developer Productivity Engineeringとは開発者体験とソフトウェア開発プロセスを改善するためにデータを使用する手法です。高度な自動化、素早いフィードバックと信頼できるフィードバックを作り上げます。
つまり、Developer ProductivityとはDevOpsの高度な自動化と、 リーンやその他の組織改善のためのデータ分析 が融合した手法です。繰り返しプロセスのデータ（メトリクス）を取得することで、フィードバックの素早さと信頼性を可視化し、ボトルネックを見つけて継続的に改善していきます。DevOpsでは、ウォーターフォールやアジャイルよりも繰り返しの開発プロセスの期間が短くなります。そのため、プロセスのデータも小刻みかつ頻繁に取得できるようになるため、様々なデータ分析手法が適用しやすくなるのが嬉しいところです。
この白書の中では、改善すべき「素早いけれども信頼できない」フィードバックの例として「自動テストのFlaky Test (毎回成功、失敗と異なる結果を返すテスト)」が紹介されています。手作業のテストを自動化することによって、テストからフィードバックを獲得するまでの期間を短縮できますが、一方でテストが毎回異なる結果を返すFlaky testが増えるとテスト結果が信用できなくなり、開発現場に余計なノイズを生んでしまいます。すべてのFlakyテストを撲滅することは難しいかもしれませんが、自動テストのFlaky率を計測しながらコントロールすることで信頼できないフィードバックを軽減することができます。
ここまでソフトウェア開発でのDeveloper Productivityについての変遷についてご紹介してきました。ここからは食べログのDeveloper Productivityチームについてご紹介します。食べログでもエンジニアの開発生産性の課題に取り組むDeveloper Productivityチームが2021年に爆誕しました！まずはこのチームのミッションをご紹介します。
食べログのDeveloper Productivityチームのミッションは「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」です。
エンドユーザーの要望をソフトウェアとして開発し価値に変換する開発サイクルの中には、実装やテスト、リリースなどの工程が含まれます。これらの工程では至るところでプロダクトの動作確認や検証が行われており、「デバッグ」「結合テスト」「再発防止策」などが絶え間なく開発チームにフィードバックされています。これらのフィードバックをより「素早く」「リッチ」にしていくことで最高の開発・テスト体験を食べログの中で実現していくことを目指しています。
「最高の開発体験」に対しては「 開発者の影響分析・デバッグにかかる労力を最小化する 」を中・長期目標とし、開発環境や開発ツールなどをモダン化していく計画です。また、「最高のテスト体験」に対しては、「 コード修正後すぐにテストからフィードバックを得られるようにテスト体験を向上する 」を中・長期目標として、テスト自動実行基盤やテストデータ基盤などの構築を行っていきます。
これらの中・長期目標を立てるにあたっては、Developer Productivityチームと開発チームメンバーが一緒になって２ヶ月に渡る課題分析をバリューストリームマッピングにもとづいてワイワイと実施しました。15年以上のサービス開発の歴史を持つ食べログでは、"これだけ歴史があればあちこちにガタが来ている"状態であり、その課題はアーキテクチャや組織文化、開発サイクルと多岐に渡っています[16]。今回の課題分析では、その中でも開発サイクルの課題にフォーカスし、素早くリッチなフィードバック獲得の妨げとなっているボトルネックについて分析しました。
開発サイクルのボトルネックの分析のステップは以下の3つです。
①業界や他社のトレンドの共有では、他社での技術的負債に対する取り組みやマイクロサービス化などの最新技術についてそれぞれワクワクするトピックを持ち寄って共有しました。課題分析、、、となると自分たちの反省点を挙げる辛い作業になってしまうことも多々あると思いますが、食べログのDeveloper Productivityチームが目指しているのは「最高の開発・テスト体験」であり、そこに必要なのは「ワクワク感」です。ですので、まず、自分たちが 「ワクワクできる」開発サイクルってどんなのだろう？ ということについて、他社の事例を参考にしつつ、みんなで共通のイメージを持つようにしました。
②現状の課題の分析はこの課題分析のメインの議論であり、バリューストリームマッピングを使用しています。まずオンラインホワイトボードに開発サイクルの絵を書き、みんなでペタペタと課題を付箋で貼っていきました。次に各工程の課題について原因と解決へのアプローチを深掘りしました。
下記は結合テスト工程での深堀りディスカッションの付箋たちです。「テストデータ準備が大変」「手動テストの実行に時間がかかる」といった課題に対して「手順が煩雑」「種データがわからない」「テストがコードとして管理されてない」「テストがパイプラインに統合されてない」などの付箋が原因として出てきました。 これらの付箋を元に検討したところ、データの準備やテスト実行などのテストに必要なアクションをコード化 していくことで、これらの課題を解決し「コード修正後すぐにテストからフィードバックを得られるようにテスト体験を向上する」を実現できそうなことがわかりました。
③食べログ理想の開発サイクルでは、すべての課題が解決された後の理想的な食べログの開発サイクルについてみんなで絵を描きました。②のステップでは各工程内部の課題の解決にフォーカスしましたが、こちらの③のステップでは開発サイクル全体をどういう風に変えていきたいかを話し合いました。開発サイクル全体で見たときに、サイクルの前半でチーム内外のコミュニケーションを密に行うようにし、サイクルの後半で各工程の自動化できる作業を集めて自動で実行するようにすることで、コミュニケーションと作業の効率化の両方を狙っていくことにしました。
この課題分析を開発チームと一緒に実施できたのは非常に貴重な経験でした。別々のチームとして活動していただけでは気づけない、例えばテストの場合はテスト実行自体だけではなくデータの投入などの準備もめっちゃ大変など、現場のリアルな話が聞けました。開発チームのメンバーも、進行中のプロジェクトなどで忙しい中での参加だったのですが、全部の分析が終わった後で、「開発チームのリアルな声を元にDeveloper Productivityチームの活動方針を決めてもらえて嬉しい」と言ってもらえたのが嬉しかったです。
Developer Productivityチームでは、「最高の開発・テスト体験」を実現するための取り組みを始めています。特に「最高のテスト体験」を実現するために「テストに必要なアクションのコード化」をしていく取り組みについては、
のチームメンバーのアドベントカレンダーの記事の中で紹介していますので是非そちらもご覧になってください[17][18]。
"カバレッジ10%のテスト自動化で7割以上のテスト工数を削減できる！？〜ゆもつよメソッドを使った要求分析〜"は、今後食べログで自動化していくテストのテスト観点について、「ゆもつよメソッド」を使って分析した取り組みです。ゆもつよメソッドを使って「機能やテスト条件」と「過去のテスト実行情報や障害情報」を組み合わせて整理していくことで、 10%の観点の自動化で74%のテスト工数を削減できる ことが分かりました。
また、"フィードバックループを高速に回すためのテスト自動化アーキテクチャを設計した話"では、「素早く信頼性の高いフィードバック」を自動テストによって実現するためのアーキテクチャ設計をご紹介しています。（もちろんチームによって重要となるアーキテクチャの品質特性は様々ですが）食べログでは 「追跡性」「再現性」「スケーラビリティ」が重要そう ということが分かったため、これらの品質を作り込むためのアーキテクチャを設計しました。
実はこれらの取り組みは一つの形で実を結び、 この12月18日に「10%のテスト自動化」を達成 することができました！食べログのDeveloper Productivityチームは今年の10月に発足したばかりであり、まだまだ小さい成果ですが、食べログのDeveloper Productivityを大きく改善していくための確かな一歩を踏み出すことができました。
このアドベントカレンダー記事では、近年話題となっているDeveloper Productivityについての業界の歴史と、食べログでの取り組みについてご紹介しました。日本の製造業での生産性と品質の改善手法が、アジャイル・DevOps開発として世界に普及し、Developer Productivity Engineeringとして発展し、2021年食べログでも本格的に取り入れてソフトウェア開発の生産性改善に取り組むことになりました。
食べログのDeveloper Productivityチームでは、開発サイクルのデバッグや結合テストなどのフィードバックをより素早くリッチにしていくため、開発環境や開発ツールのモダン化やテスト基盤の構築などに取り組んでいます。フィードバックを素早くリッチにしていくことで、食べログの開発プロジェクトで最高の開発体験、テスト体験を得られるようにします。
食べログでは現在、一緒にお仕事をしてくれるSETエンジニアを募集しています。これからもりもり自動化に取り組んで参りますので、ご応募お待ちしております
正式なご応募以外にも、転職活動前の情報収集やランチを交えた情報交換なども大歓迎です。その場合はご応募いただくときに、フリーテキスト記入欄に「カジュアル面談希望」とご記載ください！
