テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。
登場人物
プロ之 … プログラマー
テス緒 … テスター
前回、プロ之さんとテス緒さんは協力して、問題の原因が古いIE対応サービスにあることを突き止めました。しかし、IE対応サービスはすでにサポート外でサービスも停止済みであることがわかりました。プロ之さんは停止済みサービスが今後問題を起こすはずがないと結論し、テス緒さんは原因追及が振り出しに戻ってしまい途方に暮れています。
問題はどこにいった？
プロ之さんはIE対応サービスが1年以上前に終了していると聞き、自分の目でもゲートウェイが存在せずクラスター内にも稼働していないことを確認しました。テス緒さんと調べていた問題がIE対応サービスに存在していたとしても、実行されなければ今後問題になるはずがありません。修正する意味もありません。
「(完全に時間の無駄だっただろうか？)」プロ之さんは考えてみました。「(そんなことはない)」とプロ之さんは自分で答えました。調査を通じて新しく学んだことは多く、テストの考え方や観点も参考になるし、今後テストチームとコミュニケーションするときもスムーズにできそうです。「(一定の満足が得られた、有意義な活動だった)」そう結論しながら、イシュー管理システムにテス緒さんが数週間前に作ったチケットを、開発チームの担当者として「対応なし」でクローズしようとしました。
その寸前に、テス緒さんからチャットのメッセージが届きました。「ちょっと相談できる？」
プロ之さんはメッセージで返信しました。「いまチケットをクローズするところです。どんな相談ですか？」
テス緒(以下、T)「問題の他の原因について」
プロ之(以下、P)「原因は判明しました。発生した現象と完全に一致しています。他の可能性は考えられません。今後実行しないコードなのでこれ以上問題は起きません。これ以上の調査と対応は優先順位を下げるべきです」
T「そうだよね、でもおかしい気がして。話せない」
P「これまでの調査や議論は無駄ではなかったと考えています。テス緒さんにもいろいろ教えていただきましたし、有意義でした。ですが今回の問題はクローズです。いまクローズするところです。そうしないとチームリーダーにも文句を言われます」
突然背後で呼び出し音が鳴り、プロ之さんは飛び上がりました。鳴ったのは社用携帯電話で、開発チームの緊急連絡用なのでめったに使いません。プロ之さんは用心して、通話をスピーカーフォンモードにしました。
携帯電話からはテス緒さんのあわてた声が聞こえてきました。「ああよかった、番号間違えたかと思った。どうしても話をしたくって。あ、すみません、番号間違ってないですよね？ プロ之さんだよね？」
P「そうです」
T「よかった！ もうこれからどうしたらいいかわかんなくなっちゃって、リーダーにも次の作業をせっつかれるし、相談に乗ってもらえないし、プロ之さんもう話してくれないし、調べても無駄とか話しても有意義じゃないとか冷たいし」
P「そんなことは言ってません。ですが現時点ではやるべきことをやりました。これ以上は優先順位を下げるべきです。問題のコードが書かれたのはずいぶん前なので十分な調査ができる気はしません。1年以上動作していませんし…」
「1年前！」テス緒さんの大声で携帯電話が震えました。「ちょっと待ってちょっと見て日付」
プロ之さんからのチャットで大量のログが送られてきました。大量すぎて内容は把握できませんが、日付の部分を眺めると1ヶ月か2ヶ月前のものになっています。
T「見て！ IE対応サービスが1年以上動いてないのに、このログは1ヶ月前なんだよ！ データがおかしくなっているところも、最近1年以内にあったはず。だからきっとほかに原因があるはずで…プロ之さん？ 聞いてる？」
プロ之さんは考え込んでいて、聞こえていませんでした。「(あのコードは1年以上動いていない。このログを出すのはあのコードしかあり得ない。このログは1ヶ月前に、本番環境で出ている。ということは)」
「あのコードがどこかで動いている」プロ之さんは声に出して言いました。
テス緒さんは聞き返します。「でもIE対応のサービスは動いていないんでしょう？」
「動いていないはずです。それが理論的推論です。ですが動いています。これは観測した事実です。推論と事実では、必ず事実が勝ちます。コードは動いています」プロ之さんは断言しました。
2人のヒートアップしたやり取りから、新たな可能性が見えてきました。プロ之さんは調査結果から自分の結論を出しました。テス緒さんは、うまく言葉にできないもやもやを抱えながら、プロ之さんのヒントに新たな糸口を見出しました。
ここでは、プロ之さんが冷静な判断を見せています。調査結果自体は事実ですが、そこから論理的に出した結論は推論です。推論は強力な武器ですが、もしそれに反する証拠や事実が新たに見つかったら、間違っているのは推論のほうです。見つかった事実に合わせて、論理を組み立て直すことになります。
そして2人がヒートアップしながらも、相手を非難したり、萎縮させたりはしていない点にも注目できます。同じことを同じように言っても、相手によっては攻撃を受けたように感じたり、守りに入ったりして、率直な議論ができなくなる場合があります。この2人がこれまで積み重ねてきた関係性とお互いへの信頼があるからこそ、第三者から見たら激しく見えるようなやりとりでも建設的になります。2人それぞれの性格も、関係あるかもしれません。
ポイント:
- 観測した事実と論理で導かれる可能性を統合して問題を絞り込む
- 信頼関係を積み重ねているからこそ率直な議論ができる
それは人の問題で、チームの問題
ここからは後日談になります。プロ之さんはログを出力しているインスタンスを見つけ、インスタンスの内部を調査して、本来は存在しないはずの該当コードがデプロイされているのを確認しました。さらにインスタンス固有のAPI設定を手で書き換えた形跡があり、そのせいで呼び出されないはずのIE対応サービスのコードが実行されていたことがわかりました。その特定のインスタンスでのみ発生する現象だったため、これまで見落とされてきたのです。
この発見は開発チームと運用チーム両方で重大な問題として調査することになりました。その結果、2年前に大規模なリリースをしたとき、開発者が動作確認をするため一時的にIE対応サービスのコードをデプロイし、APIの設定も書き換えていたのですが、それを元に戻し忘れていたことがわかりました。作業ミスをしたのは、なんと今の開発チームリーダーだったとのことです。
対応としてAPI設定を正しく直したのはもちろんですが、このような作業ミスが起きたこと、それを今まで見逃してきたことも問題視され、対策が検討されました。開発リーダーのような優秀な人でもミスをするのだから、本番環境を直接操作するような運用は危ないと再認識され、リリース作業の自動化が前進しました。また不要なコードのデプロイ防止策として、リリースノートをテストチームと共同で書くという案を検討しています。
テストチームでもテスト観点を見直しました。ソフトウェアを動かして確認するだけでは見落としが発生するという認識から、デプロイプロセスの確認や、設定内容の確認などもテストに含めることにしたのです。こうした確認の一部は開発チームの力を借りて自動化されました。テス緒さんが「同じ内容のテストを手で繰り返すなら自動化すべき」と主張したのが採用されたそうです。
ポイント:
- ソフトウェアの問題は、誰かが「やらかした」結果なので、人の問題と言える
- 起きた問題ではなくその原因を直しに行く。問題が起きないように直す
問題を解決した！さてお次は？
いろいろな変化が起きていく中で、プロ之さんとテス緒さんは久しぶりにリアルで顔を合わせました。
T「やー、なんだか大変なことになっちゃったね。手順も変わるしツールも新しくなるし。よく、お前のせいだからな！ ってリーダーに言われるんだよ。笑いながらだけど」
P「私たちのせいではありません。タイミング良く見つけただけです。開発リーダーも少し静かになっていましたが、今は新しいことに取り組むのに忙しそうです」
T「開発リーダーさんは新しいこと好きそうだよね。でもこれが落ち着いたら、いろいろ良くなりそう。テストチームでもテスト自動化を勉強してるんだよ」
P「開発プロセスが現代的になりそうですし、DevOpsの考え方も進んでいます。良くなりそうですね」
テストで見つかった問題をきっかけとして、各チームが対策を取り、チーム間の協力も強化されそうです。失敗から学べる、優秀な組織のようです。人為的ミスを減らす工夫は、品質にも良い影響がありますし、作業の効率化にもつながります。問題への見事な対応だと言えます。
G.M.ワインバーグの著書『コンサルタントの秘密』(1990, 共立出版)に、こんな言葉が紹介されています。
第一番の問題を取り除くと、第二番が昇進する
一番の問題、いま最も重要な問題、まず解決すべき問題を無事に解決できたら、それは素晴らしいことです。しかし同時に、それまで二番手だった問題がトップに躍り出てきます。問題に対処しても問題はなくならない、また次の問題が現れるだけであるという法則です。[1]
T「ところでね、昨日こんな不思議な現象があったんだけど…」
P「テストチームのテスト自動化で、気になることが…」
2人もまた新たな問題を見つけたようです。問題は途切れないかもしれませんがひとつずつ片付ければ、ひとつずつ状況を良くしていけます。小さな問題でも大きな問題でも、根本的な原因をたどって改善のきっかけにできます。こんどの問題は簡単なものでしょうか、チームやプロダクト全体を巻き込むようなものでしょうか、はたまた…？
ポイント:
- 問題を解決しても問題はなくならない。次の問題が登場する
- チームの品質とプロダクトの品質を両方とも改善していく
本連載は今回が最終回となります。最後まで読んでいただき、ありがとうございます。
[1] 書籍ではワインバーグが13歳の時、スーパーでアルバイトをした話が紹介されています。そこで、野菜売場でルタバガ(カブに似た野菜)の売れ行きがとても悪いことに気づきました。野菜売場責任者のルウディーが売場スペースを整理しようとして、ワインバーグになにかアイデアがないか聞きました。ルタバガを減らすのはどうかとワインバーグが答え、ルウディーはその案を喜んで採用します。ルウディーはルタバガを片付けてから、こうワインバーグに聞きました。
「で、ルタバガの次は何だね」
問題をひとつ片付ければ、次の問題が登場します。おまけにそれも片付けるよう期待されてしまうかもしれません。これが「ルウディーのルタバガの法則」です。
