備考欄に感想を書くタイプのエンジニア

それで出世が遅れ(ry

これまでとこれからのプロダクト マネージャー

本記事は Matt LeMay 氏の記事 "The Past and Future of Product Management" を本人の承諾を得て翻訳した記事です。文章及びスライドの画像は同氏に著作権があります。


数カ月前[*1]、アメリカ新聞編集者協会で開かれるニュース編集室のプロダクト マネージャーの集まりでプレゼンテーションを行ってほしいという依頼がありました。そこで私はこのプレゼンテーションの中に、私が経験してきたこと、見てきたこと、そして失敗してきた(非常に多くの)ことを土台として、「これからのプロダクト マネージメント」について考えを要約しました。このプレゼンテーションはいろいろな意味で私のこれまでのライフワークそのものでした。

私はこの時、プレゼンテーションのスライドをメモ付きの形式で作ったので、これ以降それをそのまま使ってプレゼンテーションの内容を説明します。内容は簡単にまとめると次の通りです。

  • これからのプロダクト マネジメントは、プロダクトを作り出すために実行するプロセスにおいても、顧客を理解するために必要とするデータにおいても、私たちが人間の複雑さを受け入れる能力にかかっている。
  • これからのプロダクト マネジメントは、基本的に補助的で他人に自ら行動することを促進するような役割[*2]であって、「ビジョナリー」になる役割ではない(スティーブ・ジョブズお断り)。
  • 「ハード スキル」と「ソフト スキル」という区別で考えることは概ね逆効果で、最高のプロダクト マネージャーは組織内の多様なものの考え方と役割の間を橋渡しするために必要な「コネクティブ スキル[*3]」を持っている。
  • これまで言われてきたプロダクト マネージャーに求められる様々な「特性や人物像」は、本来の一部のみを見たような、まだ十分に考えられていないものであり、すばらしいプロダクト マネージャーには「デザインが分かるエンジニア」や「コードが書ける UX デザイナー」というような特性の範囲を超えた、まだ活かされていない大きな可能性が残されている。

もし賛同できそうな内容だったり、続きが気になるような内容だったり、逆に明らかにおかしいように思えるのであればそのまま読み続けてみてください。

---プレゼン資料ここから---

-

今日は、私がここ5年で見てきた4つの大きな変化の概要を通して、これからのプロダクト マネージメントについて話します。

-

ただ、4つの具体的な変化の内容について説明に入る前に、もう1つ気がついた、より上位の変化についてお伝えしておこうと思います。私がプロダクト マネージャーとして仕事を始めた時、こういう質問を多く耳にしました。「なぜプロダクト マネージャーを雇ったほうがいいのですか。」場合によっては CTO と技術に明るい創業者が、プロダクト マネージャーを雇わなくてもソフトウェアを顧客に届けることができたと、人前で自慢することもありました。また、時にはプロダクト マネージャーが必要悪のように見えたり、会社組織図と損益計算書の中で仕方なく存在を認められた役割のように見えたりすることもありました。

-

結局こういったたくさんの話が行き着く先は、プロダクト マネージャーは単に純粋な技術的役割として活躍できない二流の開発者という誤った思い込みへとなっていきました。ソフトウェアを顧客に届けるためには開発者が必要でした。それに対してプロダクト マネージャーはよくても「いたらいい」、悪い場合はコードを書いてソフトウェアを展開するような「実際に手を動かす」仕事を邪魔する存在にしかなっていませんでした。

-

このような考え方は未だに幾つかの組織の中には残っていますが、近頃は昔ほど多くは見かけなくなっているように感じます。その代わりに次のようによく質問されます。「どうやってプロダクト マネージャーを雇えばいいのですか。」

-

このように質問される理由の一つは、注目を集めるハイテク製品が表立って期待通りの製品となることに失敗しているためと考えています。(どのような種類にせよ)顧客にソフトウェアを提供するということはそれ自体が全体的な最終目標である、という考え方は5年前よりも今のほうが支持を得づらい状況になっています。加えてベンチャー キャピタルが、収益を第一に考え自分たちのマーケットを正しく理解している企業に、より多くの関心を持つようになるにつれて、「単にソフトウェアを顧客に提供する」という考え方から「顧客に適切なソフトウェアを提供する」という考え方への明らかな変化が立ち現われています。

-

しかしながら、問題は顧客に適切なソフトウェアを提供するために必要とされるスキルセットを明確にすることがより困難になっていることです。開発者を雇うことは決して簡単ではありませんが、究極的には技術的体系に精通していることを何らかの形で示したり、尺度で測ったりすることは、人間系に対してそれを行うよりも簡単です(もし後者ですら可能なのであれば、ですが)。より多くの企業がプロダクト マネジメントは重要なことであると認識するにつれて、どのような要素を持っているのが「よい」プロダクト マネージャーなのかということと、そのような人をどうやって見つけるのかということに関する不安や、明確な答えがなく戸惑う感覚が高まりつつあります。

※Ken Norton 氏が書いた見識のある(そして時代を先取りした)「プロダクト マネージャーを雇う方法(英語)」という記事は必読で、私も気づいたら読み返している良記事です。 www.kennethnorton.com

-

私は、上述の質問に対する答えも同様に時代とともに変化していると考えています。そして今日は、私たちが考える「よい」プロダクト マネージメントという観点から私が見てきた4つの変化について考えを共有します。まず一つ目に話すのは大文字のアジャイルAgile)から小文字のアジャイルagile)[*4]への変化です。

