【Findy 夏の開発生産性 LT Week】 ビジネスアウトカムを中心とするための フルサイクルエンジニアという選択 取締役CTO 丹羽健

自己紹介 2

3 会社紹介 3 物流業界の価値最大化 Our Mission アセンドが挑む物流の社会課題 全ての物流データがのるシステム基盤を作る そして物流が最大効率で回る日本社会を作る 中小企業中心で投資余力がなく デジタル化に取り残された運送業界 2030年に物流の供給力は35%不足 日本の経済損失は10兆円 一方で運送事業の市場規模は20兆円 SaaSを起点として事業が成り立ち 十分にユニコーンが狙える業界 TAM 20兆円 SAM 2兆円 2024年問題対策として、 政策パッケージが発表 解く意義の大きい社会課題を持ち エンジニアとして最大限の挑戦と 社会的インパクトを起こすこと ができる

4 4

5 アセンドの高い開発生産性 4Keys 5 5.67 デプロイ頻度 変更のリードタイム 平均修復時間 変更失敗率 5.67 deploys/day 2 hours 24 minutes 2.6 percent 高い開発生産性は前提として、この生産性をビジネスアウトカムに変換できるかが重要

ビジネスアウトカムへの整理 6 6

事業的アウトカム 相関する技術・デザインの観点 短期 顧客への提供価値 ● 新機能の提供 ● 機能ギャップの解消 収益 ● 新規顧客獲得 ● KPI (ARR/LTV/Churn Rate) ● コスト削減 デザイン・仕様 ● ユーザビリティ / UX/UI ● Leanな仕様・業務を抽象化し汎用化された仕様 技術・開発生産性 ● デプロイ頻度（イテレーションの向上） ● 開発リードタイム（価値提供の即時性） ● 低いネガティブ指標（失敗率・復旧時間） 長期 事業戦略 ● 新規プロダクトのリリース ● Product Market Fit ● 事業ロードマップの実現 ● マーケットサイズ(TAM/SAM/SOM) 技術的資産・負債 ● ドメインを忠実に再現するデータモデル ● スケール可能なアーキテクチャ ● アプリケーション基盤 ● 品質、カルチャー、CI/CD、etc 7 ビジネスアウトカムを設計する 7 エンジニアは性質的に長期視点での技術的負債を考えた開発を進めやすい。 短期と長期、事業と技術のマトリクスを持ってバランスあるビジネスアウトカムに設計する。 その改善はどれらに寄与する施策か？を各エンジニアが判別可能な状態とする

バリューストリーム：価値提供の為のエンドツーエンドな一連のプロダクト開発プロセス 顧客の課題を起点として機能提供だけでなく真に顧客課題を解決したか？＝アウトカム で捉えると分かりやすい。　 8 バリューストリームでモデル化する 8 バリューストリーム （プロダクト開発プロセス） ビジネス目標 顧客要望 収益KPI 事業戦略 アウトカム 新機能提供・機能改善 KPIの達成・ARRの積上 事業ロードマップの実現 ⏳ 改善項目 イテレーション 継続的学習 フィードバック 設計 開発 テスト リリース 運用サポート 仕様策定 バリューストリームのモデルを利用して、アウトカムを最大化する方策を考える

9 バリューストリームを紐解く 9 バリューストリーム ビジネス目標 アウトカム ⏳ 機能/改善 イテレーション フィードバック ⏳ 設計 開発 テスト リリース 運用サポート 仕様策定 アジャイル開発 DevOps 4Keys 開発リードタイム 4Keys デプロイ頻度 Lean 思考 プロダクトマネジメント 不具合改修 リスク削減 負債解消 Four Keys やアジャイル、DevOps はアウトカムを実現する部分的な指標/施策でしかない。 部分的な施策であることを踏まえてバリューストリームの最適化に活用する。 ※4Keys の残る平均復旧時間・変更失敗率はカウンターとなるネガティブ指標であるため割愛 FE BE

10 バリューストリームを高速化する 10 プラスを増やすアプローチ リーン思考による初期仕様の策定 開発高速化のためには、やることを減らすこと。 機能改善の多くはアウトカムへの不確実性が高いため、 開発着手以前にコアとなるMVP仕様をLeanに定める。 高頻度デプロイで不確実性を解消 機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 開発効率化でのリードタイム圧縮 仕様策定後は速やかに顧客に機能提供ができるよう CI/CDなどを整備して開発リードタイムを圧縮する。 顧客要望が冷める前に機能提供ができることで アウトカムへのサイクルタイムを圧縮することも可能。 他にもアプローチはあるので、バリューストリームのモデルを利用して　 現在の環境のボトルネックを特定すると良いと考えています。 イテレーション 仮説 IDEA プロトタ イプ CODE データ DATA 構築 Build 学習 Learn 検証 Measure

11 バリューストリームのロスを防ぐ 11 マイナスを減らすアプローチ サイロ化によるコミュニケーション齟齬 組織が分断されると目標へのコンテキストが伝言ゲーム のように失われる力学が働く。また組織内の局所最適な 目標が設定される恐れが発生（ex. 4KeysへのHack） 仕様的負債を産まないプロダクトマネジメント 技術的観点も含めプロダクトマネジメントをすることで 同じアウトカムを保ちつつ仕様的な複雑さを下げる。 技術的負債の多くは仕様的な負債に根ざしており、 無駄に課題内在性負荷の高い仕様を産まない。 フロー配分の最適化 事業フェーズを鑑みて 開発項目の最適なフロー配分を設定 比率配分を定め、偏った投資を防止 スタートアップ・アセンドでは 機能改善への投資比率を高く設定 他にもアプローチはあるので、バリューストリームのモデルを利用して　 現在の環境のボトルネックを特定すると良いと考えています。 ⏳ ⏳ ⏳

アセンドでの フルサイクルエンジニアによる バリューストリーム最適化への設計 12 12

13 フルサイクルエンジニアでの開発 13 1エンジニアがソフトウェアの ライフサイクル全てにオーナーシップを 持ち開発できるよう開発環境を設計・投資 ユーザ課題を中心として機能検証の 開発サイクルを高速に進めることが可能 アウトカムを中心として開発 フルサイクルを支えるため多くの技術的投資と仕組み的な資産を積み重ねています

14 バリューストリームのフルサイクル化 14 バリューストリーム ⏳ イテレーション フィードバック ⏳ ChatOps フルサイクルエンジニアでの開発 Lean Management ビジネスアウトカムを主眼として開発生産性に積極的に投資し、 「面・質・スピード」を兼揃えた開発環境・カルチャーを構築。 Postmortem Mono Repo 深い業務理解 5.67 deploys/day 設計 開発 テスト リリース 運用サポート 仕様策定 GitOps Sentry Autify Full TS Arch DDD PM by Eng 24.3 PRs/day フロー配分 ビジネス目標 顧客要望 収益KPI 事業戦略 アウトカム 新機能提供・機能改善 KPIの達成・ARRの積上 事業ロードマップの実現 Product Management 領域の統合 週次振り返りの実施 要望起票Channel 最短20分での機能提供 プロダクト専任による ノウハウの蓄積

アセンドは社会課題解決をすることこそがエンジニアの本分と捉え、 真なる課題解決をアウトカムに据え開発ができるカルチャーを徹底徹尾に構築していきます。 このメッセージに共感された方、ぜひ共に働きましょう！オフラインミートアップも開催！ メッセージ 15 CTO丹羽のTwitter (@niwa_takeru) お気軽にフォロー・DMください。

No content