●議事進行の工夫

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

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


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







では、本題です。

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

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

■(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セミナー協賛募集（世界的人物が来海）・・・増満

---

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

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

ここ最近は、勉強会のたびに、新メンバを迎えることが多くなっておりますが、

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

大槻さんは、ソフトバンク等でソフトウェアの販売・マーケティングに関わって２０年の大先輩。

事業を興すにあたって、ベトナム等いろいろな地域を視察されたとのことですが、

最終的に、上海の○○○（これは参加者の秘密）に魅せられて単身乗り込んでこられました。

まずは、少人数制の有料セミナー「宝知セミナー」の開催を通して

有用なソフトウェア・活用方法を情報発信していくとのこと。

オフショア開発とは異なるジャンルですが、ソフトウェアを生業とするもの同士、

色々とご指導をお願いいたします。

(1)勉強会の模様

今回は、事前に投稿していただいた８つの失敗事例・悩みについて意見交換しました。

次回の定例会で、「べからず」や具体的な指針まで落とし込む予定です。

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

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

■4. 直すのでなく隠す

この事例に対して、

畑さんからは、

「Ｃａｔｃｈや排他制御は書かせない。（フレームワークで吸収）」という自社で成功している事例の紹介がありました。

標準化や規則を活用した仕組み化（人材非依存）よりも、

スーパースター人材で高いパフォーマンスを発揮させる方向性を突き進むＡｎｄｙさんからは、

という指摘がありました。

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

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

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

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

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

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

1. ・バグにレベル付け（例.Ｓ→Ａ→Ｂ→Ｃ）するのをどう思うか？
2. ・品質指標として何を使っているか？
3. ・全プロジェクトで共有に利用できる指標はあるか？

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

２・３については、件数/ＫＬＯＣ（もしくはＦＰ）を各社とも使っているとのことでした。

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

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

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

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

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

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

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

８. テストの品質が低い（メンバの品質意識が低い。正常系で動けばとりあげずＯＫ？）

何をすると顧客が喜び、何をすると顧客が怒るのかを考えさせ、 顧客満足度が給料につながるということを理解させる。 顧客が満足しない　→　発注しなくなる 　→　お金がもらえない　→　給料が上がらない という理屈を社員にはよく言っています。 我々の仕事は製造業ではなくサービス業であり、 儲かる儲からないは顧客満足度次第と思って欲しい

テスト工程でのツール活用状況

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

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

今月は、、、、

畑さん！！

秋山さん、完全復活

悩み相談コーナー

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

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

未確認情報ですが、Andyさん、畑さん、山口さん、藤本さん、東さんは、

さらに「地蔵」に向かったとのこと。

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

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

《人気が高かった議題》
１）　発注する方も大変です
２）　設計書記載レベルがばらばら
３）　発注側に問題がある場合のマネジメントの難しさ
４）　発注側の作法を変えるのは難しい
５）　Webサービス特有の難しさ
６）　規約違反
得票数が高かった、以上の６題について勉強させていただきました。


議題１）　発注する方も大変です
発注する側の人間と、受注する側の人間は
実際に会って話をする機会がほとんどありません。
よって、いかにコミュニケーションをとるべきかということが問題にあがりました。

日本から設計者などを派遣すると、派遣ｌコストがかかります。
何もしなければ、伝達ロスがおこってもコストがかさみます。
それでは、一体どうするべきでしょうか？？

参加者の皆様は、コミュニケーションの問題を打破すべく・・・
●インフラを整備する
●文章力を上げるトレーニングを実施する
●設計者本人が来上海(実質、はべらし開発？)
というような感じで、努力されている模様です。

小規模の開発の場合、オフショアでせずとも
国内で開発をしたほうが結果的に費用がかからないこともしばしばあるとのことです。

でも、中国は、日本よりもプログラマーの絶対値が大きいです。
巨大なプロジェクトを行うには、
どうしてもオフショア開発をせざるをえないというのが現状のようです。
そうなると、コストをかけて現地の環境を整えるのが
成功への近道になるのではないでしょうか？

“意思”＋“感情”＋“信頼”　⇒　成功への近道

行き当たりばったりでは、だめなのですが

“コスト”と“計画”がしっかり決まっていないと

行き当たりばったりになってしまう事が多い模様でした。

（今月のべからず　その１）

コストと計画を決めずに、オフショア開発を発注するべからず。

議題２）　設計書記載レベルがばらばら
元々この議題は、
「地域、メンバー構成などにより、設計書の記載レベルがバラバラになってしまった」
という問題についての議論でした。
しかし、問題を掘り下げていくと、こちらの議題も
コミュニケーション不足が根底に会ったのではないかという方向に話が進みました。

●チームにまとまりがあるか？
●チーム内で情報の共有化はできているのか？
●チームの権限の統制がとれているか？
●役割分担ははっきりしているのか？
というポイントが欠けていると、設計から開発まで
様々な問題が多発するという結論になりました。

コミュニケーションの話題となると、
どうしても“出身地”に関する問題を耳にします。
出身地に問題があると答えをだすのは簡単です。
さらに、説得力があるように聞こえます。
しかし、それでは何も解決しません。
問題の視点をいかに変えていくかがポイントのようです。

（今月のべからず　その２）

出身地にこだわるべからず。

３）　発注側に問題がある場合のマネジメントの難しさ
お客様への説明はリーダーシップを取れる

プロジェクトリーダーが行うのが理想です。

しかし、理想を現実にするには

涙ぐましい努力が必要になってきます。

“根気とコストと時間があれば、成功する可能性が高くなる”

というのが、オフショアの常識となりつつあるみたいです。

逆に、環境を整える為の経費を削ると・・・

結果的に、もっと大きな損失が計上される事が多い模様でした。

オフショアは、コストとの戦いでは無くなって行くのかも知れませんね。

（今月のべからず　その３）

コスト削減のオフショア開発はするべからず。

６月第一週末あたりで正式な告知メール発送される予定です。
※　東さんは、日中文化交流の為に大連入りされるので、
　　アウトプット（報告書）を楽しみにしています！
※　木村さんは、今のところ在上海のご予定ですが、
　　急な予定変更がある可能性もあるご様子。
　　(どうか、当日のご都合がつきますように・・・)


２）　役割分担

６月の役割は下記の通りとなりました。

	役割	担当者
1	幹事	藤本さん
2	ファシリテータ	勝又さん
3	レポーター(記録等)	秋山

※　６月から、話しの脱線を防ぐ“秘密兵器”が登場します♪


３）　会場について

毎度、皆の頭を悩ますのが、「例会会場」の手配です。
今回も５人でかなり悩みました。
お名前があがったのは、P社さま、W社さま。
藤本さんが調整を行い、後日お伝えすることになりました。


４）　事務局会議

事務局会議は、MSNメッセンジャー等の利用
⇒　簡単な内容は、「Twitter（トゥイッター）」でつぶやく（フォロー）
という方向になりました。

しかし、「Twitter（トゥイッター）を使ったことが無い」という事が問題に・・・
まずは全員Twitter（トゥイッター）のユーザになる事から始めることになりました。



●　オフショア開発フォーラム　７月例会について

１）　例会の日程

まだ、１ヶ月以上も先のお話ですが・・・
７月も基本的には　第三週の木曜日（7/16）になりそうです。


２）　役割分担

７月の役割は、暫定ですが下記の通りになる予定です。

	役割	担当者
1	幹事	秋山
2	ファシリテータ	東　さん
3	レポーター(記録等)	勝又さん

●　そのほかの決定事項について

１）　フォーラムサイトの記事転載について

意外と曖昧だったので、
「基本的には転載可能だが、出典元を明らかにする事」
という方向性を改めて確認いたしました。


２）　アドセンスの設置について

Googleサイトに「Google AdSense 設置」という新機能が追加されました！
早速、フォーラムのサイドバーに設置しました。
Google AdSense 　からの収入は、会則に則り毎月報告いたします！
※　よろしければ数日に１回、広告欄を“ポチッ”とクリックしてみて下さい＾＾


３）　サイト管理の権限

サイト管理の権限が変ることになりました。

	管理者	編集者
旧・方針	勝又さん	東さん、木村さん
新・方針	全員	-

Googleサイトの弱点（バックアップが取れない）理由から、
長らく旧方針でサイトの管理が行われておりました。
しかし、サイトの更新（特にサイドバーの更新）を
よりスムーズにするために、新方針へ切り替わる運びとなりました。
※　“削除⇒保存”を行うと修復がきかないので、うっかり消さないように注意です！


４）　入退会申請の手段の追加

入会・退会の手続きをよりスムーズにするため
申請フォームをサイトに追加する運びとなりました。

《入退会手続きの利便性向上について》
●　入退会の補足追加事項
　⇒　入退会の申請が簡単に出来るようにする。

テーマはCloseできませんでしたが収穫もありました。仕様書標準書式の作成＆公開、定例単語のDB化＆公開、ブリッジSE適性判断Toolの作成＆公開といった、上海オフショア開発フォーラムとして情報を発信するアイデアの提案や、社員教育についてのコアなディスカッション等、濃い議論を行えました。

最後にお約束の記念撮影をパシャリ。

世界的エンジニアをわずか７名で囲んで交流できる贅沢なひと時でした。

詳細はこちらで。 ← すいません。勝又個人サイトです。ネタが重複するので。

中山公園そばの喫茶店で、

新メンバ、藤本さんを迎えて事務局会議が開催されました！！

事務局は、ボランティアなので、金銭的なメリットはありません。（むしろ持ち出し）

藤本さんの会社は、メディアやセミナー等でのPR効果等には無頓着とのことですので、

個人的な人脈、知名度アップに、事務局という立場を活用していただければと思います。

勉強会が開催されました。

今回の参加者は、１４名。

ファシリテータは、三度目の正直を目指す勝又、

記録・撮影は東さんです。

今回のテーマは「設計工程のべからず集」

過去の進行の不備の反省を改善するために、

今回からは、以下のような流れでアウトプットを構築していく方針です。

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

■アウトプット構築の流れ

　１．事前ブレスト・・・Web上で事前に失敗事例・悩みを投稿

　２．事例の具体化・詳細化・・・事前ブレストで提示された内容を具体化・討論する。

　３．事前ディスカッション・・・Web上で原因分析等を勧める

　４．対策立案・・・定例会で対策を立案する

　５．清書・・・事務局で清書して成果物構築

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

４月の定例会は「２．事例の具体化・詳細化」

５月の定例会は「４．対策立案」

を行います。

今回は、事前に会員のみなさまから提示された

２５件（！）について、議論しました。

記録係の東さんも熱気に引き込まれて、

何度となく議論に参加されていました。

詳細は後日。

３月から、議事録担当者がＭＶＰを選ぶことにしています。

今回は、、、、、

山口さん

が選出されました！

事前ブレストで、５件の失敗事例・悩みを提示してくれた上に、

勉強会でも多くの発言で盛り上げてくれました。

ＭＶＰのご褒美（？）として、

二次会の乾杯の音頭をとっていただきました。

今後ともよろしくお願いいたします。

これまで唯一の女性参加者であった山口さん待望の新女性メンバとして、

秋山さん

が参加されました。

これで、Ｈさんのセクハラ攻撃もへっちゃらですね。（笑

「真面目に勉強しているんですねぇ・・・。」

「勉強会と二次会のギャップがすごい。」

番外コメントとしては、

「え？飲みすぎ？まだ７本ですよ♪」

二次会からは、長瀬さん、宮原さん、■さんも合流。

到着時にはすっかり出来上がっていた、いったいどこで飲んでたんでしょう？

長瀬さんからは、浙江大学（理系で中国ベスト３の大学）の大学院で

講義したときに感じたことを教えていただきました。

『学部だとアジャイルは知らないが、

  大学院ではやっている。しかもレベル高い。』

『例えば、リファクタリングは、当たり前に理解している様子。』

『通訳に「ここはわかっているので次へ」と促された』

『日本語を学んでいるのは１２００人中６人。』

この席は、パブっぽい空気をかもし出していました。

宮原さんは「尾崎豊」の物まねで場を盛り上げてくださいました。（笑

こちらの席では、「中国人の上司って・・」をネタに盛り上がっていました。

「あるあるある！」

の連発でした。（笑

今回は、移動せずに、パーティセットを「姫りんご」さんから手配しました。

お味のほうは好評でしたが、量が多すぎたようです。

幹事としては、手配も楽なので、このスタイルを継続したいと思ったのですが、

「食べたいものを頼めないのがイマイチ」

「タバコを吸えないのがつらい」

という声がありましたので、

次回以降は、まじめに二次会会場を探そうと思います。