プロダクト開発 = 「正しいもの」を「正しく作る」

最近本業で新規のプロダクト開発をしているので久々にアーリーステージのプロダクト開発についていろいろ考えることが多かった。
その中で結局プロダクト開発とは、 「正しいもの」を「正しく作る」 という以上でも以下でもないんじゃないか？となったので書き殴ってみてる。
アジャイルやスクラムの様々な文献に影響を受けているのでこれを参考にしているとバシっとは指定できないところだけど、少なくとも以下の考え方や文献には影響を受けている気がする。

• Shape Up: Stop Running in Circles and Ship Work that Matters
• 20. Framing - RYAN SINGER
• Scrum@Scale
• Dual Track Agile
• The Double Diamond

「正しいもの」？

端的にいうと、ユーザーが必要としているもののこと。
もっと極端にいうとプロダクトとしてグロースするための最適な機能などのことを指すと思うとイメージが湧きやすいかもしれない。

以前のブログ でも紹介したように、Cynefin Framework ^{1 2} を再掲する。

上図の Complicated な領域であれば、答えは自分たち (チームないしは、社内のステークホルダーなど) で定義できるので「正しいもの」を作るのはそう難しくない。
一方でプロダクトのほとんどが Complex な領域、すなわちユーザーに使ってもらうまで「正しいもの」がどれかわからないような問題に向き合っている。
新規のプロダクトならなおさらユーザーの期待値や実際のワークフローは未知数なため実験を多くせざるを得ない。

上で挙げている、Dual Track Agile などでは、こういうフェーズを Discovery と呼んでおりこれをなるべく確度高く行う方法を提案している。
挙げていくとキリがないが例えば、ユーザーインタビュー、プロトタイピングなどが該当する。

こういう領域は主に PdM や Business Analyst など、いわゆるプロダクトの人が専門性を持っている領域の認識。

「正しく作る」？

こっちはいわゆる開発のプロセスなどがイメージがつきやすいと思う。
上で挙げている文献などではいわゆる Delivery と呼ばれるようなフェーズのことを指す。
近年だとほとんどの有名な書籍に引用される LeanとDevOpsの科学 でも語られる Lead Time for Change を早くするだったり、 Deployment Frequency を高くするような作り、プロセスにしていくことがこの Delivery に貢献する活動となると考えている。
また、以前のブログ でも紹介したように技術負債を効果的にコントロールしたりする活動もここに含まれる。

ここの領域はいわゆる Software Engineer や SRE などの技術職の専門性が活きる領域となる認識。

「正しいもの」を「正しく作る」？

例えば、 「正しくないもの」を「正しく作る」 とそれは無駄なものにパワーを割いていることになる。
「正しいもの」を「正しくなく作る」 とそれはスケールしない、もしくは将来的に競合と戦えなくなるアジリティの低下を産むことになる。

このように片手落ちではダメでどちらも正しくやる必要がありそのための様々なツールや測定方法、改善方法が世には提案されているのだろうと思っている。

例えば、 Shape Up: Stop Running in Circles and Ship Work that Matters なんかはまさにこの Discovery と Delivery をうまくフレームワーク化しようとしているように見えるし、 Dual Track Agile も明示的にプロセスを分けることでこの2つのフェーズの確度を上げようとしている。
Scrum@Scale の Product Owner Cycle と Scrum Master Cycle を分けているのも 「正しいもの」を「正しく作る」 をサポートする仕組みと思うと理解が深まったりした。

というわけで今後も 「正しいもの」を「正しく作る」 を大事にしていきたい。