ITアウトソーシングプロジェクトやってみてわかったプロジェクト遂行上の注意点

今絶賛デスマーチ中ですが、これやっときゃよかったという、反省点。アウトソーシングプロジェクトに限らず、どんなプロジェクトでも同じだと思いますが、特に期間が長いプロジェクト特有の事例かと思います。

以下アウトソーシングを提供する立場で記載してます。

目次

契約の単位を考える

わかりやすいパターンだと以下があり、下に行くほど、コントロールがしやすい。

1. 全業務丸ごと一括契約
2. 業務機能毎に個別一括契約
3. 業務機能毎に準委任契約

これら、考えつつサービス仕様書の構成を考える。

• 共通仕様書
• 業務機能A仕様書
• 業務機能B仕様書

これらを決めることで、プロジェクトを進める上での目標が明確になり、顧客、ベンダーの意識が合いやすい。あと、業務をバラバラにすることで、トランジションしやすい。

意思決定の仕組みを作る

週に1回、偉い人を含む会議などを開き、課題進めるにあたって意思決定を一定期間内で必ず行う仕組みを作る。

例)ワーキンググルーピングで議論しまとめる作業を週一回、意思決定者にレビューしてもらう会議を週１回設け、決定事項と未決定実行を管理する。

顧客xアウトソーサーそれぞれ専任者を最低一人ずつアサインする

顧客も、我々も片手間でやっている期間が長かったため、スピード感、決定事項が曖昧になってしまいました。ゆっくり実施もありですがその時は、移管業務をある程度、契約に分割して少しずつ切り出しで移管をしていくやり方が必要。あんまりズルズルやると既存業務が引き継ぎ中に変更が入ったり、新規に業務が追加されたりと、なにがどこまでただしいのかわけがわからんくなる。

プロジェクト計画書のちゃんとした合意

システム構築プロジェクトも一緒かと思いますが、途中でむちゃくちゃな要件変更が起きた場合の対策として、計画書の印刷物に捺印を押してもらうなど印象付けを必ずする。

初回計画書提示後、指摘をもらったものは必ず反映して、必ず承認してもらう。

そして、要件変更があった場合、前段までやってきたことは無効とするぐらいの念押しを記載しておく。

顧客側の体制の構築依頼

責任者、体制と役務とタスクを早い段階からバイネームで文書化する。これをやらなかったので、ヒアリングにおいて「自分は関係ない、あの人に聞いて」とボールの投げ合いが起きて、話が進まなくなった。またジャッジするひとも明確ではなかったので、アイディアはでるがジャッジができないという宙ぶらりんの検討事項が残りやすくなる。

スポンサーリンク

関係者全員を集めた説明会を各フェーズで実施

各フェーズ毎に関係者を集めた説明会を実施して全員のベクトルを合わせる。これを怠ったため、顧客側の担当者でゴールイメージがバラバラになり、客側のやる気がある人は先の先まで見越しいろんなこと問題提起してくるが、全体のバランスがとれなくなるので、議論に偏りが出て、結果全体のまとまりがなくなり、協同作業がうまく進まない。

客側の準備プロジェクト中の担当者の変更は原則なしとする

せめて、体制がかわるとしてもアウトソーシングを意識した体制は維持してもらう。個々の担当者と合意を今までとってきたものもすべてがパーにならないようにこの点は担当者が、かわったとしても決まったことは活きる前提の合意をとる。これをやらないと、顧客側の前任者が合意をとった内容にケチをつけてきて、再検討ということになり、前フェーズのタスクのやり直しになる。

準備期間の契約はフェーズ毎にする

要件定義(基本計画策定)、現状分析、トランジションとフェーズ毎に契約単位を分割させる。途中で中断するリスクを抑えたり、そのフェーズごとのアウトプットを明確化することで、一歩一歩着実に前に進むように契約でコントロールする。
特にアウトソーシングは引き継ぎがほとんどなので、遅れるトリガーもすべて人が原因で、ITトラブルが原因とかにはならない。
ほぼほぼうまく行かないので、遅延した場合の原因が顧客のスピードにある場合の顧客側のペナルティや、免責事項を書いたほうがよい。

それなりの覚悟と行動力が必要であることを顧客に植えつける

受注取り逃しになる可能性もありますが、顧客側にもかなりの労力が伴います。

例えば、アウトソーシング反対勢力への説明や、個々人への説明や説得。

アウトソーシングスタートのタイミングで業務改善はしない(極力)

したほうが受け入れ時に楽になるが、そんなコントロール力を持ってる顧客は稀かと思われる。安定化した業務を引き受けると移管がスムーズ。
まずは、改善を取り込まず、業務を移管しその後安定化したら、改善を検討すべき。

図解 わかる!ITアウトソーシング―組織のスリム化とコア業務への特化戦略で生き残る!