コンサルタントの日々学び

日々のデリバリーで得た体験、ノウハウ、教訓とかを週次ベースで書き留めていきます。

システム開発で溢れる課題と2つのリソース不足

学び

システム刷新プロジェクトの開発フェーズでの一場面。
「解決しないといけない課題があと700個も残っている」
「課題はまだまだでてくるのに、週に10個も解決できていない」
「残りの期間は2ヶ月…どうしよう」

プロジェクトに関わったことがある人ならあるあるではないだろうか。

開発時点でシステムと業務とのGapがでてきた。
システムでの実装方法は2通りあるが、どちらも異なる業務の負荷は発生する。
この機能を使おうとすると、意図しない範囲の人まで情報が見えてしまう。
現行のシステムの中身を見てみたら空欄や不整合なデータが入っていて移行できない。

開発を進めていくほど課題は多く出るがなかなか解決が図れない。
「パッケージにある機能をそのまま使う」と方針を立てていたとしても上記のような課題は必ずでる。
そして課題を解消しきれないまま期限がきて、プロジェクト稼働時期を見直す。
もしくはそのまま稼働につっこみ大混乱を招く。
よくある失敗プロジェクトの王道だ。

 

なぜこのような事態を招くのか。
要因はいろいろある。
要求定義やベンダー選定など上流にも要因はあるが、ここでは開発工程、いわゆる下流での要因を紹介しよう。
それはプロジェクト参画メンバーの2つの不足がある。

 

1つは業務やシステムの方針を意思決定できるリソースが充分でないこと。
上記で書いたような
「開発時点でシステムと業務とのGapがでてきた、どうするか」
「システムでの実装方法は2通りあるが、どちらも異なる業務の負荷は発生する、どちらを選ぶか」
というような意志決定は現場の担当者やシステム部だけでは意思決定できない。
業務部門の課長以上の人がプロジェクトに参画し意思決定する必要がある。
なぜなら、決めたことが今後の業務や関係者の負荷、はたまた他部署への影響にも及ぶからだ。
だが、えてしてうまくいっていないプロジェクトではその層の参画が不足している。
「現場のことがよくわかっている運用担当者が参画していればいい」
「開発はベンダーがやるんだからプロジェクトには兼任で顔を出しておけばいい」
そう考えた結果、挙がってくる無数の課題を解消しきれなくなる。
うまくいくプロジェクトでは、販売・物流・生産の領域なら、各領域の課長クラスが専任でプロジェクトに参画する。
それだけでなく、事業所ごとに生産方式が異なるなら、上記に加え事業所の生産担当にも兼任で参画してもらう。
これくらい意思決定できる体制を設けてはじめてプロジェクトが前に進む。

 

もう1つの不足は「プロジェクト経験者」だ。
上記のような意思決定は「出てきた課題をつぶしこむ」動きだが、プロジェクトでは先手先手でのリスクの潰しこみも重要だ。
「でてくる課題はまだ収束傾向にないので意思決定者のリソースはまだまだ確保が必要」
「今後結合テストや受入テストで運用担当のリソースが必要になるから前もって確保しよう」
「新システムの教育も意識変革と操作への慣れの2段階があるからこれくらいから動こう」
「並行稼動を見込むと新旧システムへの2重入力が必要になる、それに向けた入力簡易化のツールを準備しよう」
など次に起きることを予測し、関係者の協力を仰ぐ、必要なタスクを準備する手を打つ必要がある。
だが、プロジェクト経験したことがない人にはこの勘所がない。
今後起きうる事態が見極められないためどうしても後手に回ってしまう。
後手に回るとまた課題が溢れ出し、手に負えなくなってしまう。
このような先手を打った動きをとるためにも、プロジェクト経験者が参画しておく必要があるのだ。

 

ただ、「意思決定できる人材」は会社・業務にとってもキーマンである。
「プロジェクト経験者」も、たいていの会社ではプロジェクトは数年に1回のイベントであり、稀有な存在だ。
そのため、なかなか担当部署や該当者と話をしてもリソースを確保しづらいのが実情だろう。

その解決策はトップダウンの意思決定しかない。
会社全体の中で「どこにリソースを割くべきか」を判断し、決定できるのはトップしかいないからだ。

このときに困るのが、トップがことの重要性を理解していない場合だ。
過去にプロジェクトの経験がない、もしくは失敗プロジェクトの経験はあるがただしく振り返りを行っていないトップに重要性を理解してもらうのには骨が折れる。
ひたすらトップへの啓蒙が必要となってくる。
例えば、過去の失敗プロジェクトを振り返り、リソース確保の重要性を理解してもらう。
ことの重要性を理解している別の役員などから説得してもらう。
他社でうまくいっているプロジェクト・うまういっていないプロジェクトの事例から情報を出していく。
または実際にうまくいっているプロジェクトにコンタクトして、リソース状況やその重要性を会話する場を設けるのも策だ。

 

「こんな大変なことをやらないといけないのか」と感じる方もいるだろう。
だが、プロジェクトは始まる時点で大方勝負は決まっている。
開始時点で必要なリソースを確保できるかどうか。ここであらかたプロジェクトの行末は決まっているのだ。
はじめにトップの啓蒙含めリソース確保に走る大変さ。
そして開発フェーズになって溢れでてくる課題に対処しきれず頭を悩ます大変さ。
両者を天秤にかければどちらを行動すべきかはそう難しくないはずだ。