●議事進行の工夫

なお、前回の勉強会終了後のアンケートでいただいた指摘に対応するため、今回は以下の工夫を施しました。

１．議論を可視化・構造化するための資料を用意
２．関心度の高い５つを選んで重点的に議論
３．自由発言制でなく指名制
  「これについてどう思いますか？話したい人どうぞ！！」
  というスタイルでなく、
  「●●さんいかがでしょうか？」
  というスタイルに改めました。


「指名制」のほうは、
東さんのアイデアでしたが見事に実践していただきました。
ファシリテータには、
空気・表情を読む高～～～い能力が要求されますが、
とても効果的だったように思います。







では、本題です。

※文中の個人名は敬称を略させていただいております。ご了承下さい。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■(1)Test専門部隊の弊害と限界

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

『責任感を「期待」するべからず』
『書いてないことをやってもらえると「期待」するべからず。』

●ネタ提供者としては、

『一般的にテスト専門部隊を設置しているプロジェクトは品質が低い』

という認識を持っており、主な問題点として以下を上げました。

(1)限界：内部構造を知らないテスタが抽出できるバグは限られている
(2)弊害：開発者の品質意識低下が発生する。

これに対して、色々な意見・事例紹介がありました。

●失敗事例としては、

『インターンの学生さん(大学のレベル的には高い)１６人でテストチームを構成した』
『うまく機能しなかったのでその後はやっていない。』
『本日までに完了するように」と指示しても、残業しないで帰ってしまう』
『不合格のテストに合格と印をつけたり･･･。』

『自分が現地に来て横について指導している時は良いが、帰国すると・・・。』(東城)

●以下のような意見がありました

劉尭>
・素人のほうが意外な操作をするので顕在化するバグもある。
・時間の無駄なので単体テスト仕様書はつくるなという指示をうけることもあるので一概に言えない。(簡単なチェックリストで十分)






忻琳玲>
・テストを誰がやるかはあまり問題でない。
・テスト仕様書をどういう基準でつくるか？誰が検収するか？にこだわる。
・私たちの場合、作成者はプログラマ。
・内容は概要設計書準拠が50%、プログラム準拠が50％としていた。
・テスト実施者は、テスターでもプログラマでもＯＫ。
・単体テストの検収は概要設計者。
・エビデンスは画面のハードコピー(効率重視なので、生データを残したりはしない。)

 なお、ＳＡＰの場合は、プログラムに入力される
 データパターンが決まっているので、一概に他のシステムと比較できないかもしれない。


王輝>
・「テスト専門部隊」という組織はないが、より大きなテーマをもたせた「品質保証部隊」がある。
・６ヶ月の外部研修を実施して方法論・意識を学ぶ。
・ツール開発は重要な活動の１つ
・テスト仕様書はプログラマも概要設計者も作成する。

  →モチベーションの面でも効果が期待できそうな気がします。




●効果が期待できるＴｉｐｓとしては、以下が紹介されました。

(1)上流工程の人に参画(作成 or レビューア)してもらう
(2)サンプルを提供する
(3)ツールの開発・活用

(1)については、効果があるのは確実だと思いますが、

「上流工程＝＞発注側＝＞お客様＝＞受注側は立場弱い」

という構図が多いオフショア開発においては、
異なる課題～発注側の検収負荷が高い～を招きますので、
テスト項目数が膨大な単体テストレベルで適用できるか？
という疑問が湧きます。
ただ、グループ会社や、お客様先に常駐しての開発であれば
適用可能だと思いますので念頭においておきたいものです。

(2)(3)については、
こちらはプロジェクトや企業規模の大小に関わらず
実践できるのではないかと感じました。

特にツールの開発・活用というのは、
チェックを厳しくして品質を向上させると同時に、
本来はトレードオフの関係にある「効率」も向上させる優れた方法だと思います。


●総括

おおむね「テスト専門部隊は危険・不要」という認識が形成された気がします。

もちろんテスト専門部隊が期待通りの成果を上げることもあるので、
その条件については、別の機会に議論したいと思います。

また、意見が異なる部分については、
どちらが正しい・間違いというものでなく、
単体テストの粒度や
その他のプロジェクトの条件（例.規模、期間、新規？改造？）が異なるようです。

これらに加えて、

誰がやるのか？
設計書の「質」とは？
どういうプロセス？INPUTは？OUTPUTは？書式は？
プロジェクト規模との関係は？
単体テストの粒度は？

