オフショア

2005年09月21日

疲レタ。

今日はだらだらと。

さて、以前お話しましたが、現在「初級1」あたりを漂っている私ですが、本日やっと「初級1」が終わりました。

「初級1」、中国語語学学校の話です。

「あぁ、来週は「初級1」のテストか。ちょっとメンドクセェな」

なんて思っていましたが、先生が言います。

先生:「復習はゆっくりやった方がいい?」

ゆっくりも何も自分のペースでやりますから。
ん?学校でやるって言ってます?

サッチモ:「復習って学校でやるの?」
先生:「そうだよ。普通は全部で24時間ぐらい」

ってそれ全12章しかないから1章について1日(1日2時間なので)かけるっていってます?

無駄話&練習問題&章毎のテストがないことを考えれば今までかかった時間と同じなんですけど......

先生:「でも復習を自分で全然しない人は今までかかった時間と同じぐらいかかるんだよね」

うーん。

テスト前に復習を学校でやるなんて至れり尽くせりだけど、「自分でやるから先進んでくれ」なんて無しですかね?
でもそこまで言われるとどんなレベルのテストをするのか非常に気になります。

ま、授業でやるって言ってんだからそれはそれでやりますよ。

つーことでまだしばらく「初級1」を抜け出せません。

たしかその後「初級2」「中級1」「中級2」「上級」だったかな。

なげぇな。

ま、徐々にやってくしか無いんですけどね。

 

そうそう、話は変わりますが、最近疲れが全く抜けないんですよ。
単に年を取ったせいだとは思わないんですけどね。

最近仕事をしていても発注先の中国(私が常駐している)の会社が1年前、つまり私が来た頃に比べてほとんど成長してないんですよ。

問題が発生した時の報告が無いのは当たり前で、そもそも問題が発生した時にそんなに重大な問題ではないと思っている様子。
問題の重大さを自分で判断できるほど経験あったっけ?

今回のプロジェクトは以前に比べて管理が楽になったのは事実なんですが、その背景には

・設計書がきめ細かい
・そもそも仕様が以前に比べると簡単

など原因は彼らの成長を裏付けるものにはならないんです。

問題が発生しても俺が何とかすると思ってるんでしょうか?

俺も客なんですけどね。

通訳も、マネージャも前回のプロジェクトから比べて成長したんじゃない?と思う奴らは違うプロジェクトにアサインされるか辞めちゃいます。

辞める理由は会社が嫌になった訳ではなく、いろんな理由によるもので納得はできます。

でも違うプロジェクトにアサイン、つまり配置換えについてはせっかく育ったやつを他のプロジェクトに回すということは俺に常に教育係を求めてます?

この会社の副社長、いい人です。そんな彼が言います。

「会社に組織力が付いてきた」
「俺も現場に入る」

私からすると

現状の組織力:
マネージャ職のヤツが会社の中で組織の中での立ち振る舞いが若干できるようになった。

俺も現場に入る:
実行されてませんから。。。。っていうか全くノータッチだよね。

さらに最近通訳として入った女性。
英語が堪能で日本語もいけるといってましたが、

仕事で使えません。

それに

俺、英語話せませんから。

そもそも英語で話すんだったらITを知ってるマネージャと片言の英語で話した方が、お互い意味は通じます。

それに翻訳させても、分からないところは中文そのまま残して納品してくるし。

他に日本語できるやついるよね?

何で聞かないの?

せめて分からないところが有るんだったらそのまま納品せずに俺に聞くぐらいは最低しなきゃいけないんじゃないの?

1年前から同じこと言ってますが、ナレッジの共有はされません。

という感じで、結局プロジェクトの運営には全く関係ありません。
むしろ悪化しているといった方が良いのでしょうか。

中国でのオフショアのメリットってコストメリット以外に無いんだと思います。
今後、「品質はやっぱり中国」みたいな方向になれば別でしょうけどこの会社でそれは当分望めません。

さらには最近はベトナムやタイでもオフショアが盛んです。
つまりコストメリットだけを考えればそっちのがいいわけです。

どうすんのかな?

以前のプロジェクトの問題点って彼らに渡して有るんだからせめて新しく入ってきたやつにはそれ教えてあげないと。

俺にまた同じこと注意して教育して欲しいの?

嫌だ

自分達で気づかないと先は無いですよ。

できない人たちじゃないんだから。
怠けてるだけなんだから。

つうことで明日は違う仕事で気分転換します。

仕事で気分転換?

癒してください。
  ↓
結局愚痴ですか?(ブログランキング)



satchmo_sh at 23:59|PermalinkComments(0)TrackBack(0)

2005年09月03日

疲マスタ、イヤ、ホントニ。

