先に、TVドラマ「ハケンの品格」になぞらえて、「コンサルの品格」というエントリーを書きました。それには、コンサルタントとしてのあり方、接し方、使い方について、次の2点を軸に述べています。

▽業務推進のサポートとしてのコンサル

▽外部の目としてのコンサル

※コンサルは開発請負業者としての側面も持ち合わせていますが、あくまでも「コンサルティング業務」という点に限っています。

同じように「SEの品格」について考えてみます。

システム構築者としてのエンジニア

システムエンジニアという名前の通り、システムの設計や構築を手がける際にSEを動員することは一般的でしょう。

このとき、SEに期待されることは、与えられた要件定義（RFP）を忠実に具現化することではありません。

現時点で存在しないものを設計するのですから、実装に着手してから初めて定義不足に気付くというのはよくある事です。しかし、だからといって、その発見がシステム構築の後段で起こるほど、手戻り工数も増していくものです。

ゆえに、クライアントにとってシステムの理想的な姿を思い浮かべて、設計、構築、運用に当たることが望まれます。とはいえ、クライアント側も、SEにおんぶに抱っこというのもよくありません。そもそも、SEとは要件定義にしたがってシステムを構築するという点を十分に認識し、不足情報があれば適宜SEに情報を提供する姿勢を持ちましょう。

ソリューション提案者としてのエンジニア

SEとはシステムエンジニアを略したものであり、一般にはシステム構築の設計者を指します。しかし、今日では、システムだけではなく業務プロセスの見直しも含めてシステム設計をすることも多く、そのため、「ソリューションエンジニア」という呼ばれ方もしています。

彼らがやることはコンサルに近いですが、コンサルとの最大の違いは、システムに落とし込むことを前提としたソリューションを提案、実装するという点です。

既にある要件定義やRFPについて、要望をそのまま受け入れるのではなく、「こうしたらもっと良くなります」というソリューションを提示し、クライアントにとって本当に良いもの提供することを考えることが必要です。

クライアント側は、彼らに十分な提案の機会を与えて下さい。言われたことだけをやってくれれば良い、というスタンスではベンダーと戦略的なパートナー関係を築くことはできず、いつまで経っても運用品質が低空飛行のままです。 コンサルのケースでも述べましたが、雇う側と雇われる側のそれぞれが高い意識を持って臨まなければ、Win－Winの関係など築ける訳がありません。「ベンダーに我々の業務が分かってたまるか」、「クライアントはシステムの門外漢だ」などと思っている方、だったら、それを改善するための次の一歩を踏み出しましょう。

著者紹介

吉澤準特 (ヨシザワジュントク)

外資系コンサルティング会社に勤務。守秘義務を破らない範囲でIT業界の裏話をつぶやきます。ファシリテーション、ビジネスフレームワーク、人材教育など執筆多数。日本能率協会、秀和システムそれぞれから書籍刊行。執筆依頼/インタビューお引き受けします。こっそりITIL Manager (v2)資格保有。

筆者ブログ「IT業界の裏話」

Twitterやってます

この記事は吉澤準特氏のブログ「IT業界の裏話」の過去記事を抜粋し適宜加筆・修正を行って転載しています。