読者です 読者をやめる 読者になる 読者になる

ninjinkun's diary

ninjinkunの日記

【翻訳】プロダクトマネジメントトライアングル

はじめに

プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとしても最終的には極度に抽象化した言葉になってしまう。例えば、機能横断型チーム間におけるプロダクトマネジメントの責任について、部分的には正確だが曖昧な説明として、「空白を埋める」「糊の役割を演じる」などが含まれる。

このプロダクトマネジメントの役割についての曖昧さは、プロダクトマネジメントの本質に近い。一つの会社の中でも、プロダクトマネジャーの役割は根本的に、そして急激に変わりうる。プロダクトマネージャーは景色が根本的に変化する中で活動する。技術は変化し、チームの力学も変化し、社会も変化し、新たなビジネスの機会が予期せずやってくる。そういった変化が、プロダクトと自らの役割にどいういう意味を持つかを理解することは、プロダクトマネージャーの特別なスキルセットだ。その意味において、プロダクトマネージャーは自らのジョブディスクリプションを定期的に書き換えなければならない。

しかし、周りの世界の変化に合わせて、プロダクトが成長するためのニーズを特定し、実装するための確かな手法とはどんなものだろう?プロダクトマネージャーは、他のものとの間に立って、とても概念的なこと(例えば世界を変えるビジョン)ととても具体的なこと(例えばある一つのボタンの機能要求仕様)との間に橋を架けることを専門にしている。皮肉にもプロダクトマネジメント自身の領域には、この橋が見当たらない。我々には、毎日やっていることのリアリティを伴った、プロダクトマネジメントの高度な責務を繋ぐ明確なフレームワークが欠けている。私はこの橋となり、プロダクトマネジメントの話題を深く探求する基礎として、プロダクトマネジメントトライアングルというグラフィックモデルを考案した。

プロダクトネットワーク

このモデルを説明するための準備として、まずプロダクトマネージャーが活動する領域について説明する必要がある。以下のプロダクトネットワークの図は、私がソフトウェア製品のコンテキストで根源的な要素だと信じているものを表現している。プロダクトと、それを開発したり使ったりする人々の多くの傾向は変化するが、以下の要素は常に現れる。

network.png
図1: プロダクトネットワーク

プロダクトネットワークの中心に位置するのは、プロダクト自身だ。ソフトウェア会社におけるプロダクトは事実上、人々がアクセスできる環境にデプロイされたコードで構成されている。全てのプロダクトは三つのこと、開発者、ユーザー、ビジネスで繋がっている。

開発者(もしくはエンジニア)はコードを書いてデプロイできる人たちだ。会社にはたいていプログラミング以外のプロダクトの仕事をしている人たちが居るが、コードをアップデートする人たちこそが唯一厳密に欠くことのできないチーム要員だ。開発者は会社のすべての責務を担うことができる(常に効果的にとは行かないが)。

ユーザー(またはやや大ざっぱには「顧客」)はプロダクトを使う人、プロダクトを使うかもしれない人の両方だ。全てのプロダクトは人によって様々なレベルで使われるというゴールを持っている。

ビジネスはプロダクトへの投資と恩恵(例えば利益)を期待する存在だ。組織が営利であれ非営利であれ、限られた量の資金を持った部門が存在する。

whitespace.png
図2: 空白領域

この明白な一連の要素だけでも、ネットワークの中でプロダクトを成り立たせることは可能である。開発者と、ユーザーベースを築くという夢のために、会社が経済的に持続できるように資金を提供してもうことは可能だ。しかしそれは空白を無視している。「空白」はプロダクトネットワークのミッシングリンクを暗示している。この空白を埋める役割があれば、プロダクトネットワークはより良く機能し、そして最終的にはより成功するプロダクトへと導くことができる。具体的には、図2のA、B、Cに示されている3つの空白がある。

空白領域A

領域Aは開発者、プロダクト、ユーザーの間にある空白だ。開発者とユーザーは、プロダクトについて異なるメンタルモデルを持っている。一方の開発者は彼らが作ったプロダクトを使うことは可能だが、彼らのメンタルモデルにはプロダクトがどう実装されたかという知識が染みこんでいる。このため、将来的な機能強化を検討する際に、ハードワークする優秀なエンジニアたちは、比較的少ない労力で厄介な複雑性をコードベースに追加しない解決策を取るという、自然なバイアスを持っている。他方のユーザーは、画面の操作を通してしかプロダクトを知らない。彼らはプロダクトが裏側でどう動いているかを、教育による理解によって説明することも可能だと思われるが、彼は知らないし関心も無い。ユーザーは作るためにかかったコストやコードの美しさは気にかけず、自らの満足や抱えている問題を解決するためにプロダクトを使うのだ。

ユーザー視点を通してプロダクトに対して適切な見方ができ、この空白を埋められるエンジニアたちも居る。その一方で成長するビジネスは、ユーザーと開発者の間の橋渡しになる専門の頭脳を必要としている。デザイナーの役割はこの最も明確な実例だ。デザイナーはユーザーのメンタルモデルを理解し、開発者の実装に合わせてユーザーインターフェイスを考える責任を持っている。しかし他の職種もこの空白を埋めている。Webアナリティクス、マーケティング、ユーザービリティ調査、IA(インフォメーションアーキテクチャ)、テクニカルサポート、コミュニティマネジメント、QAなどの名前が挙がる。この中のいくつかの職種は、開発チームにユーザーを理解させることに注力している。また他の職種は、プロダクトをより良くするために既存のユーザーと交流したり、新しくユーザーになる可能性がある人を呼び込むことに注力している。

空白領域B

領域Bはユーザー、プロダクト、ビジネスの間に存在している。これは(願わくば)人々がプロダクトを使うことを、ビジネスの利益(もしくは他の利点)に転換できる価値がある場所だ。この領域の複雑さは大まかに以下のどちらかで説明できる。

  1. ユーザーが直接プロダクトにお金を支払う、もしくは
  2. ユーザーのアテンションを広告主に売る

1の例はEコマースや、サブスクリプション型のプロダクトだ。この場合での空白領域Bの職務は、会社の資産を使って効果的に見込み顧客を惹きつけ(従来型の広告やSEO、営業などを通して)、それぞれのユーザーから可能な限りの収益を特定し、最も儲かる市場にプロダクトの拡大を導いていくことである。

2の例はソーシャルネットワークとメディアの会社だ。この場合は複雑だ。なぜなら、あなたはプロダクトネットワークの「ユーザー」を、二つに分けなければならないからだ。それは (A) プロダクトの表面上のユーザー(例えばFacebookに投稿する人、ニューヨークタイムズを読んでいる人)と、(B) そのユーザーにリーチするためにお金を払う広告主だ。この場合は空白領域Bのプレイヤー達の役割は、ユーザーの好み、人口統計的データ、行動、関心を特定するためにプロダクトデザインに影響を与えて、広告主の利益を最大化することだ。彼らはまた、見込みのある広告主にプロダクトを売り込み、利益に最適化した価格モデルをデザインしなければならない。

もしかするとここには第三のケースとして、はじめはユーザーベースの成長に取り組んで、マネタイズは後に回すという、ベンチャーキャピタルの資本を入れたスタートアップも入るかもしれない。このシナリオでも空白Bを埋める人々のニーズはある。その職務では、投資家を喜ばせ続け、プロダクトが未来にマネタイズ可能になることを世界に知らせる空虚な指標(ユニークユーザー、ページビュー)を成長させる必要がある。

空白領域C

領域Cはビジネス、プロダクト、開発者の間に位置している。ここは会社がどこに投資をして開発力を集中させるかを判断する場所だ。高い視点から見ると、これはプロジェクトを導く光の役割を果たすビジネスビジョンの策定と、それによるコミュニケーションを必要とする(ときによってはCEOが仕事として持つ)。低い視点から見ると、特定のエンジニアリング的な機能、雑用やバグ修正の優先順位付けを必要とする(ときによってはプロジェクトマネージャーが仕事として持つ)。技術的なニーズを埋める際には、「買収 vs 開発(buy versus build)」というハードな質問に答える必要もある。空白Cは会社がアイデアを実行に移す場所である。

参考までに、私は下の図3にそれぞれの領域の空白を埋める役割の例を含めておいた。これは網羅的なリストというわけではなく、それぞれの領域の雰囲気を手っ取り早く伝えることを意図している。

pillars_template_roles.png
図3: 空白領域それぞれを埋める職種の例

我々はプロダクトネットワークの基本的な要素の間にある、空白領域A、B、Cが何を示しているかを議論してきた。会社が成長するにつれて、これらの領域は要素を繋ぐ連帯によって埋められていく。デザイナーはユーザーと開発者を繋ぐ連帯を築くために採用され、ビジネス開発部長はユーザーとビジネスを繋ぐために採用される。

pillars_template_roles2.png
図4: プロダクトマネジメントの責任範囲

多くの役職が追加されるにつれ、プロダクトネットワークの要素たちは異なった方向から引っ張られるようになる。図4の領域AB、BC、ACは、しばしばプロダクトネットワークの要素ごとに矛盾したインプットが一度に集まる場所になる。私はこれらの各スペースを「融合領域」と呼んでいる。

融合領域AB

pillars_template_roles_ab.png
図5: 融合領域AB