さて、久々に仕事の話。

現在のプロジェクトにおける主な問題点。

1.進捗報告が無い
2.課題管理がされていない
3.会社として問題意識がない

今回のプロジェクトは設計書も丁寧に書いたし、仕様自体も難しくない。さらにはスケジュールも若干余裕が有る。

そして前回のプロジェクトで散々教えたプロジェクトの管理の方法についてどれだけ理解しているんだろうということも踏まえ、ある程度

放置プレイ

を決め込んでいました。
んで結果は上記の通り、

何も向上していない。

1.進捗報告が無い

スケジュールに対する実績だけが送られてくる。全く予定通りだったとしても報告は必要なわけです。ましてや問題が発生しているならなおさらです。

以前、この会社のマネージャが言いました。

マネジャ:「簡単に解決する問題だから報告の必要なし」

いや、別にいいけどね。全部責任とってくれるんだったら。でももし問題が解決できない、もしくは見込んだスケジュール内で解決できなかったらそれ全部キミの責任だよ。だって問題が発生したこと聞いてないから。

報告が自分のリスクヘッジになることも散々教えたよね。

これね、自分の上に立つ人間がダメな場合は特に有効なのよ。基本的にはプロジェクトにかかわった場合、どのポジションでアサインされてもそれが自分のプロジェクトだと思ってやったほうが見えることが多いし、自分の為にはなるんですけど、どうしても線を引かないといけないことって有るわけですよ。

例えば、分かりやすくあるプロジェクトでのプロジェクトマネージャとその下にいるリーダの関係を考えてみる。

自分がリーダとしてアサインされました。PMが全然ダメ。でもこのプロジェクトを絶対に成功させたい。そこでPMに成り代わりこのプロジェクトを自分で仕切ってうまく収めよう。

正しいです。非常に。

が、

与えられた役割ってモノにはそれに伴う責任が有るわけです。つまり、勝手にPMの動きをすれば自分の責任範囲を超えてそれをやることになるわけですから、失敗した場合、

「こいつが勝手にやったこと。全部こいつが悪い」

となってしまう可能性があります。
なのでPMには

「こういう問題が有るからこう対処します」

ぐらいの報告は必ず上げます。これはPMに何かを期待するわけではなく、「問題をPMが知っていた」という事実を作る為に行います。

例えばそれで失敗した場合、

「PMはどんな問題が発生していたか、リーダがどういう対処をしようとしていたかを知っていたのに何もしなかった」

という結果に持ち込むこともできます。
さらにまわりの人間に自分がそういう動きをせざるを得ないということを認識させることができればさらにいいです。

問題のケースによって、自分がいる組織によってその立ち振る舞いは変わりますが、それでも自分に責任を負わされるのであれば、その組織自体が基本的にダメか、わざと責任が追わされるように誰かが、PMなのかその上なのか、そういう振る舞いをしている人がいるはずです。その辺は気をつけましょう。

これは基本的にPMとリーダだけではなく、他のポジションでも当てはまることです。

2.課題管理がされていない

進捗報告にも通じる話ですが、何か問題が起こった場合、スケジュールへの影響の有無にかかわらず、問題が発生した時点で課題としてあげないと。

ダメじゃん

なんで?

プロジェクトにかかわる全ての人間が前述したように

「これは自分のプロジェクトだ。なんとしても成功させたい」

と思っていることはほぼありません。もしそうであれば極端な話、課題管理なんて必要ありません。

課題管理の目的は課題を列挙することではないでしょ。よくあるのが課題が挙がっているだけの「課題管理表」ですが、これは

意味がありません

重要なのはその課題を「誰がやらなければならないのか」ということです。たまに課題が発生した当初、これは誰がやると明記されているもそれっきり進まないという状況に出くわします。

こういう場合に多いのは最初にその課題を解決しなければいけない人間の次のアクションが記載されていないというものです。状況は常に変化するわけでし、その課題にかかわる人間も1人とは限りません。

つまり「誰が」に加えて「いつ、何を」も課題の状況を踏まえ常に更新することです。

そうすれば課題管理表を見るだけでも今、誰がその課題にどう取り組んでいるのかがわかります。そうすれば課題が解決されない場合、誰の責任なのかが簡単にわかります。

3.会社として問題意識がない

この会社の副社長が言います。

副社長:「今、マネージャがダメ、だから私も現場に入ります」

ですが、結局問題が発生した時に

副社長:「彼らは未だわかっていない。遺憾です」

ぐらいのセリフが飛び出すわけです。
「現場に入る」ってどんな意味だったんでしょうか。

 

ここで私の選択肢は2つ。

仝世ぢ海韻譴个い弔は分かってくれるということで今回の問題点をしつこく追及して原因を提示し、今後の改善に期待する。

