SWEBOK

http://www.martinfowler.com/bliki/Swebok.html

今月は IEEE による SWEBOK（ソフトウェアエンジニアリング知識体系） のレビュー月間である。これは、我々の専門分野についての知識体系を定義しようという試みで、ライセンス化へ向けての土台となるものだ。

いつもならこういった類のものは無視することにしている。いくつもの IEEE 標準が出されたが、それらは決まって商業ソフトウェア開発者たちに無視されてきた。そういったものは学術的であり、大規模な政府プロジェクトに関わるものだった。ビジネス側の人間は「政府」と「効率的」を同一視していないのである。

しかし、Cem Kaner はこのことを真摯に受け止めている（彼の判断には敬服しているところだ）。彼は blog の中でこう言っている。

SWEBOKがライセンス試験の根拠となるというのであれば、SWEBOKのプラクティスは不正行為訴訟の根拠ともなりうる。SWEBOKにおいて「グッドプラクティス」と呼ばれているプラクティスを実践していれば、たとえ不正行為だと訴えられたとしても、自らの活動を「SWEBOKに従っている」と弁護することができる。逆に、はるかによいプラクティスを実践しながらも、そのプラクティスがSWEBOKと相容れなかったら、法廷で厳しい追求を受けるリスクがある。ライセンス試験の根拠としてSWEBOKをとらえてしまうと、SWEBOKが業界認定のプラクティスであるという公式声明となってしまう。まるでライセンス制の業種のようにだ。

さて、Swebok のどこがダメなのか？ 今月は忙しく、詳しく精査する時間が取れなかったが、ちょっと読んだだけで赤旗を揚げることが出来るくらいダメダメである。Swebok は必要以上に計画駆動開発(plan-driven development)を強調しており、アジャイル手法はまったく認めていないことがよく分かった。

まず読んだのは設計の節である。Swebok は設計をプログラミングとはまったく別の活動であると見なしていることは明白である（アジャイルムーブメントにいる我々とは対照的な見方である）。ここでは、非常に詳細なレベルの設計は、コーディングとテストのインプットとして必要であると提案されている（どれだけ詳細であればよいのかということは、事実上、言及することは出来ないのだが）。

載ってる本の選択はそんなに悪くなかった——GoF本が推薦リストに載ってなかったが 　(GoF本は、重要度が高い『お勧め参考文献』の章じゃなくて、重要度が一段低い『もっと詳しく知りたい人のための参考文献』の章にあった）。

プロセスの節は、測定管理の記述に多くを費やされている。これは本当にダメなことだ。以前、私は、生産性は計測不能だと述べたはずだ。これは科学的管理法を基にしており、プロセス中の人間の役割や人々の相互やり取りについては、完全に無視されている。繰り返すが、「人」や「相互作用」は、「プロセス」よりも勝るのである。これは知識体系の大きな欠陥である。

要求の節では、開発を始めることよりも、理解しやすいシステム要求仕様(SRS)を構築することに集中していた……ああ、またウォーターフォール派かと。（面白いことに、スパイラル型の絵が貼ってある……が、要求仕様のドキュメントを作るだけ！）。要求段階においてコストのトレードオフをあれこれ考えるのは意味がない。要求に不可欠な要素が、きちんと機能するかどうかが大切なのだと思う。

ざっと見てきたたわけだが、いずれきちんと見ることにする。ただ、基本的に Cem Kaner と同意見である。私達の産業は未熟で、こういった知識体系を作ることはまだ出来ない。我々はソフトウェア開発についてまだ学ぶべきことがある。今のところ、いろんな学派が存在している。ソフトウェアエンジニアリングのコミュニティは、それぞれ意見を持っており、ソフトウェア開発において、それらは部分的には最適なことなのかもしれない。 だが、広く認知されたコンセンサスはまだ存在していない。

(さらに詳しく知りたい方は Robert Levy を見てください)