非機能のテストを省くな

　皆さんは、たとえプロジェクトが遅れていても非機能要件をしっかりと定義し、それをテストしているだろうか。言うまでもなく、システムを安定稼働させる上で、性能や信頼性といった非機能要件は重要である。また、その要件が正しく実装されていることを確実にテストしなければならない。

　ところが、この非機能要件はやっかいなものだ。特に非機能要件のテストは「本番と同等の環境」や「本番相当の処理パターンや件数」、「障害時の回復手順」といった条件をそろえなければならない。リーダーなら、緻密な計画作りに奔走することだろう。

　その上非機能要件は、利用者にとって分かりづらく、重要性にも気付いてもらいにくい。中には「それはベンダーが保証するものでテストは必要ない」と存在を否定する人さえいる。最近はシステム基盤を提供するクラウドサービスが充実してきた。これが普及すれば、利用者と非機能要件の距離はますます遠のくだろう。今回は、そんな状況のなかでのルール「非機能のテストを省くな」を紹介しよう。

利用者の協力得られず非機能なき開発に突入

　筆者はユーザー企業のシステム部門の方々と仕事をすることが多い。この方々は、非機能要件への意識が薄いわけではない。むしろ問題なのは、利用者だ。往々にして非機能要件に対する意識が薄く、問題が生じやすい。

　筆者が以前携わったプロジェクトではこんなことがあった。そのプロジェクトは、利用者の興味が画面や業務機能に特に集中していた。一方、どんな処理がいつどれくらいあるか、1秒間にどのくらいの処理件数か、障害が発生したときにはどんな運用になるかといった点に対して、全く関心がなかった。

　プロジェクトは非機能要件がろくに決まらず、テストフェーズに入っていた。さすがに心配になった筆者は、恐る恐る「非機能要件のテストを省くと、きちんと動くシステムにはなりませんよ」と
切り出した。利用者の方と一緒になって、テストの内容を検討しようと考えたのである。

　ところが、利用者の反応は変わらなかった。「私たちはシステムの素人なのでよく分からない。プロであるあなたたちにすべてお任せします」。一方的にテストを押し付けられた。

　テストしたくても何が正しいかを示す要件がはっきりしない。困り果てた筆者は上司に相談した。すると「そこまで言うのなら仕方がない。対価もいただけそうにないので、最低限のテストだけやってくれ」と返された。そこで筆者は、思いつく範囲の要件を挙げてテストした。その間、利用者からは「何をしているの？他にやってほしいことがたくさんあるんだけど」などと横やりを入れられた。時間に余裕もなく、周りに軽視されるテストの実施に、筆者はとてもモチベーションが下がった。

　そんなこんなでリリース日を迎えた。だが、その初日、業務開始から数時間もたたないうちに、システム障害が発生した。画面の応答が返らないというトラブルだった。利用者からは「何が起こったんだ。早く直してよ！」と矢のように催促された。

思いつきのテスト 稼働数時間で障害

　障害時の運用方法など決めていない。原因分析や復旧もなかなか進まなかった。やむなく筆者らは、システムの「再起動」を試みた。すると、何とかシステム障害から復旧。大きな問題にならずに済んだ。

　非機能要件のテストを省いた結果だった。利用者の協力を得られなかったので、仕方がない面はある。しかし、“システムのプロ”としてやるべきことを怠った点は否めない。たとえどんな状況でも、非機能要件をしっかりと定義し、それが達成されているかどうかをテストしなければならなかった。今回は再起動によってたまたま障害から復旧し、利用者への影響も限定的だったからよかった。だが、一歩間違えれば、取り返しのつかない大きなトラブルになっていたかもしれない。

　システム全体でどのような挙動となるべきか、それを示すのが非機能要件である。本来なら、利用者も高い関心を持たなくてはならない。そのテストには、利用者に積極的に関与してもらえるようにリーダーが働きかけよう。「利用者も別にこだわっていないし、いいんじゃないか」という考えを持った瞬間に、プロジェクトは動かないシステムの構築へと進んでしまう。