-

これはどういう意味でしょうか。いったん Agile はもともとマニフェスト、つまり価値の宣言だった、という基本の形を振り返ってみる意味はあります。そして、Agile は頻繁にそして継続的に顧客のニーズに合った製品を届けることができる敏捷性を促進する価値をまとめたものです。純粋な形で表現すると「Agile とは一個人として存在している私たち人間の複雑さと必然的な変化を尊重する考え方」ということになります[*5]。

-

皮肉なことに、Agile の価値のまとまりは、高度な考え方と静的なプロセスという形で明文化されました。この考え方とプロセスはどんどん明確になり、また細かく区分されたプロセスとツールで成り立つエコシステムとなりました。そしてこのプロセスとツールは特有の包括的な文書と規則のまとまりを必要としました。

-

しかしながらある意味では、これによってより簡単にプロダクト マネージャーを雇えるようにはなりました。利用したいプロセスを選んで、そのプロセスの専門家を雇えばいいわけです。それで終わりです。

-

ただし、この方法には非常に厳しい制限があります。とりわけ顕著なのは、この方法が適応力が優れていて頭の回転が速い人、つまり agile な人ではなく特定の知識や経験にとらわれている人を雇うことを意味してしまうことです。

アジャイル マニフェストの署名者の一人である Andy Hunt 氏はこのことを自身のブログ記事「Agile の失敗」の中で非常にうまく説明していて、その記事の中で彼が「ルールを守ることの心地よさ」と呼んでいる部分の文章を以下に引用します。

初学者に効果的な唯一の方法は、単純で文脈に依存しないルール、つまり、「これが起こった時はあれを行う」という型になるルールに従うことです。そして、都合のいいことにアジャイル メソッドアジャイルを始めるための幾つかの具体的な実践方法を提供しているため、新しいチームはこれらの実践方法やその一部にとらわれてしまったり、そこから抜け出せなくなったりします。

だから、アジャイルの原則やアジャイル マニフェストの抽象的な考え方を参照する代わりに、可能な範囲でまとめられた実践方法の鉄則を理解して、それ以上先に進みません。アジャイル メソッドアジャイルを実践する人たちに対して自分で考えることを説きますが、正直に言ってそれはなかなか受け入れがたい考え方です。単にアジャイルを実践する人たちに提供されて「型通りにしなさい」と要求する原則に従うほうが、はるかに受け入れられやすくなります。そのほうが簡単ですし、バカにして笑ったり笑い返されたりする心配もありません。そしてその結果としてクビになることもないでしょう。もし誰かに何をやっているのかと聞かれれば「アジャイルを実践している」と答えることができますし、大部分は使えないルールのまとまりを徹底して実行することに集中できます。これでみんな気が楽になります。実際に顧客に何かを提供する時が来るまでは…。

