障害管理 :-<
現在、巨大なシステム開発現場でさまざまなテストが並行して実施されている。しかし、その中で、障害の管理はなぜかメールのやり取りに終始している。一応簡易なBTS(バグトラッキングシステム)はすでに用意されているのだが、それが有効に使われておらず、障害が検知されるとメールで以下のようなやり取りが頻繁に行われるのだ。
- 「XXXで応答がきません。調査してくれますか？」
- 「XXXで必須項目YYYが未設定ですね。ログ添付します。」
- 「コンソールには、XXXと出ています。このケースは以下のIDでテストを実施したときの内容です。」
- 「XXXの障害は直しました。今すぐデプロイしますので、しばらくお待ちください。」
こんな感じだ。巨大なプロジェクトなので多い日にはこれだけで200通近くメールがやり取りされる。
BTSにも障害は多数上がっているが、メールでやり取りされている障害はほとんど登録されていない。リーダミーティングでも「BTSに発見者が登録するように」と周知してもらったが、まったくといって効果が無い。実際メールやり取りと電話のやり取りを見ていると1日10件程度の障害が上がっているように感じるが、登録してあるのは、自分がいれた2件だけ、という状況だ。
メールで丁寧に1日の終わりに状況をまとめてくれる人もいたりする。
- 「本日の障害は以下でした。そのうち、XXとXXはすでに修正済みです。一覧を記します。」
こんな感じで丁寧に一つ一つの障害と対応状況を書いてくれていたりする。しかし、そんな人もBTSには登録しようとしない。
いったい、なぜなのだろう。
メールで丁寧にまとめるのであれば、BTSからその日1日のリストを表示すれば事足りると思う。何度もメールに書いたりまとめたりする手間はとても面倒だと思う。それなら同じように書く工数をBTSへ登録する工数とすれば、ステータスの管理や状況一覧などが見られるのでメールや電話だけよりずっと便利だと思うのだが。
また、この巨大プロジェクトは障害をExcel一覧表で管理しているサブチームもあるようだ。しかし、Excelでの管理が面倒で、細かな障害内容やログの添付や画面イメージの添付などが必要な場合、管理が難しくなるので、BTSが普及しているのに、なぜか利用しようとしない。それでもうまく障害を管理し、状況がわかるのであればよいが、当然、相手のチームが何をしているのか、問題があるのか無いのか、修正がすんだのか、仕様を変更しなければいけないのか、他チームに影響があるのかどうかがまったくわからないのだ。それで、さらに悪循環でメールを利用して問い合わせるのだ。
本当にどうしてBTSを利用しないのだろう。なぜ、BTSを採用しているのだろう。
隣のチームのリーダに聞くと以下のような回答が返ってきた。
- 「自分が障害を発見した、とは思っていません。発見者が登録すべきです。」
- 「障害かどうかわからないから、登録していないケースが多いのでは。」
なるほど。こういうところにプロジェクトを進める文化を感じるのだ。障害を悪いことと思うとなかなかあげにくいだろう。また、障害を発生させるとなにか、問題になる(障害自体ではなくプロジェクトとして。たとえば、品質上、障害数が定義されているなど。)場合、十分障害かどうかを判定してからBTSに登録すべきだ、と考えるのだろう。
しかし、なんらか不具合の可能性があるから調査をしているのである。調査をするには時間もかかるわけだから、それはきちんと作業として認識すべきである。それを個人の中に閉じてしまうと、同じような問題が起きた場合にその個人以外が連絡を受けるとまったく同じ調査をすることになる可能性が高い。こういう作業がムダなのだ。もし、BTSにあげていれば、調査を依頼されたときに、「そういえば、同じような問題を聞いたことがあるような。BTSを検索してみよう。」となるわけだ。深く知る必要は無いのだが、何も知らないよりはずっと無駄な作業を抑えることができる。また障害かどうかわからない、というのはまず障害としてあげ、障害出なければ、調査結果だけを残しておけばよいのだ。品質管理上の障害数が問題になるのなら、「これは障害ではない」というステータスにしておけばよいだけだ。
また、上記理由からは、障害をあげることが悪いこと、という文化も感じる。確かに、障害があると、チーム間で責任を擦り付けるような流れになりやすい。そういう流れもあるので、個別にこそこそっとメールや電話でやり取りし、事なきを得ると何もなかったようにしてしまうのだ。ここにもお互いに信頼関係が築けていないチームだと、こういう裏取引のような隠れた部分が多くなるのだ。
オープンで正直なコミュニケーションを心がけ、問題はすべてのチームで共有し、問題の発生責任も個別のチームではなくプロジェクトにあるのだ、という意識が必要なのだ。
プロジェクトが遅延していると、「意識が低い」とか「危機感が無い」とか、「相手が悪い」として相手を攻める姿勢が強まってくるが、プロジェクトチーム全体で責任があるし、全体で喜びも悲しみも共有すべきなのだ。自分ができているからよい、とかそういうことはまったく関係ない。
問題の根底にお互いを尊重し、信頼しプロジェクトチーム全体として物事を考えたい。
こんなことを少しとなりのチームのリーダに話したら、
- 「私は全体主義は嫌いです。自分のチームの成果を正当に評価してほしい。責任は私たちではなく、ほかのチームです。」
こういいきられてしまった。
全体主義ではない。全体主義は、誰かが統制して強制するから全体主義なのだ。私の主張は、全体での成果が最も大事で、各チームの成果など何にもならない、といいたいだけなのだ。それでもそのリーダには根深いものがある。結局責任をどこかのチームが取らされるのが、成果主義で、その責任を自分たちのチームにだけはかぶせないようにしなければならない、という考えで進めている、というのだ。
今回は時間切れ。担当者たちの心の闇はまだまだ深いようだ。
