「プロジェクト成功への組織力強化」 技術士/PMP 井野 弘
<この文書は私が、2008年にあるＩＴ会社の周年記念誌に寄稿したものです。内容はＩＴ萌芽期からの経験を踏まえた全体的なふり返りです。多少古くてもあえて手直ししていません。>
- はじめに
- １．プロジェクト成功は永遠のテーマ？
- ２．今までのプロジェクト成功への試行錯誤と反省
- ３．プロジェクト成功への３つの力
- ４．真に役に立つ組織力の発揮とは？
- ５．組織力を如何に強化するか？
- おわりに
はじめに
近年、ハードウェアは集積技術を中心とした圧倒的な技術進歩による価格破壊でコモディティ化した。インターネットの驚異的な進展によるネットワーク化、Web化も進み、携帯電話の高機能化も劇的に進化し、結果的にＩＴ応用は一昔前には考えられないレベルに拡大・深化した。しかし、この間の劇的変化に比較して、その構築を担うＩＴプロジェクトは相も変わらぬ状態で、失敗することが少なくない。金融システムや社会的インパクトの大きいシステムなどでも、ちょっとした品質不良等で大きな問題を引き起こすことが珍しくないし、一般企業においても公表されない失敗プロジェクトは数多い。
プロジェクトを失敗させないために、誰もがすぐに思い浮かべるのはプロジェクト・マネジメントをうまくやることであろう。プロジェクト・マネジメントは、元々は米国の軍や宇宙開発で発展してきたものであるがその手法の適用も含め、現在も多くの企業が、試行錯誤しながら充実すべく継続努力している状態である。
本稿では、こういう状況を日本のＩＴ業界の現実のプロジェクトの問題・課題と捉え、打破するために今、企業レベル、組織レベルで何を考え、何をどのように行うべきかについて考察する。
本稿の結論は、「プロジェクト・マネジメントに深い関係を持つ組織力を強化すべき」であるが、現実の企業においては、ヒト・モノ・カネ・ジカンに限りがあり、その中でどういう注意をしながら投資・整備・強化すべきかを念頭において述べる。
１．プロジェクト成功は永遠のテーマ？
１９６０年後半（昭和４０年代前半）から、ＩＴプロジェクトは失敗を繰り返してきた。この間約４０年間で、ＩＴプロジェクトが対象とする応用分野は圧倒的な多様化と広がりをみせ、プロジェクト規模は大きくなり、プロジェクトに対する要求レベルは厳しくなる一方である。ますます短くなる要求開発期間、基幹業務への使用や不特定多数の消費者が直接ユーザであるための高性能・超高品質要求、そしてオフショアの台頭を契機にした低価格化等々、要求は止まるところを知らないエスカレーションの歴史である。プロジェクト失敗をなくすための企業努力や関係者各個人の工夫に対し、対象となるプロジェクト要求が厳しくなる一方であることの「イタチゴッコ」を繰り返してきたし、今後も繰り返し続けるであろう。
若干古いが最近の調査でも、例えば、「日経コンピュータ・2004/11/17のＩＴプロジェクトの成功確率は３０％」という特集記事があり、2006/3 JUAS（社団法人日本情報システム・ユーザー協会）のアンケート調査でもQCD(Quality, Cost, Delivery)の全てが日経コンピュータの特集記事と大差ない傾向を報告している。図１にJUASの工期についてのアンケート結果データを抜粋引用する。ここで注意すべきことは、「ある程度予定通り完了」という部分がかなり大きい比率を占めていることである。これは、いろいろ事情はあろうが、「予定通りではない」ことを意味しているのであり、厳密にいえば遅延したと思われる。費用、品質についても同様傾向のデータが報告されているが、割愛する。
この数値は、過去に感覚的に感じていた程度とさほど変わったものではない。母数のプロジェクト数が指数関数的に増加している中で、「成功するプロジェクトは３０％で、７０％は成功とはいえない」ということが以前と同じような感覚であるとしたら、プロジェクト成功のための努力は、よく頑張ってきたといえるのかもしれない。しかし、逆に抜本的な対応策がないとみるほうがより適切ではないか。つまり、「プロジェクト成功への決め手」は、今だ、探し当てることができていないし、その兆しすら見当たらないと言わざるをえない。
２．今までのプロジェクト成功への試行錯誤と反省
１）カミ（紙）の山
多くのＩＴ企業やユーザ企業は、プロジェクト失敗を繰り返さないためにいろいろな試行錯誤をしてきた。古くは、とにかく開発作業の標準化を行うとか品質管理手法を応用するといったことが中心であったが、その後プロジェクト・マネジメントの手法を取り入れる必要性を強く感じ、取り組んできた。そして、それを軸にしたプロジェクト要員の教育・訓練を強化することによって克服しようともした。
しかし、古い時期は現実的には紙ベースでの形式知化しかできない時代であり、その種の組織的活動を頑張れば頑張るほど、「カミの山」ができることとなり、その中身を実作業で活かすには、カミの山を作ることをはるかに上回るエネルギーと知恵と粘りが必要であった。暗黙知に基づく作業の進め方は、元来日本人の得意な分野であり、形式知をベースにした運営は、どちらかというと不慣れであったことにもよる。このDNAは、現在でも濃厚に継続している。
いずれにしろ、現在のイントラネット、Webベースの環境、e-Learningやツール類の手軽な状況と比較すると圧倒的に低レベルのインフラ環境であった。このインフラの進歩をうまく活用すれば、今や「カミの山」の弊害を克服する道は開けてきている。
２）再利用・部品化
古くは、応用ソフトウェアを構成する機能レベルより更に下部の部品としての共通サブルーチンをどのくらい汎用的に作成・再利用していくかに注力した。プロジェクト内での共通化は当然行われたが、プロジェクト横断で共通化することは、使用するコンピュータの種類やOSによって調整が必要になるという事情があった。これらを克服するには組織的な動きが必要であるが、必ずしも十分ではなかった。そういうボトムアップのアプローチでなく、トップダウンで業務機能から汎用化して来たのがERP(Enterprise Resource Planning)であり、欧米で確立されたものが多い。
日本では元々、そのレベルでは企業には個別事情があり使用することは無理という感覚があったが、SAPの出現以来、パッケージソフトの使用は当り前の時代になってきた。ＩＴの本質的な特徴である、再利用の御利益を享受できる究極の方法である。ただ、無理にパッケージソフトに合わせた業務改革の失敗とか、標準パッケージであるのにアドオンする機能が多すぎて、パッケージソフトである利点を活かし切っていない場合も多い。
一時期は、CASE(Computer Assisted Software Engineering)ツールで生産性・品質を追求することが流行ったこともあるし、４GL(4th Generation Language)でプログラミングを容易にすることも行われた。最近では、Object指向が定着し、Java言語でプログラミングすることにより、部品化されたものを再利用する仕掛けは相当成熟して来たといえる。残念ながら、筆者はこのあたりの最新事情は詳しくは分からないので詳細は割愛させていただく。
３）手段の目的化
ここ１５年間前後は、ISO9000、PMBOK、P2M、CMM(I)、ITIL、共通フレーム、ITSS、とグローバル化の流れにのった考え方や方法が採用され、経産省や業界主導の共通化努力がなされてきた。
この時期、筆者は1993年７月に当時の日本ＤＥＣ社で、日本で初めてのソフトウェア開発組織におけるISO9001認証取得の担当責任者として活動した経験がある。当時、応用ソフトウェア開発の標準化を図り、プロジェクトマネジメント・プロセスを確立することを主目的で整備・推進していたが、本社（米国）からの指示でISO9000認証取得を早期に達成する必要が出てきた。そのため、認証取得を目的にしたプロジェクトを興し、開発部門や購買部門等の関連部署を巻き込んで、客観的視点に耐えられるプロセスをルールやガイドラインとして構築し、それに沿って各プロジェクトが実行するという進め方をした。世界的にもまだ認証取得はまれで、日本ではどこも達成できていない状況であり、どうしても早い時期の認証取得が意識の上で強くならざるを得なかった。
端末からのファイル共有などはできる状況であったが、相変わらず「カミの山」を作り、「黒船が何月に来るぞ～」という脅しの論理で現場を動かすという、今考えても芸のない方法であるが、結果的にはプロジェクト目標である「目標時期に認証機関の認証を得る」ということは達成した。目標時期に認証取得を達成する必要はあるが、ISO9000認証取得の本来の目的は、「システム開発の品質保証体制とプロセスを確立し、高品質のシステム開発を行うこと」である。目標時期に認証取得することは、この本来目的達成のための手段である。
今振り返れば、目的を「目標時期に認証機関の認証を得る」と設定した瞬間に「手段の目的化」が進んでしまったのである。手段が目的に変化した場合、時間が経つと本来の目的達成はすっかり忘れられ、達成した目的（手段）による直接的な御利益が眼に見えてこないことなどと相俟って妙な脱力感が支配してしまう。果ては、更に形骸化してしまい、惰性でメンテナンスしているだけ、ということになってしまう。
そして結果的に、そういう進め方への反省でなく、そういう課題の取組みに対して、組織全体または経営者が懐疑的になってしまい、その後の新しい課題に対する取組みに消極的になってしまう弊害が染み付いてしまう。そうなると、その後の真に必要な事柄や正しいタイミングでの判断を誤らせることに繋がってくる。目的設定が不適切であることによって、せっかく英知を集め多量のエネルギーを投入しているにもかかわらず、悪循環（Negative Spiral）を突き進む構図になってしまうのである。ISO9000認証においては、多くの企業で上述したと同様の事態に陥っているケースが少なくない。最近のCMM(I)のアセスメント等でも今後同じような状況が発生するのではないかと心配しているが、杞憂に終わることを願っている。
４）人を鍛える
「プロジェクトはプロジェクト・マネジャーの腕次第で成功・失敗は決まる」ということがある。
極端な場合は、だからこそプロジェクト・マネジメント・プロセスなど最低限度に止め、人材の発掘や教育に全力を傾けるべきといった考えの経営者も少なからず存在する。確かに、プロジェクトにおける人の果たす役割は重大であり、個人能力による失敗・成功の可能性はかなりある。環境変化は常に前提にしなければならない以上、人が適応すること、そのために教育・訓練する必要性は永遠に止まることはない。
しかし、個人力に全てを委ねることは、プロジェクト・マネジメントでいう「リスク・マネジメント」が欠如する訳で、当人が何らかの不都合な（事故、病気、ケガ、想定通りにパフォーマンス発揮できない）場合、そのプロジェクトはリカバリーが不可能になる。個人力は重要であるが、個人に頼りすぎることは、極めて危険なことなのである。
近年、日本でも大手企業中心にPMI(Project Management Institute)が実施するPMP(Project Management Professional)資格の取得が叫ばれ、結果的には相当数増加した。この資格試験は、PMBOK(Project Management Body Of Knowledge)という形式化された（ドキュメントになった）プロジェクト・マネジメントの考え方・方法の理解をベースに試験するもので、現在では世界的にDe-facto Standardになっているものである。PMIの発表では2007年8月末時点で、世界で247,698名、日本で20,462名のPMP取得者がいる。ここ数年で急速に増加してきた。
取得者が増えたとはいえ、「それによりプロジェクトがうまくいくようになったとは思えない」といった苦言を耳にすることがある。当り前のことだ。どんな物事でも知っているだけでは、実行できるとは限らないし、結果を出すことに直結する訳ではない。しかし、先人の知恵や経験を知ることは、知らないより間違いなくよいことである。いわば、知識は必要条件であるが、しかし十分条件ではないということだ。
そういう基本的なことを置いて表面的な現象論、結果論だけをあげつらって批評する人こそ、問題である。
３．プロジェクト成功への３つの力
プロジェクト成功のためには、単にプロジェクト・マネジャーを鍛えただけでは不十分である。プロジェクト・マネジメント・プロセスを標準化してこれを徹底的に実行させるだけでも不十分である。筆者の意見では、３つの力があり、それぞれを強化し、それぞれをバランスさせ、関連性を確保しながら底上げしていく必要がある。
１）３つの力
過去数十年間の企業努力の積み重ねにも拘らず、圧倒的な情報化時代の中でＩＴプロジェクトが失敗するケースは増えこそすれ、減ることはなかった。
2003年の拙著「プロジェクト成功への挑戦＜３つの力＞」でも述べた、こういう状況を打開し、抜本的に成功確率を上げるために、少なくとも「激変する要求とのイタチゴッコ」に遅れない対応をすることが必要である。３つの力をバランスよく強化することが重要である。何故バランスさせるかというと、実現不可能な改革・改善を回避し、確実な実現を漸進的に進めるためである。
漸進的であることは、必ずしもゆっくりやるということではなく、無理をしないという意味合いである。以下拙著からの引用でプロジェクト成功への３つの力を図２に示す。
３つの力の関係を、例え話で解説すると分かり易いかも知れない。昔の田舎芝居のイメージに近いかも知れないが、「リーダー力」は主要な役者の技量・力量であり、「PM組織力」は芝居小屋や舞台装置や台本の整備力であり、「経営力」は興行力・企画力・宣伝力といったところである。台本については、リーダー力の一部と見るべきかも知れない。役者の力量は観客に直接アピールし、その芝居の出来を最終的に決定するものである。しかし、その役者を際立たせる舞台装置や台本がよくなければ宝の持ち腐れになってしまう。その両者が優秀であっても、興行センスが悪く、興行場所・時期が不適とか、宣伝が稚拙であることにより客の入りがよくなければ、いくら立派な芝居ができても満足のいく結果には行き着かない。
３つの力は、それぞれを強化・ブラシュアップする必要があると同時に、相互に依存関係を持つものでもある。
２）ＰＭ組織力
ＰＭ組織力とは、プロジェクト・マネジメントを実際に行う時に、企業として整備しているプロジェクト・マネジメント・プロセス（プロジェクト実行のためのインフラ）の成熟度のことである。単にプロセスを定義し実行させるということではなく、可能な限り自動化するとか、サポーティブなやり方が望ましい。
プロジェクト・マネジメントはプロジェクト成功のための主要要素であることは間違いないが、その割には企業によってそのプロセス整備の程度には差がある。PM組織力が低いほど、プロジェクト・マネジャーに多くの負荷がかかり、その純粋な個人能力に依存していることになる。
プロジェクト・マネジメント・プロセスは、PMBOKで定義している９つのエリア＋契約マネジメント＋見積・提案プロセスを対象としたプロセスであり、プロジェクト・マネジャーの仕事を支えるインフラである。図２で示すように、PM組織力はリーダー力を支え、経営力によって支えられている。
３）リーダー力
プロジェクトの成否は最終的には人次第である。いくら環境が整っていても、逆に問題だらけの環境やプロジェクトであっても、それを切り盛りするプロジェクト・マネジャーやプロジェクト・メンバーの個人の資質、能力、スキル、人間性、やる気、（運？）などによって結果は大きく変わってくる。特にプロジェクト・マネジャーが顧客や社内上層部、プロジェクト・チームを適切にリードできるかどうかが最重要である。リードする力とは、方向付けし、関係者がその方向に向かって一致協力するように仕向けることであり、その上で実際のプロジェクトの推移に沿って、常にプロジェクト成功に導くあらゆる方策をとることである。
リードする力には、いわゆるリーダーシップを発揮できる能力のほかにも、交渉力、コミュニケーション力、問題解決力、社内外への影響力といったものが含まれる。リーダー力を効果的に発揮するためには、プロジェクト・マネジメントの基本知識を持ち、それを適切に応用できることが基本要件である。また、プロジェクトの中でクリティカルな位置を占める技術がある場合は、その内容を理解・把握することが求められる。同時にそのプロジェクトが対象としている業務内容についての知識・能力も、多くの場合必要である。
リーダー力は、PM組織力によって支えられ、経営力によって間接的に支えられている。
４）経営力
プロジェクト・マネジャーのリーダー力が、与えられたインフラの上で最大限発揮されることにより、プロジェクトの成功確率は上がっていく。プロジェクト・マネジャーの活動を支えるのは直接的にはＰＭ組織力であり、それに沿ってマネジメントすることによって、プロジェクトの品質を向上し、プロジェクト成功確率を上げることが可能になる。
しかし、ＰＭ組織力そのものの強力さが問題で、そのＰＭ組織力を支え、それを機能させるインフラ力が経営力・企業力である。例えば、最新技術を身に付けた特定の人材に対するニーズが極端に高く、そのスキルさえ十分あれば多くのプロジェクトが受注できるような局面があったとしよう。ＰＭ組織力の人的資源マネジメントの中でこの時点でできることは、あまりない。せいぜいできることは、その人材をいくつかのプロジェクトで共有するか、外部人材を探すか、大急ぎで人材速成のプログラムを起こすかといった程度であろう。根本的な方策は、この状況を早期に想定して、戦略的に人材育成ができているかどうかということである。先手を打って人材育成するためには、経営レベルの感覚と手腕が問われる。
そもそもどういう新技術が次の時代をリードするかということは、技術に対する先取り精神とともに、海のものとも山のものともつかない技術へのリスクを背負う覚悟が必要となる。先行投資して人材育成できるかどうかは、純粋に経営課題そのものである。
経営力は、PM組織力を直接支え、リーダー力を間接的に支える。
５）ＰＭ組織力と経営力
ＰＭ組織力と経営力（ＰＭインフラ力と企業力）の区別は、前者が基本的にプロセス整備の程度を示すのに対し、後者はその内容（実行）そのもののレベルを向上することに発揮されることになる。プロジェクト成功確率を上げるためには、経営力をPM組織力強化に着目させ実際的にそれを積極的に促進することである。ＰＭ組織力と経営力は、相互に密接に関係し、共通することは、個別のプロジェクトの活動ではなく、企業レベル、組織レベルのプロジェクト横断の施策を行うということである。
個別プロジェクトの実行に直接的に関係するのがＰＭ組織力であり、間接的に関係するのが経営力であるという違いがある。この後、本稿では、便宜上両者を合わせて、組織力またはＰＭ組織力と表現する。
４．真に役に立つ組織力の発揮とは？
プロジェクトの成功のために組織力が大きく関係するが、では、組織力は具体的にどういう事柄に、どのように発揮され貢献できるのかを考えてみる。個々のプロジェクトが成功しやすくなるように組織力は発揮されなければならない。真に個々のプロジェクト・チームに感謝され、尊敬されるような組織力発揮をしたい。
１）プロジェクト・メンバーの視点から
この視点からみて、ありがたいと思える組織力（の発揮）はとどういうことか。最も高度な組織力の発揮とは、我々が電車やバスの利用を当たり前と思っているのと同じように、プロジェクト・マネジャーやプロジェクト・チームが、整備された環境を享受し、より高度な仕事ができることである。プロジェクトを推進している当事者たちが、どうやって手を抜くかをいつも考え工夫しているような状況であれば、せっかく組織的にサポートするつもりで行っていることが、「百害あって一利なし」となる。
変化・改善・革新している過渡的な状態で、人間の慣性（習慣）を変更することを苦痛に感じたり、抵抗したり、やらないための理由を考えたりすることが克服されれば、新しい方法が身につき、体で覚えたことを無理なく実施している状況になるのであろう。
２）プロジェクト・マネジャーの視点から
プロジェクト・マネジャーが本当に困っていること、悩ましいことに対し、適切・タイムリーに助言を与え、ヒントを得られるように組織的なサポートがどの程度できているか。部下のプロジェクト・メンバーに余計な手間や時間をとらせないで、必要なことをスムーズに実行できる仕掛けや仕組みを整備することは組織力そのものである。チーム内外のコミュニケーションを円滑に行うための施設や設備の整備は組織としての課題である。特に、チームが複数場所、国外を含む遠隔地に分散する場合にはコミュニケーションがプロジェクト成功へのキーとなる。そういうプロジェクト・チームにとっての雑事をサポートする組織的な仕組みは組織力発揮そのものである。
更に、例えばプロジェクト見積手法や見積データの過去経験の蓄積によるガイドラインがあるか、品質データの過去経験の蓄積によるガイドラインがあるかは、組織的なフレームの構築と徹底した実行ができているかが問われる問題であり、組織力そのものが現実的にプロジェクト・マネジャーの活動に影響を及ぼす例である。
特にプロジェクト計画時点での各種テンプレート、サンプル、メトリックス・ガイドがあるかないか、その内容程度によって計画作業の効率だけでなく、計画の品質が左右される。計画の品質は、プロジェクト管理のベースラインの精度を決めるものであり、この充実はプロジェクト・マネジャーの個人力に依存するだけでは解決しきれないことである。
３）管理者・経営者の視点から
常に、個々のプロジェクトの状態が正確に把握できること、問題対応が後手に回らないことが重要で、そのためにプロジェクト・マネジメントに関係するルールやサポートシステムを整備する必要がある。その上で、すべてのプロジェクトが成功するために、監視しコントロールする仕組みが必要である。そして、個々のプロジェクトの実行から得られた知識・経験・ノウハウなどをどれだけ有効に次に生かせるかが重要であり、そのための仕組みや徹底は、組織力によって決まる。
問題発生が問題ではなく、プロジェクト・マネジャーの手に負えないような問題の原因になることをどれだけ事前につぶせるか、発生した問題をどれだけ早期に解決できるか、大きくなった問題をどういう決断をもって処理できるか、といったことは最終的には管理・経営の課題である。適切、タイムリーに判断するためには、日常的に状況を正確に把握できる仕掛けと訓練ができているか、という経営努力によるのである。
４）具体的強化課題例１－プロジェクト・ライフサイクル定義
プロジェクト・ライフサイクルの定義、プロジェクト・マネジメント・プロセスの定義を明確にする。プロジェクト受注企業では、見積・提案の扱いのルールは特に重要で、営業部門とデリバリー部門が分かれている場合は、顧客への金額・期間のコミットとなる行動には注意を払わねばならない。見積・提案の手法とレビューの方法についても、組織的な責任の問題と共に技術的な経験の再活用や信頼できるバックデータの仕組みは組織的な取組みを欠いては成り立たない。プロジェクト・マネジメント・ライフサイクルと並立して、プロダクト・ライフサイクルがあり、その定義も大きな課題である。昔からのウォータフォール・モデルやパッケージソフト・モデル、スパイラル・モデル、プロトタイピング・モデル等々、複数の方式があり、その成熟度を上げれば、モデル毎のWBS(Work Breakdown Structure)テンプレートまで持ち込むことができ、見積・提案の精度向上やその処理スピードアップが期待できる。
プロジェクト・マネジメント・プロセスとプロダクト・プロセスを合わせて、プロジェクト全体のマネジメント・プロセスが構成され、そのレベルでWBSテンプレート化すれば更に効果が大きいことは自明である。
５）具体的強化課題例２－プロジェクト・コスト管理
プロジェクトの原価を正確に把握できるようにすることは初歩的な組織力である。このあたりのシステム化も企業によっては不十分であるとか、歴史的に屋上屋を重ねた結果、硬直的で柔軟性にかけるといったことが少なくない。ＩＴプロジェクトでは、人件費がコストの大部分になるので、人の稼動に関してどの程度正確にタイムリーに把握できるかは重要なことである。また、当然ながら、プロジェクト要員個々の作業実績データ入力が二重入力になるようなことは避けるべきことである。プロジェクトに付加されるコスト実績は、少なくとも１週間単位で正確に把握できることが望ましい。
一方、プロジェクト単位の予算管理システムが明確になっている必要がある。プロジェクト予算の原価として見積値、計画値、受注値などの中でどれを使うのか、リスク見積コストの執行方法、請負契約時の瑕疵担保引当をどう扱うかといったことなどを明確にしておく必要がある。プロジェクト単位の売上計上のルールも進行基準で行うためには、マイルストーンを明示したプロジェクト計画書やプロジェクト予算との関連を明確にしておかねばならない。また、これらの多くは会社決算・経理と直結する内容であり、プロジェクトだけの勝手な事情だけでは決められないものである。まさに組織力が問われる課題である。
６）具体的強化課題例３－プロジェクト・マネジメント・ツール
プロジェクト・マネジメント用のツールを実際の仕事でどの程度駆使できているか。現実に採用可能な適切なツールがあるかという問題もあるが、例えば、次のような機能を持つITツールであれば、実際の管理に使用できるのではないか。最近この手のツールも入手可能になってきている。
・計画機能（WBSテンプレート管理、WBS作成、スケジューリング（クリティカルパス計算）、要員計画、コスト計画、品質計画、計画変更）
・進捗把握機能（タスク単位の進捗把握、コスト実績、EVM(Earned Value Management）、品質データ管理）
・協働機能（チーム内外のメッセージ交換、情報共有、遅れタスク警鐘、ファイル履歴管理）
・Web-based（場所分散対応、オフショア対応）
・報告機能（進捗状況（ガントチャートでの予実績表示）、問題管理状況、リスク管理状況、品質状況、コスト状況）
・完了機能（テンプレート化、知識共有化）
・価格安価でASP(SaaS)でも可
・使用容易でセキュリティは厳密に管理
こういうツールを駆使したプロジェクト推進は、プロジェクト・マネジャーやプロジェクト・チームの仕事をやり易くするだけでなく、結果的に、上位組織や経営レベルからも個々のプロジェクトの状況を「見える化」することができる。ツール導入時には「できないことをあげつらう」ことが多いが、「できることを駆使して便利にする工夫をする」ことを大切にするほうが、結局は進歩に繋がる。
上記のような仕組みを自社固有システムとして作り上げる努力は、昔から各企業で行われてきたが、グローバル化の波の中では、確かな市販のツールを使うほうが望ましいようだ。なぜなら、その方が新しいプロジェクト・マネジメント手法も素早く取り込むことができるからである。
７）具体的強化課題例４－ナレッジ共有
プロジェクトをビジネスとして行う企業・組織では、個々のプロジェクトの経験知をどの程度、横展開できるかで真の組織力が試されることになる。見積・提案の内容・工夫、プロジェクト計画の内容・工夫、プロジェクト遂行の方法・工夫、技術的ノウハウ、顧客対応ノウハウ、・・・等々の共有である。
一般的に、個々のプロジェクトはそれ自体を処理することに全力投球しているのが普通であり、それを繰り返しプロセスとして、再生産につなげることは組織力視点の取組みがなければならない。そうでないと個々のプロジェクトは単なる一過性の単発の仕事で終わるだけである。そして、結果として、いつも「いつか通ったいばらの道」を繰り返し歩むことになるのである。皆が、苦しい思いをしながら。
８）具体的強化課題例５－組織編成
組織力発揮の最も直接的ものは、組織編制である。PMO(Project Management Office)、や品質保証部門、先進技術集団、特定専門技術集団といったプロフェッショナル集団を編成し、プロジェクト横断でサポート・コントロールする。
当然、専従者主体となるので、ヒト・モノ・カネ・ジカンとの兼ね合いで、どの程度の組織規模・機能・責任・権限とするかということになる。重要なことは、カタチだけの組織であっては、「百害あって一利なし」になるリスクであるので、あまり無理をしない程度に、しかし経営の覚悟をもって毅然と実践しなければならない事柄である。
９）具体的強化課題例６－人事制度上の考慮
プロジェクト・マネジャーや技術者の人事上の扱いをどういう形で実現するかも、組織力発揮の重要な側面である。キャリアパスを明確にし、プロジェクト要員の自己実現のロードマップを明らかにすることにより、モラールアップと自己実現努力の醸成を図る。単にキャリアパスだけでなく、報酬制度とのリンクを如何にするかということとも関連してくる。また、プロジェクト・レビューはプロジェクトの正常な進行のためには重要な方法であるが、レビューアについてのスキル基準を明確にし、人事評価にも反映するといったことも必要な施策になってくる。
５．組織力を如何に強化するか？
組織力強化をどのように行うかは、せっかくの経営資源投入効果を確実に出せるかということに直結する。経営の覚悟として、これらの方針を明らかにして進めたい。
１）組織力強化するための覚悟
突き詰めて言えば、プロジェクト成功のために役立つ仕組みや仕掛けを構築し洗練させていくことがＰＭ組織力強化である。そして、強化することは、現状に対しして何らかの変化を加えることである。仕事のやり方が変わるような変化をする場合、そこに関わる人の適応（力）、順応が大切なことになる。
一般的に、人間の思考と行動には慣性が働くものである。昨日の続きの今日であり、今日の続きの明日であることこそが自然な感覚である。これが、改革や変化に即応できない、抵抗感の根源にある。しかし一方、「火事場のｘｘ力」といったことや、突然の大事故に遭遇した時に発揮される人間の適応力はたくましいものである。
マッタリした慣性（惰性）などに構っていられない状況では、その場の状態に素早く反応して全力で適応し対策に全力投球するのだ。このような関係する人々の状況や動きを睨みながら、組織力を強化するためには、二つのやり方がある。
一つは、変化をゆっくり引き起こす方法で、現状から漸進的に、無理をしないで進め、慣れればそのスピードを速める方法である。あまり安全運転すると改革の意識は芽生えず、何より時間がかかり過ぎ、途中で息切れする恐れがある。
二つ目は、壊れない程度に激しく、適応できるギリギリまで変化させるやり方である。
限度を過ぎると、すべてがチャラになる恐れがある。どれだけ効果的・効率的な仕組みに変えられるかという御利益との兼ね合いで、組織全体が狙い通り変化についてこられるかを見切ることが重要である。ただヤミクモに突っ走るだけでは、せっかくの問題意識や変革の意欲も逆効果になる可能性を秘めている。
２）目指す全体像を明らかに
現状の問題を正しく把握・分析して、進む方向と望ましい姿を描くことが必要である。目に付く所（例えば、直感的に優先度の高い事柄）から手を打つ方法は現実的であり、それなりの効果が直ぐ出る可能性が高いのでやりやすい方法であるが、部分最適に陥るリスクがある。まずは冷静な現状分析から、目的を明確にして全体像をイメージすることが重要である。その上で、その達成のために必要な対策（施策）を洗い出し、優先順位をつけ、現実化の手順を検討・決定し実行に移していくことになる。
そもそも、ＰＭ組織力強化の正しい「目的」の明確化のためには、「動機」が何であるかが問題である。正しい動機から正しい目的設定することが最も重要なことである。「流行だから」、「他社が取り組んでいるから」、「顧客に言われたから」、「他社に先駆けると差別化要素にできる」、「顧客に宣伝材料になる」、「何かやらないと社内のまとまりがつかない」・・・、といったような動機でスタートすると、よほど注意して正しい目的設定をしない限り、手段の目的化（本来目的の忘却）に囚われてしまう。もちろん、最初の動機が正しくなくても、冷静に正しい目的を見失わなければ問題はない。
３）背伸びは適度に
例えば、現在かなり多くのＩＴ企業が取り組んでいるＣＭＭ（ＣＭＭＩ）(Capability Maturity Model)において、レベル２から一足飛びにレベル４には行けないと、元カネギーメロン大学のＣＭＭ創始者のワッツ・ハンフリー（Watts S. Humphrey）は言っている。（CMMはレベル１から５で組織能力の成熟度（高度さ）を定義したものである。）プロセス改善は漸進的なスパイラルで一歩一歩確実な進化を進めるのが最も無理がなく、成功する可能性の高いやり方なのである。それにもかかわらず、よくある組織力強化の間違ったアプローチは、「ＣＭＭレベル３を何年何月までに達成する」という社内プロジェクトを立上げ、何が何でもそれを達成するという進め方をすることが多い。もちろん、明快な目標を掲げ、全員一致でその達成を目指すという、「プロジェクト型推進方法」は分かりやすく、ベクトル合せがしやすいので、正しい目的を見失うことがなければ、そのこと自体は大いに結構である。
問題は、背伸びの仕方が適切であるかどうかである。CMMレベル１の自社の実態であることを忘れて、もしくは実態を知りもしないでレベル３を目指すことこそが問題なのである。背伸びしない改革・改善などありえないが、現状から冷静に判断して実現可能であるかどうかの視点・分析が不足するのは問題である。そういう視点・分析の欠如から「べき論」が蔓延して、実際の仕事をする人々が「やらされる」、「上司や経営者が言うのでしょうがない」といった、完全受動型、指示待ち型、被害者型の意識で取り組む様が眼に浮かぶではないか。
プロセスの改善は、完全に以前と違うものに一気に革新（リプレース）するか、無理をしないで着実な進化可能なことに絞って「牛歩を厭わぬ」がしかし確実に実現することを積み上げるかのどちらかを選択しなければならない。ここで注意すべきは、牛歩であっても少しは牛を走らせることは可能であり、必ずしもスピード感がないということではなく、工夫によってはスピードアップすることはあり得るということである。
無理し過ぎた背伸びは、手段の目的化を招きやすい。過ぎたる背伸びは害悪であると肝に命じる必要がある。
４）焦点を絞る
「ヒト・モノ・カネ・ジカン」の経営資源に限りのある現実の中で、包括的に取り組むには、相当な企業体力が必要である。目指す全体イメージを明らかにしたうえで、プロジェクト成功に対し基盤となる部分や最も効果のあることなどをベースに優先度を決め焦点を絞って進めることが現実的である。
例えば、CMM(I)のように第三者による客観評価を得るには、原則的にCMM(I)で定めた評価体系の全体を漏れなくカバーすることが必要になる。特定の弱点があれば、その企業にとってその弱点は真に資源投入しても改善すべき課題であるかどうかを個別判断すべきである。結果的には、第三者の客観評価が一定レベルに達しないかもしれないが、自社の弱点はあっても自己分析の結果に基づいた別部分の徹底強化をするほうが、無理に全体向上目指して客観評価の一定レベルを達成するより、好ましい選択かも知れない。
一度にいろいろな事柄をまとめて一新するには、革新アプローチが適切であるが、革新アプローチの適用においては現行のプロジェクトの移行とか、新しい方法の教育・訓練等、解決しなければならない課題がたくさん出てくる。
漸進的アプローチの場合は、時間がかかり過ぎる傾向はあるが、確実に一歩（半歩？）前進することは比較的簡単である。組織力強化の方法としては、漸進的アプローチで、焦点を絞った課題を確実に達成することを積み重ねるほうが、リスクも少なく、抵抗感も少なく、結果も確認しやすいなどの利点があり、現実的である。もちろん、一度に多くのことを変化させる必要に迫られる場合もある。
例えば、プロジェクト・サポート・システムを全面的に更新するような場合は、業務処理方法も大きく変化する可能性が高く、これを機に、関連する課題も含めて一気に変更するほうが現実的であろう。
５）必ず効果を出す
組織力強化活動で何かを変えていく場合、最初の段階では現場のプロジェクトは迷惑がっているのが大半であり、それらの障壁を超えて実施することになる。そのため、できるだけ早期に実施した結果や効果が、明確に確認できるようにしたい。その結果は個別プロジェクトにとっても直接的に有益なものであることが望ましい。有益な結果を確認することにより、強化活動は現場から見ても「百の議論」より説得力が増し、その後の信頼感が増大することになる。信頼感ができれば、共に改善・改革を追及する体制が大きく前進することになる。
組織力強化活動の施策は、比較的漢方薬的効用のものが多く、効果の確認・検証が難しいことが多くなるが、計画時に何らかの確認・検証手段を明確にし、それも含めて関係者にオープンにし、結果もタイムリーにオープンにすべきである。
６）できるだけ自動化を
プロジェクト・マネジメントに関する組織力強化を実現するには、古くはカミの山を作りそれを徹底させることが主流であったが、今日のIT発展の時代には、ITツールをどれだけ使いこなすかが重要である。すべてを人に頼る強化策は、いくらIT環境を駆使しても、カミの山を理解させる活動と大差ない。強化する内容を可能なITツールを用いて実現することにより、使用する側は、ツールに馴れることだけに意識がいき、抵抗感は段違いに少なくなる。
組織としてのルールやガイドラインは、ツールに取り込んで、ルールを守るという意識でなく、「ツールを使うと結果的に一定のルールに従っている」というほうが、皆が自然体で馴れることができる。ツールを多用することにより、多くの事柄がバイナリー化され（コンピュータ内に取り込まれ）、結果として多くのことの「見える化」できることに直結する。
正しい客観的な事実に基づいて、正しい判断、高度な判断・決断をすることが、より高度なプロジェクト・マネジメントの域に進むことに直結する。そもそも、正しい判断、決断の根拠となる信頼できるデータを手に入れるために多くの時間とエネルギーを費やし、本来の正しい判断・決断をする役割を充分果たせていないプロジェクト・マネジャーはたくさん存在する。
「足で見る」ことも大切だし、会議で状況把握することも大切であるが、ツールを駆使して正確なデータを迅速に把握し、それを踏まえた思考・判断・決断・実行が最も重視しなければならないことなのである。
７）明るくオープンな雰囲気で改善を
組織的な仕組みや仕掛けを構築・改善する場合、そのユーザとなる現場（プロジェクト・チームなど）は、ある種の警戒感を持って身構えるものである。これは、余計な作業が増えることが過去にも多かった経験則に基づき、変化を嫌う気持ちと相俟って、ある意味当然の構図である。しかし、我々は過去数十年間、個々のプロジェクト事情や意向を最優先するあまり、組織的改革・改善の取組みを試みては失敗することを何度も繰り返してきた。
そういう雰囲気を乗り越えていかなければ、今後も繰り返すことは自明である。組織内の関係者が全員で目指す方向を心から共有し、最大限の協力を明るく行うことが必要条件なのである。そしてそのためには、全員が、理解できないことは質問し、議論して納得することが必要である。「明るくオープンに」やりたい。
そもそも、プロジェクトの現場はもっと楽しい職場にすべきではないかと思うが、プロジェクト横断で組織的に進める施策は、更にオープン・マインド・ベースで自由な発想と工夫を出し合って、全員が参加意識を持って進めることが望ましい。「私作る人」、「あなたはそれに従う人」というメンタリティでは、楽しくない。どうせやるなら、皆が参加して、楽しくやるようにしたいものである。
おわりに
以上、ＩＴプロジェクトを成功させるために、プロジェクト推進のインフラというべき、組織力、ＰＭ組織力の重要性とその現実的な進め方について述べた。
最近ようやく、プロジェクト成功のためには「プロジェクト・マネジャーを鍛える」ということに重点投資することから、PMO(Project Management Office)を置き、組織力を強化する方向に舵を切る企業が増えている。そのこと自体は望ましいことであるが、上滑りした形式主義に走るアプローチにならないように望みたい。動機・目的を明確にし、一手一手が確実に有効打になり、カラダ（組織）に染み付いて、全体のレベルアップに繋がるようにしたいものである。
筆者自身は最近、包括的なプロジェクト・マネジメント・プロセスだけでなく、それを意識しながら、よりクリティカルな部分プロセスに焦点を絞って、現実的に（結果がすぐに確認できる）集中的に改善・改革することを模索している。包括性追求のために無理をしがちになることを回避したいためである。もちろん部分的プロセスからのアプローチは部分最適に陥る危険性を孕んでいるので、全体最適を強く意識する必要があるが、漸進的アプローチとしては成功する可能性が高いと考えている。
現実には、プロジェクト・レビューに着目して、その成熟度モデルをCMMに対応するコンセプトとして考案した。RVMM( Project Review Maturity Model) と仮称している。プロジェクト・レビューの成熟度を５段階に定義し、実際の各企業・組織の成熟度を評価（アセス）し、効果的・効率的にレベルアップするための道筋（Load Map）を示すことを目的としている。図３にその概要を示す。
当然ながら、レビューに焦点を絞って検討しているが、成熟度を上げるためには、レビューアのスキルの問題などを取り上げる必要があり、その結果、人事システムとの関連が出るといったように、レビュー活動にとどまらないことになる。
部分フォーカスして進めるが、進むに連れて関係する課題が増えることになる。
