２４時間以内

今週の水曜日は、約３ヶ月ぶりに会社に泊まり込みました。

その日は、クライアント先で、お客さんの担当者Ｂさん、私、後輩の３人で
システムテストを実施していました。

システムテストとは、プロジェクトによって意味合いが多少異なるものの、大体が、
・実際の運用を踏まえた、一連のシナリオに沿ってテストを実施するもの。
・実運用と同量のデータを扱うことがほとんどで、
　「クライアントの実際の運用に沿って、システムを操作した場合、
　　システム的に問題が発生しないか？」といった観点でテストを行う。
といったものになります。


【１．障害発生】

　テストは順調に進んでいき、午後３時を回った時点で、その日の予定を達成
　した状態になりました。

　その日は、前プロジェクトのメンバーで、新年会を行うことになっていました。

　「この調子なら、余裕で間に合うな～」、なんて考えていました。

　まだ時間があったので、明日行う予定のテストも実施することになりました。

　そこで不具合が発見されたのです！

　即座に解析しましたが、クライアント先で対応ができるようなものではなく、
　腰を据えてプログラミングしないといけないような、一筋縄ではいかない不具合。

　一旦、開発現場に戻る必要があります。

　新年会どころじゃない状況になってきました。

　システムテストは一連の流れに沿って行うテストのため、シナリオの途中で
　不具合が発生した場合は、一般的に、その不具合を改修しない限り、先に
　進めてはいけないものです。

　その日のうちに、不具合を改修しなければ、明日からテストを実施する
　わけにはいきません。

　新年会はコース料理のため、もう時間的に、キャンセルはできません。

　後輩に「開発現場に戻って、キミが対応できる？」と聞いてみると、
　「いえ…、僕にはできません…」と、返ってきました。

　ということで、私が開発現場に戻り、対応することになり、
　新年会欠席の電話を幹事さんにしました。（お金は翌日、幹事さんに払いました）

　正直言って、後輩の技量から、この対応は難しいと思っていました。

　だから、「いえ…、僕にはできません…」という答えが返ってくるのは、
　ある程度想定していましたが、本当は、
　「自分にはちょっと難しいです…。でも、ふくたまさんも一緒に開発現場に
　　戻ってフォローしてくれるなら、何とかやり遂げてみせます。
　　何より、自分が担当した機能で起こった不具合なので、自分が最後まで
　　責任を持って対応します。」
　といった、答えだったら、とても嬉しかったです。

　そういう意識を持つようになるというのが彼の課題だし、
　彼にそういう意識を持たせるよう仕向けるというのも、私の課題だと思っています。


【２．瑕疵障害とは】

　一般的なシステム開発は
　１）プログラミング
　　↓
　２）単体テスト
　　↓
　３）結合テスト
　　↓
　４）システムテスト
　の流れで進んでいきます。

　（実際には、クライアントによる５）運用テストがあります）

　改修ボリュームにもよりますが、１）プログラミングで実際にソースを改修した
　際には、必ず不具合が埋め込まれます。

　それが当然なので、
　２）単体テスト　→　３）結合テスト　→　４）システムテスト
　というように、３段階に分け、綿密なテストを行っていき、
　不具合を０に近づけていくというのが、テスト工程の役割となります。

　それぞれのテストには、役割があり、
　２）単体テスト…機能内の品質を保証する
　３）結合テスト…機能間の品質を保証する
　４）システムテスト…機能間、かつ、実運用に耐えうる品質を保証する
　となります。

　今回発見された不具合は、機能内の操作で起こりうる不具合のため、
　本来であれば、２）単体テストで検出しなければなりません。

　それが、４）システムテストで検出されたということは、
　２）単体テストのやり方に問題があったということになります。

　実際には、２）単体テストのテスト項目に、その不具合が起こる操作を抽出する
　ことができていなかったため、「テスト項目抽出漏れ」が、不具合の摘出を
　遅延させてしまった理由となります。

