何故日本企業のソフトウエア・オフショアは失敗するのか　- for under-ground 4：Blind sight -

要件を"まとめ"、"break-down"するのは、あくまでも受注側のengineerでなければならない。 色々な視点で客先要件や、社内の現状、移行を事前に調査し、 検討違いの主観を入れない為に、結果を要件実装のための基礎資料としてそのまま投下する、 これができることが社内SEの能力で、発注側のSE能力だと思うが、違うか？ だが、日本人は発注側の主観で要件をまとめてしまう。 最悪なのは、要件を"日本語"の数語にまとめ、 そのまとめた語を英語に直訳して、悦にいっている勘違い野郎が多い。 おいらがleaderやっていたら、漏れなく昼間っから マ○かくなら、自宅でやんな！ボケ と罵られるpatternだが、普通に何処にでもいる。 もうなーもいう気力がなくなるが、これが国内の現実だ。 しかも、駆け引きの為に、 要件を"まとめ"る 場合まである。 要件を入れる側が、projectの足引っ張ってどうするよ！？ 確かに、駆け引きせざるを得ない、受注側もある。 どことは言わないが、中国とか、中国とか、中国とか（T_T）　　 あの国にはjunior　programmerしかいないんだが、（←そのうち、お題にします） それにしても、国産makerの内部SEが酷いのは事実だ。 要件で掛け違えているのに、他でなんとかなるわけではないが、 日本人の"まとめ"る災は、projectの管理も狂わせる。 こんな事があった。 日本への進捗報告は、power-point　1～2　pageにまとめて報告してください。 と、某社が海外に依頼しようとしているのを、私がダメ出しした時のことだ。 私の主張は、 1.power-pointは、進捗報告などのように、dynamicにtaskを実現する為の詳細taskや進捗を記述していくsheetに使うには不適当。 2.進捗報告は、前回との相違がはっきりわかるようにしなければ意味がないから、１～２pageは無理。 3.まとめるための工数が無駄。（実体を移さない進捗報告は、意味の無いdocumentだから） これに対し、発注側担当者は A.進捗報告に付け加わる項目は、Commentだけだろう。taskが増えるわけない。あとは進捗だけ報告してもらえば問題ない筈。 B.詳細の進捗報告をしてもらっても、見ないし、見てしまえば、こちらの工数と責任が発生する。 私の目が点々になったのが、ご理解いただけるだろうか？ projectを管理した経験がないのがまるわかりである。 特にA. 成功するproject管理 それは、信用という妄信ではなく、 徹底した透明化によるtask管理によってのみ成立する。 成功したproject経験者だけが知っている鉄則である。 もっとも透明化は、task管理だけでなく、全てにあてはまるから、ここでは別立てにする。（また、そのうち） 進捗報告書というものは、単純にprojectの進捗を報告するものではない。 一つのtaskに対し、どれだけの詳細taskが必要であり、実際にどのくらいの調査をどのくらいの工数で完了させたのか、 予測工数の精度や、critical-pass、project運営の問題点など、 人間を駒としたSimulation　Gameに勝つための資料であり、資産だ。 （↑こういう表現をするから魔女って言われるんだろうなぁ） 中でも一番如実に物語るのは、projectを運営するPLの能力。 当然、実際に使用しているsheetそのものであれば、という前提付だが、 その資産を態々解らないように工数をかけて変質させるorderを出しているのだ。 到底私には理解できない。 態々blindをかけ、情報を劣化させようとしているのだから呆れる。 offshoreだから、何も見ないでお任せでいい。 本当にそう考えているらしい。 どれだけの日本企業が、同じように考えて痛い思いをしているか、まったく解っていない。 あいた口があいたまんまである。 これが、完全なBlack-boxとして機能するだけのskillがある場所ならいい。 その場合は私もそこまでは言わない。 　（いや、言うな。私が、こんな楽しいGameを見逃すわけが無い。） それはまぁ、おいといて、 例えば、これが、新規に開拓した受注相手だったらどうだろう。 私に言わせれば、このような進捗報告をorderして、もしprojectがぽっしゃったら、それはorderした日本の責任だ。 「信用」などというものは、それに足るだけの裏打ちや実績を証明してくれた場合に発生する依存関係であって 盲目的に「信じる」のは妄信/妄想というのだ。 application開発に宗教者は要らない。 それとも、日本の企業は、 信じて、詳細を見てさえいなければ、仕方がないと、責任がないと、上に対し言い訳が立つのか？ もっとも、中国のように始めの１回はskillの高い人員を使い、２回目以降はどうしようもないので構成する、 ところには、１回目だけじゃなく毎回監視しないとだめなんだけどね。総junior　programmerだし。 閑話休題 ここが日本人の面白いところなのだが、 日本人は、進捗のpercentが上がっていれば安心する。 そのpercentageをあげるのに費やした工数の妥当性が報告されていなくても安心してしまう。 おめでたいことである。 だから １～２pageに"まとめ"て といっているのだろう。 だから火を噴くのだが、ここらへんの学習能力の無さは日本人共通。 みんな同じアナに落ちて、 "海外オフショアは、うーん・・・" なんていっている。 何も全ての進捗報告内容をcheckしろ、といっているのではない。 発注側がPLと同じlevel、同じviewで進捗報告を評価する必要など、無い。 発注が注意しなければならないのは、project　leaderがleaderとての仕事をコナしているか、 projectを円滑に行えるだけのengineerをassignしているか、 だけでいい。 だが、その事実を確認するには、どうしても実際の運営実績をみる必要がある。 一つのtaskを実現するには、複数の詳細taskに分解してmanagementすることが望ましい。 私など、詳細taskに展開して報告できないleaderは、その時点でleader能力が無いとみなす。 何故か？ taskを分解し、詳細なtask毎のschedulingをする ということは、taskを理解していないと出来ない。 そして、taskを理解するために、何が必要なのか、どのくらい工数が必要なのか、 理解し、報告できるlevelのengineerがいなければ実行不可能だから。 解りやすいのは、 DataのI/O、check　logic、error　handlingなどの共通化module。 影響範囲などを鑑みて、projectを運営しなければならない項目だ。 この洗い出しや工数、実績が報告できないleaderを、信用できるか？ 詳細に分割するからこそ、クリティカル・パスを改善するための手が打てる、合理化できる。 問題点の検出も早いし、それによる作業の影響範囲の把握もスムーズに行える。 この能力がcheckができる報告書を、"まとめ"る？。 お話しにならない。 そう思うのは私だけか？