-

そしてこのことは、プロダクト マネジメントの世界で起こっている、これまでのやり方に対するより多くの困難を伴う変化の一つであることを物語っていると私は考えています。そして企業は、プロダクト マネジメントが正しいプロセスを選ぶことではなく、組織全体の中でどのようにやっていくのがよいのかという実績を積み重ねていくことだと気づき始めています。

ここで私が言う「実績を積み重ねる」と言うのはどういうことを意味しているのでしょうか。プロダクト マネジメントは、原理原則を読むことでは十分に習得できないという意味でヨガやマインドフルネス[*6]と似ています(たとえ私がヨガや瞑想から得た経験に何かどんなものであれ効果があったとしても、それが必ずしもすべての人に対して簡単にもしくは自然に訪れる 類のものではありませんが…)。私が見るところでは、一般的に企業が最もしてしまいやすい失敗は、新しいアジャイルAgile) プロセスなるものが実施されるか、新しいプロダクト マネージャーが雇われて、状況がすぐに改善しなかった時にはどちらか一方もしくは両方が失敗だったと明言してしまうことです。問題はツールとプロセスではなく、人と人同士が相互に良い影響を及ぼし合うことの方にあると気づくためだけに、企業がプロダクト マネジメントのプロセスを5回も変えるさまを目にしたこともあります。ツールとプロセスを変更することは比較的簡単ですが、それが人と人同士の相互の影響となると時間を要しますし、楽でもなければ反響も大きいものになります

ツールとプロセスではなく、どのようにやっていくのが良いのかという実績を積見上げていくことという意味でのプロダクト マネジメントの議論の中で、私は Jon Kabat-Zinn 氏が瞑想することについて述べた文が良い教訓になると思っています。

(一般的に人は)リラックスしたり、特有の興奮状態を体験したり、自分を磨いたり、ストレスや痛みを取り除いたり、古い習慣や行動パターンを脱したり、煩悩の束縛から自身を解き放つために瞑想をします。どれも瞑想をする理由としては妥当ですが、もしお望みのこれらのことがただ瞑想をしているからという理由のみで叶えられると考えているのであれば、どれも 同じような問題を抱えることになります。特別な体験をしたり、少しでも望みが叶うことそのものにとらわれてしまい、もしそういった特別な何かをすぐに感じなければ、選択した道が誤っていたのではないかと疑ったり、自分が「正しく行えているか」どうか迷ってしまうでしょう。

-

さて、次に話したい2つ目の変化は、「データ駆動型」プロダクト マネジメントから「顧客駆動型」プロダクト マネジメントへの変化です。

-

おそらくは「ソフト スキル」の一群としてプロダクト マネジメントを見た際に、そのスキルセット関して過剰に不安を持っていることが理由で、「データ駆動型」プロダクト マネージャーの需要が高まっているということを私は耳にしたことがあります。そして、本当に今の時代に「データ駆動型」を望まない人なんているのでしょうか。いるはずがありません。私は自らの PM としてのキャリアを通して、プロダクト マネージャーの権威を確立し、正当性を与える一つの手っ取り早い方法を見つけました。それは、量的「データ」による疑いのない確実性を引き合いに出すこと、ダッシュボードでいっぱいになったスクリーンを眺めて多くの時間を過ごすこと、そしてアナリティクス[*7]のためのツールの評価と管理に十分な時間を費やすことです。

-

ただし、プロダクト マネージャーの仕事はアナリティクスを理解するのではなく、顧客を理解することにあります。「データ駆動型」という言葉は、多くの場合数値を収集する対象となる人々よりも集めた数値のほうに重きをおく考え方を想起させてしまいます。もし私たちのゴールが単にグラフを右肩上がりにすることなのであれば、たとえそれが顧客や私たちの製品の現実の状況を犠牲にしたとしても、特定のグラフを右肩上がりにする要素なら何でも最大限に活用するでしょう。

