No307　システム開発でのテストとレビュー

2023年の3月あたりから、コンビニなどで住民票などの交付サービスで他人の証明書が発行されるというトラブルが相次いでいます。

この数ヶ月で４度（横浜市、川崎市、東京足立区、徳島市）発生というのは、頻度が高すぎます。

システムの開発保守を行っている富士通側はそれぞれ別種のバグであり対処は完了しているとのことですが、利用者から見ると何ともお粗末な話です。

今回の件については、開発担当である富士通側の問題もありますが、依頼側である行政側（市区町村）側にも問題があったのではないかと思います。

このようなバグが残ってしまったり、後になって見つかるというのはシステム開発ではよくある話です。

今回はちょっと堅目になりますが、システム開発の一般的な進め方とバグ抽出の難しさについてお話します。

それを踏まえて、次回には今回のトラブルについて解説をしたいと思います。


1. システム開発の難しさ

システム開発というのは、非常に難しいものです。

頭に描くイメージを実際に稼動かすまでには様々な作業が必要です。

理想のイメージ
　↓
　↓イメージを言葉に直す（要件定義）
　↓
要件定義書
　↓
　↓その実現方法を考える（設計）
　↓
システム設計書
　↓
　↓それをプログラムにする（プログラミング）
　↓
プログラムやデータ
　↓
　↓利用方法や手順を考える（運用設計）
　↓
運用開始

それぞれのステップは資料や言葉によるコミュニケーションに依存しますので、様々な誤解や抜けが発生します。

それぞれのステップで10%の誤解や抜けが発生するとしますと次のようになります。

理想のイメージ
　↓
　↓要件定義での欠落(-10%)
　↓
要件定義書（90%）
　↓
　↓システム設計での欠落(-10%)
　↓
システム設計書（81%）
　↓
　↓プログラミングでの欠落(-10%)
　↓
プログラムやデータ（73%）
　↓
　↓運用設計での欠落(-10%)
　↓
運用開始（66%）

各ステップでの誤解や抜けが重なると理想形の2/3しか実現ができないことになります。
依頼した側が「俺たちの頼んだことが全然システムで実現されていない！」と憤るトラブルは多くありますが、ある意味当然と言えます。

ですが、（日本語などの）言語表現にはあいまいな部分が必ず残るため、依頼側の意図を100%伝えることは極めて難しいのです。

もちろん、開発側もそんなことは百も承知で、いろいろな手法でそれを抑えます。

今回はこういった誤解や抜けを防ぐ方法の代表格である、テスト技法とレビュー技法のお話をします。


2. 品質向上のためのテスト

システム開発ではこういった誤解を減らし依頼側の期待に近づけることを「品質向上」と呼びます。

ここで言う「品質」には様々な意味が含まれています。
依頼内容そのもの（機能）はもちろんですが、使い勝手、反応速度、エラー頻度、バグの少なさ、なども品質と呼んでいます。

システム開発での品質向上策といえばテストが代表的な方法です。

補足：
　ご存知ない方に補足しておきます。
　ここで言う「テスト」はプログラムの動作確認のことを言います。
　学校の定期考査や大学入試とは全くの別ものです。
　おおむねプログラマが作った直後のプログラムはまともに動きません。
　なので、期待している通りの動作になるまで、修正とテストを繰り返します。
　なお、テストの進め方は様々な主議手法があります。
　・全てのプログラムを作ってからテストをするパターン、
　・少し作ってはテスト、を繰り返すパターン、
　・「テストプログラム」と呼ばれる自動化プログラムを作るパターン
　どれがベストとは一概に言えませんが、最近はテストプログラムを使うプロジェクトが増えてきています。


3. テストの欠点

テストによる品質向上は王道ですが、いくつか落とし穴があります。

要件が決まり、設計を行い、プログラムを作った後でないとテストはできません。
そりゃそうですよね。あたりまえの話です。

ですが、ここでやっかいなことが起きます。
最初にも書いたように、誤解はどの段階でも紛れ込みますが、テスト段階でそれを全て見抜くのはムリ、というこです。

設計書に「○○せよ」と書いてあったとします。
そう書いてあれば、「○○する」プログラムを作りますよね。
「ああ、オレにはわかる、わかるぞ。これは依頼者の期待ではない！正解は△△せよだ！」なんて考えるのは天才プログラマというより、ヤバい人です。