といったより具体的な内容を
別の機会(10月以降の新テーマとして検討)に議論したいと思いました。

＃ 「フォーラム標準づくり」は複数の方から要望がありますのでやりますかね。。。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■(2)用語「単体Test」の解釈の不一致

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

・認識確認をせずにプロジェクトを進めるべからず
・相手も同じことを考えていると期待するべからず。
・曖昧な要求・質問(例.できますか？これと同じで。)をするべからず。

・横より縦(プログラマと設計者)の連携を重視すべし
・標準化すべし(書式、指標)
・サンプル作成すべし！
・レビューすべし！
・パッケージ化すべし！
・社内講座を実施すべし！

●単体テストというよりも、より汎用的な議論がなされました。

べからず部分は、
もはやオフショア関係者にとっては「常識」といえるレベルだと思います。

すべきの部分では、「横より縦」という事例の紹介が新鮮でした。
先月、李さんなど成功している事例と今回の事例・議論をあわせると、

標準化（プロセス準拠）、サンプル作成、レビュー

という点が成功しているプロジェクトに共通している要素のようです。

渡辺さんのほうからは、標準化について

『一般論として日本人は能力差の分散が小さいが中国人は分散が大きい。
 個人任せにしておくと、中国では品質に大きな差がでる。
 標準化が重要と痛感している。』

という発言が有りました。

増満さんからも、「愚痴ですが・・・」と断った後に、同意する発言がありました。

『同感。今日もケンカしてきた。』
『「できます」というから信用したのに、
 後から「あ、こういう機能もあったので追加でコスト下さい。」
 と平気で言ってくる。』
『それでもプロかと・・・。』


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■(3)直すのでなく隠す

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

「任せるべからず」

「難しいところはフレームワークで吸収すべき。プログラマにさわらせない。」
「細かい対策を会社で用意するのでなく、権限と責任を与えて信賞必罰で任せる。」

ネタ提供者としては、
「任せなければうまくいくのはわかるけど、そんな仕事は面白くない。」
ので、任せてうまくいく方法を模索したかったのですが、
現時点では、無理と判断しました。

以下に主な議論を紹介いたします。

増満＞こういうケースを社内で共有・教育する仕組みはなかったのか？
勝又＞この案件ではバグ情報の共有ＭＴＧをやっていた。
      そもそも、このようなリスクは「全てのタスク」が抱えているので、
      何か問題が発生するたびに「原因＝○○不足」「対策＝○○教育」
      という対象療法的なアプローチをとると
      対策の量が実行不可能（コストor時間）なほど多くなってしまうだけ。
      (「改善」に熱心な会社の多くがここでつまづく）





秋山＞知らないからできないのでは？
勝又＞確かにそのようなケースも多いが、このケースはあてはまらない。
     本質的な課題は
    「自分で解決できない場合にどういうアクションをするか？」
     ということ。
     日本人(少なくとも私)なら「わからない」と上長に報告するが、
     そうではないことが多いと感じる。



増満＞となると、、、、やっぱり「任せるべからず」ということですね（笑
勝又＞ですね。（苦笑

渡辺＞対策を積み上げるのでなく、権限と責任を与える信賞必罰アプローチが効果的。
      １００人規模の組織になったら難しいかもしれないが・・・。
      あと、日本人の(過剰なほど)細かい期待に沿えるような人材は独立するので、
      オフショア開発の現場に残っていないと思う。期待すべからず。


忻琳玲＞仕組みである程度解決できる。
        規約とそれに準拠したコーディングチェックシートを用意して
        プログラマ本人に提出させていた。

なお、この件については、
「現在の議論はフェアでない可能性がある。中国人技術者の声を聞くべき。」
という声がありますので、
優秀な中国人技術者を招聘して、お話を伺って見たいと思います。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■(4)横連携不足

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

・横連携を必要とする体制をつくるべからず。（特に小規模プロジェクト）

・縦連携を考慮すべき ・情報共有の情報システムを使うべき ・ボトム・ミドルの自発的意識に期待するのでなくトップダウン方式でやるべき（権限・責任付与)

●ネタ提供者の畑さん、成功事例保有者の山口さんが欠席だったので、
議論になるか不安でしたが、非常に盛り上がりました。

●効果のあるＴｉｐｓとしては、

東城>
  縦割り組織（権限と責任を付与）にして、
  情報を一元的に管理して対応している。