私の友達でニューヨーク・タイムズのデータ サイエンティストの Mike Dewar 氏は、まさにこのことに関して、リコメンデーション エンジンはメトリクスを最大化することに寄与しているのではなく、むしろ人々の体験をデザインしていくことに寄与していると主張する素晴らしい記事を書いています。

-

ビッグデータ」時代の最も有害で根強い神話のうちの一つに、私たちは数値とダッシュボードを見ることで、「人々が彼ら自身について知っていることよりも多くのことを知ることができる」というものがあります。このような考え方はデータに関する基本的な誤解を招くだけでなく、人間を特徴づける人間性に関しても同様の誤解を招くことになります。私たちが人々の声に耳を傾けることなしに彼らを理解できると考えるのは思い上がりで偏った考え方であり、正直なところ嘆かわしくもあります。実際に人と話すことで、時には困惑したり、気まずくなったり、あからさまにがっかりすることになります。でももし本当に顧客を理解したいのであれば、私たちは人のことを完全に想定できるわけでも数値化できるわけでもないことを受け入れ、それに対応する必要があります。

-

Datascope Analytics 社が自社のブログで公開した風刺漫画は、私たちが時々しょうがなく認めてしまう重要なこと、つまり「データ駆動型」の仕事は、明確な目的がなければただ穴を掘ってはその穴を埋める仕事になってしまうということをうまく捉えています。あるときには、顧客のニーズや行動を過剰に単純化してしまうことによって顧客との距離を広げてしまう見せかけだけの仕事になってしまいます。もし私たちが「なぜ」ということを問わなければ、つまりもし私たちが「データ駆動型」による決定の背後にある乱雑な人間の理性のようなものを探していなければ、プロジェクト マネージャーとしての仕事を全うしていないということになります。 datascopeanalytics.com

-

上述に関連して、次に話したい3つ目の変化は「なに」から「なぜ」への変化です。

-

私が PM として働き始めた時、プロダクトのロードマップを「わがものとすること」にとてもわくわくしていました。次々とアイデアを出すような人、突如として現れたビジョナリーになって会社を良い方向に一変する人になろうとしていました。要するにチームのメンバーに何を作ればよいのかを教えるつもりでした。

-

このような考え方は、プロダクト マネージャーはプロダクトにおける「ミニ CEO」の役割を担っているという思いに端を発しています。PM の仕事を始めた当時、私はこのような考え方がとても気に入っていました。自分がとても重要な人物であるような気にさせてくれましたし、気力が湧いてくるようでした。それどころか、時々この男のことを頭に思い描き始めたりもしました!

-

そういったわけで、私はチームのメンバーが私に「何に取り組めばいいのか」と聞いてくることがとても好きでした。それで私はまるでプロダクトの真の指導者、ロードマップと成功指標の番人、あるいはプロダクトの未来の守護者になったようでした。私一人だけが企業の最も重要なゴールと願望を理解していて、私一人だけがそのゴールを達成できる素晴らしいアイデアをふくらませ、私一人だけがチームにいつどのアイデアを実行すればいいのかを教えようとしました。

-

いま、この考え方は私が問いただしたい別の問題と密接に繋がり合っています。そしてこの問題は正直に言うと私がやってしまったとんでもない失敗です。世の中には開発者とそれ以外の主に経営を行い結果を出すことに責任を持つ他の人々はビジネスもしくはビジネスの主題に関する決定から「分け隔てられる」必要があるという広く支持された考え方があります。開発者はただヘッドフォンをつけて一日中コードを書きたいだけ、そしてもし彼らにビジネスのゴールやユーザーの本質的な欲求の話、つまりなぜ今やっていることを何故やっているのかということを話そうとするのであれば、それは開発者の時間を無駄にし、彼らの特別で非凡な性質をダメにしてしまう原因になってしまっているというようなことです。

