人気ブログランキング | 話題のタグを見る

プロジェクト・マネジメント・システムは存在しうるか

明けましておめでとう。本年も当サイトを通じて、皆さんとマネジメント・テクノロジーについて一緒に考えていこうと思う。どうぞよろしく、お付き合いいただきたい。

さて、年初なので、少し基本的な問いを考えてみよう。プロジェクト・マネジメント・システムは存在するのか、しうるのだろうか、という問いである。

マネジメント・システム」という言葉には普通、二種類の用法がある。方式・体系としてのマネジメント・システムと、ITとしてのマネジメント・システムである。前者の類例には、「品質マネジメントシステム」などがある。いわばルールと手順の体系であって、それ自体は全てを紙ベースで進めても構わない。

わたしがここで問題にするのは、後者である。つまり、プロジェクトをマネジメントしてくれるソフトウェアは存在しうるか? との問いだ。この問いに答えるには、プロジェクト・マネジメントとは何か、あるいは、プロジェクト・マネージャーの仕事とは何なのか、を考えねばならない。

プロマネの仕事の中心には、「決めること」がある。したがって、少なくともプロジェクト・マネジメントの重要な要素として、何らかの「決断」があるはずだ。

今の世の中には、データさえ蓄積できれば、AI・アナリティクスで自動判断できるようになる、という楽観的な信憑がある。したがって、将来はAIがプロマネのかわりに判断してくれるようになる——のだろうか? ちょうどAIによる自動運転が、人間を車の運転から解放してくれるように。

そういった将来像を描く人もいるだろうが、とりあえず、まだそれは現実ではない。では現時点でのプロジェクト・マネジメント・システムとは、何をするのか。プロマネの判断を「助けてくれる」のだろうか? そして将来的には、自動判断に発展する可能性を持つものなのだろうか。そんなシステムは存在しうるのか。

別にわざわざ、そんな問題を立てる必要は無い。現にお前さんの働く会社だって、プロジェクト・マネジメント・システムを持っていると、言っているじゃないか。そんなご指摘が、読者の間から聞こえてきそうである。

ごもっとも。日揮のPMS(Project Management System)については、Webサイトでも情報を公開している。

このPMSはどのようなITシステムなのだろうか。本システムは主に、プラント系のプロジェクト向けに作られている。プラント系プロジェクトは普通、EPC (Engineering=設計, Procurement=調達, Construction=建設)の3フェーズ(3業務)からなっている。そこで日揮のPMSも、
  • Engineering Management System
  • Procurement Management System
  • Construction Management System
の大きな3つのサブシステムと、それを取り巻く周辺システム群からなっている。

そしてそれぞれが、プラント系プロジェクトを動かす主要素である、「設計文書・図面」「資機材」「建設工事作業」について、いわばマスターリストを保持し、それらにまつわるコスト・スケジュール・リソース等の、データを集約する機能を持っている。

(ただし、今ウェブサイトを見てみたら、英語の説明の図はちょっと内容が古いなぁ。直してもらわなければ。連休明けにやらなければいけない仕事が増えてしまった・・)

日揮のPMSは、長い歴史があるため、ほとんどが自社製(一部パッケージベース)の作り込みである。

では、このシステムがあるため、日揮のプロマネは大船に乗ったような気分で、着実に心配なく仕事ができるのか? 自分は要所高所の判断だけを下し、後はシステムが皆を采配して仕事を進め、結果として納期も守り、利益も上がるのか。そうだ、と答えたいところだが、現実は全然違う。

現実のプロジェクトはリスクの塊である。プロジェクトとは、最初に労力や資金を投入して、最後に価値あるアウトカムや利益を得る、一種の賭けなのである。プロマネの仕事とは、プロジェクトをマネジメントするとは、上手に賭け(仮説)を仕立てて、人々をそれに向けて動かし、見事にその果実を得ようとするところにある。

マネジメントは管理ではない。このことは何度か、このサイトでも書いた。英語のマネージManageとは、御しがたいものを、自分の意図や目的に沿うように動かすことである。暴れ馬を乗りこなすイメージだ。英語で、I can manage my car.といったら、その人の車には何か問題があるのだな、ときいた人は思う。

