DXの成功には「プロダクトマネジメント」が欠かせない理由

プロダクトづくりでは
「機能」ではなく「課題」を愛せ

　セブンペイやCOCOAの例では、1人の強力なリーダーシップがなくても不具合自体は防げたかもしれません。ただ、あれだけ大勢の関係者が関わっていたはずなのに、プロダクトマネジャーだけでなく、チーム全員が誰ひとり、プロダクトへの強い思い入れ、愛を持っていなかったのではないかと私には思えます。これらのプロダクトでは、おそらくメンバーの皆が「厄介なことを押しつけられた」と考えていたのではないでしょうか。私はプロダクト愛を持ったチームをプロダクト志向チームと呼んでいますが、これらのプロダクトではそういったチームになりきれていなかったと思います。

　COCOAなどは本来、「これで日本を感染症から救えるかもしれない」可能性もある、やりがいのあるプロダクトのはずです。それが、比較的早い段階から不具合に対する指摘があったにもかかわらず、誰も確認をしていませんでした。少なくとも、我々の目に見える形では、誰かが思い入れのある行動を起こしていないことは確かです。セブンペイにしても、関係者がそれぞれ言われたことをやっていただけという印象を受けます。

　私がエンジニア、プロダクトマネジャーとして恵まれていたのは、自分が作ったプロダクトや、チームとして関わったプロダクトへの思い入れが強くあったことです。この思いは今でも消えていません。グーグルで「Chrome」の担当者だった時にも、世の中で一番優れたブラウザーと信じて疑っていなかったし、自信もありました。開発者が集うイベントなどでも、会社に頼まれたわけでもないのにプロダクトへの愛を熱く語ったものです。

　日本企業では、自社のプロダクトについて、そのようには考えていない人が多いのではないでしょうか。これは大変残念なことです。私からすれば、自分が作ったもの、自社が提供しているものなら自信を持ってすすめられるし、仮に人にすすめられないようなものであったなら、社内に働きかけて変えるようにしたいという思いがあります。

　一方で、プロダクト愛が間違った方向へ発揮されると、それはそれで問題となります。これは、Core（世界観）、Why（課題）、What（UXやビジネスモデル）、How（機能）のうちのHowの部分にだけ、肥大化したプロダクト愛が注がれる場合で、技術者や開発者には特にその傾向があります。

　タクシー配車アプリを例に考えてみましょう。技術者はアプリの利点について、最先端のAI技術を取り入れていることなどを熱く語るかもしれません。ところが、ユーザーにとっては「ボタンを押したら、すぐタクシーが来てくれる」ことがアプリの最大のメリットかもしれない。となると、これを実現できるなら、極端に言えばアプリの裏側では人間ががんばって電話で配車していてもいいわけです。

　プロダクト愛のない製品、プロダクト愛の方向性が間違ってしまった製品としては、フィーチャーフォン、いわゆるガラケーなども挙げられるかもしれません。ガラケーには販売時にインストールされているアプリがたくさんありましたが、1つの製品に初めから入っている割には操作性がバラバラで、統一感がないことがほとんどでした。いろいろな開発会社に発注されたアプリは、どれも製品仕様には合っている、つまりHowは満たしているはずなのですが、1つのプロダクトとしての携帯電話のビジョン不在で開発されていたからだと思います。