今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。
このメルマガは設計についてのコツみたいなものを語ったものっぽいね。
読み返してみて、今でも考え方は変わっていないけど・・・コレ書いた時点では、スクラッチ開発とかパッケージ導入のプロジェクトしか想定していないんよね。昨今流行りのローコード、ノーコードになったらどうしてるんだろう？
アプリ開発から完全に遠ざかってしまったから、現状ではコレが正解かどうかは不明。
インフラ・プラットフォーム側はほぼ非機能しかないからね。Azure Data Factory みたいなインフラ？アプリ？で分けにくいようなリソースの場合はまた考えていかないといけないかもね。
まぁ、今の会社じゃ誰もできる人がいなかったから、Azure Data Factory に関してはそのへん含め全部あたくし一人でやったけど。
※以下、当時の文章。
※一部のマークダウンが何か反映されない・・・？
機能設計と言えば、設計の花形部分ですね。
画面や帳票等、業務に直接関わる、かつ、ユーザーの目に触れる部分の設計となるので、お客さんも関心が高い部分となります。（だから花形です。たぶん。）
また、一番お客さんのレビューが多くなるのもこの部分になりがちです。
では、この設計って何だろう？
どういうことをやっていけばいいんだろう？
機能設計と画面設計ってどう関連があるの？
今週は上記について簡単に解説します。
個人的には・・・機能があっての画面・帳票・バッチ・API だと思います。
最初からその逆（例：画面から機能を定義）だと、必ず要件の抜け・漏れが生じます。
※「画面から機能を定義」というのが絶対に無いわけではありません。「あ、お掃除バッチがないとストレージにファイルが永遠に溜まっていくわ」みたいに、後から気づくことも多々あります。
要件定義では、機能単位で「こういうことをやる」と定義している（はず）なので、基本設計もまずは機能単位で定義 → 細分化（画面等）をしていく方が抜け・漏れも少なくキレイだと思います。
なお、画面設計等のコツについては後の号で解説しますのでお見逃しなく！
機能設計とは
- 機能設計の意味
機能設計（function design）とは - IT用語辞典 e-Words
※ここでは、1）の意味で記載しています。
1）ソフトウェアや情報システムの開発工程の一つで、システムの機能ごとに仕様を定義する工程。
→基本設計（概要設計）または外部設計と同一、あるいはその一部とされ、要件定義書などを基にシステムに必要な機能を定義していく。
2）各機能を実現するためのシステムやプログラム、データの構成や仕様などを定義する工程。
→内部設計、または、詳細設計と同一、あるいはその一部とされ、基本設計（概要設計）や外部設計で定義された機能の一覧などを基に、各機能を実現するための具体的な構成や構造などを定義していく。
- 機能設計の位置づけ
基本設計書は要件定義書に記載されている要件を基に、要件を実現する方法を記載します。
大きく分けて以下について設計します。
※以下、私見です！
| ドキュメント種類 | 概要 | 例 |
|---|---|---|
| 基本設計書 | 機能設計 | システムで実施・実行する要件を実現 |
| 非機能設計 | システムが担保していないといけない要件を実現 |
- 機能の決め方
機能は、大きく分けて以下のように決め、または、決まります。
① 顧客より提示される（顧客によって決まるパターン）
→公共系、金融系の巨大プロジェクトでは、あらかじめ顧客側から機能一覧を提示されることが多いです。
大抵の場合、顧客側のコンサルタントが要件定義書を作成し、その際に一緒に機能一覧も出されます。
ベンダーは機能一覧を確認し、過不足が無いか、機能に対する不明点は無いかを確認します。
② ベンダーが作成（ベンダー決めるパターン）
→小・中規模案件はほとんどこのパターンです。要件定義工程でまとめます。
要件定義書を基に、必要となる機能を洗い出すこともあります（基本設計工程からの請負の場合）。
また、要件定義の前工程で業務分析を行う際に、新システムで必要となる機能としてまとめられることもあります。
機能設計でやること
- ①機能一覧の作成（もしくは、機能一覧の見直し）
機能は要件定義書を基に作成します。要件定義書に記載されている要件を満たすために、システム上でどのようなことができないといけないのか？を洗い出し、一覧化します。
この一覧を「機能一覧」といいます。大抵の場合、納品物に指定されていることが多いです。
「機能一覧」＝「このシステムでできることリスト（概要）」だと思っていただけたら簡単かと。
この段階では、最低でも以下の項目が整理されているはずです。- 機能ID
- 機能名
- 機能概要
- ②機能の実現方法決定
機能一覧を基に、その機能を満たすための実現方法を決定します。
具体的には、画面、帳票、バッチ、API のどれで実現するのか（もしくは、別の方法なのか）を決定します。
「機能の決め方」にあるように、機能一覧を作成するタイミングはまちまちですが、
機能一覧を基に実現方法を決定するのは機能設計工程で実施します。
この段階では、最低でも以下の項目が整理されているはずです。- 機能ID
- 機能名
- 機能概要
- 分類（画面、帳票、バッチ、API、その他）
- 分類ID
- 分類名称
- ③画面、帳票、バッチ、API 設計
実現方法が決定した時点で、それぞれの画面設計、帳票設計、バッチ設計、API 設計に入ります。
あらかじめ決められたフォーマットを基に、機能を具体化、詳細化していきます。
| 設計 | 概要 | 成果物（例） |
|---|---|---|
| 画面設計 | システム上の画面について設計します。 主にどの画面に何の項目が必要か、データをどこから取ってくるのかを設計します。 また、画面遷移で不自然な点は無いか、エンドユーザーが使いやすい画面、および画面遷移になっているかを設計します。 |
画面一覧 画面遷移図 画面仕様書 |
| 帳票設計 | システムから出力する帳票について設計します。 主にどの項目をどのようなフォーマットで出力するのかを設計します。 |
帳票一覧 帳票仕様書 |
| バッチ設計 | システムで使用するバッチ処理について設計します。 主にどのタイミングで、どのデータを処理するのかを設計します。 |
バッチ一覧 バッチ仕様書 |
| API 設計 | システムで使用する API について設計します。 主にどんな処理を、どんなルールで実装するかを設計します。 |
インターフェース一覧 インターフェース仕様書 |
機能設計のコツ ※私見です！
- 機能はブラさないこと
機能から画面、バッチ等が生まれるため、機能に過不足がある（＝ブレる）と、工数に大きく影響します。
（大きめなプロジェクトでは、要件定義後に改めて本見積（確定見積）を提示することが多々ありますが、そこで拾いきれなかったら痛いです。。。）
余計な機能があった場合は最終金額から引く、という調整もできますが、機能が足りないという場合、工数とスケジュールで頭を悩ませることになってしまいます（主に PM、PL が）。
顧客が当初の要件から機能を追加してきた場合には、二次フェーズに回す等、うまく調整しましょう。
- ID を付与すること
各機能、各画面、バッチ等に、システムで一意となるよう ID をつけてください。
例えば、「別の機能から呼ばれる 1 つの画面があるが、微妙に仕様が違う」みたいな場合も、画面名は同じで別の ID を付与することで判別可能となります（もちろん、1 画面に統一してもいいですが）。
また、機能 ID、画面 ID を組み合わせてクラス名に使用することも可能です。
（金融系ではセキュリティの観点より、クラス名や DB 名等に一目見ても分からないような名前をつける場合があります）
設計書とクラスのひもづきも容易になるのでお勧めです。