こんにちは！ コワーキングスペース松原ガレッジスタッフの櫂谷です！ 大阪府松原市でウェブを中心としたソフトウェア開発を行っています。
当事業で課題図書として「はじめよう! システム設計 ~要件定義のその後に」を、生産性保守性の高いプロダクトを作るための知見を得れるよう意識して読みました。
- 作者:羽生 章洋
- 発売日: 2018/01/25
- メディア: 単行本（ソフトカバー）
本書の対象者
システム開発において必要な知識・スキルの3点セット(UI・機能・DB)が偏りがちで、得意でない領域は基本的なことであっても不安がある人。
概要
昨今のシステム開発では、デザイナー、プログラマーそれぞれが別の領域の業務を担当することが多いため、全員が知識共有ができる必要があります。
別の領域の基本的なことをお互いにあまり知らないために意思疎通ができない、ということを無くすべく、全員が横断的に知識を共有するできるようにするための本です。
要件定義という仕事
UI、機能、データ を要件としてまとめる為に下記を定めることを「要件定義」といいます。
- このITシステムを作ることによってどんなふうになることを期待しているのか
- このITシステムはどのようなものか
- このITシステムは具体的にはどういう要素（UI、機能、データ）で構成されるのか
要件定義の成果物
クライアントと要件を挙げながら、合意する成果物を作成します。
- 企画書
- 全体図
- ソフトウェアアーキテクチャ
- シナリオ一覧
- ビジネスシナリオ
- アクションシナリオ
- 操作シナリオ
- ワークセット一覧
- UIラフスケッチ
- IFDAM図 （拡張画面遷移図）
- 機能定義書
- ERD ( Entity Relationship Diagram )
この成果物を元にシステム設計を行います。
まずはフロント層から
フロント層だけでユーザの期待に答えられるのであれば、他のバック層・DB層は必要ありません。フロント層だけでは力不足のときに後ろから支えてあげるのがバック層ということになります。
- フロント層の役割とは「ユーザの期待に応えること」
- バック層の役割とは「フロント層の期待に応えること」
- DB層の役割は「バック層の期待に応えること」
フロントが果たすべき要件はユーザの期待、システムに対する要件から決まりますので、最初はフロント層から設計を行います。
UI設計の手順
- 項目をUI上に配置する
- UIの分割を検討する
- 分割に伴う遷移と画面間の機能について検討する
- 画面遷移の変更に伴う操作手順の再確認と操作性の検討を行う
上記の工程をループさせて試行錯誤し、下記に作業を行います。
- ビジュアルデザインを施す(UIデザイナーとの協業)
- 後工程のためにIFDAM図に修正をフィードバックする
このとき「ユーザはこのUIを使うことによって、何を達成したいのか」を忘れないということを意識すべきです。 UIの役目は「ユーザの期待にシステムが応える」ために「システムの代表としてユーザに向き合う」ことです。
行動別にUIを用意する
複数の機能を1つのUIに盛り込むと、ごちゃごちゃとしてしまい、ユーザが混乱します。 それぞれの行動別にUIを用意しましょう。誤解のしようが無い明快なUIを提供できます。
機能を設計する
「機能を設計する＝コンピュータの行う仕事を定める」＝「プロセス設計」
プロセス設計、仕事を設計する要点は、大きく分けて下記の2つです
- ゴールから逆算して必要なことを考えること
- 段階的に詳細化すること
この2つは言い換えると「モジュール化を行う」ということで、部品化するということです。
モジュールのインターフェースを定義し、加えてそのモジュールを小分けにして個別の部品にしていき、それを受け持つ担当の層を決めていきます。
「具体的な実現手段：実装」を小分けの対象として、「順接」「分岐」「反復」+「段階的詳細化」という手法でモジュール分割を進めていきます。
そしてこの機能のインターフェースを「機能名」「入力」「出力」の3つを決めて定義します。
バック層の存在意義
フロント層とDB層が直接やりとりすればいいのでは？という疑問もあります。
単なる社内業務の効率化だけであればそれで済みますが、「サービスがAPIで提供されている」ということによる「事業価値の最大化」が可能になります。
DB層設計の手順
- バック層がDB層に期待している機能を集める
- 機能ごとにモジュールのインターフェースを定義する
- モジュール内でひつようになるテーブルを設計する
- モジュールの実装を考える
- 全モジュールのテーブル設計を統合・調整する
共通化の罠
「大規模だから無駄なことを減らしたい」ので「共通化の推進」が行われますが、プロジェクト当初から期待通りのパフォーマンスは発揮されるケースは非常に稀で、逆にプロジェクト全体を停滞・低迷に導くこともあります。
「どんなアプリになるかハッキリしないと共通仕様が作れない」という状態と、「共通仕様がハッキリしないと手戻りが怖くてアプリ設計ができない」という状態がぶつかって、プロジェクトが止まってしまいます。
この罠に陥らない方法は、「共通化をやめる」ということで、材料が出揃うまでは共通化を後回しにすることです。 着実に成果が出る道を選びましょう。
インターフェース定義で、データ型の箇所は現在触れ始めている Typescript にも通じるものを感じて興味深かったです。
「共通化の罠」の chapter は実際に以前メンターからお聞きしていたトピックで、設計者と制作者の正義がぶつかってデッドロックになるという仕組みは納得でした。
体系的にシステム設計についての知識が盛り込まれており、中でもフロント・バック・DBの各層での具体的な設計方法などは再読して参考にしたい項目でした。
