縦割りチーム :-<
- 「マージを終えたら、必ず手動で全件テストを実施し、結果を履歴に記述すること！！！守らない場合は個人的に注意します。」
我々は構成管理にCVSを使っているのだが、大規模開発のため、それぞれのテスト用にブランチを分けている。で、特に重要なブランチへのマージについては、個人のPCから直接マージする行為を禁じていて、ビルド専用マシンでマージしなければいけない、というルールを作り運用している。上記コメントはこのビルド専用マシンに必ず表示されている文言だ。
重要なブランチへのマージや、マージ後の手動テスト(自動化は行っていない。)はビルド専用マシンで行わなければいけない、というのは全員で了解済みなので特に問題は無いのだが、上記コメントからはプロジェクトに望む姿勢が明確に現れているように思う。
我々のプロジェクトは、プライマリSI会社の元に作業請負で参加している十数名のサブチームで構成されているわけで、プロジェクトの主導はプライマリSI会社の社員たち、という状況だ。そのため、ある程度、プライマリSIの社員たちは作業を指示する側、我々は作業を受ける側、という感じになっている。で、そこのプライマリSIの社員が少し怒っているわけだ。
- 必ず、マージ時には全件テストの実施と結果確認をし、それを履歴に書け、といっているのに守らない人がいる。
確かに、自動化されていないブランチなので、マージやコミットした際には全件テストが必須なのはわかる。しかし、それが守られていないので、怒って命令しているのだ。
しかし、私はこのテキストに問題を感じている。それは以下のような点だ。
- プライマリSIの社員は我々をあくまで作業要員としてしか見ておらず、プロジェクトを共有するチームとは思っていない。自分たちの仕事をメンバに作業をやらせ、監視することだと考えているフシがある。
- 手動で全件テストを行っていないのには理由があるはず。その理由を聞こうともせず、「履歴を書け。書かなければ罰する。」という態度はどうなのだろう。
確かに、だれかが指示をしそれを受けて作業をする、というやり方は一般的だし、いくらXPなどのアジャイルを実践しようとしていても、個人の中には命令される喜びを感じる人もいるのは事実だ。なので、指示をし、作業をやらせる、という状況もある程度は許容しよう。しかし、これは全員に同じように命令を発動し、全員が従わなければ許さない、という言い方だ。実際私のようなひねくれ者は、この発言を見るたび、わからないように履歴を書いたり、無視してやろうか、と思うことがある。明らかに、プライマリSIの社員は「自分が雇い主。雇い主の命令に従うのは当たり前。」という概念が染み付いており、いくら「一緒に走りましょう。」とか「みんなで成功を勝ち取りましょう。」といっても言葉面しか理解できないのだろう。そういう縦割り組織の概念しか無い人にはなかなか「チームで」という言葉も「リーダとそれ以下」としか考えられないような気がする。みんな表面は中よさそうな顔をしていても、こういう発言を最も目立つ箇所に書いておく人には注意しなければいけない。何もその人が悪いわけではないのだが、私の価値観の「チーム一丸となって」という概念が伝わりにくい気がするのだ。*1「XXをやれ。いわれたとおりに動け。それ以外考えるな。あとはオレが何とかするから指示通り動け！」ではうまくいかないのがわかっているのだが。
コミュニケーションが重要とよく言われるが、こういう態度がコミュニケーションを阻害していることに気づかねばならない。実際、最近、この全件テストを実施していない人がたくさんいることがわかったとき、以下のような会話がなされたのだ。
- 社員B：「おい、社員A。ビルドで全件テストがぜんぜん実施されていないぞ。」
- 社員A：「本当ですね。こういうのって誰かがやらなくなるとみんなやらなくなるんですよね。」
- 社員B：「困るよ。ちゃんと指導してね。」
- 社員A：「はい。」
- 私：「(内容が聞こえてきていたので)全件テストを流さないのは理由があるのでは？実際、テストを実行すると20分はかかります。その間、ずっと待っているのは苦痛です。」
- 社員A：「20分もかからないよ。5分ぐらいだよ。そのぐらい待てるでしょ。」
- 私：「もし5分だとしても、5分も待つことは苦痛です。*2ほかの作業に入ってまた5分後に確認に来るのは大変です。メンバはそう思っているんじゃないでしょうか。」
- 社員A：「大事なことなんだからそのぐらい守らなくてどうするの。みんな意識が低いんじゃない？」
- 私：「できないのは理由があるはずです。なぜできなかったのか、メンバに聞いてみたらどうですか？」
- 社員A：「そんな必要はありませんね。甘えでしょ。」
- 私：「では、マージ後担当者が毎回テストをするのでなく、定期的にたとえば、帰社時に当番が実行するのではどうですか？」
- 社員A：「(聞いていない。社員Bに向かって）徹底させます。ビルドマシンに付箋を目立つように貼っておきました。本日の定例ミーティングで口頭でも注意しておきます。」
- 社員B：「了解。ちゃんとやらせてね。」
こういう会話が先日あったのだ。この会話からもメンバ間の信頼やチーム内の役割に対する考えが明らかになっている。こういうやり取りがあると、普通のメンバだったら「どうせ言ったってムダなんだ。じゃ、言われたとおりにやればいいのね。」という感情に走ってしまい、最低限の仕事しかしなくなる。こうなるとどんどんプライマリSIの社員が作業指示を出し切れなくなり、ボトルネックがそこに発生してくる。
それにメンバは日々忙しく作業をしていて、その中で自分なりに優先度を見極めて作業をしているのだ。全件テストを実行するより、ほかの作業が優先度が高いと思っているから実行していなかったのだろう。実際、全件テストでエラーが出ることはまれだし、1日に何度もマージするときは、そのつど行うのは面倒だし効果的ではない、と感じていたのだろう。ここで重要なのは以下だと思う。
- メンバの意見を聞くこと。彼らにしかわからない状況がある可能性もある。
- 優先度を明確にしてあげること。ここでは、全件テストを確認するほうが、現在開発中のモジュールを完成させるより優先されるのならそうすべき。
こういう点を抑えてあげてメンバと対話しなければいけない。しかし、最も重要なのは
- お互いに信頼関係を築いたチームのメンバ同士になろう。
と意識することだ。プロ野球のようにある程度パターン化し役割も明確化でき決められたルール内だけでの話なら縦割り組織的やり方もあるかもしれないが、システム開発の現場は複雑で難解であり、しかもほとんどがうまくいかない状況では、このような縦割り組織的運用では成功を勝ち取ることができない。少しずつでもこのチームもそういう縦割り体制から脱却させるために私には何ができるか、を考えていかなければいけない。
では、私ならこの問題にはどう対応するか。おそらく朝会で以下のように話を進めるだろう。
- 私：「問題ですが、ビルドマシンで全件テストが実施されないことが多いようです。問題が複雑化する可能性が高まるので問題だと思っています。」
- メンバA：「それは、時間がかかりすぎるからです。」
- メンバB：「ほとんど全体にかかわらない部分なので、自分のサブプロジェクトのみテストを実施しました。」
- 私：「なるほど、理由がありそうですね。ではこの後二次会で確認しましょう。」
