レビュー時に指摘されなかったので今さら修正できません
コーディング規約を守らない中国人プログラマ
コーディング規約にはっきりと「例外を無視してはいけない。」「想定外の例外を捕捉(catch)してはいけない」と書いてあるのですが、全く守られていません。完全無視です。
（オフショア大學／日本人）
2008年3月創刊予定のオフショア開発専門誌編集会議より。
今回ソースコードを見てもっとも愕然としたのは例外処理。
数百箇所も禁止コードがそのまま書いてあるのです。
try {
処理;
} catch( Exception ) {
// 何もしない
}
（ある中国オフショア開発より）
日本人マネージャが数百箇所におよぶ禁止コードの修正を中国人プログラマに指示したところ、以下の理由からあっさり拒否された。
・今からやると納期に間に合わない
・修正すると不具合が発生する
・レビュー時に指摘されなかった
・□□□□□□□□
→そんなの関係ねー。今すぐ直せ（怒）
■成功の勘所
受け入れ担当者の技術力がないと、コーディング規約準拠を断念せざるを得ない。なぜなら、多少の規約違反があっても、見かけの上では、プログラムは正常動作するから。あなたなら、どうする？「規約だから」の一点張りか。それとも・・・
☆オフショア開発でコーディング規約が守られません。もっともらしい言い訳をして修正依頼にも応じません。なぜ、中国では明確な規約すら守らないのでしょうか。
◆規約を理解していないから
◆違反しても罰則がないから
◆規約の重要性を知らないから
◆当社ではちゃんと規約を守ります
◆その他
締切：2008年01月29日23時00分
協力：クリックアンケート
« 多忙注意報 | Main | リニューアル計画 »
The comments to this entry are closed.
Comments
中国内陸部に子会社を作り、オフショア開発を続けてきました。当初、規約を理解しようとも、説明しても、納期や場当たり的な対応を言い訳に、守ってくれないことを、現場のSEたちが嘆いていました。
今では、規約を守らないことは恥ずかしいこと、という指導を行い、子会社ということもあり、したがってくれるようになっています。
なぜ、規約を無視するのかについては、規約を守ることによってプログラムの品質が均一化することや、保守がやりやすいことなどの、目的を理解していないからだと考えました。なので、なぜ守ってもらわないと困るのかをあの手この手で何度も説明しました。
リーダークラスにやっと浸透してきたので、これから増加していくメンバーにはリーダーたちから教育してもらえると考えています。
それまでは、ソフトを開発しても作りっぱなしで保守フェーズを経験したことがないことも、品質や保守に対する意識の違いを生むのではないかと思います。
理解してくれれば、意識が変わっていくと思っています。
Posted by: 江藤 | January 22, 2008 09:59 AM
日本と同じような阿吽の呼吸は一切通じません。面倒でも一つずつ、実務の意味を伝える必要があります。これさえ押さえておけば、頭の良い中国人はしっかりとやりますよ。とにかく、日本人は仲間内で通じる言葉でしか話そうとしません、特にアジア人には。この悪習をまず、直すことから始めてはどうでしょうか？これからの時代、日本人は苦労するでしょうね。
Posted by: 老板 | January 22, 2008 10:02 AM
規約の重要性ではなく、規約の「目的」を理解していない、
もしくは理解させていないからだと思います。
日本側も、よく保守性や品質の向上だだの何だの理由をつけますが、例えば、
「get_userData()は規約違反、GetUserData()としなさい」という修正を
メンバー10人・１時間かけて行うと、何が改善されるのでしょうか？
個人的に、規約が自己満足になりすぎな部分もあるかな？と思っています。
今回の場合、例外の仕様が定義されているなら中国側がマズイですが、
「例外は無視するなと書いておいて、聞かれたら答えよう」なんてスタンスであったのであれば、
これは日本側の怠慢だと思います。
中国側の言い分として・・・
例外は無視するなだって？じゃあtry~catchだな。
でも、数百あるのに、仕様はどこに書いてある？
やっぱ書いてない。どーせQAで質問しても返事よこさないし、
進捗でも「QA近いうちに返答する」とかしか言わないし。
毎週後で回答すると言われるだけ。もう付き合ってられない。
だから、このままでいいや。
・・とかあるのではないでしょうか？（笑
私のプロジェクトでは、
メンバ変数に、それを新規に定義した人の名前（イニシャル）をつけるという
勝手な規約に遭遇しました（笑
（初めはなんかの管理ツールが勝手に付加してるのかな？と思ってました。）
驚いたのが、全員、１つ漏らすこと無く守ってるのです。
もちろん、指摘しましたが、理由を聞いてOKとしました。
日本主語ではもちろんNGですが、
プロジェクトの事情を理解した上での判断と分かり、納得したからです。
きっと、みんな守ってた理由は、
それを行う事の目的とメリットを理解していたからなのだと思います。
Posted by: しみけん | January 22, 2008 10:03 AM
語弊がありそうなので補足です。
私は、保守や品質向上には「Coding Rule」ではなく
「Design Rule」の方が有効だと思っています。
多分、次のプロジェクトにもDesign Ruleを定義すると思います。
Posted by: しみけん | January 22, 2008 10:05 AM
江藤さん、こんにちは幸地司です。
なぜ規約を守らないと困るのかをあの手この手で何度も説明した手法について、興味あります。口頭説明で工夫されたのでしょうか。それとも、口頭説明以外でもあの手この手を使われたのでしょうか。
どんな手段が最も理解の助けになったのか、差し支えない範囲で教えてください。
Posted by: 幸地司 | January 22, 2008 10:06 AM
老板さん、こんにちは幸地司です。
日本人の仲間内でしか通じない悪習とは、特にオフショア開発における悪習とは、いったいどんなものがありますか。なぜ、この質問を投げかけるかというと、本人には「悪習」を行う自覚がないため、自助努力による改善が難しいからです。無くて七癖とも言いますし。
社内用語、業界用語、日本人にしか通じない用語・・・。
昔、初めて”ITa”, ”ITb”という用語を聞いたとき、ぽかんとしました。昨年、某所で新人研修したときに、「サブコン」が通じなくて話が止まってしまいました。sub contractorのつもりでした。
Posted by: 幸地司 | January 22, 2008 10:07 AM
しみけんさん、こんにちは幸地司です。
> どーせQAで質問しても返事よこさないし、
> 進捗でも「QA近いうちに返答する」とかしか言わないし。
よく聞く話です。それにしても、オフショア開発では、そこまでQ&A遅延が蔓延しているのでしょうか。しみけんさんプロジェクトでは、個人裁量でどしどし動いていますね、きっと。他の方の会社では、いかがでしょうか。
Posted by: 幸地司 | January 22, 2008 10:09 AM
しみけんさん、こんにちは幸地司です。
>「get_userData()は規約違反、GetUserData()としなさい」という修正を
>メンバー10人・１時間かけて行うと、何が改善されるのでしょうか？
規約遵守が自己満足なのか、そうでないのか。その判断は難しいですね。ツールでちゃちゃっと修正できるレベルならいいですが。
Posted by: 幸地司 | January 22, 2008 10:10 AM
やはり、その規約を守る意味付けが重要ですよね。
結局、その規約を守ることによって、性能が上がるとか、目に見える効果が無い限りは、難しいです。
コーディング規約をチェックするツールを導入し、そのツールのoutputで問題が無いという確証をつけなければ納品物とみなさない。という契約をしたら、かなり守られましたけど。
●規約の重要性を知らないから
Posted by: ひろせ | January 22, 2008 10:11 AM
コミュニケーションの力を発揮するべき所でスムーズに解決しなかったようなトラブルに見えますね。
すべての規約を守ることはどこでも不可能でしょう。大事なのは規約を守れなかったりしたときにどう対応するべきかだと思います。
人間ですから、わがままを言いたい気持ちは誰でもあるでしょうが、どう表現して解決するかは窓口役の判断範囲に成るでしょう。
ここで中国は何故規約を守らないかの質問になるのは問題解決ではなく逆効果になってしまうと思います。
Posted by: Park yongjin | January 22, 2008 10:44 AM
原因を求めようとしたら答えは規約の重要性を知らないからが主な原因だと思います。
ですが、規約を一個ずつ説明して行くのはその分の時間を必要としますし、それなりの時間に比べていい結果が出るかが疑問です。
何でも細かく説明して行く日本人と付き合っていますが、そこまで説明する必要があるかと思ったりします。時間の無駄が多すぎるのでは？
理解できない内容は先に連絡してもらって、すぐに返答してあげるのが一番だと思います。問題なしだったら、後は実行のみ。実行で何かのトラブルが発生したら窓口さんの活動によってお互いの暴走を防ぎながら進めるだと思います。
Posted by: Park yongjin | January 22, 2008 11:31 AM
Park yongjinさん、こんにちは幸地司です。
> すべての規約を守ることはどこでも不可能でしょう。
賛否両論を呼びそうな面白いご意見です。いつも本音のコメントを書き込んでくださり、ありがとうございます。
私はコーディング規約を全て守るのは『当然』だと思っていましたので、失礼ながらPark yongjinさんの発言を読んで、思わず笑ってしまいました。
いま、改めの自分の行動を振り返ると、確かに「100%遵守は非効率では？」と思われるような規約は存在しました。100%遵守の判断が難しい規約もあります。たとえば「コメントは、ソース全体の30%程度書く」など。
Park yongjinさんや他の皆さんへの質問です。
100%守るべき規約と、守るのが難しいコーディング規約の具体例を教えていただけますか。
＜100%守るべき規約＞
・
・
＜100%守るのが難しい規約＞
・
・
Posted by: 幸地 司 | January 22, 2008 01:28 PM
こんにちは。
確かに規約として決めた内容は100％守るべきでして、守れないものは規約としてふさわしくないと思っております。ですが、実践していきながらでないと守れるか否かが見えない場合があるかと思います。守ることによって貰える得と損の比例はどれ位かによって守ってくれなかったり、変な形に変換して守ったりすることも考えられます。
どんなに変な規約でも守ってくれなかった方が悪いに決まっております。難しいとかの言い訳で通用するぐらいなら規約の意味がなくなるでしょうから。
私が言いたかったのは「全ての規約を守るのは無理」より「守れなかった場合の対応」でした。「どこでも不可能」は「中国では明確な規約すら守らない」を気にしての発言でした。一応私も中国人ですので、反発がありました。アハハ～
case by caseで＜100%守るのが難しい規約＞等が存在するでしょうから例にするのも難しいですね。すみませんが、当社の場合、コーディング規約は自社で決めますので、私の立場ではあまり意識して無いです。
Posted by: Park yongjin | January 22, 2008 03:32 PM
Park yongjinさん、こんにちは幸地司です。
>「中国では明確な規約すら守らない」を気にしての発言でした。
> 一応私も中国人ですので、反発がありました。アハハ～
反発を招くような表現をしてしまい、申し訳ありません。いつも気をつけて文章を書いているつもりですが、よく誤解を招きます。もし事実と異なるようでしたら、遠慮なく「中国では、明確な規約は守られる」とご指摘ください。
コーディング規約の表現は簡潔ですが、その行間には現場で培われた暗黙知がテンコ盛り。仕事を通じて暗黙知を移転してもらえるなんて、ある意味において、オフショア受託企業は幸せな存在です。
日本の産業構造では、受託企業は発注企業から叩かれて、叱られながら成長するといった雰囲気があります。誰もが下積みの修行時代を経て、ようやく一人前になるべきとの観念です。
・トヨタ自動車が□□□を育てた
・和田アキ子の厳しいシゴキが若手○○を育てた
でも、この感覚は、国際化したオフショア開発では通用しないのかもしれません。日本人マネージャがよく口にする「規約遵守を厳しく指導して、中国を育てる」という発想は捨て去るべきでしょうか。
Posted by: 幸地 司 | January 22, 2008 04:14 PM
こんにちは。
「中国では、明確な規約は守られる」と言いたいですが、現実はそうでもないです。守る方もいますし、守らない方もいますからね。簡単に返答できれば宜しいですけど。
「中国は特別」のような考え方を捨てるべきだと思います。「中国を育てる」ような発想は宜しいですが、口にすることは偉そうな感じになりますので「受託企業のメンバーを育てる」にするのが宜しいかと思います。国範囲になったりすることが反発を買うでしょうから。
規約としては暗黙知を適用しない方が良いと思います。暗黙知まで分ってくれと外国人に頼むのはある意味酷いです。
新人が見てもすぐ分るような規約を工夫するべきかと思います。
そういえば、「規約遵守を厳しく指導して」が受身にとっては「お金を払う気が無い」に理解されたりするとまずいですね。(^0_0^)
Posted by: Park yongjin | January 22, 2008 05:59 PM
Park yongjinさん、こんにちは幸地司です。
>「中国は特別」のような考え方を捨てるべきだと思います。
>「受託企業のメンバーを育てる」にするのが宜しいかと思います。
なるほど。逆説的ですが、日本も特別、中国も特別、インドも特別、・・・、あらゆる国や地域が特別と考えてもいいかもしれませんね。参考になるご意見ありがとうございます。
Posted by: 幸地 司 | January 22, 2008 08:19 PM
Park yongjinさん、こんにちは幸地司です。
> 規約としては暗黙知を適用しない方が良いと思います。
> 暗黙知まで分ってくれと外国人に頼むのはある意味酷いです。
最初に紹介した記事は「想定外の例外をキャッチしてはいけない」という規約でした。この規約の背景には、重要な知恵が潜んでいます。
障害分析をやり易くするために、想定外の例外をシステム最上位でのみキャッチすべきであるという知恵です。この知恵を「暗黙知」と呼ぶか、プログラマの「常識」と呼ぶかは、判断が分かれるところかもしれません。
他にも、「メソッドの行数は５０を超えてはいけない」などの禁止令もコーディング規約として頻出します。この規約の背景にも、重要な知恵が潜んでいますが、この知恵を「暗黙知」と呼ぶ日本人は少ないでしょう。普通に、プログラマの「常識」だと一蹴されるはずです。
オフショア開発では、こうした暗黙知と常識の分かれ目が難しいですね。
Posted by: 幸地 司 | January 22, 2008 08:22 PM
幸地さん、こんにちは。
「あの手この手で何度も説明した手法」ですが、泥臭い手法です。
まずは、頭にきて、開発連絡用の掲示板上で日本語で守らないのはルール違反だ、と、怒りを示しました。
が、リーダは謝りますが、次も同じことを繰り返します。怒っても効果はないな、と感じました。
変数の書き方の統一など、大きく影響しないこと(保守では重要なのですが、、)は、もうある程度目を瞑りましたが、文字、数字をハードコーディングしていたものは、後々の仕様変更に耐えられないし、バグを内在させるので、修正しました。
日本で修正した工数を示し、その間、日本側は徹夜に近い作業をした、納期が遅れることによって、ユーザに謝らなければならなかった、と、ちょっと誇張して伝えました。
それは結構素直に驚いたようです。
そこで、なぜ、そうしないといけないのかを、日本語で掲示板に記入し、翻訳者に翻訳させ、ミーティングしてもらいました。
定数に関することは、そこで理解してくれたようです。そのことで、規約をすべて理解し、守ろうとするか、というとまた別の話しになります。
こちらが思ってるほど、すべてがうまくはいきませんが、リーダに対して、規約のポイントを説明したりすることで、守ってくれるようになってきていると思っています。
Posted by: 江藤 | January 22, 2008 09:06 PM
「あの手この手」もうひとつ。
現地の日本人総経理は親会社から行った元SEなので、スケジュール管理、雛質管理にも細かく突っ込んで、指導しようとしてくれています。
納品前に、品質管理者を通す、というルールを作り、規約を守っているかのチェックを行うようにしました。
ただ、管理者の意識しだいで、チェックは無意味なものになりますが、管理者も製造担当者も規約を意識する、という効果はあったかな、と思います。
Posted by: 江藤 | January 22, 2008 09:07 PM
ひろせさん、こんにちは幸地司です。
> コーディング規約をチェックするツールを導入し、そのツールの
> outputで問題が無いという確証をつけなければ納品物とみなさない。
> という契約をしたら、かなり守られましたけど。
ツールによる自動チェックは効果的だったのですね。違反すれば罰則（ペナルティ）を科す発想でしょうか。私は、属人性を排除した判断基準による罰則規定は大賛成です。
しみけんさんが発言された「Design Rule」の遵守ですが、ツールによる自動確認は難しいかもしれません。日本が中国性悪説を前提に管理(control)すると、互いに疲れそう。
Posted by: 幸地司 | January 22, 2008 09:08 PM
江藤さん、こんにちは幸地司です。
> まずは、頭にきて、開発連絡用の掲示板上で日本語で
> 守らないのはルール違反だ、と、怒りを示しました。
このような正直な告白、大歓迎です。
> リーダは謝りますが、次も同じことを繰り返します。
> 怒っても効果はないな、と感じました。
ＰＤＣＡ改善活動の発想だと、同じミスを繰り返さないために、リーダーは謝罪と同時に再発防止策を提示するはずです。前回は、その辺が甘かったということでしょうか。
わざわざ時間を割いてご自身の失敗経験を明かしていただき、本当にありがとうございます。
Posted by: 幸地司 | January 22, 2008 09:09 PM
江藤さん、こんにちは幸地司です。
> 文字、数字をハードコーディング
笑い話のようですが、若い中国人プログラマの間では根絶するのは難しいのでしょうか。それとも、最近の中国オフショア開発では、ほぼ解決済みですか。
私も若いころ(^^)は、マジックナンバーをよくソースの埋め込みました。試行錯誤が多いパターン認識アルゴリズムの研究開発でしたので、ソース書き換えが面倒になって、そのうちマジックナンバーを全て外部で持つように自主改良しました。
自分で苦労しないと、コーディング規約の重要性は腹に落ちませんね。
Posted by: 幸地司 | January 22, 2008 09:10 PM
おはようございます。
「想定外の例外をキャッチしてはいけない」の背景は知らなかったです。いい勉強になりました。ありがとうございます。
前回の訂正ですが、「中国は特別」のような書き方（言い方）を捨てるべきだと思っております。
確かに地域によって考え方等がいろいろ違ったりしますが、特に悪い意味での指摘のような場合は影響範囲をできるだけ絞るのが正しい行動でしょう。
「メソッドの行数は５０を超えてはいけない」のような内容はコーディングで目指すべき内容として常識ですが、規約として絶対だと主張するのは恐らくオフショアぐらいかと思います。
「メソッドの行数が５１行だったのでバグです」だったりするとうっとうしいでしょう？日本人なら平気でしょうかね。
プログラマー役であった時に社内のソースレビューでしたけど、「変数定義のインデントがずれた」でバグだと言われたことがありますが、悔しかったです。アハハ～
Posted by: Park yongjin | January 23, 2008 09:36 AM
Park yongjinさん、こんにちは幸地司です。
> 特に悪い意味での指摘のような場合は影響範囲を
> できるだけ絞るのが正しい行動でしょう。
同感です。フィードバック(feedback)の大原則です。
1. その場で直ぐに指摘する
2. 悪い箇所を具体的に指摘する
3. ”I message”を使って指摘する
>「メソッドの行数が５１行だったのでバグです」だったりすると
> うっとうしいでしょう？日本人なら平気でしょうかね。
私なら嫌です。私の身体には「てーげー主義」の沖縄人の血が流れているので^^;
思いっきり余談(joke)ですが、『メソッド行数は何行あっても可読性に問題なし』を数学的帰納法で証明することができます。
１．もしも、メソッドが1行なら、明らかに可読性よいので問題なし
２．いま、メソッド行数＝Ｎのとき、「可読性の問題なし」と仮定する
３．メソッド行数が(Ｎ＋１)のとき、高々1行追加しただけで可読性は変化しないので、(Ｎ＋１)行のメソッドであっても問題なし
４．結論：ゆえに『メソッド行数は何行あっても可読性に問題なし』
※jokeです
Posted by: 幸地 司 | January 23, 2008 11:45 AM
はっきり善悪が決められないコメントの書き方、括弧の位置、命名ルールなどは 日本人ならルールに従う、中国人なら自分の習慣に従うのようです。
この意味では日本人は犬型、中国人は猫型かもしれない。
個人的には有能なコーダーに好きのようにさせたほうが生産性が高く、 後にツールをかましてたりBPさんにお願いしたりして直せばよいと思う。
Posted by: 張小東 | January 23, 2008 11:57 AM
張小東さん、こんにちは幸地司です。
> コメントの書き方、括弧の位置、命名ルールなどは
> 日本人ならルールに従う、中国人なら自分の習慣に従う
私なら、提示されたコーディング規約が自分の流儀と異なっていても、何の疑問も持たずに素直にルールに従います。ワン！(子犬のつもり）
ペアプログラミングでもいいし、業務システムの保守業務でもいいし、オープンソースの共同開発でもいいですが、長期間にわたり第三者とソースコードを共有する体験を持てば、コーディング規約遵守に対する感覚が研ぎ澄まされるでしょう。（と規約を守らないプログラマを批判したりして・・・）
とはいえ、単体テスト完了に責任を持つソフトハウスのプログラマ(specialist)であれば、製造から試験工程だけの生産性向上を目指すのは決して間違いではありません。specialistにコーディング規約を遵守させるには、張小東さんの言うとおりツールや仕組みを整えることが重要。
specialistのプログラマが高い生産性を維持したまま、顧客の保守性を考慮してコーディングするようになるとprofessionalの仲間入り。これが私の見解です。
Posted by: 幸地 司 | January 23, 2008 12:37 PM
まずは、メソッド行数、変数定義、ナンバーなどのチェックはCheckStyle（Javaの場合）で行うべきものです。皆さんも優秀な人なので、こんなチェックを行う時間がないでしょうね。
次は、技術的なチェックですが、これはルール守りとリーダクラスのソースレビューが有効かと思います。PGたちはすべて理解するのは大変でしょうね。最初からプロジェクトに入るわけではないし、仕事経験も少ないし。。。
Posted by: greenhorse | January 24, 2008 05:19 AM
私のお付き合いしているオフショア先は、コーディング規約を意識しています。
いくらコスト削減で安くなっても、後々無駄なコストが発生すると意味がないので、少し割高でも同じ価値観で仕事ができる会社、ＰＭを選択しています。
Posted by: 佐藤朋也 | January 24, 2008 05:30 PM
greenhorseさん、こんにちは幸地司です。
> PGたちはすべて理解するのは大変でしょうね。
> 最初からプロジェクトに入るわけではないし、
> 仕事経験も少ないし。。。
日本企業の慣例だと「新人は黙って規約通りにコーディングしなさい」と上司や先輩から指示されることが多いと思います。多くの新人ＰＧは素直に従います。
この「コーディング規約に素直に従う」という態度は、中国人の新人ＰＧでも共通ですか？ それとも、学生時代に身につけた自己流のコーディング・スタイルを優先しますか。
途中からプロジェクトに投入されたＰＧは、時間不足なのでコーディング規約に守れないのでしょうか？ それはＰＧ個人の問題ですか、それとも計画が悪かったのですか。あるいは、日本企業がお金を出し渋るのが悪いのでしょうか。
（一度にたくさん質問してしまった・・・。悪いＱ＆Ａの見本だな）
Posted by: 幸地 司 | January 24, 2008 05:31 PM
佐藤朋也さん、こんにちは幸地司です。
> いくらコスト削減で安くなっても、後々無駄なコストが
> 発生すると意味がないので、少し割高でも同じ価値観で
> 仕事ができる会社、ＰＭを選択しています。
コーディング規約を守る効果を具体的な数値（特に金額）で示さないとなかなか議論が先に進みません。その観点から、「割高でも・・・を選択する」と判断する姿勢は、投資対効果(ROI)からも理にかなっています。
差し支えなければ、下記２つを教えてください。
問１ 割高の許容範囲は？（価格１．５倍でも選択するか）
問２ 同じ価値観で仕事できるかどうかを判定する方法（面談？チェックリスト？）
Posted by: 幸地 司 | January 24, 2008 05:32 PM
たしかに、細かな規約多いですよね。
関数名のプリフィクス、コメントの空白の数、
設計書の書式設定に至るまで、いろいろありそうです。
きっと、いろいろな会社から開発を受託して数カ月おきに規約が
全く変わってしまう、その頭の切り替えに受託会社の担当者は
とても苦労されていることとと思います。
しかし、私の考えですが、受託料金の中には、
「機能仕様を満たすこと」や
「納品日を守ること」と同じように、
「顧客の規約を守ること」も含まれている
と思っています。 …含まれると思っていましたが、
オフショア開発ではなかなかそうはいかないのですね。
皆様が書かれていたように、
面倒でも一つずつ実務の意味を伝え、
規約の「目的」を理解させ、
あの手この手で何度も説明し、
価値観やビジョンを共有する、といった地道な作業が
唯一の解決策でしょうか。。
＃本アンケートのテーマは「コーディング規約」でしたが、
もしかしたら他の言葉でもマッチしてしまうのでは？
と、つい思ってしまいました。。
「オフショア開発で○○○○が守られません。
もっともらしい言い訳をして修正依頼にも応じません。」
それでもなお、発注者側がコストや技術者不足といった課題を
解決でき、今後も発注する価値がある会社であると判断すれば
継続発注になるでしょうし、そうでなければリピーターには
ならない。
実際、複数の顧客がリピーターとして継続発注をしているかは
良い委託先を見極めるための大きなポイントだと思います。
オフショア開発会社の初期選定時には参考になると思います。
Posted by: nakajii | January 24, 2008 05:34 PM
nakajiiさん、こんにちは幸地司です。
> 私の考えですが、受託料金の中には、
>「顧客の規約を守ること」も含まれている
> と思っています。 …含まれると思っていましたが、
> オフショア開発ではなかなかそうはいかないのですね。
アンケート結果を信じるなら、「当社ではちゃんと規約を守ります」との回答はわずか６％。この数字が独り歩きしては困りますが、nakajiiさんご指摘の通り、オフショア開発では意外なほど規約が守られていないようです。
十分なデータを収集していないため、結論を急ぐことはできませんが。
実態調査を進めると、もしかしたら、規約が守られない原因の大半は発注する日本企業の問題だったりして。
Posted by: 幸地司 | January 24, 2008 05:35 PM
nakajiiさん、こんにちは幸地司です。
> 実際、複数の顧客がリピーターとして継続発注をしているかは
> 良い委託先を見極めるための大きなポイントだと思います。
> オフショア開発会社の初期選定時には参考になると思います。
正論。これは痛いところを突いてきましたね。鋭いご指摘ありがとうございます。となると、タケノコのように湧いて出る家内制手工業な中国オフショア受託企業には、厳しい評価基準です。
【オフショア開発会社の選定基準、価値観を判定する方法】
もし可能なら、オフショア開発会社の社長と営業窓口とプロジェクトマネージャーと現場のプログラマーをそれぞれ別室に呼んで、次の質問を投げかけてみたいです。（容疑者尋問っぽい発想です）
「あなたが担当するオフショア開発プロジェクトにおいて、あなたが責任を負うべき品質は次のうちどれですか？ もし複数の品質特性を挙げた場合は、優先度をつけなさい」
機能性
信頼性
使用性
効率性
保守性
移植性
◎幸地が満足する回答例＝意識統一
理想論ですが、全員の答えが同じなら大満足です。もし全員が「我社はソフトウエアの保守性には責任を持ちません」と回答しても合格。全員一致は無理でも、少なくとも社内で品質意識が統一されていることが感じられる回答が欲しい。
×不満な回答例＝みんなの意見がバラバラ
社長「全ての品質が重要である」
営業「どれを優先すべきかはcase by case。お客様のご指示に従います」
ＰＭ「仕様書通りの品質を確保します」
ＰＧ「リーダの指示に従います」
Posted by: 幸地司 | January 24, 2008 05:37 PM
幸地さん 佐藤です。
経験交えてご回答します。
>> いくらコスト削減で安くなっても、後々無駄なコス
>>トが発生すると意味がないので、少し割高でも同じ>>値観で仕事ができる会社、ＰＭを選択しています。
>コーディング規約を守る効果を具体的な数値（特に
>金額）で示さないとなかなか議論が先に進みません。>その観点から、「割高でも・・・を選択する」と判断>する姿勢は、投資対効果(ROI)からも理にかなってい
>ます。
>
>差し支えなければ、下記２つを教えてください。
>
>問１ 割高の許容範囲は？（価格１．５倍でも選択
>するか）
今、オフショアで開発しているのですが、実は私が担当する前に開発した前バージョンの製品も別のオフショア会社で開発しましたが、ひどい状態でだめなので
作り直ししています。
ひどい状態というのは色々ありますが、今回のテーマである「コーディング規約が守られません」という問題も多大にあります。
当時の責任者は、日本で開発するよりも1/3になるとのことで実施しましたが、結果的にある程度サービスできるレベルにリカバリするために、日本側でもぐらたたき、追加開発して、最終的に追加機能も加えていますが全面作り直しになりましたので、当初の５倍程度かかっています。
私が担当してからは、私が過去に数社とオフショア開発経験があるので、その中で一番割高だけど安心して任せる会社、ＰＭ指名でやっています。
それでも日本国内の協力会社の1/2程度です。
ということで、複数のオフショア会社とお付き合いしましたが、最終的には比較的割高だけど、マネジメントができる会社とだけ現在はお付き合いしています。
>問２ 同じ価値観で仕事できるかどうかを判定する
>方法（面談？チェックリスト？）
前述のとおり、何社かお仕事しましたが、初めは面談と提案書です。
単純に開発すればよいという提案（というか見積）だけしか出さない会社もあれば、きちんと提案書にして
出してくる会社もいます。
その上で、作業の過程でアウトプットを要求し、日本側で精査して、フォローしながら進めています。
Posted by: 佐藤朋也 | January 25, 2008 10:13 PM