理想のプロダクトにするための本質を整理できれば、開発プロセスや必要な役割は見えてきます。本記事ではKiZUKAIのCTO永山氏の考える「これじゃない感」を生まないプロダクト開発のポイントについてご紹介します。「ユーザー目線でみたらどうでもいいこと」をやっていないか？こう語る永山氏の想いとは。

【株式会社KiZUKAI CTO  永山勇太 氏 プロフィール】

大手グローバル企業にてカスタマーサポートを軸に様々なチャネルでCRMディレクションのノウハウを築き上げる。
自身が経営するIT開発会社の経験を活かし、2016年9月に株式会社モンリッチ（現：株式会社KiZUKAI）のCTOに就任。顧客体験管理が収益につながる次世代型CXMツール「KiZUKAI」の開発に従事し、サービス設計・開発を牽引する。

ITリテラシー格差から生まれるコミュニケーション齟齬

なぜ理想のプロダクトがスムーズに開発できないのか？

日本は諸外国と比較してITリテラシーのレベルが低く、その影響はプロダクト開発にも表れています。プロダクトを作りたいビジネスサイドは「何を／いつまでに／どう解決したいか」が描けても「どうすれば実現できるか」はイメージできないことがあります。イメージできていてもそれを伝えることが難しいため、開発サイドとの齟齬が生まれやすく、意図しない結果につながることがあります。

そのため開発サイドのPMや営業はビジネスサイドの要求をすべて引き出し、どう実現すべきかをしっかり話して合意を取らないと、ビジネスサイドが本来意図していない要件で仕様を固めてしまう恐れがあります。つまり、開発サイドの「この落としどころでいいか」という思い込みが、ビジネスサイドの「求めていたものと違う」という結果につながります。開発サイドがビジネスサイドに対して積極的に認識をすり合わせにいかなければクオリティは上がりません。
また、時間経過とともにビジネスサイドの要求が自覚なくして変わるため、開発サイドは逐一左右確認をしないと正しいゴールが導き出せません。このコミュニケーション齟齬がプロダクトのローンチスピードと品質を低下させ、プロダクトの差別化ができなくなります。

ビジュアルで認識を合わせて取捨選択をする

プロダクトのローンチスピードと品質を高める開発条件とは？

この問題は言葉のやりとりだけでは解決できづらく、同じ日本語を使用していてもビジネスサイドと開発サイドで異なるイメージを持ちます。双方の認識を合わせるためは以下の2つの条件が必要です。

①モックアップを共通言語に

モックアップ（完成の見た目・操作性を示すデザイン）があれば、ビジュアルをベースに会話が進みます。

色や動き、トレンドなどをベースに表層的なデザインを制作するデザイナーが多い一方、ビジネスサイドは「エンドユーザーの課題をどういうプロセスで解決し、どうストレスなく使えるか」を重視してデザインしてもらいたいと思っています。ですが、ビジネスドメインの知識を吸収して本質的なデザイン（設計）ができるデザイナーが非常に少ないのが実情です。

本質的なデザインに対応できるデザイナーがいない場合、ドキュメント（仕様書や要件定義書、フロー図、機能の流れなどを言葉や簡易的に図式化したもの）に沿って話を進めることになります。しかし双方の認識の解像度を高めようとすればするほど、ドキュメントの量は増えていきますし、議論が進むにつれ要件は適宜アップデートされるので、ドキュメント更新の工数がかかり、かつ更新が追いつかずに誤った要件で開発が進むことで後々「こうじゃない」という話になることが多く発生します。さらに、ドキュメントからイメージする完成形は個人差があるため、リリース直前でリカバリーに追われ、リリースに間に合わない事態にもつながることもあります。

日本人エンジニアの場合、単価が高いため工数がかさむと費用は膨大になります。一方、日本と比較して単価の低いオフショア開発では、オフショアサイドもビジネスサイドも言語の壁に気を遣いながら注意深く進めるため、自ずとミスが減り、コスト調整がしやすくなります。

②ミクロ視点とマクロ視点の切り替え、取捨選択の重要性

IT開発は簡単に見える機能ほど難しく、難しそうに感じる機能ほど簡単にできる傾向があるため「どの機能開発が重いのか」はビジネスサイドには見えづらくあります。「作ったけれどエンドユーザーに受け入れられない」というリスクに対応するため、開発側が機能ごとに工数を整理して指し示し、ビジネスサイドが「今やるべきか」の判断をしやすくすることが重要です。

特にプロダクト最初期はできる限り早くローンチしてビジネスサイドの仮説がエンドユーザーに対して結果が出ているか検証し、結果が出ていなければピボットして機能のスクラップアンドビルドを繰り返す必要があります。最初から完璧で規模が大きいものを作るのではなく、必要最小限でプロダクトをリリースし、プロダクトの方向性が変わることを前提においた開発が必要です。これをプロダクトに関わるすべてのステークホルダーが理解している状況を作ることが大切です。

