Srcumとプロダクト

先日、Scrum Masterを取得した時に学んだ、プロダクト哲学のようなものについて備忘のため記載します。

いいプロダクト開発

サービスやシステムを開発している人なら誰しもが経験する、機能追加と保守開発のバランスについて

プロダクトを開発していると、成長期にはプロダクトオーナーや事業の要望で、無限の機能追加を求められます。
エンジニアとして価値を認めさせるにはその要望に答え、プロダクトの追加機能（すなわちユーザー価値として見える部分）の開発に多くのリソースを投入してしまうことになりかねません。

一方、都度降り注ぐビジネス要件に対応するために機能追加開発を繰り返していると、ソースやインフラのメンテナンス性が加速度的に悪化します。
（これはエンジニアの方なら感覚的にわかるかと思いますが、ビジネスサイドの人にこの肌感覚はありません）

そうすると、徐々に機能追加に要する時間が拡大していったり、品質不備による障害が発生したり、という負のサイクルに突入していくまで秒読み状態です。

エンジニアとして、長期に亘って高い価値を生み出すためには、ビジネス観点での機能追加と同じスピードで品質を高めるための活動を実施しなければなりません。

理想的には、バックログの構成は下記のバランスを保つべきです。

30%：ビジネス要件（ユーザー価値が見える機能開発）
40%：交渉調整枠（状況に応じて上下どちらかのチケット対応）
30%：品質担保（カバレッジ向上、リファクタリング）

このバランスで「いいプロダクト」をビジネス・技術の両輪で作っていくことが重要です。

スタートアップなどでこれから組織構築していく場合は意識しておくといいと思います。
（組織が醸成された大企業の場合は稟議通すなどして頑張ってください）

プロダクトを見渡す

複数のチームで開発を行なっている場合、各チームは（理想的には）自分のチームのパフォーマンスを最大化しようとします。

各チームのパフォーマンスが最大化されていれば、組織としてのパフォーマンスも最大化されているはずだ、と思うマネジメント層の方も多いかと思います。

しかし、これはすでに「部分最適のバイアス」に陥っています。

例えば、複数工程からなるライン工を想定します。

工程Aでは部分最適化が進み、１時間に30個の製品を作って、工程Bに流します。
工程Bでは努力しているものの、扱っている機械の特性上１時間に10個の製品を仕上げるのが限界です。

ここで工程Aをさらに最適化していくとどうなるでしょうか？

工程Aで作られた製品が後続工程Bにどんどんスタックしていくことになります。

工場ラインで言う所の「仕掛品」「在庫」が増えるだけでなく、工程Bの工員は無駄にプレッシャーを受け、あるいはマネジメント層に叱責され、モチベーションを失っていくことになってしまいます。

そうすると工程Bのスループットが悪化し、全体としてのアウトプット量や品質は劣化してしまうことになります。

たちが悪いのは、このときに工程Aは部分最適化が進み、これまで以上の成果を出したなどして表彰されてしまうようなケースがあることです。
実際に工程Aは工場にとって何もプラスを創出していないにも関わらず、ローカルな数字の改善により不当な高評価を得てしまう可能性があります。

プロダクト開発において、各自が全体を俯瞰してバランスを感じ取ることは重要です。
自分の担当部分しか見えていない状態では、部分最適のバイアスに陥って、プロダクトにいい影響を与えないような改善を繰り返してしまうどころか、他チームの生産性を劇的に下げてしまうこともあることを意識しましょう。

プロダクトを育てる

「スパゲッティチャレンジ」という取り組みを、あるビジネススクールで複数の属性の人たちにやってもらって結果を比較するという実験が行われました。

チャレンジの内容はシンプルで、乾燥スパゲッティ数本とマシュマロを4−5人のチームに渡し、20分以内にもっともマシュマロを高く積めたチームの勝利、というものです。

チャレンジは経営者やMBAの学生から幼稚園児まで、多岐に渡って実施されました。

その中で成績のよかったのは一体どの属性の人たちなのでしょうか？

（正直細かい結果は忘れたのですが）なんと幼稚園児の方がMBA学生に比べて倍以上の成果をあげるということがわかりました。

理由はそのプロセスに現れています。

MBAの学生は、4−5人のチームが編成されるや否や、各自の役割を明確にし、スケジュールを立て、綿密な設計をはじめました。
20分の制限時間の中で、18分を準備時間に充て、完璧な設計が完成してから残り2分でスパゲッティとマシュマロの構築をはじめました。

すると、途中で何らかのトラブルが発生し、最終的にタイムアップのタイミングではスパゲッティ１本も組めていないケースが散見されたそうです。

一方、幼稚園児は、チームが編成されてスタートすると、各自が思い思いにスパゲッティを積み上げはじめます。
最初は全くうまくいかず、失敗を繰り返すのですが、失敗のたびに学び、次のチャレンジでは改善し、また失敗し・・・を繰り返すので、20分の中で着実に成長していきます。

結果的に、かなり安定度の高い構造物ができあがるケースが多いという内容でした。

プロダクトの成長においても、同じことが言えるかと思います。

綿密にマーケティングし、調査と設計を行って、完璧な品質のものを世に送り出しても、全くユーザーに見向きもされないようなケースは多々あります。
チャレンジの20分で、実際のプロダクトベースでユーザーの反応を見るという過程が全く行われていないからです。

これからのプロダクト開発はDCPAであるべき、と主張される方もいます。

なるべく早いサイクルでプロダクトを市場に投下して、反応を見て、よりCVRが改善するように短いサイクルで改善して実験を繰り返していく。

そういったプロダクト開発の進め方を意識していく必要があります。

さいごに

僕自身、大企業とスタートアップ両方経験しているので、大企業に於ける実現の難しさなど重々承知しているつもりです。

しかし、競争環境が激化している現代において、
・改修が行われないまま複雑化したプログラム
・ローカル目標を追い求める開発チーム
・重厚なプロダクト改善フロー
は自社の首を締めるだけになると思っています。

ライトで高サイクルのプロダクト開発を行える環境を作っていきましょう。