システムエンジニアは「システムの都合」に固執し過ぎてはいけないという話

これは、自分自身もエンジニア時代にやってしまっていたなぁ、という反省の念も含めた話です。

私は、シスコシステムズで働いていたころ、「ユニファイドコミュニケーションズ」と呼ばれるソリューション群のシステム設計や構築に携わっていました。

一番多く設計したのは、
「Cisco Unified Communications Manager（CUCM)」
という、IP電話を制御するシステムでした。

企業で使っているビジネス用の電話システムがありますが、これをシスコのIP電話システムに入れ替えるという案件が多かったと思います。

関わった会社は結構あります。名前をきけば皆が知っているような、大企業も結構含まれています。

それで、要件定義や設計の打ち合わせをしていると、お客様から

「ｘｘｘｘということはできるか？」

という質問が当然ながら出てきます。

中には、エンジニアからしたら「そんなのできるわけないじゃん」みたいな要求をしてくることもあったりします。

そしてそんな搭載している機能の中にはない要望が出たときには、「それはできません」という回答を行うことになります。

ところが、お客様がなぜそういうことをしたいのかをを深掘りしたら、本質は別のところにあって、別の機能で要求を満たせる、なんてことがあったりするのですよね。

結局、お客様の仕事をイメージできていないのです。

案件を経験していくにつれて、

「あぁ、俺はお客様に寄り添ってものごとをを考えてなかったな」

ってことを痛感したのでした。

エンジニアは、当然ですがシステム構築側から勉強をし設計のスキルを習得していきます。

なので、どのようにシステムを構築するか、どう設定したらどのように動くかは詳しくなります。

ただ、お客様の満足するよいシステムを構築しようと思ったら、

「そのシステムが、どのように現場で使われているかを知る事」

が大事なのです。

ザ・現場。

一番ベストなのは、その業務を経験することです。そうすることで腹に落ちてきます。

もちろん、業界によって使われ方はまちまちなので、すべてのパターンを網羅することなどできません。

ただ、少しでも現場を経験をしていることは、お客様の要件を想像するための\手助けにはなり得ます。

昔の私は、まさにシステム寄りでしかものを考えませんでした。

今となっては、お客様がなにか要望されたことについてそれが標準機能として実装していない場合には、

・なぜそのような要望をするのか背景を確認する
・その要望は、業務の中でどの程度のインパクトがあるのかを知る
・100点の回答はできなくても70点の代替策はないか探る

といったことを考えてもらう様、エンジニアに言っています。

そうすると、中には「実現は可能だが、設定が非常に複雑になり、運用になったときに相当な苦労をする」というようなものが意外と見つかるものです。

疎の設定を選択するかどうかは、運用での苦労を買ってまでも実装する必要があるかどうか天秤にかけることになるのだろうと思います。

ここまでは、標準機能の範囲での検討です。できる限りこの中で納めるべきです。

その要件が、業務の根幹に直結するような場合には、やむを得ませんが、開発によって特別仕様をあつらえるということになるのかなと。

ただし！

以前にも書きましたが、システム導入を成功させるお客様は、カスタマイズをやらず、自分達の運用をシステムに寄せていくということができるんですけどね。。（そのあたりは↓をどうぞ）

エンジニア君は自分の配属された部門や経歴などから「システム指向」な人と「現場指向」でみたとき、どちらに寄っているかちょっと考えてみてください。

極端にどちらかに寄りすぎてもいけなくって、どちらもバランスよく考慮できるようになることがベストなんだろうと思います。

最近自分が担当しているプロジェクトチームのエンジニア君達をみて、昔の自分を思い出してしまい、ちょっと書いてみました。

それではまた！

日々感謝 m(_ _)m