PMBOKのような欧米発のプロジェクトマネジメント手法や知識体系に関心を寄せるITエンジニアが増えている。しかし，それらをそのまま日本のプロジェクトに適用することがベストとは限らない。今こそ，日本流のマネジメントを体得すべきである。

奥井 規晶　インターフュージョンコンサルティング 代表取締役

　情報システムが複雑化・高度化する一方で，単価の切り下げや納期短縮に対する顧客の要望は強まるばかり。このため，スキルの高いプロジェクトマネジャー（PM）が求められている。しかし，実際は未熟なPMがリスクの高い仕事を綱渡りのようにこなし，納期遅れや品質低下の危機に直面している開発現場が多い。

　このような状況を改善するために，IT業界ではいくつかの団体が，プロジェクトマネジメント手法の普及に努めている。しかし，それらの手法はいずれも欧米で体系化されたもので，必ずしも日本におけるシステム開発の実情に合っていると言えない。

　日本の開発現場には，日本的なマネジメント手法が必要であるはずだ。実際，日本のプロマネたちはこれまで，舶来の手法に頼らず数々のプロジェクトを成功させてきた。しかし残念なことに，そうした手法は体系化されることなく，PM個人の脳内に秘匿されてきた。

　本連載では，日本に合ったプロジェクトマネジメントとは何かを考え，その本質を解き明かしていく。第1回は，日米のプロジェクト運営の違いと，日本のトップPMが備える資質について考える。

トップダウンとボトムアップ

　ソフトバンクや楽天といった新興企業が相次いでプロ野球に参入し，ともに米国メジャーリーグ流の運営形態を取り入れたことが話題を呼んだ。実は，日米のプロジェクト運営の違いを考えるうえで，日米の野球チーム運営を比較することは良いヒントになる。

　メジャーリーグのチームは，経営者であるオーナーと球団を頂点にしたトップダウンの組織構造だ（図1）。球団はゼネラルマネジャー（GM）の任命権を持ち，チームのビジネス運営を担う。GMは，球団とともに試合のプロモーションを実施するほか，監督や選手の人事権を握っている。監督はGMに与えられた戦力でチームを勝利に導く任務を負い，選手は監督の指揮下で試合を戦う。

図1●野球チームの運営における日米の違い
図1●野球チームの運営における日米の違い
権限を明確に分化して上位下達の指揮系統を確立しているメジャーリーグに比べて，プロ野球は球団と監督の役割分担があいまい。時には監督の発言力が勝る場合がある

　一方，日本のプロ野球には現在，前述のソフトバンクと楽天を除いてGMはおらず，球団と監督がGM的な責任や任務を分担している。といっても，両者の間で明確な役割分担があるわけではなく，それぞれの権限が及ぶ範囲はチームによってまちまちだ。原則として，選手の人事権は球団が持っているが，監督が球団に対して強い影響力を持つことがある。長嶋茂雄氏や星野仙一氏のクラスになると「全権監督」となり，選手の人事に大きな発言力を持つ。トップの判断に現場が従うメジャーリーグに対して，現場の意見が運営方針を左右し得るのが日本のプロ野球である。

　トップダウンの米国と，ボトムアップの日本。この構図は，企業組織にも当てはまる。米国企業では，担当者の権限をはっきり規定して逸脱を許さず，トップダウンで理路整然と仕事を進める。これに対して日本の組織では，現場の総意に基づいて物事を進めるボトムアップ方式が尊ばれる。

　実際，こうしたボトムアップ文化が日本経済の成長を支えた。自動車やデジタル家電といった製造業が，その好例だ。欧米から輸入した生産方式に，現場が改善を繰り返し，世界最高レベルの品質と効率を実現した。開発プロジェクトも，例外ではない。より良いシステムを期限内に作るために，開発メンバーが自分に与えられた任務を超えて創意工夫を凝らすことは少なくない。

　ただし，ボトムアップは開発プロジェクトにおいて大きなリスク要因になり得る。「決定権を持つユーザー側の担当者がはっきりせず，要求仕様がなかなか固まらない」，「PMや開発リーダー，エンジニアの権限がはっきりしないので，マネジメントがあいまいなまま進められる」。日本のプロジェクトは，現場での臨機応変な対応が可能である反面，こうしたリスクが常につきまとう。

マニュアルvs「そうは言っても」

　トップダウンとボトムアップという日米プロジェクトの特徴は，権限の所在や組織構造だけでなく，プロジェクトの進め方にも現れている（図2）。

図2●日米の開発組織の主な特徴
図2●日米の開発組織の主な特徴
日本の組織は，現場の裁量権が比較的強い

　筆者は過去に何度か，米国での開発プロジェクトに参加した。そこで驚いたのは，アメリカ人が開発業務を徹底してマニュアル化することだった。彼らはまず，プロジェクトのゴールやそこにいたるプロセス・タスク，マイルストーン，判断基準などを徹底的に議論する。さらに，詳細まで明確に定義して文書化したら，それに基づき一気にプロジェクトを進める。マニュアルという客観的な物差しにより，異なるバックグラウンドや考え方を持つメンバーたちを納得させる。古くから人的移動が盛んで，異質な人間が共存する欧米の伝統が生んだ知恵である。

　もちろん，日本でもプロジェクトの手順やスケジュールなどを文書化する。しかし，そうした文書はいわば“紳士協定”で，拘束力は弱い。むしろ，「文書上はそうなっているが」と言いながら，メンバー同士の“あうん”の呼吸で進められることが多い。決められたことであっても，「そうは言っても」と融通が利くのだ。

　こうしたあいまいなプロジェクト・マネジメントは，民族や言語の同質性が高い日本人には都合が良い。ただし，想定外の修正・変更が途中で発生する可能性は大きい。さらに，現場での合意をうまく形成できない場合，プロジェクトは破綻する。

“玉虫色”の裁定が不可欠

　プロジェクト内で意見が衝突した時の決着方法も，日米で大きく違う。欧米人は徹底的に議論を戦わせるが，日本人は決着をつけたがらない。

　かつて参加した米国のプロジェクトで筆者は，メンバー同士の激しい議論を目の当たりにした。中でも，ことあるごとに意見を戦わせる2人のエンジニアがいた。この2人がぶつかる時は，それはもう徹底的にやりあう。見ているこちらがおろおろするほどだった。ところが，決着がつくと実にさっぱりして，両者はまた通常の関係に戻る。仕事は仕事と割り切り，議論で負けたからといって任務遂行に支障をきたすようなことは決してなかった。

　これに対して，日本のプロジェクトでは，メンバー同士が公の席で白黒つくまで議論することはめったにない。白黒つけてしまえば，負けた方が傷つくからだ。議論に負けたエンジニアは，人格を否定された気がしてしまう。「恥」という日本人独特の感情が湧き，仕事に対して非協力的になる。このため，PMはメンバー間で議論が勃発した時，どちらの顔も立つような“玉虫色”の裁定を心掛けなければならない。

　他のメンバーの活躍にどう反応するかも，日米で大きな差がある。

　これもやはり，先ほど触れた米国プロジェクトで経験したことだ。あるエンジニアが表彰を受けた時，メンバーは全員でパーティーを開いて祝福した。筆者の経験から言って，これは，日本では考えられないことだ。日本の開発現場では，優秀な人材が認められるのを妬む風潮があるからである。個人の活躍は，横並びを乱すものとして疎まれる。