中国でうまくいかなくても、日本だとうまくいく理由は、丸投げの対応ができるからだと思う

　中国オフシェアの話で、
マネジメントしなくても半分のプロジェクトは成功するっていうことを書いているブログがありました。

　私も、中国の人たちと開発していたとき（とはいえ、彼らは、中国では、大学教授とかなので、まあ、できる人たちなのですが、その人たちと一緒にやっても）、そんな気がしました。

　理由なのですが、日本の場合、仕様書に書いてなくても、プログラムを作る側で判断するのがあたりまえなのです。
　だけど、中国の場合、書いてないことは、やらないのが、あたりまえなのです。

　だから、極端な話、私が最近やってるような、マネージャーさんは、なにやってるんだか、よーわからんけど、ほぼ私に丸投げで、私は、勝手に、すきなよーにやっているっていうような仕事は、日本では、うまくいくんだけど、中国だと、「なにしたらいいんですかあ？」と聞かれて、ぜんぜん仕事してくれなかったり、てきとーに作られて、しまったりします。

　たとえば、オブジェクト指向で書いた、クラス図があったとします。
　で、それを作る場合、メソッドの引数の意味（値の範囲とか）がわからなかったら、周りの関係者たちに、プログラマ側が聞きますよね。

　でも、中国だと、マネージャーに「ここわかんない、どーにかしろ！」といってくるのです。このとき、マネージャーは、仕事を丸投げしていたら！？
　マネージャーもだれにきいたらいいか、わかんないですよね。
　日本の場合、たぶん、丸投げだろうとあきらめて、自分たちで、ドキュメントをしらべて、聞く人をわりだし、「勝手にきいていいですか」とマネージャーにおうかがいをたてる。なんで、まるなげのしごとでも、できるというからくりです。

---

　同じ件について、atsushifxの七転八倒さんののブログで、とりあげていましたが、そこで

作業者が主体的に行動してリスクの芽を摘み取っている - 徹夜続きでもなんでもやりとげるのどちらなのかわかりませんが、

とかいてありました。これで言うと、前者のほうだと思います。

日本の仕様は、きのうの極上生徒会の内容のように、
「う」とシンディ真鍋がいうと、
「それは、どーとかこーとかで」とぷっちゃんが説明するようなもんです。
（きのうの極上を見てない人には、さっぱりわかんない説明で、すみません）

　そーやって、理解することが、いいことか、全部仕様書に盛り込んだほうがいいのかって言うのは。。。微妙な問題の気がする。

以上、あくまでも、私の経験です。ほかのひとは、違った印象／経験を持ってるかも！？

オブジェクト指向だと、ユーザー自身が業務をわかってない新規事業だと、大変だねという話

　そうそう、２日間の説明は、以前書いたブログの

なぜ、業務の標準化や、新規ビジネスを創出できないように、業界が進んでいるといえるのか？」と、思われるであろう。

と

９０年代前半で、システムをビジネスパターンに分けることによって、枯れたプログラムをつなぎ合わせる手法が、ＳＥという存在が業界から省略されることによって、なくなってきた

の説明のためなんですけど、その説明、しておきますね！

---

　オブジェクト指向による分析は、昨日、その前にも書いたように、スタートラインが、ユーザーの業務説明から始まるのが普通。

　この場合、ユーザーが、自分で業務がわからない（新規業務などは、やったことがないから、自分自身もわからないことがある）と、開発側では、なにをつくっていいかわからないということで、開発できない。仕様待ちになってしまう。
　こういうケースだと、よくユーザーさんのほうから、「あとで仕様をまとめます」とか言われる場合があるけど、真に受けてはいけない。たいてい、仕様はでてこない。

　っていうことで、新規事業、新規業務で、業務がまったくわかんないのには、オブジェクト指向は使いにくい。

　それと、もうひとつ。
　オブジェクト指向の場合、業務の標準化というと、標準化したモデルないしは、クラスの再利用ということになる。この場合、業務手順である、クラスの中のメソッドもふくむ。
　ところが、実際に業務手順までをモデル化しようとすると、なかなか決まらない。
　フォームや、コード体系なら、結構簡単に決まるけど、手順も一緒に決めてしまうという場合、なかなか、きまんない。

　なので、オブジェクト指向だけしか教えないと、標準化するのは大変だし、新規事業（業務）からシステムを組むのも困難。
　でも、最近の学校って（稚北大も、佐賀大も）オブジェクト指向中心のカリキュラムなのね！ということ。で、この業界自体が、オブジェクト指向中心の方向に進んでいるように見える。

