足りないのはソフトウェア工学だけ？

工学

@ITの記事に最近（IPA）設立した新組織「ソフトウェア・エンジニアリング・センター」（SEC）に関する解説が載っている。要は SEC の設立の趣旨にある「ソフトウェア開発の問題に対して、世間ではソフトウェア工学的なアプローチが不足しているので、その普及を図っていく」という事に対する疑問が呈してあった。官製主導のソフトウェア産業の振興策には、何かと反発したくなるのは事実だろう。以前 CMM の政府調達への導入騒ぎのようにやはり、現場の問題点を正しく認識せずに突っ走ってしまう部分もある。

・・・・・＜略＞
一方で、ソフトウェア開発にかかわるすべての問題を「ソフトウェア工学」や「方法論」といった“高級な議論”だけに集約させていいのかといった意見もある。このような意見は実装を主な業務としている開発者からよく聞くことができる。「もっと泥臭い問題が現場にはゴロゴロしているのだ」と彼らはいう。いわないまでも心の中で思っている。
　工学的な知見を取り入れた標準的な開発手法の存在はもちろん非常に重要なのだが、そこに現場のノウハウが盛り込まれなければ絵に描いた餅（もち）のままであり、失敗プロジェクトの出来（しゅったい）を食い止める防波堤になりはしない。
（@IT NewsInside ［Analysis］ 足りないのはソフトウェア工学だけ？ より引用 ）

だからといって、私にはこれはちょっと乱暴な意見に聞こえる。今の日本のソフトウェア産業の現場は全体的に見て、自浄作用がかなり低いのではないかと思う事も多い。*1 デスマーチの現場では労働基準法違反を通り越して、ほとんど奴隷制度のような勤務状態の中、粗悪な品質のソフトウェアが世の中に出され続けているのが現状である。ソフトウェア工学ほど実社会にその成果が還元されていない工学は無いと揶揄されているが、これは工学的なアプローチに対して頑な現場や商業的な理由で UML とか MDA 等の大げさな方法論やツールを煽ってきたマスコミだって悪いんじゃないかな。
上記の記事には、

  1. 官製の SEC に対する反発
  2. ソフトウェア工学に対する誤解に基づく反発

の２つが有るように思える。最初のものについては致し方ない部分もあるが、２番目については「突っ込み」を入れたい。特に

ソフトウェア開発にかかわるすべての問題を「ソフトウェア工学」や「方法論」といった“高級な議論”だけに集約させていいのかといった意見もある。

の部分については、ソフトウェア工学とは何かという認識を明確にしないままに思い込みだけで書いている節がある。何が「高級」なのだろうか、UML や MDA、CMM、SCRUM といった「方法論」って書いたら気取っているとでも言いたいのであろうか。工学である以上どのような形で進めるにしても、ベースに考え方の上に、具体的な手順を体系化して行くのは当然だと思う。それらを考えるなら、やはりそれは「方法論」になると思う。現場のノウハウ・経験的知見を盛り込むにして、特にソフトウェアのような抽象度の高い生産物の場合は、幕の内弁当ではなく、やはり何らかの一般化を行いながら、その本質を探り、できるだけ多くの分野に応用できるようにする事が大切だと思う。「工学」ってそういう事でしょうに。
また、泥臭い現場の問題と言うが、ソフトウェア工学にもテストや保守工程の改善、実際のプロセスのフォローレビューのような地道な調査作業を要するどちらかと言うと泥臭い分野はある。泥臭い物を泥臭いままにしておくか、そこを根気よく考察を進め、何か新しい考え方や役にたつ知見を引き出すのか。何のためのソフトウェア工学か、やはり誤解されているような気はする。

以前、２年ほど前に大阪の京橋で XP(eXtreme Programming) やアジャイルプロセスに関するシンポジウムがあった。その中で Kent Beck による XP の解説があった。今はどうなっているのか知らないが、その頃 XP といえば４つの価値と１３のプラクティスに特徴される、設計を軽くして、実装とテスト工程を極端に重視する個性的なプロセスと言う認識があった。提唱者のスピーチなので当然、そうした事柄の話になるのかと思ったら、約２時間の講演のうち具体的な ４つも１３ も XP の特徴に関する説明は後半で軽く触れる程度しかなかった。パワーポイントの原稿も表紙もいれて高々１０枚程度しかなく、しかもその殆どは簡単な箇条書きと線画であった。講演は

  • More Inventory → Less Feedback → Reduced Economy → Economy of Scale → 最初へ：従来（Waterfall）
  • Less Inventory → More Feedback → Reduced Waste → Reduce Predictablity → 最初へ： XP の理想

といった２枚の簡単なノートを中心に、ソフトウェア開発において、成果物はどういったものなのか、変更に対応するにはどうしたら良いかといった考察をじっくり説明したものだった。成果物（仕様書、設計書からバグレポートまで）をたくさん作るからフィードバックが減り、変更に追従できず、コストが上がる。だから成果物は（コード、テストケース、日毎の実行モジュール）程度にして、コミュニケーション・フィードバックを強化すれば、より確実性が増すだろう。そういった XP に至るまでの思索の過程も含めて、基本的な考え方についての説明であり、非常に面白かった。今では XP のトレンドは全然追っかけていない。４つの価値観も、１３のプラクティスも多分に色々と変っているだろう。そう発展途上だからそうなるのは当たり前である。表面的な知識で事の正否を決めるなら、混乱しているように思うだろう。しかし上記の XP に至る、Less Inventory の循環については変っていないと思う。ここが XP の本質的な部分なのだろうし、これは良い意味での「工学」だと思った。その本質から実際の現場に合わせてどう展開していくのかはやはり現場ごとに違ってくると思うが、単なる知識や暗記物でなく、合理的に考える基準を与えてくれるからである。

実際に XP やアジャイルが今のソフトウェア工学の中でどのような位置付けなのかははっきりと把握しているわけではない。多分に反論や疑問も多いだろう。しかし基本的に筋の通った考え方が基盤にあるので、公平な視点で論議をすすめ、そこから新しい物を見出す事も可能だと思う。それが「工学」の本来の姿だと思う。決して作業者を無意味に縛り付けるための教義や法律ではないと思う。

表題の通り、確かに「足りないのはソフトウェア工学だけ？」と言う問いには同意したい。しかし何が足りないかと言われれば、それは多分、「ソフトウェア工学」以前の基本となる「工学」的なものだと思う。

*1:別に現場の方々が悪いと言っているのではない、産業を取り巻く社会的な情勢や個々の会社の経営環境、そして社会的な教育環境に大きく影響される部分もある。