技術レビュー演習のWeb上体験

2009年3月31日(火)
野中 誠

レビュー指摘件数と所要時間のばらつきは大きい

 具体的なレビュー指摘内容の話に入る前に、ここで、この演習題材を作るきっかけとなった事故についてご紹介します。

 2006年に、高齢者用集合住宅の室内で入居者が死亡し、その後1カ月たってから発見されるという痛ましい事故がありました。その引き金となったのが、入居者が在宅中でも、外からの施錠でシステムには「不在」と表示される仕様上の問題でした(図2の1-3)。入居者の様子を見ようと警備員がやって来て、帰り際に外から施錠したために、入居者が在宅中にも関わらずシステム上は「不在」となってしまいました。その後、入居者の体調に異変が起きたのですが、「不在」の部屋には生活援助員が応対しないという業務手順も災いし、この部屋のドアが再び開けられたのは入居者の死亡後1カ月が経過してからでした。

 技術者として、このような重大な事故に至る問題を、二度と見逃してはなりません。限られた時間とリソースの範囲で、お客さまの安全・安心にシステムを通じて貢献するためには、レビューのスキルを高め、効率的/効果的に問題を検出する必要があります。

 さて、話をレビュー演習の題材に戻しましょう。図3は、比較的スキルの高い若手ソフトウエア技術者約20名(大学院生数名含む)に、宿題形式で個人レビューを実施してもらったときの結果の散布図です。横軸はレビュー所要時間、縦軸は指摘件数(有効指摘と無効指摘を含む)を表し、それぞれの技術者の結果をプロットしています。赤いひし形はレビュー観点を自ら設定した上でレビューを実施、赤丸はレビュー観点に加えて利用シナリオを挙げた上でレビューを実施した技術者の結果です。

 個人のスキルややる気の違いなどもあるので一概には言えませんが、指摘件数に大きなばらつきがあること、長い時間をかけても指摘件数の少ない人がいること、レビュー観点や利用シナリオを挙げてレビューした技術者は指摘件数が多い傾向にあること、などが散布図から読み取れます。

 エンジニアリングの観点から取り組むべきことは、レビュー観点を明確化してレビューしたり、利用シナリオを列挙した上でレビューしたりなど、個人レビューにおいて成果物を「読む」方法の改善です。インスペクション会議の質と効率を左右するのは、それぞれのインスペクタが事前の準備プロセスでどれだけ幅広く問題を指摘できているかに依存します。

レビュー観点の例と仕様上の問題

 では、最後に、具体的なレビュー観点の例と、この仕様における問題をいくつか挙げましょう。

 レビュー観点は、一般には、ユーザーの視点(仕様の妥当性確認)、設計の視点(実現可能性)、テスト担当者の視点(テスト可能性)などが挙げられます。実際には、次に挙げたような、もう少し踏み込んだ観点でレビューした方が検討しやすくなります。

 安全性:システムが認識した状態と観測対象の状態にギャップが生じたとしても、安全サイドに倒れる設計になっているか(フェイルセーフ)。この仕様では、図2の1-3、2-3、3-3で「不在」に状態が遷移したとたんにすべての警告がキャンセルされるため、フェイルセーフの面で問題があります。

 正確性:システムが認識した状態と観測対象の状態にギャップが生じないか。N/Aは本当に起きないか。事故事例で示した通り、「外から施錠」イベントにより、システムの状態と高齢者の状態にギャップが生じます。また、図2の4-4において、高齢者が玄関で転倒してドアが閉まった場合、やはりギャップが生じます。加えて、図2の4-2において、泥棒が窓から侵入して玄関から出て行った際に、システムの状態遷移において問題が生じないか、確認する必要があります。

 利用シナリオの網羅性:システムの利用シナリオは網羅的に検討されたか。新たな機器が追加される可能性を考慮したか。湯沸かし器が後から取り付けられたときに、不在時に給水が再開される可能性があるが、図2の4-6はN/Aのままで問題ないか確認する必要があります。

 妥当性:正しいドメイン知識に基づいて仕様を確認したか。すべての利用シナリオに対して、システムは妥当な振る舞いをするか。事故事例から明らかな通り、入居者と警備員がどのように振る舞う可能性があるか、正しい知識を持って検討された仕様とは言えません。

 完全性:イベントと状態のすべての組み合わせについて、仕様が網羅しているか。これは前のページですでに検討を終えました。

 これらの観点は一例であり、ドメインによっては、重点的に考慮すべき観点が異なるでしょう。それらの観点や、観点別のチェックリストをドキュメントとして形式知化し、組織内で知識を再利用できるかたちにしておく必要があります。この知識を組織的に活用できるかどうかが、その組織の技術力に反映されるのです。

 以上、身近な例でありながら重大事故につながった例を題材として、観点を明示してレビューすることの有用性を紹介しました。この記事が、読者の組織におけるレビューの効率性向上に何らかのヒントを与え、それがソフトウエアの品質向上に貢献するのであれば、筆者にとってこの上ない喜びです。地道な取り組みではありますが、ぜひ、レビューの効率と効果の向上に向けて取り組んでください。

東洋大学
早稲田大学大学院理工学研究科博士後期課程退学。早稲田大学理工学部助手を経
て、現在、東洋大学経営学部准教授。経営システム工学をバックグラウンドとし
たソフトウェア工学研究に従事。情報処理学会ソフトウェア工学研究会幹事、日
本科学技術連盟ソフトウェア品質研究会(SQiP)副委員長などを務める。
Webサイト(http://www.se.mng.toyo.ac.jp/

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています