コンサルがエンジニアにモノ申す！ヒトが大事だと。
■おひさしぶりのご挨拶
約5年ぶりの投稿になります。水上裕介です。
5年前はエンジニアとしてのキャリアをメインに活動していましたが、最近5年は、ほぼコンサルタントとしてPMOやユーザサイドでの要件定義等に参画することが多い日々でした。
このブログでは、エンジニア・コンサル双方の立ち位置から「真の顧客満足」を提供することに目指す中で、私が日々感じることをアウトプットする場として情報発信させていただきたいと考えています。
さて、私は定期的にブログを更新していく根性や根気がありません（笑）。書きたくなったら書く感じになりますが、なるべく隔週での投稿を目指します。
■コンサルとは？
さて、コンサルとエンジニア双方を5年以上それぞれ経験したことで、コンサル視点とエンジニア視点がよくわかるようになってきました。
まず、コンサルについてですが、そもそもコンサルにもいろいろなジャンルがあると思います。
https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%82%B5%E3%83%AB%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0
■コンサル経験
私の経験してきたジャンルは、総合系やIT系です。
例えば、以下のような案件です。
・公共系の大規模プロジェクトのPMO事務局のメンバとしてSIerの成果物の品質評価
・大手SIerのパッケージシステムの要件定義～リリースまでの開発プロセス管理
PMOやプロセスコンサルなどを通して感じることは、
・PMOは、「ベンダ等の成果物を想像し、モノづくりをプロジェクト目的に沿うように効率的に成果物の内容を誘導していくこと」
・プロセスコンサルは、「ベンダ等の開発方法を標準化（誰でもできるように）することで、ベンダ内に開発・運用（DevOps）を効率的に実施するノウハウを提供すること」
が要諦だと感じています。
私は、モノを作ることが好きなので、PMOよりはプロセスコンサルの方が面白いと感じています。
■エンジニア経験
さて、エンジニアとしては、業務SEやアーキテクト（インフラ/アプリ双方の基盤）っぽい立ち位置を経験してきました。
・業務SEでは、短時間で整理しやすいUMLを使うのが好きで、概念（論理データ）モデルや業務フローをサクッと定義して極力手戻りなく、効率的な開発をリードします。
・アーキテクトっぽい立ち位置では、例えば、JBOSSのBRMSなどのルールエンジン基盤を業務アプリに適用するソフトアーキテクチャの設計/実装やリリースサイクルを高速に回すためのデプロイ環境（Chefとか使って）を構築することなどをやってきました。
ちなみにエンジニアのキャリアを細かくいうと、プログラマからスタート、SE、アーキテクト、業務SEの順に経験を積んできました。
■コンサルに必要なスキル
さて、まだまだ少ない私の経験に基づくので一般論ではない点をご留意いただき、まずコンサルとエンジニアの視点で最も異なる点は、
・モノ視点で考える
・ヒト視点で考える
に尽きると感じています。
モノ視点とは、最終的な成果は、モノ自体（ビジネスデータを構築する仕組み、ネットサービス）を提供することを主眼においており、
ヒト視点とは、最終的な成果は、ヒトの満足（ビジネスを前に進める支援、高収益ビジネスモデル構築支援）の提供を主眼におく。
ヒトの満足を提供するためには、誰が考えるコトに主眼を置くか（キーマンの発見）が重要となります。
また、何をやらないか、やるべきかをスピーディかつ網羅的に整理し、実行するスキルを高めることが大切です。
■これからのエンジニアに必要なスキル
前述したモノ視点のエンジニアは多いと思います。
そもそもモノづくりのポジションを現場で求められているので、自然とモノづくりの視点が身につくのが普通です。
しかし、これからは、よりエンジニアにもヒト視点、つまりコンサルスキルが求められると考えています。
変化の激しい時代も重なり、業務が回らないため、仕様がコロコロ変わる、せっかく作ったモノが使われない状況が散見されます。非常にもったいないし、非効率・低生産性、時間外労働が常態化される原因になったりもします。
そういった状況を回避するためにもコンサルのスキルを学ぶことが重要だと考えています。しかし、エンジニアがコンサルのスキルを身につけるには大きな壁がありました。
次回は、そのブレークスルーの経験をお話したいと思います。
最後までお読み頂きありがとうございます！多分隔週での更新になります。