忻琳玲＞
  プログラマに設計者とコミュニケーションをとらせる。(縦の関係)

秋山>
 失敗事例を情報システムに掲載して共有している。
 参照することを義務付け(毎朝)
 間違いが多いと評価を下げる。

渡辺＞
  弊社のプロジェクトは短期・小規模なので、
  現時点では、大きな問題と感じていない。
  プロジェクトのトップに権限と責任を付与して、
 トップダウンで取り組んでもらっている。

劉尭＞
 権限と責任を付与してくれるのは嬉しいが
 上の人がすべてコントロールするのは困難だと思うが・・・。

渡辺＞
 文化論であまりにも一般化しすぎかもしれないが、、、
 あるスーパーＰＭ（１０プロジェクトをみている）の話。

 そこの会社のそれぞれのＴｅａｍＬｅａｄｅｒは技術的には優秀だが、
 プロジェクト間の協力(例.他プロジェクトで誰かが休んだら手伝う)という発想は無い。

 色々と話した結果、結論としては以下に落ち着いた。

 ・そういった教育を受けていないので仕方がない
 ・そもそも、世界的にみたら日本人のほうが特殊
 ・そもそも、こういう期待にこたえられるような人材はオフショアの現場にいない


●本題からは、やや外れますが、
派生して「社員間の人間的な交流」の方法・効果について
の話題が出たのでご紹介します。


増満>
 アメリカは個人主義だけどコミュニティを大事にするので結構情報が連携される。
 パーティが開かれたり、就業時間中におやつがでてきて話し込んだり。
 この点は中国とは違う。

 ※増満さんの「アメリカは、、」発言を複数紹介しておりますが、
   別にアメリカかぶれではなく、参加者の質問に答える形で
   情報を提供してくれています。

東>弊社ではスポーツ交流が盛ん。その中からリーダが生まれてくる。

王輝＞会社から50元補助/人/月している。交流が増える。

小西＞情報共有の効果はあったか？

東＞効果ある。
  ただし強制力が必要（仲良しイベントだけでは無理）
  わが社は大学教授が先生で社員は元生徒という特殊な環境。
  ただし、自発性が失われる点に問題を感じている。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■(5)品質指標定着の困難さ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

「品質指標がない会社はオフショアするべからず」

●もはや、品質指標がないプロジェクトは「論外」という意見が大勢を占めました。

●こうなってくると、各社の品質指標の中身に関心が移りますが、
先月・今月の議論をまとめると、

「どこも同じ」

という印象です。

（品質指標の例）
 単体テストのテスト項目数の基準 -> 1000ステップあたり60～80個
 合格基準-> バグ検出数の下限・上限を用意。範囲外はチェックして対処を決定
 バグ収束曲線 -> 品質判断、出荷判定・出荷日予測等に活用。Excelマクロで自動化

●私の知る範囲ですが、
４・５年前の中国では数値で品質を語ってくれる会社は皆無だったので、
オフショア開発も「体裁」の面では、 かなり成熟してきたと感じます。

「画期的な方法」でなく、 「あたりまえ」のことを
どれだけ徹底できるか？自動化できているか？数値の蓄積があるか？
という点がベンダーの「強み」となる時代になっているようです。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■(6)納品直前の追加要件

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

「危ない発注元とは取引するべからず」

見極め方法

「相見積もり」をとっている会社 は危険。
第六感（粘着質の人は危険、険のたっている人は危険）

●この話題は、
独立系・一括請負で業務を推進されている企業の方が
特に共感されておられました。

「それはひどい・・」という理不尽な事例も複数紹介されました。

・日本人は寝技(後出しジャンケン)が得意
・事前に決めるのが下手

という自虐的な発言の連発です。

「(契約書に記載がなくても)そんなのは、やるのがあたりまえだろ。」

という議論が日本ではまかりとおりますが、
この議論は中国からみれば「非常識」というのが参加者の総意です。

●欧米系の企業文化に詳しい増満さんからは、

「程度の問題で、欧米系でももちろん変更はある。」
「ただ、最初の要求がかなり具体的。Ｗｅｂサイト構築の例だと、
  先方がモックアップ、デザイン素材を用意してきた。」
「さらに機能仕様を細かく既定してくるので、
  認識づれが発生するリスクがかなり低い。」

●匿名になりますが、

『日本のＩＴ企業の仕事はうけたくない。』
『非ＩＴ企業(＝経営層のＩＴリテラシーが低い)なら先生扱いしてもらえるのに、
  なぜ、手配師が幅を利かせて、細かくて、理不尽な要求をする
  ＩＴ企業と取引するのか？』