■映間同じことを言ってできないのだから、今できること以上を要求せず、できることだけを要求する。

これは状況によっても違いますけどね。

例えば、その中国の会社が子会社だった場合、選択肢は,靴ないわけです。子会社でなくともその会社を育てようと思っている場合も同じです。

△鯀択してもコストメリットが有るのであれば△鯀択する意味もありますよね。そもそも現状のオフショアの目的はそこにあるわけですから。

,両豺腓肋来的にさらにコストを下げる場合には必須ですね。細かい指示をしなくても管理できるようになるのであれば発注側の管理コストが著しく下がりますからね。

ま、他にも状況によって色々あるとは思いますが。

選択肢が2つ有るといいましたが、実際は,靴ないんですね。なぜって私が△鯀択した場合、当然発注側の会社にそれを伝えて今後はそういう発注の仕方をするように言わなければならないわけですが、その時点で予想されるのは

発注側:「それってオフショアの意味あんのか?」

今はコストだけだったら他にやすい国もありますからね。

ははは。。。

私が抱える問題の本質とはこれいかに。

帰ってきたばかりで(今日は9/5)で疲れてるので文章にまとまりがありませんがお許しを。

たまには仕事の話もして見ます。

いかがでしょう

有り
無し

今日新しい部屋の写真を撮ってきたので次はそれで行きます。



satchmo_sh at 23:59|PermalinkComments(2)TrackBack(0)

2005年06月05日

問題の本質

今日は久々に先が見えない仕事の話。
 
先週末、中国側企業のマネージャより前プロジェクトの「プロジェクト報告書」が私宛に送付されてきた。
 
結論から言うと私が求めていたものとは全く異なるものだった。
 
4月の連休前に前回のプロジェクトについてについて双方反省点を洗い出し、次回のプロジェクトに役立てよう、そのために双方で問題点の抽出をしようということを私は提案していた。
 
中国側企業もその提案を快諾し、その際に私の方から中国側企業の問題点としていくつか挙げ、その回答と中国側企業でさらなる問題点の抽出、日本側企業の問題点の提示を求めた。
一方、私の方でも日本側企業での問題点を洗い出し、日本側企業に対して5月のはじめにレポートを提出していた。
※本来日本側企業のマネージャ自らそのレポートを作成すべきだが、私も契約先への納品物という意味合いとプロジェクトの総括という意味で作成した。
 
その中国側企業からの結果が昨日送付されてきたのである。
 
実は5月のはじめに期限を決めて送られてくるはずであったが、現在中国側の企業が請け負っているプロジェクトで問題を抱えており、この作業が遅れていたのだ。
 
確かにこの作業にはコストがつかない。いくら今後の投資的な意味が含まれているとはいえ、小さな企業にとって直近のプロジェクトをトラブルなく遂行し、売差を確保することは重要な課題であることは理解する。
 
彼らの名誉の為に言っておくが、これは彼らに非があって問題を抱えたのではなく、元請の私が契約している企業とは別の日本側企業の仕切りの悪さが原因であることは明らかだった。
 
話を戻す。
 
まず、前述したように、私は「プロジェクト報告書」を求めたわけではない。名前が「プロジェクト報告書」になっているだけであれば別段何の問題もないのだが、そうではない。
一番残念なのはこちらから提示した問題についての回答がほとんど無いことだ。
 
このドキュメントは日本語で作成されている。しかし、日本語の表現が曖昧だとか、そのようなレベルの話しではない。そもそも顧客に対する成果物として作成されたものではなく、双方のリスクをいかに減らすかという意味において作成されたものである為、日本語の表現に誤りがあったとしても、確認こそすれ、今回は問題にするつもりなどなかった。
 
また、私が提起した問題がほとんど記載されていない。記載されているものもあったが、私がブレークダウンした問題を逆に抽象化してしまっている。
先ほど「回答がほとんどなかった」と言ったが、回答があったものの例を挙げてみる。
 
プロジェクトを遂行する中で、不可解な質問が出始めた時期があった。設計書に明確に記載されていることが質問票としてあがってくるのである。疑問に思い、設計書をどのようにSEに伝えているのか確認すると、「量が多いので全てを翻訳はしていない」という回答が返ってきた。
 
今回のプロジェクトの体制では一般に言われる日本語が話せるブリッジSEはおらず、通訳がついている。しかし、中国企業側のPMから設計書の量が多い為に全ての翻訳をしていては間に合わない為、ところどころ通訳に翻訳の指示を出していたのだ。
当然通訳がどこを訳せばいいのか判断することなどできない。そもそもそれでは設計書の意味をなしていない。
結局、全ての設計書のレビューを口頭で行う羽目になった。
 