融合領域ABは空白Aからのインプットが空白Bからのインプットと出会い、ユーザーに一貫したストーリーを形成する場所である。この領域の人々は、ビジネスのニーズを理解しながらユーザーにとって価値があるプロダクトを作ることに集中する。またこの人々は、プロダクトのユーザー体験パラメーターを理解しながらマネタイズをする責任も負っている。私は領域Bの複雑さは以下のように表せると前述した。

  1. ユーザーが直接プロダクトにお金を支払う、もしくは
  2. ユーザーの注目を広告主に売る

どちらの場合の運用も、融合領域ABの緊張関係の大きさに重大な意味を持っている。1の場合の緊張関係は相対的に少ない。なぜならユーザーにプロダクトを好きになってもらうのと、会社に多くの利益をもたらすことのは同じことだからだ。プロダクトを重要なものに改良していくことで、より多くの人が知り、お金を払うことになる。しかしながら2の場合は、一つのプロダクトを作る中でユーザーと広告主にとって価値を届けるという避けがたい対立が存在する。広告はユーザー体験を低下させ、企業広告主との結びつきは信頼をむしばむ。一方でユーザー体験の効率を上げることは、しばしば広告のインプレッションを下げることに繋がり、利益を減らす要因となる。これはトレードオフを天秤にかけ、会社全体のニーズに合わせたプロダクトソリューションを生み出すために、ビジネスとユーザーのニーズを組み合わせる人間にとっては重要である。

この融合領域のニーズは、隣接した空白領域からやって来る直交したインプットに限定されるわけではない。ときどき一つの領域からも、複数のインプットが調整を求めてくることがある。たとえあなたが空白領域Bからやってくるプロダクトへのビジネス的な要求を無視できたとしても、空白領域A内でインプット同士の衝突は起こりうる。例えば、それぞれのユーザーのニーズを代表する二人が、ユーザーに最適な体験をどう作るかで意見が一致しないことがあるだろう。ここにユーザー体験とチームメンバー同士の視点の対立を調整することに最終的な責任を持つ、独立した存在のニーズがある。

融合領域BC

pillars_template_roles_bc.png
図6: 融合領域BC

融合領域BCは、一貫したビジネス戦略を形成するために、空白Bにある帯と空白Cにある帯が一緒にならなければならない場所である。これはビジネスのアイデアがふるいにかけられ、ビジネスビジョンの中でリソース分配、優先順位付け、合併などを通して行動を始める領域である。空白Bを埋める人々は、プロダクトがどの様にビジネスの成長に寄与するのかについての仮説を立てる。ここには会社のミッション、目的、可能性についての物語を所有するニーズが存在する。新しいビジネスアイデアが発生するにつれて、融合領域BCはどんなコンセプトが会社の物語にフィットするのかを判断するものになる。強力なフィルターは、会社が市場と会社のコアコンピテンシーに基づいて、ベストショットを持っている開発分野に注力することができる。

融合領域BCは、会社の知識が体系化されている主要な領域である。プロダクトの仮説が成功するかどうかという学びが、会社の物語の中に組み込まれてることが不可欠だ。多くのスタートアップが彼らのコントロールの外で失敗している中、領域BCでの強いマネジメントに通じているスタートアップは、時間をかけて勝てるプロダクトアイデアを選び出す能力に磨きをかけることができる。

融合領域AC

pillars_template_roles_ac.png
図7: 融合領域AC

融合領域ACは、開発者とって明確で実現可能な計画を作るために、空白Aにある帯と空白Cにある帯が一緒にならなければならない場所である。空白領域Aからのインプットは、エンドユーザーの利益のためにプロダクトは理想的にはどう振る舞うべきかを説明してくれる。空白Cからのインプットは、与えられた利用可能な資源と、競合するビジネス上の優先順位を達成するために、何が可能かを決定づける。この2つの力が領域ACで出会ったとき、しばしばトレードオフが必要になる。理想的なソリューションは多くの場合、高価すぎるか、きちんと作るには時間がかかりすぎる。融合領域ACは理想主義のデザイナーの夢を打ち砕くところではない。それはビジネスのパラメータの範囲内で、ユーザーのニーズに叶うソリューションを考え出すところなのだ。

融合領域ACは実用最小限のプロダクト(MVP)という概念が生まれる場所である。MVPの開発とは、手元でビジネスの仮説を検証したり無効にしたりするための手法で、ユーザーがプロダクトに到達可能にするために最少量の労力を費やすことである。効果的にMVPを生み出せる会社の能力は、素早く反復し、学習し、究極的には成功するプロダクトを見つけ出す能力に等しい。MVPに機能を入れるのか入れないのかを決めることは、一種の芸術だ。このためには、何がユーザーにとって本当の問題で、プロダクトは発展のためにどのように位置づけられるかを感じ取る感覚が求められる。

プロダクトマネージャーの責任範囲

ここまでプロダクトネットワークとその様々な領域を見てきたので、我々はプロダクトマネジメントがパズルにどうはめ込まれるかを説明するためのコンテキストを手に入れた。最初にプロダクトマネジメント求められていないことが何かについて書いておくのは価値があることだ。幾人かのプロダクトマネージャーは、開発者の帽子を被ることができるにもかかわらず、プロダクトマネージャーの役割にはプロダクトそのものに手を触れること、例えばコードをアップデートすることは求められていない。それは開発者の仕事なのだ。プロダクトについて最も責任を持っている人間(プロダクトマネージャー)がプロダクトに直接手を触れることには責任を持っていないことが、プロダクトマネジメントの特筆すべき点である。

ではプロダクトマネージャーは何をすればいいのだろう?我々はこの謎めいた回答の正しい意味を知るための前提を既に手に入れている。

プロダクトマネージャーはプロダクトネットワークの全ての領域を健全に機能させることに責任を持っている

ここで言う責任は、ここまで話してきた空白領域と融合領域という2つの包括的なカテゴリーにマッピングされる。

  1. プロダクトマネジメントはプロダクトネットワークの要素間の重要な空白領域を認識し、埋めなければならない。すなわち領域A、B、Cのマネジメントだ。もし必須のリンクが見つからなければ、プロダクトマネージャーはそのリンクの役割を演じる、もしくは役割を埋める方法を探さなければならない。このために、プロダクトマネージャーはWebアナリティクスから顧客担当やプロジェクトマネジメントまで、プロダクトを取り巻く役割を曲がりなりにも適切に機能するくらいまでは務めることができなければならない。
  2. プロダクトマネジメントはプロダクトネットワークの各要素に影響を与えるために、異なるインプットを統合しなければならない。すなわち領域AB、BC、ACのマネジメントだ。プロダクトマネージャーはそれぞれの要素のための会社の物語を持っておく必要がある。開発者はやるべきことについての明快なストーリーを求める。ユーザーはプロダクトをどう使うかについての明快なストーリーを求める。ビジネスは世界に対するプロダクトの貢献についての明快なストーリーを求める。統合という役割を通じて、プロダクトマネージャーはこのストーリーたちの作者であり伝道者になるのだ。

これらの2つの機能はプロダクトマネジメントの陰と陽だ。プロダクトネットワークにミッシングリンクを追加することによって、プロダクトマネージャーはシステムに必要なだけの複雑さを追加する。これとは反対に統合は引き算だ。プロダクトマネージャーはプロダクトネットワークの各インプットが絡み合う複雑さを理解し、ユーザー、ビジネス、そしてエンジニアリングの要求という中核要素に向けてプロダクトを引き算していかなければならない。

私は上述したプロダクトマネージャーの責任は、会社やプロダクトシナリオを問わず常に真であると信じている。もしあなたがこれらの2つの機能を果たしていないなら、あなたは「プロダクトマネージャー」ではない。しかしながら、この説明はとても概念的なものだ。これらの2つの責任カテゴリの中で、プロダクトマネージャーによる活動は、状況に応じて幅広く存在する。イントロダクションとして、私は概念とプロダクトマネージャーの確固たる責務の間に橋を架ける努力をしてみたい。このエッセイの残りでは、ある会社のシナリオを上述の2つのカテゴリに分類されたプロダクトマネージャーの責務にどのように移すかを説明していく。

プロダクトマネジメントのシナリオ例

プロダクトネットワークを紹介したとき、開発者はソフトウェア製品を作る中で唯一求められる役割だと説明した。誰かがコードの出荷を必要とする。「空白」についての議論の中で、私は会社は成長のために、プロダクトネットワークの中の空白領域A、B、Cに描かれたより多彩な職務を満たさなければならないということを説明した。スタートアップが資金調達をするとき、こうした非開発者の職務の補充が始まる。もしビジネスがグロースに到達したら、組織はより専門性の高いポジションを増やしながらスケールする。しかしながら、非開発者の社員の役割を具体化する方法には大きな食い違いがある。いくつかの会社はすぐにプロダクトマネージャーを追加する。他の会社は最初のプロダクトマネージャーを採用する前に、デザインや営業の専門家を増やすことから始める。会社が非開発者の役割を追加する順番は、業務領域と現在のチームのスキルセットによる。

消費者向けスタートアップは、しばしば早い時期に専任のデザイナー(空白A)を採用する。なぜならビジュアルの印象は、限られたアテンションの期間の中でウェブ訪問者の注意を引くために決定的に重要だからだ。一方でエンタープライズ向けのスタートアップは、しょっぱなからビジネス開発の役割(空白B)を埋めたがる。この場合、製品の有効性を確かめる方法は、コアの機能性に基づいた組織に売れるかどうかにかかっている。優れたビジュアルデザインは常に大切だが、ゲームの序盤では重要性は低くなる。

これもさらに特筆すべきことなのだが、特にアーリーステージのスタートアップにおいては、開発者がプログラミングによる貢献の上に、さらに非開発者の役割も勤めている。開発者がデザイナー、プロジェクトマネージャー、CEOとして振る舞うのはよく見られる光景だ。開発チームのプログラミング以外の能力は、非開発者によって埋められる空白のどの部分に会社が注力するべきかに大きく影響を与える。いくつかの会社が熱心なデザイナーを理想的に採用したがっている一方で、開発チームがその分野に十分強ければ、その役割のニーズはそれほど緊急性のあるものではなくなるだろう。

以下の例は、プロダクトネットワークの中でリンクを形成する非開発者の役割の中でも際だったものである。プロダクトマネジメントの責任の特徴を説明する上では多くの変数が存在するが、製品に関わるチームの構造は、プロダクトマネージャーの日々の仕事に大きな影響を与える。

例#1: 開発者 + デザイナー + プロダクトマネージャー

pillars_template_d_bare.png
図8: 開発者 + デザイナー

ある会社が、デザイナーを最初の非開発職として採用したシナリオを考えるところから始めてみよう。私が描いているところでは、この役割は図8の空白A上の「デザイン」と書かれた黄色の帯で表されている。会社がユーザーと開発者をつなぐ役割を補強したいと考えて、プロダクトネットワークの最初のリンクにこの役割を選ぶのはよくあるパターンだ。収益化に注力する前の段階では、多くの会社がユーザーを彼らの価値提案に釘付けにしたいと思っている。すでに述べたとおり、特に消費者向けスタートアップでは、注意が移り変わる前、ほんの数秒だけプロダクトを見てくれる新規ユーザーに、印象を与えて明確に理解してもらえないと、プロダクトは市場で見過ごされることになるだろう。

そこでこう言ってみよう。会社はプロダクトマネージャーを二番目の非開発職として採用しよう。このシナリオでプロダクトマネージャーは何をするべきなのだろうか?繰り返しになるが、プロダクトマネージャーの責任における二つのハイレベルのカテゴリーは

  1. プロダクトネットワークの要素の間の重要な空白を認識し、埋める。
  2. プロダクトマネジメントトライアングルの三つの融合領域の中で、直交している異なるインプットを融合させる。

この例や他の例で、空白A、B、Cと融合領域AB、BC、ACについて考察する際の身近な意味を取り上げてみる。

領域プロダクトマネジメントの責任
認識し、埋めるべきプロダクトネットワークの重要な空白
A 会社が専任のデザイナーを抱えているという事実は、一つの分野においてはこの領域におけるプロダクトマネージャーへの圧力を減らす。しかしながら、デザインリソースだけでは開発者、プロダクト、ユーザーの関係を良好に保つには不十分である。デザインプロセスが成功するためには、ユーザーリサーチやWebアナリティクスのような、他の役職からの支援が欠かせない。プロダクトマネージャーは、彼ら自身が埋めるもしくは誰かが埋めることを求めている役割に気づいて、埋めなければならない。専任デザイナーのスキルセットだけでは、全領域のデザインニーズはカバーできない。例えば、優秀なビジュアルデザイナーと働くときは、プロダクトマネージャーはインフォメーションアーキテクトの役割を果たすことを求められる。伝統的なデザインプロセスから外れた領域Aの埋めるべき空白が存在する。例えば、プロダクトマネージャーは検索エンジン最適化(SEO)、技術サポート、コミュニティマネジメントの任務を担ってほしいというニーズに直面することがあるだろう。
Bもし会社のモデルが事業の開始直後から収益の伸びを示すことを求めているなら、このシナリオの中で領域Bはプロダクトマネージャーが熱心に注力する領域になるだろう。この領域専任の同僚が居ない場合は、プロダクトマネージャーにはこの領域に配置されて埋める責任がある。この重要な存在、埋められていない領域Bの空白は、会社がMBAホルダーのプロダクトマネージャーを探す動機になっている。プロダクトマネージャーは市場の収益ポテンシャルを見積もり、ビジネスモデルを開発する責任を負うことになるだろう。しかし多くのアーリーステージのスタートアップは収益化に注力していない。彼らはユーザーからの大きな需要に応えることに集中している。しかしながら、これはプロダクトマネージャーが領域Bを無視していいということではない。会社が収益に注力していてもいなくても、現在のもしくは潜在的な投資家は会社の辿る道のりを理解したいと思っている。そのために、プロダクトマネージャーはユーザー、プロダクト、ビジネスをつなぐリンクを提供する必要がある。このためには、ユーザーに受け入れられることを、ビジネス価値があるという指標に翻訳することが求められる。リーンスタートアップの用語で言えば、これはプロダクトのエンジンと成長の可能性を定量化することを意味する。プロダクトの仮説が失敗したときは、プロダクトマネージャーは新しいプロダクトのコンセプトを提供するための理論的根拠を持っておかなくてはならない。
C領域Cはこのシナリオにおいても、他のシナリオにおいても、プロダクトマネジメントの責任の中でやりがいがある部分だ。プロダクトマネージャーはビジネスを効果的に推進するプロジェクトにおいて、開発チームに注力するという重要な役割を担わなくてはならない。ここで、プロダクトマネージャーはプロジェクトマネージャーに手を染めなければいけない。プロジェクトマネージャーはすべてのエンジニアリングタスクを調整し、明確にしなければならない。プロダクトマネージャーはプロダクトのすべての細かい変更するという戦略の末端に有りながら、プロダクトのビジネス的な道のりを、エンジニアリングチームを焚きつけて集中させる明快なビジョンとして語るという、抽象的な役割を実行しなければならない。そしてまた、プロダクトマネージャーは中間層としてプロダクトロードマップを持っておく必要がある。例えロードマップが変わることがあるとしても、投資家も開発者も、どのプロジェクトが開発パイプラインに降りてくるかについての長期的な展望を見ておきたいと思っている。
プロダクトネットワーク内の各要素に影響を及ぼす異なるインプットを融合させる
AB 専任デザイナーの存在によって、融合領域ABの重要性は増加する。デザイナーが居ることにより、会社はユーザーのニーズを代弁する強い声を手に入れる。これはもちろん良いことなのだが、ときどきは逆方向からのバランスが必要になることがある。デザイナーによって進められる施策の中には、ビジネスにはほとんど影響がないプロダクトの改善案というのが山ほどあるのだ。例えば、デザイナーが検索のUIを改善したがっているとしよう。しかしプロダクトマネージャーは、検索の欠陥は理想的とは言えないが、ビジネスの成長を妨げるものではないと考える。融合領域ABにおいては、プロダクトマネージャーはデザイナーをビジネスにインパクトがある領域の改善に集中させる役割を担う。そしてときには、デザインのエネルギーをユーザー体験を阻害することに費やさなければならないこともある。例えばユーザーは広告やペイウォールの追加を嫌うだろうが、ビジネスにとっては必要なときもあるのだ。たとえあなたがデザインとビジネスのゴール間にある緊張を無視できたとしても、プロダクトマネージャーはユーザー体験の改善についての様々な視点を融合させることに労力を費やす必要がある。さらにその上、プロダクトマネージャーはSEOの帽子をかぶるかもしれない。例えば、デザイナーがユーザーインターフェイス側の意見として、SEO最適化用のテキストをページから削除したいと言うかもしれない。緊張をほぐすためには、既存ユーザーの体験をシンプルにしたいという要求に対して、検索経由の新規訪問者の獲得という天秤を考える必要がある。できればこの種のコミュニケーションは、対立する部署に置かない方が望ましい。ユーザー層の拡大と、既存ユーザーの満足の対立両方に注力しているビジネス関連の部署は、成果を生み出すだろう。デザイナーが会社の方向性に沿うようにし向けるのは、この領域の責任のうちである。柔軟で現実的なデザイナーであれば、ビジネスの緊張関係をほぐすというプロダクトマネージャーの役割に寄り添ってくれるだろう。
BC 融合させる過程でのプロダクトマネジメントの職務は、外交とコミュニケーションに長けていることを必要とする。プロダクトに対して異なる視点を持つチームメンバーたちをまとめることが要求される。しかしこのシナリオにおいて、融合の仕事はプロダクトマネージャーの心の中で起こる。領域BやCの専任の役割は居ないし、同じページを奪い合う異なる人格の人間が居るわけでもない。それでも、プロダクトマネージャーが主体的に解決しなければいけない緊張関係は存在する。もしビジネスがもがいていたり、お金を使い果たそうとしていたら、どのビジネスアイデアにリソースを投入するかを決めることは、ますます困難さを上げる。次に賭ける場所を決めるのは、プロダクトマネージャーが毎晩考えなければならない。失敗したビジネスアイデアを止めることに失敗すると、会社は崖から飛び降りる方向に突っ走ってしまう。ビジネスを織り込んだ物語を磨いておくことと、その物語に合致するプロジェクトのみにリソースを投入することは、プロダクトマネージャーにとって重要だ。
AC 専任のデザイナーが居る状況では、領域ACにおけるプロダクトマネージャーの責任は、2つのことから構成される。それは (A) プロジェクトにおけるデザインのエネルギーを、最もインパクトのあるコードをリリースすることに集中させること、(B) デザイン主導の機能開発と、他のエンジニアリングタスクの優先度のバランスを取ることである。デザインエネルギーの価値を最適化するというのは、デザインプロセスのインプットとアウトプットの管理に携わるということだ。プロダクトマネージャーはロードマップ上の進行中のプロジェクトで、デザインの関与を必要としているものを特定しておかなくてはならない。デザインが関わるプロジェクトのために、プロダクトマネージャーはユーザーとビジネスゴール、そして現在のプロダクトの状態(実装の困難具合まで含む)についての知識を基にして、明確なデザインのパラメーターとフィードバックを生み出さなくてはならない。しかし、デザインプロセスに制約を加えすぎないことも重要だ。デザイナーはプロダクトマネージャーの想像力を遙かに越えるアイデアを生み出すことがある。デザイナーは局面を変えるような仕事をするために自由を必要とする。デザイナーがプロダクトのモックアップインターフェイスを作ってくると、開発チームが積極的に開発しているものを一足飛びに越えて、デザインのお披露目会が必然的に始まる。これは開発チームが数週間かけてデザインの実装に突き進むような、ウォーターフォールプロジェクトを作るという意味ではない。開発チームがインクリメンタルに実装していくために、最も重要なデザイン要素をプロダクトマネージャーが特定していくのは健全なプロセスだ。プロダクトマネージャーのゴールは、可能なのと同じくらい学びを分散させることである。これにより、デザインの欠陥をすぐに洗い出し、デザインのうち価値が低い機能を開発しないようにすることが可能になる。またプロダクトマネージャーはデザイン駆動の機能開発において、開発チームに精力的に注力させるように指示しなければならない。プロダクト発見の段階においては、プロダクトの仮説が良いか悪いかを検証するため、技術的負債を増やしながらも、多様なデザインの方向性を素早くプロトタイプすることが受け入れられる。しかしプロダクトが成熟してくると、開発チームのエネルギーを費やす先としては、新しいデザインコンセプトの実装は減らして、パフォーマンスやセキュリティ、クロスブラウザ対応、リファクタリングドキュメンテーションを増やすべきである。

