◯コードの共同所有のやり方
共同所有をすると品質向上、リスクの低減、チームの自己組織化、メンバの安心度につながるが、どうすれば実現出来るのか。

最初は物理的な共有、svnやgitなどのツールの活用がこれに当たります。
次は知識の共有、ペアプロやレビュー、TDDなどの取り組みがこれに当たります。
最後が責任の共有、リファクタリングの実施やCIがこれに当たります。

単にコードを共有しましょうというよりも段階を見せて、効果を説得しないと駄目ですね。社内で使わせていただきます。

◯オフショアで成功するコツ
工程ではなく、機能で委託する。機能単位で責任を持ってもらうことが出来る。
例えばテスト工程だけオフショアに出すと、高い確率でレベルが低い人材が割り当てられる。

アメリカではオフショアをかなりやめているらしい。5割から6割を国内に戻したらしい。結論としては「オフショアはうまく行かない。」という認識が広まっている。(ハーバードビジネスレビューで見たとか?)
オフショアするのは企業が重要視してないところ、テストをオフショアする企業は結局「テストを軽視している」ということ。

あとは人が辞めてしまうので、仕組みにノウハウがたまるようにしないとだめだとNEC誉田さんからコメント。
品質の期待値をきちんと伝えるのも効果があるらしい。

◯オフショア開発におけるテスト改善
事例発表でTISの鈴木三紀夫さんが「890個のテスト観点リストと745個の不具合推測リスト」を作成したと話していた。こんなにたくさんのリストを見きれるのかという疑問がすぐ頭をよぎるが、全部読むことが重要ではなく「作業者に頭を使わせることが大事」とのこと。数が膨大だと作業者がコピペで済ませることができなくなり、担当者なりに頭を使う必要が必ず生じる。

・・・

基調講演と招待講演は大変タメになりましが、その他のセッションは役に立ちそうなものと、役に立たなそうなものと結構はっきり分かれました。
参加費は2日間で8000円ぐらいでしたが、値段的にはこんなものでしょう。学会の延長線上と思えば。
でも来月同じ雅叙園で開かれるデブサミを考えるとデブサミのほうがおすすめかも知れません。

来年は誰か他の人に行ってもらおうかな。

NECの誉田直美さんが、自信が考える品質のあり方について語った90分のメモです。

・・・

誉田さんが考える「王道を行く」とは本質を理解した上で、決意を持ち達成に向けて行動すること。
手段ではなく目的、手抜きではなく効率化、新たな気持も大事だけど先人の知恵に学ぶ。
品質のみを追求している訳ではないが、品質を追求すればコストも納期も改善出来ると誉田さんは考えている。

＜事例１＞
自社が関連する単体テスト実施状況を調査したところ、単体テストをきちんと実施しているプロジェクト(限界値とか、テストの組み合わせを考慮して普通にやる)は単体テストで手抜きをしている or 単体テストをしていないプロジェクトと比較して出荷後のバグが38%少なかった。きちんとテストを実施すれば62%も取り除けたのに(きちんと単体テストをしても38%も残るのかという見方もできるけど・・・これは私の主観)

＜事例２＞
オフショアの品質を改善するために、海外子会社をかなりの労力をかけて教育した。具体的には数値目標を立て、プロセス・基礎開発技術・マネジメント・日本語語学力に国内同等レベルを求めた。結果として現地管理職の認識も代わり、改善が進むようになった。(最も、事例としてあげた中国の工場は管理者が転職してしまったらしいんだけど・・・)

＜事例３＞
開発案件や組織力が似ている組織Aと組織Bからいろいろなデータを取ってみた。Aを100%としたとき、Bの全工数は106%程度、ただしレビューやテストは50%前後だった。1000行あたりのバグ件数はBはAの80%。全バグ数に対する上流工程までのバグ摘出率はAとBはほぼ同じ。Bのテスト項目数はAの約半分だった。

組織Bは「プロセスを改善すれば工数やバグ数は減るはず」と解釈し、そのように取り組んでいた。だからテスト工数がAより少なくなり、そのような統計結果も出た。でも市場で出たバグを見るとBの方が品質が悪かった(数は変わらなくても、Bの方が長期間にわたってバグが出続けた!)。結果としてBのほうがAより2倍以上品質が悪いという調査結果が出た。

データを分析すると組織の取り組み方の違いが現れた。Bの組織は目標の達成が主眼となってしまい、数値目標を達成したらテストを終えてしまっていた。本当はプロジェクトごとに差が出るものなのにそれがなかった。基準値順守が「形骸化」してしまった。社内のベストプラクティスを組織Aと組織Bに適用しても組織Bでは効果が得られなかった。結局組織Bはルールだから実施していた、テスト時に担当者が頭を使っていなかった。

誉田さんがまとめのスライドに載せていたのは「何のためのプロセスかを常に考える土壌作り」が必要とのこと。形だけを真似ても成果は得られない。

・・・

目から鱗でしたね。ソフトウェアの状態をツールやメトリクスを使って見える化し、データをノウハウとして蓄え、組織として横展開できれば品質は今より良くなるはずだと思っていましたから。まさに組織Bの人間です。
プロジェクトごとに性格や条件が違うことに気づき、もっと頭を使わないと駄目ですね。自社の品質改善を考えていくに当たり、大きな宿題をもらった講演でした。

1/28と1/29に目黒雅叙園で開催されていたJaSST’10に行ってきました。色々学んだことはあったのですが、まずは基調講演の振り返りから。基調講演はJohannna Rothmanさん、Manage It! 現場開発者のための達人式プロジェクトマネジメントの作者さんですね。

開発者が行う改善は55%だが、マネージャーは65%の改善に貢献出来る。目的を持って人をまとめるのがマネージャーの仕事、開発に集中出来る椅子とかを揃える以外にに良い人間関係を築くことが大事。

効率的なマネージメントのやり方を17の法則としてまとめた。以下原文ママ。

1. Know What They Pay You Do
2. Plan the Work: Portfolio Management
3. Accept Only One #1 Priority at at Tme
4. Commit to Projects After Asking Your Staff
5. Hire the Best People for the Job
6. Preserve Good Teams
7. Avoid Micromanaging or Inflicting Help
8. Treat People Individually and With Respect
9. Meet Weekly with Each Person
10. Plan Training Time in the Workweek (Plan Training Time Each Week for Yourself)
11. Give Credit Freely
12. Fire People Who Can’t Do the Work
13. Emphasize Results, Not Time
14. Admit Your Mistakes
15. Recognize and Reward Good Work
16. Take a Vacation
17. Manage Yourself

以下Rothmanさんの発言メモ、一部意訳があるかも。

1. 業務上の肩書きと実際の職務内容、使命があっているか確認すること。
3. 優先度1のタスクは常に1つしか無いはず。複数あるのは何かがおかしい予兆。
4. タスクはチームで決めよう。
5. 雇うべきはgreatな人材、それは必ずしもチームに今いる人材とは違う。タイプ(性格/個性)の異なる人を集め、アイデアを生む。
6. 良いチームは残そう、解散するとチームが備えていた力が失われる。
9. 信頼できる関係を築くなら1対1がいい。直接のフィードバックもし易い。
13. 作業時間に比例して作業内容も増える。1週間40時間で仕事を終えられるよう作業を組むのもマネージャーの仕事。

Pragmatic Programmerシリーズの1冊を書いているだけあって実用的で、口先だけの話をしている人ではないのだなと聞いていて感じました。