【システム開発】重要！プロトタイピングの注意点【発注者視点】

随分昔とは違って、いまはプロトタイピングツールも充実し、システムが完成する前に本物に近い画面イメージや操作性を確認できるようになりました。

この投稿をご覧頂いている多くの皆さまはご存知ないかと思いますが、ひと昔、いやふた昔？とにかく随分と昔の汎用機と呼ばれる巨大なコンピューターでは、いまほど画面がリッチではなく白黒画面でサイズも狭く、手書きで書いた画面イメージと実物はほぼ相違がなかったため、発注者と開発者間でイメージが違うという問題は起きませんでした。

しかし現代のシステム、特にWEBサイトの画面などは芸術作品かと思えるくらいデザインが秀逸であり、操作性も独自性を持たすことができるようになりました。

それは歓迎すべきことなのですが、そこに新たな問題も発生してくるわけです。

今回は、システム開発・WEBサイト構築・アプリ開発では欠かすことができないプロトタイピングにおいて発注者が注意すべき点について解説をします。

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。

プロトタイピングとは

プロトタイプという言葉自体、日常生活の中でも耳にするものですのでイメージが湧くと思います。

システム開発におけるプロトタイピングは、システム開発の初期段階、要件定義フェーズの中、あるいは直後くらいのタイミングで、デザインや機能を視覚的に確認し、発注者と開発者間のシステム完成後のイメージの相違を最小限に押さえるために有効な手段です。

また、システム完成前にユーザーからのフィードバックを得るために非常に有効な手法となります。

しかし発注者がプロトタイピングを効果的に活用するためには、いくつかの重要なポイントに注意を払う必要があります。以下、発注者がプロトタイピングを進める際に注意すべき点を詳しく説明してまいります。

プロトタイピングの目的を明確にする

プロトタイピングを開始する前に、まず発注者はプロトタイプを作成する目的を明確にする必要があります。プロトタイプはさまざまな目的に使用される可能性があり、これをはっきりさせないまま進めると、開発チームとの間で誤解が生じたり、方向性がブレることがあります。

たとえば、プロトタイプがユーザーインターフェースの確認のためなのか、それとも技術的な実現可能性を検証するためのものなのかによって、開発のアプローチが大きく異なります。プロトタイプの目的が不明確なまま進めると、後々修正が必要となり、コストや時間が大幅に増加するリスクがあります。

具体例として、ある企業が新しい会員管理システムを導入するためのプロトタイプを作成したとします。この際、プロトタイプの目的を「ユーザーがどれだけ直感的に操作できるかを確認する」と明確に設定した場合、UIデザインや使い勝手にフォーカスして開発を進めることができます。しかし、目的があいまいだと、デザインと機能のどちらにリソースを集中すべきかがわからず、両方が中途半端になってしまう可能性があります。

プロトタイプの作成範囲を定める

プロトタイピングではその範囲の管理がとても重要です。発注者は、プロトタイプがどの程度の機能を持ち、どの範囲まで開発するかを明確に定義し、過度な範囲拡大を防ぐ必要があります。

これはプロトタイプの目的とも密接に関わってくることですが、簡単に言うとプロトタイピングに凝り始めるとキリがないということです。共通的な動作は、ある画面のみで追求し、他の画面では省略する。あるいは、登録系・参照系・検索系など機能を分類し、その分類ごとに代表画面を決めて細かなUI・UXを決定するということを事前に決めておきます。

また、実際にプログラムを組んで動作するところまで行うのか、画面遷移の範囲まで行うのかによっても、かかるコストは変わります。

プロトタイプの範囲を曖昧にしてしまうと、熱心であるがゆえに結果としてプロジェクトの納期が遅れたり、コストが膨らむ原因となります。プロトタイプは試作品であり、すべての機能を詰め込む必要はありませんので、必要最小限の機能に集中することが重要です。

ユーザーのフィードバックを得る

プロトタイピングの最大の利点は、早期にユーザーのフィードバックを得ることができるという点です。発注者はこのフィードバックを適切に収集し、それを開発プロセスに反映させることが成功への鍵となります。