例2: 開発者 + デザイナー + ビジネス開発 + プロダクトマネージャー

pillars_template_d_bd.png
図9: 開発者 + デザイナー + ビジネス開発 + プロダクトマネージャー

例2では、専任のビジネス開発の役割が加わっている点が例1と異なっている。この例では融合領域ABにおいて、プロダクトマネージャーが自身の内部でバランスを取っていたユーザーとビジネスのニーズが、外部の緊張状態に変わっている。今では2つの強い声が存在している。デザイナーはユーザーのニーズを代弁しており、ビジネス開発部長はユーザーから金銭的な価値を引き出すことを代弁している。話し合いにおいては、双方の見方が綺麗に揃うときもあるし、そうでないときもある。デザイナーとビジネス開発部長の関係を管理することは、プロダクトマネージャーの重要な仕事になるだろう。プロダクトネットワークの融合領域ABはホットスポットになりそうだ。

融合領域ABの緊張関係は、トライアングルの反対側まで大きな影響を及ぼす。その結果、空白領域Cもまたホットスポットになり得る。正しいビジネスのビジョンは、ユーザーとビジネス的価値の相乗効果を生み出す。プロダクトマネージャーはユーザー基盤とビジネスが共通のゴールを目指すようなビジネス的な物語をこしらえていくために、ビジネス開発部長によるビジネスアイデア(領域BC)を制御しなければならない。例えば、マーケットプレイスがすさまじく成長した理由がこれである。このようなネットワーク効果はインターネットに織り込まれているのだ。プロダクトマネージャーは常に魔法の公式を探そうとするべきだが、デザイナーとビジネス開発部長の手と手を取り合わせて、戦わせないことはそのうちの一つだ。

例3: 開発者 + デザイナー + ビジネス開発 + ビジネスビジョン + プロダクトマネージャー

pillars_template_d_proj2.png
図10: 開発者 + デザイナー + ビジネス開発 + ビジネスビジョン + プロダクトマネージャー

例3にはビジネスビジョンを持っている人間という、三番目の非開発者職が含まれている。この役割は一般的にCEOが担当する。ビジョナリー的なCEOは、開発チームに会社のミッションと戦略を伝える最も重要な人間になるだろう。しかしこれでプロダクトマネージャーが領域Cの責任から解放されるわけではない。ところどころでは、事態はよりややこしくなるだろう。プロダクトマネージャーはCEOのビジョンを、北極星を目指すためのプロダクトロードマップに翻訳しなければならない。もしそのビジョンの構成要素がユーザーやビジネスの立場から無価値だったときは、プロダクトマネージャーはCEOの期待をうまくコントロールし、ビジョンをふさわしいものに変更するように焚きつけなければならない。このように空白を埋めることを「上司をうまく使う(managing up)」と呼ぶ。

今や三種類の非開発職がプロダクトネットワーク上でリンクを形成している(デザイン、ビジネス開発、ビジネスビジョン)。ここまでプロダクトマネジメントの責務の変遷として、融合領域の割合が増え、空白を埋める役割を減らす方向へシフトしてきたことを見てきた。このシナリオで成功するプロダクトマネージャーの特徴とは、外交手腕に長け、感化を通してコントロールすることがうまく、共創的な問題解決のスキルを持っている人間である。

例4: 人が増えたプロダクト組織

pillars_template_d_full.png
図11: 人が増えたプロダクト組織

例4に示すのは人が増えたプロダクト組織だ。今や我々はアーリーステージのスタートアップの領域から、拡大したスタートアップや成熟した組織の領域にやってきた。このシナリオでは、会社は領域A、B、Cの空白にまたがる帯の職種を埋める社員を雇用している。デザイナー、ユーザーリサーチャー、技術サポート、コミュニティマネジメント、SEOスペシャリスト、営業、戦略提携担当、広報、プロジェクトマネジメント、経理、経営者によるリーダーシップなどの組織を想像してみてほしい。この環境では、プロダクトマネジメントの職責は空白を埋めるのとは逆の、融合領域の比重が高まる。製品の方向についての膨大で多様なインプットを捌くことが、プロダクトマネジメントの主なチャレンジになるだろう。プロダクトネットワークの各要素である開発者、ユーザー、ビジネスのために、展望の全体像を理解することと、物語を練り上げることがプロダクトマネージャーの仕事である。

このシナリオでは、衝突は容易に起こり得る。一つの領域でも、衝突の可能性はある(例えば、領域AでデザインがSEOと衝突する)。しかし隣り合う領域のもめ事を押さえつけても、有害な政治的戦いは続く。このような状況でのプロダクトの成長のためには、プロダクトマネージャーは衝突の矢面に立ち、ことが始まる前に決着をつけなくてはならない。これは、確立された物語によって、一貫性がないインプットをそっとフィルタリングし、新しい問題に敏感で、すべての視点を統合するプロダクトの方向性のフレームワークと、先を見越しながら対話することをプロダクトマネージャーに要求する。

プロダクトマネジメントトライアングルの応用

私はここまで上記の例たちを通して、プロダクトマネジメントトライアングルによる視覚的な語彙が、プロダクトマネジメントのパターンを説明するのに役立つツールであることを示してきた。プロダクトマネジメントの第一の責任は固めること(空白や融合領域を埋めること)であるのに対し、プロダクトマネジメント固有の職務は、会社の人々をプロダクトを磨くように組織した結果に現れる。

プロダクトマネジメントトライアングルという視覚的な語彙の適用により、プロダクトマネジメントをより正確に語ることができる。より具体的な詳細として、なぜ多くの異なった責任を果たすことについての話が「プロダクトマネージャー」というタイトルでシェアされているのかを、これを使って説明することができる。なぜ良いプロダクトマネージャーがいくつかの状況では活躍し、他の状況では活躍できないのかを明らかにすることもできる。一方の成功したスタートアップのプロダクトマネージャーは、広い空白を埋めることを求められる環境で活躍するために、自身の認識を順応させている。他方の卓越した企業のプロダクトマネージャーは、プロダクトネットワークの溝を埋めるための備えはあまりしていないが、複雑な政治的構造のインプットたちを融合させることに秀でている。プロダクトマネージャーそれぞれが、描かれたプロダクトマネジメントトライアングルとプロダクトネットワークの要素間を繋ぐ帯を通じて、組織の中の彼らの役割を表現している。このエクササイズを通して、プロダクトマネージャーはどこに注意を払えばよいのか認識することができる。それは空白A、B、Cか、融合領域AB、BC、ACか。

会社が求めるプロダクトマネージャーの職務要件は、採用したい会社がどのように構成されているかをトライアングルの図に書いて含めれば、より正確なものにできた。この方法では、MBAを持ったプロダクトマネージャーは、会社にユーザー、プロダクト、ビジネスの間に満たすべき十分な空白があるタイミングを明確に見ることができた。またユーザー体験が得意なプロダクトマネージャーは、ユーザーと開発者の間に溝がある好機を捉えることができた。

