テストチームから開発チームを見ると。「提案する開発者」

今日は、中国に常駐しているテストチームのメンバーから開発陣の印象をレポートしてもらった。


◆開発チームの劉さんの発言
　・「今回開発しているバッチのログ出力に関してですが
　　主処理と条件分岐、処理結果のレコード取得件数をログに出力させようと思いますが
　　これでいいですか？」

◆普段は仕様書の修正がないと動かない、動けない
　・これまでであれば、ブリッジの役割を果たすテスターと日本側の設計者とのやり取りの結果モジュールの修正が必要となったとしても
　　テスター「設計者がこう言ってるから修正してくれ」では開発者は動かない
　・設計者の言質をとる、あるいは修正が必要である旨を証拠として残さないといけない
　・開発者「設計者が仕様書を修正してアップしてくるか
　　あるいはBTSに仕様修正内容を記載するかしてくれ」
　・私から見ると（ブリッジテスター目線）、「開発者は『仕様書は絶対的なもの』という考えが強すぎて融通が効かない存在」に映ることがある

◆でもそれがオフショア開発での常？？（推測ベースです）
　・設計者と比較的近い関係でやり取りできる日本の開発現場と違い、オフショア開発では仕様書（とそれに準ずる設計者の言質）がより重視される
　・どんなに急いでいたとしても、修正すべき処理内容がはっきりしてたとしても、仕様書が修正されないと動けない
　・でも設計者との距離が離れている分、開発者が慎重になるのは当然なのかもしれない
　・なぜなら、開発者の裁量を増やして実装を任せることによって設計の意図からまるっきり外れたものが実装されてしまうよりは
　　「こういう仕様で実装してくれ」と設計者に頼まれたこと以外やらない、つまり頑固なまでに仕様書を重視する姿勢の方が安全だからだ
　・開発者の姿勢に納得する部分もでてきた

◆ログ規約がない！！
　・開発者が仕様書を絶対視しているにも関わらず、今回開発しているモジュールのうちバッチのモジュールにはログ規約（仕様書）がない
　・ログ出力に関しては開発者の判断に任されるという状況
　・ただでさえ開発者は慎重にならざるをえないのに「自分の判断で出力するログを決めてくれ」というのはプレッシャーだったかもしれない

◆仕様書の追加依頼
　・必然的に実際に出力されるログはとても控えめで物足りないことが多い
　・つまり、どのような処理がされたかが見えてこないログが出力されていた
　・モジュールがリリースされる度に、出力して欲しい処理についてブリッジテスターと設計側が確認をとりながら出力処理を増やしてもらった

◆「提案する開発者」増殖中？？
　・このような背景のもと劉さんの提案があった
　・「開発者は仕様書に記載されたことをきっちり実装する、それ以上もそれ以下もない」と認識していたので、この提案には感動を覚えた
　・今回の劉さんの提案以後、開発チームでミーティングがもたれ出力するログに関する基準を設定していた
　・今後は仕様書（あるいは明確な規約）がないような場合は開発チームで同様のミーティングを行い、設計チームに提案していくことになるだろう
　・実は今日も日本の設計チームとのスカイプMTGで彼ら開発チームは提案していた
　・仕様の不備に対して修正案を複数用意していたのだ
　・しかも、図を多用したまさに「言葉の壁を越える」ドキュメントをチームで作っていた
　・劉さんの提案する姿勢は確実に開発チーム全体に広がっている
　・実に頼もしい「提案する開発者」、現在増殖中です！

「今、言っている事は絵に描けるか？」
理解しているかどうかは絵に描けばすぐにわかる。
ここでの絵とは図である。

そう言えば、この図を描くというのはとても大事なことだと思う。
日本人同士でも図を描くことでお互いの言っていることがよくわかる。

外国人同士ならなおさら図を描いて話す必要に迫られる。
言葉だけでは伝わらない。

亜才中国には内部設計チーム、テストチームに日本人がいる。
彼らは開発陣とすぐに会話ができるし、その場で図をお互いに描きながら話せる
これは開発陣と同じオフィスで働いているからで、彼らが日本にいてはこう行かないと思う。
現地に常駐している強みだと思う。そして彼らは中国亜才の社員である
だから、食事や社員旅行も共にする。
言葉や図だけでなく、こういうものも共有していないと普段のやりとりの中でも
伝わらないものだと思う。泥臭いが大切なことだ。
 
同じ釜の飯を食う、同じ湯船につかる。
そんなことに大した意味はないように感じるかもしれない。
しかし、一緒に食事をし、生活をともにすると、必ず「コミュニケーション」が生まれてくる。
このコミュニケーションこそ最も大切なものだと思う。
相手は中国人、こちらは日本人。言葉が通じないのだ。
 
