中間納品はお化粧されたプログラム
三現主義とは
現場に行って、現物を観て、現実を直視せよとの教訓。品質管理の基本的な心構えである。
（本誌発行人）
中国オフショア開発で痛い目にあった日本人プログラマの嘆きより。
中国から完成したプログラムが納品されたので、日本で動作確認したところ、単純なバグがいくつも見つかりました。直ちにQ＆A票で不具合を指摘しましたが、中国側の試験では問題なかったと一蹴されてしまいました。
実は、このプロジェクトの基本設計は、日本側の都合で大幅に遅れていました。中国オフショアチームは、不平をこぼさず連日残業で対応してました（中国社内では不満たらたらかもしれません）。納品間際には、日本も中国も休日返上で作業にあたりました。
ところが、いざ蓋を空けてみると中国からの納品物はバグだらけです。ですが、日本としても中国に多少の負い目があるため、厳しい態度で責任を追及することが出来ません。
納期が迫っていることもあり、中国での修正をあきらめて、全て日本側で対応することになりました。普段からお世話になっている日本のＢＰに急遽ＰＧを増員してもらい、他人のソースコードのデバッグに明け暮れました。
結局のところ、予定よりも手間もコストもかかりました。これがオフショア開発なら、もう要らないと思います。（日本人）
上記は、２０代の日本人プログラマの言葉である。もしも、同じセリフを日本人プロジェクトマネージャーが言ったなら、「それは自業自得」と非難の嵐は避けられまい。だが、この状況で当該20代プログラマを責めるわけにはいかない。
当該プロジェクトでも、途中で中国からサンプル・プログラムを取り寄せて動作確認を行っていたはずだが、最悪の事態を防げなかった。途中納品されたサンプルだけが、お化粧されていたのかもしれない。
今となっては後の祭りである。結果的に、この会社の三現主義はお題目にすぎないことが判明した。オフショアゆえ現場にゆけず、忙しさのあまり現物チェックを怠り、サンプルに騙され現実を見誤ってしまった。
■成功の勘所
2008年3月創刊のオフショア開発専門雑誌より。
中国語の「没問題」を、日本人が文字通り「問題なし」と解釈すると危ない。「没問題」のに「現在」の２文字をつけて考えるべきである。これまでの作業工程では「没問題」。でも、明日問題が発生するかどうかは、誰もわからない。それくらいの軽い発言であることが多い。
※
【アンケートに回答しよう】
☆オフショア開発では、三現主義（現場・現物・現実）が無視されがち。計画的にサンプルを中間納品させても、お化粧されてチェック機能が働かないことが多い。
◆よくある
◆たまにある
◆あまりない
◆皆無、当社は完璧
◆その他
締切：2008年02月05日23時00分
協力：クリックアンケート
« 短期出張 | Main | 琉球新報に写真掲載 »
The comments to this entry are closed.
Comments
中国側のPG開始スケジュールより前に規約書を一式送付し、主要PG数人にプロトタイプの作成を依頼し、
その後現地に向かってチェックする事で一定の品質を
保つことに成功しました。
ただプロジェクトの規模的に日本人SEが訪中する
費用を計上できないものが多々あるのが現状です。
●
Posted by: sato | January 28, 2008 08:41 PM
satoさん、こんにちは幸地司です。
現地でプロトタイプをチェックされたのですね。具体的には、どの点に注意してプロトタイプを確認しましたか。仕様理解や動作確認だけですか。それとも、設計思想からソースコードの中身まで精査しましたか。
主要ＰＧ数名の品質がよくても、後から人海戦術で大量投入されたプログラマの納品物がＮＧという事例が山ほどあります。プロジェクト規模が大きくて、全品チェックは非現実的だという指摘もあります。
実務者の皆さんにとっては耳タコかもしれませんが、うまい解決法があればご教授願います。
Posted by: 幸地司 | January 28, 2008 08:42 PM
オフショア開発の責任者(国に関係ない)はシステム開発の経験を持ってるのでしょうか？テスト環境について発注側と同じ環境にしていましたか？PMは品質管理の責任者でもあるのでしょうか、PM自身はSEの知識を持っているのでしょうか・・・、以上の疑問をクリアーしなければ開発に踏み込まない方がいいと思いますね。オフショアだけではなく、日本国内の開発も同じだと思います。オフショア開発に失敗が多いとよく聞きましたが、開発の責任者はシステム開発経験をもって、\\\"三現主義\\\"も実施することであれば、オフショア開発について失敗することはありえないと思いますね。（試験環境は日本と同じしなければ試験結果の違いに対して相手の悪いと断言しにくいと思いますが・・・、私(日本企業の社員・開発の発注側)の場合、必ず同じ環境でテストします、そして最初の一個目のテストデータも同じにしています。同じ結果を出れば次の試験ステップに踏みます。ご参考まで）
Posted by: 春 | January 28, 2008 08:44 PM
春さん、こんにちは幸地司です。熱意溢れるコメントありがとうございます。
> テスト環境について発注側と同じ環境にしていましたか？
私が知る限り、テスト環境の完全一致は難しいと思います。ハードウエアが違う、ネットワーク環境が再現できない、機密保持のため本番データを社外に持ち出せず擬似データでしか試験できない・・・などなど、数え上げるとキリがありません。
案件の難易度や互いの成熟度によっては、テスト環境が違っていてもオフショア開発が成功することもありそう。
ところで、SEの知識が希薄なＰＭでは、オフショア開発を成功させるのは難しいのでしょうか。私の経験では皆無ですが、確率ゼロとはいえなさそうな気がします。てか、「ＳＥの知識」が曖昧なので、ちゃんと定義しない限りこの議論は無意味ですね。失礼しました。
わたし、恥ずかしながら「三現主義」なる言葉をついこの前まで知りませんでした。「三現主義」は、ソフトウェア業界の常識なのでしょうか。先日の調査によると、５Ｓの認知度はかなり低かったです。
Posted by: 幸地司 | January 28, 2008 08:46 PM
中国のソフトウェア開発者はとりあえず動くサンプル程度の製造は非常に早いと感じます。それになりに動くし好感触を得ます。反面、きちっと単体試験をしているにも関わらず製品化やリリースの最終局面でつまらないバグや機能の抜けなどがあります。レビューにレビューを重ねてもこのような障害はなかなか抑えることができないのが現実です。
Posted by: 岩釣 | January 30, 2008 09:33 AM
岩釣さん、こんにちは幸地司です。
「・・・をやれば、オフショア開発について失敗することはありえない」と断言される方がいます。先日も「うちは失敗したことがない」と豪語する中国ベンダの日本人営業マンがいました。
成功／失敗の定義は人によってまちまちなので、額面通りにコメントを受け取るわけには行きません。ですが、自信満々の彼らとレビューにレビューを重ねても障害を取り除けないプロジェクトとの違いは何だと思いますか？
差し支えなければ、どんな手順で「レビューにレビュー」を重ねてきたのか、簡潔にご説明ください。
Posted by: 幸地司 | January 30, 2008 09:34 AM
こんにちは幸地司です。
先日、次の話を耳にしました。
『初めて委託する会社や担当者の場合には、コーディング開始から１週間目に必ずコードを送ってもらい、コーディングの癖を見抜いて厳しく指摘する』
とても興味深いお話です。その方が用いるコーディング規約は、シンプルで項目数も少ないのが特徴。規約やレビューの目的が明確で、必要な手は貸すけど、余計なことはしない。メリハリのきいたcontrolだと感心しました。
Posted by: 幸地司 | January 30, 2008 09:35 AM
みんなわかっていることと思いますが、中間納品をさせた結果をどう活かすかにより、その後の結果（最終納品）に差が出るのではないかと思います。
Posted by: ひらじ | January 30, 2008 10:49 AM
ひらじさん、こんにちは幸地司です。
> 中間納品をさせた結果をどう活かすかにより、
> その後の結果（最終納品）に差が出るのではないかと思います。
ずしりと重いコメントありがとうございます。
中間納品の目的によって、結果をどう活かすのか複数の打ち手が考えられそう。たとえば、中間納品の目的が「ソースコードの癖の確認」なら、コーディング規約の周知徹底を強化する。たとえば、中間納品の目的が「難易度の高い機能実現に目処をつける」なら・・・する。中間納品の目的が「顧客を安心させるため」なら・・・する。目的が「個人間のバラツキをなくすこと」なら・・・する。
なので、たとえ中間納品物がバグだらけでコンパイルすら通らなくても、目的を満たせばよしとする考え方もありですね。
ひらじさんが実際に工夫されて、しかも効果絶大だった中間納品の結果を活かす取り組みがあれば、差し支えない範囲で教えてください。
Posted by: 幸地司 | January 30, 2008 10:50 AM
田畑良一さん、こんにちは幸地司です。
> サンプル自体が×のケースがあります。
なにやら奥が深そうな話です。私の好奇心を刺激します。差し支えなければ、もう少し具体的にご説明願えますか。
Posted by: 幸地司 | January 30, 2008 11:30 PM
こんにちは。
>>>現地でプロトタイプをチェックされたのですね。具体的には、どの点に注意してプロトタイプを確認しましたか。仕様理解や動作確認だけですか。それとも、設計思想からソースコードの中身まで精査しましたか。
ソースコードの中身含めてのチェックです。
OKになった段階で他のPGも同様に作ってくださいという依頼で作業を進めました。
これでPG毎の作りのばらつき等、初歩的な問題はクリアできました。（当然通常のバグはあります）
Posted by: sato | January 30, 2008 11:33 PM
中間納品までは日本側もプログラムソースを具にチェックしたりする場合がありますが、その時点でＯＫであれば、後は大丈夫という安堵感があるのでは？いずれにせよ、中国開発は定期的なチェックが必要なのでは？また、最終局面は駆け込みで成果物を仕上げることも多いと思います。
Posted by: 匿名希望 | February 01, 2008 10:57 AM
こんにちはひらじです。
弊社で行ったのは、最終納品のつもりで納品させました。コーディング規約や動作確認等も普通の納品通りの手順を踏みます。最終的な納品日はありましたがスケジュール上先に仕上がるものを納品させ受入検査を行うイメージです。全体で見ればある意味中間納品のような形になりました。
>>実際に工夫されて、しかも効果絶大だった中間納品の結果を活かす取り組みがあれば、差し支えない範囲で教えてください。
残念ながら、すぐに結果が良くなるということはありませんでしたが、１年程度の期間で見れば、その後もありましたので結果的に効果は絶大だったのではないかと思います。
規約やバグを指摘することは当然ですが、それがなぜ発生したかを検討しました。例えば中国側の取り方に誤解があったのか、それは中国側管理者の問題か、本人の問題か、仕様書、規約の問題か、説明の仕方の問題かなどです。ほとんどは、仕様書、規約の内容とコミュニケーション不足でした。つまり中国側だけの問題ではなく日本側に問題は無かったのかという観点です。そして原因を一つ一つ改善していき、最終的には中国側の理解も深くなり、また日本側のノウハウ蓄積にもなりました。当初納品物の平均納品回数が４回以上でしたが、最後の方の納品物は１回台まで品質が向上しました。
その次は最初の苦労の工数が無い分、日本側中国側双方の工数も費用も削減されることになりました。完璧ではありませんでしたが、日本国内へ委託しても起こりうるレベルとなりました。
Posted by: ひらじ | February 01, 2008 10:59 AM
satoさん、こんにちは幸地司です。
> ソースコードの中身含めてのチェックです。
それだと、日本側のチェック工数も相当膨らみそうですね。某しみけんさんのプロジェクトならＯＫですが、日本側メンバーから不満の声はあがりませんでしたか。余計な工数が増えると、オフショア開発抵抗勢力を生み出してしまうので要注意です。ただでさえ、ＳＥは忙しいのに。
> 他のPGも同様に作ってくださいという依頼で作業を進めました。
この一言で作業が順調に進んだとしたら、中国には優秀な管理者が現場を統括していたのではないかと推測されます。「同様に作る」ための作業手順などは、存在しないわけですよね？ 上海には、「構成管理」や「Ｑ＆Ａ」といった基本的な動作であっても10ステップ以上の細かいフローチャートで定義する会社があります。
Posted by: 幸地司 | February 01, 2008 11:01 AM
匿名希望さん、こんにちは幸地司です。
> 中国開発は定期的なチェックが必要なのでは？
ＰＭ的な統計・数値情報のチェックだけなら楽ですが、定期的に現場で現物を観て現実を知るとなると、今の日本側の体制だと厳しい会社がたくさんあります。やっぱり、日本側の体制不足のうちは、時期尚早ということで中国開発は諦めた方がよいですか？
> また、最終局面は駆け込みで成果物を仕上げることも多いと思います。
本音告白ありがとうございます。誰が何といおうと、人は「締め切り効果」を使って仕事を完遂させるものです。残念な事実ですが。
よく聞く中国の悪口ネタ：
最終局面にて、日本側は押しつぶされそうな重圧の中、全員連日徹夜の覚悟で作業に当たっているのに、中国オフショア拠点では今夜もさっさと定時帰宅。「目処がついたので、また明日やればいい」みたいな軽いノリ。こうした温度差が分散開発で生じると、あっという間に感情的な対立に発展してしまいます。
Posted by: 幸地司 | February 01, 2008 11:03 AM
ひらじさん、こんにちは幸地司です。
> そして原因を一つ一つ改善していき、最終的には中国側の理解も
> 深くなり、また日本側のノウハウ蓄積にもなりました。
素晴らしいサクセス・ストーリを披露いただき、ありがとうございます。
首都圏には、まだまだオフショア未経験の中堅企業がたくさんあります。彼らがオフショア着手をためらうにはそれなりの理由がありますが、多くの会社に共通する社風があります
・失敗回避傾向が強い
つまり、失敗を重ねつつも、徐々に改善していこうと考えるのではなく、いきなり完璧を求めます。つまり、現在取引する国内Business partnersと同等の品質・手間・スケジュールを求めます。それでいて、コストは3分の1なんて・・・。んなアホな。
Posted by: 幸地司 | February 01, 2008 11:04 AM
こんにちはひらじです。
>つまり、失敗を重ねつつも、徐々に改善していこうと
>考えるのではなく、いきなり完璧を求めます。つま
>り、現在取引する国内Business partnersと同等の品
>質・手間・スケジュールを求めます。それでいて、コ
>ストは3分の1なんて・・・。んなアホな。
ははは（笑）その通りですね。中身まで知ろうとせずブラックボックスのままそっとしておき、紙（仕様書）を入れると完璧な製品が出てくると考えている傾向があります。国内委託でもそれだけではできないのにです。
この傾向は、弊社も例外ではありません。なので、そうではないこと認識してもらおうという社内活動を地道に行っています。
あれっ？本来のテーマから脱線してるかな？すいません。
Posted by: ひらじ | February 01, 2008 11:06 AM
中間納品自体がNG(遅延or低品質)というケースが多いです。ちなみに中間納品を求められるのは以下のパターンです。
・日本側が難易度が高いと認知されている案件
・日本側担当者が、オフショア開発初体験の案件
そもそも中間納品の目的・OK基準が曖昧なので厳密な回答でないことはご了承下さい。
Posted by: かつ | February 08, 2008 05:21 AM
かつさん、こんにちは幸地司です。
> ちなみに中間納品を求められるのは以下のパターンです。
> ・日本側が難易度が高いと認知されている案件
> ・日本側担当者が、オフショア開発初体験の案件
ということは、中間納品が求められることは少なさそうですね。「中間納品」を「中間レビュー」と言い換えるとどうでしょうか。有効に機能する場合と、そうでない場合があると思います。その違いがわかるといいですね。また、中間レビューのおかげで成功した案件と、中間レビューのおかげで大成功した案件と比較して、その僅かな決定的な違いを見極めるとワンランク上のマネジメントに到達しそうです。
Posted by: 幸地 司 | February 08, 2008 05:23 AM