プロダクトが進捗していないと感じた時の戦い方

この記事は Product Manager Advent Calendar 2019の18日目 です。

はじめに

Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。

スタートアップの強みはストラテジーと実装の一致

早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。
逆に言うと、これらが一致していない場合、早さは生まれない。
正しい戦略が、組織や技術的負債のために実行されなければバツ。
逆に素晴らしいテクノロジーを扱えるチームがあったとしても、間違った戦略で活用してもバツ。

いわゆるプロダクトマネジメントは
「ストラテジーと実装の一致状態を継続させる」という機能なのだと思う。
狙うマーケットが変わったり、ストラテジーが変わればプロダクトが変わる必要がある。
プロダクトの原動力は人なので、人に納得性を植え付けるか、人を替える必要がある。

多くの場合、プロダクトのエンハンス、組織拡大していく中で段々乖離が大きくなっていき、

• プロダクトでの実現が事業戦略のスピード感に合わない
• 実現するために膨大なコミュニケーション、調整が必要
• そもそも一部では実現を諦めてしまうほど高コスト、高難易度なものになってしまっている

のような問題が顕在化していきます。

プロダクト作りにおける負債の種類

まずプロダクト作りにおいて、相対する負債の種類をカテゴリー分けしてみました。

技術的負債

説明不要。

これが貯まっていると開発速度が思うように出なくなったり、予期しないところに影響が出て保守性が低下していく

組織的負債

プロダクトを生み出すチーム、組織の負債。

機能開発したんだけどオーナー不在の状態になっていたり、特定の人がハブになっているなど あとは職種間で期待値があっていなかったり、二項対立が起きていたりいうことも含みます

関係者的負債

関係者（特に社外）の負債

特にtoBとかだと顕著で、特定顧客しか使わないであろう機能要望に対応せざるを得なくなったりとか、SaaSを導入するのに受託みたいな期待値になってしまうこと。

顧客以外にも、アライアンスを組んだパートナー、ベンダーに仕様をロックされていたり、投資家との関係性的に計画を思っていた通りに進められないということも

思想的負債

プロダクトの機能における負債

プロダクトの機能に哲学、思想が欠如している状態。この機能はこうあるべきというものがない。 ユースケースがないとも言えます。

プロダクトが成長して機能が増えていく中で起きがちで、 本来は分かれているべき機能が汎用的な１つになっていたり、逆のパターンもあったり、 これが貯まっていくと技術的負債と同様、スピードが落ち、保守性が低下していきます

負債の誕生

負債の生まれ方として、まずイメージしやすいパターンとしては

1. 顧客的負債＆組織的負債
2. 思想的負債
3. 技術的負債

の順だと思います。

具体的には

1. 顧客的負債＆組織的負債

顧客の声が強く＆営業と開発の間に距離がある場合に起きがち。特定のユーザーだけの課題かつ、解決方法が本質的ではないようなものを必須で対応せねばならず、最悪だと交渉の余地なしみたいなことも、、

2. 思想的負債

長期的なプロダクトの方針を考慮したものではなく、短期的な目の前の問題だけを解決するような解決策になる

3. 技術的負債

プロダクト要件が長期的なストラテジーとずれているので、当然プロダクトを実現するためのコードにもずれが発生する

というもの

大体の場合はこうして最初の負債が生まれていきます。 リリースした瞬間には負債という認識がないこともありますが、エンハンスしていく中でゆっくり確実に乖離が大きくなっていきます。

影響し合う負債の恐ろしさ

そして、真に恐ろしいのが負債の発生は必ずしも上記の順番でなくとも起こるということです。

というのも作り手からすると、

「コードが悪くなるのは、思想が悪いから、思想が歪められるのは外部ステークホルダーの存在など制約条件が強いため、、、」

みたいな要件→実装と、一方通行に考えがちですが、

実際には要件を決める段階で

• 「技術的にこのやり方だと難しいと思ったから、、、」
• 「プロダクト要件を適切に判断できる人がないから、とりあえず早そうなやり方で実現した、、」

みたく、様々な時系列、カテゴリーの負債が相互に影響しあっています。

こうだったらまだやりやすいのに、、、

負債が積み重なった現実

というわけで、それなりに成長したプロダクトの負債は複雑に入り組んでいるため、 最もインパクトのある部分を特定して、効率よく進めるというのが極めて難しいです。

なぜならどの負債も向き合うのには相当の専門性が必要な中、それら全てを俯瞰して判断しなくてはいけないから

上流から下流に流れていくような一方向の依存であれば、最も上流の根本的な問題を特定して解決しにいくところですが、

このように相互に複雑に依存しあっている場合は目の前の問題を探索的に解決していきながら、依存関係を整理していく必要があります （地道に解きほぐして、解像度を上げつつシンプルにしていくイメージ）

ここからは銀の弾丸はないという前提で、進捗させていくためにどういうアプローチをすべきなのかをまとめていきます。

地道に負債を解きほぐしていく

組織の中で各負債と戦っていくポジションを図にするとこんな感じになります（toB SaaS寄り）

引用:Cultural Capital Theory in Software Engineering - Speaker Deck

基本的に自分のロールから離れた問題を扱うのは非常に難しいです。

理由はスキルセットの問題もありますが、コンテキストがわからないのと、日常でその問題に苦しめられるわけではないのでどうしてもオーナーシップが生まれにくいからです。

たまにバリバリ顧客と接する立場なんだけど、エンジニアのリテラシーに通じていて、 視座が高く俯瞰して見れるみたいなスーパーマンもいたりするが、あまり期待してはいけないなと

進め方としてはまず相手の立場、専門性をリスペクトしつつ、対話可能な状態にしていきます。この記事でいうところのリテラシーを身につけるという話がまさにそうです。

まずはリテラシーからはじめよう

この複雑な問題を進捗させるには１方向からのアプローチではダメで、多様な職種が混ざったプロジェクトチームが必要になります。 その上で少しづつ自分たちが抱えている負債と、周辺の負債を俯瞰して見れるようにしていきます。

もし進めていっても、負債は無限に出てくるし、何から手をつければいいか全然わからんという時は 上図のちょうど中間に位置している、比較的どのポジションでも共通のコンテキストで話しやすい思想的負債、組織的負債から着手していくのが有効だと思います。

誰でも語れてしまう故の難しさはもちろんあるんですが、 組織、フローといった問題は変更というアウトプットが誰の目でも認識しやすいという利点があります。（もちろん結果として改悪になることもありますが、、）

こうして確実にアウトプットを出して進捗させていきつつ、そもそも異なる専門性を持ったメンバーが一緒に負債解消をしたという経験そのものが、さらに複雑な問題にアタックする土台になると感じているので、徐々に領域を広げて、他の負債に対しても取り組んでいくのがいいと思っています。

おわりに

0→1で新しいサービス作ったりするのも楽しいと思う一方で

ビジネスも会社も急成長する中、数年後にストラテジー通りに進められず身動きが取れなくならないように問題を予測し、 急成長に対応しつつも同時に未来に手を打つというのも非常に面白いんじゃないかと思う今日この頃です。