プロダクトマネジメントトライアングルは、プロダクトマネージャーが自分の役割を効果的に説明したり、自信の強みと弱みについてより良い認識を持つためにも使うことができる。自分の会社の構成についてのプロダクトトライアングルを描くことと、私が例1で作ったような表を書くことによって、プロダクトマネージャーはどの領域が吹き飛びそうかを認識することができる。これは例えば、デザインが営業と衝突しそうである(領域AB)などである。そしてそこがプロダクトマネージャーが融合のために注力するべき場所なのだ。またプロダクトトライアングルは、プロダクトマネージャーが組織の弱点を特定するためにも使える。彼らが領域Cに健全さを取り戻すには、おそらく彼らのアジャイルプロジェクトマネジメント原則を見直す必要があるだろう。

終わりに、私はこのエッセイがプロダクトマネジメントについてのより具体的な議論の発射台として役立つことを望んでいる。そのうちに、私はプロダクトマネジメントトライアングルの各領域についての「ハウツー」について書くつもりでいる。

Kindle Unlimitedにカラマーゾフの兄弟があった

5冊分 (782+756+864+1080+684) / 980 = 4.25 なので4ヶ月で読み切れば元が取れる。普通に読んでいくと2ヶ月くらいかかるので、言うほどお得でもない。普通に買う方が良いかもしれない。

光文社古典新訳文庫がたくさんあるのは良さそうに見える。

スマートフォンアプリ開発における共創的な開発チーム

先日、一休.comを運営する株式会社一休の社内テックトークで『スマートフォンアプリ開発における共創的な開発チーム』というタイトルでお話しさせていただいた。元々、ずっと考えてきたエンジニアとデザイナーのコラボレーションというテーマを言語化してみたいと思っていたのだが、そこに丁度Fablicでの現場の体験を話して欲しいという依頼があったので、絡めた内容でスライドを作った。

しかしこの言語化する作業が想像以上に大変で、週末を二回潰して準備をした。結局今まで勉強したポインタになる書籍を紹介することで、なんとなくバックグラウンドについては察してもらうというスタイルになった。

タイトルも迷って何パターンか書いてみたのだが、最終的には「共創的」という耳慣れない言葉を採用した。本当は「Collavorativeな開発チームでのアプリエンジニアの役割」とかの方が言いたいことに近い気もするが、これはこれで何だかわからないので見送った。

Fablicで使っている手法について紹介したが、自分が入社する前からあったものもあるし、自分が関わって開発したものもある。これらは当然ながらFablicの開発チーム全員の成果であることを強調しておきたい。

とりあえず、現時点で勉強してきたこと、実践してきたことが詰め込まれた発表になったと思う。良い機会を頂いた一休の皆さんに感謝したい。

結構がんばって資料を作ったので、YAPC::Asia Hachioji 2016mid in Shinagawa(飛び入り予定)やpmjp.slack.comオフ会#4でもこの話をしようかと思っています。

iOSとAndroidでReduxを使うサンプルを作った

Flux(とその実装としてのRedux)は中〜大規模のWebクライアントに向いている設計だと思っているので、具体性を出すためにサンプルとしてTwitterクライアントを作ってみた。iOS版はRIDEと同様にReSwiftを使い、Android版はReSwiftを写経したJava版Reduxライブラリを作って同梱している(用途があれば切り出してもいいかも)。

簡易な実装なので、UITableView、RecyclerViewとの同期問題、アニメーションの問題などは積み残しになっている。

普通にアプリケーションを作る場合に比べてFluxはコード量が増える傾向にあるが、一人で簡単なものを作っているだけではFluxのうまみもなく、実装は結構だるかった。開発に1ヶ月以上かかる場合や、チームが2人以上の場合などであればペイすると思う。

影響力の武器を読んだ

有名な本らしく、同僚から薦められたので読んでみた。人が騙されたり、冷静に行動できなくなる現象を解説した本である。セールスやマーケティングで用いられている人間の行動に関する知見が、社会心理学実験の結果を用いて説明される。

確かにとても面白い本で、自分は読んで良かったと思うのだが、同時にこんな知見が流通している世界に住んでいたのか…と唖然としたというか、少し辛い気持ちになった。もちろん騙す知見を流通させる目的の本ではなく、知っていれば騙されるのも防げるというスタンスで、防衛法も書かれている。

プロダクトマネージャーに関心がある自分としては、4章「権威--導かれる服従」に書かれていた、権威や上司には自動的に従ってしまう社会的な特性があるという部分が印象に残った。プロダクトマネージャーは開発チームの上司ではなく、人事権も持っていないことが特徴であると言われている。この知見を元に考えると、プロダクトマネージャーに権威を持たせないことで、メンバーの自律的な行動を引き出すという目的もあるのかもしれないと思った。

影響力の武器[第三版]: なぜ、人は動かされるのか

影響力の武器[第三版]: なぜ、人は動かされるのか


設問への回答

内容を覚えておこうと思って、各章の章末にある設問「内容の理解」へ回答を作ってみた(暇なのか?と言われると言葉に詰まるが…)。折角書いたので、以下に自分のメモとしてコピペしておく。ネタバレも含まれる。

第1章 影響力の武器

  • Q1. 動物に見られる固定的動作パターンとはどのようなものか。このような行動パターンは人間行動のいくつかのタイプとどの様な点で類似しているだろうか。またどのような点で異なっているだろうか。

  • A1. 動物の固定的動作パターンとは行動を始める際にある特定、単一のシグナルがきっかけになっているものである。具体的には七面鳥の母鳥が雛を認識する条件は、ピーピー鳴くことだけであって、他の条件はほぼ考慮されない。
    このような行動パターンは、人間の行動の内、少ない指標だけを使って自動的に行動するパターンに類似している。
    異なっている点としては、動物のパターンは生得的なものが多いのに対し、人間のパターンは成長期に学習するものが多い点である。また人間が用いる刺激が多種にわたる点も異なっている。

  • Q2. なぜ、人間の自動的反応はこれほど魅力的なのか。また、なぜそれほど危険なのか。

  • A2. 自動的反応は少ないエネルギーと時間で正解にたどり着ける点が、複雑化していく世界に順応するためには大変魅力的である。一方で、深い考察なしに行動してしまう場合が多いので、詐欺などに悪用されることが多い点で危険である。

第2章 返報性--昔からある「ギブ・アンド・テイク」だが……

  • Q1. 返報性のルールとは何か。私たちの社会では、なぜこのルールが強力に作用するのか。

  • A1. 返報性のルールとは、他人が何かをこちらに施したら、自分は似たような形でそのお返しをしなくてはならないというルールである。
    このルールによって人間の活動を広げるに辺り、コミュニティを作って互いに協調して作業したり、異なる集団と交易することが可能となった。このルールが強力に作用するのは、このルールがこうした人間の社会化のための基礎的な条件になっており、深く浸透しているためである。

  • Q2. 承諾誘導の専門家が利用する、返報性のルールの三つの特徴とは何か。

  • A2.

    1. このルールは非常に強い力を持っている
    2. このルールは望まない相手からの望まない行為であっても作動してしまう
    3. このルールは不公平な交換を助長する場合がある

  • Q3. リーガンの研究では、このルールの三つの特徴がどの様に描き出されているか
  • A3. リーガンの研究においては、第一の特徴の発現としてコーラを渡された被験者は二倍もチケットを購入してしまった点が挙げられる。また、第二の特徴では、実験者がコーラを買ってくることは特に被験者から期待されておらず、いわば好意の押し売りであったにも関わらず、被験者達はルールにはまってしまった。第三の特徴では、コーラを渡した参加者はコーラ一缶以上のもうけを出しており、等価な交換が成立していない。

  • Q4. 「拒否したら譲歩」法では、承諾率を高めるために返報への圧力がどの様に利用されているか。
  • A4. 相手が譲歩すると、施しを受けとったことになり、返報性のルールが働くため、こちらも譲歩して相手の好意に応えようとしてしまうため。

  • Q5. 「拒否したら譲歩」法を使うと、受け手はなぜ (a) 同意した内容を実行し、 (b)将来も進んで親切な行為を行おうとするのか。

  • A5. 最終的な合意に参加したという意識が高まり、責任感が生まれるため。また、この方法の受け手は満足度も高まるため、将来もよい顧客となる。

第3章 コミットメントと一貫性--心に住む小鬼

  • Q1. 多くの状況で、なぜ人は一貫性を保ちたいと思い、また一貫していると見られたいと思うのだろうか。
  • A1. 一貫性には私たちの文化の中で高い価値が置かれており、一貫した行動を取ることで論理性、合理性、安定性、誠実さが高く、人格者や知者と見なされるから。

  • Q2. 多くの状況で、なぜ人はかたくなな一貫性でさえ望ましいと思うのだろうか。
  • A2. 一貫性を保つことで、問題についてそれ以上考えなくてもよくなり、楽に生きられるため。

  • Q3. コミットメントが、本人の自己イメージや将来における一貫した行動に影響を及ぼす原因となる要素を四つあげよ。
  • A3.
    1. 行動を含む
    2. 友人知人に知られる
    3. 努力を要する
    4. 自分がそうしたかったのだと思える

  • Q4. なぜ書き記す形のコミットメントが非常に効果的なのか。
  • A4. まず、書き記す形のコミットメントは害がない譲歩に見えるので、相手に行わせることが簡単である。そしてコミットメントの証拠が残り、さらにその証拠を人に見せることもできるために効果的である。
    人は書かれたものは筆者の本心が反映されたものだと思い込む傾向がある。たとえ本心に反して書かされていると知っていてもこのバイアスは有効である。このため、周囲の人間に書き記したものを見せることで、周囲の人間からの見方を変化させ、本人の自己イメージにも影響を与えることができる。

  • Q5. 「承認先取り法」というテクニックと「自分を支える柱を築く」という言葉の関係を述べよ。
  • 承認先取り法とは先にアンケートに答えさせるなどのコミットメントを引き出すことで、その後の判断を有利になる方向に誘導するテクニックである。このテクニックを使うことにより、まず相手に自分を支える柱を築かせて、その後に柱自体を取り去ってしまっても、対象者はすでに築かれた柱により自分の判断を正当化させているので、判断を変更することは難しくなる。

