見出し画像

Outcome / Day で考える開発生産性

Niwa Takeru｜アセンド株式会社CTO

みなさん、こんにちは。物流・運送会社向けにSaaSを開発するアセンド株式会社でCTOを務めている丹羽です。
アセンドではプロダクトエンジニアとして「日本で最もデジタル化の遅れた産業で、最高の業務体験を創る」ことを信条として、猛進的に日々のプロダクト開発を進めています。そこで１つ大切となるのが開発生産性です。
プロダクトを創る以上はどれだけ顧客体験を良くできたかの価値にこだわるべきであり、今回は開発量のOutputではなく価値のOutcomeという観点で開発生産性を考えます。

Outcome を求めるプロダクトエンジニアに関しては下記の note で詳細にまとめております。ぜひご覧ください

この記事は「エンジニア組織の開発生産性・開発者体験向上の取り組みをシェアしよう！ by Findy Advent Calendar 2023 」の最終日25日目の記事となります！


アセンドのOutput観点での開発生産性

前提として一般的な Four Keys でのプロダクトチームの開発生産性を紹介します。デプロイ頻度は平均で１日あたり6.6回と高く、多い日では10回以上もデプロイをするトランクベース開発で進めてきました。また、変更差分が小さい故に修復時間と変更失敗率は良い状態にあると考えています。
2023年のState of DevOps と比較してもエリートチームに分類されており、Output の面でも高い開発生産性を出すことができています。

アセンドプロダクトチーム 2023年 の Four Keys

Output をまずは改善し、時間を産む

いきなり本論から逸れた話をしてしまうのですが、Outcomeの生産性を求める前に Output を高めることが重要と考えています。なぜなら Outcome であれ Output であれ生産性を上げるためには、改善するための時間を産まなければならないからです。生産性を上げるためにまず時間を作る投資をすることは鉄則と考えます。
Output の生産性を上げるにはアーキテクチャやカルチャーの変革など時間軸のかかる投資が本質的には必要であり、 Outcome とは別の流れで先行して施策を実行することも可能と考えています。

時間を産む投資をする点において、アセンドではシード期であるプロダクト初期から取り組めていたことが幸いでした。GitOpsを導入し1分でデプロイする仕組みを構築したり、カルチャーの面でトランクベース開発を当たり前とする心理的安全性の向上を図ってきました。効率的に開発し時間を作ることで、より時間を作る開発生産性の向上への投資ができる、複利で生産性向上の資産を積み上げることをアセンドのプロダクトチームでは大切な姿勢としています。

Outcome をモデル化する

プロダクト開発の Outcome の生産性を測ることは難しくあります。Outcome を実現するには複数の因子があり、マーケットが反応するまで時間を要するなど直接的に測れるものではありません。ではどうするか。

プロダクト開発を山登りに例えて目標であるアウトカム＝山頂にどれだけ速く辿り着けるか、 Outcome / Day で開発生産性を考えることとしました。Outcome / Dayの速度を上げる因子を挙げ開発生産性向上の施策を考えます。

プロダクト開発の目標であるアウトカム＝山頂にいかに速く辿り着くか

Outcome 実現のためのバリューストリーム

顧客の要求が出てから Outcome が実現されるまでの開発フローをバリューストリームと言います。一般的なソフトウェアの開発では、顧客要求に対して仕様策定し、設計・開発・テスト・リリースをした後に、顧客にあてて Outcome を達成することができたか分かります。ただ往々にしてプロダクト開発とは不確実性は高く顧客課題の解決を１度でできることありません、反復的にイテレーションを繰り返すことでアウトカムに近づいていきます。

プロダクト開発のバリューストリーム

このバリューストリームのモデルを利用して、Outcome / Day の速度を上げる因子を考えます。速度を上げるためには、分子である Outcome を最大にするアプローチと、分母である Day を最小にするアプローチに分けられます。また、それぞれのアプローチに対してアセンドがどのように取り組んできたかを触れていきます。

Outcome:分子を最大にするアプローチ

分子の Outcome を最大にするアプローチには以下が考えられ、プロダクトマネジメントが主なものになります。

仮説の精度のバランス

Lean な考え方を大切とする一方でしっかりと仮説を立てることも重要と考えています。特にアセンドが開発するような業務アプリケーションにおいては、体験の前に業務が存在します。業務を正しくサービス上で扱えなければサービスとしての意味がありません。つまり業務が回らなければ顧客が仮説検証をすることができないのです。
アセンドでは開発を始める前にまずは業務整理・ドメインモデルの発見に時間をかけており、その仮説で業務が回ると言えるまで確度高めてから開発を始めています。
一方でUXやユーザビリティの領域においては仮説の精度を高くは求めていません。特にUIによった部分であれば顧客が実際に使った時の方がインサイトは得られます。

  • 仮説対象に既に業務がある場合は仮説の精度を高めてから開発する

  • ユーザビリティを高める仮説の場合は精度は求めず、顧客から早く学ぶ

仮説立てする対象は不確実性が高いものかをあらかじめ考えて、仮説立てをすることが重要と考えています。

無駄なものを作らない、手戻りを無くす

顧客要求を受けて意欲的に立てた仮説で作ったものの6, 7割がハズレであると体感を持っています。開発の無駄の中で使われないものを作るものは実際に手を動かしていることがからロスのインパクトは大きくあります。
上述で作る前に仮説を深めることの大切さを言っていますが、この立てた仮説に対して「必要か不要か分からないものは作らない」という方針をアセンドでは持っています。リーンに開発し顧客に当てたときに改善要望をもらって初めて機能に組み込むことで無駄な開発を最小化しています。顧客から当初は必要と考えられていたアナログでは必要だった業務が実は無くとも回ったこともあり、追加で要望をもらう中でデジタルを前提とした良い機能へ進化した事例もあり、作らない重要性はここにもあります。

