導入

こんにちは、Product Teamの朴です。

プロダクトを開発する中で、信頼が大事という話は良く聞きます。プロダクトマネジメントに関する本の「INSPIRED」、「Radical Candor」などでもメンバー同士の信頼関係の構築の大事さが強調されています。

特にプロダクト開発の中で多く取り上げられるこの信頼とはなんでしょうか？時々組織の技術的な面よりこの信頼を積み上げることで、プロダクト開発のスピードが上がる重要なキーにもなります。ではプロダクト開発のスピードにも関係するこの信頼はどう積み上げていけば良いでしょうか？

この記事は信頼についてと、信頼を資産のように考え、活用する方法についてです。

信頼とは

信頼の語源は「慰安」の意味のドイツ語の「trost」からだと言われています。誰かを信頼し、裏切られる心配がないと安心できますよね。それに裏切られる心配もないので、予防のためにコストをかける必要もないので安心できる、ということでしょうか。

心理学の観点で見ると信頼は「相手に対する期待」、「リスクを取る意思」、「相互依存性」の３つの要素から構成されています。すなわち、信頼とは「他人が自分に役立つ意図や行動を示してくれるという期待の基、相手を助けるために自分のリスクを取ろうとする状態」ということになります。 *1

それではなぜこの状態を大事だと私たちは思うのでしょうか？それは信頼は資産のような性質があるからです。

信頼は資産

信頼を資産のように考え、資産のように管理する概念は実は昔から使われています。毎年Fortune誌が100社を選定する際にもその企業の信頼度を資産のように評価する「Trust Index」という指標もあります。

それ以外に、信頼と資産はすごく似たような性質を持っています。信頼を資本ではなく、資産という説明をした理由は資産の性質の積み上げていくものでありつつ、積み上げた分だけではないところにあります。

例えば、ある企業の総資産とは業績として自社の資本を積み上げただけでなく、株式を発行したり、外から投資をしてもらう、もしくは単純に借り入れてくるケースなどで資本以上の資産が持てることになります。逆に企業価値が下がる、株式が下落するなどで企業価値がトータルで低く評価されることももちろんありますよね。つまり、積み上げた分だけで評価されるのではないというところで、信頼も同じような性質を持っているので資産という表現をしています。

信頼も急にできるものではなく、基本的には積み上げていくものです。自分が取った行動が他人からの信頼の大きさに影響します。同時に信頼は自分が取った行動だけではなく、他人からのこの先うまくやっていけるという期待、すなわち信頼負債が信頼を評価する際に影響します。信頼は積み上げていく資本の性質と先に反映される負債の性質を同時に持つため、信頼資産として管理することができます。

信頼資本は個人の行動によって真面目に積み上がるので時間と努力をかければ積み上がります。しかし、信頼負債は他人からの期待を満たせない場合、減少してしまいます。例えば、リーダーや何かの役職を持っているにも関わらずそれ相応の動きができない、より高いパフォーマンスが期待されているのにパフォーマンスが出せてないなど、様々なケースで信頼負債が減少することになります。

仮にすごく評価が高いメンバーが集まっているチームの場合、最初は期待されているので高い信頼負債の元、より高い信頼資産のおかげで物事をアグレッシブに進められますが、信頼負債の責任を持てなかった際には次のプロジェクトでは少ない信頼資産で進めるしかなく、何か制約があったり、不自由な状態で進めるしかなくなります。

結論、私たちがとある個人やチームを信頼するというのはその人の行動をもとにした最小限の信頼と、その個人やチームの普段の行動、立ち位置、価値観などによってまだ経験してない領域の問題解決力に対して他人が持つ期待から構成されており、これが信頼資産になります。

信頼資産がプロダクトに大事な理由

プロダクトの開発で信頼資産が大事な理由は大きく２つあります。

コミュニケーションのコスト削減

プロダクトの開発には多くの曖昧さが出てきます。PMが整理すべきか、開発が整理すべきかや、デザイナーの領域か、エンジニアの領域かなど多くの曖昧な領域があります。

端的な例を挙げてみます。決まったスケジュールで開発を完了しないといけないのに、急にセキュリティ部門やCSなどであまり大きすぎず、小さすぎずの追加の要件があったとします。この時、この要件を受け入れるかどうかを決める主体はPMと開発のどっちでしょうか？どっちも簡単に答えるのは難しいと思います。この状況でお互いがお互いのことが信頼できてないと自分の立場だけを考え仕事を押し付けるような形でコミュニケーションが長引きます。

しかし、お互い信頼資産がある程度作られている状況であれば、よりスムーズにコミュニケーションができます。PMが開発より大きい信頼資産を持っているのであれば、全体的な状況をみて素早く整理できるし、開発がPMより大きい信頼資産を持っているのであれば開発側が開発のスコープ、進捗などを確認し、状況整理ができると思います。もしPMと開発の両方で高い信頼資産があるのであれば、お互いの議論でよりベストな方法を模索できると思います。

プロダクトの開発で信頼資産は、一緒のチームの誰かにどれぐらいできるだろうと期待される能力値の印となります。これぐらいはできるという期待を表したものです。これによって曖昧な領域でコミュニケーションのコストが発生する際に、素早い状況整理ができます。

挑戦を促す（プロダクトの成功の不確実さに対する安全装置）

