Skip to main content

Posts

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

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

アメリカでプロジェクト・マネージメントをやってみて見つかる落とし穴

人間から人間への情報伝達の時間を、見誤る。 経験値によって、 A さんから B さんへの情報伝達のスピードは、上がります。 例えば、アメリカの現地の人間にソフトウェアの設計を始めて行わせるときに、経験豊富な日本人がリーダーになり、教えていきます。リーダーの前田さんは、部下に概要を話して、「これを、やって設計してみてください。」と部下のリチャードに言います。リチャードは、経験豊富なシステムアーキテクトで、知能も高い人です。 数日たって、リチャードの様子を見ると、何だかあまり進捗していません。 さて、何が起きているんでしょうか? 前田さんは、日本では何回も大規模プロジェクトをマネージしてきた人です。部下も持っていて、指示も出していました。 私が、リチャードに「何か困っていることはないですか?」と聞くと、「私の仕事のインプットが何かわからない。」と言います。彼には設計のお仕事をお願いしているのだから、要件は、きちんと彼に伝えられているはず。でも、それがちゃんと伝わっていない。 前田さんを呼んで話を聞くと、「ちゃんと、話しましたよ。」と言う。 最初は、私も、単なるコミュニケーション不足だと思っていたんですが、そうではなかった。 前田さんは、言ったつもり。しかし、リチャードは、完全に腹にはまっていなかった。理解の深さが、非常に浅かったんです。でも、そんなの当たり前です。初めてやらされること、初めて聞くことが、一瞬でわかる天才はいません。 日本では、前田さんの仲間は、同じようなプロジェクトをこなしてきた経験者、熟練者の集団です。 だから、一(いち)言うと、十(じゅう)わかる人たちなんです。 リチャードが、言われたことを咀嚼する時間と言うものを、きちんとプロジェクト計画に盛り込んでいかないと、一瞬でプロジェクトと言うものは、遅れるんです。 日本企業は丁稚奉公で、ソフトウェア開発を訓練します。最初は、小さい部分から始め、徐々に、経験を積んで、範囲を広げていきます。大学卒の新人は、はじめは、何がなんだか、わからないまま、言われることだけをこなしていく。その中で、様々な疑問を持ち、それを解きと言う訓練を続けます。 アメリカのソフトウェア開発の熟練工を中途採用して、彼らに仕事を渡す場合には、それでば成り立ちません。

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

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

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

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

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

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

日本人が、アメリカのプロジェクトを成功させる秘訣

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

アメリカのプロジェクト・マネージャーに期待してはならないこと

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