筋よくバランス感を持った仮説を立てるためにはドメインへの深い理解が最も大切です。同じ領域に対して１エンジニアが開発し続けることでドメインの学習が進むと考えています。

顧客が本当に必要だったもの

開発内容の配分＝フロー配分を最適にする

実際のプロダクト開発では機能開発以外のことにもコードを書いています。不具合改修やリファクタリング、またプロダクト初期は運用サポートの為のコーディングなど、アウトカムに直接効かない開発も存在します。一方でリファクタリングのような負債返却をしなければ長期的にはアウトカムを出せないシステムともなります。

大切なことは開発フローの配分のバランスが適切な量になっているかということです。不具合による緊急対応が多すぎれば一度足を止めて負債返却に走るべきですし、過度にリファクタをし過ぎて機能開発が疎かになっていることもありました。現時点での開発内容のバランスが理想像と合致しているかが大切です。
Four Keys の開発リードタイムを計測すると共に、各PRに対して以下の４分類のどれに当たるかラベルをつけることで開発フローの可視化をすることができます。

開発フロー配分を可視化する

コミュニケーションのロスを無くす

伝言ゲームが存在するようにコミュニケーションパスが多くあるほど情報は正しく伝達されません。プロダクト開発のような不確実性の高いものは、そもそも言語化が難しく多人数で連帯をとることは困難です。

アセンドでは以下の２点でコミュニケーションパスを減らし、プロダクトエンジニアとして開発に携わっています。

  • プロダクトマネジメントのレイヤーからエンジニアが関わり、顧客要求から仕様策定の段階から入り、何を作るべきか？を共に考えます。UX/UI デザインにも携わります。仕様を決める際には様々な可能性を探っており、前提条件があるから１つの可能性を選択できます。開発を進めるうちにこの前提条件が崩れることはあり、仕様策定当初から関係しなければ気付くことはできません。

  • フロントやバックエンドの技術領域でエンジニアを分けることもロスに繋がると考えています。特に問題視していることは本来の顧客課題解決が目的あったことがAPIや画面の開発という仕様実現に目的が変わってしまうことです。フルスタックで開発することの意義がここにもあります。

Day:分母を最小にするアプローチ

分母の Day を最小化するアプローチに関しては Four Keys で計測できる開発生産性が主なものになります。

開発効率を上げる

ここは一般的な開発生産性向上の部類であり、多くの事例や手法があるため詳細は割愛します。アセンドとして大切にしている考えは開発生産性は資産と仕組みによって実現されるという考えです。努力による生産性向上は短期的なものであり、誰もが自然と生産性が上がる仕組みが求められます。
実際にアセンドで生産性向上に寄与している仕組み・資産には以下があります。

  • Full TypeScript Architecture
    すべて TypsScript に言語統一し開発中のスイッチングコストを最小化

  • ChatOps, GitOps による作業時間１分でデプロイできる仕組み

  • desing-kit やロジック類をまとめたライブラリの開発

  • Copilot, Renovate, Autify, Sentry などの各種ツール導入による効率化

今後も全体の開発生産性が上がる仕組み・資産を築いていきたいと考えており、Enablementの一環として各種エンジニアのスペシャリストの活躍を求めています。

トランクベース開発で即座に顧客にあて、イテレーションを高速に回す

製造業でも在庫を減らす重要性は説かれていますが、プロダクト開発においても同様です。顧客にあてていない仮説は仮説のままでありその良し悪しは分かりません。トランクベース開発で毎日デプロイすることの意義はここにあります。
エンジニアが開発を終えてからリリースまで時間がかかると、追加要望が出た際も不具合が出た際でも開発内容を思い出すための時間がかかります。時間が掛からないように覚えていくことも脳内メモリの圧迫に繋がり、メモリのスワップも発生するため開発効率が落ちる問題を起こします。

機能リリース後は即座に顧客にヒアリングを行い仮説検証の結果を得ます。アセンドではオフラインで働いていることもありBizメンバーとも関係が良く、機能リリース後にカスタマーサクセスのメンバーを通じて即座に機能を顧客に確かめることができます。この顧客の声を聴いて早ければ20分に改修を行いブラッシュアップすることもあり、イテレーションスピードの強力さが伺えます。

その日に開発したものはその日に出す、エンジニアがクリアな頭で複雑な開発を進められる状態にすることは Developer Experience を考えるうえで大切な視点と考えています。

トランクベース開発とイテレーションをキーワードにChatGPTで作ってもらった画像です。

終わりに

今回は Outcome / Day で考える開発生産性ということで可能な限りで生産性に寄与する要素を因数分解して紐解くことをしました。実際のプロダクト開発は不確実性は高く、生産性を上げようにも複数の因子が絡んでいるため、相乗効果のある施策もあれば、足を引っ張り合う施策もあります。システム思考でアプローチを考える必要があります。

アセンドでは Outcome / Day を最大化するためにプロダクトエンジニアというアプローチをとり、各施策が相乗効果があるように開発体制を設計できていると伝わったのではないでしょうか。
とはいえ、デジタル化の遅れた物流・運送業で最高の業務体験を創るには、まだまだOutcomeを中心とした開発生産性の向上とエンジニアの力が必要です。この開発環境を共にアップデートしたい Engineering Manager の方、この開発環境で全力で開発をしたい Product Engineer の方をお待ちしております！！

本記事に共感をされた方はぜひ 丹羽のX(Twitter) のフォローをお願いします

この記事が気に入ったらサポートをしてみませんか？