理系白書から考えるソフトウェア工学

理系白書には、何しろたくさんの研究と研究者が登場する。研究者達の苦労や待遇、評価の低さについての現状についても興味深く読んだが、自分はこの本が訴えたい内容とは別のところで考えさせられることがあった。

それは同じ理系でも自然科学と情報工学・ソフトウェア工学では、導かれた成果の性質や寿命がかなり違うのではないかということだ。

Wikipedia で「工学」を引くと冒頭に次のような定義が書いてある。

工学（こうがく、engineering）は、科学、特に自然科学の蓄積を利用して、実用的で社会の利益となるような手法・技術を発見し、製品などを発明することを主な研究目的とする学問の総称である。大半の分野では数学と物理学が基礎となる。

工学と理学の違いは、理学がある現象を目の前にしたとき「なぜそのようになるのか?」を追求するのに対して、工学は「どうしたら目指す成果に結び付けられるか」を考えることにある。

また、自然科学については、次のように書いてある。

自然科学（しぜんかがく、natural science）とは、科学的方法により一般的な法則を導き出すことで自然の成り立ちやあり方を理解し、説明・記述しようとする学問の総称。

自然科学の法則は寿命が長い。きちんと証明されると訂正されることはほとんどなく、自然科学の法則同士に矛盾も生じない。自然科学の研究の根拠となるデータがしっかりしていれば疑いの余地がないことが多い。

工学（エンジニアリング）は科学、特に自然科学の蓄積を利用して、実用的で社会の利益となるような手法・技術を発見し、製品などを発明することを主な研究目的とする学問だとすると、ソフトウェアエンジニアリングの何の科学の蓄積を利用していると言えるのだろうか？

プロセッサの構造や電気的特性にまでさかのぼれば、物理学や化学が関係してくると思うが、ソフトウェア工学がテーマとして扱っているのは自然科学から遠いところの話がほとんどではないかと、理系白書を読んで思った。ようするにソフトウェア工学が扱っている対象はなく突き詰めれば人間ではなかろうかということだ。

無理矢理自然科学に結びつけるとすれば、人間の頭の中、脳の情報処理の生化学となるのだろう。でも、脳神経の生化学的な研究と、脳の情報処理の仕組みとの関係はまだまだ解明できていないことが多く人間が考えること、考えるしくみを自然科学で十分に説明できるところまでには至っていない。（そうはいうものの『考える脳 考えるコンピューター』ではかなり踏み込んでいる）

そうなると、工学が実用的で社会の利益となるような手法・技術を発見することが目的であり、ソフトウェア工学に至っては、よりどころになる自然科学の法則がほとんど使えず、思考や行動が必ずしも論理的でない人間を研究の対象にするしかないということになる。

そこで最初の疑問に戻る。自然科学で解明された法則は安定しており寿命は長いが、自然科学に立脚した説明がほとんどできないソフトウェア工学は必ずしも安定ではなく寿命もそう長くはない（例えば50年以上はもつものは本当に少ない）のではないかと思う。

今、『ソフトウェア・テスト技法』で有名なJ．マイヤーズが1978年に書いた『ソフトウェアの複合/構造化設計』という本を読んでいる。マイヤーズ自身、1974年に書いた著書で「源泉・変換・吸収（STS）型の分割法」だけを紹介していたが、4年後に書いたこの本では、STS型の分割法に加えてトランザクション分割、共通機能分割、データ構造分割といった分割法も紹介している。巨匠と呼ばれる人でさえ築き上げた方法論を何年かたつと修正したり付け足したりすることが分かる。

別な見方をすれば、ソフトウェア工学は対象となる人（エンジニア）の性質や考え方に変化がなければ、構築した法則の寿命は長い。でも、地域による人の考え方の差や気質などが異なると同じ法則が有効に働くとは限らない。もしも、同じ法則がどの地域でもどのプロジェクトでも有効に働いているように見えるのであれば、それは地域や人がその法則を受け入れた、もしくは染まっただけなのではないあろうか。

その見極めをするのは非常に難しい。自然科学がベースにないと、方法論の有効性を検証したデータの再現性は高いかどうかわからない。ある方法論をソフトウェアプロジェクトに適用してよい成果が出たとしても、デマルコが言うようにプロジェクトメンバのそれぞれが失恋して落ち込んでいたり、気になることがあって気もそぞろな状態でデータを取ったらまったく違うメトリクスになるかもしれない。

対象としているのが論理的とは言い難い人なのだからしょうがない。

そうであるなら、ソフトウェア工学は先人の知恵と考えればよいのではないか。先人が失敗したり成功したりして、失敗を繰り返さない、次は効率よく進めようと考え、編み出した先人の知恵、それがソフトウェア工学だと考えるのだ。

