世に「ＳＥ」という言葉がある。

Sound EffectでもSpecial EffectでもService Engineerでも使われるかもしれないが、
今回話題にしたいのはコンピューターで言うところの「ＳＥ」、
「Ｓｙｓｔｅｍ　Ｅｎｇｉｎｅｅｒ」である。

まず最初にこの単語の意味を物理的に定義しておきたい。
個人的見解による定義は後で述べることにしよう。

「Ｅｎｇｉｎｅｅｒ」の部分は簡単、「技術者」である。
問題は「Ｓｙｓｔｅｍ」である。この単語を日本語に訳すことは、実は難しい。
なぜなら、それは単独物質を表す名詞ではなく、一種の概念を表す単語だからである。
これを理解するには、例を上げた方が解りやすい。

例えば「オーディオシステム」という言葉で「システム」が使われることがある。
この場合、システムとはどう意味を表しているだろうか。
（オーディオは音響である。）

オーディオシステムを構成する物は単独の物ではない。
音源となるのはＣＤやＭＤ、カセットテープ、ラジオ等がある。
うちの例を上げさせてもらえば、レコードやＭＩＤＩ音源と呼ばれる物も付いている。
レーザーディスクやテレビも付けている人もいるだろう。
これをアンプという物に通して音を大きくして、スピーカーやヘッドフォンから
音を出す。

そう、オーディオシステムは、いくつかの単独製品の組み合わせからなるのである。
しかもその組み合わせは自由である。
従って、同じように音を鳴らす装置であっても、全てが一体化しているラジカセは
システムとは呼ばない。組み合わせが固定されているからである。

ここで、システムの概念が解ってきたことと思う。
システムとは、「ある機能を持った物（多くの場合単独ではあまり価値がない）を
自由に組み合わせて（選択して）全体として意味ある物に仕上げる」という、
「組み合わせる」という動作もしくは思考をも含めた名詞なのである。
出来上がった全体を漠然と１つの物としてとらえるだけの意味ではないのだ。

さらに、この「組み合わせる」もしくは「選択する」という「意志」が大切である。
これが無い物は、本来の意味ではシステムではない。

コンピューターシステムと言う場合、オーディオと同じように考えれば、
コンピューターを構成する部品を集めた物と定義出来るようにも思える。
本体とキーボードとマウスとモニター、プリンターやモデムも入れたらいいだろうか。
でもこれだけではコンピューターシステムとは呼べない。
「コンピューター、ソフト無ければ、ただのゴミ」という言葉がある通り、
これにソフトがなければ意味がない。ＯＳやワープロや表計算のようなソフトを入れて
こそ初めてコンピューターシステムになる。
コンピューターシステムで重要なのは、マシンと言う物質的な物ではなく、
ソフトも含めて、全体で「何が出来るか」である。

        ・・・

さて、話を「ＳＥ」に戻そう。
では、コンピューターで言うところに「ＳＥ」の場合はどういう定義にすれば
いいのだろうか。

ＳＥとは、簡単に言えば、このコンピューターシステムを構築する人と言える。
どのようなハードを組み合わせ、どのようなソフトを入れたら何が出来るかを
教えるわけだ。
しかし、それだけでは駄目なのがＳＥである。なぜか。

オーディオシステムでは、その組み合わせは多くの場合ユーザーが決める。
どういうソフト＝音源を聞きたいために何を集めてどのようにつなぐかは
ユーザーが決める。

それが可能なのは、オーディオの場合、目的がはっきりしているからである。
それは「音を聞きたい」である。もちろん、音と映像を同時に、というのもある
だろうが、いずれにしても目的は単純だ。
そのような組み合わせが一番良い音になる、一番安いなどの付加的条件はあっても
根本は同じである。

ところがコンピューターの場合はそうではない。出来ることは、ある意味では無限に
あるから、目的あったシステムを組むのは難しい。そこで、そのアドバイスをする
為の人が必要であり、それがＳＥである。
ＳＥとはコンピューターシステムを組み上げるアドバイザーなのである。
設計者と言っても良い。
ではＳＥに求められる要件とは何だろうか。

今まで述べた通り、ＳＥはユーザーの目的に即したシステムを組み上げるのが仕事で
ある。ということは、まずはユーザーの持っている目的を聞き出すことが第一要件で
ある。