　これが、はじめの文の説明。

---

　で、あとの文の話題。

　じゃあ、昔、新規業務のときは、どーしてたのか？というと、業務における通論というのが、存在していた。
　モデルまでの形にはなっていないけど、フォームなどはきまっていたわけっす。

　たとえば、
　　　小売で伝票なら、統一伝票だし、
　　　受発注のオンラインプロトコルといえば、ＥＤＩでＥＤＩＦＡＣＴとか。
　で、それらを使うとなると、だいたい業務パターンは決まってしまい、さらに、それらはプログラム可能なレベルにまで落としてあったわけ。

　なんで、その通論をもとに、考えればよかった。新規業務との差分をとれば、いいのね。

　このへんの通論の基準が、流通システム開発センターが、毎年、その成果を出している本にのっていて、その本を持っていると、どのへんが通論になっているかが、おさえられたわけ。

　９０年代は、こんなかたちで、通論っていうのがあって、その通論はビジネスパターンとよべる、こまかな部分の組み合わせにできて（っていうか、ライブラリがあったのよ）で、新規ビジネスでも、それの適用や、差異をとればよかった。

　でも、最近のシステム開発では、まず、そういう通論をクラス化したようなのも、見ないし、学校でも、おしえていないようだ。
（「情報処理」の佐賀大の記事にも、教える内容に、標準業務：集金業務なんていうのは、なさそうに見えた）。

　昔のＳＥさんは、そういうのを習ってきたんだけど（ウィリアムのいたずらも、さんざん勉強させられましたよ！ウィリアムのいたずらの専門はＤＴＰなのに。ちなみにＤＴＰでも、そういう通論的なシステムっていうのがあるのよね）、

　オブジェクト指向が中心になって、昔のＳＥさんみたいな、通論なんていうのを学ぶ人も機会もなくなってきましたね（通論がデザインパターンに変わってしまった。でもデザインパターンは、カネを生み出すシステムを教えてくれるわけではない）。

---

　だからたとえば、下記のシステムを開発する場合、昔のＳＥなら、一発で答えられるのに、今のシステム開発の人だと（オブジェクト指向で分析すると）、ユーザーが答えてくれるまでまってしまう。ユーザーは、知っている可能性は低いので、そーすると、システム開発が宙にういちゃうのよね。

（記）

　会員制のフィットネスクラブで、クレジットカードで、自動的に落とすことを考える。会員は、何年間も継続して契約している。

　なにが、むずかしいか、わからない？

　何年間も継続して契約しているって言うことは、クレジットカードだと、有効期間が切れてしまうって言うことなんですよ。
　なんで、有効期間を、切れるごとに、お客さんにきかないといけない。でも、いっぱいお客さんがいたら、それ聞くのも大変。どうしよう！！

　業務分析して、ヒアリングからだと、たぶん、このフィットネスクラブの人がクレジットカードをやっていなかったら、そう思うよね。

　これは、集金の通論を知ってる人なら、答えはわかると思うけど、「洗い替え」を行う集金代行業者にたのめばＯＫ。そうすると、有効期間が切れても、勝手に処理してくれる！！ゼウスなどが、対応してるよ！

SkypeなどのVoIPビジネス中国で違法って、オフショア開発＆中国のソフト産業に影響大では？

　スラッシュドットの記事によると、

中国政府の中国情報産業省(MII)は、SkypeなどのVoIPビジネスが潜在的に不法であるとの見解を示した。

そうです。（ここが原文）

　つーことは、Skypeとか、できなくなるんだろうか？
　中国では？

　もしそうだとすると、日本国内では、skypeとか使って、連絡とかが、ただになっても、中国で開発する場合、通信費が（それも莫大に）かかることになるし。。
（スラッシュドットの記事をみると、インドも規制があるみたいだし）

　さらに、インターネットも、みかままさんのブログをみると、中国は、アクセス制御がかかっているところとかあるみたいだし。。。

　つーことで、将来的に、通信費とかまで含めたら、中国で開発するより、日本のフリーの人や、（専門学校や、大学生の）学生アルバイトに頼んだほうが、安くつくんじゃないかなあ？

　中国も、ＩＴを自由にしないと、国際的に取り残されそうな気がするぞ！
　まあ、ほかの国のことだから、どーでもいいんだけどね！！