言葉で伝えることができない部分は身振り手振り、そして絵や図を使って伝える。
通訳をはさめばいいと思うかもしれない。
しかし、絵や図をわざわざ書いて伝えることで、さらに伝えることができるものがある。
それは、伝えようとする気持ち、感じ取ろうとする気持ち。
一生懸命書いた絵や、オーバーなアクションを使って伝えようとすると、相手も懸命に理解しようとしてくれる。
そして、そうやって共有し合えた理解は、決してずれることがないのだ。
 
他のブログでもこの点について、言及している方がいました。
 
「ネットのコミュニケーションツールを最大限活用し、システム開発を行うというのは、一見効率的で何も問題無いよう見えますが、実はそこに最大の落とし穴があります。」

本当にそうだと思います。
インターネットという通信手段がある時代にあって、わざわざ中国に駐在してのコミュニケーションなんて、
時代錯誤なのかもしれない。
でも、メールやドキュメントで、しかも通訳をはさんでのコミュニケーションは、
感情はなかなか伝わってくれないのではないだろうか。
生の人と人との交流があり、決してずれることのない基盤が作れて初めて、
物事は前へと進むのだと思う。
 

今日は亜才のオフショア開発がどのような様子で進められているか

現場の生の声を少し紹介したい。
テストチームに報告してもらった。
彼&彼女達は、テストチームの一つの活動として精査というものを面白おかしく紹介してくれた。
物語チックになっているので少しは読みやすいと思う。見てみよう。

設計者が今日もぼやいていた。「昨日、１週間で書き上げた設計書を
開発側にリリースしたんですが、ものの２時間で叩き返された」

それはなぜか。
「精査のせいさ！」

説明しよう。設計者を苦しめる精査とは。
一言で言うと、設計書のブラッシュアップ

これは、設計書の品質の高めるためのものだが、裏読みされると設計者にとってはただの駄目出し。
設計者には嫌われるかも知れないがあえて心を鬼にして設計者に指摘事項をあげている。

一方、テストチームの余さんは、
「ここが違いますね」
とまた設計書の不整合な部分を発見していた。
また、設計者に心苦しいことを言わねばならない。


そう言えば、この精査がなかった頃、設計書を開発にそのまま渡していた。
すると開発側は大混乱。これはどういうことだと、テストチームに質問が来る。
「是澤さん、是澤さん、これはおかしいです！」
という開発側のマネジャーの劉さんから質問攻めにあった是澤さんは、
設計側への確認に追われ、テストケースの作成もおぼつかなくなっていた。

是澤さんは思った。
「なんて俺は馬鹿なんだ。」
「俺たちが設計書の不整合などを設計側に確認してから開発に仕様書を渡せばいいんだ。」
これが精査の誕生の瞬間だった。
つまり設計側にとっては悪夢の始まりだった。

初期の精査とは、DBテーブルと画面入出力項目の不整合、
例えば画面項目の最大長と対応するテーブルのフィールドの桁数が異なるとか、型が異なるとか、そういうものだった。

我々は開発側とすぐにコミュニケーションが取れる位置にいる。
つまり、中国にいるので、開発側が困りそうな部分が何かよく見えた。
そのため自然と開発側が困ることを先に設計側に確認するようになった。
最近では、抜け落ちているロジックについて指摘するほどまでに進化してきた。


精査のメリットをまとめて上げると下記になる
 

• 開発側は実装中にその都度、不整合を発見したら質問するという効率が悪いことを行っていたが、精査を行うことにより、短時間に確実に不整合を見つけることができるようになった
• 以前、QAは、開発チーム（中国人メンバー）と設計チーム（日本人メンバー）のやり取りだったのが、
• テストチームと設計チームの日本人同士のやり取りになり、翻訳プロセスが省け、コミュニケーションのスピードが速くなった
• 問題点を整理して設計チームに伝えるため、設計側も注意すべきポイントが分かるようになり、設計書の質が上がった
• 開発チームと同じ場所で仕事をしているため、開発側が困ると思われることがすぐにわかるので、あらかじめ設計側に確認することができるようになった

 

本来、開発側が質問するような事を先にテストチーム側が設計チームに確認してしまうので、開発側からは、「スムーズに開発に入れる」と大好評。
我々テストチームはバグを多く見つけることを期待されているが
それだけじゃない！！
バグの芽を未然に摘み取るのもテストチームの大切な仕事なのだ！！！！

以上、テストチームからテスト活動の一部を紹介してもらった。
熱っぽく語っているのは、日頃、周りから評価されにくい立場であるテストチームだからか、
「ブログに掲載するよ」というとここぞとばかり力を入れた報告をしてきた。

少し補足するとここでいうところの「精査」とは正に仕様書のレビューのことである。

本来、日本の開発では、製造側が設計側から仕様説明を受けるときに、

設計側に質問することがあると思うが、オフショアでは製造側は中国人、日本の製造チームほど、質問が的確に出すのは難しいだろう。

こんなところにオフショアの落とし穴があるんだろう。