さて、そもそも設計書を各メンバーに伝える為の体制を組むことが出来ないという問題に対する解答だが、私は以下のような回答を予想していた。
 
1.通訳を増やす。
2.設計書を通訳、翻訳する時間をスケジュールに組み込む。
 
1.は時間がないのであれば人を増やして対応するというものである。2.はそもそも設計書を翻訳するのは初めから必要なことはわかっているわけだからそれをスケジュールに正しく反映するというものだ。確かに日系ベンダからのスケジュール要望はあるだろう。しかし、そのリクエストに応えられない体制のまま進んでしまえば、うまくいかないのは目に見えているし、日系ベンダがそれを呑まなかったとすれば、そもそもこの日系ベンダには「オフショア固有のコスト」が理解できていないことになる。
このような日系ベンダと取引してもうまくいくはずが無い。無理な要求だけ押し付けられるのは目に見えている。幸いこの中国企業は他の日系ベンダから資本提携を受けているため、そのような日系ベンダから「戦略的撤退」をしたとしてもそれほど影響は無い。
 
では中国企業からの回答はどうであたったかというと以下の通りだ。
 
「現在、通訳の日本語レベルが高くない。その為、通訳に時間がかかってしまい、スケジュールに影響を与える。また、他の要員についても日本語が話せない為、現在日本語教育を行っており、この問題の解決に努力している。」
 
まず、問題の本質を捉えていない。このマネージャは私が先ほど言ったように、設計書を翻訳できない体制でプロジェクトを進めたことを問題視していない。次に現在日本語教育を行っているということだが、これは私も毎日これが行われることは目にしており、会社として取り組むのはすばらしいことだと思う。しかし、「努力する」というのは解決方法にならない。
 
例としてあげたがこのようなものが多く、とても有用なものではなかった。
 
日本側の企業には彼らのレポートを受けて私が作成したレポートを補完すると言ってあったのだが、この内容を受けてドキュメントにコメントだけして、日本企業に送付した。
 
私は週明けに確認しなければならないことがある。これがマネージャ個人で作成されたものなのか、会社として作成されたものなのかである。
後者の場合、個人的には別の会社をパートナーとして乗り換えることも考えた方が良いとも思っている。
 
この結果を受けてさらに日本企業にはコメントした。
「この内容を踏まえ、何かしら検討が必要かと思います」
と。
 
表現を曖昧にしたのは私が「個人的に」と言ったことを日本企業も思っているのか、それともパートナーを維持する為に何らかの方法、たとえば、これを真剣に取り組むように促すような方法を提示するのか探りたかったからである。
 
日本企業数名に送ったのだが、まず、現場のマネージャからの回答は、彼らの今後の取り組みに「期待する」というものだった。
 
先ほど「努力」は解決方法にならないと私は言った。「期待する」も同義である。
 
通常、この回答から推測するに「期待する」という解決に向かう以外のコメントが寄せられたということは「撤退、乗り換えもある」という意思表示に他ならない。
 
しかしである。
 
この現場マネージャを知っている私の見立てではこれはどちらでもない。
 
オワカリカ?
 
オフショアはこのような問題の連続である。ただし、問題は発注先、発注元両方にある場合が多い。今回、中国企業の報告書を受けて書いた為に彼らの問題を取り上げたが、当然、私が書いたレポートには日本企業の問題点も山のように挙げられている。
 
オフショアの前提として2つの方向が考えられる。
 
1.要求を満たす発注先を見つけるまで小規模の案件を発注し、ベストマッチする企業を探す。
 
2.可能性のある企業と資本提携、もしくはパートナーを組み、その企業を育てる。
 
さらにその前提として、自社で行っているプロジェクトの運営方法と、「オフショア固有のコスト」を踏まえたうえで損益分岐を割り出し、オフショアに適正な規模のプロジェクトを決めることも重要だ。
 
オフショアの問題は文化の違い?そんな曖昧な問題ではない。もっと具体的な問題だ。発注先は明確な目的を持ってオフショアに望むべきだ。そしてそのリスクも考慮すべきである。
 
私も問題の本質を今一度見つめたい。
 
それこそが最も重要であるからだ。
 
カラダがいてぇ。
走りすぎた。


satchmo_sh at 23:59|PermalinkComments(0)TrackBack(0)

2005年05月12日

上海で思う人の育て方

中国人は「報告」「連絡」「相談」が出来ない。
 
よく言われることだ。
いわゆる「ホウレンソウ」である。
 
私が思うにこれが徹底して出来る日本企業も多いとは思わない。しかし、なぜ合言葉のように中国企業に対してこの言葉が使われるのだろうか。
 
中国人の資質なのか?
 
