問題を隠す文化 :-<

以前、こんなことがあった。

結合テストに入る予定が1ヶ月近く遅れており、非常に混沌としていた。ただ自分のチームの作業は終了しており、接続先の準備が整い次第いつでもテストに入れる予定だった。もちろん、待つだけでは意味が無いので、その間は接続先のチームの作業をしており、メンバのほとんどが、土日無しで働いていた。プロジェクトの成功のために、身を粉にして働いていたつもりだ。別に売り上げも増えない状況で赤字を出しながらの作業となっていた。(孫請けとして自社から10人程度参加していたのだ。)もちろん、自分たちのチームは悪いわけではないが、遅れているチームがあれば、そちらをサポートし、一刻も早くテストを行ってプロジェクトを成功させなければならないと、必死で作業していた。

ところが、ある日、進捗会議で私のチームに対する批判が出て、それを担当マネージャが私に伝えにきた。というのも、結合テストに入れないため、もう片方のチームと先行して疎通テストを行っており、そこでの障害件数などを報告していたことが問題だったようだ。要するに、「結合局面で障害が多いのは、どういうことか。オペミスが多いと報告があったが、たるんでいるんじゃないか。」と言われた、ということだった。

こちらとしては、困っているチームのサポートを最優先し、一刻も早く、結合テストに入ることが可能なように、サポートをしてきた。また、サポートをしながら、接続できる部分は先行で疎通確認を行っていたのだ。(実は、これはマネージャからの指示だった。)週40時間労働なんてどこへ行ったのか、かなり無理をしてメンバ全員で作業してきた。その努力に対し、「たるんでいる。」という発言はいったいどういう発想をもったら言えるのか、理解不能だった。

落ち着いて考えてみると、この発言にはいろいろな問題があっ他と思う。

• 問題１：一生懸命努力していたが、その努力を認めようとはせず、数値だけで物事をマネージャが判断していた。

これは、いつも自分のチームだけはスケジュールどおり進捗をあげていたことに起因するようだ。そして私が書いた報告書自体も毎週ほかのマネージャから全体に伝えられていたので、私のチームの状況がよく伝わっていなかったようだ。つまり、ほかのチームが皆忙しく作業をしているのに、私ののチームだけは順調に進んでいると簡単に報告してくるのが許せなかったのだろう。つまり「みんな大変なんだから、あんたたちももっと苦労しろ。」と思い続けていたのだろう。だから、我々が250時間から300時間/月も働いているのに、それに気づかず、「たるんでいる。」という発言につながったのだろう。このあたりは、私とそのマネージャとの間にいる担当者からもう少し詳細に状況を伝えてもらえれば、改善したのだろう。
まあ、この件は我々の作業が全体によく見えていなかったため感情的な問題になっていただけで、まあそれほど大きな問題ではない。単なる誤解だ。(ただ、自分がマネージャだったら、こういう発言は絶対してはいけないと改めて認識した。言われた立場としては、不愉快千万なはずだ。事実、私も最初は不愉快だった。)

• 問題２：結合テスト局面(まだ入っていなかったが)で多くの障害が出るのは問題である、と考えている。

これはウォーターフォール時代からの流れで、障害が後工程で発生することは悪いことだ、という考えに起因しているようだ。私は、

• • 問題はなるべく早く見つけよう。
  • 細かな問題も、ドキュメント不備などの理由が隠されている可能性があるため、ナレッジとして管理しておこう。

という考えで進めてきたので、早めに障害があがり、インタフェイスの不具合などに気づくことができたので、よかった、と思っていたのだ。しかし、時期的には結合テスト局面で平気で多くの障害をあげるのは大きな問題のようだった。マネージャたちの気に入ったやり方は以下だ。

• • 設計段階で、問題はなるべくつぶすべく、十分な時間をかけ、検証する。
  • テスト時には、設計で問題を解決していたので、問題は多くは出ない。だから品質が高いといえる。

これだ。しかし、こんな理想的に進むわけが無い。このモデルの問題は、

• • 設計段階で十分な時間をかけ、検証をする。

という点だ。テストをすれば1日でわかる問題も、設計書をしらみつぶしに眺め、同じ問題に気づくためには3日眺めなければならないかもしれない。しかし、テストの段階で問題が発覚するのは悪だと考えてしまうのだ。なので、設計はさらに重要で、もっともっと厳密な設計基準やレビュー基準を設け、それを満たさなければならない、と考えるのだ。そういう考えを進めていくと、問題はどんどん複雑になっていく。

• • 当然、時間がかかる。作業もつまらなくなる。細かなミスも許されないという文化になる。
  • 問題がおきることを悪いことと考えるため、テスト時に問題がでることがストレスになる。
  • 問題がおきることを悪いことと考えるため、問題を隠そうとする。
  • 問題がおきない、という計画に基づくため、問題がおきると対応する時間的な余裕も精神的な余裕も無い。

大事なのはいかに効率よく、高い品質を実現するかだ。そのためにテストは必須だし、テストばかりを繰り返すというのが最近の流れのようにも思う。早い段階でテストを実行し、それを繰り返すのだ。だから問題がおきることは当たり前だし、早く問題が起きることはよいことだという文化が広まる。問題がたくさんおきることを想定しているからストレスもたまりにくい。
もちろん、いい加減な設計で、問題が多く、繰り返しでも対応をいい加減にしてそれを繰り返していてはだめなのは言うまでも無い。設計基準の品質のおとしどころは重要だということだ。あまりに基準が低ければ、いくらイテレーティブに開発しても、だんだん理解不能なモデルになることも多いだろう。だからといって完璧なモデルを設計段階で必ず作り上げなければいけないわけでもないのだ。なので、ある程度よし、と思える段階でテストをし、また設計を見直し、またテストをするのだ。この繰り返しが高い品質を生むはずだ。

最近でも、このような価値観のプロジェクトは以外に多いのではないだろうか。少しずつ、このような価値観を変えていきたいものだ。