仕事におけるマネジメントの概念の中核には、「人を動かす」「人に働いてもらって目的を達する」という意味がある。自分自身で手を動かして、具体的な成果物を作ることは、マネジメントではない。成果物を作ること自体は立派な仕事で、それがなければプロジェクトは前に進まない。だがマネジメントとは、そうした仕事を方向付けし、組合せ、采配して、総体として機能し価値ある成果をインテグレーションすることにある。

もちろん、日揮のプロマネはPMSがなかったら、仕事にならない。そうでなければ10万点を超える図面や仕様書、100万点近い資機材を、どうやってコントロールするのか。ただ、それはプロジェクト・マネジメントにとって必要条件だが、十分条件ではないのだ。PMSがあればプロマネが不要になる訳ではない。

(あなたが製造業の人なら、たとえば考えてみて欲しい。生産管理システムは生産をマネジメントしてくれるのか? 工場長は不要になるのか? もちろんそんな事はない。生産管理部長が不要になることだって、まったくない)

そもそも、プロマネの仕事とは何か。プラント系プロジェクトの枠を離れて、少し一般化して考えてみると、以下のような要素からなることが分かる:

  • プロジェクトをデザイン(計画)し、
  • 組織とルールと手順をつくり
  • ゴール・目的・目標などビジョンを示して
  • チーム員を引っ張り
  • 人に仕事をアサインし、指示を出し
  • ステークホルダを説得してプロジェクトに協力してもらい
  • リスクを予知して事前対策を講じ
  • 途中途中で進捗やコストや中間成果物の品質を確認し
  • 外部環境変化や内部状態の変化から生じる問題を検知・分析し
  • 予測と価値評価を行い
  • 適切な決断を下し
  • プロジェクトの着地点を見据えて皆をモチベートし
  • プロジェクトの成果物や所産をアウトプットを、適切なアウトカム(運用や価値など)につなげ
  • 経験からの学びをLLとしてまとめる

こうした職務を進めるのための要件をまとめると、5つくらいに集約できそうだ。

1. 価値観が必要

決断を下すためにも、人にビジョンを示して引っ張るためにも、何が価値あることなのかについての基準をしっかり持つ必要がある。え? 企業活動ならば、利益を最大化することで、すべては尽きるはずって? そうだろうか。たとえば、実績づくりや人財成長など、非金銭的価値はどうするのか。これらも含めて、決断が必要なのだ。

2. プロジェクト・デザインの能力が必要

プロジェクト初期における計画や組織づくりにおいては、全体の仕事をどのように分割し(あるいはモジュール化して)、どこを誰にやってもらうのが適切かを考える仕事がある。妙な切り方をするとインタフェースが増えて、トラブルの原因になる。手配可能なリソースには限界もあるし、適性もある。こうした仕事(Work framingとも呼ぶ)は、一種のデザインに属する。デザインは本質的に、サイエンスとアートの中間領域にあって、センスを要求される。

3. 対人的なコミュニケーション能力が必要

プロマネはその時間の半分を、人とのコミュニケーションに費やす、とよく言われる。マネジメントが人を動かす仕事である以上、ある意味で当然なのだろう。それも、相手はチーム員だけでなく、社内外の種々のステークホルダ達である。したがって人を動かすといっても、単なる命令ではなく、説得とリーディングが要求される。おまけに、人と人の間には、どうしても面子や好き嫌いといった、ヒューマン・ファクターが大きくからむ。何を言うか、だけでなく、誰を通じてどう言うか、までが賢慮の範疇である。

4. 予測(あいまいさ=リスクを含む状況下で)の能力が必要

プロジェクトはリスクのかたまりであり、また現状把握それ自体も案外難しく、曖昧さの残る状況で、先を見通さなくてはならない。もちろん、誰しも100%先のことが分かるはずはない。ただ、洞察力は、環境変化への適応性を高める上で、必須である。

5. 結果を引き受ける責任感(覚悟)がある

