皆さんはおそらく「ソフトウェア・エンジニア」あるいは、「システム・エンジニア」と呼ばれているものと思われますが、自分の職名として「エンジニア」と呼ばれていることに、とくに疑問を感じたことはないのではないかと思われます。職場では、皆さんのことを自然に「・・エンジニア」と呼んでいることでしょう。
普通に「技術者」といえば、「technician」であって、必ずしも「engineer」という呼び方はしません。では、なぜこの世界は、「ソフトェア・エンジニア」であって「ソフトウェア・テクニシャン」と呼ばないのでしょうか。
もちろん、ソフトウェアの開発の世界にも多くの「technician」が関わっています。たとえば外向けの仕様書を書いたり、特許関係の文書を担当している「technical writer」は、間違いなく「technician」ですし、単に、仕様通りにプログラムを書くという意味での「programmer」であれば「technician」ということになります。ソフトウェア開発の流れ〔工程）を細分化したとき、その個々の工程を専門に扱う人を配置したときは、「technician」の存在が可能になってきます。
ということは、逆にいえば、「ソフトウェア・エンジニア」というのは、そのような働きを求められているのではないということです。
結論から言って「エンジニア」というのは、“エンジニアリング”する人、ということです。もともとは、船のエンジンなどを扱う人ということですが、当時は、それだけコントロールが難しく専門性が求められたわけです。今日では、もう少し意味が変化して、何も無いところに橋りょうや道路を作っていく人、効率の良いプラントの仕組みを作る人であり、そこから、渾沌とした顧客の要求を整理し、それをソフトウェアの製品の形にするための筋道を考え（そして作）る人、ということになります。つまり、片方から「要求」を流し込むと、もう一方の方からプログラムが出てくる仕組みを考える人、ということです。どうすれば、バグが少なく、納期通りに作り上げることが出来るか、ということを考え、それを実現するための「工程（プロセス）」を作るわけです。
また、エンジニアは、ある意味では、常に挑戦していなければなりません。一つうまく行く方法（道筋）を作ったとしても、顧客の要求は時間とともに変化しますし、そこで使った技術は日進月歩で進歩します。いや、その前に、一つの道筋を作り上げることによって、自分のスキルそのものも変化します。したがって、エンジニアは、極論すれば、同じ方法は２度と使わないし、同じ道は２度と通らない、ということになります。前回は十分にうまく行ったかも知れませんが、それでも今回は、どこか変化させて、もっと良い道筋を作ったり、変化に強い方法に切り替えたりするのが「エンジニア」なのです
もし、そのような変化を推進しないなら、一旦うまく行く方法が手に入った時点で、そのあとは「technician」だけいれば済むことになります。もっとも、この分野ではそのような状況は存在しません。このように「エンジニア」は、常に変化させなければなりません。少なくとも、この世界の技術が「完成」するまでは変化させなければなりません。
このホームページをご覧の皆さんは、おそらくほぼ全員が「知識労働者」かと思われます、いやその“はず”です。ソフトウェアの世界の人とは違った分野の方にもご覧頂いていることは、寄せられるメールからも見えているのですが、ほとんどは、ソフトウェアの開発に関係する世界の人と思われます。
「知識労働者」という言葉は、１９５０年ごろにＰ．ドラッガーによって使われた言葉で、ブルーカラー労働者との違いなどは、別のページ（「知識労働者」「続・知識労働者 」）で触れていますので、そちらを見ていただくとして、ここではソフトウェアの世界の知識労働者 としてのあるべき姿について、少しお話したいと思います。
上にも述べたように、エンジニアは常にプロセスを変化させなければなりません。もちろん、自分から変化させることが望ましいのですが、そうでなくても、要求の多様化や高度化といった形で、市場の方からそれを求めてきます。それがどんどん自分で考えつけばいいのですが、必ずしも、そうは行きません。そこで求められるのが、「知識労働者」としての「形」です。
世界中で、市場の変化を先取りして研究し、実験しています。地域や組織によっては、他よりも早く市場の要求として現れてきているところもあり、そのようなところでは、現実の問題として新しい方法に取り組まれているわけで、その結果が文献として公開されます。それが私たちにとっては、事前に準備する機会を与えてくれるわけです。
こういった有効な情報を早く収集し、それを身に付けて実際の場に使っていかなければ、その前に、市場の要求の圧力に押しつぶされます。
知識労働者が、知識労働者であるゆえんは、絶えず新しい、そして有効な知識を吸収し、それに基づいて新しい方法を考え、構築し続けていることにあります。次に来る市場の要求を察知し、それにうまく対応するための方法を、少しでも早く考えるわけですが、そのために、絶えず新しい知識や考え方に触れていることが必要になります。そうして、自分の置かれている場面にどう活かすかを考え、試行してみるわけです。
最近（９８年１０月）に出版された『ＵＭＬ モデリングのエッセンス（羽生田栄一監訳、アジゾン・ウェスレイ・パブリシャーズ・ジャパン）』という本の中で、「１ヶ月に少なくとも１冊は内容の充実した技術専門書を読むように・・」という記述があります。これだと、年間に６冊です。できれば１０冊ぐらい読んで欲しいのですが、当面は５，６冊が目標としては適当なところでしょう。最初は、年間に３冊位しか読めないかもしれません。でも、その次の年には、６冊が苦痛にならなくなります。そうすれば５年で３０冊の専門書、あるいは仕事に有用な書物が読めることになります。
もちろん、読むべき技術書の分野は、その人の立場によって少し異なります。マネージャーの立場であれば、リスク・マネージメントなどの分野も対象になります。
これが「知識労働者」のスタイルです。このスタイルが、「ブルーカラー労働者」がこの分野に進出しようとする際の障壁であり、それが今日の「雇用のミスマッチ」の背景でもあるのです。したがって、もし、これが出来ないとすれば、「エンジニア」は勤まらないと思ってください。「technician」にはなれるかも知れませんが、「エンジニア」は無理です。
もちろん、この「エンジニア」の不足の問題は、ソフトゥエアの分野に限ったことではありません。他の分野でもエンジニアが必要なのですが、残念ながら「知識労働者」のスタイルを身に付けたエンジニアが不足していることで、それぞれの分野において変化〔発展）が止まっている原因と考えています。
組織のプロセス・レベルが低い組織では、たとえばＣＭＭなどに基づいて「工程」を明確にし、それなりの成果物を作りながら進めていくことで驚くほどの効果が得られます。バグは１桁減るでしょうし、納期も遅れが半分になることもしばしばで、時には、遅延も解消することもあります。
そのため、多くの関係者（本来はエンジニアのはず）は、そこが自分たちが目指していたところと思うのでしょうか、いつの間にか、変化させる事を止めてしまいます。それ以上、変化し続けることは、「知識労働者」のスタイルが身に付いていない人たちにとっては、とても辛いことなのです。できれば、それを止めたいと思っているのです。もっとも、このような人は、その間にも、殆ど適切な文献を読んではいません。
ＩＳＯ９０００の導入を機に、またＣＭＭの取り組みを機に、それなりの効果が得られた所で多くの人たちは止まってしまいます。そして、前回と同じことをし続けます。それでもしばらくはそれなりの結果が出ているのですが、その背後に迫る破綻には気づいていません。プロセスのデータがきちんと収集されていないと、市場の要求との乖離が始まっていることには気づきません。そしてこの状況に気づくのは、乖離がある限界点を越えたときで、そこまでには、通常は、２年程度の時間が経過しています。そして、この時点では、すでに「意識」の方は、以前の状態に戻っているのです。
そのため、このあと市場の要求との乖離が限界を越えたことに気づいたときは、以前よりもまして厳しい状況に置かれるはずです。もっとも、何年か前にＩＳＯ９０００やＣＭＭに取り組まなかったら、ここに来る前に市場の要求を満たすことが出来ずに破綻しているはずで、当時の取り組みは、ここまで引き伸ばすことに貢献？したということです。ただ、この間の２年という時間を将来に繋ぐことが出来なかったわけです。
今日では、認証ビジネスの効果？もあってか、我が国でもＩＳＯ９０００（ＩＳＯ９００１）を取得している組織はだいぶ増えてきました。でも多くの組織では、それが経営上の貢献として現れてきていないし、むしろ、柔軟性を欠くあまりに、市場の要求に対する“抵抗線”としての役目すら果たしているようです。ＩＳＯ９０００は、１００年１日のごとく、ここで確立した「工程」を守れとは言っていません。ＣＭＭほどには、変化を表に出していませんが、それでも、市場の要求をブロックするのに使われているとしたら、本末転倒も甚だしいと言わざるをえません。
なぜ、そのような対応がなされているのかというと、一つの、そして最大級の原因は、そこに「エンジニア」が存在していないということです。常に新しい方法〔道）を求めて変化させ続けようとするエンジニアがいないということです。ＩＳＯ９０００を導入して１年たって、いまだに経営上の貢献として現れてこないとすれば、何かを変えなければならないことは自明の理です。そしてそれが出来るのは、「エンジニア」なのです。「知識労働者」のスタイルを身に付けた「エンジニア」こそ、その役目を負っているのです。
このエンジニアさえいれば、ＩＳＯ９０００から入るべきかとか、ＣＭＭから入るべきかと言った議論には、何の意味もないことに気づくはずです。変化させる姿勢さえ持っていれば、ＩＳＯ９０００から入っても、ＣＭＭのＫＰＡ（Key Process Area）の具体的な取り組みのなかから有効な取り組みを借用するでしょうし、ＣＭＭから入っても、適当なところでＩＳＯ９０００を目標に据えたりチェック項目として使うはずです。
残念ながら、「シックスシグマ」も、いまのところ、同じ危険に曝されているということが言えます。この１２月に出版された『シックスシグマ 導入戦略（青木、三田、安藤共著、ダイヤモンド社）』を読んでも、著者の方達はこのことに気づいているように思われます。一時のブームに終わってしまう危険を肌で感じているのです。もし、本当にそうなってしまったとき、この国の「産業」の栄光は過去の歴史の中に消えてしまう。信じられないかも知れないが、８０年代の栄光が、４０年前の戦後の状況では想像できなかったのと同じように、この先の３０年後の姿を想像できないのも無理はないかもしれません。
ところで、ここまで読み進んでこられたあなたは「ソフトウェア・エンジニア」ですか？