成功するプロダクトを企画、開発することはとても難しいです。プロダクトの開発は基本的に仮定をベースに企画されます。その仮定には分析やいろんな予測が含まれますが、それは予測に過ぎないので結局開発し、サービスする中でフィードバックをもとにPDCAを回していくしかないです。小さいプロダクトの場合は特になりかもですが、中規模以上のプロダクトの場合は責任も重くなり、進める中で説得が必要になったりもします。

信頼資産はここで役に立ちます。起点になる論理が妥当で、起案者の信頼資産が十分であればメンバーを説得するコストが大きく減ります。メンバーがその人の信頼資産を十分に認めているのであれば最終決定権者だけど説得するだけで十分です。メンバー一人一人を説得する必要はなくなります。また、これによってプロダクト開発の中で発生する課題を乗り越えるのに役に立つし、メンバー達とより挑戦的なプロダクト作りに熱量高く取り組むことができます。

信頼資産を作る方法

本業を上手くこなす

各自が自分の領域で責任のある役割を見せることが信頼資産を作る基本となります。私たちが信頼資産を積む理由は、曖昧な領域で自律的、かつ素早く問題解決をしていくためです。そのためにはメンバーの中でお互い信頼できる存在である前提が必要で、その時に使われるのが信頼資産です。

もし、まだ入社してすぐや、チームに入ったばかりなどで自分の本業で自身がない場合は、自分がどうプロダクトに向き合っているかをメンバーに話すことをお勧めします。話す中でお互いの期待値をすり合わせることができ、これを元により素早く信頼関係を作ることができます。

挑戦的なことを約束し、達成する

信頼資産は信頼負債と信頼資本で構成されています。

当然ですが、信頼負債を積むことも信頼資産を積むことに繋がります。自らの実績や行動を元に信頼資本を積むこともできますが、より難しいことに挑戦し、他人の期待値を上げることで信頼負債を積むこともできます。自分の信頼資本を超えることに対する挑戦は周りから何か指摘を受けることもあるでしょう。しかし、その中で責任を持って進め、全力で目標を達成するとその信頼負債は信頼資本に繋がります。また、より多くの信頼負債を積むことができるようになるでしょう。

ラポールを形成する

ラポールは心理学で使われる用語です。お互いに心が通じ合い、安心して相手を受け入れることという意味です。ラポールを形成し、お互いがお互いのコンテキストを理解すると信頼資産が増加に繋がります。お互いの価値観や進め方を理解すると、信頼資産を増加させることができます。しかし、ラポールを作っただけで信頼資産が増えるのではなく、ラポールを作る中でお互いのコンテキスを理解することができ、そこから信頼資産の増加が繋がります。

ラポール形成に最も効果的だと思う方法が1on1だと思っています。1on1で業務、キャリア、成長などさまざまな話し合いの中で信頼資産を増やすことができます。弊社の1on1については以下の記事をおすすめします。

tech.uzabase.com

組織構造も大事

信頼資産は組織レベルでしっかり支援しないと意味がなくなります。信頼資産を作って、活用するにも組織構造に邪魔されるとプロダクト開発で信頼を積んでもあまり意味がないでしょう。メンバー同士の信頼資産を組織で活用するには以下の３つが大事です。

過度に領域を分けない

組織内で各担当者で過度に領域分けをすることはたまにあります。プロダクトのステークホルダーに開発に関するフィードバックや、ミーティングなどで話した際に、自分の担当じゃない、開発の仕事だからなどと思われるとか、言われることはないでしょうか？これは開発の仕事、あればPMの仕事、とかではっきり線を分けることは信頼資産を作る中でマイナスになります。良い組織はメンバー同士でこのケースではどうすべきかに対して議論すべきで、このケースだとそのチームでどうぞのように責任転嫁すべきではないと思っています。お互いが信頼資産を作り、それを活用するには過度に領域を分けず、メンバーが同じ目線で進められる組織の構造も大事だと思っています。

新メンバーに信頼負債を与える

これは簡単にいうと信頼ファーストですね。新メンバーはまだ実績がないので信頼資産をゼロから作らないといけない、これは間違いだと思います。新メンバーがゼロから信頼資産を作るのは当然難しく、大変で非効率です。会社や組織に慣れる時間が欲しいのは間違い無いですが、ゼロから何かを積み上げる、達成することはとても非効率ですね。なので新メンバーには信頼負債を与え仕事を進めさせ、その結果を元に信頼資産を管理していくことが効果的で効率的だと思います。

失敗者にしない

誰でも失敗はできますが、それに対してあなたは失敗者であるとしてしまうと、その人の信頼資産はゼロになってしまいます。組織のあるべきは、その人が失敗によって失った信頼資産を取り戻せるように手伝うことだと思います。失敗をふりかえ、自ら信頼資産をまた構築できる安全装置を用意することで、メンバーはみんなの信頼資産を元により挑戦的で、自律的に動くことが期待できます。

まとめ

包括的なドキュメントよりも動くソフトウェアを

アジャイルソフトウェア開発宣言にはこう書かれています。動くソフトウェアを大事にし、変化に対応するための取り組みを重要だと考えています。特にITのプロダクトの開発では色んなステークホルダーが存在するため、変化に対応するにはより多くの人々とのコミュニケーションが時には開発のスキルよりも求められます。そのような状況の中、お互いをどれぐらい信頼できるかは開発のスピードに大きく影響します。信頼を資産のように管理することによって、より効率的にプロダクト開発ができると思っています。

*1:NOT SO DIFFERENT AFTER ALL: A CROSS-DISCIPLINE VIEW OF TRUST - Rousseau et al