「設計の理論」の版間の差分

本ページでは現状では参照していない文献ですが（2022年1月25日）、設計の理論を紹介していると思われる関連文献として『岩波講座 現代工学の基礎』があります。ある程度、設計についての抽象的な説明があるかもしれません（たとえば『岩波講座 現代工学の基礎〈1〉設計の方法論』（2000/5/10）あたり）。 しかし岩波のこの本はそんなに厚くないし、ソフトウェアも含めては説明していなかったかもしれません（手元にないので確認できません）。

 

集団でソフトウェアを作るとき、そのソフトウェアのビルド方法を仕様書に書かないといけません。（これは製造業の設計図などには無い、IT業界の独自の事情です。）

 

 

 

* 設計図（これは完成予想図である必要があります）

* 部品と機能の対応表（メンテナンス用です）

}}

 

では「設計図」とは何かというと、製造業の場合での「設計図」の意味を説明すると、それは「完成予想図」です。「完成予想図」というところがポイントで、実は生産方法などは指定していないのです。なので設計図だけでは、実は何も生産できないのです。

 

 

 

 

という状態にまで、部品図と組立図の状態をそれぞれ完成予想図の形で書き上げていくのが、図面を書くという事です。

 

 

もし、納品される品物が仕様を満たしてない場合、けっして合格品としてはいけず（つまり「検収」してはいけず）、（発注者は）協力会社に作り直しを要求します。この仕様違反のさいの作り直し要求はIT業界にかぎらず製造業<ref>澤田善次郎 監修・ 名古屋QS研究会 編 『実践 現場の管理と改善講座 09 試験・計測器管理 第2版』2012年4月25日 第2版 第1刷発行、114ページ</ref>でもどこでも、受け入れ検査は通常、そういう仕組みです。

 

ソフトウェアを作る場合も、最終的に製品の完成の段階では、最低限このような水準にまで、設計図を作りこんでいきましょう。（ただし、ソフトウェアには「寸法」など形状の条件は無いので、そこはアルゴリズム的な条件に意味を読み替えること。）

 

製造業では図面をもとに見積もりをします。基本的に技術系の業界では、設計図をもとに見積もりが行われるます。

学生は企業社会を知らないと思うので説明しますが、コンピュータ業界にかぎらず、そもそも製造業なども含む技術系の業界で、設計から生産までの流れがどういう工程で行われているか、説明します。

 

まず、なにかの設計図では、具体的な生産方法は指示しません。たとえば、組み立てた後の形状がどうなってるかは組立図（くみたてず）に描いても、しかし、「どうやれば組み立てられるか？」とかの情報は一切、そういう事については『設計図』では指示しません。

 

 

こうすることで、分業もしやすくなり、一石二鳥です。

 

 

=== あいまいさを無くすのが設計図 ===

基本としては、設計図とは、設計図だけを見ても、あいまいさの無い状態で完成品の満たすべき具体的な条件が分かるようにしなければなりません。

 

さて、製造業などでも、「図面」という完成予想図があります。

よく、IT業界でいう「現場で見つかった仕様書の不具合を仕様書にフィードバックする」とか言う表現は、おそらく完成予想図のような書類のことを指していると思います。

 

 

 

 

 

さて、IT業界の場合、末端の部品プログラム完成予想図を描く前に、普通の設計では既にフローチャート図または状態遷移図などといった、全体的なシステムの図面を書くのが望ましいとされています。（以降の説明では、言い回しの省略のため、フローチャート図または状態遷移図を単に『フロー図』または『フローチャート図』と略記する。）

 

 

なお、もしかしたらIT業界でも、状態遷移図やフローチャートを描かないで設計する事態も企業によっては横行しているかもしれませんが（原理的には、状態遷移図やフローチャート図が無くても、エクセルなどで作成した部品プログラム仕様とその組み立て仕様のエクセル形式の完成予想図だけでも、原理的にはソフト設計できてしまう）、しかし、こういう状態遷移図などの画像での説明を省いた設計では設計ミスが発生しやすく、結局、再設計などの手間が掛かってしまうのがオチです。

 

 

 

 

 

なぜなら、開発前～開発中の経緯を、上司や他部署に事後的に報告したり、のちに入社してくる後輩などに教育としてソフト開発時の出来事を教えるためです。

アマチュアのゲーム製作の場合、エクセルまでは不要でしょう。

 

ゲーム産業に限ったことではないのですが、企業でのパソコン内での、ファイル名やフォルダ名の管理手法として、たとえば何かの説明書きのファイルがいくつもある場合、

 

 

 

フリーゲームなどは、あまり説明書が細かくかかれないので、気にする必要はないでしょうが、一般IT企業のソフトウェア説明書や製造業の組み込みソフトなどは、もっと細かく一通りの操作方法を説明します。

 

 

 

 

だから例えば工場の生産ライン用の設備に組み込まれてる組み込みソフトの説明書なら、その説明書の文面は、工場で下書きしてるわけです。

 

 

 

 

しかし、それは新人特有のよくある勘違いなのです。説明書を書く場合にも、実機でテストプレイをするべきなのです。

 

 

===== 組み込みソフトの場合の手順 =====

大まかなページ数などの仮決めのために、仕方なく仕様書を見ながら、仕様書から想定されるハズの操作方法を書きます。

 

 

