どうも、ランサーズでProductivity Teamをやっているいさな(@isanasan_)です。
この記事は、Lancers（ランサーズ） Advent Calendar 2022 の10日目の記事であり、開発生産性 Advent Calendar 2022の10日目の記事です。
昨日は@isanasan_さんによるエンジニアである僕が自炊をするときに意識していることと
@s977043さんによるEMが気にしている生産性の指標についてでした。
モチベーション
2022年10月に、ついに弊社にもDeveloper Productivity Engineering（DPE）にフォーカスする組織としてProducrivity Teamが発足しました。（詳しくはこちら）
2019年にGradle社が下記のドキュメントによって体系化したDeveloper Productivity Engineeringは今や世界中に広がり、国内でも数多くの企業で取り組みが行われています。
※ Developer Productivity Engineering の成り立ちや歴史的経緯は食べログさんのこちらの記事に詳しくまとまっています。
本稿では、ソフトウェア開発ひいてはプロジェクトマネジメント全般をとりまく環境の変化から、なぜ今、Developer Productivity Engineeringが重要なのかを考察してみたいと思います。
尚、本稿では以下の内容については取り扱いません。
- Developer Productivity Engineeringの内容
- 開発生産性を向上させるための具体的なプラクティス
また、本稿では便宜上、開発生産性を「エンジニアが開発に着手してから開発を完了するまでにかかる時間の短さ」と定義します。
※開発生産性とは何か、というテーマは大変興味深い題材なのですが、1つの記事で取り扱うには巨大すぎるため別の機会に譲るとします。
tl;dr
- 私たちはユーザーにとっての価値が何なのか分からない時代のただ中にいる
- 仮説検証サイクルを高速に回すことがより重要になった
- 開発生産性を向上させることで仮説検証サイクルを高速化できる
- 開発生産性は企業にとって競争力そのものであると言える
私たちはユーザーにとっての価値が何なのか分からない時代のただ中にいる
現代のプロダクト開発における状況を、かの有名なプロダクトマネージャー、及川 卓也さんは書籍「プロダクトマネジメントのすべて」の中で下記のように端的に表現されています。
プロダクトに関わるすべてのものは仮説である。 by プロダクトマネジメントのすべて p59
及川さんのこの指摘は、エンジニアに限らず、プロダクト開発に携わるすべての人が「あたりまえじゃん」と感じるものだと思います。
ことほど左様に、国際的に標準とされているプロジェクトマネジメントの知識体系であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する書籍「PMBOK」では、第6版から第7版で内容が大きく改訂され「不確実性」や「複雑性」に対する言及が大幅に加筆されています。
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Mizuho Kushida｜note
このことを、t_wadaさんは2021年のDevelopers Summitの発表で下記のように表現しています。
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer – Speaker Deck
仮説検証サイクルを高速に回すことがより重要になった
ここまでの内容から、私たちはユーザーにとっての価値が何なのか分からない時代のただ中にいるということが分かりました。
そんな不確実性の高い状況で、私たちは一体どのようなアプローチを取っていけばよいのでしょうか。
アジャイル(俊敏)開発の必要性
ソフトウェアの開発プロセスにおけるベストプラクティスを網羅的にまとめた書籍「実践ソフトウェアエンジニアリング」という書籍では下記のように述べています。
市場の状況は急速に変化し、顧客の要求は移り変わり、新しい競合が警告もなく登場し脅威となる。ほとんどの場合、プロジェクトが開始される前に要求を完全に定めることはもはや不可能である。ソフトウェアエンジニアは流動するビジネス環境に対応できるようにアジャイル(俊敏)でなければならない。by 実践ソフウェアエンジニアリング p.28 chapter3 アジャイルとプロセス
また、日経BP社の中田 敦さんはシリコンバレーのスタートアップに取材した内容をまとめたスライド「シリコンバレーの「何が」凄いのか」という資料の中で以下のように述べています。
不確実性の極めて高い状況では、素早く仮説検証を繰り返すことが有力なアプローチであることが分かります。
※ 引用した資料では具体的な実現手法としてアジャイル開発やデザイン思考が紹介されていますが本稿では取り扱いません
加えて、どれほどの速度で仮説検証サイクルを回しているのかについても具体的な数値が紹介されています。
余談ですが、上述の資料は2017年に公開されたものなので、およそ5年が経過した現在は当時の何倍もの速度で仮説検証サイクルを回しているのだろうということは想像に難くありません。
開発生産性を向上させることで仮説検証サイクルを高速化できる
ここまでの内容から、私たちはユーザーにとっての価値が何なのか分からない時代のただ中にいて、仮説検証サイクルを高速に回すことがより重要になったことが分かりました。
では、仮説検証サイクルを高速に回すためには何をしたらよいのでしょうか?
PIXTAのCTO、やさいちさんは経営とソフトウェアエンジニアリングの接続 – WEB SALADという、財務諸表の構成要素からブレイクダウンしてプロダクト開発のプロセスを考察する素晴しいブログポストの中で下記のように述べています。
プロダクトオーナーやプロダクトマネージャーといったプロダクト責任者が要求定義を担う場合、Stream-aligned teamは要件定義以降の開発プロセスを担うことになります。 この場合、そのプロセスが上手く実施されているかどうかを表す定量的な指標をKPIとして設定します。 この指標としては、サイクルタイム（あるタスクに着手してから完了するまでにかかった時間）を採用し、単位期間における中央値の時系列推移をモニタリングするとよいでしょう。 なぜなら、プロダクト責任者の考案する機能が一定の確率で顧客生涯売上を増やすとするなら、単位期間内にリリースした機能の数が多い状態を保つことで、顧客生涯売上の期待増加額を最大化できるからです。
つまり、サイクルタイム（あるタスクに着手してから完了するまでにかかった時間）を短縮することが、仮説検証サイクルを高速化し、ユーザーの求めている価値を創造することに繋がるということです。
開発生産性を向上することでサイクルタイムを短縮できる
では、あるタスクに着手してから完了するまでにかかった時間を短縮するためにはどのような取り組みが必要なのでしょうか。
書籍「The DevOps HANDBOOK」では下記のように述べられています。
リーンコミュニティでは、バリューストリームのパフォーマンスを測定するために一般的に使われている指標が2つある。そのうちの1つがサイクルタイムであり、もう1つがプロセスタイムである(タッチタイム、タスクタイムと呼ばれることもある)。
サイクルタイムは、顧客が要求したときからその要求が見たされるまでの間を指すのに対しプロセスタイムは測定の開始時が顧客の要求のための仕事を始めたときになる。つまり、仕事がキュー(バックログ)に放り込まれて滞留している時間が省略されるのである。
顧客が感じる時間はサイクルタイムなので、プロセスの改善では、プロセスタイムではなくサイクルタイムに着目する。しかし、サイクルタイムのなかでのプロセスタイムの割合は、作業効率の重要な指標になる。by The DevOps HANDBOOK p.47
※ 書籍ではリードタイムと表現されていた箇所について本稿での語彙を揃えるためにサイクルタイムに変換しています
上記の内容を図示したものが下記になります。
|--------------- サイクルタイム ----------------|
|--- プロセスタイム ----|
---------------------------------------------
^ ^ ^
チケット作成 開発着手 開発完了
サイクルタイムに着目してプロセスを改善する必要があるとした上で、プロセスタイムの割合も重要であると指摘しています。
上記の図から、プロセスタイムは「エンジニアが開発に着手してから開発を完了するまでにかかる時間」を示していることがわかります。
つまり、本稿で定義した開発生産性(エンジニアが開発に着手してから開発を完了するまでにかかる時間の短さ)を向上することによって、サイクルタイムを短縮することができると言えます。
開発生産性は企業にとって競争力そのものであると言える
ここまでの内容をあらためてまとめてみましょう。
開発生産性を向上させることで仮説検証サイクルを高速化できることが分かりました。そして、仮説検証サイクルを高速に回すことで顧客からのフィードバックを得ることができ、より早く誰も体験したことのない新しい価値を生み出せることが分かりました。
つまり、開発生産性は誰も体験したことのない新しい価値を生み出す力 = 企業の競争力そのものであると言えるのではないでしょうか。
まとめ
本稿では、ソフトウェア開発ひいてはプロジェクトマネジメント全般をとりまく環境の変化から、なぜ今、Developer Productivity Engineeringが重要なのかを考察し、以下の結論を導きました。
- 私たちはユーザーにとっての価値が何なのか分からない時代のただ中にいる
- 仮説検証サイクルを高速に回すことがより重要になった
- 開発生産性を向上させることで仮説検証サイクルを高速化できる
- 開発生産性は企業にとって競争力そのものであると言える
最後に
ランサーズでは一緒に働く仲間を募集しています。
Productivity teamに少しでも興味がありましたらこちらからカジュアル面談できますのでお気軽にどうぞ!!
明日は@masudak1983さんの「失敗事例をもとにした生産性可視化PJTの始め方」と
@nintia8さんの「bundleからメンバー情報を引っ張り出す」です。お楽しみに。
