プロジェクトを成功に導く方法
私が、IT業界に身を投じてから既に30年近くになります。その数十年間、関わった開発プロジェクトは数百件にもおよびます。
これら数百件におよぶプロジェクトで、(細かいプロジェクトは忘れてしまいましたが)成功したプロジェクトは、悲しい事に全体の10％位ではないかと思われます。
一般にシステム開発プロジェクトの場合、次の三大要素を満たさなければ成功とは言えません。（三大要素の「頭文字」を取って、「QCD」とも言います。）
・納期(Delivery) ：カットオーバー日(本番運用開始日)
・コスト(Cost) ：開発費用、ハードウェア等の環境整備費用
・品質(Quality) ：機能、性能、障害発生率
さらに、納品した後の業務運用の事も考えると、「保守性能」も重要になります。システムの機能や性能を当初の予定通りに仕上げても、日々の業務運用に支障をきたす様では、最終的に「使われないシステム」になってしまいます。
「保守性能」に関しては、幸いなことに、以前勤めていた会社で、5年間程サポート関連の部署に配属されたことがあり、お客様から、日々システムへのフィードバックを頂くことができました。(その当時は、毎日辛い日々でしたが・・・)
このため、その後は、上記「品質」には、「保守性」も必須であることを認識するようになりました。弊社の主要品質規定には、会社設立当社から、次のような項目を挙げております。
(1)可用性(安定性) ： 連続稼働に耐えうること/途中で停止しないこと
(2)信頼性 ： 障害が起きないこと
(3)操作(使用)性 ： 操作し易いこと/使い勝手が良いこと
(4)保守(メンテナンス)性 ： 保守(メンテナンス)し易いこと
(5)機能性 ： 機能要求を満たしていること
(6)効率性 ： 処理時間、ハードウェア資源等を浪費しないこと
「納期」と「コスト」に関しては、特に説明する必要はないと思いますが、このように、開発プロジェクトを成功させるには、数々の課題があります。
今回は、「プロジェクトを成功に導く方法」と題して、システム開発プロジェクトにおいて、プロジェクトの成否を分ける重要ポイントについて、簡単ではありますが、紹介させて頂きます。
また、品質の内容を、御社業務に関わる部分に置き換えれば、IT業界にかかわらず、全てのプロジェクトにも通じる内容になるのではないかと思っていますので、IT業界以外の方も、参考にして頂ければと思います。
■三大要素に柔軟性を持たせる
当然のことですが、プロジェクトを成功に導くためには、「納期」、「コスト」、および「品質」、どれもが重要項目になります。一つも欠かすことは、できない項目です。
しかし、私のこれまでの経験から言うと、プロジェクトの成否を握る一番重要な項目は「納期」です。
私が関わったプロジェクトで、失敗したプロジェクトのほとんど全てで、プロジェクトの検討を始める前に、カットオーバー日が決まっていました。
さらに悪いことには、目的のシステムに搭載する機能までもが、プロジェクトの検討を始める前から決まっていました。
そして、最悪なのは、「予算」までも上限が決められています。
つまり、プロジェクトの検討を始める前から、「何月何日には」、「このような機能を備えたシステムを」、「いくらの費用を掛けて」動かさなければならない、と言う状況だったのです。
一見、「プロジェクト開始前に、カットオーバー日と搭載機能、および予算が決まっているのは当然のことだ。」と思われるかもしれません。
ところが、この要件(RFP：Request For Proposal)が提示されるのは、「納期」に間に合うギリギリのタイミング、あるいは既に「納期」に間に合わないタイミングの何れかなのです。
「RFP」とは、日本語で略すと「提案依頼書」と言う意味で、システム発注側が、システム受注側(システム開発側)に、提案書の作成を依頼する文章のことになります。
このように、システム開発プロジェクトに着手する前から「納期」に間に合わない状況となっている訳ですから、この時点で、既に「負の連鎖」が始まっていることになります。
「負の連鎖」と言いましたが、システム開発における「負の連鎖」とは、次の様な形を取ります。
【負の連鎖発生条件】
既に「納期」、「機能」、「予算」が決められている（「納期」はギリギリ、「機能」も削れない、「予算」も増やせない）
【影響】
●要求機能を提供しつつ納期を守るためには、製造工数は削れないので、設計工数や試験工数を削るしかない
●設計工数を減らすと、製造工程に入った段階で、
設計ミスが多発 → 製造の手戻り多発 → スケジュール遅延 → 予算がないので人員の追加投入ができない → スケジュールのリカバリーができない → 残業増加 → メンバー疲労 → 脱落者続発 → さらなるスケジュール遅延 → 後工程(試験)にしわ寄せ
●試験工数を減らすと、
試験回数や試験項目の削除 → 障害が発生しても、その場で対応 → 再試験実施せず →システム品質が低下する
【結果】
●納期が遅れてしまう
●納期遅延で開発費増加 → コスト超過
●品質も最低 → バグ修正でもコスト超過
上記のように、プロジェクト開始前から、「納期」、「予算(コスト)」、および「提供機能」を、余裕がない程、ガチガチに固めてしまうと、最終的にプロジェクトは失敗してしまいます。
「機能」は、最終的に「品質」に直結しますので、最初に述べたプロジェクトの三大要素「納期」、「コスト」、「品質」、これら全てが「納期」の影響を受けることになります。
【プロジェクト成功のカギ】
●「納期」が決まってしまっているのであれば、「提供機能」、もしくは「予算」に余裕を持たせる必要があります。
●「提供機能」が決まってしまっているのであれば、「納期」、あるいは「予算」に幅を持たせます。
●「予算」に余裕がないのであれば、「納期」や「提供機能」を柔軟に変更します。
このように、三大要素を必要に応じて変更することでプロジェクトを成功に導くことができまるのです。
プロジェクト開始前に、「納期」、「予算」、「機能」が決まっているのは問題ではありません。プロジェクト開始前には、あらかじめ「納期」、「予算」、「機能」を予想するが当然です。
しかし重要なのは、プロジェクトが始動し、要件設計が完了する前までに、これら三大要素を、見直すことが重要になります。
「納期」、「コスト(予算)」、および「品質(機能)」、どれも重要な項目なので、これらの内、一つでも変更が必要になった場合には、お客様、上司、あるいは経営者等、プロジェクトのステークホルダー(利害関係者)の説得が必要になると思います。
ステークホルダーの説得は、とても難しくて、できれば行いたくない作業ですが、プロジェクトを失敗させるよりは、マシだと思います。
また、ステークホルダーに対して、妥当な資料をもとに説得を試みて変更を承認してもらえない場合、プロジェクト失敗時には、責任をステークホルダーに回避することができます。
これも、プロジェクト・マネージャーにとっては、重要なリスク回避手段になります。
■コミュニケーションの重要性
プロジェクト成功のカギである三大要素を見直せば、プロジェクトは成功するのか?
残念ながら、それだけではありません。実際にプロジェクトを開始すると、予期せぬ出来事が、次から次へと発生します。
各フェーズのスケジュール遅延は当然発生しますし、搭載予定の機能が作成できなかったり、新たなツールの購入が必要になったりと、次から次へと問題は発生します。
この時に重要なのが、メンバーとの意思疎通、コミュニケーションです。
進捗管理表等、目に見える形で問題が明らかになっている場合には、自分で問題解決に動けるので、何とか対応が取ることができます。
しかし、目に見えない部分で問題が発生している場合、この問題が表面化した時には、取り返しのつかない状況になっているケースが多々あります。
この「目に見えない部分で発生している問題」を把握するためには、メンバーとのコミュニケーションが必要になります。
また、メンバーに関しては、メンバーの行動を観察しておく必要もあります。
・遅刻が多くなった
・休みがちになった
・他メンバーと会話しなくなった 等
普段と異なる行動を取りはじめたら「要注意」です。
IT技術者は、一般的にプライドが高く、自分の技術力に自信を持っている人間が大勢います。
自分の技術力に自信を持つのは良い事なのですが、それも程度に「よりけり」です。
自分の能力範囲を超えた部分で問題が発生しても、何とか自分だけで対応しようとするので、その分負荷が掛かってしまいます。
その結果、次の様な、これも「負の連鎖」が発生してしまいます。
●問題発生 → ●自分で解決しようとする → ●残業時間が増える → ●朝、遅刻する → ●その内に休みだす → ●最終的に「うつ病」になる
これが、技術者が職場から脱落していく過程になります。
何か変な行動を取りはじめたら、先ずは他メンバーに、それとなく様子を聞き、それから個別にヒアリングを行うことが重要です。
話を「見えない問題を可視化する」に戻すと、「失敗の兆候」は常に現場で発生します。
このため、現場で作業を行っているメンバーが、一番先に「失敗の兆候」に気が付きます。
当事者意識や問題意識が高く、誰にでも意見を言える人が「失敗の兆候」に気が付けば良いのですが、技術者は、前述の様に、問題を内に抱え込みがちです。
このため、コミュニケーションを取ることで、「失敗の兆候」を聞き出すことが可能になるかもしれません。
プロジェクト・リーダーは、本職のカウンセラーではないので、「失敗の兆候」を聞き出すことは苦手かもしれません。
しかし、現代においては、メンバーの精神的、肉体的な問題点を含め、技術的な問題点を聞き出すこともリーダーに求められるスキルになります。
このためには、常にメンバーを観察し、いつでも声を掛けられる環境を整えておくことが重要になります。
一方、開発案件を発注した側では、このような状況を把握するのは、正直難しいと思います。
進捗会議や定例会等で、相手側(受注側)が、状況を正直に話すとは思えないからです。
それでも、案件を発注した側も、プロジェクトに関しては「当事者」ですので、担当者同士でコミュニケーションを取る努力をすべきです。
「相手が全て問題なしと言っている」、「相手が何も話してくれない」と言う理由だけで、会議を打ち切るのは得策ではありません。
最終的に、プロジェクトが失敗して困るのは、案件を発注した側なのです。当事者意識を持ち、相手から情報を収集する努力が求められます。
プロジェクトが失敗した場合、社内で責任を取るのは、発注側の担当者です。
確かに、プロジェクト失敗の責任は、システム開発会社かもしれません。「会社 対 会社」の責任では、システム開発側の企業が、賠償金を含め、何らかの対応を取ると思います。
しかし、こと社内において責任を取らなければならないのは、「あなた」なのです。
プロジェクト担当者は、相手の言う事を「鵜呑み」にせず、「重箱の隅をつつく」ように質問責めにしろ、とは言いませんが、定例会などの場では、言葉だけの報告ではなく、何か提出物を出させるようにした方が良いかもしれません。
相手(受注)側の反応を確かめる手段としては、「Q&A(質問)管理表」等を活用されるのも一つの手段です。
開発作業を進めて行く上で、仕様の再確認は、よくある事です。仕様確認時、開発側企業の社内で問題点が解決すれば良いのですが、発注者側に、仕様を確認する必要性もあります。
疑問点が無い開発作業など存在しません。少し言い過ぎかもしれませんが、疑問点が無い、と言う事は、開発作業を行っていない可能性もあります。
また、疑問点があっても、開発担当者の勝手な思い込みだけ自己解決してしまい、その結果、本来の仕様とは異なる機能を開発してしまう可能性もあります。
「Q&A(質問)管理表」には、受注者側からの質問と、発注側からの回答を記録しますので、後日、双方にとって証拠(エビデンス)としても活用できます。
つまり、「言った/言わない」と言う問題を解決する手段として、非常に有効な手段と成り得ますので、「Q&A(質問)管理表」は、とても便利なツールです。
「Q&A(質問)管理表」を、発注者/受注者のコミュニケーション・ツールとして活用して下さい。
■まとめ
「プロジェクトを成功に導く方法」として、ここまで説明してきた内容を整理すると、次のようになります。
●三大要素に余裕を持たせる
・プロジェクトの成否は、「納期」、「コスト」、「品質」の三大要素に掛かっている
・特に「納期」は最重要
・最初から三大要素の幅を固定化すると、プロジェクトは失敗する
・基本設計フェーズに入る前に、プロジェクト全体の見直しを行う
・プロジェクトを見直す時には、必ずステークホルダーに報告し、その記録を残す
●コミュニケーションの重要性
・目に見えない問題は、コミュニケーションで発見する
・プロジェクト「失敗の兆候」は、常に現場にある
・問題をメンバーの心の中に秘めさせない
・コミュニケーションを活発にするツールを活用する
・全員で当事者意識を持つ
今回は、プロジェクトを成功に導く方法として、三大要素の説明とコミュニケーションの重要性について説明しましたが、その他にも次のような課題もあります。
・適切なRFPの書き方
・プロジェクト・フェーズの細分化管理
・役割分担の明文化
・目標の共有化
プロジェクト管理は、どの業種でも重要ですので、機会がありましたら、続編を作成しようと思っています。
以上
【株式会社 エム・システム】 本 社 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F TEL : 03-5671-2360 / FAX : 03-5671-2361 盛岡事業所 ：〒020-0022 岩手県盛岡市大通3-2-8 3F TEL : 019-656-1530 / FAX : 019-656-1531 E-mail ： infomsystm.co.jp URL ： http://msystm.co.jp/ ブログ ： http://d.hatena.ne.jp/msystem/ Facebook ： http://www.facebook.com/msysteminc
