ミス :-<

まだまだ不十分ではあるが、結合テストが始まり、徐々にサブシステムが合流しつつある。しかしテストは非常に遅れており、ありえない状況ではあると感じながら、日々作業を続けていたが、単純なミスを連発してしまった。

よくある話とは思うが、テストモジュールのバージョン違い、配備漏れなどだ。確かに、単純なミスで防げるとは思うが、何十回と配備を繰り返しているとどうしても漏れやミスも出てくる。また、極度に慎重に確実に作業をすれば防げるかもしれないが、ある程度急ぎの状況で、テスト継続を速やかにするために、あわてて配備をすることもあった。そういう中でのミスだ。

しかし、単純ミスであればあるほど、他のサブシステムの人たちは怒りが収まらないのか、非常に風当たりが厳しくなってしまった。こういうのは気持ちの問題だから、難しいのだが、自分のところでミスがあると、すべてのテストがとまってしまうのでインパクトが大きいのだ。ある意味、ビジネスの世界ではペナルティとして当然と考えられるのだろう。

で、問題分析と対策をせよ、と言われた(正確には言われる前にわかっていたので、先に書き上げておいた。)ので対策提示書を提示した。

そこには、

• 該当サブシステム責任者の作業時間を延ばす。
• 他システムのサポートより、自システムを優先する。
• スピードより、確実な作業を行う。

という内容を書いたところ、了承を得た。ひとつひとつ説明をすると

• 作業時間を延ばす

というのは、マネージャとしてもあまり強制する気はない、とのことだった。確かに、強制を執行する立場になればいやなものだろう。しかし、気になる言葉ももらった。「プロ意識が欠けていて、それで解決できるのならお願いしたい。」ということだ。同じプロジェクトのチームのメンバとして信頼関係がなりたっていなければプロジェクトは失敗する確立が高まる。そういう意識が少しでもあるのだな、とも感じたので、これは実施することにした。

• 他システムのサポートより、自システムを優先する。

もともと他チームに比べれば進捗が良かったので、他のチームをずっとサポートし続けていたのだ。しかし、これをやめ、余裕があるのなら、自システムの更なる理解(実は、昨年度の改造で引継ぎなのだ。)を深め、内部テストを充実させる、としたところ、これも受理された。もともともし、2つのサブシステムがあり、

• • Aサブシステム：80点
  • Bサブシステム：60点

という品質だった場合、私はBサブシステムを80点にあげることを優先させたい。そして早く結合させテストを実施したい、と考えていた。しかし、このプロジェクトは、余裕があるなら、他に迷惑をかけないよう、自システムをブラッシュアップすべき、という考えだ。全体の会議でも、まだまだテストに参加できないチームもある中、もうひとつの余裕があるチームは「ドキュメントに不備があるので、直しています。」という報告をしていた。その報告を受けたマネージャも「ドキュメントは大事だ。よろしくお願いする。」と話していた。

どうもこの辺も私と考えが違う。確かにドキュメントも重要だが、結合テストに参加すらできていないチームがあるのであれば、そちらをサポートすべきだろう。ドキュメントも無くて困るものは作成しておく必要があるが、きれいな書式で納品物を作る作業は必要ない。そんなことより、まずプロジェクト全体で動くソフトウエアを作らなければいけないのだ。

ここは自分のサポートチームのマネージャも同じように、自分自身のチームを完璧に仕上げてからサポートに回るべき、という考えで何度か意見が対立していた。いろんな局面と考えがあるだろうが、それでよいのだろうか。

• スピードより、確実な作業を行う。

これはある意味、そうかもしれない。ひとつのミスが数時間のチーム全体の遅延になるため、確かにストレスはたまる。今後は確実性を高めていきたい。

で、一番言いたいのは、「作業時間を延ばす。」という対応だ。私はそんな対応がよいなんてこれっぽっちも思っていない。しかし、システム開発は根性でなんとかんる、と思っている人がこのプロジェクトには多いように感じる。また「プロ意識が低い」と他人を批判する人も数多くいる。で、そういう人たちに「もっとコミュニケーションをとりながらやりましょう。無駄話をしながらぐらいの余裕がないと、コミュニケーションもミスが多くなりますよ。仲が良くないと、どうしても漏れや勘違いも増えますよ。」と言ってもまったく同意はしてもらえないだろう。いつも思うが正面からこういうことを言っても共感も得てもらえないし、かえって反発を招くだけだ。それに今回、ミスをした本人が言うにしてはあまりに、無責任な発言にも聞こえてしまう。

• ミスを糾弾する姿勢を継続すると、こういう厳しい状態になりますよ。

とだけ、言いたいのだ。ミスをミスとして許容し、次への対策を考える、そして対策が無い場合もあることを考慮すべきだ。ミスはなくならないし、なくすために必要以上の工数をかけるべきでもないのだ。もちろんプロジェクトによってこのあたりの価値観は異なる。ひとつのミスが人命につながるようなシステムなら、十分すぎるぐらい慎重にならなければならない。たとえば、原発のソフトウエアの現地テストなどでは失敗は許されないだろう。ただ、そんなシステムはめったに無い。

また、こういう問題がおき、心に余裕がなくなり、チームメンバが苦しい思いばかりになっていることも問題だ。現実的に根性だけでは無理なこともあるのだ。そういうときに、何をすべきかをマネージャなら考えていきたい。具体的には機能の縮小、段階リリースだ。

今回、ミスの責任を取る形で、いろいろ対策を考え、認められたが、直近のマネージャとしては「扱いにくい奴だな。」と感じているのかもしれない。ただ、プロジェクトを成功させるためにはどんなことでもやらなければいけない。それがたとえ自社の利益と離れていようとも、私は成功をしなければなんにもならない、と思う。自社だけ被害を免れればよい、という考えではなく、全員で成功を勝ち取ることを考えていきたい。

いいたいことが山ほどありすぎて、うまくまとめられませんでした。