「はじめよう！システム設計」を読んで、システム設計について考えてみた
下記記事の続き的な記事であり、もっとメモ寄りの記事。
「はじめよう！要件定義」を読んで、要件定義はじめてみた
システム設計ってなに
要件定義とは、「何を作るかの情報を揃える仕事」でした。
システム設計は、その要件をもとに、「下記層において、各機能のうち何をどこでどのように実現するかの情報を揃えて、開発担当者がスムーズに開発を進められるようにする仕事」といえます。
フロント層
バック層
DB層
要件そのものをもとに、開発担当者（プログラマー）同士の齟齬や要件との齟齬なく開発を進められる場合はシステム設計は不要そうですが、まずそんな場面に遭遇したことはありません。。。。
補足
※ 本の中では、「要件をアーキテクチャにマッピングするのがシステム設計」という表現がされていますが、要件定義の成果物のうちUIはフロント層、データはDB層ほぼ確定なので、考えるのは主に機能のマッピング/役割分担になりそうです。
また、著者の書いている「要件定義」では、（特にフロント層において）いわゆる「基本設計」の一部まで終わっているのでは。。？という印象を受けているので、ここで触れるのは「詳細設計」に近い部分にはなりそうです。
アーキテクチャ
【英】architecture
アーキテクチャとは、情報システムの設計方法、設計思想、およびその設計思想に基づいて構築されたシステムの構造などのことである。
フロント層
大前提として、フロント＝UI（ユーザーインターフェース）の決めは要件定義の一部であるべきという著者に同意です。
その上で、ラフイメージを材料に、細かいレイアウトやモジュールの動きを設計していきます。
UI設計
（要件定義.UIとけっこう重複）
ユーザーの行動シナリオを1つピックアップし、下記順で試行錯誤しながら最適（＝ユーザーが達成したいことを快適に達成できる）なUIを探っていきます。
1. 項目配置：エイリアス/シノニム/ホモニムを潰しながら、近接と整列(※後述)を意識
2. 画面分割：視認性や操作性によっては検討
3. 画面遷移
4. 操作手順：使い勝手を俯瞰的に確認
→また1.から
※重要 ここで変更が発生した場合、要件フェーズの資料にも反映する！
レイアウトデザイン
UIが固まったら（or同時進行でも）、「ノンデザイナーズ・デザインブック」という書籍から紹介されている4つの基本原則を組み合わせて、レイアウトの調整をします。
近接(Proximity)：関連する項目を近くに集めてグルーピングする
整列(Alignment)：見えない直線に各要素を沿わせる（≒グリッドデザイン）
反復(Repetition)：繰り返し要素のリスト化
コントラスト(Contrast)：視覚上の刺激を高め、重要度に差をつけたり強調したりする
機能設計
（要件定義.機能とけっこう重複）
入力をもとに出力を行うのが機能、「機能 = Function = 関数」です。
これを詳細化（＝モジュール化）して、担当の層を決めていきます。
例（要件定義で作成した機能）
青枠部分の処理がもっと詳細化できる＝青枠部分をモジュール化して呼び出すことになります。
末端の処理まで書けているかを意識して詳細化していき、必要に応じて、バック層への依頼→DB層への依頼、と割り振りしていきます。
感想
まず、前記事でも少し触れたのですが、工程の区分けって難しく、この本の中でも要件定義部分と重複して書かれているところも多かったのでまとめるのが難しかったですが、差分抽出するとこういうことかな？という認識に落ち着きました。
（あとは本には書かれてないのですがDBの物理設計も必要そうですね）
実際には要件定義に書かれている成果物のうち多分に漏れている部分を含めて設計フェーズで定義していることが多そうですね。
細かいところまで含め、このアーキテクチャで要件がほんとうに実現できる、という確実性を早い段階で高めることで手戻りを減らすことが、システム設計までのフェーズで求められる部分になるのかな～と思いました。
システム
【英】system
システムとは、複数の要素が体系的に構成され、相互に影響しながら、全体として一定の機能を果たす何物かのことである。
参考文献
羽生章洋 （2018）. はじめよう！システム設計 ～要件定義のその後に 技術評論社
Discussion