第4章社会的証明--真実は私たちに

  • Q1. 社会的証明の原理について説明し、録音された笑い声を使うと、お笑い番組に対する観客の反応がどのように変わるかを社会的証明の原理に基づいて述べよ。
  • A1. 社会的証明の原理とは、自身の考えが他の人の考えや行動に影響を受けることを言う。特に自分の意見に自信が無いときは他人行動から影響を受けやすい。 お笑い番組ではこの社会的証明の原理から、笑い声が入ると面白いと感じてしまう。特に面白いかの判断がつかない微妙な場面では笑い声の効果が高い。

  • Q2. この世の終わりを主張する教壇のメンバーは、彼らが予言した最後の審判の日が明らかな誤りとなってから、新たな改宗者を求め始めた。なぜか。
  • A2. 教団のメンバーは自分たちの最後の審判が誤りであったという事実に直面し、自分たちの信念が危機に陥ったのを感じ取っていた。そのため、信者を増やすことにより社会的証明を打ち立てようとした。

  • Q3. 個人が社会的証明に最も影響されてしまう二つの要員とは何か。これら二つの要員が強力に作用したガイアナのジョーンズタウンの状況はどの様なものだったか。
  • A3. 二つの要員とは、不確かさと類似性である。不確かさとは確信が持てないときや、状況が曖昧な場合である。類似性とは、自分と似た他者の行動から大きく影響を受けることを言う。 ジョーンズタウンの事件では、服毒自殺を推奨されるという不確かな状況がだった。また現場が南米のガイアナという交流できる他者が居ない僻地であったため、周りの信者から類似性の影響を受けやすい状況にあった。結果として先鋭的な信者が服毒自殺を行った後で、社会的証明の影響で周りの信者も次々自殺する結末になったものと思われる。

  • Q4. 集合的無知とは何か。それは緊急事態に居合わせた人々にどのような影響を及ぼすか。
  • A4. 集合的無知とは、緊急事態に居合わせた際に、どう行動するかという不確かな状況で、周囲の人々の行動から社会的な証拠を引き出そうとするときに起こる。周囲の人々の行動を観察してそれに倣おうとするものの、その人々もまた周りの行動を参考にしようとしているため、結果的には大多数が傍観者になることを選択する結果になってしまう。この現象は人口密度が高い都市部ほど起こりやすい。

  • Q5. 都市のありふれた生活場面で、緊急時に居合わせた人々の介入を拒むものは何か。
  • A5.
    1. 都市の方が騒々しく、変化が激しいため、自分が遭遇した事件の緊急度を確かめるのが難しい
    2. 都市の方が多くの人が居るため、事件に遭遇した際も他の人が周りに居る確率が高い
    3. 都市の方が知り合いの住民の割合が低い

  • Q6. ウェルテル効果とは何か。それは広く報道された自殺記事と、その後の飛行機事故や自動車事故による死亡者の急増との奇妙な関係をどのように説明するのか。
  • A6. ウェルテル効果とは、ゲーテの「若きウェルテルの悩み」が出版された後に、主人公ウェルテルの自殺を真似して自殺者が増加した現象を指す。 このウェルテル効果を現代に当てはめると、自殺が広く報道された際、同効果により自殺願望が高まった人々が意図的な事故を引き起こし、結果として死亡者数が増えることが説明できる。

第5章 好意--優しそうな顔をした泥棒

  • Q1. 「ハロー効果」とは何を意味する言葉か。それは個人の身体的魅力と他者の目から見たその人の魅力全般との関係を説明するのに、どのように役立つか。
  • A1. ハロー(後光)効果とは、ある人が望ましい特徴を一つ持っていることによって、その人に対する見方が大きく影響を受けることを言う。身体的魅力がある人は、この効果によりその人の他の能力(知性、才能、誠実さなど)も高いと見られがちである。結果としてそのような人は対人関係や社会の中で大きな影響を持つことが出来る。

  • Q2. 私たちには、自分を好きだと言ってくれる人(つまり、お世辞を言う人)に好意を感じる傾向がある。また、自分はあなたと同じだと言ってくれる人(つまり、類似した人)を好む傾向もある。後者に関して、類似した他者に対して私たちが自動的にイエスと言う傾向があることを示す証拠はどの様なものがあるか。
  • A2. 保険会社のセールス記録を調べた研究では、年齢、宗教、喫煙の習慣がセールスマンと似ていると客が保険の契約をしやすい傾向があった。 別の研究では、調査を依頼する調査者の名前を受取人の名前に似せると、調査に応ずる人の割合がほぼ二倍になった。 また、さらに別の重い肝臓病の患者リストから手術を受ける順位付けをする実験では、被験者は同じ政党の支持者を先に選んだ。 セールスマンの研修プログラムでははこの傾向を利用して、姿勢、雰囲気、話し方を客に合わせる様に教育している。

  • Q3. 集団間の対立の増大や現象に関する一連の研究が、少年達のサマーキャンプの際に行われた。対立が生じた後、それを弱める効果があったのはどの様な手続きか。また役に立たなかったのは、どのような手続きか。
  • A3.トラックのエンジンがかからない、水道が止まるなどの危機を演出し、共同作業をさせて困難を克服させた場合には対立が弱まった。一方、一緒に居る時間を増やすためにピクニックや催し物を企画した際は対立は弱まらなかった。

  • Q4. 栄光にあずかりたがる傾向(栄光浴)とはどのようなものか。この傾向はどの様な条件、どの様な人々に最も生じやすいか。
  • A4. 栄光浴とは勝利したスポーツチームや政党、有名人などとの関係を強調することにより、自分の優位性を証明しようとする傾向である。著者によれば、このような傾向を持っているのは自分について自己否定的なイメージを持っており、自分一人の力では物事の達成は得られないという見方をしている人々である。具体例としては、バンドのグルーピーやステージママなどが挙げられる。

第6章 権威--導かれる服従

  • Q1. 「実験参加者が相手を傷つけるのを拒まなかったのは、権威者に服従しようとする強い傾向があったからである」というミルグラムの議論を支持する証拠の中で、最も説得的なものはなんだと思うか。
  • A1. 最も説得的な証拠は、実験の参加者の役割を入れ替え、研究者が実験の中止を命じ、参加者の仲間が継続を命じた場合は全員が実験を中止したことである。このことにより、参加者は実験の継続を求められた際に、相手の権威に強い影響を受けていたことがわかる。

  • Q2. 自分の行動に対して権威が及ぼす影響を私たちがどの程度自覚しているかについて、ミルグラムの研究が示しているのはどの様なことか。あなたの考えを支持する証拠をあげよ。
  • A2. 実験の結果から、権威の影響を私たちは意識はしているものの過小評価しがちであるということが言える。社会化の中で埋め込まれた権威に対する服従という行動は、行動を自動化するという観点からは有用だが、危険も存在する。 職場でも、上司が命令という形で現場に指示を出すと、それに対して意見を言ったり決定を覆すことが難しくなる。自分の経験からも、上司が自分より若い場合や、経験が浅い場合、つまり権威が少なく見える場合には意見が言いやすいという傾向があると思う。

  • Q3. 本章で紹介した研究に寄れば、最も影響力のある権威のシンボルは何か、三つあげよ。また、これらのシンボルのうち少なくとも二つについて、それらがどのように作用したか、あなた自身の体験から例を挙げよ。
  • A1. 本章で紹介されている権威者のシンボルは、肩書き、服装、自動車である。 自分自身の肩書きによる権威を感じた経験としては、相手の名刺にPh.Dと書かれていると、相手の話を聞く前から相手を専門家、知識人として扱ってしまう経験が挙げられる。また服装による影響としては、警察官のような格好をした警備会社の職員が見ている前でも、赤信号を渡ることをためらうという行動が挙げられる。

第7章 希少性--わずかなものについての法則

  • Q1. 希少性の原理と、ブレームによる心理的リアクタンス理論はどのような関係にあるか。
  • A1. 商品やサービスが希少なものであるとされると、私たちはその商品に対する自由を失うと解釈できる。心理的リアクタンス理論によると、この場合に私たちは自由を回復したいという欲求から商品に対して反応してしまう。

  • Q2. 「恐るべき二歳児」と十代の若者が、なぜ特にリアクタンス効果を生じやすいのか。
  • A2. その年代の人間はいずれも自分自身を個人として考える感覚が現れてくるので、特に支配、権利、自由といった問題に敏感であるためである。

  • Q4. 禁じられた情報に対して、潜在的な受け手が示す標準的な反応はどのようなものか。 情報へのアクセスが遮断されると、受け手はその情報欲しくなり、また情報の内容に賛同するようになる。
  • A4. この現象は情報を実際には受けとっていない場合でも生じる。また、情報が他では手に入らないものと見なされた場合には説得力が増す。

  • Q5. ウォーチェルらが行ったチョコチップクッキーの研究は、希少性の原理の効果を最大にする状況についてなにを示唆しているか。
  • A5. クッキーが最初から少なかった場合よりも、最初は多く入っていて後から少なく減らされた方がクッキーの評価は高まった。このことから、既にあったものが手に入りにくくなると希少性の原理の効果は高まることが示唆される。 また、クッキーが人気でなくなってしまったと説明された場合と、研究者のミスで別の瓶を渡してしまったと説明された場合では、前者の方がクッキーの評価は高まった。このことから、社会的需要によって数が少なくなった場合は、より希少性が高まることが示唆される。