それは「否」である。
少なくとも私が仕事をした中国企業で働く中国人を見た結果は「否」である。
 
ではなぜ資質は持ちながらそれが出来ないのか?
 
これも私の個人的な見解からいえば単純に教えられていないからだ。
ただそれだけの理由である。
 
「ホウレンソウ」、企業の新人教育ではよく使われる言葉だ。
しかし、IT業界に限らないと思うが、1度でもプロジェクトマネージメントを経験した方であればこの言葉が、単に新人教育の「合言葉」ではなく、本当の意味でこの重要性を理解していると思う。
 
私は思う。
間違っているという人もいるかもしれないが、プログラミングの技術やインフラの知識、プロジェクト管理の知識、そんなものは後からいくらでも手に入れられる。
しかし、「仕事のスタンス」は最初に決まってしまうものだと思う。
 
私が今契約をしている中国の企業は社員数100人に満たず、その半数が25歳以下という若い会社だ。
 
まだ間に合う。
 
要は常に「考えさせる」ことだ。例えば「ホウレンソウ」がなぜ重要なのか知識として教えるのではなく、なぜ重要なのか「考えさせる」ことだ。そうすれば自然と実行できる。
 
同じ会社の30歳の中国人マネージャと以前こんなことがあった。
私は彼が提示してきた進捗報告書にクレームをつけた。そのとき彼が言ったことは
「あなたは何をどこまで報告して欲しいのか。つまり報告書をどう作ればいいのか教えてくれ!」
 
言い忘れたが、彼らは単純に下請企業とう訳ではなく、パートナーと位置づけて育てていこうという意図もあった。その為、管理ドキュメントなどの雛形なども提示せずに彼らがどのようにプロジェクトを遂行するか見てみようということで、社内システムを発注した経緯がある。「失敗も可」という前提でだ。
 
私が期待していた、というよりも診てみたかったのは進捗報告の意味を「考えた」上で作成することだった。しかし彼は進捗報告がほしいというリクエストに対して進捗報告らしく体裁を整えて提出しただけだった。
 
こんなこともあった。中国人マネージャは
「このプロジェクトで私たちはCMMレベル3を取得するつもりです」
※CMM:簡単に言えば組織のソフトウェア開発能力を評価するためのモデル
私は絶対に失敗するという確信があった。失敗するというのはCMMを取得することについてではなく、
「CMMを取得することにより開発プロセスの改善を図ること」
についてだ。
なぜか?
彼らが「考えて」いないからだ。案の定CMMレベル3を取得する為のミーティングが連日開かれていた。
そう、既にこの時点から彼らの目標は
「CMMレベル3を取得すること」
であり、
「CMMを取得できるような開発プロセスでシステムを開発すること」
ではなくなっていた。
 
プロジェクトが終わるまでにプロジェクトメンバと個別で話をしたが、誰も疑問には思っていなかった。ただ副社長に
「CMMレベル3を取得せよ」
という命令を受けたから実行したに過ぎない。
副社長とはよく話をする。営業的な戦略もあるだろうが、単に会社の肩書きとしてほしいという意味でその命令を出したのではないことはわかっていた。
しかし、メンバにその意図を十分に伝えることが出来なかった為、今回の結果を招いてしまった。
 
私は「まだ間に合う」と言ったのを覚えているだろうか。
 
「考える」というのは30過ぎてから教えても無理だと個人的には思う。既に「仕事のスタンス」が決まってしまっているからだ。だから社員の半数が25歳以下ならまだ間に合うと思ったのである。
 
「考える」ようにさせる為に仕事をしながら個々に教えるよりも会社に入った最初の時期に、仕事を始める前にちゃんと教えてあげるべきだと思う。教育は専門ではないのでどう教えるかは専門家に任せる
 
中にはそんなことを教えなくても出来る人もいる。しかし、そういう人間が出てくるのを待つ方が良いのか、そういう人間を作る方が良いのか、私は後者だと思う。
 
確かに教育にはコストがかかる。規模の小さい会社では短期的に売り上げを確保していかなければならないのもわかる。これをどう判断するかは経営者によるのだが。。。。
 
いずれにしろこの会社の社長、副社長は人材育成について真剣に考える数少ない中国企業である。彼らがそれを実行に移したとき、この会社は本当に強力な力を手にするだろう。
それこそCMMという肩書きなんか必要ないぐらいの信頼を獲得することも出来るだろう。
 
彼らのような経営者が増えることにより、冒頭で言った
 
中国人は「報告」「連絡」「相談」が出来ない。
 
という言葉も聞かれなくなるだろう。
そしてこの会社が変わっていく過程を私はもうしばらく見ていたい。
 


