フロー効率性とリソース効率性について(QCDのトレードオフなんて本当は無かったんだ)

最新版

本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。

i2key.hateblo.jp


本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイルリーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。

共通の価値観としての「リードタイム」

SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得て仮説を補正する(別の案を試す)というサイクルをくるくる回すことになるかと思います。このようなときに開発チームとして目指すところは学びの回数を最大化することなのは自明かと思います。そしてそのサイクル短くする、すなわちサイクル効率性を高めることが必要になります。サイクル効率には仮説の質等も影響も与えますが、今回はエンジニアが直接結果をコントロールしやすいサイクルタイム、言い換えるならば、学びまでのリードタイムを軸に考えていきます。またスコープは学ぶまでのリードタイムであるため、Build部分のみにフォーカスするのではなく、Build-Measure-Learnの1回転をスコープとします。 例えば、コードレビューで手戻りが頻発すればリードタイムが伸びますし、受け入れテストで受け入れられなければやりなおしになるのでリードタイムが伸びます。様々な活動は結果的にリードタイムに跳ね返ります。

f:id:i2key:20170514231222j:plain

すごくラフですが以下のような開発プロセスのバリューストリームマッピングを例にします。LTはリードタイムを表しています。リードタイムとはプロセスが作業を受け付けてから、下流のプロセスに渡すまでの時間になります。PTはプロセスタイムで、作業者がひとつの作業項目を完了するのにかかる時間です。そして実際に価値が作り込まれているのがこのプロセスタイムになります。実際のところは[PT = Value Add Time(VAT) + ムダ ]であり、 本当に価値を作っている時間はその一部になります。赤い部分が上記のBuild-Measure-LeanサイクルのBuild部分に相当します。エンジニアが直接結果をコントロールしやすい部分です。

f:id:i2key:20161207025451p:plain

フロー効率性とリソース効率性の話

あえて極端な例。A機能、B機能、C機能の実装それぞれ15人日かかる場合。

f:id:i2key:20170514231345j:plain

  • リソース効率性パラダイム(図の上側レーン) 複数のことを同時にやるとプロダクトが届くまでのリードタイムが長くなる。ただし、みんなに仕事が割り振られるためリソースの稼働率は高くなる。
  • フロー効率性パラダイム(図の下側レーン) 逆に、同時にやることを一つにすると、プロダクトが届くまでのリードタイムは短くなる。ただし、全員が同じことをやる場合、どうしても一時的に、手持ちがなくなる人が出て来るためリソースの稼働率は下がる。図ではCも3Weekのリードタイムで出してるが実際は、4週目とかにズレこむ感覚。でも、ABCのリードタイムのトータルでは上側レーンよりは圧倒的に少ない。

これはどちらが正解というわけではないです。この2つはQCDのようによくあるトレードオフの関係にあります。大規模開発のように大量のものを一括でドン!とリリースするような文脈だと、上記のリソース効率のパラダイムになります。そんな中でフロー効率性を高めるようなペアプログラミングを実施したいと提案しても、(リソース)効率落ちるだろと言われ却下されることは多いのではないでしょうか。逆にフロー効率性を高めて、学びまでのリードタイムを最小化しようとしているときに、偉い人が出てきて「リリース物は全部承認印が必要だ、だが、時間はあまりないので一括で見るからまとめて持ってきなさい」とかいわれると現場はフロー効率性を高めようとしているのにリソース効率性のノイズが入り、現場からはヘイトが高まるのではないでしょうか。

ポイントとしては、タスクやデータ、物事の流れに着目し、それがうまく流れているかをカイゼンしていくことが大事です。

そして、一般的には、フロー効率性の目線で現場の課題を可視化していき、フロー効率性を高めると結果的にリソース効率性における課題も表出化され改善されることが多いです。ベースはフロー効率性を高める目線で活動しつつ、制約が現れたときにそれをコントロールの対象とするか、前提とおくかは重要(制約理論)です。ここらへんはThis is Lean*2とかに詳しくは書いてあります。

f:id:i2key:20170514231433j:plain

QCDのトレードオフなんて本当は無かったんだ

SoEライクな開発の座組において、QCDとScopeは「学びまでのリードタイム」という軸で見ると以下の意味を持つ。結論から言うとリードタイムという観点だとQCD全部大事品質は悪いと基本的に手戻りを生むので速度に跳ね返る。手戻ってる時間は学びをうまない時間。品質を下げるという判断は学びの速度低下を許容するとこと。

  • Quality:低下するとリードタイムを悪化させる(=品質下げるという選択肢がそもそも無い:固定)
    • プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長くなる
    • 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さなどにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる
    • 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイムが長くなる。障害発生により、それの対応に終われリソースが枯渇し本来やるべきことの足かせになり、リードタイムが長くなる
    • 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行かれリードタイムが長くなる
  • Cost:大抵人件費でありチーム体制は頻繁に増減はない(固定)
    • コストはエンジニアリングの場合、大抵、人件費に跳ね返るが体制は基本的には固定であり頻繁に上下するものでないので固定になるケースが多い。
    • 学びまでのリードタイムの人件費と見るのであれば、少ないにこしたことはない。結果的にコストはリードタイムそのもの。
  • Delivery:出来るだけ短縮したい(伸ばさない、短縮すべき対象)
    • リードタイムそのもの
  • Scope:一度にやる量を決めることでリードタイムが結果的に変わってくる
    • 大きくする(大きなバッチ)と、リソース効率性のバイアスがかかるため、一括でリリースは出来るが、デリバリまでのリードタイムは増える(前述の図の上側レーン)
    • 小さくする(1個流し)と、フロー効率性のバイアスがかかるため、小出しにはなるがデリバリまでのリードタイムは小さくなる(前述の図の下側レーン)

QCDは調整ネジではなく、リソース効率性とフロー効率性が調整のネジ

この文脈においてQCDは基本的に変数ではなく、ほぼ定数として扱うことになる。全部大事。そして、デリバリは早ければはやいほどいい。そこで調整ネジというか変数になってくるのがScopeで、一度に開発する(同時にリリースされる)対象の量とサイズがそれにあたる。それにより、リードタイムが上下する。 調整ネジとは言え、学びへのリードタイムを短くしたいので、フロー効率性を高める選択をしたほうがよいのが本音。

チームが一度に行うタスク量が多い/サイズが大きい場合

一度に開発する量が多い/サイズが大きいと、並行作業が発生する。チームメンバは担当する機能が割り当てられ、それぞれ別々の機能の開発をする。つまり、この時点で、チームは前述の以下の図の上側レーンを選択したことになる。例えば、プロダクトオーナーから起案された機能要望がとてつもなく大きいとかがこれにあたる。エンジニアは本能的に下記図で上側レーンのようにリードタイムが増えることを感じ、「もっと分割できないですか?」「必要最小限にできないですか?」ときいたりするが、「これ全部必要です。」といわれることが経験上あるはず。しかしながら、これに対して「エンジニアチームの生産性が悪い」「なかなかリリースされない」みたいな意見がでたりもする。この状況を作り上げている「1つ」の要因はバッチサイズの大きさである。しかし、これはチームがそうなることを選んだのである。POやプロダクトマネージャーはチームに大きな塊を渡した時点で、渡した側も何が起きるか、どういう選択をしたのかを把握しておく必要がある。

f:id:i2key:20170514231558j:plain

This is Leanの P21にはリソース効率性に振り切っている状況を以下のような図で説明されている。1つのリソースにフォーカスして、そのリソースが与えられる稼働を100% になるように複数のフローユニット(タスク)に分割する。

f:id:i2key:20170514231618j:plain

部分的にリソース効率性が求められる場合はある

  • どうしても一括でまとめて処理しないとならない場合
    • 手動でしかテスト出来ない部分、データセット上、まとめて確認したほうが早いような場合
    • 認印が必要でなおかつ承認者が特定のタイミングでしか捕まらない。承認者のリソースに空きがうまれたタイミングで一括で処理してもらう必要がある場合。
      • 【余談】大抵ここがボトルネックになってくるため、制約理論を活用することになる。
      • 【余談】最終的には改善していくとこの承認行為自体が不要になる場合もある(権限委譲等により)
        • 権限委譲については、いろいろなやり方がある。エンジニアリングにより、安全に失敗できるインフラを構築できればその枠内では権限委譲できる等。
          • 例えば、自由にアイデアをリリースしたい場合、Feature Toggleを用いて、社内のメンバのみに公開する設定で実装。ドックフーディングをして、問題なければユーザの10%に公開。そこで問題なければ全体公開等。これはエンジニアリング&インフラにより権限委譲を可能にするパターン。
          • もしくは、マイクロサービスアーキテクチャにて売上をあげている単位でマイクロサービス化(アーキテクチャレイヤ分割というよりは、ドメイン分割)。これにより売上責任を持ったクロスファンクショナルチームは、売上をあげる責任を持つと同時にプロセス権限が委譲される。

チームが一度に行うタスク量が少ない/サイズが小さい場合

一度に開発する量が少なく、サイズが小さい場合、チームは1つのことにフォーカスできる。例えば1つの機能を全員で実装する。すると複数の機能を全員で実装していた場合よりも、とある1つの機能は学びまでのリードタイムが短くなる。下記図の通りである。また、チームへ渡される要件のスコープが小さければ小さいほど、チームの見積もりの確度は高まる。更に、チームは自分たちの本来の適正な生産性で作業を実施できるようになる。

f:id:i2key:20170514231637j:plain

