プログラム設計の誤解 <span class="fz-18px">－ソフトウエア設計シリーズ「守」④</span>

「設計する」とは、人が「考える行為」の一種だ。
ソフトウエア設計技術者は、考えたプログラム作りの作戦をプログラマ（プログラム製作の専門家）に伝える。
だがソフトウエア設計技術者とプログラマの確実な意思疎通はなかなか難しく、プログラムの不具合の温床となる。
本シリーズは設計と文書化をテーマとし、本記事では設計した考えを伝える難しさの原因を分析する。

ソフトウエア設計シリーズ「守」④		プログラム設計の誤解	松浦公政	2023年
対象読者	コンピュータのプログラムと設計の関係に興味がある技術者
	ソフトウエアの設計書の作り方に悩んでいるＩＴ技術者・システムエンジニア
	ソフトウエア開発の現場での価値ある設計書に興味がある技術者

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

プログラムの設計とは
プログラムを作る技術と設計する技術は別物
価値ある設計書とは

プログラムの設計とは

プログラムを作る上で考えるべき要点は、命令語をどう羅列して目的の機能を実現するかを決めること

比較項目	活動内容	出力	抽象度
プログラムの設計	目的の機能を実現するように、コンピュータに与える命令の適切な並び（＝プログラム）を考案する活動	人間の言葉（日本語や英語などの自然言語）で記述した考案内容	高
プログラムの設計	プログラムが動作する上で必要になるデータを考案し、そのデータに分かりやすい名前をつける活動	人間の言葉（日本語や英語などの自然言語）で記述した考案内容	高
プログラムの製作	設計内容をプログラミング言語に翻訳し、コンピュータが理解できる命令語の並びを作る活動	プログラミング言語で表現したコンピュータへの命令語群	低

整理すると　⇩

設計とは、プログラムの「組み立て方」という脳内の抽象的な「考え」

プログラムを作る技術と設計する技術は別物

プログラミング言語でプログラムを作る技術の習得はそれほど難しくない

パソコンやスマートフォン用にプログラムを作る命令語は、単語数が少ない上に、単純な動作しか表現できないので覚える量は少なく、習得はかなり容易な部類に入る。
	作りたい機能が単純なら、何回か試行錯誤すればプログラムを作れる。

だが　⇩

習得が容易だといっても、狙った機能を実現するために、単純な命令をいかに組み合わせるかを考えることは、実はかなり難しい。

このため　⇩

少し複雑な機能を果たすプログラムを適切に作るには、「考え」が重要になる。
	たとえば販売店舗の一日の「売上集計」の算出には、どんな作戦を段取（プログラムを組み立て）れば、正確な結果を上手く出せるかを「考え」ることが重要だ。
この「考え」が『設計』そのものだ。

プログラミング言語の技術は目的を実現する手段に過ぎず、目的を達成するための知見の方が重要

プログラムの設計技術（プログラムの組み立て方の作戦を考えること）と、プログラムを作る技術（設計内容をコンピュータが理解できるように翻訳すること）では、その思考に使う脳内の回路はおそらく別物だ。
プログラムを作る技術は本質的に「翻訳作業」なので、プログラミング言語の習得が必要だが、習得の難易度は実は低い。

単純な電卓のプログラミング言語の習得は難しくない
【画像出展】イラストＡＣ		たとえば左図のような単純な電卓だと、プログラミング言語を構成する記号の数は、キーの数の14個になる。
記号	文字	「５」や「３」などの数字ボタン、「＋」「×」などの演算ボタン、「＝」の計算開始ボタンなど、ボタンの上に刻印されている記号で構成される。
記号	単語	１文字が１単語（＝意味を持つ単位）になる。
記号を並べる順序		「５」　➡　「＋」　➡　「３」　➡　「＝」　の順に押すと電卓が計算を始め、計算結果を液晶窓に表示する（この場合は「８」を表示）のように記号の順序に規則がある。
記号を並べる順序			「５」➡「＝」➡「３」➡「＋」の順序に押すと正しい計算結果を表示しない。

電卓のプログラミング言語の習得難易度は　⇩

数字や四則演算の記号は小学校卒業までには習い終わるので、追加で覚えるキーの数はたかが知れている。
	ほとんどの人にとって電卓の操作方法（プログラミング言語）の習得はたやすい。

だが　⇩

電卓のキーを押して「7+8」や「12-5」を計算させたところで、他人はその行為に大した価値は認めない。

なぜなら　⇩

電卓は、より高度な目的を達成するための単なる道具に過ぎないから、単に使う能力があっても尊敬はされない。

大事なことは　⇩

「どんな結果が欲しい」という明確な目的を持ち、その目的を効率的に達成する「道具」として電卓を使いこなすと、初めて他人が尊敬してくれるようになる。

だから　⇩

電卓を使って計算し、何らかの結果を得るなら、「何を得たいか」「どう電卓を操作して計算させるか」「計算結果をどう使うか」を明確にする必要がある。
	たとえば、今日一日の店の売上集計が電卓を使う目的なら、設計書に記載する内容は、次のような記述になろう。
		入力	今日一日の売上伝票群。
		処理	「伝票の売上合計欄に記載された数字数桁を電卓の数字キーを押して入力し、最後に『Ｍ＋』キーで記憶させる」をすべての伝票で繰り返す。
		出力	『ＭＲ』キーで合計値を電卓の液晶窓に表示させ、売上台帳に転記する。

上述の内容を設計する技術者に必要な知識は、電卓用のプログラミング言語の造詣はさほど重要でなく、むしろ「売上集計」の概念、電卓の基本的な機能、電卓の操作作法、の理解が重要になる。