satchmo_sh at 23:59|PermalinkComments(0)TrackBack(0)

2005年05月07日

できるひとできないひと+良い上司悪い上司

新人のころに覚えたことはなかなか忘れない。
そしてそのとき助けてもらったことも絶対に忘れない。
 
私は上司に恵まれた。
今でも自分の仕事の基礎はその人から叩き込まれたと確信し、そして感謝している。
 
彼はよく言っていた。
「自分が出来ることとやっていいことは違う」
と。
初めて聞いたとき、
「はぁ?出来るんだったらやって何が悪い?意味わかりません」
と思っていた。
 
しかし、すぐその意味に気づくことになった。
 
当時私は2億数千万の基幹システムの構築プロジェクトの開発中(開発も終盤を迎えたころ)に配属された新人でシステムのカットオーバー後、トラブル対応をしていた。主な仕事は
 
「発生したトラブルを正確に把握し、PM(上記の上司)に正確に報告すること」
 
であった。
 
「ただの報告」
 
と当時は思っていた。
 
ある日客からトラブルの連絡を受けた。以前発生した障害と同じ現象だったため、以前の対応日からリスクを1日積み客に対応日を連絡し、PMに報告した。しかし、PMは激怒し私に言った。
 
「なぜ、このシステムを設計していないお前が、現象を特定する前に客にスケジュールをコミットしたんだ?俺はそんなことお前に頼んでないし、お前にそんな権限も与えてない」
 
正直納得がいかなかった。前と同じ現象であれば客に少しでも早く対応日を連絡することで迅速な対応を印象付けられるし結果は一緒じゃないか、やっぱり会社がでかいとお役所仕事になってしまうのか、と。
 
でも、結果は違っていた。
同じに見えた現象も原因は全く異なり、私が客にコミットした対応日より数日を要することがわかった。
幸い機能的に重要なものでなかったこと、他のリカバリ方法があったこと、PM、リーダ(当時の先輩)の絶妙なフォローにより大事には至らなかったが、PMは客に謝罪した。
 
