設計とは「小さな決断の連続」です。アプリケーション開発にあたって最終的に出来上がる機能の集合体であるアプリケーションを、それを構成する要素に分解し、それぞれどんな機能を持たせるか？どんな技術で実現するか？どんなデザインにするか？などを状況に応じて一つ一つ決断していき、最終的にアプリケーション全体の設計を行うのです。そのため、設計はアプリケーション開発の起点であり、その出来栄えを左右する重要なものになります。
今回はアプリケーション設計について理解していただくために、設計要素を整理していきます。どんな設計要素があって何を設計するのか。これを整理するだけでもアプリケーション開発における設計への理解度はグッと深まるでしょう。
基本設計(外部設計)
基本設計はアプリケーション開発において基礎となる部分を作ることです。クライアントから聞き出した要求をもとに、ユーザー視点でアプリケーション全体を設計していきます。
要件定義
間接的に設計と関係がある大切なポイントなので記述しておきます。要件定義とはクライアントから引き出した要求をもとに、「こうした機能が必要だ、リソースはこれだけ必要だ、開発期間はこのくらいだ」といった要件をまとめたものです。つまり要件定義にはクライアントがアプリケーションによって何を実現したいのかが明確になっていないといけません。このあとの設計は要件定義の内容を基本として進めていくため、この段階で実現するべき要求を明確にし、クライアントと合意することが大切です。
全体設計
アプリケーションの全体像を設計します。アプリケーションの利用目的や利用環境、実際の使用場面での業務フローを交えつつ、アプリケーションのあり方を明確にすることが大切です。
システム設計
アプリケーション開発や稼働に必要なインフラ、ネットワークおよび機器構成などのアプリケーションのインフラにあたる部分を設計します。最近ではクラウド上でアプリケーションを開発および稼働することが多くなっているので、クラウド設計に対するスキルも欠かせません。
画面設計
ユーザーが実際にPCやスマホで使用する操作画面のレイアウトやデザイン、あるいは機能を設計します。ユーザーが最も触れる部分なので、見やすく、使いやすいデザインや機能を採用することが重要です。デザイン性を重視したアプリケーションの場合、デザイナーに設計を依頼することもあります。また最近では、UX（ユーザーエクスペリエンス）という考え方が重要になってきており、デザインの重要性が増してきています。
データベース設計
データベース設計は概念設計と論理設計および物理設計に分けて考えます。概念設計ではデータベースを必要とする業務を遂行するために欠かせないデータを定義し、論理設計ではデータベースを構成するテーブルやフィールドの設計を行い、物理設計ではそれに必要なハードウェア資源を設計します。
インターフェース設計
インターフェースとはアプリケーション内部と外部をつなぐ結合子のようなもので、主に外部アプリケーションとの連携を設計する項目です。その他ユーザーが入出力するデータや帳票についても設計します。
運用設計
アプリケーションが安定稼働するための日常業務や、障害対応がスムーズに行われるようにルールやプロセスを設計することです。たとえばアプリケーション稼働中に何らかの障害が発生した場合、あらかじめ復旧プロセスが定義されていれば対応の迅速性がアップします。またバックアップやバージョンアップなど継続的な運用は必要です。運用設計は開発会社が運用保守にあたる場合でも必要不可欠です。
テスト設計
開発中のアプリケーションをどういった方法でテストするか、どんなテストツールを使用するかを設計します。アプリケーション品質を向上するためにはテストが欠かせませんが、同時に時間がかかります。テストを適切かつ効果的に実行し、高品質なアプリケーションをすばやく納品するために事前に設計しておきます。
詳細設計(内部設計)
次の詳細設計について解説します。ユーザー視点で見た設計が基本設計なら、詳細設計は開発者視点で見た設計です。
開発環境設計
アプリケーション開発をどの技術で進めていくかを設計します。導入するサーバーやデータベース、開発に使用するプログラミング言語やフレームワークなどを明確にし、開発環境を統一することが大切です。
機能分割設計
基本設計にて洗い出したアプリケーションに必要な機能のそれぞれの違いを明示します。さらに各機能が完全独立するまで分割を繰り返し、プログラムの最小単位を作ります。こうすることで小さい単位でプログラム作成が行え、効率的にアプリケーションを開発できます。
モジュール設計
機能分割設計によって細かい要素に分けた機能を、処理手順やワークフローに沿って一覧します。これによって重要度の高いプログラムなどが判明するため、アプリケーション開発の優先順位やプロセスを組み立てられます。
内部データ設計
データの入出力のフロー、分割したモジュールの整理と結合度の確認、さらにモジュール間でのデータの受け渡しについて設計します。内部データ設計まで来ると基本設計からかなりドリルダウンされた設計書が完成します。
以上が設計全体の要素です。ただし組織やプロジェクトに呼び方が違っていたり、プロセスが異なる場合もあるので、その都度それぞれの定義や範囲を確認することも重要です。
設計のやってはいけない5個のポイント
アプリケーション開発の現場では「アンチパターン」といって、全体にやってはいけないポイントがあります。このポイントを無視してしまうと、アプリケーション開発は往々にして失敗に終わるでしょう。ここではそのポイントをご紹介します。
ポイント①設計と開発の並行作業
納期があまりに短く設定されているとやってしまいがちなのが、設計と開発を平行して進めることです。一見効率が良いように見えますが、全体の設計が定まっていない状態では改修が起きたときの手戻りが大きくなり、結果として膨大な工数を無駄にしてしまいます。
ポイント②開発予算を度外視
エンジニアが設計したものはすべて実現できる状態でプログラマーに引き渡さなければなりません。あれもこれもと欲張ってしまい、開発予算を度外視した設計では結果的にすべての要件を満たすことができなくなります。
ポイント③人が読めない設計書を作る
設計現場でよくある課題が「属人化」です。つまり設計者（自分）しかそのドキュメントを理解できなかったり、あるいは理解に時間がかかるという状態です。アプリケーション開発においても納品後の運用保守を考慮しても、可読性の高い設計書を作ることが大切でしょう。
ポイント④主観だけで作る
設計書を作成するのはエンジニアでも、それを読むのはプログラマーでありアプリケーションを使用するのはクライアントです。そのためエンジニアは常に客観的視点を持って設計書を作成する必要があります。プログラマーやクライアントの立場に立っていない設計書には価値がありません。
ポイント⑤表記ゆれがある
エンジニアは常に読み手を考えて設計書を作成しなければなりません。その点から考えれば表記ゆれは排除すべきものです。たとえば「です、ます調」なのか「である、だ調」なのかといった言語レベルの表記ゆれは可読性を損ないます。また同じことを別の表現で表現してしまうと正しい理解の妨げになります。用語集などを作って、かならずそれに沿って表現するようにします。
設計とその成果物がプロジェクトの成否を左右する意識を持とう
以上がアプリケーションの設計の内容とポイントです。そして重要なのは、設計の結果はすべて設計書という成果物として保存されるということです。つまり設計の品質は設計書の品質に依存するということです。そのためには、成果物を標準化するためのツールを導入することもおすすめします。