『チームが機能するとはどういうことか』を読んだ

Incrementsの知人が社内で輪講していると言っていて、気になっていたので読んでみた。創造的なチームを作るために気をつけることと、そのために必要になるリーダーシップについて書かれている本とのこと。

現代のチームが固定されたメンバー制から専門集団の一時的な集まりになっている(例えば病院、災害救助、スタートアップなど)ことから、チーム構造からチームワーク自体へ注目するという意味で動詞のチーミングが提唱される。

心理的安全

自立的かつ創造的なチームのキーになるのが心理的安全である。

心理的に安全な環境では、何かミスをしても、そのためにほかの人から罰せられたり評価を下げられたりすることはないと思える。手助けや情報を求めても、不快に思われたり恥をかかされたりすることはない、とも思える。そうした信念は、人々が互いに信頼し、尊敬し合っているときに生まれ、それによって、このチームでははっきり意見を言ってもばつの悪い思いをさせられたり拒否されたり罰せられたりすることはないという確信が生まれる。

現在持っている知識の限界を認める…あることについて自分は知らないとリーダーが認めると、謙虚さを誠実に示したその姿勢によって、メンバーにも同様の姿勢を持つよう促すことになる。

心理的安全というキーワードの導入により、このチームには心理的安全はあるか、メンバーは心理的安全を感じているかといった議論が可能になるのが良いと思う。

また、心理的安全を高めようというプロジェクトを行って、結果的に失敗する話も書かれていたのが印象的だった。トップダウンで心理的安全高めようぜ!と言っても効果は無く、心理的安全を高める個々のリーダーシップ行動が重要であると書かれている。

心理的安全についてはThe five keys to a successful Google teamで見たことがあったのでGoogleの文化と思っていたが、この本の方が先に出たようだった。

フレーミング

フレーミングの力」という章があるのだが、このフレーミングの概念が今ひとつわからない。

フレーミングは人々に行動を根本的に変えてもらうためのきわめて重要なリーダーシップ行動だ。チーミングと学習を促すときにはなおさら欠かせないものになる。また、フレーミングをすると、人々は前向きで生産的な変化に伴うぼんやりとしたシグナルを察知しやすくなり、自分自身のものの見方に対する理解が容易になる。

文中ではこの言葉がいくつかの意味で使われているように感じる。自分が読み取ったのは以下の通りだが、間違っているかもしれない。

  • 個々人が思い込みや信念を持つこと、またそれを変化させること
  • メンバーに役割を与えて、期待をすり合わせること
  • やってはいけない、踏み込んではいけない領域を示すこと
    • そのことで逆にその範囲内で自由に振る舞えるようになる

バウンダリーオブジェクト

専門性が異なる人間同士の混合チームで境界を越えてコラボレーションするための方法として、バウンダリーオブジェクトという概念が紹介されていた。

ボストン大学のポール・カーライル教授は、自動車産業の新製品開発チームの中にある知識の障壁を研究した。そして、バウンダリー・オブジェクトによって、職業や専門知識による境界が取り払われやすくなることを見出した。模型や図の要素を示したり話し合ったりすると、専門用語のわかりにくさが解消されるのである。

これは自分の仕事で言うと、ペーパープロトタイプやFlintoなどを使って作る動的なプロトタイプが相当する。確かにアイデア段階でデザイナー、エンジニア、ビジネス職が集まって議論する際のベースとして一番有効なのは、見て触れるプロトタイプである。

そしてプロトタイピングいいよねと言うより、バウンダリーオブジェクトとして有効だよね、という視点で考える方が応用範囲が広いように思う(やっていることは同じで、言葉が違うだけなのだが)。自分の意見が理解されないときや相手の意見が理解できないときに「この場合のバウンダリーオブジェクトになるものは何だろう」と考えることで、図を描いたりプロトタイプを作ったりする具体的な行動に移れるようになるのではないか。

おわりに

多少冗長で読むのが辛いところもあるが、現代的なチーム活動とリーダーシップについて大切なことがまとまっていると感じた。自分の経験上も、確かにこの本に書かれている条件が満たされていたチームは良いチームだったと言えると思う。そういう「あー確かに」と言えるような良いチームの条件が言語化されているところに本書の魅力がある。

ワーク・ルールズHow Google Worksが好きであれば、さらに楽しく読めるかもしれない。

4/1追記

PMJPのSlackでドラッカー風エクササイズというのを教えていただいいた。メンバー同士の期待の摺り合わせるためのワークショップとのことなので、チームのキックオフ時や新しい人がジョインした際に行うと、チームの心理的安全を高めることができるかもしれない。

東京駅構内のはせがわ酒店

ここ数年で自分のお酒の嗜好が日本酒に移って、ときどきお店や家で飲んでいる。そして日本酒はだいたい東京駅のはせがわ酒店で買っている。

  • 品揃えが非常に充実、普通の酒屋にはなかなか置いていない人気銘柄がある
  • 180mlの瓶やビールも充実しているので、新幹線で飲むお酒を探すのにも便利
  • 駅構内なので下車料金がかからない

お店の仕入れと回転の良さからか、置いている銘柄が毎日どんどん変わるので、見る度に知らない酒蔵や新作に会えて楽しい。何が入荷しているかはオンライン店の新着をチェックすることである程度把握できる。

しかしIT業界民としては東京の西側が活動の中心になるので、東京駅にはほとんど縁が無い。そこで自分は例えば恵比寿から新宿に行くときも、わざわざ東京駅経由で中央線に乗ったりする(JRの規則的にもOKなはず)。新幹線で関西方面に行くときも最寄りの品川駅ではなく、東京駅まで行って乗っている(…なんでこんなことしてるんだっけ?)。

以上、最寄りにいい酒屋がない民のTipsでした。近所にはせがわ酒店がある人がうらやましい。

余談だけど、新幹線のEX-IC予約は「品川-新大阪」のように品川で取らずに、「東京-新大阪」のように東京駅で予約すると、品川駅でも東京駅でも乗れて便利*1。時間があれば東京駅まで、なければ品川駅でという使い方が可能になる。

アプリ開発と状態遷移の管理

このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。

CROSS2016に出るので、最近の自分の考えを整理しておく。

最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。

アプリは大きなシングルトン

iOSAndroid共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば

  • ユーザーのログイン情報を集約するUserManager
  • コンテンツへのいいね情報を集めるLikesManager
  • ブックマーク情報を集めるBookmarkManager

などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵UserManager以外にも一つ二つはシングルトンが存在していることと思う。これらはどのViewControllerから呼びたいし、状態を一意に保ちたいものたちだ。DIでインスタンス化を制御することはできるが、結局内部的にはシングルトンである。

自分はシングルトンを増やすことには抵抗があった。シングルトンは様々なところから使われ、内部状態が常に書き換わっていく。これが増えていくと、結果的にアプリの内部状態がどうなっているのか把握できなくなっていく。今UserManagerがどんな状態にあるのか(初回の起動なのか?ログインしているか?ユーザー情報の更新は終わったか?)を想像しながらコーディングやデバッグをすることになり、これは結構なストレスである。もちろん今までこれをずっとやってきているわけだが…。

しかしアプリ内でデータを共有したい、データを一意に保ちたいというニーズはなくならない。であれば、アプリは全体が大きなシングルトンであると考えてしまったほうがいいのではないか。ReduxのStoreがそんな思想で作られているかは知らないが、結果的にはそういう作り方を強制される。自分にはこの制約は結構しっくりきている。

内部状態の管理

野放図に作られるシングルトンは更新のための規約を持たない。どこからでも呼び出してメソッドを叩けば更新される。また、更新や状態の読み出しのためのメソッドの命名も実装者依存なので、結果的にはregisterUser, isLoggedIn, addLikeなどの名前が増えて行く(実装者にしても別に名前を混乱させる意図はなく、オブジェクトに注目して命名すれば自然とこうなると思う)。

f:id:ninjinkun:20160304001715p:plain ReSwiftのREADMEから転載

Fluxでは変更をActionに集約するという強い制約がある。すべてのActionはなんらかの状態更新を行うために発行されるので、ActionをLoggerに流していればアプリの起動時からの状態更新をすべて追うことができる。今の所は時々デバッグに使っているくらいなのだが、これをクラッシュ時に送信するというアイデアもあるようなので試してみたいと思っている。

別の効能としては、内部状態が実装者である自分の制御下にあるという、ある種の全能感が得られていてとても気分が良い。状態に起因する不具合があっても、必ず追いかけられるという安心感はとても心を落ち着かせてくれる。