という声も印象的でした。

さて、批判・評論で終わらないのが
実務者・当事者の集まりであるフォーラムの議論です。

「小さい会社の場合は存続危機になる。
  検収条件等を厳密に記載している。
  先方に非がある場合は配置したアプリケーションを撤去するところまでやる。」

「取引しない」･･･見極め方法は前述

という対策も紹介されました。

（４）番外編

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

(1)中国企業向けの開発でも同じ？

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
東城さんのほうから、

『オフショア開発に議論しているような問題点があるのは承知している。
 中国企業向け開発の場合どうなっているのでしょうか？
 要求レベルや品質や単価や売上の回収など。』

という質問が投げかけられました。

これに対して一般に流布している情報と異なる事例を複数の方から紹介していただきました。
それによると、、、

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

申しわけありませんが、参加者限定とさせていただきます。m(_ _)m

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

(2)もはや上海でオフショアするのは無意味？

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

エンジニアの単価について以下のような情報が紹介されました。

・日本の地方では、仕事のできるエンジニアであっても単価は３５～４０万円まで落ちているところがある。（この単価で客先常駐も）
・ミャンマーでは真面目で日本語（２級）・技術もそこそこの人材の単価が１０万円。

さらに、議論の随所にでてくるように、中国エンジニアは、、、

・教わってないのだからできない。
・(過剰といわれる日本品質)の要求を満たしてくれるような人材は会社に定着しない。(独立)

という状況です。

もはや「コスト削減目的のオフショア開発」は、
上海ではありえないのでは？と多くの人が感じたと思います。

以前、上海市政府のオフショア推進関連の人と交流していたときに、
オフショア開発における上海の強みは？と突っ込んでも、共感できる答えがなく、

最終的には、

「市場と考えろ！！！」

と開き直られましたが、実際、その認識が正しい時代に突入しているようです。

（５）二次会の模様

 今回の二次会は、会場のビルを出て徒歩３０秒の「ｘｘｘ」で開催されました。

 王輝さん、渡辺さんは、勉強会後もお仕事があるとのことでご欠席。
 (お忙しい中、ありがとうございました！！！）

 今回の会場は、非常に便利な場所にあるのですが、
 以前、利用しようとした時に、某Ａさんから

 『ここは絶対やめておいたほうがいい！！』

 という助言をうけたので、これまで利用する機会がありませんでした。

 今回は、幹事（秋山さん）が、場所選定に困ったあげく、
 「怖いものみたさ」の心理も働いて利用することになりました。

 結果、、、

 「ギリギリセーフ？」という感じでしょうか。

 価格は、食べ飲み放題で１５０元なので、
 同レベルの店ではやや高めという印象。(駅近という立地を考えると安い？)

 メニューは豊富で、味もまぁまぁでした。
 (刺身、お寿司、天ぷら、串焼き、サラダ、うどん、お茶漬け等)

 気になったのは、料理・飲み物が出てくるのが非常に遅い点。
 これはいただけないですね。。。

 印象に残ったのは、

 (電気代節約のため？）トイレまでの通路、店を出るまでの通路の照明が消えていること。
 懐中電灯で店員さん(ビル管理人？)が足元を照らしてくれるのですが、
 新鮮な体験でした。

 ただ、、、

 こちらも１１時の閉店時間を大幅に超過したのでおあいこですね(汗
 大幅超過したにも関わらず、店長さんが元気良く

「ありがとうございました！！」
「又、お越しください！！」

 と仰っていたのは好印象でした。

（６）会計報告

 勉強会･･･１０元×１１人 → １１０元 (秋山預かり)
 二次会･･･預かり１,３５０元（１５０元×９人） 支出１,３３２元
 剰余金･･･１８元
 剰余金（累計）・・・６５元

（７）連絡事項

(1)オフショア合宿があります・・・近日報告
(2)宝知セミナーの開催（フォーラムメンバ特典付）・・・大槻、秋山
(3)Androidビジネス研究会の立上・・・中尾、秋山
(4)Rubyセミナー協賛募集（世界的人物が来海）・・・増満

---

９月は、合宿で勉強会を行います。

今回の勉強会は、幹事：秋山さん、進行：東さん、記録：勝又で実施しました。
至らない点は、引き続き改善してまいりますので、ドシドシご要望ください。