🐁

小さなプロダクトから、小さな仕事から

2022/10/31に公開約1,300字

Minimum Viable Productの提言より、小さな製品から始めることには明確にメリットがあることが示されています。

誤った仮定(価値提案)に基づき多くの機能を備えた製品の開発すると、失敗した場合のコストとリスクも増加するため、MVPからインサイトを得てそれを徐々に製品開発に反映させるほうが比較的に安価である。

実用最小限の製品 - Wikipedia

作ってみてはじめて、それが何なのかを分かるというのはありますよね。顧客だけではなく開発者にとっても最小限のプロダクトにはそれだけで学びがたくさんあるということです。

さらに、最近 O'Reilly Japan - Effective DevOps を読んでいますが、ここでも組織を変えるという文脈で似たような話が出てきました。

組織レベルの固定思考は、改革に悪い思い出がある人やさまざまな理由でリスクを嫌う人が複数いるため発生することが多い。...間違ったドキュメントの訂正のような小さいもので良い。...そして、変更や改革は状況を改善するだけでなく、必ずしも大きな問題やサービス障害を引き起こすものでもないという自信を付けていくのである。

はい。チーム改革がどんなものかをまず小さくやってみて確認する、フィードバックを得る。一緒ですね。いきなり大風呂敷を広げても、チームメンバーが新しい体制への疑念を強めてしまう結果になるのはなんとなく想像できますよね。(それ、本当にいいの?できるの?

これについては、私自身も最近の仕事で体験しました。チームがユーザーがどう行動したいか、ではなく作り手がどう行動してほしいかを考えて施策を考えている傾向があるという課題を感じていました。そこで、今の課題はこれで、ユーザビリティをこのように計測して、という話をドキュメントにまとめてみました。しかし結果は、私自身も本当にこれで事態が解決に向かうのか?という疑念が湧いてきてしまったのです。これはチームの体制が変わることのリスクを恐れているというのが原因だと思います。

どうするべきか?

うーん。この場合どうするべきでしょうか?明日のミーティングでは私がユーザーがどう行動したいか、を軸とした施策を提案するところから始めてみようと思いました。その案が上手く行けば、次も似た考え方に基づいた施策を考えやすいのではないでしょうか。

この辺りで、サイズを小さくはじめることは仕事のやり方にも通用するのでは? ということに気が付きました。そこで私なりのルールを作りました。

  1. 自分からはじめる
  2. 自分の仕事の領域からはじめる
  3. シンプルなプロダクトからはじめる
  4. すぐにフィードバックが得られるところからはじめる

以上です。

Discussion

ログインするとコメントできます