ソフトウェア工学は未成熟なプラクティスによって重大な阻害を受けている

平鍋さんの資料にある「ソフトウェア工学は未成熟なプラクティスによって、重大な阻害を受けている」の文言にビビッときた。
以下は思いつきのメモ。
特に主張はなし。

【参考】

Agile, Software Engineering, Process Kaizen. They mix like oil and water ? from Kenji Hiranabe

SPI Japan 2016 | イベント | 日本SPIコンソーシアム

現場から始めるアジャイルの技術プラクティス

ソフトウェア工学の方法論と理論 1. 目的とスコープ(Purpose and scope)

SEMAT “Call for Action” の日本語訳 - とあるソフトの開発記録

アジャイルは”再び"死んだ

(引用開始)
ソフトウェア工学についての後悔
Tom Demarco ソフトウェア工学、そのときは去った。
Ed Yourdon ソフトウェア工学に大切なことは？
Barry Boehm あの指数曲線は間違いだった。
Ivar Jacobson ソフトウェア業界は、ファッション業界のようだ。
Tom Gilb ソフトウェア工学は定義を間違った。
(引用終了)

(引用開始)
Ivar Jacobson
ソフトウェア工学は未成熟なプラクティス(immature practices)によって、重大な阻害(gravely hampered) を今日受けている。
例えば、具体的には以下のように：
言葉の流行が、工学の一分野というよりファッション業界のようだ。
しっかりした広く受け入れられた、理論的基礎の欠如。
非常に多くの方法論(methods)とその派生。
またそれらの違いがほとんど理解されずに作為的に強調されている。
信頼できる実験的評価(experimental evaluation) と妥当性確認(validation)の欠如。
産業界の実践(industry practice)と学界の研究 (academic research)の乖離。

私たちは、ソフトウェア工学を堅固な理論および検証された原則とベストプラクティスを基礎として、再建するプロセスを支援する。そのプロセスは、以下の特徴を備えている。
広く合意された要素からなる、特定用途に拡張可能なカーネルを含み、技術の問題と人の問題の両方を扱い、産業界、学界、研究者そして、ユーザに支援され、要求とテクノロジの変化に応じて追随できるような拡張性を備えている。
(引用終了)

「ソフトウェア工学」という言葉は、たぶん、IT技術者ならば、愛憎の両面を持つ言葉だろうと思う。
いつも現場で混乱していて、その解決の手がかりになるような、厚い雲から差し込む光のように感じるけれど、実際に使おうとしたら、そう簡単に結果は出ないし、使いにくい。

個人的には、ソフトウェア工学は、製造業の品質管理やPMBOKのように、汎用化された知識体系として提示したいけれど、問題解決の適用領域が時代と技術に依存するために、その範囲がとても狭い。
そして、技術の陳腐化が激しいために、使える期間がとても短いがゆえに、工学と言いづらいのだろうと思う。
工学として使える手法は、夏日のアイスクリームのように、一瞬だけ使えて、溶けて無くなる、みたいな。

それから「プロセス」という言葉がいつも引っかかる。
普通の感覚では、「プロセス」は業務フローや業務のワークフローのような、ある定型的な手順を指す。
しかし、ソフトウェア開発をプロセスとして定義しようとすると、各案件の開発手順は、環境・組織・技術・要件などによって異なり、それらを統一ないし標準化することがとても難しい。
むしろ、標準化しても、すぐに陳腐化してしまい、使えなくなる。
誰でもいつでも使える「プロセス」という発想自体がおかしいのかもしれない。

つまり、物理の法則や数学の公理系、製造業の品質管理、製造業のIEとは違い、ソフトウェア工学は、汎用的な工学として成立できていないように思う。
その根本問題には、問題解決の領域が狭すぎる、問題解決の鍵となるアイデアの生存期間が極端に短すぎる、ということがあるのではないか。

でも、矛盾しているが、ソフトウェア工学やプロセス改善について、自分なりに考えて試行錯誤することには意味があると思う。
そして、その問題の解決の糸口に、オープンソースやアジャイル開発があるように直感的に思う。