- 講演資料：プロダクトオーナーシップのすゝめ。
プロトタイピングを行い、サービスのイメージを具象化する
小林氏が所属する開発チームは、「INSUITE」のコンテンツ機能を新規で設計・開発した。コンテンツ機能とは、大企業などで経営メッセージの共有や現場からの発信に使用できるコンテンツマネジメントシステムのこと。Webページや動画といったコンテンツの作成・配信が簡単にでき、閲覧数やいいね数などの解析機能も有している。
始まりは2年前に遡（さかのぼ）る。同社のCTOから「ユーザーが自ら発信できるような新機能を開発してほしい」という指令が下された。小林氏はUX担当として「新機能として何を実装するか」を先導して考える立場になった。嬉しい気持ちの反面、小林氏は戸惑っていた。なぜなら、過去に経験した案件はすべて仕様が決まっているものばかり。自分で仕様を考えて機能を作るのは初めてだったのだ。
「チームで話し合う場を設け、どんな機能を作りたいかをディスカッションしました。ですが、みんなの言うことはバラバラで、意見がまとまりません。原因を分析するため、各メンバーの意見を『何を作るのか』『どう実現するのか』『どうやって作るのか』の3つに分類しました。
すると、各人が異なる視点で話をしていたことがわかりました。本来であれば、『何を作るのか』を決めたうえで、初めて『どう実現するのか』『どうやって作るのか』を決めることができます。そこで私たちは『何を作るのか』にまずフォーカスしました」
小林氏たちは、プロトタイピングという手法を用いて議論を進める方針をとった。プロトタイピングでは、実働するモデル（プロトタイプ）をプロジェクト早期に作成する。メンバー全員で、サービスのイメージを共有し合いながら議論を進めるのだ。機能やアイデアを具象化することで、ユーザーから早めにフィードバックを得られるという特徴も有している。
機能の方向性を策定する流れは
- サービスを使うユーザー（ペルソナ）を想定する
- プロトタイピングを行ってユーザーの課題を探る
- ユーザーにサービスを使ってもらいながら、方向性が正しいかを確認
というフローに決まった。また、「INSUITE」がカバーする業務領域のうち、新機能では社内報の制作プロセスを支援する方針となった。
ペルソナは、社内報を出してほしいと指示を出す課長のBさんと、社内報を作る文系卒で若手社員Sさんの2名だ。ペルソナをもとに、開発チームはユーザーの課題を探っていく。想定ユースケースを洗い出して分析を行った結果、「社内報の作成・公開がWeb上で完結すれば、各種の課題が解決できること」「文系女子のSさんに『私でも簡単にWebページが作れる』と思ってもらうのが重要であること」がわかってきた。
「プロトタイプを作成して、ユーザーに機能のコンセプトを見てもらいました。すると、非常に好感触でした。進むべき方向は間違っていないと感じ、開発をスタートしました」
試作品（プロトタイプ）を見たユーザーからの声
- SNS的要素が大事だと共感。集合知を生かせるような仕組みが欲しい。
- 利用状況がわかるのは嬉しい。
- ちゃんと伝える、双方向コミュニケーション、悩んでた！
プロジェクト初期フェーズでユーザーからのフィードバックを得られるのは、プロトタイピングの大きな利点なのだ。
「ユーザーの体験をより良くすること」を考え続ける
プロジェクトにおいては、全体的な工数の半分以上を設計に要した。なぜなら、「エンジニアが、ユーザーの気持ちをなかなかイメージできない」という課題に直面したからだ。この課題を解決するため、小林氏は3つの作戦を立てた。
1つ目は「自分の体験を掘り下げてもらう」ことだ。例えば「なぜブログやmixiで体験や気持ちを共有することにワクワクしたのか」を考えてもらう。そうすると、理由がいくつも挙がる。当時の気持ちとその理由を、エンジニアにイメージしてもらうことが可能になるのだ。
エンジニアがイメージしたこと
- プロフとか共有することで「仲間感、つながり感」ができてた！
- Twitterは同じ想いを今、その場で、共感できるから、謎の一体感ある！
- pixivが盛り上がったのは、HTMLがわからなくても簡単に作品が共有できたから。
- リアクションあるとモチベ上がる！
こんなふうに「心が動いた理由」を言語化することで、「サービスにどのような体験が必要か」が明確になる。
2つ目は「社内にいる人物を掘り下げてもらう」こと。例えば、ドリーム・アーツ社内にもWebの社内報を担当する社員がいる。その社員は子を持つ母であり、プログラミング経験は全くない。HTMLが苦手なので、下書きした文章をHTMLに変換する作業に時間がかかっているはずだ。つまり、その社員が機能を使う場面が想像できることで、必要な設計が見えてくる。
3つ目は「とにかく数多くのユーザーインタビューをする」こと。場数を踏むにつれ、インタビューの内容も変化していった。最初は「どんな課題を解決したいですか」といった漠然とした内容だったが、徐々にユーザーの日常生活にフォーカスし、具体的な業務内容を聞く方向にシフトしていった。「これらの施策を行うことで、ユーザーがどう行動してどのような気持ちになるのか、リアルに想像できるようになりました」と小林氏は語る。
設計に時間がかかったものの、その後の開発フェーズは短期間で終了した。全員の認識が事前に合っていたため、手戻りが少なかったのだ。リリースから1年が経った現在では、コンテンツ機能は1万アカウント以上で利用されている。
「プロジェクトを自分ごととして捉え、『何を作るのか』を自分自身で考えることが重要です。そうすることで、『もっとこういう機能にしたい』『担当領域についてもっと勉強したい』『ユーザーからの喜びの声が嬉しい』と実感できます。
自分で考えるからこそ、モチベーション向上につながります。コードを書くことがより楽しくなります。『何万人もの方々に使っていただいている機能を、私たちが作りました』と、実績として情報発信することも可能になりました。『何を作るのか』を自分で考える行為は、エンジニアに幸せをもたらすと私は感じています」
ユーザーの課題を解決するプロダクトを創出するには、日常的にユーザーのことを考え、観察し続ける姿勢が必要だ。「プロダクトオーナーシップに必要なこととは、ユーザーの体験をより良くすることを考え続けられること。そして、それを楽しむことです」と小林氏は結び、セッションは終了した。
お問い合わせ
株式会社ドリーム・アーツ
