イベント情報

10月定例会開催のご案内

「べからず集作成(まとめ)」

上海近郊での合宿(二泊三日)になります。

お申し込みはコチラ

オフショア開発PRESS譲渡

◆お見逃しなく!!
フォーラム会員様限定イベントです。
 
◎詳細はこちら

あと 151 日で
上海万国博覧会 2010/05/01~

活動実績‎ > ‎

09/07/16 第15回勉強会(べからず集~検収・テスト編~)

‎2009/07/20 10:39‎‎ に 勝又伸一 が投稿   [ ‎‎2009/08/21 7:13‎‎ に更新しました ]

7月16日(木)に第15回の勉強会を開催しました。

今回の勉強会は、

幹事:秋山さん
ファシリテータ:東さん
庶務(記録、レポート、タイムキーパ、撮影):勝又

という体制で開催しました。

会場は、交通至便(!)で定番になりつつある、
Andyさん率いるワンジーテクノロジー様です。
中山さん、渡辺さん、いつも差し入れありがとうございます!!

以下、レポートいたします。

(1)新メンバのご紹介
(2)勉強会の模様&今月のMVP
(3)二次会の模様
(4)会計報告

(1)新メンバのご紹介

ここ最近は、勉強会のたびに、新メンバを迎えることが多くなっておりますが、
今回の初参加は大槻さんです。


※大槻さんに寄り添っているのは内海さんですが。なんか・・・。

大槻さんは、ソフトバンク等でソフトウェアの販売・マーケティングに関わって20年の大先輩。
事業を興すにあたって、ベトナム等いろいろな地域を視察されたとのことですが、
最終的に、上海の○○○(これは参加者の秘密)に魅せられて単身乗り込んでこられました。

まずは、少人数制の有料セミナー「宝知セミナー」の開催を通して
有用なソフトウェア・活用方法を情報発信していくとのこと。

オフショア開発とは異なるジャンルですが、ソフトウェアを生業とするもの同士、
色々とご指導をお願いいたします。

(1)勉強会の模様


今回は、事前に投稿していただいた8つの失敗事例・悩みについて意見交換しました。
次回の定例会で、「べからず」や具体的な指針まで落とし込む予定です。

  1. テスト専門部隊の弊害と限界
  2. 「単体テスト」「結合テスト」という用語が意味する内容がプロジェクト・個人ごとに違う
  3. 納品物の品質評価基準に後出して付帯事項が押し付けられた。
  4. 直すのでなく隠す
  5. チーム間、メンバー間での横連携不足
  6. 発注者側の受入検収の負荷が高い
  7. 品質指標定着の困難さ。
  8. テストの品質が低い(メンバの品質意識が低い。正常系で動けばとりあげずOK?)

■1. テスト専門部隊の弊害と限界

勝又提供ネタです。直感と異なる挑発的なタイトルだったせいか、しょっぱなから白熱しました。
趣旨としては、

・テスト専門部隊を置くと、開発者のモラルが低下(「テスターがいるからいいや」)が発生して、
  設置しない場合よりも品質が低下する傾向がある。
・プログラミング、内部構造(概要レベル)を知らないテスト専門部隊では
  検出できないバグがある。

というものです。

「事例のテスト専門部隊は、義務・責任を果たしているのでは?」
「テスト専門部隊は有用である。」
「そもそもテスト担当のレベルが低すぎる。」
「責任分担が不明確だ。」
「弊社でもモラル低下が感じられる。」

といった、意見が出ました。

現段階の結論としては、

「専門部隊は有用。但し、一定の基準を満たさないテスト専門部隊は設置するべからず」

となります。

来月は、「一定の基準」について具体的に定義したいと思います。

■2. 「単体テスト」「結合テスト」という用語が意味する内容がプロジェクト・個人ごとに違う


ネタ提供者の趣旨としては、このような同名異(※)があることで、油断すると、

・見積もり失敗(工数予測過小)
・期待値を下回ることでCS低下