数多くの既存ユーザーがいる大企業の場合、株主への配慮やユーザーからのネガティブな反応を避けるため「緻密な部分まで揃えて出したい」という事情もあると思いますが、中小企業は「ここはミニマム／今回はここまで／2年かけてこのレベルまでいこう」といった柔軟な進め方ができます。
とはいえ大企業も短期的なプロダクト構想はデザインレベルで詳細に描いて開発し、中長期的なプロダクト構想は、先々に新しい開発言語や先端技術が課題を解決する可能性も加味し、マイルストーンレベルで大きい予定の共通認識を持つほうが市場変化を見越したうえでの設計ができ失敗は少なくなります。

プロダクトのローンチスピードと品質を高める開発プロセスとは？

市場のリアクションを見て改変が求められる、世の中に浸透していないサービスやイノベーティブなプロダクトや、プロダクトのリリースを早めたい開発の場合、次の基本プロセスによって失敗を減らすことができます。

（1）要件を固める

実際に手を動かす前に、PMとデザイナーはビジネスサイドと徹底的なブレストを通してあるべき姿の共通認識をすり合わせ、モックアップ作成の要件を固めていく。誰の／何を／どう解決するかを軸に議論をし、プロダクトのあるべき姿を文字レベルでまとめていく。表装デザイナーではなく、ビジネスドメインの知識をキャッチアップして骨格設計ができるデザイナーがPMとともにビジネスサイドと対峙するのが望ましい。

（2）モックアップ作成

文字レベルの情報から本格的なワイヤーレベルのモックアップを設計し、その設計をもとに表装デザインをしてモックアップを作成する。完成したモックアップをビジネスサイドに操作してもらい、違和感や想定と異なる部分を感じてもらい、順次アップデートしてブラッシュアップする。

（3）要件定義書の作成

モックアップだけではエンジニアが開発できないため、「誰が／何のために／どういう課題を解決するために存在する機能」といった前提条件と「ここを押したらこういう選択肢がある」「こういう状況で使用するからこういう動きになっている」など、モックアップをベースに要件を定義する。この段階で全体工数の概算が算出できるので、機能ごとに算出してビジネスサイドに共有する。予定に合わない場合はどの機能を開発し、どの機能を開発しないかを決めて調整するか、予定を遅らせてすべてを開発するかをジャッジする。

（4）エンジニアによる技術検討

モックアップと要件定義書があることで、「リアルタイムで数百人が使う部分だから技術はこれにしよう」などの選定ができ、地に足のついた合理的な解を導き出して開発できるようになる。

（5）プロダクト変化のスピードが遅い場合は仕様書を作成する

プロダクトの変化スピードが遅い場合は保守的な意味合いが強くなり、人員の入れ替えの可能性のほうが高くなるので、入れ替えが起きても即戦力になるよう技術的なドキュメントや仕様書を作り、組織変化によってプロダクト品質が低下するリスクに対応できるようにする。

逆に、プロダクトの変化スピードが早い先進的な開発の場合は、細かいコードレビューやレギュレーション、開発ドキュメントを作成しても、短期的にリプレイスが多発するため工数が無駄になるケースが多いので、人員が入れ替わる際は、現状のプロダクトをキャッチアップして進めてもらったほうが早い場合がほとんどです。

マルチ視点のPM×目的意識の強いエンジニア×非表装デザイナー

プロダクトのローンチスピードと品質を高める開発に必要な役割とは？

プロダクト開発は、ビジネスサイドと開発サイドの間を取り持つPMの質にしばし左右されます。優秀なPMに加え、ボトムアップで意見を出せるエンジニア、優先度を分けた提案ができるデザイナーがいれば、ビジネスサイドの期待値を上回るプロダクト開発が実現できるでしょう。

ビジネスサイドの言葉をエンジニアサイドの言葉に、エンジニアサイドの言葉をビジネスサイドの言葉に通訳できるPM

PMは、ビジネスサイドが自由に話せる状況を作り、引き出した要望をエンドユーザーの立場になってロジカルに整理して開発サイドに伝わる言葉で伝達しなければなりません。それには双方サイドの意図や気持ち、キャラクター性を加味したコミュニケーションスキルが求められます。

エンドユーザーにとって優しい在り方をデザイナーとともに追求し、かつビジネスサイドの要件を欠かない、というマルチ視点で要件を固め、エンジニアに伝わる言葉で伝達すれば、技術的な部分はエンジニアが詳細に設計を進めることができます。

ビジネスサイドに積極的に意見できるエンジニア

東南アジアのエンジニアの人件費は、日本の1/5〜1/3程度だと言われています。そこで「日本人のエンジニアとして求められるのは何か」を考えなければなりません。何が言いたいかというと、「言われたままに実装するだけのエンジニア」なら費用の安い海外人材に軍配が上がってしまうということです。

ビジネスサイドがどういう意図、目的を持ってプロダクト開発をしたいのか、PMがどう話をまとめて今の状況になっているのか、それらを理解したうえで「この技術／順序／プロセスでやろう」とプランニングして実装しないと、ビジネスサイドの要件にフィットしていない意味のないプロダクトができあがります。

