技術者のスキルを伸ばす設計書とは <span class="fz-18px">－ソフトウエア設計シリーズ「破」⑥</span>

仕事は、基本的に「依頼する ➡ 依頼で動く」関係で、ソフトウエア開発の仕事では「作戦を決める」設計者と「作戦に乗ってモノを作る」プログラマの関係になる。
設計者側の依頼の仕方が、成果物の出来栄えに大きく影響するので、プログラマ側の心理に寄り添って設計内容の効果的な伝え方を考察する。
本シリーズは設計と文書化をテーマとし、本記事では設計した考えを伝えるノウハウの基礎を説明する。

ソフトウエア設計シリーズ「破」⑥		技術者のスキルを伸ばす設計書とは	松浦公政	2024年
対象読者	依頼する相手に前向きな取組みを促す「依頼スタイル」に興味がある管理職・ＩＴ技術者
	委任型の依頼スタイルに必要なスキルとメンタリティに興味がある管理職・ＩＴ技術者
	設計結果を手順で表現するスキルレベルからの脱却を目指すシステムエンジニア

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

人を動かす（依頼する）メカニズムの分析
1. 依頼者と作業者間に生まれる具体と抽象
2. 仕事とは、課題（抽象）を対応（具体）へ変換する活動
部下から見える上司の姿
ソフトウエア開発で人を動かす（依頼する）メカニズムの分析
委任型の依頼スタイルに必要なスキル・メンタリティ

人を動かす（依頼する）メカニズムの分析

依頼者と作業者間に生まれる具体と抽象

他者に何かを依頼する際に、具体的に依頼する／抽象的に依頼する、で得られる効果の違いを考察する。

依頼（指示）の具体度と、その指示がもたらす結果の大きさは、相関関係がある

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

依頼方法の抽象度と、成果物の自由度および期待値の関係は、ピラミッド状に表せる

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

仕事とは、課題（抽象）を対応（具体）へ変換する活動

仕事という課題解決は、基本的に「依頼する ➡ 依頼で動く」関係になるので、「仕事」とは、「課題（抽象）から対応（具体）への変換活動」と捉えられる

変換活動の受渡しの流れをリレーに例えると、全行程の途中のどこかで、依頼者（川上）がバトンを依頼受者（川下）受け渡す。

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

上司が部下に、花見の場所取りを依頼する例で、抽象度が違う依頼方法が及ぼす効果を考察すると、リスクを取らない上司は部下の育成が下手に見える

		具体的な依頼	抽象的な依頼
依頼例
		今週金曜の朝７時から上野公園のトイレの近くで、30人分の花見の場所を確保し、千円の花見弁当と、350mlのビール30本と、ウーロン茶15本を用意してください。	今週金曜の勤務後に、部署のみんなが楽しく参加できる花見を予算3万円で手配してください。
利点	依頼発側	依頼した期待を大きく裏切らない。	依頼した期待以上の成果が出る可能性がある。
			依頼内容を詳細に指定しなくても済む。
			依頼内容の不備に気づいてもらう可能性がある。
			依頼受側の判断力を育成する場になる。
	依頼受側	知識や経験がなくても対応できる。	自由・裁量が大きいとやりがいを感じやすく、期待に応えようと工夫する動機を持てる。
			依頼内容の不備を修正する動機を持てる。
			成功すれば自信や判断力の向上につながる。
欠点	依頼発側	依頼した期待以上の結果は出ない。	依頼の意図が的確に伝わらないと、依頼した期待に対して結果が下回るリスクがある。
		依頼内容を詳細に決める準備作業量が多い。	依頼の意図が的確に伝わらないと、依頼した期待に対して結果が下回るリスクがある。
		依頼内容に不備があると結果に不備が出る。	我慢して見守る姿勢が求められ、見守る過程では大きなストレスを受ける。
		依頼通りの進行かを適宜確認し、状況に応じて修正指示などの制御が必要になる。	結果が不調だった場合、依頼した責任を引き受ける精神的強さが必要になる。
	依頼受側	自分への信頼・期待を感じ難く、やりがいを持てず、作業をミス（例：寝坊）するリスクが高まる。	工夫や臨機応変な対応力など、経験値や抽象的な判断力が低いと、期待を下回るリスクが高まる。
費用便益分析		ローリスク・ローリターン	ハイリスク・ハイリターン

部下から見える上司の姿

抽象・具体軸で捉えた「部下から見たよい上司」は、「委任型」「面倒見型」の２タイプある

「上司の指示」と「部下の期待」を抽象－具体軸で分類すると「部下から見た上司」は４タイプに分かれる。

抽象-具体軸での上司の四象限図

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

➡

部下の立場での「よい上司（仕事の依頼者）」は、「委任型」か「面倒見型」。

面倒見型の「よい上司」には肉体上の限界が訪れるので、面倒見型は長続きしない

面倒見型の仕事依頼スタイルは、依頼発側（上司）の準備負荷の高さゆえに次の問題がある。

依頼発側（上司）の作業量の限界がボトルネックになり、大規模な仕事はこなせない。
依頼発側（上司）は慢性的に負荷が高いため、ストレスが臨界点を超えると燃え尽き症候群などになる。
依頼受側（部下）の成長戦略が弱い仕事依頼スタイルのため、依頼発側（上司）の負荷を軽減する見通しが立たない。

面倒見型の仕事依頼スタイルを続けると　⇩

面倒見型の依頼発側（上司）が負荷過多で燃え尽きたり、辞めたりして、仕事自体の継続が難しくなる。