を招くことがあるというものです。

参加者からは、

「確かにある。」
「これは仕方がないから、見積り時・計画時に成果物を具体的に定義すべき」
といった意見がありました。

内海さんからは、「広告でも同じ。例えばヘッドコピーと言葉だけで説明しても、認識齟齬があるので、対面して、「ここ!」と指さして説明する。」

李さんからは、成功事例として
「プロセス遵守+サンプル作成+問い合わせ窓口一本化で回避できる」
という力強い指摘がありました。




(※)同名異議は「ホモニム(homonym)」といいます。なじみのあるシノニム(synonym)は異名同議。








■3. 納品物の品質評価基準に後出して付帯事項が押し付けられた。


本件は、東さんのほうから失敗事例として紹介がありました。
これは既に解消されている事例ということで、その対策(成功事例)が紹介されました。

成功事例「事前契約の細分化と途中成果物検収依頼の徹底。」

そして、べからずとしては、

「発注側のプロセスがしっかりしていない場合は受注するべからず。」

8月は、「しっかり」について掘り下げたいと思います。





なお、プロセスの代表格であるCMMIの効果については以下のように懐疑的な意見が多かったです。

「中国の場合、品質向上でなく営業目的の為に取得している。」
「CMMIは、会社全体でなくても取得できる。」
「受託開発がメインの会社は、要求レベルの低い社内システムでCMMIを取得している。」
「CMMIは、金さえ支払えば取得できる。金も政府からの補助金で賄える。(儲かることも)」


■4. 直すのでなく隠す


勝又氏から以下のような事例が紹介されました。

あるシステムのコードレビューをしていたところ、
以下のようなコーディングを発見した。

Refresh()
Refresh()  ← なぜ同じ処理を2回?

画面描画の不具合(残像が残る)対応であった。
この処置により、バグの発生頻度が劇的に減るのは確かだが・・・
根本的原因は、排他制御が考慮されていないからであった。  

また、規約に違反して、
例外発生を無視(Catchして回復処理もログ出力もしない)して
処理を続行してしまうというケースも多く見受けられる
(性能低下、原因特定困難)


この事例に対して、

李さんからは、
「中国の大学ではこのような実務的な内容は教えない。だからできない。」という指摘がありました。

畑さんからは、
Catchや排他制御は書かせない。(フレームワークで吸収)」という自社で成功している事例の紹介がありました。

標準化や規則を活用した仕組み化(人材非依存)よりも、
スーパースター人材で高いパフォーマンスを発揮させる方向性を突き進むAndyさんからは、
「そもそも、このような人材に任せるほうが問題では?」
という指摘がありました。



とりあえずの対策としては

「指導するのは困難。複雑な機能は任せるべからず。」

となりますが、オフショアビジネス的には正解かもしれませんが、中長期的にそれで本当にいいのか?という疑問が残ります(※)。この点について8月は議論したいと思います。

(※)中国人技術者の成長は?モチベーションはどうなる?この案件は、オフショア開発には通常みられないゼロからのスクラッチ開発で、プロジェクトメンバーの士気は非常に高かった。コンシューマ向けプロダクトとしては論外な品質であったが、正常系機能の実装工数は日本の標準的なエンジニアと比較しても遅くなかった。



5. チーム間、メンバー間での横連携不足

事例を提供してくださった畑さんからは、この課題に関して、以下のような原因分析がありました。


『個人主義(安易な言い方ですが。。)』
『自分の担当部分だけを仕上げればよいという考え方。』
『プロジェクトとしての結果が各自の評価に繋がるという意識が全く無い。』

対策としては、

『プロジェクトとしての結果を評価(給与)に直結させる。』
『リーダーに情報共有を促進させる。』

と考えているが、これに対してどう思うか?という投げかけがありました。

これに関しては、各社ともこれといった効果的な対策がないようで、いきづまりかけましたが、
そんな中、山口さんのほうから以下のような成功事例の紹介がありました。

『過去に「横展開地獄」があった。それを経験したTeamは、今ではこの問題は解消されている。』
『とにかく、しつこくしつこく注文した。』
『方法は、終わるまで帰さないこと。』

8月はこの成功事例をさらに掘り下げてみたいと思います。(例.山口さんは人事評価権を持っているか?どのような規則・書式・ツールを利用しているか?)



6. 発注者側の受入検収の負荷が高い(発注側が嫌気がさしている)

こちらも畑さんからネタ提供がありました。
オージス総研では日本国内外注開発とオフショア開発の生産性を測定しているので、
数字でもはっきりとこの傾向が出ているのだと思います。

畑さんからは、
「トップ・マネジメントからの支持」と「上海の品質向上」が課題をあげてくれました。

取り組んでいる品質向上策としては、「テストの定型化・自動化」を紹介してくれました。

定型化:テスト仕様書・テストケース・テスト規約等を標準化→品質のばらつきを抑制
自動化:xUnit,JMeter,Seleniumなどを使い、受入検収を自動化→負荷を軽減

8月は、自動化についてより掘り下げたいと思います。

この話題については、どの社も決定的な解決策は持ち合わせておられないようですが、
以下の指摘が印象に残りました。


李さん>発注側を巻き込む(中国現地に長期出張)ことで、発注側の気分は和らげられる。
李さん>弊社では、バグレビューを4回行っている。とことん質問される。
Andyさん>「オフショア開発というのはそういうものでは。だから、うちは内製している。」

7. 品質指標定着の困難さ


勝又提供のネタです。参加者に聞きたかったことは、以下の3点でした。

  1. ・バグにレベル付け(例.S→A→B→C)するのをどう思うか?
  2. ・品質指標として何を使っているか?
  3. ・全プロジェクトで共有に利用できる指標はあるか?

1については、レベル付けは複数社で行われているとのことでした。

2・3については、件数/KLOC(もしくはFP)を各社とも使っているとのことでした。

ただ「この件数なら品質が良い・悪い」という基準については、

案件ごと(規模、新規・改造・移植など特性)に異なっており、全社で1個の定義というのはないようです。

バグのレベル付け(重み付け)の話題では、藤本さんのほうから、

『どの重みから対処してますか?』

という質問が出て、様々な角度から興味深い意見がでました。さて、あなたか?

藤本>顧客満足度を下げるのは単純ミス。なので、BとかCのレベルを無くそうという運動をしている。

>重みでなくバグ原因でグループ化して多いものから対処するようにしている。単純ミスを減らそうという方向性は弊社も同じ。

勝又>重要度が低いバグ(B・C)は許容してもらって、S・Aを0件にしようという運動をしている(いた。)

8月は、このレベル付けについてさらに掘り下げたいと思います。

勝又的には、「バグレベル/総工数」を使えば、全プロジェクトに適用できる品質指標とできる気がしてます。。。

8. テストの品質が低い(メンバの品質意識が低い。正常系で動けばとりあげずOK?)

こちらも畑さんからのネタ提供です。畑さんが実践されている対策は以下になります。

何をすると顧客が喜び、何をすると顧客が怒るのかを考えさせ、
顧客満足度が給料につながるということを理解させる。

顧客が満足しない → 発注しなくなる
 → お金がもらえない → 給料が上がらない
という理屈を社員にはよく言っています。

我々の仕事は製造業ではなくサービス業であり、
儲かる儲からないは顧客満足度次第と思って欲しい

これに対しては、大半の参加者からは共感しておりましたが、
Andyさんからは以下のような厳しい意見が発せられました。

Andy>
 方向性としては賛成。
 ただし要求レベルに見合う待遇を実施しているか?
 まさか1万元以下の給料の人材のこのような要求をしていないか?

また、事例として紹介された内容が「エビデンスの間違い、不合格なのに合格とする」というものだったので、

