Skip to main content

何故、大規模プロジェクトが失敗してしまうのかは、幹部側の問題なのじゃないか?という仮説


何故、大規模プロジェクトが失敗してしまうのかは、幹部側の問題なのじゃないか?という仮説

多くの大規模プロジェクト(ソフトウェア開発)が、失敗する。

大規模プロジェクトと言うのは、言うなれば、「戦争」みたいなもの。本当は、戦争自体がプロジェクトであり、その中で、従属するプロジェクトがある。

であるならば、大規模プロジェクトを成功させるキーは、戦争から学ぶことができる。

ここでは、一部だけをお話しする。

大規模なプロジェクトでは、幹部がしっかりしなければいけないし、幹部の一人一人に対して、マネージできる範囲を規定しなければならない。日本の場合、熟練した経験豊富なプロジェクト・マネージャーが、大規模プロジェクトを任される。

アメリカも同じだが、プロジェクト・マネージャーを複数用意するところが大きく異なるように思える。

(アメリカ人のプログラム・マネージャーに聞いてみた。彼女の息子たちは、アメリカの軍隊で活躍している。)

アメリカの軍隊で喩えると、サージェント(日本語の軍曹)がプロジェクト・マネージャー、マスター・サージェント(曹長)がプログラム・マネージャー、カーネル(大佐)は、会社の部長各(PMO(プロジェクト・マネージメント・オフィス)の部長)を兼ねているプログラム・マネージャーとなる。

はっきりと、プログラム・マネージャーと複数のプロジェクト・マネージャーを確保することが、大規模プロジェクトをマネージするための基本体制と言える。

日本は、プロジェクト・マネージャーがいて、アシスタント・プロジェクト・マネージャーが付いたりするが、役割と責任の定義、それぞれのポジションの概念を考えると、日本のやり方は、非常にあいまいに思える。

さて、ついでに行っておくと、プロジェクトの責任者は、ジェネラル(将軍)に対応する。

本気で、戦争のメソドロジーを勉強しなければ、いけません。

勝つためには。

Comments

Popular posts from this blog

ソフトウェア開発の「基本設計」の英訳は、Basic Design ではありません。

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

プロジェクトのステアリング・コミッティーって、本来何なんだ?

日本の企業の多くの会社が、何らかの「プロジェクト」と呼ばれる活動を行っている。そして、プロジェクトを支える会議の一つとして、ステアリング・コミッティーという名前の会議を作る。 純日本風の会社は、だいたいその言葉を縮め「ステコミ」と呼ぶ会社も多い。(ちょっと、気持ち悪い響き) (ここでは、アメリカのプロジェクト・マネージメントの話をする。どう考えても、それが世界の標準となっているからです。でも、日本では、その標準が、自社に使えるように、いいとこどり、つまみぐいされるから、本物のプロジェクト・マネージメントが持つパワーを享受できない場合が多いような気がします。) ステアリング・コミッティーというのは、何をする会議だと思いますか?大体の日本人は、カタカナの言葉が、ピンとこないから、その会議に参加してみて、自分の経験をもとに、会議の目的を類推して、認識する。 「あぁ~、これは、プロジェクトのメンバーが、何かを報告しているな。つまり、現在のステータス(状態)のチェックだな。」 いいえ、それは、プロジェクト・ステータス・ミーティング(プロジェクト進捗確認ミーティング)の役割です。 プロジェクト・ステータス・ミーティングだったら、その会議を持つ責任者(ミーティング・オーナー)は、プロジェクト・スポンサー(プロジェクト・オーナーまたは、プロジェクト責任者)がやる。 発表は、プロジェクト・マネージャー、もしくは、複数プロジェクトをマネージするプログラム・マネジャーが行います。プロジェクト・マネージャーが、わからない部分に関しては、テクニカル・リーダー、テスト・マネージャーなどが同行し説明します。 ステアリング・コミッティーとは、コロンブスの西インド諸島発見の船旅で喩えると、大きな船の進行方法を左右に変えるために舵(かじ)がある。「舵を取れー」と映画で出てくるあの舵です。その舵を切る動作を、操舵(そうだ)と言いますが、操舵がステア( Steer )です。今、操舵しているのであれば、現在進行形にして、ステアリングとなります。 マストの上には、見張り番が常に望遠鏡で前方、まわりを監視し、何かが起こりそうになると、「それを通知します。」 例えば、前方の氷山が見えるのであれば、舵をどちらかの方向

日米のスケジュールの作り方の違い

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