「ソフトウェア開発ファシリテーション」アドベントカレンダー16日目の記事です。
アイデアをまず動く形にしてみる、というのはとっても重要なことだと思います。
とりわけ昨今ではペーパープロトタイピングが一般的なリテラシーになってきた感があります。パワポで紙芝居を作るというところから、FigmaやAdobe XDなどを使って、紙芝居ながらも動くプロトタイプを作りながらUXを検証するプロセスは一般化してきたかなと思います。
私は最近Figmaをよく使うようになってきましたが、めちゃめちゃ簡単にペーパープロトを作れるのでとてもお勧めです。個人的にAdobe XDよりもFigmaの方がお勧めだなと思えるのは、無制限の広さを持ったキャンバスの中で画面間の繋がりが掴みやすく、全体像を把握しやすいツールに仕上がっているからです。感覚としてはmiroとAdobe XDとSketchをミックスしたような感じです。miro的なノリでも使えるツールなのが凄いです。
プログラミングそのもののリテラシーがなくても動くものが作れるようになってきたのは素晴らしい一方で、どうしても使用感を通して検証したいケースもあります。例えばチャットの進化形のような形で、複数人でコラボレーションするような画面を設計している場合です。この場合はあーだこーだと絵をこねくり回すよりは、実際にそういう機能を作った方が検証の取れ高は高くなります。
本日の本題は、このような場合にあえてペーパープロトで押し通す必要はないよ、ということです。
ペーパープロトを作るハードルが下がっているのと同時に、プログラミングで動くプロトを作るハードルも下がっています。プロトタイプだと言いつつずっと保守できるようなものを作ろうとするとフツーにソフトウェアを開発するような体制になってしまいますが、例えば上記に挙げたような「コラボレーションが本当に成立するか？」という要点を絞った検証であればもっと機能の規模も小さくできるはずです。
コラボレーションのプロトタイプであればGoogle Firebaseを利用すればリアルタイム通信を比較的容易に実現できますし、デザインもBootstrapやAnt Designなどをカスタマイズなしに活用することを考えればコンポーネントを組み合わせるだけである程度のUIを作ることができます。
業務アプリであればkintoneを活用してプロトタイピングしてしまうのもアリです。この場合はそのまま使い続けられる可能性もあるのがメリットですね。
実際にリアルなデータを交わしながら触ってみないと得られない感覚もあります。今検証するべきはどちらなのか。意外とプログラミングで動くプロトを作るコストも低かったりするので、様々なツールを状況に応じて取捨選択できるセンスが、ソフトウェア開発のファシリテーションには重要かなと思います。何なら、ファシリテーターが動くプロトタイプを作っちゃえれば一番話が早いですね。