※余談だが、当時、ある問題を抱えていた私を寝る間を惜しんで週2のランパブがよいで気を紛らわせてくれた先輩に感謝する。決してつき合わされたのではないと思いたい(笑
 
正直、新人の私にとってこの出来事は衝撃だった。そして彼は私に体制の中での役割と責任について改めて説明をした。
 
彼は決して手取り足取り教えてくれるタイプでは無かったが、私には彼のやり方があっていた。わざと私に対してそうしたやり方を取ったのかはわからない。今度日本に帰ったときにでも聞いてみよう。
 
以前、「上司として最適なのは?」という話を聞いたことがある。上司には以下の4タイプが存在するらしい。
 
〇纏が出来てなぜ出来るのかわかっている人
∋纏が出来るがなぜ出来るのかわかっていない人
仕事は出来ないがなぜ出来ないのかわかっている人
せ纏が出来ず、なぜ出来ないかもわかっていない人
 
上司としては,鉢が最良だと。
原因は
 
,匹里茲Δ砲垢譴仞功するのか説明できるから
どのようにすれば失敗しないか説明できるから
 
だそうである。△呂覆爾世瓩覆里。
 
△覆室分が出来るかがわかっていない為、出来る自分が標準であり、部下にも同じ成果を求めるがどのようにすればそれが出来るのか説明しない。
 
一概に賛成できるかといわれればどうかと思うが間違ってはいないと思う。△鰐价縫織ぅ廚世蹐Δ。
 
彼は間違いなく,世辰拭
 
私が数千万のある生産管理システム構築のリーダとしてアサインされたとき、PMをやる予定だった方が早期退職制度を適用し突然会社を辞めることになった。かなり突然だったこととこの方は今回、早期退職では辞めないと上司に言っていたこともあり、急遽PMを探さなくてはならなくなった。
 
そのとき彼が「サッチモだったらできんじゃない?問題ないでしょ?」と言い放った。
 
当時の私は3年目を迎えたばかりで、通常、社員数千人を抱える大手のSIerで3年目の人間が数千万のプロジェクトでPMを張れることは少なかったが、当時、PMが出来る人間は既にプロジェクトを抱えていたこと、また、彼が組織の中で力を持ったポジションにいたこともあり、PMをやることになった。週1でコスト、スケジュールの進捗を報告することを条件に。
 
プロジェクトは成功した。納期もコストもスケジュールにも問題なく、カットオーバー後もほとんどトラブルは発生しなかった。
 
自慢ではない。なぜならこのとき、お客さんもかなり協力的で協力会社にも恵まれたことを当時の私は十分に理解していた。決して自分の力だと思っていない。
 
しかし、結果的にこのプロジェクトを通して自分に自信がついたこと、営業や当時の上司から信頼を勝ち得たことにより、以後、PMとしてアサインされることが多くなり、自分のキャリアに大きく影響することになった。
 
前職の会社では40、50代の海千山千の老獪な「おっさん」たちに混じってPMを勝ち取れるチャンスなどほとんど無い。もちろん、若手をつぶそうとしてそうなるのではなく、リスクを考えて結果的にそうなってしまっているのだ。それを考えると上記のように偶然転がり込んだチャンスを彼が後押ししてくれたことに感謝しても仕切れない。おそらくことプロジェクトが無かったら今の私は無かったと確信している。
 
また、当時このプロジェクトに参加した協力会社の方も「3年目の若造」に対して文句もあっただろうが本当に惜しみない協力をしてくれたことに心から感謝している。この方たちとはこのときのお客さんと共に仕事をしなくなった今でも個人的にお付き合いさせていただいている。
 
私が会社を辞めるとき彼は
「なぜ俺に相談しなかった?まぁいい。自分で考え抜いた結果だよな。俺が止めても行くんだよな」
と言ってくれた。ちなみにこのとき、彼は既に上司ではなかった。
 
育つ奴は勝手に育つ。しかし、どうやって育てるかによって「のびしろ」は大きく違ってくる。最近、大卒がベンチャー志向で「どうやって自分のキャリアを積ませてくれるのか」といっているらしい。確かにホリエモンみたいな人もいるのでそれ自体間違っているとはいえないが、大企業で学べることも多い。自分が欲しいものがどこにあるのか、そして自分の足元をしっかり見ていれば大企業でもベンチャーでも流されることは無い。ベンチャー最高!と叫ぶ前にもう一度考えてみては?と思ってしまう。
 
私は今、上海で仕事をしている。今までの経験を食いつぶすだけでも十分に仕事は出来るが、それだけはしないようにこれからも前を向いて仕事をしていきたいと思う。彼に
 
「お前、小さくなったな」
 
と言われない為に(笑


satchmo_sh at 23:55|PermalinkComments(0)TrackBack(2)

2005年04月23日

体制とその役割+バカ話

今日はちょっとまじめに仕事の話。

※話を始める前に今の会社の主な業務と私の仕事内容を簡単に説明します

■業務内容
クライアントから業務システムをオーダーされ、要求に従いシステム構築する会社である。売り上げの大半は日本の企業からである。

■私の仕事
私は日本のある会社と個人的に専属契約を結んでいる。そしてその会社から発注されたシステムを中国で作る際の監査を行い、プロジェクトが軌道をそれたとき、もしくは正しく進むように軌道修正するのが仕事である。他にも契約先の日本の会社が新規に始めようとしている中国での事業のリサーチ、サポート時にはそのプロジェクトを自ら行うこともある
ちなみに今の日本の会社と契約をする前、日本で「ぷろじぇくとまねーじゃ」を生業としていた。

システム開発のプロジェクトではクライアントへの提案時に開発する際の体制を提示することが多い。
例えば、プロジェクト全体を統括するプロジェクトマネージャは誰で、この業務システムを担当するリーダは誰でといった具合に。

さて上海に来ました。
上海ライフを堪能するまもなく早速システム開発の依頼。

中国企業に体制図の提示を求めた。

私は中国語が話せない。正確には日常生活を行うには困らないが、仕事を全て中国語で話すことはできない。
「日常生活ができるんだったら仕事でもある程度話せるでしょ?」
と考える方もいるかもしれないが、これは人によって違うだろうが、私は簡単に言うとフリーランスである。例えば私の適当な中国語により、システム開発に重大な問題が発生したとする。その責任は誰にあるか?当然私にある。そのため、仕事では必ず、通訳をつけるように要求するし、日本の会社とも中国語が話せることを前提として契約はしていない。

さて話を戻すが、体制の中にも上記にあるように通訳が組み込まれている。私が考える、というよりも私が中国側企業に求めた通訳の役割は以下の通りだ。

・設計書の翻訳
・私の通訳
・私が中国側企業に出したメールの翻訳

さらに注意事項として

・わからない言葉、どちらとも取れる言葉は必ず聴きなおす。
・「通訳をして欲しい」と私が言ったとき、私が話したことについてどんなことでも全てを通訳する

実際はもっと細かい注文をしているがざっくりと言えば上記のようになる。

仮に通訳の彼をA君としよう。ある日、中国側のプロジェクトマネージャ(以下PM)にシステムの仕様について伝えなければならないことがあり、A君に通訳を頼んだ。

仮にも片言の中国語がわかる私はA君が私が話したこととは違うことをPMに伝えていることに気づいた。

私 :「なぜ、私が言ったことをそのまま伝えてくれないのか?」
A君:「私はシステムの通訳をして半年経つ。そして本プロジェクトについて設計書の翻訳を行った。だから誰よりもこのシステムに詳しい」

これは完全な誤りである。開発を一部ストップし、他にもこのようなことが無かったか洗い出した結果、いくつか問題が発見され、速やかに訂正した。以下は後日のA君の発言である。

A君:「この前あたなに指摘され、システムの仕様に対して自信がなくなったのでこれからは全てそのまま伝えることにします」

私はPMと要員をアサインした副社長を呼んで話をした。副社長によるとA君をこれからSEとして育てていきたいということだった。

ここでの重大な問題はA君にSEとしての能力が十分でないということではない。もとより彼は通訳としてアサインされており、私も彼にそれ以上の能力を求めてはいない。それは事前に明確に説明した。

では何が問題なのか?それは体制の役割について私と彼らの理解の相違である。

彼ら:体制で与えられた役割以上の役割を果たすのはすごいこと
私  :体制で与えられた役割以上の役割を自分の上位の人間の許可無く行うことは悪である。

私の考えはこうだ。
役割にはその役割に見合った責任が同時に付加されている。つまり、体制上の上位の人間の許可無く、自分の役割以上のことをするということは、同時に自分の責任範囲を超えたことをするのと同じである。これは本から得た知識というレベルの話ではない。実際に自分がPMをやってきて地獄を見てきた結果、確信として得たものである。

ではなぜそれが問題なのか?

理由は簡単だ。問題が起きたときの責任の所在が不明確になるからだ。中には「能力があるのに何が問題なんだ」と言う人もいるだろう。だが個人的にはそれは間違いだと考える。能力があるのなら体制上その能力を生かす役割と責任を与えればいい。上の実例では通訳としてアサインされた人間が仕様をコミットしてしまったのである。当然、彼に仕様をコミットする権限は無い。そして問題が起こった。

同じような例でよくある問題はクライアント側の体制である。システム担当者が仕様をコミットするのに権限を持っていない。そのため、体制の外にいる実業務の担当者が体制上システムをコミットする人間にクレームをつけ先に進めないことがある。例えば営業支援システムを開発する際の情報システム部と現場の営業の関係がこれに当たる。この場合、営業の責任者を体制に組み込み、システム仕様に対して責任を持たせるか情報システム部に現場営業を押さえ込む権限を持たせない限りうまくはいかない。

中国のシステム開発業者全てがというわけではなく、あくまで今まで私が仕事をした中国のシステム開発業者に限ってだが、プロジェクト管理と体制についての考え方がほとんど無い、または知識として知っていても実行できないことがほとんどである。これらが理解されなくても開発がうまくいくケースは当然あるだろう。だが、リスクを回避する為に管理と体制は必須である。これは中国に限らず日本の開発でも当然同じだ。

今契約している中国企業の社長、副社長はこれらを社内の教育として取り組むことを確約してくれた。そしてこのプロジェクトも何とか収まった。

同業者の方、意見交換を求む。

以下はバカ話。

この前、オフィスが入ってるビルの喫煙所での1コマ。

中国人の同僚:「鬼塚好き?俺好きなんだよね。」
satchmo_sh  :「好きだけどアルバムとかは持ってない」
中国人の同僚:「あぁ主題かもいいよね」
satchmo_sh  :「どれ?」
中国人の同僚:「どれって主題歌だって」

かみあわね〜

中国人の同僚:「GTOだって。」
satchmo_sh  :「GTO?(G)五時に(T)多摩で(O)OK?」
                        ↑
日本語言ったので放置プレイ状態

GTO←当然待ち合わせの確認ではなく、ドラマのGTO
鬼塚←鬼塚英吉(主役の名前、ちなみに主役は反町隆)

いきなり「鬼塚好き?」ってきくお前のセンスに完敗。

そして

そりまちっ。あんたいけてるらしいよ。

「えいきち」繋がりで。
(つながってねーよ)

昔、吉田栄作ってのがいた。
彼は言ってのけた。

「俺はビックになる。でっかい家かって、いい車乗って....」

夢が実現したかは知らないが、

そりまちっ。あんたおんなじ臭いがするよ。ポイズン!

熱いやつ大好き。冬は特に。

明日は、あん?もう5時過ぎてるし。ねみーし。

反日デモが騒がれる中、ぷーさんに拉致られてピクニックにGO!

なげーな......



satchmo_sh at 03:54|PermalinkComments(0)TrackBack(0)
Counter

合計:

今日:

昨日:

Recent Comments
Access Ranking

アクセスランキング
Page Ranking

アクセス解析
Search Word Ranking

レンタルCGI