多くの場合、ユーザーは大雑把な目的しか持っていない。ただ「何がしたい」である。
でもそれではコンピューターシステムは組めない。
もっと細かいところまで聞き出す必要がある。

具体的に何をしたいのか。
それをいつまでに（期間）、どれ位で（金額）など。
特に重要なのが具体的目的を聞き出すことがある。
それが出来ればシステムの半分は出来たと思っても良い位である。

具体的目的を引き出すためにどのような手法を使うか。
１から構築の場合は「他社での例をあげる」、現状の改良ならば
「問題点を指摘する」等があるが、いずれの場合も「提案する」という方法が
効果的である。

ユーザーに１から目的を整理させるのは難しい。よほどの話術があり、
相手の深層思考を聞き出せる能力に長けているならともかく、そうでない場合は、
具体的な例を上げてみるのが一番解りやすい。
それはＳＥ側でも説明しやすいし、ユーザーにも解りやすい。
目に見える「例」解りやすい。
まさに百聞は一見にしかず。

        ・・・

このような相手の目的を聞き出しまとめることを「要件分析」というが、
この後は実際のプログラムに結び付く設計を行う。
プログラムを実際に作るプログラマーに解りやすいように、
ユーザーの目的をプログラマーの解る言葉に書き直してやるのだ。

さて、要件分析は実は最初に行うだけではない。
最初に話をした段階で全ての要件が聞き出せているということは、
おそらくほとんど無い。必ず聞き漏らしていること、ユーザー側にしてみれば、
言い忘れていたことがある。

従って、プログラムがある程度動く形になったところ（こういうものをプロトタイプ
と言う）でそれをユーザーに見せ、検証してもらう必要がある。作成しているものは
正しいか、抜けている部分はないか、それを確かめるのである。

最初から聞き漏らしていたかも知れないし、ひょっとするとプログラマーに解る
言葉に直すときに間違っているかも知れない。だからこの手順は重要だ。
出来れば途中で複数回行うのが良い。

こういう手法をプロトタイプ手法と言うらしい。まあ名前はどうでも良いが、
要は、途中で成果を見せて確認する方法で、この方法のメリットは確認以外にも
有り、最初の要件分析にかける時間を減らし、素早く（取り合えずでも）動くものを
得られるということである。

実際に動くものを見られると、ユーザーは安心する。たしかに作ってくれているという
安心である。これは重要だ。

ここでＳＥが気を付かなければならない、いや、覚悟しなければいけないことがある。
それは「仕様変更」である。
コンピューターシステムを構築する上で、仕様変更は（ほぼ）避けられないこと
である。

仕様変更にはいろいろとある。
ユーザーが言い忘れていた（ＳＥが最初に聞き漏らした）ことがあったり、
途中で一部変更せざるおえない状況が出たなどである。
そもそもＳＥがプログラマーに渡す仕様書が間違っていたのも、
プログラマーにしてみれば仕様変更である。

これにいかにうまく対応するかがＳＥの腕の見せどころと言っていいだろう。
プロトタイプを何度も見せるというのは、この仕様変更を最小限の影響で
食い止めるためにも重要である。完全に組みあがってからのへ変更は難しい。
途中でならやりやすい。これはプログラムだけではなく、世にあるほとんどの製品で
言えることだ。
だからこそ、開発の要所要所でプロトタイプを見せるのである。
ここまでで仕様変更はないかを確認するためにも。
有ればそこまでの内に直すためにも。

        ・・・

プロトタイプをうまく使えば、多くの場合結果的に開発期間を短く出来る。
ユーザーの求めているものをちゃんと形にするという意味での開発期間を。
現在のように、１つのシステムを構築するのに与えられた時間が短い場合には、
これは極めて重要である。

根幹にかかわる大変更の時は仕方無いとして、それ以外の場合は対応するのが
「あたりまえ」である。仕様変更を拒むＳＥは２流であると云わなければならない。
「出来ない」と言うＳＥはクビにした方がいい。
優れたＳＥほど仕様変更に対しても柔軟である。
そう、仕様変更に対する柔軟性によってＳＥの優劣が決まるのである。

        ・・・

ＳＥの重要な仕事としては、同じ目的をやり遂げるために最良の選択を選び出すと
いうのもある。

