筆者は現在、小売業を展開する中堅企業様（売上高数百億円規模）の情シス支援の仕事を業務委託契約で行っています。
具体的な仕事内容は、小売業様が会計パッケージを導入するにあたり、PMOとしてプロジェクト推進支援／業務要件定義の支援／受入テスト支援などを行っております。
そのプロジェクトで、日系SIerの人気ＴＯＰ１０以内に入る有名企業にパッケージ導入を依頼しているのですが、はっきりいってＳＥのレベルがかなり低いです。
大企業なので多種多様な人財がおり、たまたまハズレを引いた可能性もありますが、（せっかくの機会なので）筆者がユーザ企業の情シスの立場で、いまいちだと感じたSEの特徴をまとめてみます。
一言で表現するとコミュニケーションレベルの低さです。
大企業SIerでこのレベルだと、多くの業務系システム開発が失敗するのも当然だと感じさせられました。
※いまいちなPM（プロジェクトマネージャ）編はこちら↓↓↓
いまいちなプロジェクトマネージャの特徴について。PMは未来に向けた仕事をすべきと考える理由。
いまいちなSEはコミュニケーションレベルが低い
SEの仕様説明が雑でユーザが理解できない
SIerが仕様説明を行う相手方であるユーザの方々は、自分の業務には精通していますが、ＩＴに関する知見に乏しいことがほとんどです。
一方、システムエンジニアは、ユーザとシステム開発者の橋渡しとなり、システム開発に必要な仕様確定を、ユーザが理解できる文脈に置き換えながら合意形成を図っていくことが仕事です。
ですが、現実には「ユーザが理解できる文脈に置き換える」ということができないSEが多く、その結果、ユーザが十分に理解できていないまま強引に仕様確定を行い、後々トラブルになるというケースが多々見受けられます。
「ユーザが理解できる文脈に置き換える」という意味は、ユーザが普段実施している業務手順に沿って、この機能を実装することにより、実装前と実装後でどのように業務が変更となるか？ということを説明することです。
多くのSEはこのやり方を割愛して、ピンポイントで確認したい仕様だけ確認するので、ユーザはイメージを膨らませることができず、仕様を理解できないのです。
ではSEがなぜこのやり方を出来ないかというと、SEがユーザ業務を十分に理解できていないからです。要はSEはユーザ業務を理解できていない、ユーザはITを理解できていない、というお互い理解できていない者同しが、なんとなくで仕様調整を行っているという恐るべき状況が発生しているのです。
なので筆者個人の見解としては、SEはもっとユーザ業務を深く理解すべきです。初見の業務であれば、わからないのは当然ですが、書籍で業務知識を勉強する、ユーザに適切なヒアリングを行う、ユーザの業務マニュアルを読み込む、など適切な対応を実施すれば理解できるはずです。
ユーザ業務を十分に理解した前提で、システム開発に向けた仕様調整を行う事で、初めてSEとしての役割を果たせると考えます。
ユーザとSIerの責任範囲を明確化できておらず、仕様確認が細かすぎる
上記の仕様説明が雑というのと重複するところもありますが、ユーザとSIerの責任範囲が明確化できておらず、仕様確認が細かすぎるというSEもいます。
本来、ユーザへの仕様確認というのは、どういうインプットに対してどのようなアウトプットがでてくるか？という事を確認することが目的です。
インプットとアウトプットの間に存在するロジックについては、正しいアウトプットがでてくるというのを前提として、ユーザの立場からするとブラックボックスであり、SE（SIer）がプロとして責任を持つべき領域です。
たとえば家に例えると、価格（インプット）に対して、どのような間取りで、どのような設備が備わっているか？（アウトプット）というのが購入者側からすると重要です。その家が具体的にどのような技術で設計されていて、どのような素材で作られているか？（ロジック）というのは多くの人は気にしないと思います。（好きな人は気にするかもしれませんが。）
ですが、いまいちなSEは、内部処理のロジックについてユーザが誰一人理解できない説明をした挙句に、そのロジックに対して合意を迫ってきます。いったい何を目的としているのか筆者には理解できません。仮にそのロジックに不備があった場合に、仕様は合意しているとSIerの責任を回避するつもりなのでしょうか？そんなことはできる訳がないです。
繰り返しになりますが、ロジックについての責任は、SE（SIer）がプロとして責任を持つべきです。
先ほどの家の例ですと、仮に設計に不備があった場合に、この設計図をお客様に合意していただいております！ですので責任はお客様にあります！なんて馬鹿げたことをいう業者はいないですよね。
オープンな質問をしてくる
オープンな質問をしてくるSEも駄目です。オープンな質問とは、例えば「これどうしましょうか？」とか「なるべく早く確認お願いします」などです。
前者の「これどうしましょうか？」は、そんなことユーザ側に聞かれてもわかる訳がない！というのが回答になります。SEが考えるのを放棄して、責任転嫁をしよとしているように思えます。
本来の進め方は、いくつかの案とそれぞれのメリット・デメリットをユーザに説明して理解していただいたうえで、SEの最もお薦めする案を提示すべきです。そこまでして初めて、ユーザと真っ当な議論が可能になります。
後者の「なるべく早く確認お願いします」にも最悪です。なるべく早くと抽象的な表現をされても、各々のなるべく早くは異なります。すぐにやらねばと焦る人も居れば、１カ月後くらいでいいだろうと考える人もいます。
しかも筆者の視点からすると、SIer側が期限を明示できないという事は、タスクごとに計画を立てて、どの成果物がいつまでに必要なのかというスケジュール管理ができていないんじゃないか？という印象を受けてしまいます。
ですので、SEは自社の計画に基づいて、いつまでにどのような確認が必要か、日付を明示的に提示すべきです。そのうえで初めてユーザが無理なら無理と具体的な会話が可能になります。
最後にご紹介
IT・業界の転職・キャリア相談や仕事上における悩みなど
なんでも話を聞くサービスを行っております。
もし転職することに不安を抱えているようでしたらご利用ください。少しは心が楽になるかと思います。
よろしければお使いください。↓↓↓