開発者とプロダクトオーナーの認識ギャップを埋めるには？ レッドハットのアジャイル支援に学ぶ【デブサミ2019夏】

【B-6】顧客が使いたくなるアプリを作る方法

　デジタルトランスフォーメーションを背景に、システム開発に取り組む企業が増えている。顧客から依頼されるのではなく、自社で新たな顧客体験を提供するアプリでは、顧客に受けいれられるか分からない。またアジャイルやスクラムといった新しい開発スタイルに戸惑う企業も。製品リスクやスクラムチームに関するベストプラクティスをレッドハット 河野彰範氏が解説する。

• 講演資料：顧客が使いたくなるアプリを作る方法

レッドハット株式会社 サービス事業統括本部 第3コンサルティング部 シニアコンサルタント 河野彰範氏

PBIは開発者とPOが一緒に作りあげていくもの

　レッドハットというとLinuxディストリビューターやクラウド関連ソフトウェアで有名だが、近年では「Red Hat Open Innovation Labs」としてアジャイル開発の支援も行っている。登壇する河野彰範氏はスクラムチームのアジャイルコーチとしてアジャイル開発支援に携わっている。今回は顧客が使いたくなるアプリを作ることを目指し、取り組むべき課題の掘り下げと、解決策の共有方法について解説する。

　まずは取り組むべき課題の掘り下げから。アプリを開発しても「誰も使わない」ことは起こりうる。これはリスクだ。誰も使わない製品を開発してしまうリスクを回避するにはどうしたらいいか。

　参考になるのがシリコンバレーで起業時の方法論やマネジメントをまとめた「リーンスタートアップ」。誰も使わない製品を作るリスクに関しては、3つの問いで明らかになることをリスクの高い順に対処していけばいい。問いは次の通り。

• 顧客の存在（顧客はいるか？）
• 顧客の課題に対する理解（顧客がお金を払うに値する課題を見いだせているか？）
• 解決策の妥当性（その解決策は妥当か？）

　「リーンスタートアップ」で体系的にまとまっているため、その通りに進めていけばいいはずだが、実際にはそう簡単ではない。ここではスクラム開発にあてはめて考えていこう。先述した3つの問いに対して、仮説をPBI（Product Backlog Item）の形式へと落とし込むと、スクラムが回っていく。PBIの形式へと落とし込むための重要な5つのステップは次の通り。

1. 顧客に対する理解
2. ビジネスモデルを作成
3. メンバー間で共通理解を醸成
4. MVP（Minimum Viable Product）を定義
5. PBIを明確化

　スクラム開発にまだ慣れていないと「3の『メンバー間で共通理解を醸成』がつまずきポイントになる」と河野氏は指摘する。従来型の開発手法と異なるため、開発者が心理的に戸惑うところだ。

　なぜつまずくのか。そこには開発者たちが持つ暗黙の前提として「PBIはPO（プロダクトオーナー）が作るもの。POが作るPBIは正しい」という認識がありそうだ。従来型の開発体制に慣れていれば、そう考えるのも無理はない。しかし河野氏は「仮説の定義はPOとの共同作業」と指摘する。仮説は開発メンバー全員で作りあげていくものなのだ。

　もし開発者が「POの仮説は正しい」と過信してしまうと、後述するように勇み足で不要な作り込みをしてしまうといった弊害も誘発しかねない。また開発者は良くも悪くもPOに遠慮し、提案を出さないといった状況に陥りがちだ。そうするとPOは影で「こんなに説明しているのに、誰も提案を出してくれない」とさみしく感じたりする。