感情的な部分を取り上げたが、内部状態が制御下にあるということは、開発メンバーが加わったり変わったりした際に開発がスケールすることに繋がるはずだ(まだその場面に直面していないので断言はできないけれど)。その辺りは大勢でステートルフなGUIをメンテナンスするという問題に直面したFacebook発祥のフレームワークだなという印象である。規約に沿って書けば誰でも内部状態が管理できる仕組みになっている。

状態遷移の管理

結局の所、ある程度複雑化したクライアントサイド開発とは、状態遷移をいかに管理するかということに尽きるのではないかという気がしている。ユーザーからの入力、サーバーからのGETやPOST、様々なイベントがアプリの内部状態を変化させる。このイベントとそれによって起こる更新処理をどうモデリングして実装に落とすのかでアプリの複雑さは変わってくる。モデリングというと偉そうだが、要するに状態をすべて書き出してその遷移を記述するということである。

もちろん方法はFlux系だけではない。例えば状態遷移をステートマシン(有限オートマトンFSM)として記述するというアイデアもある。今やっている開発の中でReSwiftと並行してSwiftStateも試してみたのだが、ログイン処理などはステートマシンで記述すると読みやすく書けそうだった。ステートマシンを使う手法はゲーム方面ではよく使われていそうなイメージがある(未経験なので詳細は不明)。

状態遷移の管理という観点で捉えると、Flux、ステートマシン、MVVM、Promise、FRP対象としている状態の大きさの違いなのかもしれないとも思う。Fluxはアプリという大きな単位で状態を管理するためのアプローチである。Promiseはもっと小さな単位の状態遷移、ステートマシンはその中間くらいというイメージを持っている。PromiseやObservableはまとめることでより大きな状態遷移を作ることもできるので、小さな状態遷移を積み重ねて大きな状態遷移を作るものとして考えても面白い。

おわりに

増え続ける状態と、その遷移をどうモデリングして管理していくかというのがアプリ開発の課題であると考えている。

しかし状態遷移をすべて書き出すプログラミングは、今までのように状態遷移を意識しないでプログラムを書いていた時よりも大変になる。自分がReSwiftを使っていて感じている問題を以下に書き出しておく。

  • コードの量が増える
    • 特にアラートなど、一時的な状態をViewが持っていたケースを状態に落とそうと思うと大変
  • アニメーションの扱いが大変
    • アニメーションには時間の概念があるが、Reduxにはない
    • コールバックがアニメーション中でも何度も呼ばれる
    • 真面目に扱おうと思うとアニメーションの開始、終了もActionにする必要がある?
  • iOSにはVirtual DOMに相当するものがないので、差分更新を手動でやる必要がある
    • 大抵のViewは構築コストが低いので問題ないが、TableView, CollectionViewは差分更新の仕組みを作った
    • VDOM相当のものが欲しければComponentKit使えとなりそう
  • イベントの連鎖を扱う仕組みがない
  • 個別の状態をsubscribeする仕組みがない
    • subscribeすると自分が関与しないActionでもコールバックが飛んでくる
    • この制約がsubscriberにステートレスな実装を強要している気もするので、悪いわけではないのかも
    • これを解決したDeltaというのもあるけど、どうなんでしょ

現在進行形で実験している最中なので、特に今すぐReSwiftいいよと勧めるつもりはないけれど、この方向性はしばらく掘ってみたい。規模の大きいアプリを構築するために、状態を管理する仕組みが必要というのは今後も出てくる話題だと思う。

ブックマークコメントへの返信

アプリ開発と状態遷移の管理 - ninjinkun's diary

シングルトンが状態を持つというのは悪夢のシナリオでは?

2016/02/03 01:05

アプリ開発と状態遷移の管理 - ninjinkun's diary

それ、シングルトンではなくて、グローバル変数では?スコープがグローバルであることは、シングルトンの要件では無いような……

2016/02/03 09:09

仰るとおり、このエントリではシングルトンをグローバル変数と同義で使っています。言いたかったのはグローバルな状態+手続きなので、リポジトリと言った方が正確だったかもしれません。ただ自分の経験から言うと、クライアントではこの種のリポジトリはシングルトンとして実装されるケースが多かったので、クライアント開発者がイメージしやすい言葉を使いました。

3/30追記

ReSwiftを使ったアプリ「RIDE」がリリースされました。このエントリーで考察したことが実装に反映されているアプリになります。見た目は普通ですが、ウォッチリストの同期部分などを見て頂けるとReSwiftの恩恵がわかるかもです。

4/15追記

ReSwiftについて発表した資料を公開しました。

ReSwiftでアプリの状態管理 - inFablic

コワーキングスペースで聞こえた会話

「すごいエンジニアの人はモナドとかちゃんと知ってて、ユーザーインターフェイスを損なわないようにしてるから」

「もっとモナドをさぁ」

戦争と平和を読んだ

昨年からぼちぼち読んでいて、先日読み終わった。どういう話か知らずに読み始めたのだけど、ナポレオンのロシア遠征を題材に、史実の人物とオリジナルキャラクターを混ぜて作ったフィクションとノンフィクションの間みたいな小説だった。物語の中に戦争の時期と平和の時期があるだけで、特に反戦とかそういう内容ではない。

岩波文庫の新訳がとても読みやすく、また訳者によるロシアの風俗や戦争の話が途中にコラムとして挟まっていて、内容を補完してくれて楽しめるようになっている。

簡潔で気の利いた文章

読んでいると、うまいこと言うなーという箇所がいくつもある。文読む月日とかを書くだけあって、トルストイは簡潔で気の利いた文章に執着があるのかもしれない。以下にいくつか抜粋。

「うん、すばらしい、すばらしい子どもたちだよ」なんでもすばらしいと考えることで、自分には手の負えない問題をいつも解決してきた伯爵が相を打った。

1巻。ロストフ老伯爵という、好人物だが実務能力ゼロという人間を描写した一文。

ニコライは底意地の悪い目でピエールを見ていた。それは、第一に、軽騎兵流の彼の目から見ると、ピエールが文民の金持であり、美人の夫であり、要するに女の腐ったやつだったからだった。

2巻。ピエールは主人公の一人。いきなり莫大な遺産が転がり込んできたというチートキャラ。読んでいると、チートキャラだけど彼なりの辛さも抱えているしな…と感情移入しそうなっているところにこの一節。やっぱりピエールは女の腐ったやつだったのかと胸が空くようなニコライの批評。原文がなんなのか気になるけれど、とりあえずこの訳はとても気持ち良く決まっている。

彼は自分でも気づかないうちに、大きな口に酒を何杯かあおって、体にこころよい暖かさを感じ、近くの者みんなにやさしい愛情を感じ、ありとあらゆる考えに対して、その本質を掘り下げずに、表面的に応答する気になったときにはじめて、完全にいい気分になるのだった。

3巻。酒飲みの思考をトレースしている。

死と戦っている十万を超える人間を、一人の人間が指揮できないことを、彼は長年の戦争の経験で知っており、老人の知恵で悟っていたし、戦闘の運命を決するのは総司令官の指図でもなく、各部隊が占めている位置でもなく、大砲や死者の数でもなく、部隊の士気と呼ばれている、とらえがたい力だということを知っていた。

4巻。マネージャーは無力。

何かを望んでいる人間は、望んでいるものをあたかも裏書きするように、すべての情報をまとめる傾向のあることを知っていた。また、そういう場合、矛盾するものはすべて進んで見逃してしまうことも知っていた

5巻。バイアスについての考察。

以前、彼はいい人間だが、不幸な感じだった。そのため、自然に人は彼を避けていた。今では生の喜びの微笑がたえず口のまわりに漂っており、目には人に対する関心がみんな自分と同じように満足しているだろうか? という問いがかがやいていた。そのため、人は彼といっしょにいるのが楽しかった。

6巻。ピエールが様々な経験を積んで内面が変化した後、人々に受け入れられていく場面。

最終巻になぜか付いている訳者のQ&Aも面白い。

Q 第四巻二二九ページのコラム「貴族の荘園」を読んで、ちょっと寂しくなりました。こんな恵まれた人の書いた小説を、私のようなせせこましい生活をしている人間が理解できるのかと。

A いや、大丈夫ですよ。人間の問題はたいてい時空を越えているでしょう。それに、今の日本人の充足感と空虚感は、ロシア貴族に近いかもしれません。逆に、当時の庶民の重労働や飢餓感を想像することの方が難しいでしょう

著者語る

内容はロマンスありの戦記ものという体裁なので、ぐいぐい読んでしまえる。しかし途中に作者が自分の歴史観を開陳する部分が挿入されていて、これが結構曲者だった。

物語の途中に挿入されている部分は短くてまだよかったのだけど、最後の巻にあるエピローグに文庫の半分のページ数を使ってさらに濃密な語りが入っていて、これがなかなか辛い。物語が終わってからそのまま読み始めたら、全然終わらないし内容は哲学的で小説みたいにテンポよく読めないしで、「俺は早く終わらせて物語の余韻に浸りたいんだよ!」と自分は一人でキレていた。

後日日を空けてから読んだら、歴史と個人の関係を真摯に考察していて面白い文章として読めたので、時間を開けて読むのがいいのかもしれない。

とりあえず今は長い小説を読み終わったあとの満足感に満たされている。

戦争と平和 (一) (岩波文庫)

戦争と平和 (一) (岩波文庫)