はじめに

今回は設計における発注側のポイントを説明していきますが、その説明のまえに、アプリ規模の大小による、プロジェクト進行の違いについて解説します。

規模の大きいアプリ開発では、要件定義といった、企画を更に整理、検討したフェーズやドキュメント（要件定義書）を作成することもあります。これは発注側の責任で作成するものですが、アプリ開発会社（ITベンダー）のサポートを受けたりもします。

本連載では比較的規模の小さいアプリを念頭にしているため、要件定義作成については割愛します。

また、規模とは直接的に関係しませんが、アジャイル方式の場合は、設計書より動くアプリを重視していくため、企画書や設計書も粗いメモ書き程度で済ませることもあります。

２．設計

設計フェイズでは、アプリの画面の大まかなデザインやボタンの配置などのレイアウト、画面の遷移やどういったデータを取り扱うか、そういたアプリの動きを実際に決めていきます。

このフェイズのアウトプットは、設計書（＝仕様書）となります。

設計書について説明すると、まず、仕様書は大きく２種類あります。１つはアプリの画面やボタンを押したときの動きなど、アプリの外側から見える部分に着目して作成する、基本設計書（外部設計書）と、

アプリの内部のプログラムの動きなどを記載する、詳細設計書（内部設計書）に分けられます。

多くの場合、基本設計書はユーザー（発注者）と、アプリ開発会社（ITベンダー）が一緒に作成します。

詳細設計書は技術的な内容が中心ですので、アプリ開発会社（ITベンダー）が主導して作成します。

規模の小さいアプリでは、特に詳細設計書は作成しないことが多いです。（要件定義書や、基本設計書をもとに、すぐコーディングを行う）

ここでは、基本設計書（外部設計書）を中心に見ていきましょう。

基本設計で明らかにすべきなのは、以下です。

- （１）画面の大まかなデザイン、ボタンなどのレイアウト
- （２）画面の遷移
- （３）取り扱うデータの決定
- （４）Facebookなどの連携するサービス

設計が終わった段階では、頭の中にはどんなアプリかイメージできるレベルを目指してください。

「このボタンをタッチしたら、この画面に移動する」とか、「このキャラクターをタッチしたら、○○なアニメーションをする。そして、こういう効果音が流れる」みたいな感じですね。

また、モックアップと呼ばれる試作品を作成する場合もあります。モックアップは、紙や画用紙を切り抜きしてつくるものから、 PowerPointなどのツールを使用して作成したりします。

モックアップはあくまでイメージの確認やすりあわせの道具なので、あまり、その作成に作業時間をとられないようにしてください。

※　ときおり、モックアップの作成に一生懸命になってしまうケースがありますね。

ここで作成する設計書は大きく３つの役割があると考えて下さい。

- （１）開発者、デザイナーに仕様を伝える
- （２）設計書を作成する段階で論点を抽出する（考慮漏れを防ぐ）

当たり前ではありますが、設計書には（１）開発者、デザイナーに仕様を伝えるというメッセージの役割があります。設計書をもとに、実際にアプリのプログラミングであったり、画像の作成をデザイナーは行います。そういった人が、読む文章ですから、できるだけ、わかりやすく、初めて見た人でも内容がスッと理解できるような文章を心がけてください。

独りよがりな文章、いちいち確認作業が発生してしまう文章では、せっかくの設計書を作成する意味がありません。

そして、（２）設計書を作成する段階で論点を抽出する（考慮漏れを防ぐ）。これは、非常に重要です。

設計書を書きながら、「こういう場合って、どうするんだっけ。この件はまだ想定してなかったな」みたいな、疑問がわくと思います。こういった疑問が大切で、こういった疑問を一つ一つをしっかりと、チームで摺り合わせることで、設計書のクオリティ、強いてはアプリのクオリティが上がっていきます。後から気づくと、時間やお金の問題でもう対応不可みたいことが起こりえます。