DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

おかげさまで『新感覚！プロジェクトマネジメント』も、ようやく第５０回を迎えることができました！

今回は、カフカ風に「プロジェクトの不条理」を描きながら、過去４９回のうち特にアクセス数が多い１０タイトルを振り返ってみます！（※１）（※２）

【　ある朝　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
私がいつものように電車遅延へのいらだちを引きずったままパソコンを起動すると、ｘｘプロジェクトのプロジェクト・マネージャーへの任命を告げるメールが届いていた。おそらくデスマーチに違いないと嫌な予感を抱きながら、システム開発部長のもとに出向いた。

＜　システム開発部長　＞：「前ＰＭが長期休暇に入ったため、君に頼むしかない。さっそくお客様を訪問して、今後のプロジェクト見通しを報告してくれ。前ＰＭが作った資料があるから、これを元に説明して、あとは空気を読んでかわしてほしい。わしはこれから予算会議だから、あとはよろしく頼んだぞ。」

移動時間を考えると反論などしている余裕は無い。今日のところは怒られるだけ怒られ、戻ってから作戦を練ることにしよう。とにかくプロジェクト計画と現状とのギャップを確認することで、具体的な問題点を明らかにする必要がある。

＞＞＞【第５回】プロジェクト計画と現状とのギャップ具体例紹介

それにしても、システム開発のプロジェクトは、なぜいつもこんな風に、京都ひとり旅のような行き当たりばったりの計画で進めなければならないのだろうか？

＞＞＞【第２２回】京都ひとり旅の計画は行き当りばったりが良いか？

＜　お客様　＞：「バカ野郎！本番稼動を半年延期、開発費用は２倍、わが社のレビューと受入テスト期間を半減なんてプランありえんだろう！もう少しまともな計画を持って出直してこい！もちろん今日中だ！」

おっしゃる通り。いくら見積り前提に魔除けの呪文のような再見積り条項が書かれていても、明確な理由を説明できなければ、何の効力も発揮しない。

＞＞＞【第２９回】見積り前提は魔除けの呪文だった？

【　現状分析　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずはプロジェクトメンバーへのヒアリングなどを通し、現状の問題点をリストアップ。

・3ヶ月の進捗遅延
・お客様レビュー指摘多発、収束傾向無し
・進捗・品質リカバリーのための体制強化により開発コストが増加
・徹夜・休出常態化、プロジェクトメンバーのモチベーションは劣悪

これらの問題事象の原因を追究。

・企画・要件定義の詰めが甘く、お客様レビューにて要件追加が数多く発生
・当社ＳＥのスキル不足により、要件定義書、外部設計書などドキュメント品質も劣悪
・上記問題の検知が遅れたうえ、やみくもに要員を追加して火に油を注いでいる

こんなひどい状態だと、PMBOKなどの従来のプロジェクトマネジメント手法だけでは事態を収拾することはできないか？

＞＞＞【第１回】従来のプロジェクトマネジメント手法は使い物にならないのか？

まだまだ立て直しの計画を具体化するために十分な情報は得られていないな。ここはリプランといえども、プロジェクト計画書の段階的詳細化のアプローチが必要だ。

＞＞＞【第２３回】プロジェクト計画書の段階的詳細化とは？

しかし、あれだけお客様を怒らせてしまっているのに、具体化されていないリカバリ・プランでは、納得感が無い。ここは、今後の各開発工程の完了判定基準だけでも明確にして、どの段階でどのレベルまでキャッチアップするかを示すことで、安心感を演出してみるか。

＞＞＞【第３３回】工程完了判定基準にオフサイドトラップを仕掛けろ！

私はリカバリ・プランのマイルストーンになるはずの工程完了判定基準をまとめ、各ステークフォルダーへの協力を取り付けることにした。

【　難題噴出　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずは開発の大部分を委託しているオフショアベンダーの責任者に協力を要請した。

＜　オフショアベンダー責任者　＞：「状況は理解した。ただし、これまでも何度もやり直しがあり、開発要員を２倍にして対応してきた。まずはこれまでの未払い分の費用をすぐに払ってほしい。今後もプロジェクト状況が不透明なので、現状体制のまま最低１年間のラボ契約とさせてもらえるなら協力する。」（※３）

未払い費用のことは初耳である。オフショアで単価は安いとはいえ、今後１年間ラボ契約で２倍の要員を抱えるのはさすがに厳しい。それに１年間というと当初の本番稼働予定日を越えてしまうため、もし本番稼働日が延期されなかった場合、余剰人員を抱えてしまうリスクがある。しかし申し出を断ると、オフショアベンダーに撤退されてしまうリスクもあり、そうなるとプロジェクトの続行は事実上不可能だ！

＞＞＞【第１２回】プロジェクト・リスクとは何か？

私はオフショアベンダーへの回答を保留とし、お客様の反応とオフショアベンダーからの要請について報告するため、再びシステム開発部長のもとへ向かった。

＜　システム開発部長　＞：「なんだと！プロジェクトが混乱している原因はお客様の要件追加だろ！なんとかして、本番稼働延期と開発費用追加を認めてもらうのが君の仕事じゃないか！オフショアベンダーへの費用追加も構わないが、プロジェクトの損益として赤字は許さないぞ！」

