アプリケーション設計の基本について
アプリケーション設計の基本要素
アプリケーション設計の仕事は、システムエンジニア(SE)が担当し、作成した設計書はプログラマーに渡り、それを参考にプログラムが作られます。
設計の要素は以下の通りです。1〜8は「基本設計(外部設計)」で、ユーザー目線でのアプリ設計が進められます。
9〜12は「詳細設計(内部設計)」で、開発者目線でアプリ設計が進められます。
1.要件定義
要件定義は、クライアントからの要求を聞き、必要な機能やリソース、開発期間などの要件をまとめる工程です。
クライアントがアプリケーションで実現したい事をハッキリさせることは、設計の根幹を決定づける大切な事です。
この後に続く設計の基本にもなりますので、実現すべき要求を正確に表し、クライアントと合意する事が絶対です。
2.大枠設計
アプリケーションの大枠を設計します。
アプリケーションの利用目的(ECサイトをアプリ化する事で、より集客力を高めたい)や利用環境(iOSは11以上/13以下、Androidは5.0以上/10以下)、実際の使用場面での業務フロー(利用者がメールアドレスやパスワードを入力する、商品を選んで購入に進む等、そしてその為の構成)を交えて進めます。
あまり詳細に決めず、ラフでも良いので輪郭を作る程のニュアンスです。
3.インフラ部分の設計
アプリケーションの開発や稼働に用いるインフラ(ネットワーク及び機器構成などの部分)を設計します。
4.画面設計
ユーザーがPCやスマートフォンで目にする画面の配置や機能、デザインを設計します。
ユーザーが直感的に操作出来るように、見やすく使いやすい配置や機能を採用する事がセオリーです。
デザインは、デザイナーに依頼する場合もあり、UX(ユーザーエクスペリエンス)という考え方から、デザインの重要性は大きなモノになっています。
何故なら、画面のレイアウトやデザインは、UI(ユーザーインターフェイス)となり、アプリの利用率やリピーターの増加に繋がる為です。
5.データベース設計
この設計は「概念設計」、「論理設計」、「物理設計」の3つに分かれます。
概念設計は、データベースを必要とする業務に欠かせないデータを定義します。
論理設計は、データベースを構成するテーブルやフィールドの設計を行います。
物理設計は、それに必要なハードウェアを設計します。
6.インターフェイス設計
インターフェイスとはアプリケーション内部と外部を繋げる橋のようなモノで、主に外部アプリケーションとの連携を担います。
その為の設計の他、ユーザーが入出力するデータや帳票も設計します。
7.運用設計
アプリケーションが、平常業務や障害対応を問題なく行えるようにルールやプロセスを設計します。
3W1H(When、Who、What、How)の観点で行われ、「いつ運用設計するのか、誰が行うか、
設計すべき項目は、どのような体制で行うか」とプロセスを確立するのがポイントです。
アプリケーション稼働中に障害が発生した際、復旧プロセスが定義されていれば迅速な対応が出来るほか、開発会社が運用・保守にあたる場合にも、それは必用不可欠です。
8.テスト設計
開発中のアプリケーションをどのような方法でテストするか、使うテストツールは、といった事を設計します。
会社やプロジェクトによって色々ありますが、テストの対象範囲や目的などを計画した後、実施手順やテストで使用するデータ内容のパターン等を検討します。
品質の向上には効果的なテストが必要なので、適切な選択が重要になります。
9.開発環境設計
アプリケーション開発を、どの技術で進めていくか設計します。
導入するサーバやデータベース、開発に使用するプログラミング言語やフレームワーク等を明確にし、開発環境を統一することが重要です。
(例).AndroidのアプリならAndroid Studio環境で使用する言語はJava、iPhoneのアプリならXcode環境で使用する言語はSwift等。
10.機能分割設計
基本設計で洗い出したアプリケーションの必要機能の違いを明確にする工程です。
それぞれの機能を分割し、完全に独立するまで繰り返します。
11.モジュール設計
機能分割設計で分けた機能を、処理手順やワークフローに沿って識別します。
これにより、開発の時に重要度の高いプログラムを優先して構築する事が出来ます。
12.内部データ設計
データの入出力フローや分割したモジュールの整理と確認、モジュール間でのデータ受け渡しについて設計します。
(例).ログイン処理時、ユーザーIDとパスワードがデータベースに登録されたモノと一致するか。一致した場合にホーム画面に移るか、一致しない場合にエラー表示が出るか等。
アプリ設計を行う意味
アプリ開発の工程で設計を行う事は、担当以外の人が見ても理解する手助けとなります。
成果物の設計書が作成される事で、アプリの仕様や機能が一覧出来るので、プログラマーの方が円滑に作業を行える他、聞き間違いや誤解によるミスを防ぐ事が出来ます。
また、アプリの内容を修正する事になった場合、それに準じた設計書があれば、誤って入力するリスクを減らす事にもなります。
設計作業のアンチパターン
以上、設計全体の要素について紹介しましたが、アプリケーション設計には、やってはいけない「アンチパターン」というものがあります。
それを犯してしまうと、アプリケーション開発がスムーズに進まないばかりか、失敗に終わる可能性もあります。
ここでは、それについて紹介します。
●設計と開発の並行作業
一見効率が良いように思えますが、設計が決まっていない状態で開発を進めると、改修が起きた時の工程数が大きくなり、結果的に膨大な手間と時間をかけることになります。
このことから、設計が完了してから開発を行うのがベストです。
●開発予算を度外視する
エンジニアが設計したものは、プログラマーが全て行える範囲で引き渡さなければなりません。
欲ばって機能を付けすぎてしまうと、プログラマーにも過度な負担をかけるばかりか、予算を大幅に超えることとなり、結果として、本当に必要な機能を付けることが出来なくなります。
●他人が読めない設計書を作る
設計現場でよくあるトラブルが「属人化」です。これは担当した設計者にしか理解出来ない若しくは理解が難解になる現象です。
開発のフェイズや納品後の運用・保守の観点からも、SEは誰にでも理解出来る可読性の高い設計書を作る事が求められます。
●主観だけで作る
設計書を作成するのはエンジニアですが、それを読むのはプログラマーです。そして、その設計書を基に作られたアプリケーションを使用するのはクライアントです。
先ほどでも述べたように、エンジニアは客観的に設計書を作成する必要があります。
プログラマーやクライアントの事を考えずに作られた設計書は、もはや無意味なドキュメントに成り下がります。
●表記ゆれがある
例えば、「です、ます調」や「である、だ調」が統一されていないだけでも、可読性は著しく下がります。
他にも、同じことを別な表現方法で記してしまうと、スムーズな理解の障害となります。
用語集を用意して、それに沿って記述することが、統一された表現となり、読み手の理解を助けます。
まとめ
クライアントが希望するアプリケーションが開発されることで、業務上の課題を解決したり、新しいビジネスが創造されます。設計の工程は、その為の図面作りです。
設計のクオリティ次第で、出来上がる設計書のクオリティにも関わっていきます。
そして、出来上がった設計書を基に開発作業が行われることから、設計という工程がいかに重要なポジションを占めているかが分かります。