複雑に見えるシステムを「理解しやすく設計」する技術者は、問題・課題の解決に向け、まず問題・課題を抽象化（モデリング）した上で、解決方法を考える。
考えた解決方法（設計結果）を伝えるスタイルには、「結論志向」と「意図志向」の二通りの方向性がある。
優れた技術者がモデリングして設計する思考の先に「意図志向」で表現する設計書がある。
本シリーズは設計と文書化をテーマとし、本記事では抽象化設計と意図志向での設計を説明する。
| ソフトウエア設計シリーズ「破」② |
ベテラン設計者の思考プロセス | 松浦公政 | 2024年 | |
| 対象読者 |
優れた設計者の「脳内の思考の流れ」に興味があるＩＴ技術者・システムエンジニア |
|||
| モデリング作業の進め方に興味があるＩＴ技術者・システムエンジニア |
||||
| 問題を抽象化して課題と捉え、対応の要点を絞り込むノウハウに興味がある方 |
||||
記事の音声解説付き（下のプレイボタンで解説開始）
明解に設計する技術者の思考の流れ
設計者の脳内では、思考のフェーズは一直線には進まず、再思考経路の矢印のように思考を繰り返して、徐々に設計の完成度を上げる
うまく抽象化すると、問題・課題が単純に見えてくる
明解に設計する技術者は、具体的な問題（ボトム）を抽象化した課題に持ち上げ（アップし）てから、具体的な対応を考える。
 |
|
| ②の「抽象化した課題」がモデルになる。 | |
| ①がボトムアップ・アプローチの部分になる。 | ③がトップダウン・アプローチで具体的な作戦（対応）を考える部分になる。（上流設計の思考プロセス参照） |
問題を一見で把握できるよう、問題が持つ特徴を強調して単純化し、人間視点での捉えやすさを追求して表現した情報が「モデル」。
モデルは厳密や精緻に表現する必要はなく、一見で問題のイメージを掴み易くまとめるほど、完成度が高く役立つモデルと言える。
モデルの表現方法はいろいろなパターンがあり、３種に分類できる。
| モデル種別 | 表現方法 | 表現例 |
|---|---|---|
| 物理モデル | 対象の現象を実体に近い形で表現 | 模型（モックアップ）、完成予想図 |
| 図的モデル | 対象の構造、関係、順序、動きなどを図・表で表現 | 関係図、階層図、流れ図、計画表、路線図 など |
| 数理モデル | 現実に起こる現象を数式で表現 | 待ち時間予想式（待ち時間＝待ち人数×所要時間） |
明解に設計する技術者がモデルを作るときは、人間視点での捉えやすさ（理解しやすさ）を重視し、上表の表現方法を組み合わせたり、視点が違う複数のモデルを作って「抽象的な課題（＝問題の特徴）」を表現する。
設計結果を表現する「結論指向」と「意図指向」
| 指向性 | 設計書に表現する内容 | 設計表現の具体化度 |
|---|---|---|
| 結論指向 | 問題を解決する機能の作り方を具体的に表現する。 | 具体化度：高 |
| 意図指向 | 問題を解決するサブ機能ごとに設置目的を表現する。 | 具体化度：低（やや抽象的） |
結論指向の設計者の思考の流れ
結論指向の設計者は、設計の成果を「処理手順（やり方）」で問題解決手段を表現する。
| 利点 | 欠点 |
|---|---|
| プログラマには、問題解決手段が具体的である分、迷わずプログラムを作れる。 |
問題解決手段を具体的に設計するには、解決手段（方法）を詳細に示す必要があり、設計の作業量が増える。 |
| 設計作業量が多いと ⇩ | |
| 作業が多い設計者には「直面する課題の解決を急ぐ心理」が働き、設計書の記述が「処理手順（＝こうやって、ああして、次にどうする）」に偏って、設計意図・目的（＝この機能は○○○○の状況を考慮して設ける 等）の記載が弱まったり省略されやすい。 | |
|
業務知識や仕様理解が低く、設計が解決する課題や設計の意図を理解してないプログラマでも対応できる。 |
設計書に、設計意図・目的の情報が欠落すると ⇩ |
| 仮に設計書の処理手順に不備があっても、実装工程では処理手順の妥当性を設計意図・目的と照らした合わせた判定は不可能。この結果、実装工程の作業が単調化し検証能力が弱まる。 | |
| 実装工程が単調化すると ⇩ | |
| 経験値が高く優秀なプログラマほど作業意欲を持てない。 | |
| 妥当性の判断基準の不明確さも手伝って ⇩ | |
| 意欲の低下は、実装工程でプログラマが混入させた不具合にも気付かなくなるリスクを高める。 | |
| 成果物の品質が設計者の期待を大きく裏切らない。 | 実装工程で処理手順の妥当性を判断できないと ⇩ |
| 実装作業時にプログラマが気付く、設計不足・矛盾・ムダ等の改善指摘が激減し、設計結果への品質保証の水準が下がる。 | |
| 実装工程での品質保証が弱まると ⇩ | |
| 設計結果（設計書）への品質保証が、設計工程のみに依存する。 | |
| 最終的な影響は ⇩ | |
| 開発チームの総合的な品質保証水準が低下して、最終成果物の品質が低下するリスクが倍増する。 | |
| 【参考】価値ある設計書とは | |
意図指向の設計者の思考の流れ
意図指向の設計者は、設計の成果を「機能の目的・意図」によって問題解決手段のヒント（こういう考え方で取り組めば問題解決）の形で表現する。
| 利点 | 欠点 |
|---|---|
|
設計内容を詳細に指定しない分、設計者の作業の生産性が高まる。 |
設計者には、入力・出力の仕様を漏れなく洗い出した上で、入力データ・出力データを抽象的に表現するスキル（抽象語の語彙）が必要で、対応力を持つ技術者が少ない。 |
| 設計者には、設計内容を（処理手順の羅列にせず）、実装時の要点・注意点を見通し、出力への期待を主に自然言語で表現するスキル（国語力・作文力）が必要で、対応力を持つ技術者が少ない。 | |
|
設計書の品質が低いと、設計（者の）意図が実装工程（プログラマ）に伝わらないリスクが高まる。 |
|
| プログラマに設計思考を期待する分、設計者の考慮不足に、プログラマが第三者視点で気づく可能性が高まる。 | プログラマの経験値・読解力・抽象的な判断力が低いと、低品質な成果を産むリスクが高まる。 |
| プログラマが仕様理解を深める結果、設計に潜在する矛盾を指摘する期待が高まり、プログラマが想定以上の成果品質を出す可能性が高まる。 | |
| プログラマの自由・裁量が大きいと意欲を持ちやすく、期待に応えようと工夫する動機をプログラマが持てる。 | |
| 仕事を通じて、プログラマの設計スキルが向上しやすい。 | |
| 【参考】ソフトウエア開発で人を動かす（依頼する）メカニズムの分析 |
意図志向で表現する分析（把握と抽象化）の思考
解決すべき具体的な問題を抽象化する作業をモデリング（モデル化）と呼ぶ。
たとえば、設計者が解決すべき課題が「５個ある既存の機能を整理してまとめる」だとすると、明解に設計する設計者の脳内では、次のように思考のプロセスが進む。
| 機能間の関係抽出 | ⇨ | 関係の類型化 | ⇨ | 機能の統合と命名 |
| 視点を変えると、各機能に共通点があるなど「見えない関係」が視えやすい。 |
| 見えない関係がつながると ⇩ |
| 関係が視える設計者の興味は、個別の具体機能の中身を離れ、関係を表す「線」になる。 |
 |