まじか？こんな八方ふさがりの状態がありうるのか？こんなとき第三者のコンサルタントによるプロジェクト診断を実施したら、プロジェクト全体リスクは、既にプロジェクトの続行が不可能なレベルと診断されるはずだ。

＞＞＞【第１４回】プロジェクト全体リスクのマネジメント具体例

【　不条理への挑戦　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
お客様への報告期限も迫ってきた。オフショアベンダーへの回答も保留状態のまま！

こんなときは「もはや引けない、もう戻れない！（The Point of No Return）」ミュージカル『オペラ座の怪人』の劇中オペラの中で、怪人とクリスティーヌが歌うデュエット曲のフレーズが頭をよぎる。（※４）

＞＞＞【第２１回】オペラ座の怪人は、なぜクリスティーヌを奪えなかったのか？

よし！もう何も失うものは無い！お客様、オフショアベンダー、システム開発部長の全てがWin-Winになるようなプランを独自に打ち立てることにするぞ！

まずは現状の根本原因とみられる以下の２点の解消を軸に考えてみた。

・まだまだお客様の要件は固まっていない
・当社のＳＥは日本側もオフショア側も、要件の引き出し・文書化スキルが不足

つまり、このまま当社側でお客様要件を文書化してレビューを受けるというやり方は、完全に破たんしているということだ！

お客様は、レビューや受入テストをしっかりやりたいという意向だ。おそらく、プロジェクトを成功させるためには、お客様自身が作業することに抵抗は無く、むしろ進んでやりたいと考えていることだろう。

オフショアベンダーは、１年間のラボ契約という要望さえ通れば、十分協力してくれる意志がありそうだ。今後も要件追加は避けられないはずなので、開発要員の数を確保しておくのはむしろ好都合かもしれない。

当社の日本側メンバーは既にモチベーションを失っており、事実上戦力外だ。システム開発部長は、当プロジェクトの損益が赤字にさえならなければ、何も文句は言わないだろう。

よーし、「お客様を巻き込んだスパイラル開発」と銘打って、次の方針で進めてみよう！（※５）

＜お客様を巻き込んだスパイラル開発　基本方針＞

１． 本番稼働日、開発費用は、当初計画通りを目標とする
⇒　まずは姿勢を見せて、信頼回復への第一歩

２． 業務要件は、お客様主体で文書化していただく
⇒　お客様自身による要件固めと当社の弱点回避を同時に実現

３． オフショアベンダーによるプロトタイプ作成～お客様のレビュー兼テストのスパイラルを短期間に何度も回すことで、要件確定と実装を同時に進める
⇒　オフショアベンダーの有効活用とお客様のレビュー・テストの十分な期間確保

４． 当社の日本側体制は最低限に縮小し、大幅なコストダウンを図る
⇒　お客様に文書化とテストを協力いただくことで実現可能

５． 上記スパイラルをお客様と共同で進めることで信頼回復を図り、本番稼働時期、開発スコープの見直しも含めた現実的なカットオーバー・クライテリアを模索・合意する
⇒　これでリプランの段階的詳細化を図る

＞＞＞【第３４回】カットオーバー・クライテリアとは何か？

お客様の信頼回復ができれば、要件追加に見合った開発費用追加も認めていただけるに違いない。それに、これだけ混乱した状況を考えると、初期リリース後もそれなりの規模の保守開発が必要なはずであり、オフショアベンダーのラボ契約を無駄なく活用できる道も開けるはずだ！

そうなれば長期的に見て、当社の売上増など業績にも貢献できる。さらに今回の事例を新たな低コスト開発モデルに育て上げることで、競合他社に対する差別化も夢ではないぞ！

さあ、「お客様を巻き込んだスパイラル開発」リプラン案をもって、いざ出陣だ！（※６）

「プロジェクトマネジメントは、絶え間ない不条理との戦いである！」

・・・

いかがでしたか？

最後のキーメッセージは、「不条理」を「リスク」と置き換えてもいいかもしれませんね！

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「プロジェクトの不条理」については、「ＩＴの達人（林 衛達人のコラム）　プロジェクトの条理と不条理」　も参考にしてください。

※２　「変身 (カフカ)」『フリー百科事典　ウィキペディア日本語版』
2015年3月19日 (木) 00:06 utc http://ja.wikipedia.org/wiki/変身 (カフカ)

※３　ラボ契約とは、オフショア開発における契約形態のひとつで、たとえば３ヶ月３０人月など、一定期間に発注する最低の仕事量をあらかじめ決めておくものです。
オフショアベンダーとしては期間内の最低受注額が保証されるため、開発要員のリソース確保が行いやすく、オフショア利用側としてもその工数内で臨機応変にいろいろな作業を対応してもらえるメリットがあります。しかし、その期間内に仕事を切り出せなくても、あらかじめ決めた最低保証額を支払う必要があります。

※４　「オペラ座の怪人 (1986 ミュージカル)」『フリー百科事典　ウィキペディア日本語版』2015年3月18日 (水) 20:06 utc http://ja.wikipedia.org/wiki/オペラ座の怪人 (1986 ミュージカル)

※５　「スパイラルモデル」『フリー百科事典　ウィキペディア日本語版』
2013年4月9日 (火) 15:50 utc http://ja.wikipedia.org/wiki/スパイラルモデル

※６　このブログはフィクションであり、実在する、人物・地名・団体とは一切関係ありません。