はじめに
こんにちは、エンジニアリングマネージャーの芦川です。なぜ基幹システムを担当している自分がこんな話をするのか。単純に、一度話してみたかったからです。
ニフティのコーポレートメッセージにある「お客様起点」とは、結局のところ何なのか。プロダクトマネジメントを学ぶ中で、ずっとこの問いが根底にありました。AIとの協働開発が広がり、開発のスピードは上がっているのに、それが直接的な成果につながらないという声を色々な会社から聞くようになった今だからこそ、この考え方はより一層大事になってきていると感じています。
書いてみた後の感想ですが、読み返すと中身自体はいたって普通のことでした。ただ、目線を合わせるために、あえて少し強調するように書いています。
まずはプロダクト思考とよく対比される「受託開発思考」をみてみます。
受託開発思考とは何か
クライアントや企画職が要件を考え、開発職がその要件をそのまま作る。一見どこにでもある普通の進め方に見えますね。ですが、これには明確なメリットとデメリットがあります。（プロジェクト思考と呼ばれることもあります）。
受託開発思考のメリデメ
まずはメリットから。お客様に提供する仕様を計画当初から変えたくない場合、ソフトウェアのEOL対応やレガシー環境からの環境移行などやるべきことがはっきり分かっている場合、受託開発思考が適したケースは確かに存在します。
しかし、すべての開発案件にこの考え方を当てはめてしまうと、「要件通りに作ったのに価値が出ない、売れない」「お客様のために作ったのに使われない」といった、プロダクトアウトな状態に陥ることがよくあります。
そのサービスや機能は、リリースしてみないと使われるかどうか、売れるかどうかわからないものになっていませんか。これからお客様になる誰かが、お金を払ってでもそれが欲しいと言ったことはあるでしょうか。
さらにAIとの協働開発が進むと、開発側のループはどんどん速くなっていきます。けれど、提供する価値がそもそも求められていないものであれば、売れないものを増やすだけになってしまいます。開発生産性は上がっても、価値生産性は上がらない。アウトプット（結果）は増えても、アウトカム（成果）は増えないということです。
アジャイルにより動くソフトウェアを早くリリースしよう、と躍起になるだけでも同じことが言えます。
プロダクト思考になろう
そのために基本的には、企画・営業・開発みんなが、それぞれプロダクト思考を持つ必要があるという話です。
企画者は市場やお客様の声を、開発者は実装の実現可能性やログ・データから見える利用実態を、それぞれ異なる立場から持ち寄っています。どちらか一方が持っている情報だけでは、お客様のために「なぜそれを作るのか（Why）」を十分に解像度高く描くことはできません。
だからこそ、企画がエンジニアの領域に越境してみる、エンジニアが企画の領域に越境してみる。双方が互いのフィールドに越境し合うことで、初めてWhyの解像度が上がっていきます。ニフティのような自社に企画職も内製ができるエンジニアもいる意味は、まさにここにあります。
「お客様のこの課題解決、一緒に考えさせてください」「一緒にやりましょう」。そう言えるようになるには、お客様との接点や対話を通じて、どんな価値から対価が得られるのかを理解することが欠かせません。いま手元にあるお客様へ直接価値提供をするためのプロダクトバックログは、お客様の声を起点にしたものになっているでしょうか。
プロダクト思考とは、ユーザーの課題を深く理解し、解決策であるプロダクトを通じて「価値」を提供し、最大化しようとする考え方です。
そもそも「価値」とは何か
ではそもそも価値ってなんでしょうか？機能はイコール価値ではありません。お客様にただリリースしただけでは、それは単なるアウトプットであり、価値ではないのです。お客様の体験が変わり、最終的に対価が得られて初めて、提供価値が生まれます。
どれだけ技術的に優れた、革新的なプロダクトを作ったとしても、事業価値につながらなければ意味がありません。マーケティングと掛け合わせてお客様に届け、実際に使われ、お客様の課題を解決し、お客様がそう感じ、最終的に対価を得られること。ここまでいって初めて、会社としての意味があります。
そもそも「プロダクト」とは何か
プロダクトとはお客様体験そのものであり、機能やUI、コンテンツ、決済機能なども含まれます。お客様に何かを提供し、お客様体験に影響を与えるものすべてがプロダクトです。システムとプロダクトは同じではありません。
セールス、UI、機能・コンテンツ、ログイン、サポート、課金。お客様からすればこれらは地続きの一つの体験であり、プロダクト思考の上では分けて考える意味はありません。代理店経由の販路や電話でのアウトバウンドといったセールスの機能も、お客様体験の一部です。
そもそも「お客様体験」とは何か
お客様体験には、他社の存在や、自社が直接関与していないリアルな体験まで含まれます。例えばECであれば、他社を含めた商品選びの段階からすでにお客様体験は始まっています。
インターネット回線で言えば、申し込み後の工事日程の調整や、ルーターの設置、設定方法がわからず家族に聞くといった、自社から一旦離れたリアルな行動もすべてお客様体験です。つまり、その出来事に関連してお客様が経験したすべてのことを指します。
※文脈によって価値やプロダクトやお客様体験については意見が分かれるところがあると思いますが、今回の記事ではこのような位置づけで進めていきます。
社内システムやプラットフォームチームにも通じる話
プロダクト思考は、お客様と直接接点のある事業だけの話ではありません。社内担当者や基幹システムのようなプラットフォームチームでも同じことが言えます。利用者へのアンケートや個別ヒアリングを行い、組織全体の最適化を考える。ここでも、なぜそれを作るのかを対話を通じて理解し、利用者体験の現状を把握し、これから体験をどう良く変えていくか想像することが欠かせません。
さて、プロダクト思考についてはなんとなくわかりました。が、実際、プロダクト思考を持つエンジニアは、これから何をしていけばよいのでしょうか？
明日からできる3つの行動
① 越境を意識するコミュニケーション
ビジネス側、開発側、CS、営業がそれぞれの領域を越えて理解を深めなければ、会社として良い仕事はできません。複数の業務や複数のシステムが横断して一つの価値提供につながっている場合、自分の担当範囲に仕事を閉じず、他チームに越境してコミュニケーションを取ることが大切です。部署を越えたプロダクトマネジメントの輪読会のような場は、立場の違う意見が交わされる貴重な機会になります。
② いまあるものを理解する、お客様や業務ドメイン知識
長い歴史と多くの会員を抱えていることは、大きな強みです。自社のサービスや構造を知り、業務ドメインを理解する。既存のお客様がどこに価値を感じ、対価を支払ってくれているのかを理解する。歴史が長いということは、過去の失敗も多く積み重なっているということでもあります。
ただし、問い合わせをしてくるお客様はごく一部に過ぎず、その声だけが全体を代表しているわけではないという点には注意が必要です。データ分析やAIによる分析なども積極的に活用していきたいところです。
③ いまないものを学ぶ、ニフティにはまだまだお客様との対話が必要
足りていないお客様との接点を増やすこと。お客様に直接インタビューを行い、他社を含めたリアルな行動や感情について聞いてみる。お金を払ってでも解決したいことは何かを、直接尋ねてみる。自分自身でサービスを利用し、お客様体験を学ぶことも欠かせません。
ここで注意したいのが確証バイアスです。「こういう機能があったらいいと思いますか」と聞いて「あったらいいかも」と答えられても、実際には「自分は使わないけれど誰かは使うかも」という温度感であることが多く、結果として使われない、買われないという事態につながります。拾えていない声や感情、体験にこそ、学ぶべきものがあります。
まとめ
受託開発思考は、依頼された仕様を正確に作るというスタンスで、スケジュール通りに納品し、開発生産性を上げることを重視します。要件が明確で進めやすく、納品という区切りがつけやすい一方、作ることがゴールになりがちであり、お客様への意識が弱くなりやすく、担当範囲の壁を越えにくくなるという側面もあります。
プロダクト思考は、提供価値を理解しユーザー課題を解決するために作るというスタンスで、なぜそれを作るのかを問い続け、価値生産性を上げることを重視します。ユーザー価値に直結した開発ができ、お客様体験の理解が深まり、企画と開発のゴールが一致しやすくなります。一方で、最初から正解が存在するわけではなく、お客様の求めるものを深掘りするには時間がかかります。また終わりはありません。
おわりに
ニフティグループは、お客様、株主、社員、パートナー企業、地域社会などの夢をかなえるため、常にお客様起点で行動し、チャレンジャーとしてサービスを開拓し、社会に役立つ企業として新しい価値の創造に取り組み続けます。
このコーポレートメッセージは、まさにプロダクト思考そのものだと思っています。書いてみて改めて感じたのは、至極当たり前のことを、目線合わせのために言語化しただけだということです。それでも、こうして言葉にしてみることに意味があると信じています。
