人を信頼するにはどうすればいいかについて チームファーストと、プロダクトファースト

 人を信頼するにはどうすればいいか？

それは、・・・・

 4つの資質を人に求めた。

①まずは「知性」。これは勉強ができるということではないんです。
  
  さまざまな分野の話をすばやく取り入れ、それらをつなげる能力を持っていることです。
  
  これを「遠い類推」（かけ離れたものごとをつなげる発想）と呼びます。 ②そして「勤勉」であること。

③「誠実」であること。
  
   最後に、あの定義のむずかしい資質、

④「グリット（やり抜く力）」を持っていること。打ちのめされても立ち上がり、再びトライする情熱と根気強さ。
  
  この4つの資質があると思える人には、ほかの多くの欠点には目をつぶれる。
  
  会社の面接で候補者をこれらの観点から評価する際、

その人が何を成し遂げたかだけでなく、どうやって成し遂げたかを尋ねるのです。 
  
 候補者が「収益成長に貢献するプロジェクトを指揮した」と言えば、どうやって成長を実現したかを聞くことで、
  
 その人物がプロジェクトで果たした役割について多くのことがわかることになります。現場で陣頭指揮を執ったのか？ 
  
 率先して仕事に当たる「実行家」だったか？

チームを構築したか？ 代名詞にも注目した。
  
  「私」（自分第一主義の証）と「私たち」のどちらを多く使うか？
  
 貢献意欲、それも個人的な成功だけでなく組織の大義に貢献する意欲を持っている人を求める。
 

 
  チーム・ファースト！ グーグルCEOのスンダー・ピチャイも言うように、
  
  「自分の成功が他人との協力関係にかかっていることを理解している人、ギブアンドテイクを理解している人、つまり会社を第一に考える人」を探す必要がある。 
  
 そういう人材が見つかれば、いわく「かけがえのない人材として扱った」。 
  
 だがそうした人材かどうかを、どうやって判断するのか？

彼らが何かを犠牲にしたり、他人の成功を喜ぶことがあるかどうかに注目すればいいんです。
  
 こう指摘する。 「ときとして、より大きな成果を得るために、誰かが何かを犠牲にしなくてはならないことがある。
  
  僕はそういうときの行動に強く注目している。自分とは直接関係のない、ほかの部署の成功を喜んでいるときも。そういうことに目を光らせる」。

　プロダクトづくりには2つのモードがあるります。

チームファーストと、プロダクトファースト。

チームファーストは、チームとしての状態がより良くなることに重きを置き、その基準でプロセスや活動、評価、時間軸の最適化を行うことです。

プロダクトファーストは、成果を重視する。具体的にはプロダクトの開発だったり、事業としての目標達成を活動の中心に据える。

もちろん2モード間でゼロイチということではなくて、判断基準をチームとプロダクトのよりどちらに置くのかという考え方であります。

まず一つの結論として、2つのモードの間でどちらかが正義で、一方がダメだとかそういう捉え方ではなくて、どちらも局面によって必要になる。

何らかのプロダクトを軸に事業をスタートアップしようとする局面なら、まずはプロダクトが無いと始まらない、プロダクトファーストを取る場合が多いでしょう。あるいは既に事業が運用に乗っていて、持続的にKPIを追いかけていくような局面なら、チームの関係性や活動を持続可能となるようカイゼンしていく、チームファーストのモードがより求められたりする。

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

なお、「チームの練度の問題」とは、プロダクトづくりに適した活動にチームを適応させていくには、その経験が不足している状態のことである。

リモートワークでのコミュニケーションとか、採用する技術についてとか、目の前のプロダクトづくりを成り立たせるのに様々な観点での経験が問われる。

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

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

チームとして間違ったことはしていないのに、思うような結果がついてこない、という状況に対する説明ができるようになります。

新しい企画、サービスを立ち上げようという場合、いくつかの検証を経て、では実際にユーザーが体験できるようプロダクトを本格的につくっていこうという段階に至る。

いまだ事業として成り立つかどうかも分からないため、いかに早くMVPを形作って想定ユーザーに届けるかが、ミッションとなります。明らかにプロダクトファーストである。

こういう状況下で、チームの方針がチームファーストのモードになっていたりすると、一向に期待する成果が上がらずという状況になる。その状況が続けば、もちろんプロジェクトはストップしかねない。

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

絶対的にチームファーストが正しいとまで意識的に捉えていなかったとしても、「チームにとって良いこと」は暗黙的に正義になることが多い。

しかし、「正しさ」とは、ミッションと局面によって決まる。なんとなく良さそうで流され続けると、期待される結果にたどり着けないまま、残念な終わりを迎えてしまう可能性が高い。

このプロジェクトは、どちらのモードからスタートするのか？最初期の段階に、ミッションに基づいたモード認識を共通に。

そして、自分たちがありたい方向に向かっているのかを捉え直す、むきなおりのタイミングでモードの選択を。

やがて2つのモードを意識していたことも忘れるくらい、強いチームに成長する、そのときまで。