日本でわざわざソースコード再検査
無駄と思いつつも、受け入れでも単体テストを再現します
中国で単体テストが終了したら、日本でも「受け入れ」と称して単 体レベルで動作確認します。ちょっと面倒です。
(東京在住/中国人SE)
東京の会社に在籍するある中国人SEは、製造から単体テスト工程にかけては中国へ飛び、受け入れ工程では日本に戻り、両方の現場で大活躍します。そんな中国人SEから聞いた話より。
中国では、コンパイルが通って正常系が動作するようになったら、最初のコードレビューを実施します。そして、コーディングが完了したら、一斉に単体テストに入ります。
中国でのコードレビューでは、全てのプログラマが顔を揃えて、コーディング規約とコメント規約が守られているかどうかをPCプロジェクタに投影して確認します。
実は、この後に日本でも各担当者のソースコードを1本選んで、コードレビューすることが義務づけられています。ところが、この制度は関係者の間でかなり不評です。
■問いかけ
中国でコードレビューを実施済みなのに、その後に日本でもソースコード再検査を義務づける会社があります。現場では、やはり不評とのこと。あなたは、日本でのソースコード再検査に賛成ですか?
問1 ソースコードの再検査が不評な理由を答えなさい。
問2 あなたは、日本でのソースコード再検査に賛成しますか?
締切:2008年10月16日18時00分
協力:クリックアンケート
The comments to this entry are closed.
Comments
丸ごと再度チェックする必要がありません。但し、リスクを考えると、プロジェクト進行中に担当者ごとにある程度のチェックが必要でしょうね。
Posted by: ken | October 09, 2008 11:58 AM
そのたです。
納品物を検査するのは品質確保のため当然のことだが、中国側をパートナーと見るなら不評の理由(無駄とか、信用されていないとか)を調べ、対処する必要がある。(例えば、重要性を納得まで説明するとか、検査の基準/根拠を事前に明示するとか、テレビ会議で中国のレビューを参加するとか)
Posted by: 張小東 | October 09, 2008 11:59 AM
張さんの仰るとおり、中国側ソースレビューした作業員の面子が立たないが、リスク回避の対策が必要。
受入れ側品質検査での不具合検出時には、製造側プロジェクト担当の予算・報酬減と受入れ検査部門の報酬増(予算移動)、検出報告件数の数倍の自主バグ取りなどペナルティを明確にしながら、レビュー廃止の時期を待つ。
Posted by: ちり | October 09, 2008 11:59 AM
必須と考えます。
プログラム設計の担当は、機能を理解したSEではないため、結合した場合のことを想定した動作とならない場合があるためです。
また、構造上も良くないことが多い(動けばよい、拡張性がない)ためです。
Posted by: okky | October 09, 2008 12:00 PM
kenさん、こんにちは幸地司です。
>リスクを考えると、プロジェクト進行中に担当者ごとに
>ある程度のチェックが必要でしょうね。
プログラマが50名のチームだと、担当者ごとのチェックは大変な負担になりそうです。ということは、「ある程度」のさじ加減はチーム規模によって変わりそうですね。
Posted by: 幸地司 | October 09, 2008 12:01 PM
張小東さん、こんにちは幸地司です。
>中国側をパートナーと見るなら不評の理由を調べ、対処する必要がある。
さすがですね潤オ。
現場の心理状態を分かっていらっしゃる。
最近の調査で分かったのですが、「パートナー」という言葉の感覚は、日本と中国では全く異なるようです。
ですから、ほとんどの日本人は、中国人が「(中国的な意味で)パートナーとして付き合いたい」という意味を正しく理解していません。よくあることですが、危険ですね。
Posted by: 幸地司 | October 09, 2008 12:02 PM
ちりさん、こんにちは幸地司です。
>・・・しながら、レビュー廃止の時期を待つ。
その通りです。私の心を見透かしたようなコメントをくださり、ありがとうございます。
拙著『オフショア開発に失敗する方法』の第15-4節 後ろ向きの日本人をやる気にさせる法(p242)で紹介した精神と共通します。
オフショア開発の各取り組みは未来永劫続くものではありません。組織やリーダの成熟度に応じて段階的に進化します。
日本でも厳重な再検査が必要な第一段階、徐々に検査項目を簡素化する第二段階、そしてレビュー廃止の第三段階、さらに一歩上の新しい検査基準を導入する第四段階を経て、再び第一段階に戻ります。
第四段階まで進化した組織では、新しい検査基準をオフショア拠点が自主的に導入します。いつまでも現場力が向上しないオフショア拠点では、常に第三者から基準やルールを与えられます。
Posted by: 幸地司 | October 09, 2008 12:03 PM
okkyさん、こんにちは幸地司です。
> また、構造上も良くないことが多い(動けばよい、拡張性がない)ためです。
メルマガで紹介した事例では、中国のコードレビューでは「規約に遵守しているかどうか」のみを確認しました。このため、可読性・拡張性・保守性といった品質特性について、担当者毎のバラツキが生じるのはやむを得ません。
okkyさんは「日本でソースコード再検査に賛成」とのご意見ですが、中国固有の理由が大きいですか?
すなわち「結合した場合のことを想定した動作とならない」や「動けばよい、拡張性がない」は、中国特有の現象でしょうか。日本でもそうだが、中国では○○○の理由から特にリスクが大きい、という根拠があれば、教えてください。
Posted by: 幸地司 | October 09, 2008 12:03 PM
問3回答
段階的であれ設計が\"完了\"しているなら(ウォータフォールであれ、アジャイルであれ)テンプレートモジュール提供や、過去開発モジュールの参照を指示すれば、実装段階での誤認/異常組込みは減少する。 むしろ実装以前のフェーズが重要で、仕様の行間を読ませたりシソーラス提供なしとか和製英語・略語利用といった、コミュニケーション阻害要因の対策に着目したい。
着眼点を変えると、契約前に委託先の過去開発案件の提示を求め委託側評価を行ったり、逆張りでテスタモジュールの開発をオフショア委託し自社要件提示の不明確さを自己認識するのも面白いかも。
対等な協業関係を構築するためには、(委託・受託)双方の成長戦略的思考(施行)が必用。
実務の火急的対策としては皆が回答するでしょうから、長期的視野で見てみました。
Posted by: ちり | October 10, 2008 02:46 PM
私は、再検査は必要がないと考えています。
再検査することになるには、トリガーがあるはずです。
すなわち、無作為に再検査をする必要ありません。
何か確認作業をするには、その目的とタイミングが重要だと考えています。
これは、相手が日本人か中国人かに違いはありません。
当方は、相互の考えを確認するために、最初に実装されたソースコードについてペアレビューを
実施することを奨励しています。
ペアレビューとは、設計者(指示者)視点で実装者(作業者)への指示内容が確実に伝わっているかを確認します。
設計者側は多くの設計ドキュメントで提示するため、それを意図した通りに解釈できているかを確認することが必要です。
また、大規模となると目が行き届かなくなるため、指示者側の意図を理解している人物を特定することを目的とします。
すなわち、作業者リーダを的確に判断しその者にピアデスクチェックを開発現場で実践してもらうためです。
プロジェクトによって、体系的なレビューを実施することで
再検査は避けることができると考えています。
全てをアドホックに実施していると再検査は必要になっていしまうと考えています。
Posted by: Sara | October 10, 2008 02:47 PM
幸地さん
>プログラマが50名のチームだと、担当者ごとの
>チェックは大変な負担になりそうです。
>ということは、「ある程度」のさじ加減はチーム
>規模によって変わりそうですね。
→仰ったとおりです。補足ありがとうございます。但し、うちの会社(中国)では、殆どのプロジェクトでソースレビュー工数を事前に用意しています。PMの私にとって一番CUT PLに頼みたいのは設計把握とソースレビューであります。また、中国側の面子問題も考慮したら、開発チームとは別体制、別費用で中国側のソースレビュー体制を組むことがよいかもしれません。
Posted by: ken | October 10, 2008 02:48 PM
賛成です。
不定期な再検査が必要です。中国のテスト計画書、ソースレビュー報告書を見て、完璧だと思って、総合テストに入ってから、うその報告書がわかったケースがいくつか経験しました。毎回チェックすると、大変なふたんになりますし、必要もないと思いますが、放任すると、たまに手抜き作業が出てきます。不定期なチェックが必要と思います。検査で不良を見つかった場合、担当者までフィードバックする必要があります。
Posted by: レイコ | October 10, 2008 02:49 PM
賛成です。というよりせざる終えない。
構造上も良くないことが多い(動けばよい、拡張性がない)。
テストもしていないのではないかといった具合。
おそらく、テストに対する別費用の要求があるのかもしれませんが・・・
納品時の必須事項として開発の一部には考えられていないのかも?
日本側の品質評価基準も曖昧だと中国側ではまったく品質を保障してこない・・・
ISOへの認識は薄いようで・・・
今では、日本内でもソースコードに対しての意識も低いため・・・
日本や中国に限らず品質をチェックできるよう継続的インテグレーションにて品質OKかNGかを自動的に通知する方向に持っていければと画策中・・・
Posted by: osamu | October 10, 2008 02:50 PM
賛成
Posted by: da | October 13, 2008 11:45 AM
品質管理は全数チェックを基本とすべきです。
物が動くタイミングの全てにおいて検査が必要です。
省略出来るのは品質がいいという根拠があるときだけです。
きちんと根拠があり品質がいいと立証されれは、発注元と先の要員が同一かつ同種の発注内容であれば省略するのは構わないと思います。
品質が悪いから検査をするのではなく、品質がいいから省略するのです。
Posted by: 九山隆司 | October 13, 2008 11:46 AM
ちりさん、こんにちは幸地司です。
> 実装以前のフェーズが重要で、仕様の行間を読ませたりシソーラ
> ス提供なしとか和製英語・略語利用といった、コミュニケーショ
> ン阻害要因の対策に着目したい。
前工程がより重要とは、まさにおっしゃるとおりです。コミュニケーション阻害要因を対策するなら、個別問題を取り上げてそれぞれに対する原因究明が欠かせません。ご指摘の阻害要因が生まれる原因の一つは、「常識は文章に書けない」だと思います。
オフショア大學では、使い古されたフレームワーク(思考の枠組み)を活用して粒度が揃った箇条書きを駆使すれば、文書コミュニケーションは劇的に改善されると指導しています。
Posted by: 幸地司 | October 14, 2008 10:02 PM
Saraさん、こんにちは幸地司です。
> 相互の考えを確認するために、最初に実装されたソースコードに
> ついてペアレビューを実施することを奨励しています。
>
> また、大規模となると目が行き届かなくなるため、指示者側の
> 意図を理解している人物を特定することを目的とします。
同じプロジェクトなのに、作業者側の意図を理解する人と理解しない人が混在することを認めるのですね。独創的なご意見だと感心しました。ありがとうございます。
また、プロジェクト毎に「作業者側の意図を理解する人物が異なる」という前提ですね。ペアレビューの目的を達成するためには、誰と誰がペアになって、どんな方法で実施するのでしょうか? とても気になります。
Posted by: 幸地司 | October 14, 2008 10:03 PM
kenさん、こんにちは幸地司です。
> PMの私にとって一番CUT PLに頼みたいのは
> 設計把握とソースレビューであります。
ということは、kenさんの取引先には、設計を把握せず、ソースレビューが甘いCUT PLがいるのですね。(ちなみにCUT PLとは何でしょうか^^)
> 中国側の面子問題も考慮したら、開発チームとは別体制、別費用
> で中国側のソースレビュー体制を組むことがよいかもしれません。
なるほどー。中国では面子が邪魔をしてソースレビューがうまく機能しないことがあるとの認識ですね。ところで、初級プログラマが担当させられる“テスター”とは違い、別体制のソースレビュー担当者には極めて専門的な知識・経験が要求されるような気がします。ということは、社内の別プロジェクトを担当する一人前のPLクラスが、一時的に他プロジェクトのソースレビューをお手伝いすることになりそう。この理解は正しいですか?
Posted by: 幸地司 | October 14, 2008 10:04 PM
レイコさん、こんにちは幸地司です。
> うその報告書がわかったケースがいくつか経験しました。
> 放任すると、たまに手抜き作業が出てきます。
「日本中が泣いた! 衝撃の告白」、ありがとうございます。先方の担当者には「嘘を報告した」や「手抜きした」との自覚はあるのでしょうか? 気になります。
Posted by: 幸地司 | October 14, 2008 10:05 PM
osamuさん、こんにちは幸地司です。
>日本側の品質評価基準も曖昧だと中国側ではまったく品質を保障してこない・・・
とても関心が高い領域です。何を基準化すればよいのか? どこまで基準化すればよいのか? 品質評価基準の方向性(vector)と強さ(scalar)の設置に各社とも頭を悩ませています。そもそも、発注者が普段から品質評価基準を使いこなせていないと、オフショア開発での有効活用は厳しいかも^^;
Posted by: 幸地司 | October 14, 2008 10:05 PM
九山隆司さん、こんにちは幸地司です。
> 品質が悪いから検査をするのではなく、品質がいいから省略するのです。
かっこい潤オ、名言です。
>きちんと根拠があり品質がいいと立証されれは、
>発注元と先の要員が同一かつ同種の発注内容であれば
>省略するのは構わないと思います。
この部分はよく理解できませんでした。
Posted by: 幸地司 | October 14, 2008 10:06 PM
>okkyさんは「日本でソースコード再検査に賛成」とのご意見ですが、中国固有の理由が大きいですか?
基本的に、全てコードレビューは実施します。
但し、日本では気を利かせた(こちら都合)プログラマSEがいる場合もあります(※)が、経験的に私のオフショア開発でそれができる会社と出会ったことがありません。
ですので、必須と考えています。
※このようなケースが見られる場合、次回からはポイントを絞ったコードレビューになります。
Posted by: okky | October 14, 2008 10:07 PM
okkyさん、こんにちは幸地司です。
> 日本では気を利かせた(こちら都合)プログラマSEがいる場合もあります(※)が、経験的に私のオフショア開発でそれができる会社と出会ったことがありません。
中国には気を利かせたプログラマSEがいないとのご指摘ですね。これは、技術的な課題なのか、単に経験不足なのか、それとも国民文化の違いからそう感じるのか。
・優れたプログラム(1本のプログラム)
・優れたモジュール(プログラムの組合せ)
・優れたシステム(モジュールの組合せ)
↑の「優れたXXXX」を判定する評価基準が日本と中国では異なるのでしょうか。あるいは、「優れた」仕事をする気を利かせたプログラマSEは、対日オフショア開発ではなく別の仕事に従事している可能性もありますね。下流工程の対日オフショア開発は「つまらない」と公言してはばからない人は大勢いますし。
コーディング規約(文章とサンプルプログラム)の提示だけでは、中国で気を利かせたレビューを実施してもらうのは難しいでしょうか。
Posted by: 幸地司 | October 15, 2008 09:21 PM
こんにちは。okkyです。
国民性の違いだと、今は思っています。
仕様書に記載していない事項について、想像して確認して実装する、という習慣が少なく、
仕様書どおりに実装し、不備やもれている面があっても、それは提供情報の不足、となることが多いですよね。
そのような行動特性は、経験や技術の話ではないように思います。「想像する」ことをやめているように感じます。
「優れた」の基準は、中国と日本で異なるというよりも、発注側と受注側で意見が異なるのではないでしょうか。
#立場が変われば言うこともかわるような気がします。
コーディング規約だけでは、、、レビューは難しいのではないでしょうか。
ちなみに、ここに書かせていただいている内容は、
私のこれまでの経験に基づいています。
よって、全てこれに当てはまるわけではないと思いますので、注意していただきたいです。
Posted by: okky | October 15, 2008 09:22 PM
わかりにくくて申し訳ありませんでした。
以下のことを仕組み化すれば結果として省略するのはかまわないということ言いたかったのです。
検査を省略する条件を設けそれを満たせば省略する。
例えば、関連する人や作業の性質との組み合わせをキーに過去のデータと照らし合わせ、過去何年か品質がよければ、段階的に検査を減らして、最終的には最低限の検査のみにする。
作業に関連する条件が変われば検査は復活する。
相手が日本でも中国でも同じです。
Posted by: 九山隆司 | October 16, 2008 10:49 PM
okkyさん、こんにちは幸地司です。
>> 中国には気を利かせたプログラマSEがいないとのご指摘ですね。
>
> 国民性の違いだと、今は思っています。
中国オフショア開発では、不備や漏れがあっても仕様書通りに実装する□□正直なプログラマが多いと感じているのですね。
表面的な行動特性を観察すると、仕様書に記載されていない事項を一生懸命に想像して実装する中国人プログラマは大勢いることがわかります。残念ながら、想像がハズれて間違った実装になることもあります。さらに、「余計なお世話」で、プログラムに蛇足がつくる勇み足もしばしば報告されます。
というわけで、中国でも、仕様書の行間を埋めようとするプログラマの試みは頻繁に目撃されます。
でも、日本とは何かが違うような気がする・・・。
その違いとは何か?
あるいは、↑は単なる私の思い違いか??
Posted by: 幸地司 | October 16, 2008 10:50 PM
九山隆司さん、こんにちは幸地司です。
>過去何年か品質がよければ、段階的に検査を減らして、最終的には最低限の検査のみにする。
再説明ありがとうございます。
過去何年間か同じ担当者が同じ作業を担当しているなら、検査は省略できそうですね。違う担当者が、関連性の薄い作業を担当する場合は、検査必須となりそう。
今の中国オフショアに期待するのは、はっきりいって「ソフトウェア製造工場」による原価削減。ですが、検査を簡素化して費用を浮かそうなんて考えは、捨て去った方がよさそうです。真面目に上流工程を改善しなさい!ってことでしょうか。
Posted by: 幸地司 | October 16, 2008 10:51 PM
「再検査」に関しては賛成です。
再検査の内容に関しては、中国のレビュー担当者と日本のレビュー担当者との差を埋めるものであればよいです。(最初にレビューという作業を具体的に定義する必要が出てくるし、中国側ができることと、日本側ができることを検討する必要があります。まぁ、何をどこまで中国にやらせるのかの問題になりますが。)
再検査のやり方に関してはケースバイケースで考える必要がある。
九山隆司さんの仰る
>品質が悪いから検査をするのではなく、品質がいいから省略するのです。
はごもっともで、中国でも日本でも同じだと思います。
Posted by: 一個中国人 | October 30, 2008 01:58 PM
>今の中国オフショアに期待するのは、はっきりいって「ソフトウェア製造工場」による原価削減。
日本で少子化と理系離れが進む今、オフショア開発の方針を変える時期は来ていますね。
Posted by: 一個中国人 | October 30, 2008 02:02 PM
一個中国人さん、こんにちは幸地司です。
>「再検査」に関しては賛成です。
> 再検査のやり方に関してはケースバイケースで考える必要がある。
積極的な書き込みをくださり、ありがとうございます。これからも、どしどしご意見をお寄せください。
もし宜しければ、「再検査」について、一個中国人さんが実際に取り組んで成果を出した事例を簡潔に書いてももらえますか。その方が、より参考になりますので。
Posted by: 幸地司 | October 30, 2008 08:35 PM
一個中国人さん、こんにちは幸地司です。
> >今の中国オフショアに期待するのは、はっきりいって「ソフトウェア製造工場」による原価削減。
>
> 日本で少子化と理系離れが進む今、オフショア開発の方針を変える時期は来ていますね。
おっしゃるとおりです。
とはいえ、トップのかけ声と現場の意識が大きく乖離しているのが実態です。また、受託開発専業のSIerやソフトハウスの意識と、情報システム部門の意識も違うようです。
また、私のような外部の人間が「正論」を叫んでも、「コスト削減」「コスト削減」「コスト削減」との声しか聞こえない会社では、かえって厭味に聞こえるので要注意。
景気後退が押し寄せるなど、今はとっても難しい局面ですね。
Posted by: 幸地司 | October 30, 2008 08:43 PM
ソースレビューに関して、自分の取った対策は、
1.遠隔VC(SVNなど)
2.頻繁なレビュー書確認
3.稼働率の収集
です。
1.VCを建たせて、ソースコードに限らず成果物全般を日本から随時閲覧できるようにする。中国側で解決できない問題を、日本側に投げやすくします。
2.レビュー書を送ってもらうかVCから取得するようにして、レビュー結果を頻繁に確認する(それは日本のオンサイトでも同じだと思いますが。)。一回目の取引相手でも、早い段階で問題発見できる仕組みがあれば、解決策を考えることができるようになります(一般論になってしまいました。)。
3.VCからもある程度稼働率がわかります。実際に中国側のPGの稼働率を把握するのが、ソースの完成度につながると考えています。
Posted by: 一個中国人 | October 31, 2008 12:22 PM
一個中国人さん
>1.遠隔VC(SVNなど)
>2.頻繁なレビュー書確認
>3.稼働率の収集
なーるほど。具体的に教えていただき、ありがとうございます。このブログに書き込んでくれるレイコさんの活動に似ているような気がします。
一個中国人さんは発注側の立場だそうですが、上記1.2.3.を真面目にやるとすれば、仕様まとめや設計に割く時間が足りないような気がします。
一個中国人さんの過去の成功体験では、監視コントロールに70%以上の時間を割いていたのでしょうか? 前出のレイコさん曰く、スカイプや遠隔VC監視にかなり時間を割いているとのこと。小規模プロジェクト限定の方法ですが・・・。
> 3.VCからもある程度稼働率がわかります。実際に中国側のPGの稼働率を把握するのが、ソースの完成度につながると考えています。
↑この秘訣を教えてもらえますか。(1)中国側PGの稼動率を把握する方法、ならびに(2)稼働率からソースの完成度を推測する方法。 これは素晴らしいノウハウですね。
Posted by: 幸地司 | October 31, 2008 06:36 PM
> 一個中国人さんは発注側の立場だそうですが、上記1.2.3.を真面目にやるとすれば、仕様まとめや設計に割く時間が足りないような気がします。
「時間が足りない」という主張の前提はなんでしょうか?1つのPJにはPGは一人ではないし、SE、PLも一人ではないと思います。
> 一個中国人さんの過去の成功体験では、監視コントロールに70%以上の時間を割いていたのでしょうか? 前出のレイコさん曰く、スカイプや遠隔VC監視にかなり時間を割いているとのこと。小規模プロジェクト限定の方法ですが・・・。
70%というのは、何を前提にしていますか?「小規模プロジェクト限定の方法」と結論付ける理由は理解できません。オフショア開発をするには、オンサイトより多くのコミュニケーションの時間を取るのがやむを得ないと考えています。それが惜しければ、高い人件費を払ってオンサイトでやればよいだけの話です。PJの規模に伴ってコミュニケーションの時間が指数的に増加するのが知られています。オンサイトであろうが、オフショアであろうが、このコストはさけられないでしょう。
小規模であろうが、大規模であろうが、無理に高いパフォーマンスを期待してしまうと危険だと思います。
>↑この秘訣を教えてもらえますか。(1)中国側PGの稼動率を把握する方法、ならびに(2)稼働率からソースの完成度を推測する方法。 これは素晴らしいノウハウですね。
秘訣はありませんよw。数値化と定量化だけのことです。
1)報告してもらうのと、確認するの2通りしかありません。両方やれば確実でしょうという考え方です。報告書を確認しても真実を把握しにくい。成果物を直接に確認するのが有効だと思います。
2)最終納品物のステップ数を取る/取れるなら、途中のステップ数変化も取る/取れるの話です。バグ潰しの進捗とか、コーディングの進捗とか、いろんな方法論と経験則があります。そこらへんは、グーグル先生が教えてくれると思います。
Posted by: 一個中国人 | November 03, 2008 11:46 PM