ＤＲＩ通信２２号 「プロジェクト管理」 １９９８．７．１
梅雨の最中、為替レート、株価、Ｗ杯サッカーとどれもうっとうしいこの頃
ですが、皆様お元気ですか。情報社会の進展によって、かつての産業革命の
時と同じような、社会構造の変化が起きていて、思ってもみないビジネスチ
ャンスがごろごろしているのかも知れませんが。
先月はアウトソースについて述べたわけですが、「アウトソーサーに効率的
なシステムを指示出来かつ検証できないまま任せたら大変なことになる。ア
ウトソースできるまで地道な努力が必要だ」といった感想をいただきました。
さて今月はプロジェクト管理について考えてみます。私が大学を卒業したの
は１９５９年ですから、まもなく４０年になりますが、石油化学がさわがれ、
四日市、川崎、千葉、水島などあちこちにコンビナートがつくられ始めた頃
です。エチレン、ＢＴＸ、塩ビ、ナイロン、ポリプロなどを造る固有技術と
ともに、一つの目的に対して大勢の多種多様な技術者を総動員するためのプ
ロジェクト管理の重要性が指摘され、追及されました。
プラント建設でのプロジェクト管理の目的は、所定の機能・性能の成果物を、
納期どおり、所定の費用の範囲で作り上げる事です。いろいろな人が、分業
してパラレルに仕事を進めます。大規模プロジェクトでは、数年にわたり、
数千億円の資金が投入されます。設計にかかわる人は、協力会社を入れると
数百人に、また工事にかかわる人は数千人になります。これらの人々が、遊
びなく無駄なく、次々と的確に仕事をこなしてゆかなければなりません。
そのための第一の条件は、成果物（WHAT)についての共通の理解、イメー
ジの共有であったと思います。Piping & Instrument Diagram(P&ID)と呼
ばれる組み立て図を主として、配置図、機器や配管のリストと図面がその役
割を果たしました。プロマネはP&IDによって成果物全体を見通すことがで
きました。メンバーは、P&IDの少なくとも自分の関与する部分は理解し、
自分の位置付け・役割を正しく理解することができました。
成果物（WHAT)に基づいてスケジュール（WHEN)をたてます。それは適切
な作業単位（WBS:Work Breakdown Structure) を定めこれに開始日、終
了日を割り当てる事といって良いでしょう。これをメンバー全員が共有する
わけです。実績は日々変化しますから、常時監視し続けなければなりません。
プラントはハードウエアですから、工事については目視でかなりの状況が把
握できるという利点があります。
さて情報システムに目を転じて見ましょう。主体はソフトウエア（いわゆる
業務アプリに限ります。OSやDBMSなどのプラットフォームアプリは別）
ですが、多種多様の人々の協力による個別開発など、プラントと酷似してい
ると言うことができます。規模も今や大差のないところに来ているようです。
プラントに比し、資材の物流がないと言った利点はありますが、情報システ
ムはつぎのような不利を多く抱えています。
(1)情報システムが目的とする製品は画面・帳票であるが、化学・石油プラ
ントなどの製品より数が多くまた追加・変更が多い
(2)成果物がVISIBLEでないためイメージの共有や状況把握が難しい
(3)部品間の不整合が問題になるが、プラントのような目視が効かない
(4)プラントのP&IDに相当する全部品を記述した組立図による成果物の骨
格把握やイメージ共有が定着していない
(5)使用される技術(IT)が高度で難しく、しかも未熟で日進月歩する
(6)基礎となる工学が未熟で、ど素人がベテランの勘と経験を教わりながら
進める事も珍しくない
(7)メンバーのスキルに差があり、また背景・文化が違うため用語が通じな
いなどコミュニケーションが難しい
このため「C／Sシステムの１６％しか納期、予算内に完成していない。
1/3はキャンセルされている」（Database Programming & Design 1997.7)
と言った報告が生まれてくるものと思われます。実際このような条件で
５０人〜５００人といったプロジェクトをスムーズに指揮するのは至難の業
です。数人のスーパーSEに恵まれれば可能かもしれませんが、それは幸運頼
みでしかなく、失敗の確率を下げるものではありません。
ではどうするか。前述(1),(2),(3)は所与の条件と考えざるを得ません。そこで
・成果物イメージを共用するための組立図を作成する←(4)
・情報隠蔽により高度のITは、専門家以外は意識しなくてよいようにする←(5)
・モデルベースの科学的方法論を導入する←(6)
・教育・訓練によりコミュニケーションを可能にする←(7)
が浮かび上がって参ります。
これによってプロジェクトリーダーは、成果物全体を見通しよく把握します。
メンバーも同じドキュメントにより自分の分担を正確に理解します。WHAT
とWHEN、HOWが共用でき、現状、制約がわかるときメンバーは自分の裁
量を１００％発揮し、最大の生産性を上げることができます。残された夢
（WHY)の共有も時間の問題となるでしょう。
しかしそれ以前に、大規模プロジェクトそのものを解体したいものです。大
規模プロジェクトは大規模システムを企画したから生まれたものです。なぜ
大規模システムなのでしょうか。データの流通範囲を広げたいからです。デ
ータの流通は整合性のとれた標準データを用意すれば実現できます。標準デ
ータの整備とソフトウエア開発とを分離すればよいではないか。
広域流通を実現する標準データの整備は、それなりに広い分野を対象にしな
ければなりません。しかしIT独立にすすめるとき、プロジェクトの大きさは
、進め方にもよりますが、ソフトウエア開発の1/10以下になると期待できま
す。得られた標準データは、さきに（ＤＲＩ通信２１号）も述べたようにビ
ジネスモデルの中核をなすものとして、アウトソーサーとのインターフェー
スになります。
ソフトウエア開発には、高度のITが必要です。ソフトウエアはITの進歩によ
り激しく変化・陳腐化します。これにすぐ対応しなければならない業務もあ
りますが、ゆっくり対応すればよい業務もあります。元来ソフトウエアは
「小さいことは良いこと」です。それに合ったハード環境が選べますし、カ
ートリッジ方式で陳腐化した部分だけ取り替える方式がとれるからです。
したがって、標準データの整備とソフトウエア開発との分離は、今後の方向
となるに違いありません。しかし直ぐには難しいようです。まず標準データ
整備のスポンサーが見つかりません。実益が直ぐにはないからです。本来は
経営トップがスポンサーにならなければなりませんが、全社さらには企業間
をまたがる標準データの整備を自らの課題であると認識するトップは例外だ
からです。また従来の開発技法とはかなり異なる部分を含んでいるため自信
がありません。しかも教育・訓練のステップが必要で、そのための時間を見
なければならないからです。
「動かないコンピュータ」の対策としてプロジェクト管理が話題とされるこ
とがあります。確かにプロジェクト管理は重要です。しかしプロマネのスー
パーマンを待望−−これはプロジェクト管理をスーパーマン依存にすりかえ
ているだけ−−しても解決は来ないように思われます。プロジェクトは管理
可能な大きさに制御すべきと考えます。そのためにはデータの標準化による
データインフラの構築が不可欠でしょう。プロジェクト管理はそのうえで議
論したいものです。ERPプロジェクトに苦労が多いのも、データインフラと
ソフウエアの分離が不十分で、大規模ソフトウエアとまともに格闘しなけれ
ばならないからではないでしょうか。
« 【第21号】アウトソーシングへの課題【第23号】ＤＯＡとＯＯＡの相違点 »
