for文の繰り返し制限数を明記すべきか
中国オフショア開発の現場最前線で活躍する人からの相談。
日本から中国子会社に提出したコーディング規約の中に「for文を繰り返さない」という禁止令がありました。ところが、中国側から、「何回か指定して頂けないと対応できません」と言われました。中国オフショアでは一事が万事この調子なのでしょか。こちらとしては非常に困ります。当社には他にも「一つ関数（method）の行数は長すぎない」などのコーディング規約があります。いちいち数値指定しないと対応できないんなんて、中国子会社はプログラマではなく単なるコーダーではないでしょうか。
あなたの考えに最も近い選択肢を1つ選んでクリックしなさい。
◆for文の繰り返し制限数の明記は当然
◆for文の繰り返し制限は粒度の粗い指針で対応すべき
◆その他
締切：2009年09月18日18時00分
協力：クリックアンケート http://clickenquete.com/
The comments to this entry are closed.
Comments
裏付けとしてパフォーマンス指標と許容範囲を示すべき。
Posted by: kanji | September 10, 2009 04:09 PM
> 裏付けとしてパフォーマンス指標と許容範囲を示すべき。
kanjiさん、いつもコメントありがとうございます。 他の人も気になると思うので、もう少し具体的な補足説明をお願いできますか。
Posted by: 幸地司 | September 10, 2009 04:24 PM
for文を禁止したいのか、forの使用回数を禁止したいのかを、詳しく別の言い方で説明する必要があるのではないかと思う。（その他）
Posted by: なつた | September 11, 2009 07:02 PM
幸地司さん
以下の回答はまさに「班門弄斧」であり、不適切なところがあればご指摘ください。
まず、回答の選択肢について
①for文の繰り返し制限数の明記は当然
→理由もなく「3回以内」という一般論で回答したら、「CODERに見なされたか？！」と現地の「できるSE」からの不満が募る
→「これはルールだ！！」と現地PMがそれを過剰に守ろうと指示し、「コーディング規約を守るための実装」になってしまう。
②for文の繰り返し制限は粒度の粗い指針で対応すべき
→似て非なる回答であり、実装時にいちいち確認が来たり、又は適当に実装されて思いがちの結果になる可能性もある。
↑の例は、いずれも極端的なパターンだが、
前回の投稿で申し上げた「裏付け」とは、
コーディング規則だけで語りきれない品質指標、およびそれを共有することなのでした。
たとえば、トランザクションの処理時間や、メモリ使用率など、
システム要件や設計者の思いを現地ベンダと共有できれば、
「FOR文の制限は何回までか」を喜んで考えてくれる現地SEさんもたくさんいらっしゃいます。
おそらく、「何回にすべきか」と聞かれること自体、
双方のコミュニケーションには、「設計書通り実装」のレベルに留まっているのではと思います。
事件は現場で起こってます。オフショア現場で起きた「FOR文回数事件」も、
指示するより、目標共有のうえで実装現場の「青島君」に期待したほうが確実だと思います。（せめて私がBSEとして参画したオフショア案件から、すでに数人の青島くさんが現れてくれた）
なので、自分の話をまとめますと、
①実装の立場でなければ、提示できるのは参考程度の規約にすぎない
②コーディング規約に先立って、現地ベンダと品質目標を共有する意識が必要
Posted by: kanji | September 11, 2009 07:08 PM
なつたさん
> for文を禁止したいのか、forの使用回数を禁止したいのかを、
「言葉の壁」により、そういう誤解を招く恐れがあるのですね。気づきませんでした。コメントありがとうございます。
Posted by: 幸地司 | September 11, 2009 07:13 PM
kanjiさん
>目標共有のうえで実装現場の「青島君」に期待したほうが確実だと思います。
驚きました。なぜ中国・青島（チンタオ）から入手した情報だと分かったのでしょうか？？ と思ったら、チンタオではなく青島（あおしま）ですね。日本映画好きなら、外国人SEでも知っているかな。失礼しました～。
Posted by: 幸地司 | September 11, 2009 07:18 PM
>①実装の立場でなければ、提示できるのは参考程度の規約にすぎない
>②コーディング規約に先立って、現地ベンダと品質目標を共有する意識が必要
大変参考になりました。このような説明や意識共有を必要としないのが、従来の日本型請負ソフトウェア開発の特徴であり、かつ最大の利点です。
ところが、日本でも「長期取引に基づく高コンテクストな暗黙知の共有」が崩壊しつつあるため、いちいち品質目標を共有するプロセスが必要となってきました。
高コンテクストな暗黙知とは、kanjiさんが指摘する「コーディング規則だけで語りきれない品質指標」や「それを共有する意識」などです。
米国―インド間のOffshoringなら、高コンテクストな暗黙知をできるだけ低コンテクストな形式知で表現しようと試みます。
今のところ、対日オフショア開発では、高コンテクストな暗黙知を高コンテクストのまま伝達すべきだという思想が主流です。なぜなら、日本の高度経済成長はまさにその通りのやり方で成功したからです。
一般に、暗黙知（コーディング規則だけで語りきれない品質指標）の形式知化は、高い費用負担を伴います。さらに、ただでさえ忙しい現場では、そもそも暗黙知を形式知として文書化するための時間が足りません。
逆説的ですが、kanjiさんが提言するように、規則では語れない意識を日中で共有するための時間を確保してあげることが、オフショア成功の近道かもしれません。従来の日本型請負ソフトウェア開発と比較すると、一時的な費用負担増加は避けられませんが。
オフショアＰＭＯや現場を知らない役員は出しゃばらずに、事件を一番よく知る現場に権限を委譲することが肝心かもしれませんね。
Posted by: 幸地司 | September 11, 2009 07:24 PM