思い当たることが1つや2つあると思うのですが、最初は使いにくいと思った製品であっても、使い込んでいくうちに慣れてしまい、最初の頃に感じた使い勝手は忘れてしまったという経験、ありませんか？

これはプロトタイプ作成においても言えることであり、ずっと同じ画面を見続けていると、だんだんそれに慣れてしまいます。もちろん、本人はいいものを作ることを念頭において改良を続けているのですが、知らず知らずのうちに慣れが入ってくるため、全く初めて使うユーザーの気持ちから離れてしまうことがあるのです。
一緒に開発しているエンジニアも同様ですので、開発前にユーザーに使ってもらい、操作性や機能性について意見を求めることが重要です。

このフィードバックをもとに、プロトタイプをブラッシュアップさせ最終的なシステムの機能に改善点を取り入れることで、より優れたシステムを構築することができます。

実際の例では、デザイン上かっこよさを追及することでシンプルになり過ぎて、どこをクリックしていいのかユーザーは分からないということが判明し、ボタンのサイズや色合いを変更するというデザインを調整した結果、ユーザー満足度が大幅に向上したということがありました。発注者は、ユーザーフィードバックを軽視せず、積極的に取り入れる姿勢が求められます。

システムの利用現場の協力と理解を得る

前項で、ユーザーのフィードバックを得ることについて説明しました。これはBtoCのシステム、主にWEBサイトやスマホアプリの場合と、業務システムとの場合では、少し事情が変わります。

業務システムとして社内のユーザーが使う場合、実際に利用する現場の協力と理解が欠かせません。

業務システムで、現場のユーザーが発注者側のプロジェクトメンバーに入っていることはありますが、ほとんどの場合現場業務と兼務であり、多忙な方が多いのではないでしょうか。特に、現場で中心的役割となっている人は業務に精通していることもあり、プロジェクトメンバーに組み込まれるのですが、何せ忙しい。未来のシステムよりは、いまの業務を優先させてしまうのも仕方がないと思われがちです。

そうなると、プロトタイプに対する評価もおざなりになってしまい、プロトタイプでOKをもらったのに、実際に完成したシステムはNGということが起こってしまうのです。結果、最悪の事態として、使えないシステムができあがり修正するための費用と期間が大幅に超過するということにつながります。

そのような最悪の事態に陥ることをなくすためには、ユーザーに対して、プロトタイピングの目的をしっかりと説明し、理解を得て、質の良いフィードバックを得られるよう協力を求めましょう。これは、かなり重要なことです。

リアルな話としては、ユーザーはプロトタイピングの評価に真剣に向き合ってくれたとしても、「実際に使ってみないと、よく分からない」という本音もあります。

ここでいうところの「実際に使ってみないと」というのは、業務で本物のデータで動かさないとということなのですが、それだとシステムの完成を待たなければできません。

開発者としては、「プロトタイプを使って、実際の業務を想像しつつ、意見をください」、心の中では「当然できるよね？」と考えてしまうのですが、やっぱり実業務でないとピンと来ないということは必ずあるので、100％の完成度は難しいとしても、最低限、主要な業務の流れを想像し「これなら使える、便利になる」と思えるようなレベルに仕上げられるフィードバックが欲しいところです。

リソースとコストを管理する

プロトタイピングには当然ながらリソースやコストが必要です。発注者は、プロトタイプの開発にどれだけの期間、そして予算を割くかを慎重に判断する必要があります。プロトタイプが完璧でなくても、最終的にそれが本番システムに反映されるかどうかを考慮し、無駄を避けるようにすることが重要です。

社内システムで現場担当者の協力を得たいという場合、関係部署との調整も必要となりますし、現場業務と業務のバランスにも気を使わなければなりません。時には、経営判断も必要となることすらあります。

いかなるプロジェクトもリソースとコストは有限です。必要なリソースの確保、コスト管理はしっかりと行いましょう。

期待値のコントロールが大切

プロトタイプはユーザーからのフィードバックを引き出すため、できる限り本物に近いものに仕上げたいという思いもあります。しかしその一方で、あくまで試作品であり、最終製品ではありませんから、何から何まで同じというわけにもいきません。