勝又>
 方向性としては賛成。
 ただこのレベルの人材には期待しないほうが良い。
 「不合格に合格」というのは人間として失格。
 実際、弊社でも過去に同様の問題が発生したことがあるが、
 この問題を発生させる人は一握りの人間でかつ改善されなかった。
 やめてもらうべきだと思う。



番外

この他、本題から派生した話題で、「テストケースの密度」について、
藤本さんから質問があり、単体テストの場合、
1000STEPあたり60~80個というのが多くの社で採用されている基準のようでした。

また、勝又のほうから、「テスト工程でのツールの活用状況」について質問があり、
以下のような結果になりました。

テスト工程でのツール活用状況
No ツール 使用社数
1 ソースコードの静的解析ツール(コーディング規約) 2
2 カバレッジ 2
3 負荷テストツール Web系開発では全社
4 ファンクションポイント 2

最後は、恒例のパシャリ。
アントレ講座で学んだ「チャーーンス」というノリは不発でした。(汗




事務局の独断と偏見で決定する今月のMVP

今月は、、、、

畑さん!!

が初受賞しました。
(受賞理由:ネタを多く提供してくれたこと。議論を盛り上げてくれたこと。)

「我々の仕事はサービス業だ!」
「自立的に動ける人材を育成する!!」という熱い思いに、
「その待遇じゃ無理」という意見もありましたが、

「ワシはあきらめまへんよ!」

と力強く語ってくれました。頑張ってください!!

(3)二次会の模様

二次会は、「八剣伝」で開催されました。

本日、初参加の村中さんも合流され、多いに盛り上がりました。

盛り上がったというか、、、この騒がしさは、おそらく過去一番だったかと。
八剣伝さんごめんなさい。m(_ _)m

中村の反対の「村中」で覚えてください

大手ITベンダで豊富な経験をもつ村中さん(37歳、上海暦3ヶ月)は、
この日、中国人若手と一緒にマネージャ研修を受講のため勉強会には参加できませんでした。
次回からはぜひ!!

「村中」という名前はありそうで無い名前(1万人に1人)で、
なかなか覚えてもらえないとのこと。(間違いの定番は「村山」「村上」)
しっかりと覚えました。

李さん、酒豪発覚

最初に盛り上げてくれたのは、酒豪っぷりをみせてくれた李さん。
李さんの勧めで複数の人が「乾杯(=イッキ)」をする羽目に。

銀行出身→プロマネという経歴で、「営業は始めてです。どうぞよろしく」と自己紹介する李さんですが、これなら心配ありませんね。(笑

秋山さん、完全復活

勉強会では食事を忘れたせいか、普段の元気がなかった秋山さんですが、二次会で完全復活。

どういう流れでそうなったかは把握しておりませんが、
束ねていた髪をおろして、メガネも外したところ
アルコールが回って既にオヤジ化した参加者から大好評でした。

大阪人だけど・・・

畑さんは、大阪人ですが「ボケができない」ことが発覚。

悩み相談コーナー

悩み相談コーナーでは、山口さんが、Andyさんから
「悩みあるでしょ。あるでしょ。」と追求されて困ってました。(笑

藤本さんニックネーム決定

「そういえば、なんでAndyという名前を使っているのか?」という話題から派生して、
藤本さんが「私もほしい。中国名がいい。1文字がいい」と言ったの運のツキ。

藤本さんのニックネームはFに決定しました。




こうして、 時計は12時を回ったのでした。。。


未確認情報ですが、Andyさん、畑さん、山口さん、藤本さん、東さんは、
さらに「地蔵」に向かったとのこと。

東さんと藤本さんはバイクですが何か。


みなさま、おつかれさまでした!!!

(4)会計報告

今月から勉強会は会費をいただくことにいたしました。(10元)
会費は会場を提供してくれる会社様にお渡しすることにしました。

《勉強会》
お茶代 : 10元/人
合計: 110元
※ 差し入れご提供者のワンジーさんに渡しました。

《2次会 お食事会》
合計金額:1296元
集金: 1320元 (120元/人)
繰越金: 24元