2019年09月15日に初出の投稿

Last modified: 2019-09-15

"software engineering" という分野は、大型書店で配架されている本を見るとよく分かるとおり、「オブジェクト指向」とか「アジャイル」とか「PMBOK」とか「仕様」とか「要件定義」とか「見積もり」とか「RFP」とか「CI」とか、要するに開発したり実装したりメンテナンスするような現実の手順によって、ソフトウェアなりアプリケーションのライフサイクルを対象とする分野のことだ。したがって、OS や BIOS やドライバといったプログラムの開発や管理も含まれる。CPU やビデオ・カードの回路設計とかは含まれない。

よく、僕はウェブ・アプリケーションも含めてウェブ・コンテンツの制作事業者に勤務しているコーダやプログラマは、たいていにおいてソフトウェア・エンジニアではないと言っている。開発ベンダーならともかく、たいていのウェブ制作会社のプログラマは要件定義書など書けないし、書いたことすらないと思う。顧客から RFP をもらった経験などないだろうし、恐らく8割以上は UML を理解していないどころか、ER 図を書けるプログラマには殆ど出会ったことがないし、半数くらいはデータベースの正規化すら分からない。僕も我流で知識や経験を積んできたので、もちろん偏りがあるのは理解しているが、どうしてそれを理解しているかというと、資格試験のテキストや software engineering の概論や分厚い handbook の類を見るように努めているからだ。もちろん、何か一冊の概論だけを見たらいいというわけでもないので、見つけたらなんでも目次や文献表を眺めるようにしている。特に、ソフトウェア・エンジニアリングという分野は、数学でもなければコンピュータ・サイエンスでもない実務志向の分野だが、かといってフレームワークの良し悪しとかプログラミング言語の比較といった話題にまでは関わらないし、IDE やテキスト・エディタとしてどれがいいかなどという些末な議論も視野に入れない。

それゆえ、開発手法とかテスト技法とかメンテナンスやシステム・ダウンの手順といった分野が、果たして科学なのか(科学が現実を無視していいかどうか自明ではないが)、それともマネジメントなのか(マネジメントが科学ではないかどうかも自明ではないが)という点で、ソフトウェア・エンジニアリングの研究者がもつ意見は分かれていると言ってよい。僕が見た限りでは、恐らくソフトウェア・エンジニアリングという研究分野としてどちらの指向が正しいかというよりも、それらの両方を考慮する分野なのではないかと思う。そして、形式的な手法で理想化された状況の帰結を出してみるフェイズと、実質的な手法で実用化された状況の帰結を出してみるフェイズとで、それぞれが他方へフィードバックするような関係があるのだろう。たぶん、たいていの学術研究は人がやっている以上、具体的な状況を無視するだけで形式的な考察ができるものでもなかろう(科学でも実験設備を考慮した誤差を考えるはずだし、フレーム問題と似たようなものだが、《何を考慮の外へ置いて物事を抽象化するか》がポイントになるだろう)。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook