社内情シスとコンサルの対立構造 及び担当者目線でのコンサル対策
今回は社内情シス担当の私がコンサルとどうして対立してしまうのか、システム開発のフェーズごとに問題点を記載します。
※システム更改時に担当PMとしてコンサルを選定後、案件推進を行うイメージで記載。
大きく下記３つのフェーズに分けて概要を説明後、担当者目線で対策できることも説明していきます。
①提案フェーズ
②契約フェーズ
③実装フェーズ
フェーズ毎の問題概要
①提案フェーズ
～発注側が要件を整理のうえ、発注先の企業を選定するフェーズ～
コンサル側は社内のリソースをフルに活用して、競合他社を圧倒する提案資料を作成し案件を勝ち取る。初期メンバは単価の関係でいつの間にかいなくなっており、後続フェーズのクオリティ低下や言った言わないの水掛け論の原因となる。
②契約フェーズ
～提案フェーズの内容をもとに、作業と諸条件を契約書に落とし込むフェーズ～
契約書作成に際してコンサル側はリスクとなる記載を避け、明確に定義できない作業は変更管理（追加の発注）で対応させようとしてくる。提案フェーズでの口頭の「できると思う」のような前向きな発言は当然契約書には反映されず、成果物のイメージに乖離が生まれてしまう。
③実装フェーズ
～契約書の作業スコープに則って成果物を作成するフェーズ～
プロジェクトが低単価のジュニアスタッフにコントロールされながら、デリバリーセンタや再委託先などこれまた低単価な作業員によって実装が行われるフェーズとなる。
契約内容の履行のみを目指す機械的なチームとなり、発注者側の当初想定からの乖離が深まっていく。前フェーズの問題が顕在化するのもこのフェーズである。
対立構造と担当者としての対策
①提案フェーズ
フェーズの位置づけ
一般的な企業はシステムなどの大規模な投資を行う場合、適切なベンダを選定するためにベンダ比較を行う。よく行われるのは担当者が既存の取引や、Web上の情報をもとにベンダのショートリストを行い、残った数社には案件の詳細情報を提供して実装計画提出してもらい、比較のうえ最も条件のよいベンダに発注するというものである。（RFI, RFP）
対立原因
1.1 コンサルによる口頭のオーバーコミット
1.2 有識者の限定的なアサイン
1.1 コンサルによる口頭のオーバーコミット
このフェーズではコンサルファームも案件を受注するために、提案するソリューションで実現できるメリットや、そのファームだからこそ可能な数々の魅力を語ってくる。それらは後続フェーズでの要件や制約がコンサルの想定内という前提での話なので、あまり聞くに値しない話なのだが、発注側の担当者も案件を前に進める必要性があるため、コンサルの受け売りで社内調整を進めてしまうというのが良くあるベンダ選定の裏側なのだと思う。
対策：提案のプレゼンや質疑の際はすべて議事録に残し、書面に記載されていることのみをベースに業者の選定を行おう。口頭で調子のよいことを言っていたコンサルも、文書に残るとなると裏どりに労力を割くため正確な情報を引き出すことができる。
発注担当者も複数企業を相手に選定を行うので、なかなか時間が割けないというのも分かるが、重要な論点に限定してでも文書化するべき。
1.2 有識者の限定的なアサイン
コンサルファームはそのスケールメリットを活かして、卓越した有識者を召喚することができる。テクノロジー子会社や関連企業をグローバルで従事させることができるため、圧倒的知見と実績に裏打ちされた提案資料を持って案件を獲得する。
その有識者は単価も卓越した金額なのであろう、提案フェーズが終わり次第案件から姿を消してしまい、プロジェクトの前提が変わってしまったり詳細化をする際に、誰も適切な知識を持たないということになるのである。
対策：案件の推進体制は契約上明記して、キーとなるポジションの変更には両者の合意を必須とするなどの条件を設ける。
ニッチな分野で知識の属人化がひどい場合は別候補を選定したり、リスクを会社として許容したうえで選定する必要あり。
発注担当者もコンサルを選定した後は、一蓮托生の立場で案件を進めていくことになる。提案フェーズでは発注側の方が有利な立場で物事を決めれるので、徹底して足場を固めて後続フェーズに進みたい。
②契約フェーズ
フェーズの位置づけ
ベンダ選定後は契約を結ぶフェーズとなる。提案資料をもとに、契約書にスコープ、諸条件、金額などを記載して両者で合意する。金額の支出のため、案件担当者は支出権限のある役職者の社内承認をもらう必要がある。コンサル側も担当のパートナーから承認を取り付けて両者の契約を行う。
対立原因
2.1 コンサルファームのリーガル部署の頑固さ
2.2 タイムライン
2.1 コンサルファームのリーガル部署の頑固さ
スコープや納品物自体は提案書の通りなのでそこまでこじれることはないが、諸条件（機密情報管理、著作権、支払い など）のすり合わせが難しいケースがある。
外資コンサルファームは契約文化で、ビジネス側と対等以上に権限があるケースがあり、契約文言のすり合わせに時間がかかってしまうケースがある。他ITベンダであればOKと言ってくれる文言でもなかなかOKが出ず、法務関係者との調整が必要となると、情シスの人間としてはゲンナリしてしまう。
対策：契約文言が変わることでどのようなリスクがあるのか把握し、時にはコンサル側の主張を呑むなど、無駄な時間を使わないような立ち回りを行う。
また、提案フェーズに契約のドラフトを提出させることで、折り合いがつかなそうなコンサルファームは選定から外すなど、自社の立ち位置次第だがいくつか打ち手はある。
2.2 タイムライン
契約文言の調整も時間を浪費する原因となるが、やはりコンサルファームは金額が高いので、価格の妥当性について指摘が入る可能性が高く、価格交渉に時間を要することが多い。
当然契約書をドラフトした段階でスケジュールが記載されており、見込みの契約締結日を超過するとスケジュールを引き直しとなってしまうため、両者が関係部と再調整を行う必要が出てしまう。
特にコンサル側は契約前の段階では費用が持ち出しなので、すぐに対応を進めるようにプレッシャーをかけてくることがあり、そのまま社内調整を進めようとすると、次は社内の人間からコンサル側の人間と思われ強烈に反発をくらうこととなる。
対策：契約前は発注側の立場が強い段階なので、スケジュールを厳守するというより、しっかりと議論をし尽くしたうえで契約を締結するように対応するのがよい。
一方で投下時間と品質はトレードオフになるため、締結を急ぐというマネジメントの意向があるのであれば、リスクを許容して進めるのも手ではある。ただし、担当者の立場としてはしっかり時間をかけたいという頑固のキャラを演出した方が、JTC的な評価制度では映えるケースが多いと思う。
③実装フェーズ
フェーズの位置づけ
最後は契約を締結した後のシステム開発、テスト、リリースといった実装のフェーズとなる。基本的には合意したスケジュールで成果物を作成してもらい、クライアント側も合意したスケジュールで検収を行い、問題なければ支払いをするという流れとなる。
前フェーズでしっかりとした契約が巻けていれば、リスクが顕在化した場合もコンサル側に転嫁できているはずなので、気持ちとしては余裕が持てるはずである。一方で様々な制約下で妥協していたり、そもそも１００％リスクを予見した契約を締結できるはずもないため、発生した問題が契約上カバーされない類だと非常に苦労することになる。
対立原因
3.1 ジュニアスタッフの品質不良
3.2 問題解決不能
3.1 ジュニアスタッフの品質不良
前述した通り、導入フェーズではコンサル側の有識者は姿を消し、低単価のジュニアスタッフが開発者を管理するかたちで作業が進む。
ひどい場合はほとんど知見０の新人が上司に言われるがまま管理資料を作って、開発部隊との伝言ゲームをしているような状態となり、管理方法を指導（質問責めにして訂正させる）しないと大変なことになるケースもある。
※正直、コンサル側の人材育成に加担しているようなもので、やるなら自社の新人を使いたいので複雑な想いである。またコスト削減のためにジュニアスタッフを現場に野放しにして、クライアントに迷惑をかける（実際は迷惑というより、付加価値が一切なく言われたことも最低限の品質でしかできない）コンサルファームの姿勢にモヤモヤする。
（ちなみにコンサルの指南書には新人はPMO業務から始まるという記載があるが、実態は、議事録、課題管理、会議室予約、打ち合わせ設定などの雑用であり、本質的なプロジェクトリスク管理に携われるわけではない。
キャリアを総合コンサルからスタートする方も多いが、正直自分のシステムでもなく、プロジェクト期間だけ駆り出されてPMOという名の雑用をすることになるので、事業会社側でドメインナレッジを獲得する方がよいのではないかと思う。社内情シの私に言われる話でもないと思うが。。）
対策：ある程度諦めて、自分で手を動かす前提で工数を確保しておくのが現実的。契約時に管理帳票のフォーマットや記載粒度を指定するなど、できるだけコンサルが動きやすいようにお膳立てするのもよいが、結局準備に時間がかかるのでケースバイケース。
3.2 問題解決不能
問題が発生した場合、仮設と検証およびマネジメント報告は見事であるが、結局無駄なステップばかり踏んで問題の解決に時間がかかるケース、最悪解決できないケースがある。（知見があるスタッフがいれば仮説など立てるまでもなく解決する。）
前述のとおり有識者がコストの関係でプロジェクトから放出されているため、問題解決力の高いメンバが不在の可能性が高い。
対策：コンサル側から対応策が提示された際に、情報ソースを徹底的に確認をする。不確かな情報をもとに対応を検討してもすべて時間の無駄となる。可能であれば有識者を引っ張り出してきて対応させるのが効率的で、オフィスに物理的に呼び出して作業してもらうなど、コンサルファーム側の事情は気にせずプレッシャーをかけ続けるようにする。
あとがき
今回は概要レベルの記載となったが、各フェーズでの実践的な対策についてもまとめていきたいと考えている。
また、別途具体的な事例を紹介しつつ、本音ベースで所感を記載したいと思う。