アメリカのプロジェクト・マネージメントの実際

何故、大規模プロジェクトが失敗してしまうのかは、幹部側の問題なのじゃないか？という仮説 多くの大規模プロジェクト（ソフトウェア開発）が、失敗する。 大規模プロジェクトと言うのは、言うなれば、「戦争」みたいなもの。本当は、戦争自体がプロジェクトであり、その中で、従属するプロジェクトがある。 であるならば、大規模プロジェクトを成功させるキーは、戦争から学ぶことができる。 ここでは、一部だけをお話しする。 大規模なプロジェクトでは、幹部がしっかりしなければいけないし、幹部の一人一人に対して、マネージできる範囲を規定しなければならない。日本の場合、熟練した経験豊富なプロジェクト・マネージャーが、大規模プロジェクトを任される。 アメリカも同じだが、プロジェクト・マネージャーを複数用意するところが大きく異なるように思える。 （アメリカ人のプログラム・マネージャーに聞いてみた。彼女の息子たちは、アメリカの軍隊で活躍している。） アメリカの軍隊で喩えると、サージェント（日本語の軍曹）がプロジェクト・マネージャー、マスター・サージェント（曹長）がプログラム・マネージャー、カーネル（大佐）は、会社の部長各（ PMO （プロジェクト・マネージメント・オフィス）の部長）を兼ねているプログラム・マネージャーとなる。 はっきりと、プログラム・マネージャーと複数のプロジェクト・マネージャーを確保することが、大規模プロジェクトをマネージするための基本体制と言える。 日本は、プロジェクト・マネージャーがいて、アシスタント・プロジェクト・マネージャーが付いたりするが、役割と責任の定義、それぞれのポジションの概念を考えると、日本のやり方は、非常にあいまいに思える。 さて、ついでに行っておくと、プロジェクトの責任者は、ジェネラル（将軍）に対応する。 本気で、戦争のメソドロジーを勉強しなければ、いけません。 勝つためには。

昨日、面白いことがありました。 Microsoft Project というプロジェクト・マネージメント（スケジュールをマネージする）のツールが昔からあるんだけど、日本人とアメリカ人とで、視点がまったく違っていることがわかったんです。 日本人が、スケジュールを書くと、「これやって、それから、あれやって。」とやること（タスク）を書いていく。それに対して、アメリカのプロジェクト・マネージャーが不満を言う。「成果物がいつできるのかわからない。」 わかりますか？この違い。 アメリカ人の場合、「これを作って、あれを作って」という、成果物に主眼を置いてプロジェクトを組み立てるんです。「この設計書を作って、それからこのドキュメントを作って、…」という作り物が頭に、先にあるんです。お客様との契約でも、「納品物は、これとこれです。」と言う言い方をします。つまり、ゴールは、納品物を作っていくことなんです。 日本人は、プロセス（ How ）を重視して、スケジュールを決めますが、アメリカ人は、ゴール（ What ）を重視してスケジュールを作ります。 こういう視点の差が、実は、仕事の仕方の根本を変えています。 どちらが悪いのかいいのかと言うよりも、この考え方の差で、計画の作り方がまったく違ってくるし、日本人とアメリカ人の間で、大きな意見の食い違いが発生する。 何故かと言うと、お互いに自分たちのやり方が正しいやりかただと信じているからです。 ずーっと平行線をたどります。 なので、昨日は、 4 時間かけて、この話を調整し、お互いに欲しいものは何なのか？それをどう表現すればいいのかを、日本のソフトウェア・エンジニアとアメリカのプロジェクト・マネージャーを入れて、すり合わせました。この違いをはたから見てわかっている第三者が調整しないと、平行線が、平行線のままになって時間だけが過ぎ去っていくんです。 面白すぎます。

私の勤める会社は、 SIer （エス・アイヤー、 Solution Integrator ）なのですが、大規模ソフトウェア開発を行う際に、ソフトウェア開発の設計工程の呼び方として、概要設計、基本設計、詳細設計と呼んでいます。概要設計は、簡単に言えば大体の設計ですが、お客様にわかる言葉で書く。アメリカでは、 High Level Design と呼ばれるものに相当します。基本設計は、ネット上では、 Basic Design と訳されていますが、これは、和製英語の直訳です。英語圏には、 Basic Design と言う言葉はありません。 基本設計に対しては、 Functional Design （プログラムが何をするべきなのかを記述する）が一番近い言葉です。語感的に、 Detailed Design とか、 Low Level Design とか言われますが、英語自体が曖昧です。 詳細設計は、 Technical Design （機能が、コードレベルでどのように実装されるかを記述する） と言うのがいいでしょう。 この概要設計、基本設計、詳細設計というカテゴリー分けは、 IBM からではないと言うことはわかったので、恐らく、 NEC 、富士通、野村総研のどこかが言い出した言葉なのでしょう。