予算や開発期間からの選択もあるが、多くの場合はより安定しているもの、
より長く使える、しかも簡単に使えるものをユーザーは望む。

ここにおいて、ＳＥは決して個人的欲求を入れてはいけない。
どこそこのメーカーの製品が好きだとか、あそこのメーカーならバックリベートが
あるから等、そんなことで決める奴は絶対に外さなければならない。
まして、ユーザーの要件を自分の好き嫌いによって変更させよう等という奴は
失格である。

特定のメーカーへの容易な片寄りは危険である。
常に複数の製品と比較し、総合面で優れたものを選ばなくてはならない。
もちろん将来を見越してである。
同じメーカー＝相性が良い、そう信じるのは勝手だが、それは思い込みに過ぎない。
真実は検証する必要がある。

また、一見正しそうなことを言っていても嘘もある。
「こちらの方が将来性がある」「安定している」「サポートが充実している」等と
言う場合には、客観的データが必要である。

本当に将来性があるのか。発売しているメーカーが有名でも将来性があるとは
限らない。安定・不安定はシステムの条件（台数）などによっても大きく変わる。
サポートの充実も、サポート電話があるだけでは解らない。実際に電話が通じるのか、
通じたところで相手のユーザーサポートチームはちゃんとした対応が出来る技量が
あるのか。そこまで判断しなければならない。

そういうデータは、雑誌では得られない。むしろ（特に有名どころの）雑誌はおおよそ
嘘を付いている。それは、今までの実際に触ってきた経験と、他の実際に触っている
ユーザーの声からしか得られない。

ＳＥとは、そういう意味での情報収拾力、判断力も要求される。

        ・・・

後のＳＥの仕事としては、納品や動作確認などあるが、
一番重要なのはやはり上記２点である。

余談であるが、世の中には「プロトタイプ＝デモ」と勘違いしている人がいる。
自称ＳＥの中にもそう思っている奴がいるから困ったもんだが、この２つは根本的に
意味が違う。
デモは他人に見せびらかすための飾りである。見せかけだけであり、動かなくても
良い。内部的にも本物と全く異なってもいい。
しかしプロトタイプは本物の完成前のものであり、少なくともそこまでは本物と
同じに動かなくてはならない。内部も本物と同じだ。
デモ作成は場合によって本物に結び付かない場合もある＝無意味になることもあるが、
プロトタイプではそういうことはない。

        ・・・

ここまでで、ＳＥの定義と優れたＳＥの要点を見てきた。
それを踏まえて某社の「ＳＥ」について見てみよう。
はたして彼らはＳＥと呼べるだろうか。

某社ではＳＥは年功序列で決められている。
もっと正確に言おう。某社では、プログラムがそこそこ組める＝ＳＥである。
（ひょっとすると組めなくてもか？）
さらに、年をとって会社から「係長」と言う肩書きをもらうと「チーフ」という称号が
前に付く。係長＝チーフＳＥなわけだ。
それは実際の能力には全く関係無い。単に過ごしてきた年数だけである。

本当言えば、ＳＥとして認めるかどうかは肩書きや年数、まして自称ではなく、
ユーザーが決めることなのである。あの人は「ＳＥ」として認められるかどうか。

結局、彼らの言うＳＥとは「自称」に過ぎない。
その部署の長が勝手に付けた、いわばあだ名と同じだ。
まわりにとってみれば何の意味もない。
それは何の基準にもならない。
（馬鹿にするのには使える場合もあるが。）

もちろん、中にはちゃんと出来ている人もいるようだが、
そうでない人の方が圧倒数である。
また、そういう人間に限って「ＳＥ」と呼ばれること、自ら呼ぶことを
誇りにしているから困ったもんである。
某社の「自称ＳＥ」はいかに無意味な存在であるか。

余談ながら言っておくと、部門長にＳＥ的能力が有ればそれはそれでいいが、
必須ではない。部門長に求められるのはＳＥを管理する、束ねる能力である。
似非ＳＥの部門長ほど始末におえないものはない。

まあなんだな、このようなＳＥの定義を自分なりに書けるかどうか、
それだけでも「自称」は「本物」かの判断にはなるだろうな。
もっとも頭で解っているだけでなく、実践出来ないと駄目だが。

これを、実際に書いている私が「本物」であるかどうかは読者の判断に
任せることとしよう。