SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2019夏】セッションレポート(AD)

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

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

  • X ポスト
  • このエントリーをはてなブックマークに追加
レッドハット株式会社 サービス事業統括本部 第3コンサルティング部 シニアコンサルタント 河野彰範氏
レッドハット株式会社 サービス事業統括本部 第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は影で「こんなに説明しているのに、誰も提案を出してくれない」とさみしく感じたりする。

イベントストーミングで認識の共通化を進めていこう

 メンバー間で共通理解の醸成を進めていくためには、開発者とPOとの間で合意形成を促す仕掛けが重要になる。河野氏は具体策として「複数のプラクティスを組み合わせるワークショップを実施するのはいかがでしょうか」と提案する。

 POが考えたビジネスアイデア(リーンキャンバス)から、イベントストーミングというプラクティスを通じて、プロダクトの全体像(ユーザーストーリーマッピング)を見える化していくというものだ。

 イベントストーミングとは、POとデベロッパーで作ろうとしているものの共通理解を醸成するための設計手法となる。ユーザー体験(オレンジ色のふせん)の流れを追いながら、データ構造や画面をイメージ(黄緑色のふせん)しながら、最終的なPBIの候補(赤枠)が見えてくる。開発者が開発するものを短時間でイメージしやすいといった利点がある。

 開発者とPOの間に起こりがちなギャップとして、他に挙げられるのがムダに対する認識の違いだ。開発者は「どうせ後で作るのだから、最初からきちんと作っておこう」と考える。後から作り直すことがムダであり、本音を言えば「作り直しなんてしたくない」。一方、POは「現時点のアイデアは仮説に過ぎない。使い続けるか分からないアイデアに時間と労力をかけるのはムダ」と考える。

 しかしPOが露骨に「それ要らないかもしれないから(作り込み過ぎないで)」と言ってしまうと、開発者は「ぼくたちは要らないかもしれないものを作っている?」と傷つき、心を痛めてしまうことにもなりかねない。そうした悲劇を防ぐためにも、互いに相手の視点から考えられるような仕組みがあるといい。具体的にはユーザーストーリーマッピングのバリュースライスで可視化をすすめ、認識の共有を進めていく。

 最後に河野氏は「Open Practice Library」を紹介した。今回河野氏が紹介したようなアジャイル開発のベストプラクティスを集約したサイトとなる。レッドハット社員有志からのコントリビュートが多いものの、オープンソースなので誰でもコントリビュート可能だ。「ぜひ参考にしてください」と河野氏は呼びかけた。

お問い合わせ

 レッドハット株式会社

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11637 2019/08/19 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング