プロジェクト成功までに必要なもの
これまで数多くのトラブルプロジェクトに関わってきましたが、その中で学んだことの１つに
『必ず成功するプロジェクト』というものは存在しない
というものがあります。不確実性や独自性も相まって、過去の実績に過信し、同じような進め方をすれば失敗する…というのも嫌と言うほど見てきました。成功率を高めるためには
計画性、計画実現性を高める努力
臨機応変に対応できる準備力
フットワークの軽いコントロール力
相手の協力義務（PM義務）を刺激する巻き込み力
が須らく備えられている必要があります。
もちろん数千万程度の中小規模であれば、いくつか欠けていても数名の頑張りで何とか出来てしまうかもしれませんが、億を超える規模になってくるとそうした個人頼みの進め方ではどうすることもできなくなってきます。組織的な足並みが狂っている状態を数名の頑張りでどうにかする…というのは現実的ではないのです。
少なくともプロジェクトが成功するためには必ず満たさなければならないいくつかの条件があります。しかしこれらの条件がプロジェクト開始の時点ですべて揃っているなんてことはまずありません。もし揃えられているとしたらよほど「プロジェクトマネジメント」の重要性を理解している企業や顧客が揃っているということになるのではないでしょうか。
逆に言えば、
何もないところからこれらの条件を揃えることが
（プロジェクト）マネージャーの仕事
になる、ということです。
顧客および経営層のコミットメントがある
始める前から困難となることが予測されるようなプロジェクトであっても、最終的に成功するプロジェクトにはプロフィットセンター（利益を提供してくれるもの）…すなわち顧客と経営層のコミットメントが必ず存在します。
丸投げしてプロジェクトマネージャーやリーダーが勝手に孤軍奮闘して成功するのではなく、「やりぬくためなら何でもする」「現場のパフォーマンスを最大値化させるのが我々の仕事」という顧客や経営層の自覚、覚悟とバックアップがあるのです。
それが用意されていないプロジェクトでは、大抵現場で悲鳴が上がってきます。
先日、あるプロジェクトにて
このご時世でも、平気で夜の20時や21時から会議をしようとし始め、しかもそこから「明日の朝までに」議事録を書いてよこせ、と言ってくる元請けベンダーがいた。
なんて話を聞きました。まぁ私がプロジェクトのリーダーやマネージャーをしていた2012年までにもそういうSIerやベンダーはいました。あの時代だからまだ許容された風土でしょうが、いまだにそれを「強要」する企業がいたんですね…。自分で好きにやる分にはまだしも、他人に強要するのは色々コンプラ意識としては破綻しているとしか言いようがありません。
このような方々をもコントロールしていかないと、プロジェクトはいずれ大きなヒビができて、壊れていくことになりかねません。
なかでも組織改革を伴うような大掛かりなシステム構築プロジェクトは、このコミットメントが欠かせません。そのプロジェクト中、およびプロジェクト終了後にこのシステムに関わる人がとてつもなく大きいからです。
たとえばプロジェクトマネージャーは、プロジェクトを成功させるために最もキーとなる『メンバー』に対しては指揮命令の権限を持っています。しかしメンバーではないライン業務、定常業務に就いている方々を直接的に動かす権限は持っていません。
各部門の部長は、自部門の部下に対して指揮・命令する権限を持っていても、間接部門を含む他部門への直接的な指揮・命令権はもっていません。稀に勝手な判断をする権限が与えられていると勘違いしている人もいるようですが、企業が会社法に則り、組織と体制を構築している以上そんなことはありえません。
それだけではなく、白分より立場や役職が上位にある人たちにも動いてもらわないといけない場面も多くあります。
システム開発には業務改革が伴うケースが多く、中には抵抗勢力となる人たちもいます。最終的にそういった人たちを動かすのは組織の本気度であり、それは経営層のコミットメントによって表されるものとなります。
経営層が自らコミットメントを表明してくれればよいのですが、そのようなケースばかりではありません。プロジェクトマネージャーは、そうした経営層に働きかけ、
「このプロジェクトは経営層がバックアップしている」
ということを組織内外で知ってもらう努力をしなければなりません。ここで
「それは自分の仕事じゃないし」
と思ってしまうと、プロジェクトは歪んだまま進み続けることになってしまいます。プロジェクトマネージャーはただ数字や進捗を管理する人のことを指すのではなく、プロジェクトを成功に導くため
（顧客や経営層を含む）現存するリソースを最大限駆使し
成功率を高める「やりくり」を実施する人
でなければなりません。
このことを今一度、自覚しなければなりません。
ユーザー主導とする
よくある失敗プロジェクトの原因ランキングでは常に上位に位置する
「受動的対応」
指示待ち、仕様待ち、自ら提案するでもなく、進めるためにファシリテーターになるでもなく、ただただ待ち続けるだけのプロジェクトチームです。
そういったプロジェクトでは、失敗した際のいいわけに必ず
「お客さまが仕様を出してくれない」
「お客さまのレスポンスが悪い」
という理由を述べます。間違いなくTOP3には入っていることでしょう。
こういうプロジェクトは得てして「視る（監視する）」ことが疎かにされている場合が多く、経営層、管理職、プロジェクトマネージャー、その他誰も視ていないからこそ受動的であっても誰も指摘をしないまま進みます。
システムを構築するときは通常、顧客であるユーザー企業とＩＴベンダーそれぞれでプロジェクトを編成して進めることになります。このとき、ユーザー企業がどこまで本気で、どこまでプロジェクトに関わるのかが、プロジェクトの成否を大きく左右します。
一般的にはユーザー企業のなかでプロジェクトを発足した時点で、きちんとした体制が組まれているはずですし、そうしている企業は開発する側としても信用できます。
通常は、このようにＩＴベンダーが受注する前からお客さまのなかではプロジェクトが発足しているはずで、そのプロジェクトの「ＩＴ投資が必要な部分だけ」がアウトソージングされているにすぎません。
開発側である私たちエンジニアは受注してからがプロジェクトのはじまりだと勘違いしている人も多いですが、ＩＴプロジェクトは顧客の中の業務改善プロジェクトの一部でしかないことを知っておく必要があります。だからこそ本来は「ユーザー主導」でなければならないのです。
いうまでもなく、情報システムは企業のニーズを満たすためにあります。
「何を作りたいのか」「どのようなものが欲しいのか」はお客さまにしか分かりません。
またお客さまのなかにもさまざまな利用者が存在し、そのニーズは一様ではありません。立場や部署が異なればニーズも異なります。
システムを構築するには、これらのニーズの優先順位を判断し、ＱＣＤ（品質、コスト、期限）のバランスを取る必要があります。この判断はお客さまにしかできないことです。ＩＴベンダーはソリューションの提案をすることはできても判断をすることはできないのです。
ユーザー企業から「プロなんだから、いい感じにしておいて」と丸投げされたり、逆にＩＴベンダーの考えるソリューションを押しつけたりと、十分な議論と検討の時間を取らず、納得のいく合意を得られないままシステムを構築してしまえば、実際の利用者からは「こんなシステム使えない」とそっぽを向かれるような事態を招いてしまいます。
仮にいったん目の前のプロジェクトは売り上がるとしても、その後10年20年を見据えた場合のそれぞれの会社に与える損失は何億、何十億になるのか予想もつきません。
ユーザー企業にとっては、大金を投資したにもかかわらず何の改善・解決もできないまま負債を抱え、しかも償却期間が過ぎるまでは次のＩＴ投資も難しい…ビジネスチャンスを棒に振ってしまうことになるかも知れません。
ＩＴベンダーにとっては、今後パイプの太い顧客となっていたかもしれないのに、満足度を高めることもできず、多くのビジネスチャンスを棒に振ってしまうことになるかも知れません。その機会損失額はいかほどになることでしょう。
また、ＩＴプロジェクトを成功に導くには、プロジェクトメンバー以外にもさまざまなステークホルダーの協力が欠かせません。しかし、開発側からはお客さま側の社内事情が非常に見えづらく協力を取り付けるには限界があります。
そのため、ＩＴベンダーに丸投げしたままで放置されたプロジェクトが成功することはまずありません。なんとか納品に漕ぎつけたとしても、延焼を食い止めただけで焦げ付いたプロジェクトにはなっているでしょう。
ユーザー企業がプロジェクトを主導し、かつベンダーとの連携がうまく取れていることが、プロジェクト成功の大きな条件の１つです。プロジェクトマネージャーは、コミュニケーションの粋を駆使して、ユーザー主導となるように誘導しなければならないのです。
目的と目標が明確である
プロジェクトには「明確な」始まりと終わりがあります。
期間的にも。
予算的にも。
成果的にも、です。
しかし、「やらないといけないから」という理由でなんとなく始まるプロジェクトが多いのも現実です。
実際、メンバーの中には
「なぜそのプロジェクトが必要なのか」
「なぜその作業（成果物）が必要なのか」
を上司やマネージャーから教えてもらっていない人が多いのではないでしょうか。プロジェクトマネージャー自身がよく理解しないまま「今までそれでやってきたから」という理由で選択していたり、「それはやったことないから」という理由で作成するべき成果物を作成しないということも多いでしょう。
なによりその説明責任を果たさないだけでなく、説明できるほど知見を持っていないこともあるかもしれません。
また、ＩＴベンダーのなかでも「成功する／しない」という論点を無視した経営層や上司の「予算内に収まらないとダメ」というピンポイント観点に振り回されて、するべきことをしないまま進めて失敗するプロジェクトもでてきます。
なんとなく始めたプロジェクトは目的と目標があいまいなため、何をすべきかも明確にすることができません。何に重きを置いて仕事して良いのかもわかりません。
目的意識が芽生えなければ、どうしても受動的にならざるを得ません。
目的とは「何のためにプロジェクトを進めるのか」という理由であり、目標とは「目的を実現するためには、どうなっていれば成功していると言えるのか」という基準です。
たまに、各部門の管理職がプロジェクト活動に対して売上や利益を目的や目標にする人を見かけますがこれは大きな間違いです。それは経営的な目的や目標であって、お客さまがプロジェクトとして発注し、私たちがプロジェクトとして請け負った目的や目標にはなり得ません。
これを履き違えると、ただの数字至上主義、ただのノルマ制になりすぎてしまい、時に不誠実な請求すらも罪悪感なく行うようになってしまいます。
逆に言えば、目的と目標の定めるベクトルこそが
プロジェクトのスコープ（範囲）
プロジェクトの成否
を決定するといってもいいでしょう。目的と目標が定まっていないプロジェクトはいつのまにか実行すること自体が目的化し、「頑張ったけど成果は分からない」プロジェクトになってしまいます。また「それが当たり前」と誤解したまま歳をとっていくことになりかねません。
コミュニケーションコストを惜しまない
お客さまの置かれた状況、お客さまの経営層が持っている要求などによって、情報システムのあるべき姿はまったく違います。お客さま自身のビジネスモデルを左右するものですから、当然と言えば当然です。最悪の場合、企業の浮沈がかかっている可能性だってあるわけです。
私たちベンダー、エンジニアは、システムの構築の仕方について広い知識は持っていますが、そのお客さま企業にとって最もふさわしいシステムの姿について、はじめから答えを持っているわけではありません。
この「あるべき姿（ToBe）」は、プロジェクトの構想段階でお互いにさまざまな議論を尽くすことで初めて見えてきます。
そしてこの議論には大きな時間を要します。
それぞれ、業務、部署が異なる人たちが議論するため、使っている言葉の説明からしなければならない場面も多くあります。
たとえば、「利益」という言葉１つとっても、財務部門と営業部門では意味していることが異なるかもしれません。
売上総利益（粗利）であれば「20%以上となっていれば十分」と思えるものでも、経常利益で計算すると赤字…ということにもなりかねないのです。
ちなみに、私が１社目にいた頃は、
「原価は88%以上使ってはならない」
と教えられました（たしか…88%だったはず…うろ覚えだけど）。これは販管費や営業外費、その他諸々を差し引いても黒字収支として残すためのギリギリのラインだったのでしょう。こうした数字は各企業それぞれ持っていますので、当時のこのラインが他の企業でも適用できるわけではありませんが、それくらい一言で「利益」と言っても、色々あるのだということは知っておいてください。
そういった言葉の定義を合わせることから始めなければならないため、認識を合わせ、議論し、あるべき姿のイメージを合わせるためには途方もない時間が必要になるわけです。
しかし、ここでコミュニケーションコストを惜しめば、プロジェクトが進むにつれ、
「自分がいったのはそういう意味じゃなかった」
「こんなこともできると思っていたのに」
など、認識にズレが浮き彫りになってきます。せっかく大きな予算をかけてシステムを作ったとしても、結局利用されないものになりかねないのです。
一般的に、プロジェクトには予算と納期があるため、先を急ごうとしてしまいがちです。しかし、あとになってから議論することはできません。議論は始める前にしておく必要があるのです。
成功しているプロジェクトでは、構想段階でコミュニケーションコストを惜しまず、議論に時間をかけています。そうすることが成功要因の１つとなりうることを十分に理解しているからです。
ＱＣＤが現実的である
よく尋ねられるのが
「最初から無理だと分かっている納期や予算でも、
なんとかする方法はないだろうか？」
という質問です。残念ながら現実的ではないQCD計画を、プロジェクト発足後にどうにかできる魔法の杖や銀の弾丸は存在しません。
私はよく「時間軸を歪めることはできない」と表現します。
たとえば、工数見積もりが30人月の見積もりがあったとしましょう。
３人なら10カ月、５人なら６カ月で終わらせることができる計算です（あくまで計算上ですが）。
これを３人×５カ月で終わらせることはどう考えても不可能です。
あるいは、0.2人分のパフォーマンスしか出ない要員を充てるから５ヶ月で終わらせろと言われても不可能です。
しかし、現実にはこのような無茶・無謀なＱＣＤが設定されているプロジェクトは多いのが事実です。自らがプロジェクトマネージャーやリーダーだった頃はそうした無茶ぶりがどれだけ苦しかったかを知っているはずの上司や経営層も、自らが出世してしまうと同じ穴の狢となってしまう…ということは往々にしてよくあることです。真っ当な対策法を学ばせてもらえずになんとなく出世してしまったりすると、真っ当な対策法を持たないまま成長することも無く、真っ当な対策を考えることすらしなくなってしまうのです。
こうした無茶なＱＣＤが設定されたとき、それが無茶であることを会社や上司に理解してもらうことも、プロジェクトマネジャーの重要な役割です。
そのためには
「なぜ無茶なのか」
「どれくらい無茶なのか」
を明確に、かつ論理的に説明できなければなりません。
私はトラブルなどが起きた際、その後の取組みや品質上問題がないことを説明することを
証明
と呼んでいますが、同じことをここでも求められます。「無理」「できない」と言うのは簡単ですが、その判断と決断に根拠が伴わなければ他人を説得することはできません。
根拠の証明は、いわば数式の証明問題と同じですから、ある意味で理系的な感性が必要となるでしょう。
算数のように、左辺に問題式をもってくることはありません。ここでは「問題を解く」ことが求められているわけではないからです。既に「解答」はあります。あとはなぜその回答に至ったのかを筋道を立てて説明するだけです。
しかし、言語化し、相手が理解できる言葉で説明するためには、多くの文法とボキャブラリも必要になってきます。これは文系的な感性がとても重要になってきます。
採用する際などは、どうしてもプログラミング脳を求める傾向があるため理系的な学生を優遇しがちですが、歳を取り、役職が上がるにつれて本当に必要になってくるのは、
理系的な感性 ＋ 文系的な幅の広い言語化能力
です。ＩＴ企業において本当の意味で大成するためには、ハイブリットでなければなりません。
プロセスが設計されている
上に挙げた５つの条件を満たすために、非常に役に立つのが「プロセスデザイン」という考え方です。「プロセスのフレームワーク」「業務の仕組み」と言ってもいいでしょう。
こう言ったことは、ソフトウェア工学の一環として学生時代に学んでいる人がいるかもしれません。そう言ったことを学ぶ機会が無かった人は、ソフトウェア工学、ソフトウェアアーキテクチャについて、これから学んでみると良いでしょう。
そもそも、「ソフトウェア開発の進め方はどうあるべきなのか？」を知らなければプロセスデザインを設計することもできませんし、プロセスデザインを設計できなければ何をどうマネジメントすればいいかもわかりません。
また、プロセスデザインには
「広義のプロセスデザイン」
「狭義のプロセスデザイン」
があります。
広義のプロセスデザイン
ここで定義するところのプロセスとは、プロジェクトよりも上位の概念であり、組織変革や事業戦略なども含んだプロセスを指します。
たとえば、ある企業が競争環境の変化のなかで生き残りの戦略を考えたとき、データの活用によって他社との差異化を図ろうとしたとします。データを活用し、強みにまでするには、情報システムの再構築が必要です。これに伴い、業務プロセスの見直しや組織の改編、さらには社員の意識改革までが必要となります。これは一つのプロジェクトでやり切れるようなものではなく、大きな企業変革のプロセスとなります。
このプロセスをどのタイミングで、誰を巻き込んで、どんな順番で進めれば成果につながるかを考えるのが「広義のプロセスデザイン」です。
つまり、成果を生み出すまでの道のりを設計するということです。端的に言えば、ビジネスモデルを１から考えるようなものと言ってもいいでしょう。
狭義のプロセスデザイン
ここでいうところのプロセスとは、プロジェクトマネジメントのプロセスや開発プロセスのことを指します。
狭義のプロセスデザインでは、組織の業務やプロジェクトを「プロセスの連鎖」とみなします。イメージ例としてアローダイヤグラムを想像してください。
プロジェクトは「情報」や「成果物」をインプットとして、それを加工してアウトプットを生み出す作業と成果物の連鎖によってできています。この「つながり」がうまく設計できていなければ、プロジェクトの途中で仕事が滞ったり、手戻りが発生したりします。
また、プロジェクトの計画を立てる際にも、このプロセスが設計されていなければ、計画は「絵に描いた餅」になってしまいます。
計画自体が絵に描いた餅となる → 計画性がない
計画を実現する実力がない → 計画実現性がない
ということです。どちらも、これからなにかを任せるにあたって信用も、信頼もできないということです。「計画通りにいかない」ことを言い訳にしている人の多くはこのどちらかです。
計画通りにいかないことが前提でも、計画通りに進めようと努力できる範囲内くらいには現実感のある計画を立てなければ、計画を立てること自体に意味が出てきません。
それに"だからこそ“計画の中には「リスクマネジメント」という考え方が含まれており、計画通りにいかないリスクに対して様々なケースを想定し、準備し、段取りを決めて起き、いつ何時でも対応できるようにしておくことが求められているわけです。
ですので、そもそも最初から計画通りに進める気がない計画はコストの無駄遣いでしかありませんし、計画というものに対する向き合い方がその程度にしかできない人はマネージャー（物事を統括し、やりくりする者）を名乗る資格がないことを意味します。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。