「モックアップ」の重要性と注意点 第02回 20年06月 / 最終更新：2020.06.02
目次
Webアプリケーションを作るうえで「実際にどんな画面遷移になるか？ 画面はどんなデザインになって、各画面にはどんな要素があるのか？」の確認は、手法がなんであれ「確認自体は必須」になると思います。
そういった時に、一つには「(主にExcel等で)画面遷移図を作成する」というのがあるのですが。
画面遷移図は、サイトの規模によっては割と大きくなる事もあります(筆者は、最大で「A2」サイズ相当の画面遷移図を拝見した事があります)。
「一目で全体を把握する」には適しているかもしれないのですが、「個々の遷移を見る」等には、些か厳しい側面も少なからずあります。
そういった時に「ブラウザで実際の遷移を(ある程度)確認できるモックアップ」を作る、というのは、比較的あちこちの現場で拝見をするのですが。
一方で「とても便利」なモックアップも、もう一方で「少し注意点」もあるため、「便利なポイント」「注意点」を、少し確認していきたいと思います。
モックアップという言葉ですが、本来は「原寸模型」「実物大模型」といった意味合いのようです。場所によっては「木型」といった書かれ方をされている事もあります。
端的には「実際には動くわけではないが、実物と同じくらいのサイズで同じような形をしているもの」で、その用途は「デザインや使い勝手の検討が出来る」、また「比較的ローコストで修正が可能」という特徴を持つもの、になります。
そのため、Webアプリケーションによるモックアップも、基本的には上述を踏襲している事が多いように思われます。
ここで「モックアップで何を確認したいのか」を明確にしておくとモックアップの方向性が右往左往せずにすむため、モックアップで「なにをしたいのか」の切り口をいくつか書いていきたいと思います。
これが全てではありませんが、この辺を足がかりに「今回の開発における、今の時点での"モックアップ"は、何を期待してるのか？」を明確にしていくとよいと思います。
・全体の画面遷移のイメージ
ブラウザでとりあえず「ユーザや管理者になった気持ちで」「一通りの操作をしてみて、使い勝手を確認する / 確認してもらう」のは、とても重要になります。
初めのモックアップで、実際にブラウザ経由でサイトを動かしてみたら「あれ？ この機能はどこにあるの？」「このデータはどこから登録するの？」など、案外と見つかるものです。
この目的の場合、最低限「clickしたら次のPageに遷移出来る」事が必須になります。これは多くのモックアップで「必須」な項目だと思います。
なお、最近ですと「使い勝手」という意味で「JavaScript」が絡んでくる事も多く、そこをしっかりと組むと「JavaScript側は実際の納品物に近いレベルのコード」が必要になってしまう事もあり得ます。
その辺りは「修正がそれなりに入る事を想定して、ある程度の制限を付けておく」などして実装を加減しておくと、モックアップの「比較的ローコストで修正」という特徴を殺さずに済むかと思います。一方で「そこはこのタイミングである程度しっかりと組み上げてしまう」のもまた、方向性の一つだと思います。
・画面デザイン
こちらも大切で、勿論デザインは「一端、サンプルページ」である程度調整をする必要があるのですが、細かいところで「この部分はこうして欲しい」といったお話が出る事も少なくないため、モックアップ時にその辺りを一通りつめておくと、開発の時に「システムの開発とデザインの修正が同時に走る」事が少なくなり、状況によっては「面倒な手戻り」が減る可能性があります。
この項目は「必須」ではないのですが、もしデザインをするのであれば「しっかりと」、デザインをここでfixしないのであれば「デザインがまったく当たっていない(ノンデザインの)」と、その辺りははっきりさせておくとよいと思います。
なお、注意点が一つ。システム開発になれていない顧客で、稀に「デザインが終わった == システム開発が終わった」と思われてしまうケースがあるため、その辺りはしっかりと調整をしておきましょう。
デザインをしっかりと調整する場合、CSSは「しっかり組む必要がある」のと、JavaScriptについても「ある程度、組み上げる必要がある」ので、モックアップの作成時間は比較的増大します。
・各画面の画面項目や技術的見地の確認
「全体の画面遷移のイメージ」も大切ですが、一方で「1画面の、画面項目の確認」も重要になります。
一つには「こんな情報が欲しい」という類いの情報で、これは割と「出力画面で"この項目も出したい"と言われた → 入力箇所がないので、入力画面でその入力項目を増やすようにした」といった流れが多いか、と思います。
勿論、一方では「1カラム、データを増やす程度の修正に"多大なコストがかかる"ような設計や実装をしない」という点は重要なのですが、とはいえ「塵も積もれば山となる」ので、確認可能な範囲での抜け漏れは、早めに潰しておきたい所です。
「こんな情報が欲しい」でもう一つあるのが「それは技術的に可能なのか？」という見地があります。
例えば、会員へのmail送信などの画面で比較的出てくるのが「mailの到達率/開封率」というお話で、これは「SMTPというプロトコルから、本来的に計測が出来ない」が前提にあって「ある程度の近似値を取るやり方が無くも無いが色々と制約や問題がある(ので実質、あまり使い物にならない事が多い)」といった技術的背景があります。
そういった技術考察無しで「モックアップで"mailの到達率/開封率"という項目をのせたままOKが出て開発に進んだ」場合、開発の時点で「これをどうするのか？」という辺りで議論になり、色々と調整や面倒が起きてきます。
例えば、これを「mailのエラー率」としておけば、(まぁ勿論"エラーメールが到達しなかった可能性"もあるので100%確実ではないにしても)まだしも「技術的に実現が可能」になります、ので、これを「モックアップのタイミングで」適切に調整できれば、開発時のトラブルが減ります。
このように、「技術的見地からの実現可能性」をモックアップのタイミングで適切に考察しておくことは、とても重要になります。
「画面の要素をはっきりさせないままのモックアップ」もありますが、どこかで「画面要素を明確にする」必要があるので、もしモックアップでそれをやらない場合は「どこで"画面要素の確定"をするか？」を明確に決めておく必要があるでしょう。
モックアップは、お客様との打ち合わせなどでも有用なため、昨今拝見している限り、筆者の周囲では「よく使われている方法」かと思います。
ただ、一方でいくつか注意点もあるので、そのあたりを気をつけておくと、開発の「その次以降のフェーズ」での面倒を減らせるので、ポイントを抑えて便利に使っていきたいものです。
サービス・ソリューション
