$30 off During Our Annual Pro Sale. View Details »

ビジネスアウトカムを中心とするためのフルサイクルエンジニアという選択

Niwa Takeru
September 05, 2023

 ビジネスアウトカムを中心とするためのフルサイクルエンジニアという選択

2023/09/05 Findy ビジネスアウトカム向上へのトライ~夏の開発生産性LT Week~ に登壇した際の資料です。
https://findy.connpass.com/event/292834/

Niwa Takeru

September 05, 2023
Tweet

More Decks by Niwa Takeru

Other Decks in Technology

Transcript

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

    View Slide

  2. 自己紹介
    2

    View Slide

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

    View Slide

  4. 4
    4

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. バリューストリーム:価値提供の為のエンドツーエンドな一連のプロダクト開発プロセス
    顧客の課題を起点として機能提供だけでなく真に顧客課題を解決したか?=アウトカム
    で捉えると分かりやすい。 
    8
    バリューストリームでモデル化する
    8
    バリューストリーム
    (プロダクト開発プロセス)
    ビジネス目標
    顧客要望
    収益KPI
    事業戦略
    アウトカム
    新機能提供・機能改善
    KPIの達成・ARRの積上
    事業ロードマップの実現





    改善項目
    イテレーション
    継続的学習
    フィードバック
    設計 開発 テスト リリース 運用サポート
    仕様策定
    バリューストリームのモデルを利用して、アウトカムを最大化する方策を考える

    View Slide

  9. 9
    バリューストリームを紐解く
    9
    バリューストリーム
    ビジネス目標 アウトカム





    機能/改善
    イテレーション
    フィードバック



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

    View Slide

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

    View Slide

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







    View Slide

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

    View Slide

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

    View Slide

  14. 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分での機能提供
    プロダクト専任による
    ノウハウの蓄積

    View Slide

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

    View Slide

  16. View Slide