システム・エンジニアという呼称は、広義には、なんらかのシステム--コンピュータ・システムのみではないが--を設計して作るエンジニアのことを云うのでしょうね。特に、システムとして、経営過程 （事業過程・管理過程・組織過程） を対象にすれば、（システム・エンジニアの略称として使われている） ＳＥという用語は、以下の意味あいがあるようです。

　（１） システム化の対象である経営過程を調べる （理解する）。
　（２） システム化の中身や やりかた を考える （記述する）。

　そして、（１） として、以下の２点が、1970年代から 30年に及んで、言い古されてました。

　（１） 現状を調査して、問題点を定式化する。
　（２） 問題点に対して、ソリューションを提言する。

　そういう言いかたに対して、僕は、「ＳＥの自惚れ」を、つよく感じます。すなわち、ＳＥは、経営過程やコンピュータについて、知り尽くしていて、（経営過程のなかで仕事をしている） エンドユーザを指導する、という自惚れを感じます。

　1970年代、コンピュータは、経営過程のなかで、多く・広く 使われてはいなかった。当時は、コンピュータを、どのようにして使えば、経営に役立つか、ということを試みていた時代でした。そして、コンピュータは、給与計算や ＭＲＰ （Material Requirements Planning） のように、アルゴリズムが はっきりしている領域のなかで、多量データを扱う機械 （計算機） として--人力なら、数日 費やす「計算」を、数時間のうちに実行する、という点では--、多大な貢献をしました。

　1970年代では、コンピュータ化 （自動化） と云っても、アルゴリズムが、当初から、はっきりしている領域を対象にしていたので、エンドユーザが、自動化したい仕事を、プログラマに対して、直接、指示しても、プログラマは、事業過程を理解しなくても、プログラムを作成することができました。１つの事業過程 （たとえば、購買とか、生産とか） を、１つのアプリケーションとして、システム化の対象にしていたのではなくて、個々の・いくつかの仕事 （ルーチン的な task） を自動化することが、コンピュータの役目でした。
　ルーチン的な task を自動化すればよいのだから、プログラマのほうでも、事業過程に関する知識がなければならないという訳でもなかったし、コンピュータが高価だったので、プログラマとしたら、いかにして、効率的なプログラム （ＣＰＵやメモリーを、できるかぎり、費消しないで、ステップ数の少ないプログラム） 作成するか、という点が主眼でした。

　コンピュータが、給与計算や ＭＲＰ などを対象にして、多大な貢献をしたので、1970年代半ば頃には、ほかの領域でも、貢献できるのではないか、と考えられて、かつ、（ファイルと言語という素朴なツール構成のほかに、） データベース （階層構造型） が出てきて、コンピュータ化の対象を、広く認識するようになって、１つのアプリケーション （funciton area） をシステム化の対象にするようになりました。
　１つの事業過程 （たとえば、購買とか生産とか） を対象にするようになったので、システム化の対象である事業過程を調べる （理解する） ことが、コンピュータ化を仕事としているエンジニアにとって、大きな役割になってきました。（プログラム作成を仕事とする） プログラマが、エンドユーザと、直接に、コミニュケーションできない事態になってきました。そのために、エンドユーザとプログラマのあいだに立って、事業の中身をコンピュータの やりかた として変換するために、「go-between」的役割として、ＳＥという職が出てきました。
　ＳＥが、事業過程を調べるための作図手法として、1970年には、構造化手法 （ＤＦＤや funcitonal decomposition） が提示されました。

　さて、歴史的観点から判断して、ＳＥの仕事は、どうも、そもそも、「中途な」性質を帯びているようですね。ＳＥという職が出てきたとき、エンドユーザが、コンピュータの知識を習得することに比べたら、プログラマが、事業に関する知識を習得したほうが、効率的である、という考えがあったのかどうか--そして、プログラマが、年齢的に、次のキャリア・パスとして、ＳＥという職に進んだほうが、「（コンピュータを知っている） 経験を活かすことができる」と勘違いして、育成の観点からしても、効率的だ、と考えたのか--、という点を、僕は、的確に推測できないけれど、「プログラマが、キャリア・パスのなかで、いずれ、ＳＥになる」という考えかたが一般的になってきたようですね。

　1970年代の半ば頃から1980年代の終わり頃まで、そういうキャリア・パスを前提にして、ＳＥは、「（事業的知識とコンピュータ的知識の） 中途な」立地を、逆手にして、「（事業的知識とコンピュータ的知識の） 両方の」足場を得ている、と勘違いして自惚れたようです--事業やコンピュータを知り尽くしていると勘違いして、事業過程のなかで、責任もって、仕事をしたことがないにもかかわらず、「事業を、どうすべきか」ということを知っていると自惚れていたようです。

　1980年代の終わり頃から1990年代の初め頃、パソコンが普及して、1990年代半ば以後、エンドユーザが、自らの「コンピュータ」を使うようになって、自らの仕事 （tasks） に関して、EXCELL や ACCESS を使って、仕事を効率化して、かつ、いくつかの新しい ＯＳ や新しい言語が出てきたし、インターネットやウェッブが実用化されたので、1995年以前に、大型汎用機を使っていた「体験」など、「コンピュータを知っている」という拠り所にはならない。
　また、過去 10年のあいだ、いわゆる「会計ビックバン」と云われるほど、経営成績の計量法が変わってきたので、1990年代半ば以前の知識のみでは役に立たない。

　1970年代、1980年代および1990年代と時代が進むにつれて、環境も、大きく変化してきました。或る時代のなかで使われていた--或る環境のなかで使われてきた--手法・技術が、環境が変わっても、以前として、役立つ、と思うのは、あぶない「思い込み」でしょうね。ＳＥに期待される役割は、1970年代と 2005年では、当然ながら、相違するし、ＳＥの育成も、それに対応して、相違します。

　しかしながら、現状を観れば、ＳＥと云われている人たちが、1970年代・1980年代のなかで通用した手法 （たとえば、ＤＦＤを使った事業過程の記述とか、トップダウン的なビジネス・モデル作成など） を、いまだに、そのまま、使い続けているようです （苦笑）。

　ＳＥが習得している事業知識をテストするには、以下の点を訊いてみればよいでしょう--「1995年以後、たとえば、財務会計や生産管理の書物を、それぞれ、５冊以上、読みましたか」と。そういう知識がなければ、およそ、現代の経営過程など理解できる訳がない。
　アプリケーションごとに、おおまかな構造パターンを知っていれば、事業過程を理解している、ということにはならない。

　
　（2005年 1月 1日）