ビジネスサイドやPMから落ちてくる要件が必ずしも目的にあった要件でない可能性を加味して、エンジニア目線で目的に対して意見ができる「ビジネスドメインを把握したうえで上流工程に携われるエンジニア」であれば、ビジネスサイドの期待値を越えられ、単価の高い国内人材に軍配が上がります。

表装デザイナではなく、プロダクト設計の目線で本質的なデザインができるデザイナー

toB向け、toC向け、目的にもよりますが、多くのプロダクトにおいてデザインにスタイリッシュさは求められていませんが、どうも表装ばかりに目が行ってしまうお絵かきレベルのデザイナーが多く、デザインで最も重要な「要件」が理解できないために「設計」という意味でのデザインができるデザイナーがほとんどいません。

PMがまとめた文字情報の要件からしっかりワイヤー設計できるデザイナーがいれば、PMは次の機能開発のブレストをビジネスサイドと進めたり、採用などの組織づくりに時間を建設的に使えます。表装をデザインするのは骨格ができたあとで、最後の工程です。

上記の3ポジションの理想形を読んで「そんなハイスペック人材は見つからない」と思うかもしれませんが、ここを妥協するとプロダクトの開発スピードと品質をあげることは難しくなります。上記のような実情に共感する人か、活発で前向きな議論ができるかどうかを採用時に見極めていけば必ず見つかると思いますので、諦めずに時間をかけて見つけてアトラクトすることをおすすめします。

プロダクト開発で重要な考え方とは？

目的と手段を混同しない

当たり前の話ですが忘れられてしまうこととして「プロダクトは手段であり、エンドユーザーが課題解決できることが目的」であり、プロダクトを作ることそのものは目的ではありません。なのでPoCが完了していないうちに「ソースコードが厳密に正しいかどうか」「色が適切か」などを考えても仕方がありません。とにかく動くものを早くリリースしてPoCを終え、PMFが完了して保守的なフェーズに入って初めて緻密な部分の構築に着手すべきです。

もっと言えば、プロダクトを作ってからPoCをするのでは遅いので、まず本物のプロダクトレベルでモックアップ作り、それをステークホルダーにレビューしてもらって反応を確認しながら「ここはだめだからこう変えていこう」「ここの機能不要だね」という話が最初期にアクティブに進む状態が、以降の開発工程をスマートにできます。

「隣り合わせの人たちの仕事を知ること」

ページの表示速度を0.6秒短縮することに躍起になっても、それはユーザーにとってあまりメリットとは言えません。ユーザー視点でやるべきことはもっとあります。

皆、自分の範囲を決めて視野の狭い仕事をしているのではないかと感じることがあります。仕事には必ず前と後ろがあります。誰からバトンを貰って誰に渡すかということです。PMであればビジネスサイドが前で開発チームが後ろ。デザイナーであればPMが前で、エンジニアが後ろ、エンジニアであればデザイナーが前で、ビジネスサイドが後ろ。必ず誰かから仕事を受け取って誰かに自分がした仕事を渡しています。前の人と後ろの人の状況を知っていれば、どうすればスムーズに進むかが見えてきて本質的な仕事ができます。隣り合わせの人たちの仕事を知れば「自分がやろうとしている仕事のやり方は、ユーザーにとって今やるべきことか？」に気づきやすくなります。

自分の領域だけを磨き続けるのではなく、隣り合う人たちの仕事のスキルも間接的に上げていったほうがプロフェッショナルな仕事ができる。「エンドユーザーがプロダクトを使って課題を解決できる状態」をみんなで作り上げていくことが「これじゃない感」を生まないプロダクト開発のポイントではないかと私は考えています。

編集後記

本記事では、KiZUKAIのCTO永山氏の考える「これじゃない感」を生まないプロダクト開発のポイントについてご紹介しました。隣り合わせの人たちの仕事を知ることでプロダクトを作るすべての人が「エンドユーザーがプロダクトを使って課題を解決できる状態」をみんなで作り上げていくことがプロダクトのローンチスピードと品質を高めるポイントでした。

開発3年目のKiZUKAIでは、2022年10月リリースの新機能に向けて、「ソリューションをどうすべきか」の議論を重ねています。「熱量高く話し合って決めたことも1週間後に見返してみるとまだ思考が足りないと感じることもある。そこが何なのかに時間をかけて課題解決の原石を見つけたら後は描くだけ」という永山氏の言葉が印象的でした。

株式会社KiZUKAIは、顧客体験管理が収益につながる次世代型CXMツール「KiZUKAI（キヅカイ）」の開発及び提供を行なっております。
自動ターゲティング/施策の管理/LTVへの効果測定など、データドリブンなCS/CRM運用を支援。またAIによるスコアリングやレコメンド機能も搭載されており、予測的なアクションやレコメンドされたコミュニケーションを実行することも可能です。