何でまた一般企業にシステム部門などが存在するのだろうか。最近では多方面のノウハウが必要なクライアント＝サーバー系の新規システムを作るときはだいたいベンダーに丸投げしてしまう（はずかしながら提案依頼書も見たことがない）。ユーザーを巻き込むことも多い。要件は作ってもらうし（まあ、これは当然）。ユーザーレビューと称して設計書もそのものも読んでもらう（ユーザーにはちょっと大変になってくる）。システムはユーザーのものだからと受け入れテストまでやってもらう（ニーズに合致しているかを確認してもらう必要はあるが、とりあえずバグがつぶれたものを持ってきて欲しいだろうね）。
もしユーザーが物理的に離れたところにいる場合や分散している場合はユーザーニーズをくみ取り、それらをコーディネートし、要件と仕様が合致しているかを検証する部署が必要である。ユーザーそのものを呼んでくることはなかなか出来ないからである。ところがユーザーが集中しており、ベンダーとの連絡が密に取れる場合、それでもシステム部門が必要かどうかというのは考慮に値する問題であろう。
たしかにベンダーとの連絡係は専担でいたほうがよかろう。もっとも便利だからという理由で人を増やすわけにはいけないのはどこの企業でも事情は同じ。
ユーザーが直々にシステムを担当した方が能率が高いという事象は確かに生じているようで、従ってエンドユーザーコンピューティングなどというものがもてはやされたわけである。パソコンの普及と（コンピュータは落ちるのが当たり前というユーザーの認識の変化によって）マクロを使うという程度の技術はＥＵＣとして定着した。データさえワークシートでもらえれば、あとは自分でやった方が早いという程度には腕に自信のある人も増えてきたようだ。
たしかにＥＵＣは定着した。しかしオフコンを使った第一次ＥＵＣの動きが失敗した時の反省を踏まえてそう言い切れるかには疑問がある。このときはたしか（ああ、出典忘れた、1992年ごろのLAN TIMESなのだが）ファイルの容量が限界に達してつまずき、担当者の異動がとどめとなった、そうな。
同じように、（ハードディスクが安くなって容量の問題は無視できるとしても）ファイルの管理が困難になり、マクロを書いた担当者が異動となればこれは維持が不可能であろう。きちんとドキュメントを残しておきたいものである。但し、システムが使えるようになればそれを（自分以外の人間が）メンテナンスしてゆくことに、普通、ユーザーというものはあまり関心を払わない。それ以外にも仕事がたくさんあるし、そっちの仕事がメインだからユーザーというのである。ところがソフトウェアというのは、ほとんどの場合長い間使えてなんぼである。もちろんソフトウェアを開発したり購入したりするのは利用価値を求めてであるが、だからといって期待将来価値を無視してはいけない。これはそのソフトの利用価値が将来的にどの程度保証されるかの問題である。（このへんの議論はEric.S.Raymondの「魔法のおなべ」に基づいている。）
ではどうすればこの将来価値が損なわれずに済むか。これを保証するためには、システムの作りをドキュメントに残さねばならないし、運用も無理のないものにしなければならない。回線やサーバーもできるだけ二重化しするなどして耐障害性を高めねばならないし、採用する技術があまりに本流とかけ離れたものでは困るだろう（ベンダーが売りたがっている製品はしばしばこうしたものである。）。
そんなふうに将来価値を保証するための仕事をするセクションを設けておく方が長い目で見れば有利なことが多いのではないか。。。これがシステム部門の存在価値ではないかという思いに捕らわれるようになった。システム部門はシステム開発時には可用性の高い（メンテナンスがしやすいことも含む）システムを作るためにあって、運用時はメンテナンスをするためにある。システムのコストは稼働後にかかるものであるとすれば、開発時は稼働後のコストを削減できるよう開発するのが仕事であり、稼働後はできるだけ少ないコストで済ませるようにする。ここまで言ってしまうと身も蓋も無いなあ。
（でも、これをやっていない人たちを見ると、どんなに動き回っていても、暇そうだなという印象を持ってしまうのだ。）もっとも、システムはユーザーのものだからと、要件定義や設計をあまりにユーザーに頼っているととんでもない落とし穴にはまる可能性のあることに最近気がついた。ユーザーにとっての重大事がシステムにとっての重大事であるという保証はどこにもなく、たまに両者がずれていることがあるからだ。そして恐ろしいことにそれは構造的問題として現れる。
なかなかの例がロンドン証券取引所で構築が計られ、廃棄されたTaurusというシステムである。決済業務を電子化して全ての取引から券面をなくそうという壮大な構想。もちろん取引所参加者全てと電子的に接続しなければならないということで、システムの要望を出す側のユーザーは次々と外部接続仕様を持ってきた。また取引所改革を検討するメンバーの頭は大幅に変化する取引慣行をどうするか、法律的問題をどうクリアするかで頭が一杯で、システム対応はまずそれらの部分への適応を考えてきたのだろう。
そして気がつくと誰も決済の根幹であるはずの「注文と支払の突き合わせ」すら設計していなかったわけだ。
ユーザーは、取引所の制度改革とは取引慣行が変わることであり、システム要件もこの新しい取引慣行へ対応できるかどうかが中心であったと推測される。
しかしながらシステムとしてはまず「取引の照合／消し込み」を作ることが肝心であり、これに気がついた人間は、少なくとも体制を検討する側にはいなかったと思われる。
このTaurusの失敗を紹介した本（「プロジェクト迷走す」日科技連）は、プロジェクトの失敗を意志決定の観点から分析しているため、「なぜ、こんなまぬけなプロジェクトになってしまったか」というプロジェクト管理の側面には触れていない。しかし、理由は上のようなことではなかったかと考えられうる。。つまり、ユーザー要件とシステム要件はずれてしまうという現象が発生したわけである。
しかしながら、このことは当然システム部門が気がつくべきであったろう。少なくともシステム部門の統括者はそれを指摘するべきであった。なぜなら、このことは「ユーザーが認識していないシステム上の要件を拾い上げて明確化する」というシステム部門古来の役割とそう隔たったものではないことと考えられるからである。
この古来の役割は例えばシステム同士を接続するところに現れてきた。ユーザーにとっては接続先システムとACKを投げ合うタイミングがどうかという問題はどうでもよいし、見える必要もないが、システム部門にとっては大な考慮点である。このようなことは今までもやってきた。最近はシステムがユーザーに見やすいものになってきたために、システムの専門家にしか見えないがシステム的に重要な部分というのは減ってきているように思われて、いつの間にかこのあたりのことは着目されなくなってきているが。（では、どのタイミングでACKを投げるか、そもそも投げる必要があるのか〜FTPそのものは投げない〜というのは、システムに要求される信頼性と、システム構築者の方針によって変わる。方針を決めるのもそういえばシステム部門の仕事かな？以前は担当者ごとに一家言あったりしたが、システム環境がこう多岐に渡り、若い人が増えてくると標準ルールの制定が必要になってくるだろう。）ユーザーのコンピュータのスキルが向上してきたおかげで、またコンピューターが専門家でなくとも扱えるものとなったおかげで、ユーザーのシステム開発への参画の度合いが大きくなってきた。しかしそれゆえに、ユーザー要件とシステム要件の乖離が生じやすくなってきたということが言えるのではなかろうか。
かくして「どうやってメンテしやすいシステムを作るか」というよりはやりがいのありそうな仕事がシステム部門にとって浮上してきたと思うのだがいかがだろう。Taurusのような大きな例はあまり見かけないが他山の石にしたいと思っている次第。
汎用機の時代は環境を自社ですでに保有していることが多いから、開発ルールや既存のデータベース構造、運用状況というのは必ず自分でデザインして押さえておかねばならず、それゆえ自身でシステムを作り上げる部分があったわけですが、クライアントサーバーシステムとなるととなると、ベンダーに丸投げしてもシステムはできるようになってきました。コンピュータネタ、目次へ
つまり汎用機の環境は、非常に高価で導入先ごとにひとつひとつ微妙に違うので、いきなりこのコンピュータの上でシステムを作ってよ、とベンダーに言っても受けられるベンダーは限られていました。さらに当時はソフトハウスといってベンダーとは言わなかった。
しかしクライアントサーバーではシステムを作るたびにサーバーを入れてＬＡＮを張ってと一個一個独立に構築するわけですから、システム一式をベンダーに丸投げしてもかまわないようになってきました。むしろその方が多数のCPU/機器を接続する時のリスクが少ない。
だからクライアントサーバーシステムが当たり前になった世代の人間は自分で設計ができずに、ただユーザーとベンダーの橋渡しをするのが仕事であるかのように誤解してきたわけでしょう。