アメリカの場合、ソフトウェア開発プロジェクトを行う際には、役割と責任がわかれている。簡単に言えば、プロジェクトをマネージする人、ソフトウェアを開発する人などです。 一つのプロジェクトでも、アメリカでは、プログラム・マネージャー（複数プロジェクトをカバーする）、プロジェクト・マネージャー、エンタープライズ・アーキテクト（全社レベルのシステムを設計）、ソリューション・アーキテクト（個別のソリューションの設計）、ソフトウェア開発者、テスター、ビジネス・アナリスト（ビジネスがよくわかって、それを分析する人） / システム・アナリスト（システムがよくわかって、それを分析する人）、 SME （サブジェクト・マター・エキスパート、その分野の有識者）などで、チームが構成されます。 日本人が、このプロジェクトに参加すると、役割と責任の分解（あえて、日本の役割分担と言う曖昧な表現を避けます）の仕方がわからない。プロジェクト・マネージャーは、ソフトウェア開発の設計書なんて目を通さないことがわからない。プロジェクト・マネージャーは、プロジェクトをマネージするための専門家です。それを、日本人はわからない。 で、ほぉっておくと、口が達者なアメリカ人たちが言っていることが全うそうに聞こえてしまって、一番大事なところが、見落とされてしまいます。 簡単に言うと、 ①要件定義書に要件が網羅的に記述されているのか？ ②設計書には、きちんとすべての設計が記述されているのか？ など、経験者でないと、レビューできない本質的なところが、役割の違う人（この分野では素人）のレビューだけに終わり、取り返しのつかないことになってしまいます。 さて、プロジェクトを成功させるためのコツですが、「だれも、信用しない。」ことが肝要です。 どんなことでも、「このドキュメントの内容は、だれが説明責任を持つんだ？記述の責任者は、だれなんだ？その人たちは、内容を分かって書いているのか？」と言う、確認を常にし続けなければなりません。 でも、ちゃんと、相手の役割と責任の分界点を理解した上で、信頼してゆだねることは、もちろん大事です。 終わり

私の会社の安藤君は、大規模プロジェクトのエンタープライズ・アーキテクトで、日本では 15 年の経験があります。アメリカの支社の配属になって、約 1 年、ソフトウェアの開発プロジェクトで苦闘しています。 現在、プロジェクトが開始され、要件定義フェーズを終えようとしています。 今日、私のところにやってきて、「シェリー（プロジェクト・マネージャー）は、要件定義で何を書いたらいいのかわかっていないんです。だからレビューもできないし、要件定義のドキュメントが、きちんと書き終えているのかわからないんです。」と言ってきた。 私：「安藤君さぁ、アメリカのプロジェクト・マネージャーって、いろんなことをこなして、時間通りに終わらせることが仕事で、プロジェクトをマネージすることと、ソフトウェア関連のドキュメントのレビューは、まったく、やる人が違うのがアメリカなんだよ。プロジェクト・マネージメントとソフトウェア開発は、日本のソフトウェア開発の会社だと、一緒くたにされてて、ソフトウェア開発経験者がプロジェクト・マネージャーになるんだけど、アメリカは、プロジェクト・マネージメントの専門家なんだよ。だから、明日にでも、シェリーは転職して、彼女の知識と経験を利用して、建築業界のプロジェクト・マネージャーになれるんだよ。ソフトウェアのことを期待する君が間違っているんだよ。ソフトウェアの要件定義は、通常は、ビジネス・アナリストか、システム・アナリストと言う職種の人が行う仕事なんだよ。」 安藤君：「あっ、そうなんですね。」 私：「そう、安藤君は、日本の本社のやり方に洗脳されちゃってるんだよ。」 と言うことで、自分の仕事じゃないことをやれと言われるシェリー、プロジェクト・マネージャーとして彼女はこれをやるべきだと錯覚している安藤君の両方ともが、ストレスがいっぱいたまってイライラしてしまう状態が、ずーっと続いていました。 これは、日本人にありがちな、大きな誤解です。 日本だと、プロジェクト・マネージャー、ソフトウェア開発、テストなどは、一人でこなせます。 アメリカでは、プログラム・マネージャー（複数プロジェクトをカバーする）、プロジェクト・マネージャー、エンタープライズ・アーキテクト（全社レベルのシステムを設計）、ソリューション・アーキテクト（個...

読んで面白い「プロジェクト計画書」って言うものを書きたくなった。 ①登場人物を徐々に紹介。プロジェクト・マネージャー（キャプテン、ジャック・スパーロー）、ビジネス・スポンサー（スペインの女王）（最初から、全員の人の名前だけ伝えても、何が何だかわからない） ②物語の始まり。わくわく→何が始まるんだろう？どんな人が集まってくるんだろう。この海賊のキャプテンは、何をしでかすんだろう。戦略立案しているスペインの女王の取り巻き（大体、詰まんないやつが多い）。なんだなんだと引き込まれる感じ。または、 7 人の侍が集まってくる感じ。徐々にすごいやつが現れる。 ③苦しい、悲しいことを見せて、みんなの感情を揺さぶる。やっぱ、悪い奴（足を引っ張るやつ、内部の裏切り者、裏で糸を引く悪代官）とか、ダークな魔法が必要。（悲観シナリオだとこうなるんです。だれも、楽観シナリオには興味がない。） ④どうやって、冒険は始まり、どうやって海賊をやっつけるんだ？どうやって、王女様を付けだすんだ？宝物を探すための地図は、手に入れたのか？（マイルストーン）。イライラ感をくすぐる。（リスクの洗い出しと、解決策） ⑤（この⑤は、計画ではない。でも、計画にはオチを考えておかなければね）本当の「愛」ってこれだったんだぁ～（マレフィセントのアンジェリーナ・ジョリー）（最後の安心感） ⑥（つけたし）これが、物語のすべてなので、反省会（教訓とか学び）なんてしない。将来、後継者の人たちが見たいものって、物語であり、反省会の結果なんて見たくない。（唯一、反省会をしたいのは、大失敗したプロジェクトの後付けで作った物語） 無駄なこと、将来だれも興味を持たないことは書いてはいけない。 つまり、プロジェクト計画書って、台本なんだよね。映画が取られ始めたら、アドリブで、いろんな面白いことが発生し、その都度、演出（面白くするための、成功させるための対応方法）が入る。（台本を都度、書き換えたりなんかしない） 最後に欲しいのは、書き上げられた物語。 →みなさん、プロジェクト計画書作りと言われると、気が重くなりませんか？もっと、楽しくやれば、もっと成功できるような気がする。