This is Leanの P21には以下のような図で説明されている。1つのフローユニット(機能)にフォーカスして、その1つのフローユニットが受けられるリソース時間を最大化する

f:id:i2key:20170514231658j:plain

フロー効率性を向上させるプラクティスや事例

  • カンバン(トヨタ生産方式
    • 一個流し(トヨタ生産方式
      • WIP制限にて流す量を減らす(最適化する)
      • WIP制限1にすることが目的ではない(最適な値にする)
      • WIP制限を小さくすることのメリット・デメリット
        • メリット
          • フロー効率性に特化した改善が行いやすい。ボトルネックが可視化しやすい。
        • デメリット
          • WIPを1に制限すると生産ライン上のどこかでトラブルが起きた場合、後続ラインが全面停止する。デメリットではあるが、必ず異常事態を検知でき、後続に不良品が流れないと考えるとメリットでもある。
  • ペアプログラミング
    • 二人で1つのことをするため、二人で別々のことをするよりも流れるものの数が半分&品質が上がる(副次効果で引き継ぎが不要になり、結果的に誰でもどんな作業もプル出来るようになる。こちらもフロー効率性に寄与する。)
  • モブプログラミング
    • ペアプロのフロー効率性の極値振り型
    • 「あなたが売っているのは、キー入力だろうか?それとも完成した機能だろうか?」 by カンバン仕事術*3 P112
  • Github-Flow & Feature Flagのコラボ
    • FeatureFlagを仕込んだプルリクのMasterマージで本番環境への自動デプロイ
    • 断片でのプッシュが可能になり、プルリクが小さくなる
    • 流れるもののサイズを小さくする効果(フロー効率性)
    • 対してGit-FlowはReleaseブランチが若干一括処理でありリソース効率性がある。
  • 継続的ビルド&テスト&インテグレーション
  • マルチタスクをやめる
    • カンバンのWIP制限の話と同義
  • バリューストリームマップ
    • バリューストリームマップにて、プロセスタイムとリードタイムを可視化。ムダを特定しフローを改善。
  • クロスファンクショナルチーム
    • 他組織とのやりとりは基本的にバッチ処理になりがちであり、引き継ぎのムダが発生する。それの排除。
  • フルスタックエンジニア
    • クロスファンクショナルチームの人バージョン。1人で全部できれば待ちのムダが省ける。フルスタックはある文脈では(笑)とされるが非常にフロー効率性が高い。
  • etc

まとめ

仮説検証型でプロダクト開発を行う場合、学びまでのリードタイムを如何に短くするかが重要であるのはもう自明ではあり、目指す方向は「一個流し」(フロー効率性:高)である。しかしながら「目指す」のであり「目的」ではないのがポイント。フロー効率性の極値である「一個流し」を目指すことで様々なムダが浮き彫りになり、それを解消していくと、結果的にリソース効率性も高まるのである。

  • フロー効率性(流す量を減らす)をあげると、ライン上にタスクまちの人が増えて、何もしない人がうまれる。(リソース効率性悪化)
  • リソース効率性(流す量を増やす)をあげると、ライン上に人まちのタスクが増えて、リードタイムが増える。(フロー効率性悪化)

エンジニアリングに読み替えると、チームに渡される玉の量とサイズの大きさと、それを全員で一個を倒しに行くのか、ばらばらにそれぞれのタスクをこなすのか。一般的にプロダクト開発においてプロジェクトマネジメント上QCDが調整ネジに扱われるが、SoEな文脈においてはフロー効率性とリソース効率性( チームに渡される玉の量とサイズの大きさ )を調整ネジにすべき。従来の鉄板(だと誤解されていた)だった品質すてて速度あげようは 品質は劣化すれば手戻りが発生するだけで、結局はリードタイムの増加に跳ね返る のでやめましょう。

結果的に、カンバンやスクラムがWIP制限だのプル型だのいっている理由やスコープで調整軸にするというあたりまえの話に結局戻ってしまったが、一周回って?基本を理解できたのでよかった。

*1:以下でバイモーダル戦略やSoE/SoRについて触れています i2key.hateblo.jp

*2: Amazon CAPTCHA

*3: カンバン仕事術 http://amzn.to/2rfmwHUamzn.to

Modern Agile 入門 #modernagile

完全に出遅れ感ありますが、モダンアジャイルが気になってきたのでちょこっと自分の中で理解のために整理をしてみました。モダンアジャイル自体にプラクティス厨やめろというメッセージが含まれているかとは思いますが、とは言え、本家 Modern Agile - Industrial Logic でもある程度はプラクティス風な記載はされているので同様にやるべきこと、やるとよいことをプロットして思考を整理しました。箇条書きで見にくいかとは思いますが、あくまで自分用なので。今後追記編集していくかもです。テキトーに自分用メモとして書いただけなので間違ってたら指摘ください。また、入門というタイトルは自分が入門しただけなので、入門者のために書いてるわけではないのであしからずw 各プラクティスや方法論は理解してる前提で箇条書きしてます。

Modern Agileの位置づけの理解

f:id:i2key:20170423235239p:plain

ここにプロットされている諸々の方法論については、アジャイルもDevOpsもリーンスタートアップも特定のスコープのスループットを最適化する話であり、以下の記述からもわかるようにModern Agileのスコープが従来の方法論のスコープを包含しにいった印象。ただ、ビジネス側への染み出しからいうと、人々を最高に輝かせる(Make People Awesome)というメッセージをどこまで視座高く理解しスコープを広げるかで、上記図中でのカバー領域はもっと左へ染み出していくかとは思います。

  • 人々を最高に輝かせる / Make People Awesome
  • 安全を必須条件にする / Make Safety a Prerequisite
  • 継続的に価値を届ける / Deliver Value Continuously
  • 高速に実験・学習する / Experiment & Learn Rapidly

となると、今までやってきたことの悪魔合体をしたくなる。というわけで、脳内整理メモ。基本的には過去に書いたポエム DevOpsはエンタープライズからスタートアップへの横恋慕 #devops #プロダクトマネージャー #leanstartup - @i2key のBlog の広義なDevOpsに近似しているけど。

人々を最高に輝かせる / Make People Awesome

プロセス

システム

人(スキル/スタンス)

  • 人々を幸せにするものを作る
    • カスタマーの理解
    • クライアントの理解
    • ビジネスの理解
      • ビジネスモデル
      • ビジネスフェーズ
      • ビジネス戦略/戦術
  • 開発者を幸せにする(Developer Experience)
    • 適切な技術的チャレンジ
      • 最新の技術ではなく、最適な技術の選択
    • HRT文化
      • コードを憎んで人を憎まず
  • 顧客開発の理解

安全を必須条件にする / Make Safety a Prerequisite

プロセス

  • 早期失敗のハンドリングするプロセス
  • 品質マネージメントプロセス
    • 確立したテスト戦略・計画
    • バグトリアージ
    • バグマネージメント
  • インシデントマネジメント
    • 障害時運用フロー
    • セキュリティ運用フロー
  • 失敗を非難しない振り返り

システム

  • 安全に失敗できる環境の構築
    • SplitTest(ABtesting)
    • CanaryTest
    • FeatureToggle
  • 事前に不具合を検出する仕組み
    • 自動テスト&CI
    • 自動テストの品質管理
      • Mutation Testing
    • Chaos Monkey
  • 馬鹿でかい本番リリースの恐怖からの脱却
    • Feature Flag
    • Dark Launch
  • 不安を取り除く

人(スキル/スタンス)

  • 一人前のエンジニアリングスキル
    • 若手エンジニアの育成
      • コード品質担保
      • 機能要件、非機能要件の実現
      • 開発プロセスの理解

継続的に価値を届ける / Deliver Value Continuously

プロセス

  • 組織構造
    • スモールチーム
    • クロスファンクショナルチーム
      • マイクロサービス
  • 継続的にデリバリー出来るためのプロセス
    • タスクマネージメント
    • リリースマネージメント
  • リードタイムの削減
    • VSMによるムダの可視化
    • プロセスタイム、ValueAddTimeの可視化、定義

システム

人(スキル/スタンス)

  • TPS/LEAN/TOCの理解
  • フロー効率性の理解
  • DevOpsの理解

高速に実験・学習する / Experiment & Learn Rapidly

プロセス

  • 仮説検証型プロセスの装着
    • バックログ
      • 仮説
      • 仮説を実証するために必要な条件
      • そのために必要なデータ
      • データの収拾方法
      • そのためのMVP
      • そのためのコストと時間

システム

  • (「安全を必須条件にする」がシステム面を担保)
  • 実験結果を計測する環境の構築
    • 実験が正しく行われるための調整
      • ファネル分析
    • 機能追加単位での検証結果モニタリング(マーケ施策の影響受けない)
  • ダッシュボード
    • 継続率|ChurnRate
    • 機能単位利用率
    • CVR
    • CAC|LTV
    • Leadtime to Learn
    • Leadtime to Launch
    • Leadtime to fix bug
    • etc

人(スキル/スタンス)

  • LEANSTARTUPの理解
  • プロダクトマネージメントの理解
  • PDCAを回すスキル
  • MVP設計スキル(仮説を検証するための必要最低限の実装)

ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi

Nintendo switch初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。

Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた

もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。

新規事業が対峙する現実からエンジニアリングを俯瞰する

www.slideshare.net

新規事業が対峙する現実というものを、

  • ビジネスモデル
  • ビジネスフェーズ
  • ビジネス仮説検証プロセス
  • 予算計画のリズム

として、そこからエンジニアリングを俯瞰して見てみるという構成になっております。 基本的に以前書いたブログ プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #postudy - @i2key のBlog新規事業のグロース期を支えるエンジニアリングについて - @i2key のBlogの焼き直しに近いイメージになります。簡単にスライドの補足を以下に書いていきます。

リーンスタートアップスクラムの全体像

f:id:i2key:20170305110929p:plain

新規事業における顧客開発プロセスリーンスタートアップの仮説検証サイクル(BMLループ)、またスクラム開発をひとつにまとめるとこのようになります。一旦、ビジネスがどういうフェーズで進んでいて、そのために自分たちのエンジニアリングはどう関わるのかというポイントで全体感を頭に入れておくと見通しが良くなると思います。結局はプロダクトバックログ(PBL)に入ってくるものの源流はビジネスフェーズにおける仮説検証内容になるので、そこからエンジニアリングが見えるようになるとエンジニア側から提案が出来るようになったりします。例えば、GitFlowでやっていたが、GithubFlowに変えたい。だからエンジニア工数を一部そっちの改善に割きたい。とビジネス側に提案したとしても意味不明すぎて議論にならないと思いますが、現在、Releaseブランチの運用において、複数の機能追加が合流してからリリースする流れになっており、他の機能追加の実装速度に引っ張られて他の機能もリリース出来ない状況になっている。学びに対するリードタイムが増えているため、個別に出来上がったタイミングでリリースできるようにしていき、学びに対するリードタイムを最小化したい。と提案してみるとか。そこら辺については、リソース効率とフロー効率の話で簡単に言及いたします。

ビジネスモデルからエンジニアリングを俯瞰する

いろいろなビジネスモデルがあるなかで、それらのパターンを網羅して理解するにこしたことないのですが、エンジニアとして一番簡単な方法としては、どこで売上が発生しているかを見極めることだと考えています。

  • エンジニアの書いたコード上で売上がたつパターン
  • エンジニアの書いたコード上以外で売上がたつパターン

エンジニアの書いたコード上で売上がたつパターン

f:id:i2key:20170305111542p:plain ここでは成果課金広告モデルを例としてあげています。例えば旅行予約サイトで、ユーザーが宿の予約をとると、クライアントの宿主様から予約に応じて広告費が支払われるようなモデルです。これを画面遷移レベルで見てみると、サービスのトップ画面に流入したユーザが、検索条件入力→検索結果の一覧画面→詳細画面へと進んでいき、最後に予約ボタンを押すような流れになるかと思います。更にコードレベルで見てみると、最終的には、if(isBooked)条件内の処理が実行されることで予約が成立し、そこで売上が発生することになります。要するにif(isBooked)ロジック内に流れてくるユーザ数を最大化すること=画面のUI改善つまりはコード改善そのものがファネル通過率の向上、CVRの向上=売上の向上につながる構造になっています。

整理すると、エンジニアによるプロダクト改善が売上目標に直接寄与するため、エンジニアがこのサービスの成長のエンジンになりやすいです。そして、エンジニアのビジネス貢献が可視化しやすいということは、数値目標を持ったプロダクトチームがじゃんじゃん改善サイクルを回すと売上に貢献できるという良いサイクルがつくりやすいです。言い換えると、アジャイルとか超導入しやすい座組(結果が売上で出る)になります。また、サービスの開発を外注依存のような組織が内製化をはじめる場合は、こういうビジネスモデルのものから着手していくと成果が出やすい部分になります。 キラキラして見えるようなエンジニア文化がある会社のビジネスモデルを見てみると、こういうモデルのパターンが多いように感じます。エンジニアが競争力直結なのでそりゃエンジニアの待遇がよくなるはず。逆に営業が競争力直結なビジネスなのであれば、営業が最も働きやすい構造になるかと思います。

エンジニアの書いたコード上以外で売上がたつパターン

f:id:i2key:20170305111555p:plain ここでは純広告モデルを例としてあげています。例えば、広告枠をアプリとして提供しているけれどもあくまで枠(及び期間)の固定金額でユーザーのコンバージョンの有無に関係なくクライアントにお支払いただくようなものになります。例としてあえて、前述と同じマッチングモデルで説明しているため若干苦しい部分はありますがご了承ください。このモデルの場合、画面遷移的に、サービストップ画面に流入したユーザが最終的に詳細画面に到達し、予約のようなコンバージョン行動を取ったとしても売上は発生しません。クライアントからは出広料として既に固定額でお金をお支い頂いているからです。そのため、コードレベルでみても、if(isBooked)条件内の処理が実行されたとしても売上は発生しません。ここが「エンジニアの書いたコード以外で売上がたつ」と表現している理由になります。つまりは、UI改善等のプロダクト改善をエンジニアリングで行っても売上には数値として効果が直結はしない構造になっています。

とは言え、エンジニアリングが何も貢献していないのかというと、そうではありません。営業が売る場合の顧客単価あげる(クロスセルやアップセル)ための商品開発を行い貢献することが出来ます。しかしながら、ここらへんの貢献についてエンジニアがビジネス貢献をうまく説明出来ない、もしくはビジネス側が理解してくれないと、関係性が歪んでいきエンジニアはQCD目標のみに極端にフォーカスされていく場合があります。

f:id:i2key:20170305133422p:plain

エンジニアのビジネス貢献が可視化しにくいとどうなるかというと、トラブルだけが目立つようになります。そして、できて当たり前(減点主義)パラダイムになっていき、エンジニアはコスト削減や生産性向上のようなビジネス指標から程遠い目標設定になります。結果的に、QCDSの制約の雁字搦めになるので、エンジニア側は壁を作りディフェンシブになりだします。本来、俊敏に仮説検証回したい目的に反して、組織がスローダウンしていくことになります。放置していると、社内なのに受発注の関係性になってしまいます。

そうならないために、ビジネス側・エンジニア側が共通の目標を持ち、それぞれの貢献が可視化できるようにする必要あがあります。そこでポイントなのはその目標に対して、それぞれが結果に影響を与えられるレベルで管理することです。エンジニアリングで直接影響を与えられるビジネス指標は何かをビジネス側と一緒に検討し合意形成していくことになるかと思います。いわゆるKPIツリーやOKR等がそこらへんに当たるかと思います。

ビジネスフェーズからエンジニアリングを俯瞰する

f:id:i2key:20170305111815p:plain ここでは、ビジネスフェーズからエンジニアリングを俯瞰します。フェーズと言っているのは顧客開発プロセスでいうところの、顧客発見→顧客実証→顧客開拓→組織構築、ランニングリーンでいうところの、ProblemSolutionFit→ProductMarketFir→Scalingをさしています。

顧客発見フェーズ(Problem Solution Fit目指す)

深い課題を抱えた顧客はいるか、その課題の解決策は妥当か、その結果、独自の価値提供が出来るかというポイントで検証していくことになります。本当のところは細かいプロセスがありますが、すごくざっくり言うと、ビジネス指標としての例としては、継続率を見たりします。継続しているということは、このサービスは顧客の課題を解決し続けているから顧客はこのサービスを使い続けるということが出来るからです。ここでターゲットになるユーザーは基本的にアーリーアダプターなので、ある程度のことは許容してくれるので、当たり前品質や性能品質にはこだわらず、魅力的な品質のみに特化したMVP実装をしていくことになります。MVPも検証したい仮説に応じて必要最低限のスコープが変わっていくことがポイントです。ここでの必要最低限は、「課題解決可能かどうかを検証するための必要最低限」になります。

顧客実証フェーズ(Product Market Fit目指す)

このフェーズでは、プロダクトがマーケットにフィットするかを検証することになります。言い換えると、顧客は本当に買ってくれるのか、コスト構造に無理が無いかを見ていくことになります。具体的には、顧客獲得コスト(CAC: customer acquisition cost)<顧客生涯価値(LTV: Life time value)が成立すること。この際のエンジニアリングとして求められる品質レベルは、最低限の売れる状態。MVPの定義の必要最低限が今度は「売れる」にかかります。そのため、最低限の性能品質、と当たり前品質が必要になります。

顧客開拓(Scaling)

顧客開拓フェーズでは、今までアーリーアダプター対象だった製品を一般のユーザまで広げていくことになります。そのため、今までより広いユーザセグメントに売れることが要求されます。競合よりこの製品を選んでもらう必要があるので、アップセルやクロスセルに向けた性能品質や当たり前品質が求められていきます。 また、このフェーズになると既にユーザが多くついていることになりますが、そのような状況下において製品をつかって仮説検証を継続することになるため、インフラ要件としては、既存ユーザに影響を与えずに仮説検証が出来るような仕組みが必要になってきます。具体的に言い換えると、既存ユーザと新規ユーザを分けて検証するためのコホート分析の仕組みや、セグメントに応じて機能を出し分けるようなA/BテストやFeatureFlagの運用等です。そして、それらを支えるビルド、デプロイ、モニタリングのエコシステムになるかと思います。   f:id:i2key:20170305143659p:plain

いわゆるDevOps系のプラクティスですね。

ビジネスフェーズにおけるエンジニア像

f:id:i2key:20170305111830p:plain 前述の各フェーズを乗り越えていくのに際して、上記のようなエンジニア像が見えてきます。顧客発見フェーズにおいては、エンジニアといえどもソリューション片手にユーザインタビューに行くこともあります。エンジニアという枠に縛られずにマルチロールで動けるような人材がパフォーマンスを発揮しやすいと思います。顧客実証フェーズにおいては、ビジネス目標を達成するために、自ら手段を考え、その結果必要であればサーバのアルゴリズムを弄るし、フロントへの改善が必要であればiOSでもAndroidでも弄るようなフルスタックな人材が必要になるかと思います。なんせ、領域特化した専門家だけを集めるような余裕はまだないので。余談ですが、ここらへんはなぜフルスタックが良いのかについて別途スライド上の別のページでも取り上げていますが、待ちのムダや引き継ぎによるムダが省けて結果的にフロー効率がよくなる(顧客からのフィードバックを得るまでのリードタイムが少なくなる)という効果もあったりします。 f:id:i2key:20170305144638p:plain

話をもどしますと、つぎの顧客開拓フェーズにおいては、広げていくカスタマーセグメントに応じて必要な性能要件や品質要件が上がっていきます。仮にtoC商品をtoB商品へのアップセル目的で上げていく場合、それ相応のセキュリティ要件が出てきたりもします。そのような場合には、やはり専門性を持ったエンジニアが必要になってきます。各分野のプロフェッショナルがそれぞれの目標を達成すべく貢献していくような構造になります。その中でも、特定領域の神のようなエンジニアも競争優位としても必要になると思います。

リソース効率とフロー効率について

エンジニア目線だけでいると、どうしても稼働率をベースに考えてしまいます。しかしながら対峙している新規事業においては、如何に早く顧客から学びを得るかがポイントになってきます。そうなってきたときに、「効率が良い」という言葉の意味を考えないといけません。

f:id:i2key:20170305150156p:plain

  • 稼働率という意味で効率が良い(リソース効率
    • 大量の機能を同時に実装しておりチームとしての稼働率は非常に高い。稼働率という側面では効率が良い。しかしながら同時にたくさんのことをしているので、結果的にリリースまでのリードタイムは長いため、学びを得る側面で見ると効率が悪い。
  • 顧客から学びを得るまでのリードタイムにおいて効率が良い(フロー効率
    • まとめて同時に複数のことはせずに一つの機能の実装のみをチームで行っている。場合によっては、仕事がなくて遊びが発生してしまう人もたまにいる。稼働率そいう側面だと効率が悪いが、リリースをして学びを得るという側面だとリードタイムは短く効率が良い。

顧客から早く学びを得るにはまずはリソース効率ではなくフロー効率を重視したほうが学びのない期間を作らずに済みます。

リソース効率からフロー効率に変える方法のひとつとして「マルチタスクをやめる」ことがあげられます。それを図解したものが以下になります。 f:id:i2key:20170305151846p:plain

これは極端な例ですが、A機能、B機能、C機能のすべての機能追加タスクがそれぞれ15人日かかる場合。同時進行するとすべてのリリースまでのリードタイムは3週間になります。逆に一つずつ終わらせていくと、A機能は1週間、B機能は2週間、C機能のみが3週間というリードタイムになります。AとCが仮に相関が強かった場合は、Aの結果を踏まえてCの開発をやめることも検討できます。このように、同時にやることで様々なムダが生まれていたりします。現実はこんなシンプルではないですが、「一個流し」を意識することでいろいろなムダが除けるので、リリース計画においてもビジネス視点を持つことは重要だったりします。

他にはペアプロとかもリソース効率ではなくフロー効率を上げに行くプラクティスだと認識しています。モブプログラミングなんて完全にフロー効率に振り切っている。重要なのは、二人で別々の機能の仕掛中在庫を作るのではなく二人で1つの在庫を早く出荷することに重きをおいていること。また、副次効果として、知識の流通が同時に行われるため、1機能について2人の仕様理解者が同時に生まれる。つまりは引き継ぎによるムダが減るという様々な効果があったりもします。

さいごに

基本的にスライドを見てもらえれば内容はわかるとは思いますが、補足部分をブログに記載させていただきました。 また、今回は貴重な機会を頂き、市谷さん、新井さん、鍋島さんありがとうございました。 登壇を誘って頂いた市谷さんがFouderをしているDevLoveというコミュニティは自分にとって大きな転換ポイントの一つで、かつて参加したHangarFlightというイベントの余りにもの厨二感に良い意味で感化され、絶対この場に発表者として帰ってくると誓い、その後のDevLove現場甲子園(東日本大会)と名を変えたイベントに登壇。そこでの内容を評価していただき現場甲子園の日本シリーズに登壇。そして、その内容をコピペしてデブサミ2015公募に応募。公募なぜか通る。偶然にベストスピーカー賞いただく。夏サミの登壇依頼いただく。スピーカーつながりとかでいろいろな人と知り合いになる。困ったときに助けてとお願いすると、色々教えてもらえるようになる。アウトプットするといろんな人がインプットくれるようになる。そんな中、デブサミ2017のコンテンツ委員の打診いただく。面白そうだからのっかる。こんな講演ききたいなあという思いの説明用にポエムをブログに書いてみる。そういう話してみませんかと今回の登壇の話へとつながる。登壇するために、適当なこと言えないので、いろいろな1次ソース文献を読み漁る。更に理解が深まる。という流れの最初の一歩目はDevLoveというコミュニティとの出会いにあったと思っています。自分はPapanda氏に越境をenergizeされたひとりです。まことに….感謝ッ…!!!

f:id:i2key:20170305152805j:plain:w300f:id:i2key:20170216170716j:plain:w300

新規事業のグロース期を支えるエンジニアリングについて

このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。

はじめに

現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。

前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp

現在のビジネスステージ

f:id:i2key:20161204225836p:plain

上記はAsh Maurya氏のRUNNING LEANとSteve Blank氏のSTARTUP MANUALにおけるビジネスフェーズを図にしたものになります。はじめは、MVPを作ってはぶっ壊し、捨てて、またMVPを作ってはぶっ壊しの繰り返しでProblem Solution Fit(PSF)前は過ごすかと思います。可能な限り作らないで検証できたほうがよいのでエンジニアもインタビューに行ったりもします。そして、PSF後あたりから、Product Market Fit(PMF)させるためのもう少し真面目()な製品づくりが始まります。本ブログでのスコープ(赤い帯の部分)はPSF後、PMF目前もしくはその後のScaleフェーズにおける仮説検証を支えるエンジニアリングについて言及させていただきます。どうしてもPSF前のアーリーステージは作っては壊すの繰り返しなので、カウボーイスタイルになってしまっても仕方がない部分はあると思い。

f:id:i2key:20161204224435p:plain

上図は狩野モデルという品質モデルになります。狩野モデルでは魅力的品質、性能品質、当たり前品質に分けてそれぞれの品質特性を説明しています。PSF前のアーリーステージでは、顧客が存在すること、その顧客が深い課題を抱えていること、そして、それを解決することで得られる価値(ユニークバリュー・プロポジション(UVP))が実証できればよいので、基本的にアーリーアダプターを狙って検証しにいきます。アーリーアダプターは、当たり前品質は別になくても気にしないセグメント(脳内で補完してくれる)なので、UVPの実証にフォーカスします。

しかしながら、次のフェーズのPMFを狙うには、そもそも商品が売れなくてはならないため、当たり前品質も必要になってきます。魅力的品質のみに特化したMVPだけで売れるなんて幻想です。サービスがうじゃうじゃ出ている昨今において、シンプルなMVPだけで済むなんてそんな簡単な話ではありません。MVPが何に対する「必要最小限」なのかは検証対象によって変わることを理解するのが大事です。仮に、「本当に売れるか」を検証したい場合は、競合の機能も当たり前品質になってしまっているのであれば、必要になります。PMFでLTV(Life time value) > CAC(Customer Acquisition Cost)の検証をするために、価格設定の検証をするのであれば、まずは買ってもらわないといけないので同様に当たり前品質が必要になります。各フェーズ毎に検証したいことに応じた機能設計が必要です。 そして、ここらへんからチームメンバの人数も増えるし、ユーザー数もある程度増えてきており、今までのように簡単に機能追加やリリースができなくなってきます。しかしながら、仮説検証はまだまだ続くので、その速度をスローダウンさせることなく、むしろ高速化させていかねばなりません。

グロース期を支えるエンジニアリングの目指すべき状態

前述の状況をまとめると、このフェーズでは、当たり前品質を確保しつつ、ユーザーが既にいる状態で売り物で仮説検証をしていくことになります。そのため、エンジニアリングとしては、既存のユーザーベースを壊すことなく安全に仮説検証が出来るしくみを作ることが重要です。そしてトライするスピードをスローダウンさせることなく更なる仮説検証の高速化を目指すことになります。(仮説検証フェーズにおいて、どれだけ効率よく学べるかが最重要であるためです。)そこで、単純化するための仮説検証の速度と質という2つの軸に分けて考えます。

  • 仮説検証の速度を最大化
    • 手っ取り早いのが、デプロイ回数/日をチームの目標におき、それを高速で回せる状態に持っていく。しかしながら2週間に一回リリースなのであれば、10営業日に1回なのでデプロイ回数は0.1/日である。
  • 仮説検証の質を最大化
    • ニーズに合致していないものを高速で排出しても、高速うんこ製造機になるので、仮説の質を上げるためにエンジニアができる取り組みも行う。
    • 既存のユーザーベースを壊すことなく安全に仮説検証の実験を行うための仕組みづくり。

仮説検証の速度を最大化

すごくラフですが以下のような開発プロセスのバリューストリームマッピングを例にします。LTはリードタイムを表しています。リードタイムとはプロセスが作業を受け付けてから、下流のプロセスに渡すまでの時間になります。PTはプロセスタイムで、作業者がひとつの作業項目を完了するのにかかる時間です。そして実際に価値が作り込まれているのがこのプロセスタイムになります。実際のところは[PT = Value Add Time(VAT) + ムダ ]であり、 本当に価値を作っている時間はその一部になります。そのため、前述のデプロイ回数/日を増やすのであれば、この図の赤い部分をまずは改善することになります。 f:id:i2key:20161207025451p:plain

デプロイ回数/日を目標におくと何がおきるか

  • デプロイまでの赤い部分のリードタイムやプロセスタイムを減らしたくなる。VAT=0のプロセスは価値がないので消し去りたくなる。
    • 最初はエンジニアリングでムダの部分を所々自動化する
    • しかし技術でどうこうだけではすまなくなる
    • プロセス改善することになる
    • 複数の要件を同時に実装していくと、タスク切り替えのムダが発生することがわかり、バッチサイズ(このフローに流す作業のサイズ)を小さくすべきことに気づく
    • インフラ担当とかアプリ担当とかの作業の引き継ぎにもムダがあることがわかる
    • チーム間等の意思決定がボトルネックになる
    • チーム内で担当を決めるのをやめて、なんでもやるほうが待ち時間によるムダがなくなり、はやいと感じ始める。
    • 結果的にチーム外でも同じことがいえ、組織改善まで波及する
    • そのために、付随してアーキテクチャの見直しまで発生する
    • それに合わせて責任と権利の所在が変わる
    • 継続的デリバリーの組織的な母体が出来上がる

以下はちょっと古いですが、以下が丁度Facebookがデイリーリリースに切り替わったころの周辺の各種プラクティスのマッピングになります。こういうものも参考にしてもよいと思います。結果的に、最近のDevOpsプラクティスとかぶるとは思いますが。 f:id:i2key:20161206020129j:plain Facebook's Trunk Based Development (take 2) から引用

そして、以下が自分が担当しているチームでのやるべきことをリストアップしたものになります。これを元に、最上位のレイヤー(デプロイ回数)をチームの目標としています。箇条書きで醜くて申し訳ありませんが、そのままコピペしておきます。

仮説検証の速度の最大化(チーム目標:デプロイ回数/日)

  • プロセスタイムの削減
    • 個人の開発スキル向上(若手とかはここらへんも目標にするとよい)
      • スキルマップ
      • ペアタスクによる学習
    • プロセスタイム増加の要素を増やさない
      • 技術的負債つくりこまない
        • 静的解析によるゲートウェイ
        • コードベースを小さくシンプルに保つ
          • 機能を増やさない
            • 機能毎のMAUやDAU等も見て判断できるようにする
          • コードレビュー
            • コードレビュー負荷軽減
              • 小さなプルリク
        • 無理なリリース計画を置かない
  • リードタイム削減
    • 組織改善
      • クロスファンクショナルチーム
        • 部門間の引き継ぎのムダを省く
        • 部門間の待ちのムダを省く
      • フルスタックエンジニア
        • チーム内の個人間の引き継ぎのムダを省く
    • プロセス改善
      • 大きなバッチサイズから小さなバッチサイズへ
        • タスクを管理するのではなくペースを管理する
          • カンバン、スクラム
            • タスク切り替えのムダを省く
          • リリースカレンダー
          • WIP制限
          • スコープボックスではなくタイムボックス
          • プル型のタスク管理
      • 自動化
        • 直接顧客価値を作らない作業(Value add time = 0)の最小化
          • 継続的インテグレーション
          • テストコード維持(悪化させない)
          • インフラコードを維持(悪化させない)
          • デプロイ自動化
          • 分析・集計自動化
        • 各種マーケ施策の自動化
          • マーケ担当者がエンジニアに依頼して、エンジニアが作業をするようなケース。同様の依頼が複数回発生したら運用を自動化する。
            • 特定のセグメントに対して通知やメール送信をしたい。
            • 特定のセグメントに対してキャンペーンコードを発行したい。
              • 引き継ぎによるムダ/待ちによるムダの排除
          • 営業担当者からの依頼のケースも同様
  • 安定運用
    • 未然防止
    • 事後対応
      • トラブル対応フロー
        • 障害レベルの切り分けロジック
      • etc

仮説検証の質を最大化

前述のバリューストリームマップを同様に用いて説明します。仮説検証の質という観点で最も大事なのは、このプロセスのフローに投入する玉の質、つまりは仮説の質が良いことです。ニーズに合致していないものを高速で作れたとしてもゴミを生むだけで、しかもそれだけではなく、コードベースは肥大化していき機能が使われないどころか自分たちの生産性までも下げることになってしまいます。これはまさに余分な機能のムダになります。それを防ぐためにもエビデンスに基づく仮説構築の支援をエンジニアリングにて実施する必要があります。基本的には、各種分析基盤の実装です。また、各仮説検証の結果をパラレルで走っている検証の結果が混ざって濁らないような効果測定も必要です。

また、既存のユーザーベースを壊すことなく安全に仮説検証の実験を行うための仕組みづくりも必要です。具体的にはユーザーを任意のクエリや属性にてセグメントする仕組み、また、そのセグメントに対してリリース機能の出し分けをする仕組みが必要です。そしてそのセグメント毎に公開した機能単位で分析ができることが必要です。ここらへんの仕組みは最近ではSaaSを使えば大抵オールインワインで備わっています。これらの仕組みがある状況であれば、仮にリリース後に問題が起きた場合も、機能単位で切り戻しも可能になるため、欠陥によるムダ への対策にもなります。

f:id:i2key:20161207025657p:plain

以下に仮説検証の速度の最大化と同様に質に関するやるべきことの箇条書きをコピペしておきます。

仮説検証の質の最大化

  • LEARNの質
    • 仮説の質
    • ユーザーフィードバック
      • 各種分析
      • カスタマーサポート記録のデータベース化
  • MEASUREの質
    • 計測の基盤があること
      • ダッシュボード
        • ビジネス&システム
          • BMLループの時間(学ぶまでのリードタイム
            • プロダクトバックログに起票されてから、検証されるまで
        • システム
          • 各種システムパフォーマンス
            • CPU/NETWORK/RESPONSE/etc
          • ビルド時間
          • 自動テスト時間
          • デプロイ時間
        • ビジネス
          • ファネル分析
            • 離脱率(or Churn Rate)
              • P/S FITにおけるズレの側面
                • ファネルに流すユーザの質に左右される
              • エンジニアリングで改善可能な部分
          • コホート分析
            • カスタマーセグメント毎の各種数値
              • 流入経路別の各種数値
                • ノイズを排除し純粋にプロダクトの力を計測する
                  • 営業/マーケ獲得セグメント別の結果等
            • リリースバージョン毎の各種数値
            • 実装機能毎の各種数値
          • Gross Revenue
          • LTV/CACグラフ
            • ユーザーセグメント毎のLTVとCACの関係性
          • Churn rate
          • その他各種KPI
    • 安全な検証環境
      • 既存のユーザへの影響を最小化
        • ユーザーをセグメントする機能
          • ウェブコンソール上でSQLないしUIにて、特定の条件に関するユーザセグメントを作ることができる
      • Feature Flag
        • ユーザーセグメントに対して機能の出し分けを可能にする
          • Private Beta Test
          • Dark Launch
      • A/Bテスト基盤
      • カナリヤテスト
      • ブルーグリーンデプロイメント
  • BUILDの質

まとめ

本ポストでは、便宜上バリューストリームマップの例で解説をしていましたが、本来は各チーム毎にバリューストリームマップを作成し、ボトルネックになっている部分を探し、解消することが大事です。例えば、ボトルネックじゃない部分をいくら解消しようが実は全体的には効果がないこともあります。そしてボトルネック解消には時には技術以外での解決策も必要であったりします。個人的には、TPSや制約理論を学ぶのが最も効果があると思います。そして、それらを意識しながら、下記を実現していくことになると思います。

  • 当たり前品質を確保しつつ、ユーザーが既にいる状態で売り物で仮説検証をしていくため、エンジニアリングとしては、既存のユーザーベースを壊すことなく安全に仮説検証が出来るしくみを作ること
  • トライするスピードをスローダウンさせることなく更なる仮説検証の高速化を目指すこと

以上です。

プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #postudy

本ポストは特に私が所属する組織の見解ではなく、私が今までの経験&自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。

内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える

昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス価値を生みやすく座組が作りやすいです。仮にはじめての内製化やアジャイル化みたいなことをするのであれば、そういうところから始めるとよいです。」みたいな話を軽くしたのですが、あまりにも軽くしすぎたので補足をブログにしてきます。

System of Engagement(SoE) と System of Record(SoR)

ここらへんの議論については、最近、Ito Naoya さんがSoEとSoRの話をしてくださっていて、共通認識として広まってきてる感があります。掻い摘むと、顧客とのエンゲージメントを高めるためのシステム(SoE)と、記録のためのシステム、いわゆる基幹系システム(SoR)にわかれ、それぞれに応じて、適切なマネジメントスタイル、組織、方法論、技術選定、開発プロセスを取るべきであるという話になります。SoEかSoRかというわけではなく、それぞれの要素のグラデーションでバランスよく考えましょうという話ですね。

https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement#5

その上で、SoEは仮説検証型、アジャイル型寄り。

しかしながら、もう一歩踏み込んで、更にビジネスモデルという切り口で見てみると、更に霧がはれていきます。

エンジニアの書いたコード上で売上が発生するようなビジネスモデル

例えば、SoEの中にトランザクション(従量課金モデル)の要素がある場合は、その部分から仮説検証型、アジャイル開発型としてトライすると良いと思います。 簡単に言い換えると、プロダクト上でユーザーが課金するもしくは、プロダクト上のユーザの行動によってクライアントからお金が支払われるようなモデルです。もっと、極端に言い換えると、エンジニアの書いたコード上でユーザーのコンバージョンが発生してお金が儲かるモデルです。この場合は、エンジニアが成長のエンジンになりやすいケースです。だってエンジニアのコード(UI、パフォーマンス、アルゴリズム等)が良ければ良いほどコンバージョンを生み、売上があがっていくので。 つまり、そのようなビジネスモデルのケースでは、数値責任をもったチームが仮説検証サイクルを意識してアジャイルに回すほうが売上貢献しやすいです。言い換えると、エンジニアのコードの改善が売上に直結寄与しやすい。これがビジネス価値をエンジニアが作り出していると言いやすく、説明責任を果たしやすいです。

この領域は、たとえば、ソシャゲとか、デーティングとか、ECとか、toC課金のモデルの多くであり、ネット系とかウェブ系と言われている部分の多くです。また、toBとかでいうと成果課金広告とか、アドテクとか、SaaSとかがそれになりますね。SaaSの場合は、チャーンレートが重要になってきます。または裏返しで継続率ですね。それが毎月の売上に直結します。

500StartupsのDaveが提唱しているAARRRモデルがありますがこれが一番イメージしやすいです。

f:id:i2key:20161127232130p:plain

これは勝手に私が書き換えたものですが、Churn(水漏れ)も追加しています。広告等でユーザーを獲得してきて、一定量がアクティベーションせずに離脱して、残りが継続利用してくれて、でもまた徐々に下に漏れていって、継続利用してくれるとどんどん売上が立っていってみたいな流れです。つまり、ここの水漏れをエンジニアリングで防ぐことでも、売上に直結させられます。本質的な継続率は、顧客の課題を解決し続けている必要があるのでそもそものサービスの価値の議論にはなるかと思いますが。まあ、つまりは、改善サイクル(リリースまでのリードタイム)が高速化するとビジネス価値を生みやすいということです。かつて言われていたグロースハッカーがまさに活躍する領域です。

ここからは妄想ですが、そのため、成果課金・従量課金・月額課金モデル等をベースとするエンジニアの書いたコードの上で売上が立つウェブ系なスタートアップ界隈やソシャゲ界隈などなどはアジャイルを採用することが多く、あわせてエンジニアの労働環境も良くしやすく、オフィスもエンジニア最適化されたり、エンジニアは好きなディスプレイ、マシン、キーボード、椅子で自由に働いている。そして給料も良いのでは。エンジニア達こそが競争力の源泉になるので。という構造になっている(なりやすい)かと思います。妄想ですが。

エンジニアの書いたコード上で売上が立たないビジネスモデル

それに対してSoEの中でも、逆に、エンジニアのコード上で売上が発生しないモデル。 例えば、営業が商品(製品、純広告、etc)を売ってその商談で売上が立つようなモデルとかだと、ある意味、成長のエンジンはエンジニアではなく営業力になる(スケーラブルかどうかの議論はおいとく)ケースが多いです。

ここでエンジニアが価値を出すポイントは、商品開発(パッケージソフト商品、純広告商品等)になるパターンが多いと思います。(営業支援ツール等のSoRなバックオフィス系は一旦省きます)

エンジニアリングは魅力的な売れる商品を作ることと、営業の顧客単価をどうあげるかに寄与するパターンになります。そしてエンジニアの開発した新たな商品によって顧客単価があがるのであれば、それは素晴らしい成果になります。例えば、顧客単価を上げるために、オプションプランで追加課金するような機能を追加するとか、SMB向け商品等でアップセルを狙うためにエンタープライズの大口顧客に売るために、エンタープライズ特化の機能を追加するとかになります。しかしながら、このモデルでは、定量的なエンジニアのビジネス貢献度が前述の従量課金モデル等に比べ見えにくくなってしまうため、アジャイル化する前にまずはエンジニアのビジネス貢献を定性的にでも見える化する必要があります。絶対やるべきです。 そのための一つのやり方としてAlignmentMapというものがあります。こちらもちょうどプロダクトオーナー祭りにて言及されている方がいました。 martinfowler.com

前述のトランザクション課金モデルだとKPIツリーを分解していけば、最終的にCVR改善等のプロダクトチームのエンジニアタスクに落ちやすいので、定量的にビジネス貢献度を出しやすいのですが、非トランザクション課金モデル、非SaaSモデルでも定性的にビジネス貢献を可視化することはこれで出来ます。これをやることで開発タスクがそれぞれどんなビジネス貢献に寄与するのかをエンジニア自身が把握することもできるし、ビジネス側も意味なさげに見える技術的負債の解消や性能改善等のエンジニアリングとビジネスの関係が見えるので色々やりやすくなります。AlignmentMapとか名前ついてますが、一般的な組織では当たり前のようにこういう構造化はしているとは思います。運用の仕方についてはリンク先を読めばわかるかと思いますので省略します。定期的にビジネスサイド、エンジニアサイド両方での振り返りを行い、一つのマップにマージして議論するのがポイントです。

f:id:i2key:20161127232159p:plain

AlignmentMap

SoEの各フェーズにおいて求められるエンジニアロールについて

また、前述のようなビジネスモデルでの切り口とは別の切り口で、内製化チームを作る場合、時間軸で見てみることも大事で、SoEのビジネスフェーズによって求められるエンジニアロールも変わってくるという話もしたので簡単にまとめておきます。ビジネスドメインによって差異はあるとは思いますので、あくまで考え方の一例として理解してください。

基本的には下記の図がすべてなのですが、説明しますと、初期ステージであればあるほど、なんでもやるよねという話です。MVPを作って実際のユーザーにインタビューしにいくかもしれませんし、営業にエンジニアも同行するかもしれません。そしてグロース期に入って、ビジネスコミットの強いフルスタックエンジニアは、グロースハッカーとして水漏れの補修をしながらKPIに寄与するエンジニアリングをしたりする。チーム自体がクロスファンクショナルであれば、別にフルスタックである必要はないと思いますが、フルスタックエンジニアであるほうが、リードタイムは少なくフロー効率は高いと思います。そして、P/M Fitを達成し、マーケにより流入を増やしたり、カスタマーセグメントを幅出ししたり、アップセル狙ったり、でトラフィックが増えてくるあたりで深刻な性能問題になやんだりします。ここらへんでは、今までの技術的負債をどうにかできるプロフェッショナル型のエンジニアが活躍してくると思います。

f:id:i2key:20161128160513p:plain

結果的に、午前のやっとむさんの発表に繋がったらしい。

まとめ

皆が置かれている文脈も違うため、すべてを包含してこうだとは言い切ることはできないのですが、伝えたかったこととしては、仮に内製化をはじめるとか、アジャイル化していくとか考えるときにどこから始めるとビジネス上の価値創出がしやすいか、成功確度が高いかをこういうふうに考えることも出来るよ、ということでした。 そして、その構造を理解した上で開発体制を組んだり、プロセスをきめたりすれば、よりエンジニアがビジネス貢献しやすい座組を整えやすくなるよという話でした。

そのため、自分がよくやるのは、例えば広告系なビジネスの場合であれば、営業資料があれば真っ先にそれを見せてもらったりします。そこで純広告を売っているのか、成果課金広告モデルなのかわかります。また、その比率も見ます。それでエンジニア組織のありかたを想像するキッカケになったりします。

別に今回記述した論理展開がすべての開発現場に当てはまるわけではないので、現場毎に自分たちのビジネスモデルと向き合い考える必要はありますが、こういう切り口でエンジニアのビジネス貢献というテーマで開発組織のあるべき姿を考えてみるのもよいのではないでしょうか。 こう考えることで、内製化すべきポイントはどこであるか、まずアジャイル化すべきポイントはどこであるか、エンジニアの評価制度にビジネス貢献度を入れるべきかどうかとか、色々考える際のとっかかりになると思います。

DevOpsはエンタープライズからスタートアップへの横恋慕 #devops #プロダクトマネージャー #leanstartup

DevOpsはエンタープライズのスタートアップへの憧れ

と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ?そもそもあってるっけと思いFacebookストーキングしたら違ってた。

"DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん

と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。

自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下(Dev部門、Ops部門、ビジネス部門、...and so on)においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近のDevOpsブームの前提が色々としっくりこないことがあったが、やっと先日のPoppendieck夫妻とMSの牛尾さんのバリューストリームマッピング研修に出たことで腹落ちした。実際はその研修の内容とはまったく関係ないのであるが、Maryの一切ブレないリーンの本質の部分に触れることで、よいキッカケをもらえたことに感謝している。

ちなみに私はDevOpsを以下のスコープ及びニュアンスで理解してる。勝手に理解してるだけなのでみんなの心の中のDevOpsを否定するつもりは微塵もない。TPSをみたり、リーンを学んだりでその流れでDevOpsを見てしまっているので、DevOpsというよりは、単純にリーンにバリューストリームを全体最適させる目線が強いかもしれないが。

  • 広義
    コンセプトをキャッシュに変えるフロー効率及びリソース効率を最大化する一連の実践
  • 狭義
    DevOpsは高品質を保ちつつ、システムに変更をコミットしてから、その変更が通常の本番システムに組み込まれるまでの時間を短縮することを目的とした一連の実践である。
    (こちらはDevOpsの教科書という本での定義である)

DevOpsのスコープとリーンスタートアップの仮説検証サイクル

f:id:i2key:20161030190452p:plain

私自身が、リーンスタートアップスタイルの仮説検証型でずっと新規事業をやってきた流れが強いので、そこからDevOpsに光をあてて理解していくのがとっつきやすいと思い、このような図になっている。小さくてわかりにくいかもなので補足すると、図の下部にある○の連なりは、IDEAS->BUILD->PRODUCT->MEASURE->DATA->LEARNと書いてあります。よくあるリーンスタートアップでのBMLループである。

狭義と言った部分が、すごくざっくりいくと赤い部分(BMLループのBuild部分)で、広義といったのが青い部分(BMLループ全体)になる。同時に赤い部分はエンジニアが直接結果をコントロールできる範囲であり、青い部分は利用者・ユーザの行動を介すことで結果に不確実性が伴う部分でもある。リーンスタートアップ等の仮説検証を効率よく回すという目線でみると、赤い部分はあくまでもBuild部分の最適化であり(一部Measureも入ると思うが)やや、狭く感じる。やりたいことは青い部分の仮説検証サイクルの高速化である。ここが新規事業畑だった自分が感じた違和感だった。赤い部分だけをDevOpsとして最適化しても、結局のところは、仮説のスジが悪いことでゴミを作り続けて出荷するムダ、また、良いものを作ったとしても、マーケのミスでユーザに届かないというムダが生まれてしまうのである。

シード期やアーリーステージでのDevOps

開発部門、事業開発部門みたいなような組織デザインではなく、ハスラーハッカー、デザイナーのようなチームで始まるド新規なサービス開発の場合。自分たちの持ち出しもしくは会社であれば少額のバジェットで開始するにあたり基本的にバーンレートが重要になる。 思い込みによるフルスイングでバーンレートを最大化させることよりも、小さく仮設検証型でやり失敗を小さくして学び効率を最大化させ、バーンレートを下げるスタイルとしてリーンスタートアップがある。 つまりは、ゼロから何か事業、サービスを始める場合においてバーンレートを下げつつ学びを最大化させようとすると1つの手段として仮説検証型になることになる。(起業家の嗅覚でフルスイングして、大当たりするケースもあるので、これは個人の自由である。)

仮説検証ベースの場合、価値観として最小工数で最大の学びが得られることが大事とされるため、極論、作らない。作るとしても表面だけで裏側のアルゴリズムは人力で回すとかになる。それでユーザーが価値を感じれば(コンバージョンすれば、継続利用すれば)あとから実装すればよいのである。いわゆるMVPによる実証である。 そんな感じでシード期は過ごすわけで、そこでその価値観に染まると、徐々にユーザーが増え始めてきてアーリーステージになり、シリーズAの出資を受けるフェーズになった際にも、仮説検証がベースのエンジニアリングになっている。

例えば、ある新機能をリリースする場合、新機能のリリース日から使い始めたセグメントの継続率と、従来ユーザの継続率の比較をするケースがよくある。継続して利用されるということは少なからずユーザに何らかの使い続ける理由があるのである。つまりは、ユーザの課題をいずれかの形で解決している状態である。Problem-Solution Fit(PSF)といわれたりする。(余談ではあるが、結婚指輪のECをやるような場合は継続されると気まずいのでここはビジネスモデルによる部分ではある。)

そこで真っ先に入れることになるのがコホート分析である。

f:id:i2key:20161030190510p:plain

ここでのコホートは、新規利用開始日のコホートになっており、使い始めた日毎にユーザをセグメントしており、その毎日の継続率を示している。そのため、ユーザ獲得キャンペーン等を実施した日に他のリリース等の他のイベントを行わなければキャンペーンの本当の効果を測定できる。

しかし、この運用だと問題があり、毎回ユーザ全体に新機能をリリースすることで既存ユーザへの影響というリスクが発生する。毎回、機能追加が成果があるならよいものの大半は失敗する。そのため、最初は一部のユーザにのみリリースして実験したくなるのである。その結果フラグが必要になり結果的にFeature Flag運用になる。(既存と新規機能のA/Bテストの場合もある。) 結果として、自然とDevOpsのプラクティスとしての文脈ではなくFeature FlagやFeature Toggleベースの開発を行うのである。(ここでのFeatureFlagは本番へすべてのコードリリースの文脈ではなく、ユーザー毎の機能の出し分けON/OFF文脈である。) よくあるケースとしては、外部のSaaSを使うケースである。OSSもたくさんある。CookpadさんのChankoは有名である。他にはここらへんのサイトを見ておくとわかりやすい。 また、同時にユーザーのセグメント機能も実装することになる。そのセグメントに対してFeature Flagをオンにするために。 例えば、開発チームメンバだけに公開、次に、自社メンバ、次に、全体のユーザの数%のみとなる。 昨年度、協業して自分自身もエンジニアとして参画していた99designsでの実際のFeature Toggle運用はブログで公開されているので参考に載せておく。基本的にセグメント切りおよびオンオフはAdminコンソールにて行う。

また最近でいうとFirebaseがmBaasとして提供している機能郡とかも、非常に親和性は高い。
・Remote Config x Analytics(ユーザセグメント)で機能の出し分け
・上記結果をAnalytics(コホート分析)でセグメント単位で効果検証

f:id:i2key:20161030190621p:plain

https://firebase.google.com/docs/remote-config/

ここらへんのセグメント化 x 機能出し分けによる仮説検証は、アーリーステージにおいて、DevOpsのプラクティスとしてよくある各種自動化よりも先に実施される感覚がある。このフェーズであれば、部門もわかれておらずその場で会話すれば解決するようなピザ2枚状態だし、システムも重厚長大ではないため、そういう順序でも問題がないかはおいといて結果的に現場のオペレーションが回る。(重厚長大ではない状況で、先んじて諸々自動化しておくことが大事なのはわかっているが話が混ざるとシャープではないので振り切って話すことにする。また、現場の毎日が文化祭前夜感を経験している人にはビジネス価値 > 負債量産の状況はわかるはず。)

そういう意味で以下の牛尾さんのスライドにある主要なプラクティスとサブプラクティスの優先度がサービスをゼロからグロースさせてくると自然と一部プラクティスが逆転していたりする。DevOpsにこれをやれという絶対はないものの、通ってくる文脈によって導入するプラクティスの位置づけも優先度も変わるというのは当たり前といえば当たり前であるが面白く感じた。

f:id:i2key:20161030190521p:plain

https://docs.com/ushio-tsuyoshi/5912

アーリーステージでのエンジニアリングの優先度として、コードベースが複雑でなかったり、実験なので破棄することもあるため、細かい自動化による小さなムダの排除よりも、そもそも使われないモノを作らないことであったり、作ったものがちゃんとターゲットユーザに届く(認知される)ことであったり、ユーザが途中で離脱しないことであったり、そちらにパワーを割いたほうがトータルでムダが少なかったりするケースが多い。そこで、結果的にDevOpsとか意識せずFeature Flagだったり、仮説に基づく開発(運用環境でのテスト)が行われる。(サービスを安定運用させるために、自動スケーリングさせたり、パフォーマンス監視だったりは当たり前でやるとして。)

DevOpsが見る夢は、ワイワイやってたあの頃への回帰

最近DevOpsが語られるときには、エンタープライズDevOpsであり、基本的に負債や重厚長大なプロセスを持った組織の改善という文脈が多いが、そうじゃなくオーガニックに組織が成長していく過程だと上記のように、また違ったアプローチでDevOps(のようなものを結果的にやっていく)していくことになる。そこが個人的には今まで本やウェブ上の記事で感じていたギャップなのかもしれない。

冒頭にも書いたが、今回、Poppendieck夫妻の研修に参加し、組織やプロセス、技術に対してリードタイムを如何にさげるか、リソース効率ではなくフロー効率をいかに高めるかを考えるようになり、そこら辺がクリアになった。クロスファンクショナルチームとかスモールチームとかよく言われるがそれはあくまでフロー効率を最大化するための一つの手段なのである。

DevOpsが目指している本質は、「何かあったときに会議なんかせずに席の周りにみんな集まってその場で議論して進められてたあの頃に戻ろうよ」ということなんだなあと。 例えばアジャイルスクラム)で"開発チーム"があの頃に少しは戻ったとしても、それだけだと不十分で、インフラ、ビジネスサイド、営業、みんなでワイワイやってたあの頃に戻りたいんだろうなあと。

まさに、"DevOpsはエンタープライズからスタートアップへの横恋慕"である。

結果的には「コンセプトをキャッシュに変えるフロー効率及びリソース効率を最大化する一連の実践」である。

あの頃に戻るためには、いきなり戻ろうとするのではなく、今まで作り込んできた組織構造上のムダ、アーキテクチャ上のムダ、プロセス上のムダ、そしてそれらが複雑に絡み合った状態をほどいていく必要がある。(そういうふうにエンタープライズ下でのDevOpsでは考えるようにしている。)

そこで一つの取っ掛かりになるのが、散々語られているがバリューストリームマッピング(VSM)による現状把握と改善である。 VSMによる改善を回すと、真っ先に現場レベルでできることは基本的に自動化であり、その次にボトルネックはどうしても組織構造に移る。 その文脈の中で、様々な記事や文献でいわれているように、以下のような組織、プロセス、アーキテクチャリファクタリングが伴う。そのため、VSMによる改善活動を行う場合は、権限を持っている人の同席が必須である。

  • 組織デザイン
    • 権限をチームに与え、クロスファンクショナルでスモールチーム化:スタートアップ回帰
    • 責任と自由(権利)について
      • どこかは伏せるが自分が近くで見てきた例としては、売上を上げている単位のサービスでチームをわけて権限委譲&下記のマイクロサービス化をしていた事例がある。
  • アーキテクチャ
    • スモールチームで回せるサイズ(例えばマイクロサービス):スタートアップ回帰
      • どこかは伏せるがMSAにするのに15ヶ月かかってるのを見ていたりもするのでこれは大きな経営判断を伴う。
  • プロセス
    • 人による承認のようなゲート方式からパイプライン方式へ:スタートアップ回帰

そして、その結果チームは本当の意味での継続的デリバリーを手に入れることになる。

以下は、昔、夏サミで発表したスライドであるが、このときの内容はDevOpsとしてではないが、太字部分は結局DevOpsプラクティスで得られる効果そのものを指していたりする。

f:id:i2key:20161030190538p:plain

http://www.slideshare.net/i2key/devsumi-natsumic7

「あのころ」に回帰したチームにおいて、プロダクトオーナー/プロダクトマネージャーはmini CEOである

クロスファンクショナルなチームにおけるチームの責務はサービスのグロースであったりビジネス上のKGI/KPIの達成であるため、組織体としてもスタートアップのような何かである。エンタープライズ型の重厚長大なプロセス、セクショナリズムアーキテクチャ上の制約が仮になくなれば仮説検証を行うサイクルタイムは今までよりも早くなり、仮説を市場に問うリードタイムは最小化される。

それとともにプロダクトマネージャーの役割もスタートアップ帰りが起こる。DevOps関係なくそうだとは思っているが、DevOpsが機能しだすとより顕著である。 そして、馬田さんがPM = mini CEOとよくいっているがまさにそれである。

f:id:i2key:20161030190553p:plain

http://www.slideshare.net/takaumada/zero-to-product-manager

ここで一つ問題になるのが、お金である。 エンタープライズの場合、スタートアップのように都度資金調達していくスキームではなく、例えば、年次予算を組んで事前に計画を立て、その目標へのコミットとして翌年の予算が決まるモデルが一般的である。つまり、1年以上先の未来を予測&予測にコミットすることになる。計画が間違っていたとしても、その計画の達成率が評価になるのである。そこにはピボットは含まれないし、仮説検証による学びからの計画変更は加味されていない。結局、そこの年次予算のリズムが大枠のサイクルタイムになってしまう。 では、仮説検証型で細かくサイクルを回すためにはどうすれば良いか。 ここらへんは先日のバリューストリームマッピング研修にて、MaryやTomから簡単に説明があったり、やはりその後日のリーンエンタープライズの公園にてBarryも全く同様の話をしていたりで、要はBeyond Budgeting(脱予算経営)をしなさいというところだった。 (そんなこと簡単に言われてもさー。というのが正直なところではあるがそれだと当事者意識が低めなのでここでだけ言わせてもらう。そんなこと簡単に言われてもさー。)

かいつまんで説明すると以下である。

  • 年次の予算モデルからの脱却
    • 予算確保のための計画、予算調達、実行、振り返りが年次予算である場合、そのリズムになってしまう
    • 大企業は中央集権な予算管理モデルが、意思決定をまとめて行いやすいため効率的に見えるが、不確実性が高い状況下におてそれはフロー効率を下げることになる。
    • Beyond Budgeting(脱予算経営)
    • 大企業内の新規事業組織とかはほかからの干渉をさけるため出島化することは多い。

しかしながら、現場レベルでも今すぐトライできるやりかたを考えたい。上記に比べるとミクロ視点すぎるため、全体最適とまではいけないが。要は、一旦確保したバジェットの中で如何にムダな金遣いを減らすか。確保したバジェットでできる仮説検証回数を最大化させるかがポイントである。お金の使い方のリーン化である。手前味噌ではあるが、有効なお金の使い方をするのに良いフォーマットがある。

f:id:i2key:20161030190606p:plain

http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib

これをもとに仮説検証で学びたいこととそれに対するコスト、期間を見てメンバは責任者に決裁を取ることになる。都度、実験に対して決裁を取るので、組織として年次で確保したバジェットを小分けにして使いやすい。組織の事情を全く考慮せず言っているのであくまで一例としてではあるが。

さいごに

なぜこのタイミングでこんなことを突然語りだしたかというと、世の中で語られているDevOpsがビジネス価値ガーとかいうものの、ビジネス価値までスコープにはいってないではないかという疑問であり、そこらへんの整理をしたかったからであったりします。一見、DevOpsはただのエンジニアリングに見えるものの、結果的には実はビジネス上の不確実性を小さく効率よく取り除き、赤い線の部分の活動の効率化が、しまいには青い線の効率化に昇華する部分をうまく言語化したかったものの、少しわかりにくかったかもしれません。Feature Flagなんて特に青い線の部分の大失敗を避けるインフラであったりします。エンタープライズの中でリーンスタートアップのような仮説検証型でビジネスリスクを下げつつやる場合は、それ相応のエンジニアリングが必要でそれがDevOpsというワードで括っているスコープである理解になります。

あとは、こんな話を交えて

プロダクトオーナー祭り2016 ※2016/11/29更新 プロダクトオーナー祭りでパネルディスカッションで下記の話をしました i2key.hateblo.jp

Regional Scrum Gathering Tokyo 2017 パネル: DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ

にプロポーザルを出しているので投票してネ!という記事広告の目的もあるのである。 最後までおつきあいありがとうございました。

また、全体的に論点をシャープにするため、極端に表現している部分はあります。アーリーステージだって、自動化もするし、やらないわけではありません。両立させている素晴らしいスタートアップも新規事業組織もたくさんあります。というわけで、あくまでビジネスコンテキスト上での優先度として、どちらが最優先されるかという意味になっております。あしからず。

f:id:i2key:20161027212719j:plain:w400f:id:i2key:20161020091115j:plain:w400f:id:i2key:20161019175751j:plain:w400

Scrumはじめるまえの本質的な部分の話 #agile #scrum

チームをスクラムにしたいのですが

とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。

PO、SM、エンジニアの相互の信頼が一番大事。

信頼がポイント。それがない状態で始まると意味のない何かになりやすい。

最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。

そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕(PO)はそんな天才でもないので、80%の確度がやっとです。だからエンジニアの見積もりについても80%程度の確度のもので良いと思っています。だって僕からのインプットがクソだとそもそも正確に見積もれないですよね。これはよく言われている「見積もりはコミットじゃない」ということと同じになります。」とつなげる。

これがない状態でいきなりスクラムごっこが始まるとどうなるか。エンジニア(の契約形態による)がディフェンシブになってしまう。見積もりの精度を求められてしまうことになれているエンジニアはどうしてもバッファを見込んでしまう。これは本当の見積もりではない。つまりはチームが本当のパフォーマンスを出せなくなってしまう。

だから、「ビジネス責任者」から80%ルールの宣言をする。それがまず第一。ガードを下げる。信頼してもらう。

各プラクティスはその後の話である。

チームのためと思ったことがチームの生産性を下げることがある

また、「信頼」に起因して、いきなり個人のベロシティを計測することはやってはいけないという話をした。よくスクラム入門書みたいなものには、ベロシティガーみたいなのが書かれているが、これの意味するところはチームの生産性の可視化でよいことではあるもののあるリスクを含んでいる。また、更にそれで個人の生産性を評価しだすチームなどもある。はげしく危険。

信頼がない状況でやると、何が起きるか。

見積もりのサバ読みが始まる。もしくは、品質の低下が始まる。 自身のベロシティが自身の評価につながると思うと、多めに見積もったほうが生産性は高いマンになる。もしくは、見積もりよりも時間が掛かりそうな場合に、低品質でもおわりにしてしまえという考えが出てくる。 しかし、一概に必ずそうなるとはいっていない。

アジャイルの根底にはチームへの信頼というものがある。 その信頼が足りていないときに、これがおこるのだ。 「チームから解雇されるかもしれない不安」 「守るといっても結局まもってくれないのではないかという不信感」 「なんだかんだ見積もりにコミットになってしまうのでしょうという諦め」

そして、個人のベロシティ競争になってしまうと、さらに、相互のメンバ間の助け合いもおきなくなっていく。人のこと助けても自分のベロシティあがりませんし。と。

個々の生産性を可視化して改善して高めることでチームの生産性を高めようという思いが、逆にチームの生産性も品質も下げるという結果を招いてしまうのである。 (ラプラス憲章みたいなものですね。最初は人類の希望だったのに。それがこじれて戦争になってしまうという。)

なので、ベロシティを見るのはチームの単位まで。 皆の信頼関係があるような次のステップのチームであれば別に自由でよいけど。

みんながその働き方が好きであるわけではない

とはいえ、スクラムの本質は可視化であるため、どうしてもついてこれなくなる人は出てくる。みんながその働き方が好きであるわけではないことを理解しないといけない。ドライな世界だが、チームで成長していけるので、機能すればチームの生産性はスプリント毎に上がる。

そんなお話をした。

本当につたえたかったこと

この手のチームの開発プロセスの話は文脈(ビジネスモデル、商流、体勢、etc)の影響を強くうけるのでかならずこうであるとは言えないが、プラクティスを追うのではなく、人間の力学として、どういう判断をすると、どういうことがチームで起こるかということを考えるのが大事である。