ソフトウェア開発における知の整理・体系化と伝承
―JSQCソフトウェア部会「遺言」プロジェクト―
（社）日本品質管理学会ソフトウェア部会前部会長
兼子 毅
１．ソフトウェア開発における「知」
日本のソフトウェア産業における主たる生産物は、大きく分けると二種類あるといえるだろう。一番目は、特定の企業の、特定の業務を自動化、省力化、効率化するために開発される受注型業務システムである。これらは、紙媒体の帳票が物理的に部署間を移動しながら、様々な情報が付与されたり、承認されたり、モノが動いたりしながら進められている実際の業務を、完全に、あるいは大部分コンピュータのソフトウェアに置き換えるものである。もう一つは、様々な機械の中にあり、メカニズムやエレクトロニクスの制御を行ったり、簡単なユーザ・インタフェースを提供したりする組込みシステムである。一昔前の自動車では、アクセルペダルを踏み込むと「物理的に」キャブレターの燃料噴射量が変化していたが、いまどきの車では、アクセルペダルは単にボリューム操作のための特別なインタフェースに過ぎず、その踏み込み量を数値化した上で、燃料噴射量を制御している。
多くの開発プロジェクトでは、単純に既存の業務をソフトウェアに置き換える、あるいは物理的なメカニズムをCPUとセンサーからなる制御システムに置き換える、というだけではない。一定の投資を行うからには、単純に省力化、効率化、自動化するだけではなく、何らかの付加価値を与えることが多い。つまり、従来の業務では存在しなかった、あるいは、やりたくても現実的とは言えなかった、何らかの機能や業務が付け加えられていることがほとんどである。
このような開発においては、いくつかの独立した能力が開発者（と発注者）に要求される。
- １） 発注者が自動化・システム化を望んでいる業務・対象の理解と記述
- ２） 発注者が実現を望んでいる「夢」の理解と記述
- ３） 記述された業務や「夢」を実現するシステムの設計
- ４） それらのシステムを実現するためのコストなどの見積もり
- ５） 限定された期間とコストの中で、どこまで業務や「夢」を実現させるか、発注者との交渉
- ６） 合意されたゴールを、定められた期間とコストで実現するための技術とマネジメント
従来ソフトウェア工学、あるいはソフトウェア科学として研究対象となってきているものは、上記の３）、４）、及び６）である。１）や２）も対象となっているが、実世界の本質的非論理性が、その解決を難しくしている。５）は実際のプロジェクト・マネジメントでは極めて重要なポイントだが、ソフトウェア工学などの文脈でまともに議論されていない。
「実世界の本質的非論理性」について、簡単に触れておこう。例えば、獲得した要求仕様の矛盾を示すことは数学的・論理的に可能である。しかしながら、獲得した要求仕様が、現在の顧客業務を正確に反映しているかどうかを数学的・論理的に立証することは、そもそも不可能である。よく使う例なのだが、ある金融機関で「お得意様を優遇します」と言っている。お得意様は誰か？ 何を、どの程度優遇するのか？ これらを聞きとって紙に書き留めたとしても、本当にそのように実際の業務が行われているのかを「論理的に」確かめる手段はない。支店長決裁で「お得意様」認定された顧客もいるだろう。いままでの取引履歴から、一定条件を満足しているにもかかわらず「お得意様」認定されていない顧客もいるだろう。全て「明文化」したルールに基づいて業務を運用しているところは、実はあまり多くない。全てが「明文化」されているわけでもなく、実際の運用ではルールと相反する決定がなされることもあり得る。
それでも発注者は、ありのままの業務を、そのまま自動化したい（もちろん、システム化するにあたって「業務改善」を行う場合もある）のである。特にエンタープライズ系のシステムの場合、どこまでもこのような「実世界の本質的非論理性」がついてまわる。発注者が自らの業務に対して最適化しようとすればするほど、このような問題はあちらこちらで出てきてしまう。しかも、このような「人が『恣意的に』決めたルール」は、極めて簡単に「変わる」。ビジネスの都合、競争相手との差別化、様々な要因が、これらのルールを簡単に過去のものにしてしまう。お金を取れるかどうかは別にして、これらに付き合っていかなければならない。
一方、組込み型システムの開発の場合、相手はもう少し「モノ」寄りであることが多い。このような開発の場合、実時間という制約が問題となることが多い。例えば、自動車エンジンの燃料噴射制御では、おおよそ0.1秒ごとに燃料噴射量を計算しなければならない。しかも一気筒あたり、である。限られたハードウェア性能のもとで、高機能化によって設置された様々な種類のセンサーからの情報を集めて、である。
ソフトウェア開発には、このように、いくつかの「難しさ」がある。現実に、日々進められているソフトウェア開発を的確に行うためには、様々な「知」が必要である。いろいろな教科書もあるが、ほんとうに困ったとき、いざという時に役に立つ「知」は体系化されていない。したがって、教育や伝承も極めて困難である。JSQCソフトウェア部会では、それらの「知」を集め、体系化を試みるプロジェクトを２年ほど前から始めた。その活動の中で私が得た「気付き」をお話したい。