設計技術者は目的の機能を果たすプログラムを作る「作戦」を考え、プログラマに伝える技術が重要

ソフトウエア開発で作戦は「設計書」と呼ぶ文書に表す。

設計とは、プログラムの「組み立て方」という脳内の抽象的な「考え」

脳内にある抽象的なアイディアやイメージを　⇩

「考え」をかみ砕いて徐々に具体化して行くと、現実的な実現性が増した「作戦」になる。

作戦もまた脳内に浮かんだイメージだから　⇩

「作戦」の脳内イメージを、文字や図表など人間が理解できる言語で表現する手段が『設計書』。

設計書があると　⇩

設計書で、設計技術者（個人）の脳内の「考え」（＝設計）を他者と共有する。

　考えの共有には　⇩

設計書は、他者がプログラムを作ることを前提として、次を配慮した記述が求められる。

作戦の意図を誤解させない。
作戦を正確に伝える。
作戦を理解しやすく伝える。

上表の「2. 正確に伝える」と「3. 理解しやすく伝える」は、しばしば相反する　⇩

正確さを追及すると、理解しやすさを犠牲にする

⇔

理解しやすさを追及すると、不正確になる

設計者のスキルアップの難所は、分かりやすい設計書の作り方が不明確という点に尽きる。

価値ある設計書とは

難しいのは、プログラムを組み立てる作戦の考案と、考案した作戦を伝える技術

「プログラム」の作り方を熟知する技術者（プログラマ）は多いが、ソフトウエアの「設計文書」の妥当な作り方を熟知する技術者（ソフトウエア設計者）は稀少に思う。
	職場で受け継がれてきた設計文書のテンプレートを埋めることが「設計行為」だと考えているソフトウエア設計技術者は、「考える行為の深さ」を甘く見ているのかもしれない。
	そんな技術者は、プログラムを作る際にあまり役立つ情報を設計書に書いているとは思えず、設計書など省略してプログラムコードを書いた方が「ムダ」がなく安上がりと思うだろう。
	ムダと感じるような設計書の多くは、ソフトウエア（文書＋プログラム）としての納入条件を満たすために作られる。
	ただ納入条件を満たす目的で、プログラムを作った後で穴埋め的に作り「設計書」という形を残すような設計プロセスは形骸しており、ほぼ価値がない文書を作っている。
形骸化した設計書は、モノ作りに有益な情報を設計技術者とプログラマが共有して、品質と生産性を上げる道具にはなり得ない。

では　⇩

開発担当者や顧客が情報を共有でき、効率的にソフトウエア開発を進める中核となる「設計文書」とは、どういう代物か。

残念ながら　⇩

望ましい設計書のカタチを問われても、理想の設計書のイメージは、組織ごとに、というより技術者それぞれに違う。

人によって理想の設計書が違う理由は　⇩

「設計」という用語の意味が曖昧だから、理想が人それぞれになる。（【参考】設計が抱える問題）

事細かに手順を伝えるだけの「残念な」設計書が業界にはあふれている

「考え」をプログラマに伝えるに当たり「考えを正確に伝えること」に執着し、「手順」を示すことが「設計意図」を確実に伝える技術だと考えるソフトウエア開発技術者は少なくない。
そのようなソフトウエア開発技術者が作る設計書は、手順１「○○する」➡手順２「□□する」➡手順３「△△する」のような単純作業の羅列で設計を表現する。

手順を羅列した設計書のイメージ
手順	処理内容
①	「現在時刻」と名付けた変数と「設定時刻」と名付けた変数を比較する。
②	もし比較した二つの変数の値が同じでなかったら、
③	①へ戻って設定時刻が来るか再確認しろ。
④	もし比較した二つの変数の値が同じ値なら、
⑤	ブザーを鳴らす時間を指定する出力ポートに「0.5秒」を格納しろ。
⑥	ブザー鳴動を開始を指示する出力ポートに「鳴動開始」を格納しろ。
⑦	処理を終えて呼び出し元へ戻れ。

このような記述水準の設計書の功罪

功	コンピュータ（CPU）が理解する命令文に近い低水準で記述してあるので、技術が低いプログラマでもプログラミング言語へ翻訳できる。
罪	低水準での記述だと、手順の各項番の目的・狙い・意図を理解しにくいため、プログラマが意図を誤解しても気づかないリスクが高く、誤解のまま作るプログラムは不具合の温床となる。
罪	手順通りに実行すれば目的の高次機能が実現できるか判断しにくい。たとえば設計した手順に考慮漏れがあっても気づき難くく、不具合の温床となる。

低い記述水準の設計書を受け取ったプログラマは、そのままプログラミング言語に単純に翻訳するしかないが、それなら設計技術者が直接プログラムコードを書いた方が「ムダ」がないと思うだろう。

ソフトウエア開発で「価値ある」設計書は、設計者の狙いが読み手に伝わってくる文書

設計者が「作戦」を考えるとき、その背後には必ず作戦の目的・狙い（意図）がある。

価値ある設計書とは　⇩

そのように設計する目的・狙い（意図）を伝えようと努める文書にこそ価値がある。
	目的・狙い（意図）が分からないと、読み手が誤解するリスクが高いし、手順が目的に適うかを他者がレビューできない。

では、どのような設計書だと目的や狙い（意図）を伝えられるのか。
ステップアップを目指す方は「ソフトウエア設計シリーズ『破』」へお進みください。
ソフトウエア設計シリーズの目次はこちらへ

プログラム設計の誤解－ソフトウエア設計シリーズ「守」④

プログラムの設計とは

プログラムを作る技術と設計する技術は別物

価値ある設計書とは

コメント