上流工程の設計は、抽象化した課題を入力として、対策を出力する活動だ。
考えた対策（設計結果）を伝えるスタイルには、「結論志向」と「意図志向」の二通りの方向性がある。
技術者がモデリングして設計する思考の先に「意図志向」で表現する設計書がある。
本シリーズは設計と文書化をテーマとし、本記事では抽象化設計と意図志向での設計表現を考察する。
| ソフトウエア設計シリーズ「破」③ |
上流設計の思考プロセス |
松浦公政 | 2024年 | ||
| 対象読者 | 問題や課題を解決し易くするための「見方」「捉え方」に興味がある方 | ||||
| 設計者が問題・課題を解決する際の脳内の思考の流れに興味がある方 | |||||
| 抽象化した課題への対応で、要点を絞り込む対応方法に興味がある方味がある方 |
|||||
記事の音声解説付き（下のプレイボタンで解説開始）
うまくモデル化すると、問題・課題の対応が簡単になる
具体的な問題から持ち上げた「抽象化した課題」（モデル）に対し、具体的な対応を考える。
 |
| 「抽象化した課題」（モデル）と、「知恵溜」の在庫からよく似た課題を連想（②）し、「過去の対応事例」を取り込む。 |
| ③で「過去の対応事例」を参考に、今回の具体的問題への「具体的な作戦（対応）」を考える。 |
| どんな状況や局面にも問題（困りごと）はあり、世の中は多様で具体的な問題で溢れている。 | ||||
| 問題（困りごと）の例 | 遅刻したと今日も叱られそうだ。 | |||
| 朝食を食べないので、午前１０時には空腹で集中力が続かない。 | ||||
| 待ち合わせに遅れることが多く、友人から時間を守れない人物と思われている。 | ||||
| 各問題をじっくり観察すると ⇩ | ||||
| 別々に存在する具体的な問題も、解決したいポイント（課題）を整理すると共通点が見え、各問題が抱える情報量が減ってスッキリする。 | ||||
| 問題（困りごと）の例の３件を分析したら、どれも「起床から家を出るまでに時間に余裕がない」ことが原因だったとする。 | ||||
| 問題を分析し、抽象化したモデル | 現実 | 時間に余裕なく家を出発することが多い。 | ||
| 影響 | 出発後に問題が起きやすい。 | |||
| 課題 | 出発前に十分な時間を確保できない。 | |||
| 分析の最大の効果とは ⇩ | ||||
|
３件の具体的な問題を抽象的に視たら、課題が１件に集約されたことになる。
|
||||
| １件に集約された課題の「解決方針」もまた、 | ||||
| 起きてから家を出るまでの時間を今より長く確保する | ||||
| という１件に集約できる。 | ||||
| つまり ⇩ |
||||
|
個別には種々雑多な問題でも、抽象的に視れば同じ課題に集約されやすく、集約できれば必要な対応も少なくて済む。
|
||||
| 少ない対応件数で済む理由は、抽象的に捉えた課題（＝問題の本質）に対応すれば、同じ課題を抱える問題に一斉に効果が及ぶから。 | ||||
| 問題（困りごと）の例だと、「早起き」という具体的な対応を実行できれば、例に上げた３件の問題に共通して効果が上がる。 | ||||
|
少ない対応でも、多様な問題に効果が上がる効率的な対応が見つかる点が、抽象化（モデリング）する最大のメリット。 |
||
| メリット | 抽象的に思考すると、問題の共通点（「問題の本質」と呼ぶこともある）を捉えて単純化でき、要点の「課題」が浮かび上がる。 | |
| 問題が持つ情報を圧縮した「課題」は、問題が持っていた情報量（件数）が減るので、必要な対応の量（件数）も少なくて済む。 | ||
| 抽象化（モデリング）すると日常生活にも余裕が生まれる。 | ||
| たくさん存在する具体的な問題ごとに個別に対策していたら、日常生活は対応行為で埋め尽くされ、対応疲れで心理的・身体的に破綻する。 | ||
| メンタル管理の観点からも ⇩ | ||
| 具体的な問題を抽象化して課題と捉え、対応の要点を絞り込むライフスタイルは、次々に問題が現れる現実社会で「余裕を確保する」強い武器になる。 | ||
抽象的な「対応」の構造
| 世の中のすべての問題・課題に通用する「万能の対応」は存在しない。 | |
| 「対応」は通常、特定の問題には有効だが、別の問題にはたいてい影響を及ぼさない。 | |
| たとえば、衛星情報を使った位置補正という対処は、カーナビゲーションの性能向上には効果を発揮するが、銀行の入出金管理にはほとんど影響しない。 | |
| つまり対応には、効果をよく発揮できる適用領域（得意分野）がある。 | |
| 「対応」の構成要素 |  |
適用領域に対処を組み込んで「対応」が完成する。 | ||
 |
 |