つまり、テストよりずっと前の段階で紛れ込んだ誤解にテスト段階で気付くのはものすごく難しいのです。

テストでの品質向上にはもう一つ問題があります。
先の話と重なりますが、テスト作業はかなり後の方の作業になりますので、そこで大きな問題に気づいても手遅れとなる場合が多いのです。

大きなシステムでは作業遅れによる稼動遅延がしばしば発生します。
この典形が、テスト段階になってから大きな（設計や要件に関わる）問題が見つかり、要件の再考や再設計からやり直しするパターンです。

最初に見つかっていれば、日程の見直しで対処できるかもしれません。
ですが、最後で気づいたって既に手遅れです。

もちろん、テストはとても重要な作業です。
ですが、テストだけで品質を保つのは難しいのです。


4. レビューという技法

システム開発担当者として実感ですが、要件を決める（要件定義と言います）段階でのミスは応々にして後で大問題となります。

要件を決める段階では参加者の意識が必ずしも一致していません。Ａさんの考える理想形とＢさんの考える理想形が異なるのが通常です。

ですから、これを早い段階で合わせておくと、後の作業がスムーズになります。

そのための手法に「レビュー」というものがあります。
日本語では「見直す」となります。

作った資料などを皆で読み合わせる作業のことを言います。
大きな目的は、内容の洩れや誤解しやすい文章を訂正することです。
それによって資料をレベルアップさせるわけです。

言ってみれば簡単な作業なのですが、その効果は絶大です。

・システム開発の初期段階から実施ができる
　→資料の読み合わせなら、システム開発を知らない方も参加できます。
・参加者の意識合わせが行える
　→各人のシステムイメージを合わせられます。
・新たな課題が発見できる
　→まとまった資料を通読し、会話をすることで埋もれていた課題に気付きます。

しかも、テストと違い、資料さえあれば実施できますので、要件を決める段階、設計を行う段階、プログラムを作る段階と多くのタイミングで実施できることもメリットです。

また、レビューは「依頼者側が開発に参加している」感を高められますし、「俺たちの言うことを聞いてもらえる」感も持てるなど、副次的な効果も期待できます。

デメリットとしては、余計な時間を取られるというものがありますが、上記のようなメリットを考えると十分にペイすると筆者は考えています。
（実際、筆者はレビューが好きです）

レビューをしても見逃しはありますし、参加者の発言（熱意）が少なければ文字通り「読み合わせ」に終わってしまいます。

また、レビューとテストは互いに補完し合う関係ですので、両方が必要です。


5. まとめ

システム開発を行うには、要件定義、設計といったいくつもの段階が必要です。

そのそれぞれでは誤解や抜け洩れが生じますので、当初描いていた理想形の一部しか実現できていないということはよくあります。

ですが、このようなレベルダウンは依頼側には深刻な問題ですし、開発側もそんなことは全く望んでいません。

そのため、開発側はいろいろな技法を駆使してこういったボタンの掛け違いが起きないような工夫をしています。こういった工夫をシステム開発では「品質向上」と呼びます。

一般的な品質向上策には、テストとレビューの二つがあります。テストは主に作成したプログラムが期待通りの動作となっていることの確認、レビューは主に作成した文書が期待している理想形を満たしているかどうかの確認に使われます。

テストは主にプログラムの動作確認（設計書とプログラムが一致していることの確認）に使われます。

プロジェクトによっては、要件定義書とプログラムが一致していることの確認用のテストも行う場合があります。

とはいえ、テストを行うにはプログラムが必要ですので、どうしても後の作業になりますので、そこで大きな課題が見つかると大変です。

レビューはその回避に有効な技法で、資料や文書の読み合わせが主な作業になります。

レビューにはシステム開発者に加えて開発を依頼した方々も参加できるため、参加者全員の意識合わせにも有効です。
また、皆で討議することで一体感を高め、互いに満足度が上がるなど良いことがたくさんあります。

逆に、レビューが低調な場合は、依頼側の意見を十分に吸い上げられていない可能性がありますので、注意が必要と言えます。

冒頭に証明書のコンビニ交付サービスでのトラブルの話を書きましたが、この開発でのレビューは低調だったのかな？などと思ったりもします。

テストとレビューはどちらも有効な対策ですので、両方ともに実施する必要があります。

今回は、システム開発の概要とテスト技法、レビュー技法についてお話しました。

次回もお楽しみに。

（本稿は 2023年5月に作成しました）

"