- 多くの企業は複雑なプロセスや冗長な要件に縛られて開発速度が遅くなるが、実際に重要なのは素早く「正しいプロダクト」を作ること
- プロダクト開発の過程で不要な要素を取り除けば、プロダクト開発の速度は大幅に上がる。正しいプロダクトを作ること自体は、本質的に速いプロセスである
- プロダクトチームの速度を遅くするのは、プロセス、意思決定者と実行者の距離、過剰な仕様書などの不要な要素である
[Product Velocityのための原則]
1. 「より少なくやる」ことが必要
- 一般に、速度と品質のあいだにはトレードオフが存在する
- ほとんどの企業は要件と期限を決め、品質は結果物として扱うが、私たちは逆に品質基準を決め、60日以内に何をリリースできるかを考える
- 重要なのは、すべての要件を満たそうとすることではなく、重要なことだけを素早く完成させること
- 要件を減らし、本当に必要なことだけをやれば、速度と品質の両方を高められる
- Elon Muskも似たアプローチを提案しており、「まず要件をもっと馬鹿げていないものにしろ」と語っている
2. 「バカモード」がしばしば効果的
midwit memeを例にすると、賢い人とバカはシンプルな解決策に同意する一方で、平均的な人は不必要に複雑な問題を作り出す。- 私たちはしばしば「バカモード」で問題に向き合い、複雑に考える代わりに単純な解決策を見つけようとする。
- 失敗したときは、たいてい考えすぎていたということだ。シンプルな方法のほうが、より頻繁にうまくいく
- 「自分がバカだったらどうするだろう？」と自問すると、実行可能な解決策にたどり着くことが多い
3. すべての問題が重要なわけではない
- ごく一部の問題だけが非常に重要である。セキュリティのような重要な問題は必ず解決すべきだが、すべての問題を解決する必要はない。
- たとえば、モバイルUIは良くないが、顧客はほとんどモバイルを使わないため、改善していない。
- このように、顧客がそれほど気にしない問題は無視できる。
4. とにかく作れ
- 私たちにはプロダクト開発のためのプロセスがない。Figmaモックアップ、PRD、デザインシステム、アジャイル、OKR、明確なプロダクトロードマップ、A/Bテスト、グロースハックなどを行っていない
- 顧客がエンジニアであるため、私たちのエンジニアがプロダクトやデザインなども含めてすべて対応できると考えている
- まず素早くプロダクトを作ってみて、顧客の反応を見るやり方を好む
5. 書き直しは必要なときに行う
- 企業はしばしば、技術的負債をできるだけ長く先送りするほど速く動けると考えるが、私たちは必要なときに大規模なリライトを行うことを厭わない
- ときには、正しいものを作るための最短ルートは、間違ったものを作り、それが間違っていると気づき、正しいものに置き換えることだ
- 技術的負債を取り除くことが有益だと思えるなら、そうする
6. 可能なら外注を活用する
- 可能であれば社内で作る代わりに、外部ベンダーのソリューションを購入する。たとえば、Fernという企業を通じてSDKを生成している
- もちろんベンダーを利用するには相当な初期コストがかかり、自由度も制限されるが、一般には正しい選択である
- 私たちのエンジニアリングリソースは非常に限られていて高価であり、エンジニア1週間分の時間には約5,000ドルのコストがかかる。機会費用を考えれば、その価値ははるかに高い
- 実際に自分たちで作る価値のあるものは、比較的少ない
7. 採用しない
- 人員を増やせばチームのアウトプットが増えるとは考えていない。採用は遅く難しく、オンボーディングや人材管理には時間がかかる
- とくに、多くの支援なしで貢献できる有能な人材を迎えるのは難しい
- そのため、大規模なエンジニアリングチームを構築できるリソースがあっても、小規模を維持するよう最大限努めている。そうすることで、物事はずっと簡単になる
まとめの考え
- 私たちは、以前は気づいていなかったほど、プロダクト開発はそれほど長くかかるべきではないのだと気づいた
- 顧客に必要なものを理解し、強いチームを持ち、注意をそらす不要な要素を排除すれば、高い速度でプロダクトを開発できる
10件のコメント
私もまた見に来ました。また今度お会いしましょう。
何度見てもいいですね。
?? とても理想的ですね
外注に関する管理コストや、そこに投入しなければならないリソースもかなりのものだと思いますが……それでも全体としては素晴らしい助言です。
いつも外注を使えと言われますが、外注を使うときにどうすべきかについては、ほとんど見かけない気がします。
明確なサービス像もなく、簡単な下絵だけを渡してしまうと、思った以上にひどいものが返ってくるということを認識していない……
???: 速くても、アジャイルではないように作ってください
プロダクトが明確なときにこそ可能だと思います
やるべきことが明確なときは、それ以上の設計は不要だ、という感じです
「まず要件をあまり愚かでないものにしろ」
外注業者がある日いなくなったら……電話に出なかったら（泣）
社内開発だとしても、ある日みんなが退職してしまうと言い出したら、状況は似たようなものではありませんか..?