設計の基盤となる抽象化能力 <span class="fz-18px">－ソフトウエア設計シリーズ「破」①</span>

設計者とプログラマは、製品のプログラムを開発する点でゴールを共有するが、それぞれの担当作業のゴールは別だ。
設計者が、設計書で目的や狙いを伝えるには、まず設計とプログラムのゴールの違いを認識する必要がある。
本シリーズは設計と文書化をテーマとし、本記事では設計する上で基盤となる能力を解説する。

ソフトウエア設計シリーズ「破」①		設計の基盤となる抽象化能力	松浦公政	2023年
対象読者	設計者に期待される活動内容・思考方法に興味があるＩＴ技術者・システムエンジニア
	表面に見えない関係を視える化する思考方法に興味がある方
	抽象化と言語表現の関係に興味がある方

記事の音声解説付き（下のプレイボタンで解説開始）

モノ作りの過程（プロセス）での設計の「位置」
設計工程が、要件工程・実装工程とは異なる特徴
要件工程が抱える具体的な課題の抽象化（言語化）
抽象化した情報を使って知恵を出す
実装工程に伝わるよう「文書で具体化」する

モノ作りの過程（プロセス）での設計の「位置」

モノ作りの過程は、大まかには「要件」（≒「要求」）➡「設計」➡「実装」に区分でき、区分した単位を「工程」と呼ぶ

プログラムの開発もモノ作りの一種であり、各工程は次を出力する。

工程	出力				主要人物
工程	イメージ		要旨		主要人物
要件	「こんなモノが欲しい」という「作るべきモノ」への期待を示した情報		期待	欲しいモノ	お客さん（顧客）
要件	例	今日一日の店の売上を集計したい	期待	欲しいモノ	お客さん（顧客）
⇩
設計	要件に応えて「こんな風に作る」という作り方を示した情報		仕様	作るモノの有様と作り方	設計者
設計	例	売上表のフォーマットと、集計の計算方法（計算式）	仕様	作るモノの有様と作り方	設計者
⇩
実装	設計に沿って（不足の情報は補完して）作り出す成果物		成果	完成したモノ	プログラマ
実装	例	『売上集計アプリ』のプログラムコード	成果	完成したモノ	プログラマ

設計工程には、目的の製品プログラムではなく、「作るモノの有様ありさまと作り方」を示す『設計書』が求められる。

設計工程が、要件工程・実装工程とは異なる特徴

他の工程との思考方法の違いから、設計者に必要なスキルを分類すると３種類に分かれる

工程	出力の特徴		出力の特徴	工程

要件	顧客が抱えている課題は、現実に困って解決したい事象なので具体性が高い。	① ➡	顧客が「困っていること」をコトバで適切に表現できないことは珍しくなく、その場合は設計者が困りごとを聞き出して文書化する。	設計
			② ⇩
実装	プログラマが作るプログラムは、顧客が現実に使う製品なので具体性が高い。	③ ⇦	「設計」は、脳内での整理や考案などの思考で、直接見たり触ったりできないという意味で具体性がなく、形がない抽象的な知恵。
⇩ 設計者は、具体的な事象を抽象化（言語化）し、抽象的なレベルで思考する。

上図から見えること　⇩

設計技術は、３種のスキルに分解できる	①	特徴抽出スキル	要件工程が抱える具体的な「課題を抽象化」し、
	②	相似連想スキル	「抽象的に思考」した結果（対応方針）を、
	③	手段表現スキル	実装工程に伝わるよう「文書で具体化」する。

要件工程が抱える具体的な課題の抽象化（言語化）

パターン化（あるいはグループ化）≒抽象化

抽象化するプロセスで、心に浮かぶ感情
モノゴトを眺めていて「パターンがある」と感じたときに抽象化が始まり、パターンに名前（意味を適切に表すコトバ）が付いたとき、「抽象化が完成した」という。
パターンを見つけるまでは、	何か居心地の悪さを感じ、
パターンが閃くと、	驚きでコトバを失い、
そのパターンを適切に表す名前を思い付くと、	満足感がこみ上げ、優越感を得て思考を終える。

すなわち　⇩

「抽象化できた」

とは

「分類できる塊」（パターン）が明確になり、その塊に「名前がついた」状態。

例を挙げると　⇩

「ポイントを要約して短い言葉で表現する」のが典型的な抽象化のプロセス

具体思考する人と抽象思考する人が、すれ違う会話の典型①

具体思考する人と抽象思考する人が、すれ違う会話の典型②