見えない関係がぼんやり浮かんでくると、バラバラに存在していた機能の連携が見える ⇩
機能と機能を結び付ける関係にはパターンがあり、適切な「関係のパターン」を判断する。
| 機能間の見えない関係の代表的なパターン | |
| 関係のパターン | 説明 |
|---|---|
| 因果関係 | 原因と結果 |
| 協力関係 | 相乗効果がある |
| 同類項 | 類似点を持つ |
| 対立関係 | 利害の衝突 |
| 阻害関係 | 機能遂行の障害 |
| 前後関係 | 使用前と使用後 |
| 目的・手段関係 | 設定するゴールと、その解決方法 |
| 主従関係 |
親機能と子機能 |
| 優劣関係 | 特定の指標が示す評価値の序列 |
| など | |
明解に設計する設計者は、たくさんの「関係のパターン」を脳内に在庫する。
関係のパターンが視えたら ⇩
| バラバラに存在していた機能が、共通点を持って一括りに視えるようになる。 |
 |
明解に設計する設計者は、豊富な語彙と、伝わりやすい名前を付けるセンス（ネーミング・センス）を持つ。
⇩
モデルの完成
優れたベテラン設計者の思考プロセス
| 明解に設計する設計者は、バラバラに見える要素を上から客観的に見て「関係性」を発見し、関係性を足がかりに単純化した全体像を把握する。 | ||
| ボトムアップ・アプローチ |
課題解決に向けて現実にある要素を積み上げながら共通項を探す帰納的分析。 |
|
| このような知的活動は、一般的に「情報を整理する」と呼ばれる。 | ||
| つまり ⇩ | ||
| 設計能力の前段は「整理する力」と言え、論理的に考える／組み立てる能力よりも、特徴を抽出して言語化する「語彙力」が重要な要素だ。 |
||
| 語彙力を持つ重要性とは ⇩ | ||
|
共通点や関係など特徴を把握し、把握した情報を整理して他者が理解できるコトバで説明できる人は、優れた設計者の資質がある。
|
||
| さらには ⇩ | ||
| 他者が理解できるコトバで説明する能力は、生成ＡＩを使いこなすプロンプト設計力につながる。 | ||
次回は「上流設計の思考プロセス」を考察します。
ソフトウエア設計シリーズの目次はこちらへ
コメント