開発スピードって？
この記事は スタンバイ Advent Calendar 2022 の20日目の記事です。
これまで在籍・経験した様々な開発現場でも、そして今いるスタンバイでも「開発スピード」という言葉が出てくる場面が多々あります。
ところがこの「開発スピード」けっこう色々な捉え方ができてしまうので、けっこうな割合で認識がズレていそうにも感じます。
自分も、今年どこかで誤解を招く伝え方をしちゃったかもしれないと思い、確認の意味で書き留めておこうと思いました。
そうすることでご意見が違ったらフィードバックもいただけるだろうと。
様々な開発スピード
ベロシティ
単位時間あたりの完成アイテム数、消化チケット数、修正したバグ数
ユーザー・クライアントへの価値提供のスピード
チケット化からリリースまでの期間（Deliveryのリードタイム）
上に列記したものは全て「開発スピード」を表すものと言って間違っていないと思いますし、いずれも速くすること／期間を短くすることに価値があると思いますが、ここで一つ「最終的に目指す開発スピードに結び付くか？」という問いを立ててみます。
最終的に目指す開発スピードって
開発プロセスを図に描いてみます。
順に読み進めてみると・・
プロダクトの課題を発見して仮説を構築し、
要求・要件を定義して共有し、
それを最適なカタチでリリースし、
仮説どおりの効果が得られるか測定して、
また次の課題発見へと繋げていく（図でも右から左にループさせています）
ぎゅぎゅっと短く言うなら「仮説にTRYして結果から学ぶ」
この一連のサイクルを回すスピードを開発スピードと考えて総合的に速めていくことが求められると考えています。
つまり、上の図でいちばん上に引いた長い矢印のサイクルタイム（の短さ）を、最終的に目指す開発スピードと考えたいと思います。
打席に立つ回数を増やす
よく「打席に立つ回数を増やす」という例えで語られますが、
打席に立つ＝仮説をリリースして効果測定する
と解釈できます。
仮説なので、試さないことには合ってるかどうか分からないからですよね。
また、仮説を要求・要件に落とし込む段階に限らず、以降の開発の過程でも、最適なカタチを模索するなかで仮説立てをすると思います。
それらも含めて「仮説」なのでリリースして試さないことには分からない！
というわけで、仮説を要求として受け取ってからのリリースするまでの開発期間（図で「Deliveryのリードタイム」とした範囲）のスピードも大事ですが、それより前段の、課題発見→仮説構築→要求定義といった段階のスピードも大事になるということです。
そして、注意したいのが、図で段差を付けた前後の接続性です。
なぜでしょうか？
そうです。
構築した仮説をしっかり検証できるカタチで開発・リリースしないと、リリースしても意味がなくなってしまうからです。
ミスリードを最小化する
要するに、課題→仮説→要求→要件→仕様・・と繫がっていく途中で認識のズレ・ミスリードといったものが起きてしまうと（意味のないリリースをしてしまうことで）、いくらDeliveryのスピードを高めてても打ち消すことになってしまいます。
意味が全くないほど極端ではないとしても、仮説の意図が十分に反映されていないリリースが行われてしまう危険性があるということです。
そんなことになったら開発に注ぎ込んだ時間がもったいないですよね。
そのため、（もちろん一連のサイクルのどの部分も大事なのですが）developer'sチーム側からすると、要求事項の背景にある仮説や、さらにその背景にある課題をしっかり理解してミスリードを起こさないように意識しておきたいところです。
ここで、あえて怪しい議論を紹介しておこうと思います。
meetingが多いと生産性が下がる？
生産性とか開発スピードとかが話題に上ったときに、無駄なmeetingを減らそうという議論が起こることがあります。
「無駄なmeetingを減らす」ことは私も大賛成なんですが、時折このスローガンを単純化しすぎて「meetingを減らす」議論や活動になっているケースを見かけることがありました。
極端になると「コードを書く＝生産、ミーティング＝無駄」みたいな対比でトレードオフで語られることすらあるように思います。
もう私が伝えたいことはお分かりだと思いますが、
先に述べた「ミスリードを最小化する」ためのmeetingまで削減してしまうとどうなるでしょうか？
その先にある問いは、そのコードはどれだけの価値を生みますか？です。
最近訳本が出た「ゾンビスクラム・サバイバルガイド」の挿し絵キャプションに皮肉を込めたメッセージが書かれていました。
図5.4：「コードを書くためだけにここにいる」という姿勢は、実際のステークホルダー（の不満）から逃げる素晴らしい方法だ
誰かがチケットに書いたとおり、無思考にコードを書くこと（昔どこかで聞いたことがある「コードの製造」を地で行くこと）が、どれだけ危険かということです。
そんなこと言われなくたって分かっとるわ！
と、そろそろ怒られそうなので収束させたいと思います。
仮説に沿った価値を生み出すための認識合わせをするmeetingは無駄どころか、開発スピードを速めるために大切だろうということです。
スクラムなら Refinement やその前後で行われる場でのコミュニケーションが何故大切かという意義の話に繫がります。
事業成長スピードまで求められても・・
さいごに、そこまでは開発スピードに入れられないよ！という話ですが。
事業成長のスピード（事業数字・KPIなどの成長角度、上昇角度）
仮説を検証した結果（効果）は想定より高いことも低いこともあり、当たることもあれば、外れることもあるものなので、「開発スピード」と語る範疇にそこまで求められても困りますよね。
とはいえ、事業の成長を目指してプロダクトを開発しているわけですから、リンクしています。
「打席に立つ回数」を増やして期間あたりの仮説検証を数多く行うことで、同じ成功確率なら、成功の頻度を高めることができる→事業成長のスピードを高められる、ということになります。
つまり、「開発スピード」は「事業成長のスピード」とは
別物ですが、ガッツリ繫がってます！
以上、釈迦に説法でした。
というわけで、
「開発スピード」とか「生産性」とか、このあたりの言葉の共通認識を持って、常に意識して高められていたら、とても強いプロダクトエンジニアリング組織になれると思います。
来る2023年も私たちの旅は続きます。やったりましょう！
余録1：クリプレお裾分け
先日、別のAdventCalendar向けの記事にも書いたんですが、スクラムフェス札幌がらみで知った『TEDxSapporoでの植松努さんの講演』が、思いがけないクリスマスプレゼントを貰ったような気持ちにさせてくれたので。
余録2：FIFAワールドカップ与太話
さて、四年に一度のFIFAワールドカップ期間ということで触れておかずにはいられず。今回ノックアウトステージまで進んだ成績上位のチームが備えていた要素がどう見えたかを書きます。（超・私見です）
スペシャルな個人がいて、（そのスペシャルな個人を生かすことを含め）勝つための組織行動への共通理解レベルが高く、状況を素早く学習して行動に反映でき、それを一試合通してやり続けられるチーム
勝つための組織行動への共通理解レベルが高く、状況を素早く学習して行動に反映でき、それを一試合通してやり続けられるチーム
スペシャルな個人がいて、勝つための組織行動への共通理解レベルがそこそこあり、状況を素早く学習して行動に反映できるチーム
勝つための組織行動への共通理解レベルが高く、それを一試合通してやり続けられるチーム【ベスト16レベル、日本代表の現在地？】
上から3要素は監督からチームへの落とし込みができているかも含みます。
えっと、いわゆる MECE を目指していないです。誰の意見も聞いてません。
ご意見ある方、飲みながら話しましょうw
それでは今年はこのへんで。よいお年を！