ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

第1回レビュー祭で神輿の片棒かついできた - その3

 その1とその2はコチラです。

www.kzsuzuki.com www.kzsuzuki.com

 細川さん・細谷さんによる3つ目のワークショップと、クロージングパネルにちょっとだけ触れて、閉じようと思います。

ガイドに基づくレビュー

 3つ目は、「ガイドを用いたサンプリングレビュー」というワークショップ。与えられた「ガイド」に基づいて、ドキュメントの欠陥を摘出してみようという演習です。

「ガイド」とは?

 「ガイド」とは、ドキュメント記述の妥当性を系統的に検証するための、簡易なフレームワークとわたしは理解しました。
 企業のポートフォリオ戦略の話で、BCGモデルってありますよね。横軸を相対シェア、縦軸を市場成長率としたマトリクスに、各事業をマッピングする。市場成長率が低くて相対シェアが高い事業は「金のなる木」で・・・とかいうあれです。
 複雑なものをたった2軸で表現できるはずはなく、色んな情報を落としているわけですが、それでも特定の切り口を与えて、その切り口にフォーカスして考えることで見えるものもある。

 レビューにおけるガイドも、同じ役割をもっています。1つの視点に基づいてレビューすることで、その視点については網羅的に確認ができる。普通ならアドホックに指摘が出て発散しがちな場を、1つのラインに乗せることもできる。
 もちろん、ガイドによって検証できるのは、そのガイドが持つ切り口だけですが、いくつかのガイドを用意しておくことで、検証できる範囲は増えていきます。また、アジャイル・インスペクションでの「視点」と同様、欠陥を見つけるための手がかりがあるため、経験が豊富でないメンバーもレビュアーとして参加しやすいと言えます。

今回のガイドは「入出力」

 今回のレビューで与えられたガイドは、「入力」「→」「出力」というもの。「入出力ガイド」と仮に呼んでおきます。こんな形の表。シンプルですね。

060c94fd

 演習のテーマは「コンビニにおける、電子マネーでの決済機能」でした。
 この機能は、レジから金額情報を受け取って、利用者が選択した電子マネー種別を判定して、残金から金額を引いてもマイナスにならないかを計算して・・・といういくつかの部分に分かれますよね(使ったことないので想像・・・)。で、それぞれの部分について、入力・処理・出力が決まっていないと、実装できない。
 ただ、自然言語で叙述的に書いてあるドキュメントだと、その3点セットが漏れなく明確になっているか、ぱっと見わからないですよね。そこで、入出力ガイド。

入力
  • 入力元が明示されているか
  • 判定・処理に必要な情報の中身が明示されているか
  • 値の範囲が明示されているか
出力
  • 出力先が明示されているか
  • 出力の中身が明示されているか
  • いつ出力されるかが明示されているか
処理
  • 出力を入力から導出する方法が明示されているか

というポイントに注意しながら、ドキュメントの記述内容を表にマッピングしていく。すると、埋められないセルがあったり、どうも曖昧だぞっていうセルが出てくる。そういう部分は、記述の(あるいは検討の)足りていない箇所だと気づけますね。

 もちろんこのガイドをきれいに埋められれば100%の設計、ということにはなりませんが、少なくとも「入出力と、その間の処理」については明確なものになっているわけです。

他のレビューとの関係は?

 この後のクロージングで野中誠先生が、「既存のレビュー分類は、実施形態によるものであり、目的志向ではない」という旨のことをおっしゃっていました。おっしゃる通りで、「公式か、非公式か」「記録を取るか、取らないか」みたいな、「やり方」による分類しか、わたしは見たことがありません。
 でも本当に必要なのは、「どのレビューが、どういう目的で使えるか」という情報なんですよね。たとえばアジャイル・インスペクションの目的は、ドメインに立ち入る前の、そもそもの書きっぷりをチェックして、「書くこと」そのものの品質を上げようというもの。

 ガイドに基づくレビュー(Guides Based Review?)は、アジャイル・インスペクションの次にあるレビューとされています。位置づけ上はまだ、ドメインにあまり立ち入らない範囲での品質向上を目的とするものと紹介されました。この後に、チーム内非公式レビュー、そして公式のインスペクション、という流れになります。
 もちろん、全範囲×全レビューを求めているわけではありません。アジャイル・インスペクションや、ガイドに基づくレビューによるサンプリングで、ドキュメントとしての品質を上げていく。その後に、非公式レビューと公式インスペクションで、ドメイン依存の部分のみに集中し、設計としての品質を上げていく。こんな流れなんですね。

他にどういうガイドがある?

 今回紹介されたのは、「入出力」のガイドでした。
 設計を整理し、系統的に検証するという意味では、たとえば状態遷移表デシジョンテーブルもガイドと言えるのではないかと思います。状態遷移表は、ありうる状態と、状態間の遷移をもたらすイベントを網羅的に整理することができる。デシジョンテーブルも、ありうる真偽パターンを洗い出すことができる。

 とはいっても、これらは設計に立ち入った情報を整理するものなので、もう少し手前のものが望ましいですね。
 ぱっとは思いつかないのですが、「かつ」「または」といった、論理に関する記述について、何かガイドを設けられないかなーと考えています。

クロージングパネルと、後の祭り

 この後、森崎修司先生を含め、登壇者全員によるクロージング・パネルがあったのですが、わたしの腕ではとてもまとめ切れせんので、レビュー祭りのレポートはこの辺で終わりといたします。

 感想。
 レビューは、テストに比べて理屈が少なく自由度が高く、どうもしっくりこない、「やりきった」感がないという気持ちがありました。が、今回の議論を通じて、レビューもまた、計画や戦略をもって実行できそうだという手応えを覚えました。「1日でレビュー手法を少し進化させる」という祭りのコンセプトを、実感できたように思います。

 閉会の挨拶や懇親会で、登壇者の方々は口々に、「またやりましょう」「次はみなさんが前に」とおっしゃっていました。それを聞いて、「この人たちは、全然指導者気分じゃないんだな。自分たちも学んでいるんだから、教えてくれよ!っていう人たちなんだな」と思いました。
 この祭りは、ちょっと信じがたいことに、参加無料。その理由は、「登壇者もまた、学ぶ立場だよ」という志にあるんだろうなと感じて、本当によい祭だなあとしみじみ思ったのでした。

 登壇者のみなさん・主催者のみなさん、どうもありがとうございました。来四半期の第002回を楽しみにしております(丸投げ系男子)。