そう考えると、その先人の知恵が自分たちにも有効に作用するかどうかという視点で見るようになる。場合によっては、欧米発の先人の知恵は日本では有効に働かないかもしれない。民族の気質が大いに関係するようなアクティビティの実践を促しているようなものは特に気をつけなければいけない。

また、その組織やプロジェクトの気質とは少しずれがあるけれども、先人の知恵に乗っかってやりきってしまうという方法もある。やりきって成功体験となれば、自分たちの気質自体が変わってくることもある。

30年前に書かれた『ソフトウェアの複合/構造化設計』の主張が今でも当てはまるかどうか見てみよう。

「代表的なプログラムで、その構造が設計されているものはほとんどない。その構造は、コーディング途上でそれ独自の方法で作られるのが普通である。」

【コメント】 未成熟なプロジェクトではそのような状況はまだ生きていると思うが、Noと言えるプロジェクトも増えてきてはいるだろう。モデル駆動開発が進めば払拭される可能性もある。

「ほとんどのプログラムは、要件とか環境の変化に対応できないようなつくりかたをされている」

【コメント】 これも同じで、未成熟なプロジェクトではYESと言える。

「プログラムはほとんどの時間をまちがいを修正するために費やしている」

【コメント】 またまた、これも同じで、未成熟なプロジェクトではYESと言える。

「我々は他人の成果を利用しようとはしない」

【コメント】 もろ人間系の問題でその性質は今でも変わっていないと思う。

「n人のプログラマを抱えたプロジェクトは、通常、一つ一つ違ったn個の目標を持つ」

【コメント】 この問題を解決するためにプロジェクトマネージメントの技術が構築されていったのだろう。


ちょっと脱線するが、30年前に J.マイヤーズの『ソフトウェアの複合/構造化設計』 に書かれていることが、21世紀の現代でも未成熟なプロジェクトではほとんど当てはまるというのは一体どういうことだろう。

オリンピック記録は毎回毎回更新され、新しく生まれてきた未来のアスリート達のハードルは自分の意志とは関係なく上がっていく。（こちらの記事を参照のこと）それでもオリンピックレコードが更新されるのは、選手達の努力もさることながら用具の進化、トレーニング技術の進化があるからに違いない。

ではなぜ、ソフトウェアの世界では30年前の憂いが払拭されていないのか？　それは用具（ツール）の進化はあっても、トレーニング技術（教育）が進化していないからではないだろうか。だからこそ、SEESAMEは技術者教育のコンテンツを開発しているのだけれど、教育機関ももっと頑張って欲しい。オリンピックのように多くの人に注目されるような機会がないこともソフトウェア技術者の基礎体力が上がらない理由があると思う。

さて、自然科学も話題に戻ろう。ちなみに、組込みソフト開発では大抵の場合センサやアクチュエータを使う。センサやアクチュエータは自然科学の法則を使ってできているので、センサやアクチュエータの動作について分析・設計するときは人間の曖昧さを考える必要はない。だから、解決の方向性は大抵一つの向きに収束する。でも GUI でどこに何を表示すると使い勝手がいいとか、どんなデザインパターンを使った方が開発効率がいいとかいう議論は好き・嫌いの要素も多分に含まれており大激論になって収束しないことも多々ある。

人間系の問題を考慮しないとソフトウェア工学が効かない理由はこんなところにあるのではないだろうか。

だからこそ、何らかのソフトウェアの方法論を使いたいと主張するときはその根拠を明確にし、関係者全員に共通する価値観をベースに説得すべきなんだと思う。組込み機器開発の場合、その共通の価値観とは顕在的価値と潜在的価値によって満たされる顧客満足であり、顧客満足を高めるために有効な方法論であることを説明できれば受け入れられる確率が高い。別な見方をすれば、商品に求められる価値が違う（例えば業務ドメインや制約条件の異なる）ソフトウェア開発で同じ方法論が有効に作用するとは限らない。

組込みプレス vol.8 の特集記事で書いた、QFD（品質機能展開）を使ったソフトウェア開発の方法論は、市場要求やユーザーニーズを分析して、商品の価値が最大になるような方向にソフトウェアを収束させようとする。これはまさに顧客満足を高めるための方法論であり、商品に求められる価値が異なる、業務ドメインが異なるソフトウェア開発でも顧客満足や商品の価値を最大にできるはずである。

物理法則やコンピュータを相手にしているときは仕事がサクサク進むのだが、相手が人間になるととたんにスピードが減速するように感じる。人相手のときは共通の価値観、共通の目的を一生懸命バックグラウンドで考えているのだが、だからといってうまくいかないこともある。

そんな頭の切り替えを一日の中で何回もしなければいけないからこそ、理系の研究者よりもソフトウェアエンジニアはガス抜きの機会を作らないともたないのではないかと思う。