続：設計はUMLだけで済む

オフショア開発

http://d.hatena.ne.jp/manhole/20041011#1097457833 の返信です。元ネタはhttp://d.hatena.ne.jp/hoso-kawa/20040930#1096528917にひもづくPJ-U(中国オフショアUMLだらけの開発)の話です。

オフショア開発指定で来る仕事(コスト削減に着眼した発注)が多いので、初めからオフショア開発前提です。規模が小さいプロジェクトはオーバーヘッドがかかって、かえってコスト高になるので国内でやりましょうと提案しますが、大抵でっかいです。でっかいので、いくらオフショア開発とはいえ(むしろ！)、うまくプロジェクトを遂行しないとデスマの危険がありますが、大成功を収めればそれだけコストを抑えた開発が可能となります。

id:manholeがおっしゃっているように「詳細な仕様書を自分たちで書いて、プログラム製造は他へ出す 」がオフショア開発の場合、「詳細な仕様書を書かず、その時間を使って自分たちでプログラムを組む 」が国内で開発を行う場合のプロジェクトの進め方です。もちろん国内でやる場合でも規模がある場合は詳細な仕様書を書きます。ただし、オフショア開発の場合でもいつまでも国内で詳細な仕様書を書いて、国外へ発注するわけじゃありません。私の野望としては、国外へ発注するプロジェクトのフェーズを徐々に上流へと持っていこうと考えています。

例えば詳細な仕様書を国内で書いて、国外へ持っていった場合、次に発注する時は概要が書いた仕様書を国外へ持っていき、詳細な設計書を起こす所から発注します。もちろん同じ所へ発注しなければこれは使えません。最初に詳細な設計書を持っていってるんだから、落とし所は分かったよね。んじゃ次は概要を渡すから詳細な仕様書を書いてみてよ。っとこれがどんどん上流へさかのぼっていきます。上流と言っても限界はあると思います。例えば要件定義まで海外に持っていけるかというと、無理でしょう。お客さんに国外へ行ってもらうか、国外から人を呼ぶか。交通費かかってしょうがないですから！(笑)海外へ持っていける工程には限界がありますが、ノウハウの委譲を繰り返す事により、仕様書書きもオフショア開発で行う事が可能でしょう。

それから、ここで書かれてるレベルの詳細な仕様書ってどうやって書いたのでしょう!?

お答えします。id:manholeさんの言うとおり「正しく分割・詳細化していけば」です。分析〜設計というフェーズがあって、システムが非常に細かい粒度まで落とし込まれています。実際に設計している人の中には、中国人もいてとても優秀です。UMLをさくさく書いて設計しているのは見ていて爽快でもありますよ(笑)順序良く細分化していったのは、手順どおりという感じですが、そのアウトプットが非常に正確なのは設計者が優秀と言わざるを得ない感じです。

そんな仕様書書く時間があるなら、プログラム書いて、リバースした方が効率が良い気がしちゃうくらいです。

については、結果が成功だから今回の場合は適切で正しかったと言えるでしょう。工程がどうあれ結果が全てですから。今回この疑問に答えるならば、仕様書を書く時間はとてもかかったが、オフショア開発でコミュニケーション(Q&A)のオーバーヘッドの削減、不明確な仕様の削減、品質の向上、プログラム開発期間の短縮ができた事により、結果適切であったと言えるかもしれません。

どっかにも書きましたが中国側の主張はこうです。「日本の仕事は技術的に難しい事はありません。仕様書が難しいです」と。海外だからと言って、技術者のレベルが日本より低いという偏見はありませんか？日本だってピンキリだと思いますが、海外だって同じです。優秀な人は、私なんかよりずーっとずっと優秀です。

今回、オフショア開発のコミュニケーションについてはいろいろ考えさせられましたし、仕様書やら開発やら課題も見えてきました。今後も続けてオフショア開発に取り組む事でもっと効率の良い開発ができるようになると思います。がんばるぞー！

今日という日は長かった

Life

動き出したのは午後。時間はいつもと同じように流れていたのに振り返ってみればたくさんの事があって、たくさんの変化があった。短い時間にいろんな事が凝縮されていて、充実した時間を過ごしたのだと実感。おいしい、嬉しい、楽しい。いい事だらけ。穏やかな時間はきっとずっと。

幸せとは

ポエム 独り言