ですが、この想定した操作方法は、まだ何のテストもしてないので、高確率でミスが含まれています。

なので、下書きした説明書のプロトタイプと筆記用具（赤ペン）を持ちながら、実機のある現場に移動して、到着したら実機で説明書どおりにテストプレイしながら（絶対に説明書を見ながら、杓子定規に説明書どおりにプレイします）、実機操作中に発見した説明書のミスを、赤ペンで下書き説明書に、追記でメモ書きしていくワケです。

 

 

 

また、組み込みソフトの説明書を書く技術者は、工場の組み込みソフトを書くなら、技術書の服装としてはブルーカラーの作業着で仕事してるわけです（背広ではないです）。作業着でないと原則、現場に入れないので

このような仕事を、よく新人がやらされます。

 

 

同様の理由（消費者目線）で、説明書を書く仕事も、どこの業界でも、新人がよく説明書を書かされます。

ああいう子供口調やら女口調の説明書は、集団作業の場合なら、下書きの段階での口調は、普通のビジネスマン的かな書類の口調で書いているか、たとえ　くだけた職場の場合でも普通の大人のくだけた口調で書類を書いているのであって、あとの工程で口調だけ入れ替えて子供口調や女口調に入れ替えるという手間を掛けています。けっしてイキナリ、子供口調とかで書類を書きはじめるわけではありません。

 

{{コラム|失敗学|

失敗は無数にパターンがあるので、すべての失敗を学ぶことはできません。

 

 

{{コラム|アブストラクト|

欧米の経営者が、経営哲学でよく「目標はすべて実現しようとするのではなく、優先度の差をつけろ」というのは、おそらく、こういう事を言ってるのでしょう。日本人の知ってる例でも、ソニーの元経営者のハワード＝ストリンガーは「アブストラクトを作れ」と日本社員に言ってたようですし（ここでいうアブストラクトとは、けっして日本語でいう「抽象」ではなく、論文とかの冒頭に書く要点の文を「アブストラクト」と言うように、要点のことであり、つまり設計の際に優先実現したい機能のこと）。米国アップル・コンピュータのジョブスも似たような事を言っていました。

歴史的には、パラメータ・バリエーションの考え方のほうが古く、ストリンガー経営哲学やゲーム調整方法よりも古いですが、しかし歴史の順番どおりに学ぶ必要はないです。学習はたいてい、現代の実務的な方法から学んでいくほうが効率的です。

 

:ちなみに物理学の解析力学という分野にある「変分法」（へんぶんほう）という計算手法を英語でバリエーションというが、しかし、ギルブレスのいう「パラメータ・バリエーション」は明らかに（物理学の）変分法とは別の手法である。

}}

 

 

{{コラム|小室直樹の「二値最適化」の問題|

政治哲学などの格言で「最大多数の最大幸福」という言い回しがありますが（なおこの格言を『ベンサムの功利主義』という）、しかし京都大学の数学科出身の経済学者・政治学者の故・小室直樹の著書によると（経済評論の書を多く出している）、これは数学的にはありえないとの事です。

}}

 

 

== メンテナンス用の書類の概要 ==

完成形をつくるだけの「設計図」的な「仕様書」だけでは、バグ発生時や設計ミス発生時などのさいの修理が不可能です。

 

 

前任者が会社を辞めてしまっている場合などもあるので、色々と書類が必要でしょう。こういうことから、もし下記のような資料が無いと、不具合の発生時に、修理のための設計変更で、どこをどうイジればいいか特定できず、困ります。

「部品と機能の対応表」のことを、IT業界で何と言うのか、このページの著者は知りません。しかし、ともかくそういう対応表がないと、メンテナンスが後々に困難になります。

 

=== なぜ書くのか ===

発売後の（一般のIT企業では）ソフトにも、修理・メンテナンスが不可能になる場合があります。

 

 

システム構造を解説するには、要するに変数名や関数名や、モジュールが、設計図に示した設計意図にどう対応しているかを、記載できれば良いのです。こういった大目的をまず忘れないようにしましょう。

 

なお、この「コード解説書」書類の呼び名は特に決まっていません。呼び名が無いと不便なので、とりあえず「コード解説書」と呼ぶことにします。

 

まず、ソフトウェアのシステム構造を解説する場合、どのファイルがエントリポイント（コンパイル時に最初に呼び出されるファイル。Main関数などがある）なのか、そういうことから、コード解説書に書いてください。

 

このほか、どうしても「System.cpp」とかのような漠然とした名前のファイルがある場合、何のシステムなのか、わかるように書いてください。（そもそも、そういう漠然とした名前を避けたほう安全ですが。）

 

たとえばRPGを作るなら、

 

とにかく、それぞれの書類で説明が他書類と重複していて説明文がやや増えても、説明の多いぶんには、デバッグが効率化するので問題ないのです。仕様書の分野では、説明の「大は小を兼ねる」です。

 

後任者が、仕様書や「要件定義書」や「○○設計書」などの各種の書類などを読むのは、仕組みを把握したり完成目標を確認する理由のほかにも、前任者の開発の経緯やそれにともなう思考の経緯を知りたいという理由もあります。

 

 

 

この手のメンテナス資料でよくあるトラブルが、退職エンジニアの資料紛失です。