アソビューAdvent Calendar 2022の7日目の記事です。
こんにちは。
10月中旬にアソビュー株式会社にフロントエンドエンジニアとして入社いたしまして、入社後およそ2ヶ月ほど経ちました櫻井と申します！
入社直後ですが、アドベントカレンダーを書くという無茶振り(?)を受け、何を書こうか迷っていたのですが、入社直後にジョインしたプロジェクトが実はスタートしたばかりということもあり、まさに今、プロトタイピングから始めているということについて書こうかなと思います。
はじめに
新しくジョインしたプロジェクトは、まさに今現在進行系でユーザーストーリーマッピングからスタートしており、要件定義を行っているフェーズです。そのため、毎日一刻一刻とプロジェクトの状況が変化しています。 先週、いえ、昨日今日決まったことでさえ、明日にはすでに状況が変わってるかもしれない中で、どうのように開発を進めているのでしょうか？
プロトタイプとは？
そもそもプロトタイプとは「試作品」という意味です。 実際のプロダクト開発を進める前に作る、最小限の機能を持ったものを指します。 プロトタイピングとは試作品を作り、実際に機能を触ってもらって、そこからフィードバックで挙がった課題点や改善点を実際のプロダクト開発に生かす開発手法を指します。
プロジェクトの状況
概要
まずは本プロジェクトについてですが、弊社の複数ある既存のSaasシステムの統合や機能拡充を目的として既存の業務プロセスに対して、新規のアプリケーションを開発する大規模プロジェクトになります。 このプロジェクトでカバーする業務範囲やシステム、ユーザーなどステークホルダーの範囲が非常に多くなります。
体制
規模としては初期（10月頃）は20人程度、その後直近は30〜40人ほどに拡大していく予定です。
特徴としては最近入社したメンバーが割合的には多く、全体としては開始時点での業務ドメイン知識が浅いと言えるとは思います。
下記は実際のユーザーストーリーマッピングの一部になるのですが、一部でもかなりのボリュームがあることがわかります。 全体だとさらに膨らむので、合計するとそれなりの時間をかけて進めています。
ユーザーストーリーマッピング
今回はユーザーストーリーマッピングの詳細については本ブログでは触れませんが、ユーザーストーリーマッピングについて簡単にご説明しておくと、ユーザーストーリーマッピングはユーザーの行動を横軸に時系列で並べて、その行動ごとに発生すると思われるアクションや課題を書き出していくという作業になります。そうすることで、開発対象となるプロダクトの全体図が明確になり、チームがやるべきことが把握しやすくなったり、お互いに共通した認識を持ちやすくなるメリットがあります。
下記は実際に行ったユーザーストーリーマッピングの図です。
私は入社後間もなくこちらのユーザーストーリーマッピングの会議にアサインとなったのですが、前提となるドメイン知識が不足していたということもあり、付箋に書き出す作業がなかなか進まなかったこともありました。（前提知識がないことは、既成概念にとらわれないため逆に有利になることはありますね。）
ただ、このユーザーストーリーマッピングの作業を通して、他のメンバーの考えや知識を得ることによって、ドメイン知識を学べるというメリットもあると感じました。
具体的にどのような活動を行ったかは、先日公開された弊社井上のブログをご覧いただけますと幸いです。
具体的な進め方
それではどのようにプロトタイピングを進めているのでしょうか？
プロトタイピングの目的
まず一つ目は、プロトタイピングの目的を明確にする必要があります。
本プロジェクトは前述の通り比較的大規模なプロジェクトであるので、エンジニアサイドだけではなく、ビジネスサイドも巻き込んだプロジェクトであるというのが背景にあります。
したがって、ビジネスサイドの方々とのコミュニケーションが大変大事になると同時に、どのようなプロダクトになるのかのイメージを明確に持ってもらう必要があります。
そこで、このプロトタイピングも目的としては、
- プロトタイピングで作ったプロトタイプを実際に触ってもらい、そこから得たフィードバックをプロダクト開発に生かすため
となります。
このコミュニケーションをきちんと行わないと、エンジニアサイドだけで進めていたが、結構開発が進んだ段階で初めて触ってもらったら、イメージしていたものを全然違った…ーー、などということが起こり、大幅な手戻りとなるかもしれません。また、ビジネスサイドの方々から見たら、一体何を作っているんだろう、どんなプロダクトになるんだろう、と不安をもつことになるかもしれません。
適切なコミュニケーション
上記のようなことにならないようにするために、適切なタイミングでコミュニケーションを行い、フィードバックをもらうことによって課題点を改善することが大切だと思います。
そのため、
- まず、ドキュメント上で仕様を共有してフィードバックをもらう。
- Figma 上で仕様(デザイン)を共有してフィードバックをもらう。
- 実際にプロトタイピング開発で実装した画面をさわってもらう。
ということを行っています。
3つ目はまさに今進行中なのですが、今後プロトタイピングでできた機能を実際に触ってもらうことを予定してます。
実際に操作してもらったり、その様子を観察することによって、ドキュメントやデザイン上では分からなかったような違和感、使いにくさ、新たな利用シーンなどが洗い出され、以降のフェーズの改善点となるはずです。逆に、改善点がわかる一方で、ここはイメージ通りだとか、便利な機能だねというようなポジティブなフィードバックもあるはずなのでエンジニアとしては今後の開発に対するモチベーションになるのではないでしょうか。
技術的な検証
次に、上記で検討した機能が実現できるのか、技術的な視点で検証する必要があります。
せっかく良いアイデアがあってもその機能がそもそも実現可能なのか、スケジュール内でできるものなのだろうかを判断できなくてはなりません。
例えば、画像を読み込んで加工したいという要望があり、
- 読み込んだ画像から複数箇所を矩形でトリミングしてリストで表示したい。
- さらに上記でトリミングした箇所にリンクを設置したい。
- そしてそのリンクの箇所を明るくハイライトして表示したい。
というような機能です。
これらは紙やデザインツール上で説明するより、実際に画面上で操作してもらったほうがよりイメージしやすいはずです。
画像加工に関するライブラリはいくつかあるのですが、例を挙げると、
- fabric.js
- react-image-crop
- react-cropper
:
などいくつか候補となるものがあると思います。
要望を見てみると、リンクの設置や部分的にハイライトするという機能があるためトリミングした箇所の座標も取得する必要がありそうですね。
私がジョインする以前から他のメンバー間でいくつかピックアップされて小さく検証が進められていて、最終的に react-image-crop を導入することとなりました。
(他に、area タグで画像にリンクを埋め込むとか、canvas 要素で描画するなどあるのですが、ここでは割愛させていただきます。)
下記が実際にプロトタイプを作ってみた例です。
画像をドロップアンドドロップで読み込んでトリミングした画像をリストで表示しています。
ちなみに画像のペンギンさんは以前にサンシャイン水族館で撮った子たちです。かわいいですね。
よかったこと/わかったこと
それでは上記のようなプロトタイピングによって、どのようなメリットはあるのでしょうか。
より実際のサービスに近い機能のイメージがしやすくなる
まず一つ目として、上記でも触れたように、ドキュメントやFigma上で作成したもの以上により実際の動きに近い形でチームに共有できる点です。
まだ他の人が操作可能な段階ではないのですが、自分のローカル環境で試作した機能は動く状態になっているので、その画像や動画を撮ってslackで共有すればどういう動きになっているのかをチームのメンバーに確認してもらうことは可能です。
これはチームの朝会や定例の時間を待つことなく、見せられる状態になったら or 見せたくなったらすぐに共有できる点が良い点だと感じました。
ちなみに筆者は、この手法を本プロジェクト以外の場合も頻繁にやっています。
共有→フィードバックのサイクルが早くなる
そして、共有するまでのリードタイムが減るということは、その分フィードバックをもらうまでの時間を短くすることができるという点です。 結果、そのフィードバックを次の改善にスピーディに取り入れることができます。
例えば上の例だと、矩形でのトリミングができそうなことはわかりました。ではこれを実際にビジネスサイドの方々に見てもらいましょう。
すると、「なんかイメージと違うな…。矩形じゃなくて円かな…？」「やっぱり斜めがいいかな…？」といったように、実際に動いている機能を見ることで、新しい議論が生まれる可能性があります。
このように、プロトタイピングを進めることでプロダクトの解像度が上がり、議論を経ることによって、さらにプロダクトが磨かれていくはずです。
プロトタイピングを繰り返す
このようなプロセスを経ると、プロトタイピングは一度実施したら終わりではなく、その結果を元にさらにサイクルを回すことが重要だと思います。
一度矩形でトリミングしたいと要望があったのでプロトタイプを作っても、後からまた異なった要望が来る可能性もあります。
- あくまでもプロトタイプの開発なので、将来的に状況や仕様があるということを想定する。
- そのためには関わっているプロダクトがどのようなプロダクトなのかを深く理解しておく。
- 一度プロトタイピングが完了した後も、引き続きチーム内外と適切なコミュニケーションを維持する。
ということが大切だと感じます。
今後の期待
プロトタイピングが完了した後、実際の開発に入ったらその効果ははっきりと現れるのではないかと期待しています。
まず、ユーザーストーリーマッピングを通して、エンジニア/ビジネスサイドのメンバーがプロダクトの全体図を把握できました。
そして、プロトタイピングを通してプロダクトの解像度が増したことで、やりたいこと・やれること・もっとやれることなどが明確になりましたし、
エンジニアは主な技術的な課題もクリアになっている状態なっているかと思います。
この状態で実際の開発に臨むと、そのプロセスを得ない場合よりもぐっとスピード感をもった開発ができるのではないかと思います。
まとめ
以上のように、大規模プロジェクトにおいて、仕様の策定が並行して進められている状況であったり、技術的に実現可能性かどうかなどの不確実性がある状況においては、プロトタイピングから小さく始めることは、チーム内外のコミュニケーションに貢献したり、開発中のプロダクトをより良くすることに大いに役に立つプロセスです。 今なお絶賛開発中ですが、さらに磨きをかけて、より洗練されたプロダクトになるようにしていきたいと思います！
アソビューでは一緒に働くメンバーを大募集しています！ カジュアル面談もありますので、少しでも興味があればお気軽にご応募いただければと思います！