　私が「開発現場に戻り、今日中に対応する。」と、後輩に言った時、
　後輩は「そんなにすぐに対応する必要があるのでしょうか？」と聞いてきました。

　システム開発の世界では、瑕疵（かし）という言葉がよく使われます。

　瑕疵とは、簡単に言ってしまえば、「欠陥」であり、
　瑕疵が発生した場合は、普通は無償で対応しなければなりません。

　４）システムテストで摘出すべき障害であれば、瑕疵にはなりません。
　なぜなら、２）単体テスト、３）結合テストのテストケースでは
　気付けないものなので、４）システムテストで不具合が露わになるのは
　当然だからです。

　瑕疵にはなりませんが、折半（自社とお客さんで費用分担をする）になることも
　ありますが。まあ、それは障害内容と、交渉次第かな。

　今回は、クライアント先で不具合の原因を解析した時点で、
　２）単体テストのテストケースがしっかりしていれば、
　４）システムテストまで、摘出を遅延させることはなかったということが
　　　明白でした。

　だから、今回の障害は、完全に「瑕疵」になります。


【３．信念ができあがる時】

　私が名古屋で２年間システム開発をやっていた時、お客さんのＣ部長から
　「瑕疵障害は２４時間以内に対応するのが当たり前だ！！」と
　厳しく言われていました。

　「お前らの埋め込んだ不具合のせいで、テスト進捗が遅れてしまう。
　　即時改修して当たり前だ。」ということですね。

　その時、私は、「なんて厳しい人なんだ…」と思ってましたし、
　「なんで２４時間以内に対応しなければならないんだ」、なんて不満に思って
　ました。

　でも、時が経つにつれ、私は
　「瑕疵障害は２４時間以内に対応する」という考え方を、当たり前と思うように
　なっていきました。

　逆の立場であれば、不十分だった設計、プログラミング、テストケースで、
　不具合対応が後工程にずれ込み、それが発見された場合、後工程の流れを
　止めることなく、対応してもらわなければ、後工程を担当する人間にとって
　非常に困ることになると、考えるようになっていったからです。

　最終的には、
　「瑕疵障害は２４時間以内に対応する」というのが、
　『自分の考え方』から、『自分の信念』に変わっていきました。


【４．私が「２４時間以内」という信念を大事にする理由】

　前回、１年４ヶ月続いたプロジェクトでも、私は、
　「瑕疵障害は２４時間以内に対応」という自分の信念を決して曲げることはなく、
　その通り実行しました。

　瑕疵障害が発生すれば、泊まり込みだろうが、徹夜だろうが、最大限自分が
　できる限りのことをしてきました。

　障害内容によっては、２４時間以内に対応するということが、物理的に無理な
　こともあります。水平展開が大変なケースもありますしね。

　でも、大事なことはなんなのかというと、それは、お客さんに対して
　『誠意』
　を見せることだと思っています。
　発生した障害に対して、真摯に向き合い、責任を受け止め、１００％の対応を行う。

　そういう姿をお客さんは見ています。

　瑕疵障害であっても、一生懸命対応していれば、「責任感がある」と
　捉えていただき、むしろ評価が上がることもよくあるのです。

　そして、もう一つ大事のは、
　『覚悟』、『決意』が蘇るということです。

　私個人の話ですが、
　私はシステム開発に、自分の全てを賭けています。
　この仕事で、頂まで昇るということを決めています。

　だから、一切甘えはしないし、妥協もしません。

　不具合を埋め込むことは、悪いことではないのです。
　当然のこと、当たり前のことなのです。

　摘出すべきテスト工程で不具合を検出できたなら、それはむしろ喜ばしいこと
　であり、誇るべきことです。

　テストケースがしっかりしていた、テストケースの品質がよかったということに
　なりますからね。

　でも、今回、そうではありませんでした。