私は、これが誤った考え方なだけではなく、あまりにもエンジニアを見下したような考え方だと思っています。別に、単に今やっていることをなぜやるのかということを知らずに、何かを実行することを望んでいる人がいないと考えているわけではありません。ただ一方で、このような考え方を支持した方がいいということはないと明確に考えています。あと、遠慮なく言うと私が見てきた中では、プロダクト マネージャーもしくは経営者が「なぜ」に関する情報を伝えない時は、だいたい彼らがそのなぜということを本当に理解していないです。

-

私がプロダクト マネージャーの仕事を始めた時に誰かに言って欲しかったことは、「ヒーローになろうとするな」ということです。「ビジョナリー」を自称するプロダクト マネージャーは危険な存在です。それで私は、PM の採用面接の最中に某ス****・ジ***氏の名言を連発するような候補者を採用しないようにアドバイスしています。プロダクト マネジメントは、基本的には異なる役割を持つ人たちの間で関係を築き上げ、双方の理解を得られる状態にしていくことであって、どんな作業をするのかを人に伝えることではありません。支援的な役割であり、ビジョナリーではありません。「次に何をすればいいのか」と聞かれたことで私は一時的には気分が良かったですが、実際には PM としていい仕事をしていなかったと一般的には言えます。

特にこういった状況がよく当てはまるのは、私たちの(作業の)優先順位が変わったり、環境が変わった時でした。そして優先順位や環境は常に変わるものです。もしプロジェクト マネージャーが今作っているものをなぜ今作ってるのかということを知らないのであれば、プロジェクトを作業スコープから外すのは(もしくは、初期の段階で技術的な観点からプロジェクトを作業スコープに入れることでさえも)とてつもなく難しいことです。もしチームが今作っているものを何故作っているのかを知らなかったのであれば、彼らがプロジェクトのゴールを実現するために最も適切な技術的決定を下すことはできないでしょう。

結局、私はプロダクトの「リーダー」になろうとすることをやめ、その代わりに企業のゴールが明確で透明性があること、それにそのゴールができる限り多くの人に理解されていることを確認するために尽力しました。その仕事によって自分が重要な人物であるように感じることは少なくなりましたが、チームで協力する働き方が劇的に改善されました。そしていまでは、私が優先順位付けのプロセスをつくり上げる目的で企業と協力して働いている時に、自分に対して「この企業が目指すゴールは、私がここにいなかったとしても、プロダクト チームが同じように効果的に優先度を決めることができる程度に十分に明確になっているか」と問いかけるようになっています。

-

では最後に「ハード スキル」と「ソフト スキル」から、物事を結びつけていくスキルへの変化について話します。

-

PM を雇うときに、PM の能力として「ハードスキル」と「ソフトスキル」のバランスをどう取ればいいのか、ということをしばしば聞かれました。正直なところ、私はまさにこのような区別こそ、企業が最高のポテンシャルを持った PM を見極めるのを妨げる要因であり、また PM が彼らの仕事に自信を持つのを妨げる要因でもあると考えています。

ユーザー分析とプロダクト マネジメントに関して優れた書き手である Megan Kierstead 氏は、ひどい採用面接に最後まで付き合った PM なら多くの人が共感してくれるであろうこんな話をしてくれました。その話の中で起こった出来事は、PM について「ハード スキル」と「ソフト スキル」という観点から考えた時のいわばよくある話です。「ハード」対「ソフト」という言葉そのものが、もともとそれだけで一方が他方に対して特権を与え、たぶん最も害を及ぼすような場合にはどういうわけか一方がもう一方を犠牲にして成り立つゼロサム ゲームを想起させますmedium.com

-

プロダクト マネジメントに関する多くの文献の中に、PM は「十分に技術のことをわかっている」必要があるという考え方を見つけることができます。これはある文脈の中では成り立ちますが、他の場合では裏目に出る考え方です。最もよい場合には、この考え方は、技術に関して効果的に決定を委任し、適切な問いを立てるのに十分な興味と好奇心持っているプロダクト マネージャーを企業に採用させるきっかけになります(もっとも、これらのことができるようになるための技術的なハードルはとても低いです)。最悪の場合には、最高のプロダクト マネージャーにはならず、ほとんどエンジニアと変わらない候補者を採用させることになります

