2023
11/09
WBSと一元管理
「なぜWBSをわざわざ二重で作らないといけないんですか？」
あるプロジェクトでは、ベンダーが細かく丁寧なWBS（Work Breakdown Structure）を作っていました。
システムタスクだけではなく、ユーザー側のタスクまで記載されています。
ここにユーザー側のタスクを追加更新していけば、ユーザーとベンダーでタスクを「一元管理」できます。わざわざユーザー側でWBSを作らなくても、最小限の労力で合理的に進めていくことができます。
情シスの若手Aさんは、ベンダーの依頼を受けて、このWBSにユーザー側のタスクを更新していました。
それを見た私は、すぐさまAさんに更新を取り消して、WBSを自社で作らないといけないと伝えます。
Aさんは全く納得がいかないようで、その後の説明に時間を要しました。
なぜ、自社側でもわざわざ手間のかかるWBSを作らないといけないのでしょうか？
WBSのスコープ
同じプロジェクトであっても「ベンダーWBS」と「ユーザーWBS」では管理対象が異なります。
ベンダーWBSは、システム導入・構築における「直接的」なタスクを管理します。要件定義書や設計書などのドキュメント作成とレビュー、構築フェーズにおいては各種テスト計画とテストなどです。
ドキュメントやシステムなど明確な作成対象があるので、管理しやすいといえます。
一方で、ユーザーWBSは、システム導入にかかわる「間接的」なタスクも含みます。
ベンダー側で認識しているユーザーレビューや受入テストの他にも、多くのタスクが必要となります。
ベンダーに発注するための予算調整、稟議申請手続き、部門間調整、上層部への報告・承認、影響力の強い人物への根回し、他システム連携における担当ベンダーとの調整・予算確保・社内手続き、社内プロジェクト体制の見直し、業務課題の棚卸し、業務フロー見直し、取引先・グループ会社との調整など、多岐に渡ります。
つまり、ユーザーWBSの方が圧倒的に複雑で対象が広いのです。
一元管理における2つの弊害
これら幅広いユーザータスクを、ベンダーにつまびらかに見せてしまってもよいのでしょうか？
大きく2つの弊害があります。
1つ目は、ベンダーに見せてはいけないタスクが多数あること。
例えば、ベンダーから提示された見積もりを承認するプロセスなどは、見せられません。誰が決定権をもっているか、誰が反対しているかをベンダーが把握してしまえば、ベンダーはその人に直接アプローチするかもしれません。
誰が決定しているかを隠すことで、抽象的に「上層部の承認を得られない」とベンダーの提案を拒否したり見直しを促したりすることができるのです。
2つ目は、ユーザータスクの遅れを見られたくないこと。
一般的にユーザータスクは「遅れがち」です。
現場の業務を抱えながら対応するユーザーが多く、十分な時間を避けないことが多いからです。
一方で、ベンダーにも必ず遅れが発生する局面が出てきます。その時にユーザー側が遅れていると、ベンダー側の遅れも大したことないように見えてしまいます。
進捗について、ベンダー側の緊張感がなくなってしまうのを避けたいのです。
プロジェクトにとって、常に遅れは重大責任だと緊張感をもって進めてもらいたいのです。
ベンダーに「ユーザー進捗」という余計な情報をインプットして、時間を拘束するよりも、自分たちのタスクに集中してもらった方が得策です。
ベンダーが進捗通りに進めることで、ユーザー側も遅れを取り戻そうと引っ張られます。
ユーザーとベンダーがお互いに緊張感を持ち、責任範囲を全うすることがプロジェクト成功への近道といえます。
情シスにとっての虎の子
そもそもWBSの「一元管理」がそこまで良いものでしょうか？
確かに労力は削減されますが、「楽をしたい」という手抜き思考が透けて見えます。
自分たちのWBSを苦労して作らなければ、自社の主体性がなくなり、ベンダーに依存するだけです。
さらに、ベンダー側の視点だけでWBSを作ると、ユーザー側で必ず考慮漏れが発生します。
ユーザー側には独自の「社内政治」や「システム環境」や「事業構造」があり、そこから逆算したタスク設定は、ベンダーには不可能です。
では、どうすればよいのでしょうか？
情シスの出番です。
情シスの以下メリットを活かして、WBSを作成していきます。
・ 社内システム導入の経験が豊富
・ ベンダー調整が得意
・ 社内調整で中立に進められる
・ ITと業務の橋渡しができる
・ 自社とベンダーの橋渡しができる
・ プロジェクトノウハウを溜められる
情シスがWBSを作ることは、とても大変でしょう。
しかし、次のような大きな見返りがあります。
・ プロジェクト全体を俯瞰できるようになる
・ 広い視野をもってタスクの漏れや不整合などに気付ける
・ ユーザーにもベンダーにも気後れせず堂々と対峙できる
自信をもって進捗管理をすることで、ユーザーの目には頼もしく映ります。課題があれば、まず情シスに相談するようになります。
その光景を見たベンダーも、情シスにまずは相談するようになります。
すると、情シスを中心にプロジェクトが回りだします。情シスの地位が向上し、ますます攻めの姿勢を加速させることができます。
情シスがWBSを手掛けることで、好循環を生み出せるのです。
覚醒の秘伝書
冒頭の情シスAさんは、自社WBSを作ります。
社内定例会で、自社WBSをもとに進捗管理を始めました。
最初はヌケモレが多かったのですが、徐々にユーザーから指摘をもらえるようになり、課題に対して相談してもらえるようになります。
すると、ベンダー側の反応もあからさまに変わりました。
それまでは、ベンダーはいつもユーザーの方を向いていて、Aさんには背中を向けていました。
ところがユーザーがAさんに相談する光景を見て、ベンダーも態度を改めます。確認や相談があれば、まずAさんに伝えるようになりました。
そして、Aさん自身も覚醒します。
自社WBSを苦労してメンテナンスしているので、ベンダーWBSの不備がよく見えるようになりました。タスクの漏れや不整合を鋭く指摘しています。
それを見たユーザーもベンダーも、ますますAさんを頼りにするのでした。
Aさんは以前よりも自信をもって、かつ楽しそうに見えます。
「自社WBSの重要性を腹の底から理解できました！」
貴社のIT部門・情報システム部門では、ベンダーWBSとは別に自社WBSを運用していますでしょうか？
関連コラム
コラム更新情報をメールでお知らせします。ぜひこちらからご登録ください。
情シスコンサルタント
田村 昇平
情シス（IT部門、情報システム部門）を支援するコンサルタント。
支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。
多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。
また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。
「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。
著書の詳細は、こちらをご覧ください。
