プロダクトづくりには2つのモードがあると思う。チームファースト(Team Fisrt)と、プロダクトファースト(Product First)。チームファーストは、チームとしての状態がより良くなることに重きを置き、その基準でプロセスや活動、評価、時間軸の最適化を行う。

　一方、プロダクトファーストは、成果を重視する。具体的にはプロダクトの開発だったり、事業としての目標達成を活動の中心に据える。もちろん2モード間でゼロイチということではなくて、判断基準をチームとプロダクトのよりどちらに置くのかという考え方である。

　まず一つの結論として、2つのモードの間でどちらかが正義で、一方がダメだとかそういう捉え方ではなくて、どちらも局面によって必要になる。何らかのプロダクトを軸に事業をスタートアップしようとする局面なら、まずはプロダクトが無いと始まらない、プロダクトファーストを取る場合が多いだろう。あるいは既に事業が運用に乗っていて、持続的にKPIを追いかけていくような局面なら、チームの関係性や活動を持続可能となるようカイゼンしていく、チームファーストのモードがより求められたりする。

　目的に応じて適したモードを採用する。理想は、このモードの存在や切り替えを意識せずに運用できることだが、現実的にはリソースの制約(例: 事業として残された時間が少ない)とか、チームの練度の問題からこの2モードの意識的な選択、切り替えが必要になる。

　なお、「チームの練度の問題」とは、プロダクトづくりに適した活動にチームを適応させていくには、その経験が不足している状態のことである。スプリントでの開発のやり方とか、リモートワークでのコミュニケーションとか、採用する技術についてとか、目の前のプロダクトづくりを成り立たせるのに様々な観点での経験が問われる。

　最初からすべて能力を備えているチームは稀だろう。チームができること、はじめられること、受け止められることには限りがある。スプリント(1週間)単位で注力するべきポイント(チームファーストorプロダクトファースト)を切り替えていこうとしても、チームが方針に振り切られてしまうだろう。

　このようにモードの概念を整理したときに、状況として理解できるようになるのは「プロダクトファーストの局面で、チームファーストの方針を取っている」時に生じる、成果への期待と実際のギャップである。チームとして間違ったことはしていないのに、思うような結果がついてこない、という状況に対する説明ができるようになる。

　新しい企画、サービスを立ち上げようという場合、いくつかの検証を経て、では実際にユーザーが体験できるようプロダクトを本格的につくっていこうという段階に至る。いまだ事業として成り立つかどうかも分からないため、いかに早くMVPを形作って想定ユーザーに届けるかが、ミッションとなる。明らかにプロダクトファーストである。こういう状況下で、チームの方針がチームファーストのモードになっていたりすると、一向に期待する成果が上がらずという状況になる。その状況が続けば、もちろんプロジェクトはストップしかねない。

　こうした期待と実際の活動の乖離が生まれてしまうのは、チームファーストとそれに伴う活動自体が決して間違ったものではなく、むしろチームにとって望ましい「正しい活動」のため、チームの優先度を変えにくい力学が働いてしまうところにある。

　絶対的にチームファーストが正しいとまで意識的に捉えていなかったとしても、「チームにとって良いこと」は暗黙的に正義になることが多い。しかし、「正しさ」とは、ミッションと局面によって決まる。なんとなく良さそうで流され続けると、期待される結果にたどり着けないまま、残念な終わりを迎えてしまう可能性が高い。

　このプロジェクトは、どちらのモードからスタートするのか？最初期の段階に、ミッションに基づいたモード認識を共通にしよう。そして、自分たちがありたい方向に向かっているのかを捉え直す、むきなおりのタイミングでモードの選択をしよう。やがて2つのモードを意識していたことも忘れるくらい、強いチームに成長する、そのときまで。