|||
| 適用領域と対処の組合せ具合は ⇩ | ||||
| 効果が多そうな対応の組合せ | 効果が少なそうな対応の組合せ | |||
 |
 |
|||
| 適用領域と対処の整合度が高そう。 | 適用領域と対処の整合度が低そう。 | |||
「適用領域」に「対処」を組み込んで「対応」完成
| 「適用領域」は、対処が必要となる場面や状況の枠組みで、いろいろな「困った場面・状況」の『枠組み』がある。 | ||
 |
||
|
適用領域に該当する情報システムの『枠組み』例 |
||
|
||
|
「適用領域」の構成は、対処方法が「明確な部分」と「選択する部分」に分かれる。 |
||
 |
||
| 「対処」は、適用領域の「選択する部分」にハメ込む部品に相当する。 | |||
 |
|||
| 対処に該当する情報システムの部品例 | |||
| ＰＩＤフィードバック制御 | ３Ｄ座標の透視投影行列変換 | ||
| 重要データ保持領域二重化 | 乱数生成 | ||
| 処理優先度制御 | 検索支援データ付加 | ||
| 衛星情報位置補正 | ナビゲーション地図更新 | ||
| 状態階層モデリング | 最小コスト経路算出 | ||
| 処理並列化での負荷分散 | 操作履歴データ保存 | ||
| 検索高速化用索引設置 | 稀少資源の排他制御 | ||
| データ重複・偏在解消 | メッセージ駆動制御 | ||
| 登場人物の相互作用検知 | データの高速整列 | ||
| 適用領域の「選択する部分」は、それぞれ特徴があるので、スムーズに組み込める部品（対処）を吟味する必要がある。 | ||
 |
||
| 適用領域の「選択する部分」とよく似た「対処」を選んで当てはめる。 | ||
 |
||
| 適用領域に組み込んだ対処を、課題にしっくり合うように調整する（適応させる）と、対応の効果は増す。 | ||
 |
||
全ての「選択する部分」で「選択する対処」が決まり、ピッタリ合うように微調整すれば問題への対応が完成する。
| （例）「適用領域」の『カーナビゲーション（道案内）』に適合する「対処」を組み込むイメージ |
 |
意図指向の設計結果の表現
意図志向での設計では、以下を設計書に明記すれば具体化作業は完了する。
| 各対処の | 目的・狙い | を言語化する |
| 入力・出力 | ||
| 実装上の要点 |
なお言語化とは、単に説明の文章を書くことではない ⇩
|
言語化には、具体的な実装方法を検討する実装工程の設計者や、システムをリリースした後の機能追加・変更を担う保守担当者の理解を促進させる「図解」での解説を含む。 |
|
| たとえばＵＭＬが標準化した各種の図は、記法・記号を規定している（＝言語文法がある）ので、言語に属する。 | |
|
設計書は、主軸を自然言語、補助軸を図解（図・表・グラフなど）として両方を混ぜて記述すると、読み手は左脳（自然言語）と右脳（図解）を並行して使用するため、自然と脳の稼働率が上がって理解を促進する。 |
|
| 意図志向の設計書に期待する記載項目は、本シリーズの『ソフトウエア設計書に書きたい項目』を参照。 | |
| 意図志向の設計書では、処理手順（「もし○○なら□□し、次に…」といったプログラム論理の水準）は、基本的に設計しない。 |
なぜなら ⇩
| 意図指向の設計は抽象的な設計なので、具体的な各対処の内部の処理手順設計は、実装工程に任せる。 |
実装工程で処理手順を設計するメリットは ⇩
|
日常業務の忙しさや納期の圧力から、言語化を単なる「コスト」と捉える残念な組織リーダーもいる（本シリーズの『プログラム設計の誤解』参照）。
そういう見識の組織リーダーが、中長期視点で生産性を大幅に改善した事例は寡聞にして知らない。
次回は「「境界線」をどこに引くか」を考察します。
ソフトウエア設計シリーズの目次はこちらへ
コメント