予見できない「不確実性」乗りこなせるかが成功の鍵
ここ十数年、世の中では「プロジェクトベース」での仕事の進め方が浸透し、それに伴ってプロジェクトマネジメントの必要性が広く認識されるようになりました。
プロジェクトマネジメン卜の専門資格であるPMP(Project Management Professional)の有資格者数も増えています（2006年末に1万8009人だったのが、2013年4月には3万448人へと増加）。
特にソフトウェア開発やシステム開発の世界ではプロジェクトベースで仕事をするのが当たり前になり、ノウハウや経験が蓄積されてきました。
しかし、こうした状況にもかかわらず、多くの開発の現場では状況が大きく改善されているようには見えません。企業単位で見ればやはり数％ほどトラブルプロジェクトや炎上プロジェクトと呼ばれるものがあることでしょう。
件数で数％といっても、こうしたトラブルや炎上はとても大きく爪痕を残します。
①利益率の大幅低下
②組織力の弱体
③エンジニアの離職
と言った形です。そもそもトラブルや炎上を起こすまで手をこまねいていたマネージャー、ラインの管理職たちです。トラブルになっても、スマートに解決する方策を持ってはいないはずです。そもそもそんなスキルがあれば炎上する前の焦げ付き始めた時点で策を講じることができていたでしょうから。
①は当然のように起こります。サブスクリプションならばともかく、Ｂ２Ｂで開発を請け負う多くはただでさえ平均利益率6～7%と言われるＩＴ業界です。10%もいけば企業として相当順調と言われるような業界ですから、大きくマイナスを出してしまうトラブルや炎上プロジェクトはダイレクトに利益率の低下に影響を与えます。
②はもっと深刻です。ＩＴ企業の多くはおそらく「売上」と「利益」で評価の大半を決めている企業がまだまだ多いことと思います。①の影響を大きく出した部署は当然ながら大幅に評価が下げられます。プロジェクトマネジメントに大きく関わった人たちの"やり方"に問題原因があるだけのはずが、連帯責任のようになってしまってそのままモチベーションの低下や、チャレンジ精神の減衰につながってしまいかねません。
そして①や②と連動して③へとつながっていくことになります。まともな"やり方"ができている人にとっては、そこに居続ける方がデメリットにしかならない可能性も高いわけですから仕方ありません。
そもそも、
・評価軸が収益しかなかったり、収益が大方を占めていたり
・個人評価の前に、部門評価で上限が決まってしまっていたり
・上司に評価を一任してしまっていたり
するから、トラブルや炎上するまでロクに管理もせず、察することもできないような管理職しかいない部署では完全にハズレくじを引いたような状況になってしまいます。
そんな人を昇進させる評価軸やそんな評価軸を容認する経営陣というのも相当アレですけど、一番の被害者はそこで働く人たちだということを忘れてはいけません。
「会社」とは器ではなく人です。人の集まりです。
売上や利益を実際にあげてきてくれるのは労働者たちです。彼らがはたらきにくい（売上や利益をあげにくい）環境しか作れないようでは経営や管理をする資格はありません。
では、なぜこんなにも絶えずトラブルや炎上プロジェクトが起こり続けるのでしょうか。本当に「失敗は成功のもと」を体現できていれば、１度はともかく、何度も、何年も絶えず起こり続けるわけがありません。
仮に過去のトラブルプロジェクトが
「すべて原因が異なっていた」
「一つとして同じ原因になることはなかった」
というのであればまだ納得もできますが、残念ながら
どこでも同じような失敗を、何度も、何年も繰り返し繰り返し起こしているにすぎません。つまり、失敗は成功のもとになんてまったくなっていない、というわけです。
なぜこんなにもＩＴ業界、ひいてはソフトウェア開発を担う企業、経営陣、管理職、マネージャー、エンジニアは学習しないのでしょうか。
端的に言えば、そもそもプロジェクトマネジメントをしていない、あるいはする気がない…と言うことなのかもしれません。それはマネージャー以上の責任者たちだけでなく、プロジェクトマネジメントを実際に体現するエンジニア達にも言えることです。
しようと努力している人もいます。
それでも機能しないことにはいくつかの要因があります。
技術の変化が激しく、速い
ＩＴ分野の技術は他の技術分野に比較してその変化が非常に激しく、速いという特徴があります。ムーアの法則(半導体の集積密度は18~24 カ月で2 倍になる)に代表されるように、ハードウェアの進化速度が指数関数的に向上するなかで、それを利用するソフトウェアにも機能や性能面で大きな進化が求められています。
また競合他社に先駆けて新技術を使ったり、技術者魂が新たな技術を求めたりと、ソフトウェア開発のプロジェクトでは既に実績のある「枯れた技術」だけではなく、「社内でやったことがある人がいない」技術に取り組む機会が多いのも事実です。
新たな技術への取り組みは、それ自体がリスクとなります。
そこまでハードルは高くないと思っていたのにやってみたらトラブルが続出した…という経験は、ＩＴエンジニアなら経験したことがある人もそこそこいることでしょう。
要求が変化しやすい
要件定義段階でベースラインとして設定した仕様が、そのままプロジェクトが完了するまで維持されるプロジェクト…というのはほぼないといっていいでしょう。規模が大きくなればなるほど仕様が固定化されたプロジェクトは皆無に近づきます。
お客さま自身がニーズを整理しきれていないということもあるのでしょう。
ソフトウェアはその名前が示すように、ハードウェアに対比して「柔らかい」「変更しやすい」イメージを持たれています。ハードウェアの設計を変更した場合は、部品の変更や廃棄などコストが目に見えるカタチで発生しますが、ソフトウェアを変更してもドキュメントやソースコードの変更などコストの発生が見えづらい側面を持っています。そのため要件の変更要求が出やすい傾向があります。
しかし、システム開発に携わったことがある人なら分かるように、ベースライン設定以降の要件変更には大きなコストとリスクが伴います。料理を途中まで作っている最中に、全く違う味付けやレシピを要求されるのと似ているかもしれません。
特にプロジェクト後半における要件変更には、要件定義段階での変更と比べて５～100倍ものコストがかかると一般に言われています。ソフトウェアは言われているほど決して「ソフト」なものではないのです。
見積もりが難しい
システム開発の難しさの大きな要因の一つに「見積もりの難しさ」があります。ハードウェアと異なり、ソフトウェアの機能を実現する方法は無限にあります。
この不確実性コーンは1981年にバリー・ベームが発表し、後にスティーブ・マコネルが命名した、ソフトウェア開発の各段階での不確実性を示した図です。
この不確実性コーンはウォーターフォールで開発することを前提としているため、その対策の１つとしてアジャイル開発モデルがあるのは言うまでもありませんが、アジャイルはアジャイルで様々な課題を抱えており、きちんと準備のできていない中で挑戦し、失敗していくプロジェクトも後を絶ちません。
さらに言えば、設計、コーデイングの結果というのも実施する人によって千差万別です。同じ機能を100行のコードで実現できる人もいれば、1000行、2000行のコードで実現する人もいます。実現方法の自由度が非常に高いのです。
このため、同じ機能を実現するために、どれだけの時間(工数)が必要となるかを、正確に見積もることは非常に難しいという側面を持ちます。
そのうえ(2)でも説明したように、要求が変化しやすい性質を持っているため見積もり段階で正確な工数や金額を導き出すことは不可能です。これによって発生するトラブルや赤字を「ハザード」と呼びますが、ハザードを起こす具体的なリスクを特定し、対策を打たないままに、ざっくりとお客さまの財布の限界まで予算を搾り取るだけの見積りの仕方では、想定通りに終わらせることが可能かどうかも予測できません。
見積りが難しい所以です。
短納期の要請が強い
システムはビジネスの要請に応えるために構築されます。
ビジネスは市場の変化に適応することが求められるため、市場の変化スピードが速くなれば、それに伴ってシステム開発スピードに対しても高速化が求められることになります。
企業の情報システムだけではなく、たとえば携帯電話やデジタルカメラ、カーナビゲーションなどの組み込みソフトウェアの分野なども同様です。製品サイクルが短くなり、システム開発の短納期化に拍車がかかっています。納期が短ければ、トラブルやリスクを吸収できる時間的余裕がなくなり、コストの余裕もない状況でプロジェクトを運営しなければならなくなります。
小さな失敗が命取りになる可能性が高まるわけです。
さらに無茶な納期設定をすると、現場では「必要なプロセスを省く」方向に力が働きます。本来必要なものであるにもかかわらず省くわけですから、トラブルの可能性がぐんと上昇します。
このとき、真っ先に省かれるのが「設計(書)」と「テスト」です。
コーデイングしながら設計したり、単体テストが省かれたりするのです。
必要なプロセスを省けば、必ずどこかにしわ寄せが来ます。
途中までうまくいっているように見えたプロジェクトが終盤になって急に大幅な遅れが発覚したり、品質の問題が発覚したりするケースはたいていこれが原因です。
業務改革を伴う
企業の情報システムを構築するときは一般に、単に現状の業務をＩＴに置き換えるのではなく、業務の「あるべき姿」(To-Be) を描いて業務を改善する必要があります。
中には、業務改革のきっかけづくりとして企業情報システムの構築プロジェクトを利用したいと考える経営者も多くいます。このあるべき姿について議論できない人は、システム化の検討に加わるべきではありません。
しかし、企業の「あるべき姿」には決まった答えがあるわけではなく、またあるべき姿を思い描いても、それだけで業務が改善されるわけではありません。
さらに、いくらあるべき姿を思い描いてシステムを構築しても、業務そのものが…即ち人がシステムについていかなければ意味がありません。
つまり、あるべき姿を思い描くまでのプロセスは企業ごとに異なり、どれくらいの時間(工数)を必要とするかが見えにくく、思い描いた後も「どこまでできるのか」を考える必要があるということです。
企業が持つ情報システムの構築は「業務改革」や「環境改善」…いわばそこにかかわる人々の意識の改革と切っても切り離せないものです。業務改革のスコープ（範囲）が、システム構築のスコープに大きく影響するからです。
しかし、この業務改革ほど工数が見積もりづらいものもありません。
このため、業務改革に引きずられて、システム構築のQCDが大きく影響を受けることになります。
マネージャーが定め、定めたとおりにメンバーが活動できるように環境を整え、メンバーが定められたとおりに遂行する。この相互のはたらきが円滑に行われて初めて『マネジメントが機能した』と言えます。マネージャーが一人突っ走るだけでも、エンジニアが勝手気ままに活動するだけでも、マネジメントは容易に破綻します。
プロジェクトマネジメントについて深く考えるためにはまず
「プロジェクトとは何か」
をしっかりと押さえておく必要があります。対象への理解がボヤけた状態でのマネジメント（管理）などありえません。だから、ここが常にボヤけている管理職や経営陣が治める組織や企業では、いつまで経ってもトラブルや炎上プロジェクトがなくなりませんし、減りません。
具体的に、プロジェクトとはどのような仕事を指すのでしょうか。
米国プロジェクトマネジメント協会による「PMBOK Guide」では以下のように定義しています。
独自のプロダクト、サービス、所産を創造するために
実施される有期性のある業務
表現が小難しいので分解してみましょう。
プロダクトは製品、サービスはそのままサービスです。「所産」が分かりにくいですね。所産とは英語で表記すると「result」すなわち「成果」あるいは「生み出されるもの」です。つまり、プロジェクトとは「何かを作ったり生み出したりするための活動」ということです。
プロジェクトには、最終的にアウトプットしなければならない成果物と、最終成果物を生み出すために必要となる中間成果物を作ることが求められます。
スコープとは、最終成果物と中間成果物の集合体を指します。
プロジェクト定義の冒頭に出てくる「独自の」という言葉が意味するところは、「同じものが２つとない」ということです。
たとえば、自動車の製造ラインでは同じ規格の自動車を大量に生産します。作られる自動車は規格が統一されており、同じ車種の自動車はすべて同じように作られます。このような量産プロセスが生み出すものは独自ではないので、プロジェクトとは呼びません。
一方、ビルを建設するときなどは、まったく同じ場所にまったく同じビルを建てることはありません。ＩＴシステムの場合も、同じシステムを繰り返し１から構築することはありません（まったく同じモノで良ければ、コピペで済みますからね）。
このような繰り返しのない、一度きりの取り組みで、一つひとつ異なるアウトプットを生み出すこの特徴を「独自性」といいます。
「有期性のある」とはどういうことでしょうか。
これは「始まりがあって、終わりがある」ということです。自動車の製造には、明確な始まりも終わりもありません。生産の中止はあるかもしれませんが、最初から決められたものではありません。
一方、プロジェクトには必ず「期限」があります。システムのカットオーバーには明確な期日が設定されています。携帯電話などの組み込みソフトウエアを含んだ製品は、納期の遅れがそのまま市場での競争の遅れにつながります。
明確な始まりも終わりもない日常的な業務は定常業務です。
プロジェクトが定常業務化しているケースもありますが、
その場合は、プロジェクトとしての存在意義と継続の是非を判断しなければなりません。
まとめると、三つの要素
「明確に定義されたスコープ」
「独自性」
「有期性」
を持つもの。それがプロジェクトです。
これらの特徴をもう少し平たく表現すると、プロジェクトとは以下のように言い換えることができます。
プロジェクトとは
やったことがないことを、
何が起こるのか分からないのに、計画して、
予定通りのモノ(コト)を、期限まで作る(終わらせる)こと
これはかなりやっかいな要求であることが分かるでしょう。
まず知っておいていただきたいのは、まさにこの「プロジェクトとは難しいものである」ということです。現場で納期や不具合に追われる立場にあるプロジェクトマネージャーやエンジニアは、プロジェクトに求められるさまざまな難しい要求に応えられなければなりません。
プロジェクトマネジメントに求められていることを最も抽象的に、簡単に説明すると、
プロジェクト遂行中は、
常に「明確に定義されたスコープ」「独自性」「有期性」を維持する
できない事態に陥った場合は、再計画し、
改めて「明確に定義されたスコープ」「独自性」「有期性」を維持する
端的に言えばこれだけです。
これをプロジェクトチームのメンバー一人ひとりが実現できるように、プロジェクト完成までの全体像を計画し、ルールや進め方／手順を詳細に定義し、状態や状況をつぶさに監視し、計画とズレたらすぐに調整(コントロール)する。
マネージャーに求められているのは、その役割と責任、そしてそれらを遂行する権限です。プロジェクトは不確実であるからこそ、ほんのちょっと目を離したすきにとんでもない方向へ転がっていってしまいます。
だからこそ、何らかの形でマネジメントすることを任命された管理者、管理職は、そのことだけに注力する気概が必要になります。そして任命する責任を持った経営陣は、そうしたマネジメントができる人材を育成し、最適な配置を行っていかなければならないのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。