こんな状況への転落を回避するために　⇩

面倒見型の依頼発側（上司）の負荷を軽減する手段は、究極的には仕事の総量削減しかない。
	とはいうものの　⇩
	軽々な仕事量の削減は、会社の経営状況によってはダメージが大きく、倒産するリスクが高まる。
	つまるところ　⇩
結局「委任型」の仕事依頼スタイルを早期に確立できない職場は、将来の見通しを持てない死の行進が続いて衰弱する。

ソフトウエア開発で人を動かす（依頼する）メカニズムの分析

「課題（抽象）➡ 対応（具体）」の視点で、ソフトウエア開発の設計スタイルを評価すると、ソフトウエア開発現場の多くが委任型の依頼スタイルを確立できていない

ソフトウエア開発の、依頼者＝設計者、依頼受者＝プログラマを位置付けて考えると、

死の行進から抜け出せないソフトウエアの開発現場の多くは、委任型の依頼スタイルを確立できてない。

設計の表現方法を「具体」「抽象」の視点で類型化し、各設計スタイルの利点・欠点を分析する。

設計の表現方法		具体的な設計スタイル	抽象的な設計スタイル
設計の表現方法		開発する機能を、操作方法（例：命令語）を羅列した処理手順で表現した設計。	開発する機能を、出力に期待するデータを中心に表現し、その出力に至る詳細な処理手順を並べた表現は極力排した設計。
利点	設計者	成果物の品質が設計者の期待を大きく裏切らない。	設計内容を詳細に指定しない分、設計作業の生産性が高まる。
			プログラマに設計思考を期待する分、設計者が見落とした不備に、プログラマが第三者視点で気づく可能性がある。
			プログラマが仕様理解を深める結果、想定した期待以上の成果品質をプログラマが出す可能性がある。
	プログラマ	業務知識や仕様の理解度が低くても対応できる。	自由・裁量が大きいとやりがいを感じやすく、期待に応えようと工夫する動機を持てる。
			設計の不備を修正する動機を持てる。
			成功すれば自信や判断力を中心とした能力向上につながる。
欠点	設計者	設計した期待以上の結果が出ることはない。	設計の意図が設計書で伝わらず、成果の品質が低いと設計者が責任を問われる。
		実装方法を詳細に設計する作業量が多い。	設計内容を（手順の羅列にせず）、実装時の要点を見通し、出力への期待を主に自然言語で表現するコミュニケーション・スキルが求められる。
		設計内容の不備が、成果の低品質に直結する。
	プログラマ	自分への期待が低いと感じ、やりがいを持ち難い　➡　単調作業化しやすい　➡　不具合混入に気付かないリスクが高まる。	経験値や抽象的な判断力が低いと、低品質な成果を産むリスクが高まる。
イメージ
イメージ		【画像出展】イラストＡＣ
💀 デスマーチ		死の行進が続くソフトウエア開発現場は　⇩	ソフトウエア開発現場がデスマーチに陥おちいりにくく、陥っても復元力レジリエンスがある。
		設計者に負荷が集中し、負荷過多で設計作業の品質・生産性が低下こそすれ向上はしない。
		プログラマ（または発注先）が実装作業に意欲を持てず、成果物の品質を向上させる動機が弱い。

死の行進から脱却できないソフトウエア開発現場に共通する特徴を整理すると、高度な設計者の人材不足に帰着する

低品質な成果物の責任を追及されるリスクから、設計は具体的に示す方が安心との保守的な信仰が強い。	➡	抽象的に設計するスキルを持つ高度設計者を育成できず、高度設計者の人材不足が続く悪循環に陥っている。
具体的で詳細なほど有用な設計表現方法と信じ、抽象的な設計はただ誤解を招くだけの冗長で高コストな表現方法と見做す価値観が組織を支配している。
抽象的に思考し、抽象的に表現する設計技術は、論理思考力＋象徴表現力＋言語化力の兼ね備えが求められて難易度が高く、高度な水準に到達している人材が極端に少ない。
抽象的な設計技術の習得を、もっぱら個人のセンスと経験に頼り、組織的な技術習得に向けたロードマップがない／弱い。

委任型の依頼スタイルに必要なスキル・メンタリティ

ソフトウエア開発で委任型の設計スタイルへの転換で必要なスキル・メンタリティは、設計者とプログラマでは異なり、それぞれを共に持つ必要がある

役割		必要なスキル・メンタリティ
設計者		開発する機能に期待される上位（本来）の目的の要点を短文で表す要約力がある。
		開発する機能を、手順での説明に頼らず、期待する出力データの説明で表現できる。
		機能の本来の目的から、自分内の引き出しに持つ対応手段から最適解を選択できる。
		抽象的な表現に相応しい用語と、具体的な表現に相応しい用語を使い分けできる。
		実装時に陥りやすい失敗パターンと注意すべき難所を看破できる。
		丸投げはしないが、実現手段の設計をプログラマに任せる勇気を持てる。
プログラマ		開発する機能に期待されている本来の目的を簡潔に説明する理解力がある。
		入力データから出力データを作る手段・手順を考案できる。
		開発する機能の本来の目的と照らして、入力データの過不足を看破する判断力がある。
		入力データと出力データの値域に含む “意味” に曖昧さがあれば、明文化できる。
【参考】設計の基盤となる抽象化能力

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

次回は「ソフトウエア設計書に描きたい項目」を解説します。
ソフトウエア設計シリーズの目次はこちらへ

技術者のスキルを伸ばす設計書とは－ソフトウエア設計シリーズ「破」⑥