ソフトウエアという「形がなく」「目に見えない」モノを作るときは、実在しないモノのイメージを想い浮かべ、その実現方法を工夫・考案する。
形がないモノの、イメージの想起や実現方法の考案は、「ソフトウエア設計」活動の中核に位置する。
イメージ形成力が重要な「ソフトウエア設計」活動は、脳を十分に働かせて思考する高度に知的な活動だ。
伝統文化の茶華道・武芸・職人技を極める成長のプロセスは「守・破・離」-最初は教えを忠実に守り、やがて教えを基盤に置いて応用し、最後は教えを離れて創造する-のステップを踏むと、千利休(戦国時代の茶人)が言ったという。
経済産業省の独立行政法人 情報処理推進機構(IPA)が、「組込みソフトウェア開発」に必要なスキルを体系的に整理した指標『組込みスキル標準(ETSS)』でも「守・破・離」を採り入れている
本シリーズを通じ、ソフトウエア設計スキルの向上に取り組む技術者へ、「脳の使い方」のヒント提供を目指す。
記事の音声解説付き(下のプレイボタンで解説開始)
思考品質とその評価軸
「ソフトウエア設計」活動は、脳を十分に働かせて思考する。
脳の使い方には上手/下手があり、これを『思考品質』と呼ぶことにする。
「具体化力⇔抽象化力」を軸とする思考品質の高低は、たとえば次の軸で評価できる。
| 知恵溜の凝集塊 | 手順 | メタ情報 | メタな “メタ情報” |
|---|---|---|---|
| 成長段階 |
守 | 破 | 離 |
ソフトウエア設計シリーズ記事の構成
ソフトウエア設計シリーズの記事は、成長段階と対応する層別に構成する
| 層 | 序(定義) | 守(基盤) | 破(応用) | 離(自在) |
|---|---|---|---|---|
| 概説 | ソフトウエア設計技術の成長で前提となる用語「設計」を定義する。 |
長期に渡って価値を維持するソフトウエアを設計する活動を整理する。 |
意図志向の設計書で、理解者を増やして情報を共有する。 |
ソフトウエア以外の知恵溜も利用してシステムを革新的に発展する。 |
ソフトウエア設計シリーズの記事一覧
記事を層で区切り、記事の概要を紹介するリンク集を以下に示す。
興味ある記事は、各記事のリンクから閲覧いただきたい。
序
| 序(前提) | ||
| 記事のタイトル | 記事のポイント | 対象読者 |
|---|---|---|
| ソフトウエアの設計とは | 「設計」という用語は人によって捉え方が違い、「設計活動」の実体は会社・組織・個人ごとに異なっている。 | ソフトウエアの設計とは何かを知りたい方 |
![]() |
ソフトウエアを設計する際の「考え方」に興味があるIT技術者・システムエンジニア | |
| ソフトウエア設計結果の「言語化」「文書化」に興味があるIT技術者・システムエンジニア | ||
守
| 守(基盤) | ||
|
開発完了後に長期に渡って価値を維持する(寿命が長い)ソフトウエアを開発する技術者には、システム思考が求められる。 |
||
| 記事のタイトル | 記事のポイント | 対象読者 |
|---|---|---|
| 守① トップダウン思考 | 優れた設計技術者は、大枠の思考から設計に取り組み、大規模・複雑・高度なシステムを作る。 高度なシステムの設計には、脳をどう使えばよいのか。 |
トップダウン思考に興味がある方 |
![]() |
脳の特性とボトムアップ思考の相性に興味がある方 | |
| モノ作りの基盤となる思考方法に興味があるIT技術者・システムエンジニア | ||
| 守② 段階的に詳細に | システム全体を把握するコツは、トップダウンに「思考」し、段階的に「詳細化」した構造を作って、「考える難易度」を下げること。 | 段階的詳細化に興味がある方 |
![]() |
システム思考に興味がある方 | |
| トップダウン思考で進む「自動車システム」開発の設計技術に興味があるIT技術者 | ||
| 守③ プログラミング言語 | プログラムという用語は知っていても、具体的なイメージまでは知らないという方が、その本質を理解できるよう、「プログラムが持つ特徴」を解説する。 | コンピュータのプログラムと設計の関係に興味があるIT技術者・システムエンジニア |
![]() |
コンピュータのプログラムが実際にどんなものか興味がある方 | |
| コンピュータのプログラムに不具合が多い理由に興味があるIT技術者・システムエンジニア | ||
| 守④ プログラム設計の誤解 | 設計工程には、目的の製品プログラムではなく、「作るモノの有様と作り方」を示した『設計書』が、求められている。 | コンピュータのプログラムと設計の関係に興味があるIT技術者・システムエンジニア |
![]() |
ソフトウエアの設計書の作り方に悩んでいるIT技術者・システムエンジニア | |
| ソフトウエア開発の現場での価値ある設計書に興味があるIT技術者・システムエンジニア | ||
破
| 破(応用) | ||
| IT技術者に求められる基盤能力の「抽象化思考力」は、情報を圧縮してモノゴト全体を俯瞰する技術に辿り着く。 大規模なソフトウエアを明解に設計するIT技術者は、問題・課題の解決に向け、まず問題・課題を抽象化(モデリング)した上で、解決策を考える。 考えた解決策(設計結果)を伝えるスタイルには、「結論志向」と「意図志向」の二通りの方向性がある。 技術者がモデリングして設計する思考の先に「意図志向」で表現する理想的な設計書が結実する。 |
||
| 記事のタイトル | 記事のポイント | 対象読者 |
|---|---|---|
| 破① 設計の基盤となる抽象化能力 | 優れた設計者の基盤にある「抽象化する思考力」とは、雑多な情報を圧縮してモノゴトを俯瞰する思考技術だ。 | 設計者に期待される活動内容・思考方法に興味があるIT技術者・システムエンジニア |
![]() |
表面に見えない関係を視える化する思考方法に興味がある方 | |
| 抽象化と言語表現の関係に興味がある方 | ||
| 破② ベテラン設計者の思考プロセス | 大規模なソフトウエアを明解に設計する技術者の脳内では、「把握」➡「抽象化」➡「作戦模索」➡「具体化」の順に思考が進む。 | 優れた設計者が問題解決する際の「脳内の思考の流れ」に興味があるIT技術者・システムエンジニア |
![]() |
モデリング作業の進め方に興味があるIT技術者・システムエンジニア | |
| 問題を抽象化して課題と捉え、対応の要点を絞り込むノウハウに興味がある方 | ||
| 破③ 上流設計の思考プロセス |
上流工程の設計は、抽象化した課題を入力として、対策を出力する活動。 |
問題や課題を解決し易くするための「見方」「捉え方」に興味がある方 |
![]() |
設計者が問題・課題を解決する際の脳内の思考の流れに興味がある方 | |
| 抽象化した課題への対応で、要点を絞り込む対応方法に興味がある方 | ||
| 破④ 「境界線」をどこに引くか | 良い設計と判断する最強の基準は「最適なバランスの位置に境界線を引く」分割指針。 産業用ロボット業界で磨き上げられた「モジュール化」の設計思想に、ソフトウエアの設計に応用できる合理的な分割指針を見つけた。 |
「良かれと思った共通化設計」が、のちのち足かせになったと後悔している設計者 |
![]() |
設計構造論は理解していても、現実に「どこまで細かく分ければいいのか」に悩む設計者 | |
| 設計の根拠を「物理的な構造の合理性」など納得感のあるアナロジーで説明したい設計者 | ||
| 破⑤ ソフトウエア設計のコツ |
脳を効率的に使うソフトウエア設計のコツを豊富な事例とともに解説する。 |
設計思考のPDCAサイクルに興味がある方 |
![]() |
ソフトウエアの設計の『思考スキル』『思考テクニック』に興味がある方 | |
| ソフトウエアの設計思考の『七つ道具』『三種の神器』『鑑定眼』に興味がある技術者 | ||
| 破⑥ 技術者のスキルを伸ばす設計書とは | 超多忙の泥沼から脱却できないソフトウエア開発現場には共通する特徴がある。 カギは「任せる勇気」を持つ管理者・設計者だ。 |
依頼する相手に前向きな取組みを促す「依頼スタイル」に興味がある管理職・IT技術者 |
![]() |
委任型の依頼スタイルに必要なスキルとメンタリティに興味がある管理職・IT技術者 | |
| 設計結果を手順で表現するスキルレベルからの脱却を目指すシステムエンジニア | ||
| 破⑦ ソフトウエア設計書に書きたい項目 | 設計書に「重要な/記載が望ましい」要点を、抽象的な「レビュー観点」として示した上で、具体的な確認項目例に落とし込んでみた。 | どのようなソフトウエア設計書を作るべきか模索しているIT技術者・システムエンジニア |
![]() |
ソフトウエア設計書のレビュー項目を検討している品質管理者・IT技術者 | |
| 分かりやすい技術文書を模索している方 | ||
離
| 離(自在) | ||
| 抽象思考の熟練度が高く、抽象度が高い階層でバランスよく思考できる。 得意分野や専門分野の枠に捕らわれず(たとえば二次元バーコードの設計に、囲碁の格子を取り入れるとか)、幅広い視野で柔軟に思索して、対応方法を革新的に考案する。 革新的な価値を創造する設計者は、AIを外部の知恵溜として使い倒す応用自在なオールラウンダーとなる。 |
||
| 記事のタイトル | 記事のポイント | 対象読者 |
|---|---|---|
| 離① 抽象思考による「上から目線」の光と影 | ヒトが成長過程で徐々に発達させる「抽象化思考力」の基盤はコトバの量(語彙力)。だがコトバが持つ「あいまいさ」は意思疎通に失敗する原因ともなる。 | ヒトが抽象的にモノゴトを視る能力を獲得した進化に興味がある方 |
![]() |
抽象的にモノゴトを視る能力が段階的に上がるヒトの成長過程に関心がある方 | |
| 抽象的な思考が併せ持つリスクへの考慮が求められる高度なIT技術者 | ||
| 離② 応用自在な設計者の生活習慣 | 優れた設計者は知的好奇心が強く、新たな情報や状況に接すると、「なぜ?」「何のため?」に興味が向いてしまう「思考癖」を持つ。 | 意図志向の設計者が情報を整理する方法に興味を持つIT技術者・システムエンジニア |
![]() |
より高度な設計スキルの内容に興味を持つIT技術者・システムエンジニア | |
| 設計スキルの向上方法に関心があるIT技術者・システムエンジニア | ||
| 離③ ITコンサルタントの思考スタイル | 多彩な経歴から「問題解決のヒント」の引出しが豊富で、的確な対策を提案できるITコンサルタントは少ない。 ヒントの引出しを増やすには、抽象的な思考力が基盤になる。 |
ITコンサルタントの思考スタイルに興味がある方 |
![]() |
抽象思考のための脳の使い方に興味がある方 | |
| 的確な対策を提案するために、ヒントの引出しの拡張・質向上を考えるITコンサルタント | ||
| 離④ 階層的な問題解決 | コンサルタントが「具体」➡「抽象」➡「具体」と階層を跨いで提案を紡ぎ出す思考プロセスを、身近な事例で考察する。 |
階層的な問題カイゼン・解決に興味がある方 |
![]() |
問題・課題の解決の三つのプロセスに興味がある方 | |
| 階層的な問題カイゼン・解決の具体的イメージに興味があるITコンサルタント | ||
| 離⑤ コンサルティング品質の決め手 | コンサルタントが提供する「コンサルティングの品質」とは何か、コンサルティング品質の「評価基準」を具体例を交えて考察する。 |
コンサルティングの品質に興味があるITコンサルタント |
![]() |
高品質なコンサルティングに必要な知的能力に興味があるITコンサルタント | |
| コンサルタントを評価する基準に興味がある方 | ||
| 離⑥ 知の水準と抽象化能力-AIを使いこなす設計者とは | 開発中 | 近日公開 |
| 開発中 | 近日公開 | |
| 近日公開 | ||



















コメント