from a high Tar projects

ドキュメントがなくてもシステムはできることもある

「ソフトウェア工学」ということが定義されて何年も経つというのに、現場ではあいかわらず作業員の能力にたよりきりである。例えば、単体テスト項目票が起票されない組織、いやもっといえば故障表や詳細設計書も満足に作成されていない組織も多いはずである。なぜこのようなことになるか。理由は簡単である。それでもうまくいくことがあり、その場合の生産性はきわめて高くなるからである。少々めちゃくちゃでも、能力の高い作業者が作業することで大変な効果をあげることがある。故障票がなくても詳細設計書がなくても、単体テスト項目票がなくても、能力や経験があれば何とかなってしまう場合があるのだ。だから、システム工学などの学者たちが考え出した仕組みを学習することよりも、場数を踏ませることを重視するようになる。

「ソフトウェア工学」はどんな人がやっても一定の成果をあげることができるようにするためのシステムである。しかし、そのようなことはないがしろにされやすい。なぜなら、私達の仕事は常にコスト（生産性の向上）に追われているからである。システム工学を導入しようとすればかなりのコストがかかる。そして成果が上がるまで時間がかかる。しかも、能力があればあまり必要がないとなれば、誰がそんなことをやろうとするだろうか。特にそれらの導入に反対しようとするのが、さきほどの何でもできてしまう経験者なのである。彼らが「ソフトウェア工学」を無駄だと考えるのは、さほど不自然でないと私は思う。

もっと「ソフトウェア工学」に対する障害をあげたい。ようするに上記のような組織は管理がほとんど行われていないので、きわめて作業者にとっても自由だということである。つまり監視されていないので好き勝手にできる。だから、能力のある人にとってはさまざまな実験的な手法や新たな技術をどんどん取り入れやすい。いいものさえあげればなにもいわれないからである。一方、「ソフトウェア工学」はシステムという標準を規定する。それは上のような組織の作業者にとっては「押し付け」に映る。いったん走り始めた標準は一人歩きしてしまうことが多く、無駄な作業に時間を取られることも少なくない。（例えば仕様書の文章はXXXでなければならないとなっていたがゆえに、すべてを書き直す羽目になったなど）こんなものはたんなる管理者の自己満足ではないかと疑うのも当然ではないだろうか。

だが、私はそれでも「ソフトウェア工学」が重要であることには変わりはないと思う（問題は多いと思うが）。それには2つの理由がある。ひとつはプログラミングが生まれつき持つセンスによって出来が違うなんていう考えが正しくなく、プログラミングの善し悪しはたんに定められたルール（これは公共のマナーとほとんど同じである）に従っていればよいと私が確信したからである。もう1点は、一つのシステムには複数の人たちが関わらなければならないということである。それはたんにプログラムを作ったり仕様書を書いたりする人が複数いるというわけではなく、顧客や保守担当者、管理者、実際のユーザー、営業担当者などさまざまな人が関わらなければならないからである。詳しくは次回以降に述べたい。