実は採用プロセスの中ではしばしば、ほとんどエンジニアと変わらない PM の候補者がエンジニアリング チームに最も歓迎されます。そうならないわけがありません。こういった候補者はだいたい同じような経験、興味、そして専門技術を持っています。エンジニアリングチームの開発者はこの手の話題を多く持っていますので、「非技術的な」プロダクト マネージャーを採用することで、エンジニアリング チームのエンジニアたちとの仲を引き裂いてしまうことを恐れている採用担当マネージャーは、ホッとして溜息をつくわけです。

不幸なことに、エンジニアと変わらない PM 候補者は、だいたい最初にエンジニアリング チームの面々を惹きつけたまさにその理由でチームの役に立たないという結果に終わります。プロダクト マネージャーとしてのキャリアの初期の頃、私がまだ、そこにいることの正当性の根拠として私が持っているあらゆる技術的な専門知識にしがみついていた時、私は気がつくとよくチームのエンジニアが技術的に最も興味を見出す仕事を失わないように配慮していました。しかしながら、彼らがその仕事における顧客対応の影響に責任をもつこととなってすぐに、私は私が実際には自らのエゴ以外の何も守っていなかったことに気付きました。

私が出会った中で本当に素晴らしくて技術的なスキルを持っている PM は、優先順位付けのプロセスがそれ自体興味深くもあり、そしてやりごたえもあるようなやり方でエンジニアリング チームにそのプロセスに関わってもらう方法を知っています。彼らはエンジニアリング チームに対して情報を提供するのと併せて、彼らに企業のビジネスのゴールに近づくための推進力となるような技術的な決定を下してもらうためにどのように権限を与えればよいかを知っています。言い換えれば、PM の採用に関して成功と失敗を分ける要因は、PM が「十分な技術力を持っている」かどうかではなく、むしろ異なる価値観と専門知識の間を橋渡しするように関係を作ることが非常にうまいかどうかということです

-

では、なぜ「十分な技術力を持った」プロダクト マネージャーという考え方が、あちこちに偏在しているのでしょうか。私には、どちらも額面通りに受け取った時には、とても良いと思われた「エンジニア駆動型カルチャー」と「カルチャー フィット[*8]」という2つの概念が交差するところにこの考え方があるように思えます。理屈の上では、技術的なプロダクトを作る高度に専門化された技術者は、当然彼らがより良い結果を出せる、そして権限が十分に与えられていると感じる環境で働くのが良いでしょう。そしてまたこういった技術者は、当然ながら彼らが尊敬する、賞賛する人々と働くのがよいでしょう。

しかしながら実際のところは、この2つの考え方がしばしばエンジニアは彼らの持つスキルセットを共有する人だけを「尊敬する」という信条となってはっきり表れています。奇妙なのは私がこの信条に遭遇するとき、通常それはエンジニアリング チームから発せられたものではなく、エンジニアの幸せを考え続けているマネジメント チームから発せられていることです。

-

企業がこれほどまでによいPM を採用するのに悪戦苦闘する理由の大部分を占めているのは、カルチャー フィットという考えです。なぜなら、プロダクト マネージャーという役割は仕事の内容が変わりやすく、決まったこれというものがないからです。というのもプロダクト マネージャーの仕事には、「人と人と関わり合いをうまく構築できる能力」を要する面倒な仕事が多いことから、基本的に見た目や行動がエンジニアリング チームやアナリティクス チーム、あるいはその他一緒に協力して働くいかなるチームとほとんど変わらない、わかりやすい人々を雇うことにある種の安心感を生じさせてしまいます。

-

ところが、自称「イノベーティブ」な企業のための、率直に言って滑稽なまでに保守的なものさしになっているカルチャー フィットという考えは、近頃「カルチャー アッド[*9]」という考え方に置き換えられているということを耳にします。この動きは、多様なスキルとものの見方を既存の組織に持ってくる考え方を取り入れることで組織の知識と将来性を大きく広げることを意味しています(友人の Melanie Stern 氏は採用という観点からカルチャー アッドについてとてもよい記事を書いています)。ちなみに私だったら、カルチャー アッドという考え方は、仮に既にあなたのチームのメンバーになっている人々が、新しいものの見方に対して恐怖を感じているというよりもむしろ好奇心を持っているとした場合、彼らに対するアプローチとしても、より思いやりのある方法だということを追記すると思います。 www.pov2050.com