真剣に評価をすることはもちろんながら、ユーザーの期待値がプロトタイプとしての限界を超えないように、随時説明を添えてコントロールしてください。

実際の事例から考えるプロトタイプの重要性

ある日、日経新聞電子版を見ていたときに「東急電鉄のQ SKIP、クレカタッチ乗車なぜ休止？」という記事を読みました。記事の一部を引用するとこう書かれています。

実はこの記事を読む前はQ SKIPサービスを知らなかったので、改めてサービス内容を調べてみました。

Q SKIPサービスでは、例えば東急全線が乗り放題のワンデーパスを購入・利用することができます。購入したワンデーパスを使って、スマホのQRコード、あるいは登録したクレジットカードのクレカタッチで乗車することができるようになります。

利用方法はとても簡単で、クレカタッチでの手順はこのように行います。

1. Q SKIPへ会員登録
2. ログイン
3. クレジットカード登録
4. チケット購入
5. 使用開始ボタンをタップ
6. クレカタッチで使うをタップ

①～③は会員登録ステップですから、利用手順は実質④⑤⑥の3つのみです。
しかし、このわずか3ステップにクレジットカードのタッチ機能による乗車を停止した理由が潜んでいたのです。

本来、クレカタッチを行う際にサイト上で「使用開始ボタン」をタップしなければならないにも関わらず、ボタンをタップする操作を忘れる事例が複数発生したそうです。

では、「使用開始ボタン」をタップせずにクレカタッチを行うとどうなるかというと、東急電鉄はクレジットカードのタッチ機能を使用した後払い型サービスを24年5月に開始しており、使用開始ボタンを押さずにクレカタッチで乗車すると、普通旅客運賃の後払いとして精算されることになったのだということです。

ここで考えて頂きたいのはたった1つの操作、それも、ただタップするだけ。ユーザーはこのシンプルな操作すらも、忘れてしまうことがあるということです。

恐らく開発の際にも入念に検討されているでしょうが、完璧にするということが難しいのがシステムの世界。開発の際は、これらの操作の流れは難しいこととはとらえず、かつ、もしどれかの手順が漏れたときに何が起こるのかということに気が付かなかったのでしょう。

発注者を含め、作る側の考えと使う側の考えには相違があるということ。場合によっては、このようにサービスの停止にまで至ることすらある。そんな事例でした。

プロトタイピングによってこのような問題が全て解決するとは言いませんが、多くのユーザーフィードバックを得ることができれば、開発前に気が付く可能性は高まることと思います。

プロトタイピングツールは必須

今やプロトタイピングツールを使わずにExcelやWordなどで画面イメージを作り、それをプロトタイプと言うことはないとは思うのですが、WEBサイトやアプリの構築経験がないというITベンダーもいないわけではありませんので、そのようなITベンダーの場合、もしかすると紙に印刷してきた画面イメージで、UIの要件を固めようとする場合もあるかもしれません。

万が一、印刷物でUIに対する打合せがはじまってしまったなら、発注者・開発者の認識のずれを減らすためにも「プロトタイピングツールで作ってほしい」と要望を出してください。これは、互いのコミュニケーションを円滑にする手段ともなりますので、結果的には互いのためになるものです。

ちなみに当社では、WEB系システムではAdobe XD、スマホアプリではProttなどを使っています。「プロトタイピングツール」と検索すると色々出てきますし、少し慣れれば発注者側でも作成できるものですので、覚えておいて損はありません。

まとめ

今回は、プロトタイピングを活用する際の重要なポイントについて解説しました。特にプロトタイピングの目的を明確にし、範囲をしっかりと定義すること、そしてユーザーからのフィードバックを早期に得て、システムに反映させることの重要性を強調しました。

また、システムの利用現場からの協力と理解を得ること、リソースやコストの管理、そしてユーザーの期待値をコントロールすることが、プロトタイピングを成功させるためには欠かせません。プロトタイプはあくまで試作品であり、最終システムの完成に向けて調整するためのツールです。無理のない計画と適切なコミュニケーションを通じて、より良いシステム開発を進めていきましょう。