具体さんと抽象さんの会話②図

上図のフキダシの大きさを比べて分かるのは、具体思考は長文、抽象思考は短文ということ。

つまり上例では　⇩

「本は本棚に戻して、ジュースは冷蔵庫に入れ・・・」という具体的な諸行為に、抽象さんは共通の目的を持つパターンを見抜き、そのパターンのポイントを要約して『片づける』と名付け（抽象化し）て、「文章」で表現されていた情報を「単語」に圧縮した。

設計者に期待される「課題の抽象化」で考えると　⇩

課題の抽象化とは、「顧客が困っていること」を、要点を衝いた短いコトバや文に変換する知的プロセスになる。

抽象化した情報を使って知恵を出す

設計工程での抽象思考の核心は、具体事象の共通項の検出で、そのために具体事象の間に潜む「見えない線（関係）」を見出す

現実世界の情報システムなどは、様々に異なる具体的な事象（例：「表計算アプリ」「モーター制御」「ネットワーク管理」など）で、それぞれが別物のシステムとして独立している。

ところが　⇩

視点を変えると、各情報システムに共通点があるなど「見えない関係」が視える場合もある。

見えない関係がつながると　⇩

関係あると気づくと、それまではバラバラに存在していた事象が一括りに視えたりするメリットがある。

【参考】意図志向で表現する分析（把握と抽象化）の思考

抽象思考とは、上位からの視点で、事象（モノゴト）をシンプルに理解する思考技術

抽象化する際は、事象そのもの（具体）から離れ、上から目線で客観視する。	➡	客観視すると事象の「関係性が視えやすい」。	➡	見えない関係が視えると、バラバラに存在していた事象がひとつにまとまる。
		⇩		事象間の関係性（象徴）の三大類型 (上野千鶴子『情報生産者になる』)
		関係性の「視点」が抽象化した際の「象徴」（メタ情報）になる。		因果関係【Ａ→Ｂ】	事象Ａの発生後に、高い蓋然性で事象Ｂが起きる関係
				対立関係【Ａ⇔Ｂ】	事象Ａと事象Ｂが相容れない関係
				相関関係【Ａ⇆Ｂ】	事象Aと事象Ｂは同時に起き、どちらが原因／結果かは判定困難な関係

抽象思考の効果とは　⇩
難解で複雑に見えた事象が単純に見えてくる。「語彙」を備えた設計者は、関係をメタ情報（より高い次元の言い方）でスマートに表現できる。
メタ情報で表せる程度まで単純化すると　⇩
課題の本質を理解できる人が増え、多くの人（例：専門知識を持たない人）で認識を共有できる。別々の事象の重要度比較や影響範囲の判定が容易になり、納得度が高い結論を出しやすくなる。

抽象化して全体を見通し、抽象的な知恵を出す

設計者は、個別の機能を離れて全体俯瞰したり、システムの制約条件を考慮して、顧客が抱える課題の抽象的な解決策（知恵）を考案する。

（例）課題解決のために抽象レベルで考案する「知恵」のイメージ
この機能同士は、同じタイミングで動くので、統合した方が効率的。この機能は、複数の役割を持つので、役割単位のサブ機能に分割して多様な用途で再利用。この機能は、負荷が高いので、並行処理できるサブ機能に分解して計算機の負荷を分散。この機能は、市販製品の機能を流用すれば費用削減。　　　など

（例）課題解決のために抽象レベルで考案する「知恵」のイメージ

この機能同士は、同じタイミングで動くので、統合した方が効率的。
この機能は、複数の役割を持つので、役割単位のサブ機能に分割して多様な用途で再利用。
この機能は、負荷が高いので、並行処理できるサブ機能に分解して計算機の負荷を分散。
この機能は、市販製品の機能を流用すれば費用削減。　　　など

実装工程に伝わるよう「文書で具体化」する

分割はトップダウン思考になる

抽象的な知恵（方針）を実現するためにトップダウンで思考し、機能を分割する。

トップダウンで思考する考え方は、トップダウン思考を参照

設計工程と実装工程の理想的な境界とは

「分割した機能単位（枠組み）の定義」が設計工程の仕事
分割された「担当範囲の具体化（中身）」が実装工程の仕事

【参考】細谷功『具体⇔抽象トレーニング』

次回は「ベテラン設計者の思考プロセス」を解説します
ソフトウエア設計シリーズの目次はこちらへ

設計の基盤となる抽象化能力－ソフトウエア設計シリーズ「破」①