私は、プロダクト マネージャーが組織に与えられる価値を理解する鍵となるのは、上述のような好奇心だと考えています。Scrum と XP のより正確な違いについて饒舌に話すPM の候補者よりも、チームの力学について即興のグループや政治的な組織活動を通じて学んできたことを話す PM の候補者を見るほうがもっとワクワクします。優れた PM というのは、表面上は共通点のないような経験や価値体系、そしてスキルセットの間をまたいで関連付けることができる人たちです

PM としてエンジニアやデータ サイエンティスト、もしくはその他の高度に専門化された才能のある人に気に入ってもらうにはどうすればよいのか、ともし人が私に尋ねたら、私の答えは「コードを書く方法を学ぶこと」ではありません。私の答えは間違いなく「心から彼らがやっている仕事に関心をもつこと」です。このことを理解するのに私は何年もかかってしまいましたが、今となってはこの答えがプロダクト マネジメントにおける議論の余地のない真実だと強く考えています。本当に関心をもつ習慣を作り、それをさらに発展させていくことがプロダクト マネージャーの仕事の大きな部分になります

-

組織の内部で PM の役割を担う候補者を見極めようとしている組織に相談を受けた時、私はしばしば組織内でどのように情報が行き来しているのかを示す図を描いてもらうよう依頼しています。それは組織図というようなものではなくて、単にどのように組織内の人々がお互いにコミュニケーションを行っているのかを表すちょっとしたスケッチのようなものです。大抵の場合、中心のノードとして、他人同士のコミュニケーションをつなぐ人として、または人と人をつなぐ人として数人が浮かび上がってきます。これらの人たちは、一般的にはこれまで言われてきた PM の人物像には合致しません。つまり、彼らはデザインに興味を持つエンジニアではありませんし、いくらかコードが書けるデザイナーでもありません。大抵彼らは営業部門やコミュニティ マネジメント[*10]を行う部門、あるいはマーケティング部門にいます。大抵彼らは完全に「非技術的な」役割を担っています。しかしながら、ほとんどの企業やチームに最低でも1人は、自然に異なった考えや部署の間で連絡をつけるような人がいます。彼らは、agility を理解していて、そして重要な事は、彼らは既にこれまで述べてきた難しい、でも決定的なコネクティブ スキルを持っていることを既に証明している人たちだということです。彼らこそが次の時代のすばらしい PM だと私は信じています

*1:オリジナルの記事は 2015 年 11 月に書かれています。

*2:訳者注: これはコマンド コントロール的な考え方の対比としての意味と判断して訳しています。

*3: 訳者注: 現状一言で言い表す良い言葉がないことと、ハード スキルおよびソフト スキルに対比される言葉としてあえてコネクティブ スキルと訳しました。

*4:訳者注: 以降識別しやすいようにそれぞれ Agile, agile と表記します。

*5:訳者注: アジャイル宣言の背後にある原則を参照のこと http://agilemanifesto.org/iso/ja/principles.html

*6:訳者注: マインドフルネスとは、瞑想を始めとしたストレス対策や健康に関連する活動のようなものらしいのですが、日本語にできないのでそのまま訳しました。

*7:訳者注: アナリティクスとは、日本語にしにくいのでそのまま訳しました。

*8:訳者注: 昨今組織論で話題になりがちな Culture fit については、適切な日本語訳が見当たらないため、そのままカタカナで表記しました。

*9:訳者注: Culture Add という考え方を日本語で表現する例が見当たりませんでしたのでそのままカタカタで表記しました。

*10:訳者注: 文脈からソーシャル メディア上を主とした顧客やステークホルダーに対するコミュニケーションによって製品やサービスを取り巻くコミュニティを良い方向に持っていくような仕事をしている人たちを指していると思われますが、詳細は不明です。