自分で言うのも何だが筆者は努力型だと思う。難しいアルゴリズムをすぐに理解したり、高度に洗練されたコードを一瞬で書いたりすることはできない。でもプログラミングはとても楽しい。ゆっくり時間をかけて、何度でもやりなおしができるプログラミングは自分に合っていると思う。そうやって少しずつこつこつと良いエンジニアになっていきたいと考えている。周りには「大器晩成型」だから花開くまで待ってくれと言っている。この連載では筆者が少しずつ学んできたことの中から、技術書であまり語られないが重要なことを紹介していこうと思う。テーマの中心は「良いエンジニアになること」である。
プロダクトの魔法
まるで魔法のようにいとも簡単にすばらしいプロダクトを作り上げてしまう人がいる。だがそれは例外で、一般的にはプロダクトづくりは簡単ではない。プロダクトづくりは共同作業である。そこに難しさがある。筆者のプロダクトエンジニア／テックリードとしての経験に基づき、今回はプロダクトの作り方の「型」を紹介する。
最小チーム
最小のプロダクトチームは、プロダクトマネージャー、デザイナー、ソフトウェアエンジニア（エンジニア）によって構成される。3人が1つのチームとなってプロダクトを作っていく。役割の境界はあいまいな部分もあるが、おおよそ以下のように分かれる。
プロダクトマネージャーは次の役割を担う。
- ユーザーの手元に届く最終的な成果物（プロダクト）に責任を持つ
- ユーザーが抱える課題、およびプロダクトがそれをどうやって解決するかに対して仮説を立てる
- 社内の別チームとのコミュニケーションに責任を持つ
デザイナーは次の役割を担う。
- プロダクトマネージャーと協力してUX（User Experience）に責任を持つ
- デザインに責任を持つ
エンジニアは次の役割を担う。
- プロダクトの実装とテクニカルデザインに責任を持つ
- ソフトウェアの制約を理解し、必要があればほかの選択肢をプロダクトマネージャーとデザイナーに提供する
「責任」と書かれると大げさに聞こえるかもしれないので、もっとやわらかく表現してみよう。プロダクトマネージャーは大きな絵を描く。それは理想的な世界。ユーザーはやりたいことをストレスなく実現できる。デザイナーはそれをデザイン世界の制約やルールにのっとって現実に落とし込む。これで手触りができあがる。エンジニアは技術世界の制約というノミでプロダクトを削り出していく。そうしてユーザーが実際に触るものができあがる。
課題と仮説
もう少し具体的にプロダクトづくりのステップを見ていこう。
まずは解決したいユーザーの課題を定義する。たとえば課題は「ユーザーは写真の共有方法が難しいと感じている」や「ユーザーは切手を買うために郵便局に行く時間がない」などだ。課題を見つけるには、
- 誰かの思いつき
- 生のユーザーの声
- ユーザーリサーチ
- ログデータ分析
などの方法がある。
この課題はプロジェクトの初期段階でチーム全員に共有されるべきである。できればドキュメント化する[1]。そして定期的に見なおすべきである。
紙に印刷してオフィスに貼っておいてもよいかもしれない。プロジェクトが進行にするにつれて、この課題を忘れて別方向に行きがちなので注意する。
ペルソナ
課題定義時には、ターゲットユーザーも明確にしよう。性別、年齢、住んでいる地域、インターネット・スマートフォン習熟度などさまざまな切り口がある。名前と顔のイラスト付きで定義できればさらに良い。そうすればチーム全員の頭におおよそ同じイメージが共有されるだろう。
- ペルソナの例
ひげ田ひげこ（29歳）。主婦。既婚。5歳の男の子がいる。子どもがそろそろ手を離れてきたのでまた働き始めようと考えている。2年前にスマートフォンを購入した。ママ友とのグループチャットに利用している。
デザイン
ここまできたら、実際にホワイトボードや紙を使ってワイヤフレームで画面遷移などを描いてみよう。課題、ペルソナ、解決方法を言葉で共有していても、頭の中でイメージしていることはまったく異なる可能性がある。絵にすればイメージが明確になるだろう。
デザインがある程度決まってきたら、ユーザーリサーチをするのも良い。実際に作り始める前にペーパープロトタイプ、紙芝居などを見せてユーザーの反応を見る。実際のユーザーに見せるのが理想的だが、社内で誰かを見つけるのも良いだろう。
この段階になるとエンジニアには実装に必要な部品が見えてくると思う。JSONAPI、UI（User Interface）コンポーネントなど。デザインに技術的な制約はないか、もっと良いアプローチを提案できないかを思案するのはエンジニアの重要な役割の一つである。エンジニアはここが腕の見せどころだ。
仮説の検証方法
課題とそれに対する解決法はあくまでも仮説だ。実際にプロダクトを出してみて仮説が正しかったか検証する必要がある。
完全に新しいプロダクトの場合は、世に出して問うしかない。
プロダクトに新機能を追加する場合は、A/Bテストフレームワークを使うのが一般的だ。A/Bテストについてはここでは詳述しないが、簡単に言うと「新機能が付いたバージョンA」と「新機能がない今までのバージョンB」をそれぞれ違うランダムなユーザーに見せて、新機能がどれほど効果があったかを測定するためのものだ。ここで大事なのは、「効果がある」を測定可能なメトリクスとして定義することだ。前述の「ユーザーは写真の共有方法が難しいと感じている」という課題であれば、「ユーザーが写真を共有した回数」が良い指標だろう。
A/Bテストの結果を検証する際には1点注意すべきことがある。それは「ユーザーが写真を共有した回数」が上がれば良いとは限らないという点だ。追加した機能に副作用があるかもしれない。たとえば「写真共有を簡単にしたせいで、投稿が写真だらけになってうれしくないユーザーがいる」「写真投稿が増えた代わりに、シェアボタンのタップ数が減った」などである。これらは現在のプロダクトの良い点を壊しているかもしれない。壊していないとしても、少なくともこれらのメトリクスが変化したことに気付ける必要がある。このような大事なメトリクスは、チームであらかじめ定義され、A/Bテストフレームワークで自動的にトラックされるべきである。
実装とテスト
実装はイテレーションで行う。小さな機能ができあがるごとにプロダクトマネージャー、デザイナーに共有して、初期段階で問題を見つけられるようにすべきだ。理想的には席が近くいつでも話せると良い。無理ならばデイリースタンドアップなどで補おう。短いサイクルでひんぱんにフィードバックがもらえるようなしくみづくりをしよう。
実装が一段落したあとはテストだ。チーム内でのテストミーティング[2]を最低2回は行う。テストミーティングでは、チーム全員が集まって想定されるすべてのユースケースを実際にテストしてみる。チーム全員がいることで、「バグなのか仕様なのか」「どうなおすのか」「優先度」などの合意がその場で得られる。バグを見つけるのが目的だが、バグを発見したときに喜びすぎてはだめだ。アプリケーションを実装したエンジニアへの敬意を忘れないようにしよう。そのあとQA（Quality Assuarance、品質保証）によるテストを行う。また、チームでのドッグフーディング[3]が必須である。
リリースとその後
ドッグフーディングを経て、いよいよリリースだ。A/Bテストの場合はいきなり100％のユーザーにリリースすることはない。1％など少数のユーザーにのみリリースをして仮説が正しいかを確かめる。A/Bテストの結果が出るには少なくとも1～2週間はかかる[4]。結果を待つ間は、リアルタイムで入ってくるログデータを見てユーザーの行動を分析したり、Twitter などのSNS（Social Networking Service）で生の声を検索したりするのもよいだろう。データにより仮説が正しいことが証明されたら、徐々に対象となるユーザーを100％に近付けていく。これはバックエンドの負荷を見ながらリリースできるというメリットもある。メトリクスを見て仮説が間違っていた場合や、バグが発見された場合は、次のリリースに備えてここまでのフローをもう一度くり返す。
プロダクトづくりに終わりはない。ユーザーの声を聞き続けよう。常にそのプロダクトのことを考えよう。進化しないプロダクトはゆるやかに死んでしまう。
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！
- 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう
- 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、NFT