　本来、摘出すべきテスト工程で不具合を検出できずに、２つも後のテスト工程で
　それが検出されたのです。

　だからとても恥じるべきことです。
　技術者として。
　この仕事に全てを賭ける人間として。
　この仕事で頂まで昇ることを決意している人間として。

　私も人間なので、つい甘えたくなる時はあります。
　でも、「２４時間以内」という自分の信念を思い出すと、
　システム開発に自分の全てを賭けるという『覚悟』、
　システム開発で頂まで昇るという『決意』が揺るぎないものになっていくのです。

　そして、私は今日も全力で、また、真剣に、システム開発に従事することが
　できるのです。


【５．暖かいお言葉】

　私は夕方６時半に、開発現場に戻ってきました。

　思った通り、対応は難しく、慎重にプログラミングを進めていかないと、
　他に不具合を埋め込んでしまうという、非常に神経を使う作業となりました。

　プログラミングをやっている途中で、涙が出そうになりました。

　情けない…

　あれだけ品質を向上させる対応をしてきながら、この不具合を単体テストで
　検出できなかった。

　自分はいったい何をやってきたんだろう…

　情けない…

　そんな思いのまま、夜９時半にプログラミングとテストが完了しました。

　お客さんの担当者Ｂさんも開発現場に戻ってきてくださり、レビューをして
　いただきました。

　夜１０時、レビューが終わり、明日からシステムテストを進めていける
　状態になりました。

　Ｂさんは私を気遣い、
　「今日はもう上がって、休んでください。」と、言葉をかけてくださり、
　私は、「ありがとうございます。」と答えます。

　そしてＢさんは、私がいるフロアーから引き上げていきました。

　Ｂさんには申し訳ないのですが、私は家に帰る気は一切ありませんでした。

　対応が終わっても、障害票を作り、原因や品質強化策を考案したり、
　もっと綿密にテストをしたり、本当にこの対応でいいのかと、自身でレビューを
　する必要があると考えたからです。

　ちょうどその時、新年会を終えた、お客さんのＡ課長、
　前回のプロジェクトのリーダーＣさんから別々に電話がありました。

　お二人とも、私のことを心配してくれており、電話の最後は
　「申し訳ないけど、宜しく頼みます。」と言葉をかけてくださりました。

　Ａ課長、Ｂさん、Ｃさんからは、一切文句を言われませんでした。

　むしろ、「夜遅くまで対応してくれて、申し訳ない。」という言葉ばかりでした。

　私の方こそ、
　「瑕疵障害を出してしまい、誠に申し訳ありません。」という気持ちです。

　翌朝、プログラムをＣＤに焼きました。
　
　クライアント先に行って、後輩にそれを渡し、また開発現場に戻ってきて
　いつものように作業を進めていきました。


【６．最後に】

　今回の件は振り返ってみると、やはりまだまだ品質についての意識が
　私は甘いと言わざるをえません。

　これまで必死で品質向上策を考え実施してきました。

　そんな姿をＡ課長、Ｂさん、Ｃさんは見ていただいているので、
　問題が起こっても、
　「あれだけ品質向上策を実施している中で、起こった不具合だから仕方ない」と
　思ってくださり、文句を一切言わず、暖かくフォローしてくれたんだと思います。

　もし、品質向上策を実施していない中で、問題が起きていれば、
　「ほれ見たことか！」と、文句を言われていたと思います。
　それはもちろん、当たり前のことです。

　品質保証について道のりはまだまだ厳しいのですが、逆に捉えると、
　向上できる余地はまだまだあると思います。

　いつも自分の限界を超えるつもりで、システム開発を行ってきました。

　限界までやって、さらにその限界を超えてまでやった上で、まだ不具合が残った。

　その限界をさらに超える必要がある。

　限界を超え、限界を限界でなくし、またさらに限界を高くし、その限界を
　超え続けていく。

　そうやって、今日も頂を目指し、一段一段、歩みを進めていきたいと思います。