2022.12.29

外部設計の3つの設計対象…機能・非機能・方式

アーキテクティング

こちらの記事では、外部設計について解説します。

外部設計とは

外部設計とは、ユーザーから見たシステムの振る舞いを決めることです。例えば画面や操作方法等です。

要件を達成できるように外部設計を行うため、外部設計の前に要件定義が行われます。しかし外部設計をする中で不足していた概念が発見されることはあるため、現実的には要件定義と外部設計は往復が起き得るでしょう。

IPAが要件定義の方法のベンチマークとして提供している「ユーザのための要件定義ガイド」において、「要件定義ドキュメント」として要件定義の成果物群が定められています。この中に一般に外部設計の成果物とされるものも一部含まれていますが、ここでは外部設計の一般的な定義の「ユーザーから見たシステムの振る舞いを決める」に当てはまるものについては、外部設計の成果物として取り扱います。

https://envader.plus/article/54

外部設計の設計対象は大きく分けて機能・非機能・方式です。

機能設計

機能要件を実現する挙動を決めます。

対象になるのは画面・バッチ・帳票・外部システムI/F・DBです。

画面設計

画面設計では、画面の仕様を決めます。

画面単体のみならず、画面間の遷移やUIのポリシー等の全体的な問題もここで取り扱います。

バッチ設計

バッチとは、データ群を一括処理する機能です。画面からだとひとつひとつのデータについての操作をリアルタイムに行いますが、バッチでは複数のデータをあるタイミングでまとめて処理します。例えば月末にのみ利用するレポートがあり、そのレポートのためには常時利用されているデータ群をまとめて加工する必要がある時、バッチによって月末にそのデータ群をまとめて加工しレポートとして利用可能な状態にしたりします。

バッチ設計では処理の内容を決めることはもちろん、複数処理がある時はどういう単位でまとめるかやそれをいつ実行するのか等の運用面や、画面や他バッチからのDB更新と競合した場合にどうするかという排他制御検討、失敗した場合にどうするかという異常系の検討等もしなくてはなりません。

帳票設計

帳票とは、経営に関する書類です。伝票や売上表等です。BtoC向けWebサービス開発ではあまりかかわりのない概念かもしれませんが、業務システムでは重要な機能のひとつです。

帳票設計では帳票の表示の仕様を決めます。デザインや表示する情報等です。帳票はプリントアウトして業務で利用することもあり、それには業務の運用ルールも絡むため、ファイル形式や出力方法も問題になります。

外部システムI/F設計

外部システムI/Fとは、外部システムとのデータ連携のための接点です。I/Fはインターフェイスのことです。

開発対象のシステムは外部のシステムとやり取りをすることがあります。例えば決済部分だけ決済サービス事業者の機能を利用する等です。

外部システムI/F設計では、連携のためにタイミングやプロトコル、連携するデータ項目等を定めます。

DB設計

DBの設計には段階があり、概念設計・論理設計・物理設計があります。基本設計では論理設計を行います。

論理設計では、概念設計で作成した概念モデルを論理モデルに変換します。概念設計では業務に必要な情報をエンティティ（DBで言えばテーブル）レベルで洗い出したものに過ぎず、論理設計でそれを、使用するDBに合わせた形式で属性（DBで言えばカラム）レベルも含めて詳細化します。

詳細は他記事をご参照ください。（参照先：DB分野におけるER図の書き方やツールについて＞論理モデル）

非機能設計

非機能要件を実現する仕組み・挙動・運用を決めます。

まずは仕組みです。非機能要件の多くはインフラレベルで実現される以上、インフラ周りの設計が中心となるでしょう。

次は挙動です。インフラレベルだけでは担保し切れない非機能要件もあります。特にセキュリティとパフォーマンスは、個々の機能レベルで検討する必要があり得ます。このように個別検討が必要な箇所の設計を行います。

最後に運用です。非機能要件の中には運用・保守性と移行性のように、システム面だけではなく、現実で人の動きとルールをどうするかも問題となります。要件レベルよりも具体度を高めて設計を行いましょう。

方式設計

方式設計では、アーキテクチャと開発規則を決めます。

アーキテクチャとはシステムの構造です。主にシステムの分割方法・分割されたコンポーネントの連携方法・分割されたコンポーネントの内部構造が問題になります。このアーキテクチャは、機能設計・非機能設計を、将来性を考慮した上でいかに効率的に実現するかが良し悪しの判断基準となります。

また、開発規則も問題となります。具体的にはコーディング規約等です。構造によって開発者側の行為を良い方向へ制御できるのが最も望ましい状態ではありますが、それにも限度があります。そのためルールによって開発者の行動を統制する面が現実的には必要です。

【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

IT未経験者必見 USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの？」「正しい勉強法とは何なの？」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。

「フリーランスエンジニア」

近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。

「成功する人とそうでない人の違いは何か？」

私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている！！ここでの量産型エンジニアの定義は以下の通りである。

比較的簡単に学習可能なWebフレームワーク（WordPress, Rails）やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。

多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、