うまくプロジェクトをデザインし、先を見通し、価値観を持って人を説得したとしても、そのプロマネが最終的な結果を、良し悪しを含めて引き受ける責任感が必要だ。そうでなければ、そうでなければ、誰がプロマネの言うことを聞くだろうか?

以上、どうみても、この5つの要件全て、機械化・自動化は困難だろう。賭けたっていいが、10年、いや100年たっても、AIではできっこない。そのような意味では、プロジェクトをマネジメントしてくれるシステムは、存在しないと言っていい。

では、現実のソフトウェアは何ができるのか、何をさせるべきか。それについては、IT分野の人たちは、様々な業務型システムでの経験から言えることがあるはずだ。

普通は、まず記録(実績)系の機能からスタートする。

プロジェクトで言えば、まず受発注からだ(日揮でもそうなっていた)。企業として、外部企業とのインタフェース記録を残す必要があるからだ。入出金については、会計ソフトがある前提としても、モノの入出荷の実績は(ものを扱うプロジェクトならば)必須だろう。

さらに記録と言う面では、情報(ドキュメント)の登録保管、人の実績工数(タイムシートからの集計)なども機能として欲しくなる。

実績系のつぎは指示(計画)系の機能が来る。

プロジェクトと言えば、実行予算計画が必要だ。また、モノの種類と数量に関する指示(計画)が、加工や移動にともなって、ほしくなる。

さらに、人のかかわる作業=アクティビティに関する指示(ワークオーダー)へと、機能面の要望は進むだろう。とくに、モノに関わる現場的作業だけでなく、設計等の知的作業についても、計画と指示の必要性が出てくる。

ところが、実は日本ではこれが難しい。まず、日本の商習慣のために、顧客や外部からの変更要求が多い。もう一つ、日本では働く人がおおむね優秀なので、自分から指示を待たずに動いてくれる。それはとても大事でありがたいことだが、逆に指示する側が、多少曖昧で大雑把でも、仕事が動いてしまう。これはアジアを含む海外ではあまり期待できないことだ。

おまけに実際の遂行段階で、問題が生じると、計画していなかった作業が頻繁に発生する(設計変更対応等はその良い例である)。こうした問題があるために、ざっくりとした工程計画だけ立てて、詳細は現場で担当者同士が、別のExcel表などを使って調整したりする。

こうなると、現場にいちいち確認しないと、進捗の途中経過が見えなくなる。負荷も余力も分からない。だから納期も見えない、という状況になりがちだ。

まあ日本では工場ですら、細かな製造指図がなく、現物中心で動いていたりする国である。「それで動いているんだから何が問題なんだ」と大勢の人が思い込んでいる。結果として、後で振り返って分析しようにも、詳細なデータが何も履歴として残っていない状況になる。

だからこそ、今後はオフィスワークを含む指示(オーダー)の概念や、それを可視化するチケットが重要になるはずである。

実績系・指示系と進化してきたら、さらにはデータ保守・交換・分析系の機能に進むだろう。マスタデータの保守、外部システムとのI/F、そしてデータ蓄積などである。

ただし、この3つは、実績形が完全に終わってから指示系に進む、といった形ではなく、ある程度重なり合いながら、機能を少しずつ充実化していくのが普通だろう。

以上が、今の世の中における、プロジェクト・マネジメント・システムの有り様である。プロジェクトをマネジメントしてくれるシステムは存在しない。今後も多分存在しないだろう。プロマネの決断をサポートする数値やデータを、提供してくれる機能はあると思う。いわば実行コントロール系の機能である。

だが、それは船の航海にたとえれば、GPS付きの操舵システムのようなものだ。船の現在位置、速力、これまでの航路や、積荷の上げ下ろしは、正確にわかる。だが空模様と海象をにらみながら、船団を率いて航路を決めていく任務は、常に船長という人間に残されているのだ。


<関連エントリ>
 「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ (2017-12-18)

by Tomoichi_Sato | 2022-01-10 15:24 | プロジェクト・マネジメント | Comments(0)
<< 生産管理システムは生産を管理できるか クリスマス・メッセージ:フェア... >>