幸せの定義は自分達で決める。その幸せの中には”後悔しない不幸”も含まれる。幸せな事ばかり考えていて、苦労・困難・不幸を考えていないのは本当の幸せでは無いのかもしれない。絶対に幸せにする。良く聞く言葉。私はそれに不幸になっても後悔しないと加えたい。

続：設計はUMLだけで済む

オフショア開発

http://d.hatena.ne.jp/atsushifx/20041011#1097511501 より

成功の秘訣はコミュニケーションや詳細化におけるロスやミスをなくすことにあるわけで、

  • 間違いようのない仕様書が書ける
  • 途中で仕様変更がない

なら、オフショアで全く問題がないわけです。

おっしゃる通りなのですが、私があまりに美しく書いているので失敗談も交えておきます(笑)

まず仕様書にも間違いがあります。仕様書間の不整合が一番多いです。仕様書に書いてあるDTOの項目がUMLに無い、仕様書のI/O定義に書いてある項目名が、DBのテーブル定義書と異なる等。不整合と呼ばれるものですね。仕様の抜けはあまり無いように思えます。仕様変更もきっちりと分析・設計されているせいか大きなものはありません。しかも、開発コストがかさむ仕様変更は理由を説明すれば落とし所をゆるくしてくれたり、無かった事にしてもらえます。大きなシステムですからね…。

それで仕様書に間違いがあるのになぜうまく進んでいるか？それは円滑で迅速なコミュニケーションが成功の秘訣です。コミュニケーションについてはたぶん↓あたりに書いてあります。

完璧な仕様書はほぼ無いと言っていいでしょう。ではその間違いによる作業効率の低下をいかに低減させるか。遠隔地の開発者達とそれを行うには円滑で迅速なコミュニケーションを心がけるしか無いでしょう。できるだけ正確な仕様書、開発に適した要員、コミュニケーションを促進させるための仕組み、後はプロジェクトを遂行するために一般的に必要なものがあれば、オフショア開発は失敗しないでしょう。さらりと項目を挙げてますが、ひとつひとつにはたくさんの条件が入っています。例えばプロジェクトに適した要員とは何か。これを定義するだけでも大変なので、ここはあえて曖昧にしておきます。誰かにノックされたらひとつずつ洗い出していこうかな…と少しだけ…すこーしだけ思います(笑)

一つだけ言えるのは、コミュニケーションには相互に通じる「言葉と文字」と「信頼関係」が必要って事です。飲み屋で意気投合したインターナショナルな酔っ払いじゃないんだからボディーランゲージじゃ無理です！！(爆)

Re:系列の話

独り言

系列という狭い世界に組み込まれることにより、全市場的な競争から外れることになるのです。ノウハウ・技術力の蓄積も、その系列向けつまり特定のもので一般向けでなく、本当の意味での技術力UPではないことがありますし、良くあるパターンとしてコスト競争力の低下がでてきます。

その系列の中に組み込まれていて、井の中の蛙が嫌で外へ飛び出した私。中国の仕組みはピラミッドには組み込まれていませんね。中国の仕組みを使うノウハウは一箇所に集まりそうですが、中国そのものは常に新鮮な情報(技術)が流れていってます。今度はノウハウの分散を考えるべきか…？マニュアル化する事により、中国の仕組みをオープンにできるので…って今は考えるべきじゃないかな。まだそこまで取り組みきれてませんし。

Laszlo？

Flash

http://japan.cnet.com/news/ent/story/0,2000047623,20055143,00.htm
をたまたま見て、おもしろそーと思って調べてみた。
http://www.laszlosystems.com/
が販売してたんだけど、オープンソース化されて
http://www.openlaszlo.org/
で公開されていると。

イメージ的にはまんまFlex。XMLで記述して表示はFlash Playerで行われる。Flexより簡単に記述できて、エディタがあるならオープンソースの方がコスト的にうれしい…。Flex Explorerみたいなサンプルまであってすごいおもしろい(笑)っていうかFlexより”動く”画面を作りやすくないですか！？データバインディングもXPathみたいに記述できて、分かりやすいっちゃ分かりやすい。残念ながらWYSIWYGエディタは無いみたいですが…。全然調べてませんけど、ほんの数分でガッチリ心をつかまれました(笑)

Flex Explorerみたいなサンプルはコレ↓ここまでできてしまって、かつオープンソースなのは血が騒ぎます！！
http://www.laszlosystems.com/lps/laszlo-in-ten-minutes/