レビュアー7つ道具

自分はまだまだ熟練エンジニアとはいえないのだが、チーム内では比較的経験年数が多いほう。なので、レビュアーをお願いされることが多い。主に、設計レビューやコードレビュー、テストケースレビュー、メンテナンス手順レビュー。そういうレビュアーをするときに意識していることをQC7つ道具になぞらえて、レビュアー7つ道具という名目でまとめてみた。

1. チェックシート



「チェックシート」は2つの用途で使います。一つ目はレビュー観点をまとめたシートです。それはコーディング規約の類であったり、仕様書であったり、過去の指摘項目リストであったりします。例えば、コードレビューにおいて、変数の初期化、スコープが適切であるか、などなど。もうひとつはレビュー対象リストです。基本的にはある程度細かい単位でレビューすることが多いですが、関数や処理といったリストを使う場合もあります。
「チェックシート」の目的は、実施漏れをなくしたり、レビュー対象の規模を把握したり、記録用にも使います。




2. 対話



パスアラウンド方式であれば難しいところはありますが、ミーティング形式ならば「対話」というツールをうまく活用すべきだと思います。対話をさらに分けるならば「疑問」「質問」「自問」でしょうか。




• 疑問

単純にレビュアーが理解できなかったことについて解説を求めます。レビュアーの理解もそうですが、作成者にとっては説明するということが理解を深めることにもつながると思います。

• 質問

疑問と似ていますが、レビュアーがある程度推測できることや、完全に理解していることを、あえて問うてみます。レビュアーの頭の中では作成者のロジックの組み立てをチェックしたりもします。

• 自問

所感やリスク分析などを促し、作成者に考えさせて自己解決・認識させます。人に「これではだめ」といわれるよりも自分自身で「これではだめ」と気づくことも重要。



　「対話」の目的は、理解度の共有でもあり、コードレビューについていえば作成者のクセ・センスを確認することができ、この情報は今後に役立つ可能性もあると思っています。




3. 分割



「分割」も2つの用途で使います。一つ目はレビュー対象の分割を行い、単純化とレビュー時間の細分化を行います。もうひとつはレビュアーの役割分割です。自分のチームでは基本は複数名のレビュアーとしているので、各人の切り口を変えてレビューを進めたりします。
　「分割」の目的は、単純化と細分化、切り口を多くしてより多くの欠陥を探すことができると考えます。




4. ズームアウト・ズームイン



「ズームアウト」はレビュー対象を大枠で眺めることで単純化し、逆に「ズームイン」はレビュー対象の詳細について査読します。IF文の入れ子ブロックであったり、画面全体仕様と各画面の仕様であったり。大枠についての査読をした後、細かいところについてチェックをする、比較的常套手段かな、と。
「ズームアウト・ズームイン」の目的も、単純化と細分化ですが、見方によってはモデル化ともいえるでしょうか。



5. 日本語化・口語化



「対話」と関連してきますが、図表やコードをレビュアーが「日本語化/口語化」して説明して、作成者との認識チェックを行います。あるテスト技法について学ぶときも、複数の書籍を見比べて勉強したりしますね、それに似ていると思います。物事を換言することは理解を深めるときに重要だと思います。
「日本語化・口語化」の目的は、作成者の脳とレビュアーの脳が同じインプットに対して同じアウトプットが出せるか、という視点でチェックをする、みたいなイメージです。




6. 将来設計



「将来設計」とは、ソフトウェア/システムの将来的な規模、拡張性、引継ぎなどを考慮します。これにはいくつか特性があると思いますが、




• スケールアウト可能か


• 拡張・変更が容易か


• メンテナンス・引継ぎが容易か




といったところでしょうか。
「将来設計」の目的は、文字通りの将来の品質に着目すること。




7. 休憩



1時間くらいで「休憩」を取り、頭を休めたり、作成者と会話を楽しみます。レビューは人間関係も大切です。作成者もレビュアーも作成物の品質向上とエンジニア自身の成長につながるようなレビューを心がけるようにしています。

同僚の作成物のレビュアーをする機会は多いと思いますが、皆さんはどんなツールをお持ちですか？

日本経営品質賞アセスメントガイドブック

ちょっと路線の違う書籍の紹介。

2008年度版 日本経営品質賞 アセスメントガイドブック

画像は経営品質協議会より

ソフトウェアテストとは少し離れてしまいそうですが、「経営品質」とは、というくだりでは、以下のような言葉がありました。

日本では「品質」という言葉は、製品の機能や特性を表すものととらえられてきました。ものの質だから、「品質」だという概念が定着しています。
（中略）
品質は「クオリティ」という言葉を訳したものです。クオリティの語源はギリシャ語の「クオリス」です。この言葉は「ものの明らかさ、適切さ」を意味しています。
（中略）
ある目的で適切なことであっても目的が違っていれば適切でなくなるのです。急いでいるお客様に対しての時間価値を目的としたサービスの質と、ゆっくりとくつろぎたい人むけの時間価値を目的としたサービスの質は異なります。このように品質は目的と深く関係している考え方なのです。

品質＝顧客満足度ととらえることはこの「クオリティ」という言葉の語源からもしっくりくる考え方です。この本ではいかにして「経営」品質を向上させる組織を築くかについて書かれていますが、これらは同時にソフトウェア品質を向上させる組織・チームの築き方が隠されているようです。

amazonでは販売していませんが、いろいろな場面で活用できるテキストだと思います。

コンサルティング

マイミクさんのマイミクさんの日記を見たら、かつてコンサルタントをしたお客さんとの邂逅について書かれていてた。コンサルの後も、その組織は自ら問題を解決し、自ら成長し続けていたようです。コメントにもあったとおり「その組織の問題解決のコンサルティング」ではなく「その組織に問題解決できる力をつけるコンサルティング」をしたということなのだ。

先月にしさんが「テストコンサルタントを目指してみよう」というテーマでお話されていたことが思い出されます。自分はどれだけよい工夫や考え方を皆に伝えて共有しようとしているだろうか。

登山とソフトウェアテスト

「ソフトウェアテスト」って「山登り」に似てるなあ。

• ゴール（頂上）はひとつ

お客様第一、お客様が品質を決める、そこはどんな分野でもどんなプロダクトでもどんなプロジェクトでも同じ。いかに上手に（効率的に、効果的に）頂上にたどり着くか。

• ゴール（頂上）への道はひとつじゃない

頂上はひとつだが、登り方にはいろいろある。登る道筋はリーダーが指し示し、登るペース配分はマネージャーが管理する。なるべくリスクを小さく保ちつつ、近くて緩やかな坂道を登りたい。山登りについて何も知らなければぐるぐる回ってるだけで頂上に近づかないかもしれない。

• 高い山と低い山とでは装備（ツール）が違う

高い山に登るときはそれなりの装備（ツールや知識）、パーティー（チーム）、時間などが必要になる。でも、低い山なら重装備はいらない。けれど、準備のために買い物に行くといろいろな装備（ツール）がほしくなる。意外に高い。

• 5合目くらいまでは車でいける場合がある

道路が舗装されていると5合目くらいまでは車やケーブルカー（自動ツール）でいける。でも頂上まではいけると思っちゃいけない。

• 遭難すると高くつく

山の天気は変わりやすい。なかなか頂上にたどり着けずに夜になっちゃった（デスマ）。救援してもらわないといけないけど、ヘリコプターとか救助隊は高くつくなあ。。。

適切な方向性と妥当なスケジュールと最適のツールを装備して、山に登りたいものだ。

テストのさしすせそ

トラブル対応で1週間があっという間に過ぎてしまった。

==

どこかのサイトでソフトウェアテストのあいうえお作文が載ってた記憶が。自分なりに、効率的・効果的なソフトウェアテストのあいうえお作文。サ行で。

サ：サボれ！

シ：自動化すればいいんだっけ？

ス：水準値は肝

セ：センスも必要

ソ：「ソフトウェアテスト」でググれ！

完全テストは無理なので、緩急のつけ方が重要。サボれるところはサボれ。自動化という呪文にだまされるな。メンテナンスは自動じゃないぞ。水準値の取り方で効率と効果がぜんぜん違う。無駄にテストしても品質は上がらないよ。プログラミングと同じでテストもセンスが必要。今はソフトウェアテストのサイトも書籍も充実してる、まずはインターネットを活用して勉強するべし。

なんてね。

2008/03/06追記
テストのはひふへほ
このコラムにインスパイヤされて。

Don't write redundant tests, and don't write too few tests. - テストは無駄なく漏れなく

昨日は社内では改正される特電法のお勉強会。社外ではWeb自動テストツールのお勉強会。

==

TotT: Too Many Tests by Google Testing Blog

単純な処理を例に挙げて、「テストケースが非常に多いこと」の考察をしている。int型の単純なべき数（＝2^32のパラメータ数分のべき）では、多すぎる。条件分岐がTrueの場合とFalseの場合の2通り（100%ステートメントカバレッジ）は、少なすぎる。境界値と同値クラスを考慮した場合も、少し多そう。最後は、条件分岐（OR条件）がTrueになる場合（＝3通り）とFalseになる場合（＝1通り）を考え、そのサブ処理で各2通りを考えた10通り。

原因結果グラフを解剖 - 原因から？結果から？

BlackBerryのメールは本文をBase64にするみたい。

==

原因結果グラフをデシジョンテーブルに変換する際、まずは小さなテーブル（サブテーブル）を作成してから、全体のテーブルを作っていく手順で僕は行っていたが、サブテーブルはどちらから結合したほうが簡単なのだろうか。ごくごくシンプルな原因結果グラフであれば、中間ノードと結果ノードから大枠をサブテーブル化して、細部を組み立てるほうがわかりやすそうだけれども、制約条件が関係してくると、原因ノードと中間ノードからサブテーブルを作成して、制約条件を先に考慮したほうがよさそうにも思える。

などと考えてみる。

今のところの結論としては、原因側から右側へ結合させていくほうがよさそうに思える。原因ノードと中間ノードについてのサブテーブルを作成する際に、原因ノードと制約条件をもつ原因ノードも一緒にしてしまうといいのではないか。

実施不足と考慮漏れと自動化と

少し落ち着いてきたので、ブログ更新。今日は結婚式の打ち合わせ×2回分。明日はディズニーランド、でも天気は荒れ模様らしい。でも。晴れ男だからチャラ・ヘッチャラ。

==

タイトルにそんなに深い意味がないけど、ここ数週間で思ったキーワード。超基本的だけど、勉強と実行には大きなギャップがありますねぇ。まだまだ経験が足りないな。経験しなくては。

新年度だ 静的テストだ

ずいぶんと間を空けてしまった。現在は少しずつ本を読んでるところ。今年に入って動的テストばっかりだったので、心機一転静的テストとかに目を向けようかな。レビューとかインスペクションって有名な本がけっこうあるけど、読んだことないや。まずは何を読んでみたらいいんだろうか。

事前の自己レビュー

レジュメ

機能のポイント

実装のポイント

リスク（プロダクト）のポイント

テストのポイント

テスト方法

思いついた単語を並べてみただけ。

==
2007/04/05追記。
静的テストといっても、新規システム開発、バグ修正、エンハンスで手法もかわってくる。列挙したのはバグ修正やエンハンスをイメージして書いた。

プロ野球キャンプとテスト工程

3連休最終日はのんびり過ごした。

==

2月にはいるとプロ野球12球団のキャンプがはじまり、スポーツニュースでもその話題が多くなる。ふと、ニュースで「今日から野手と連携プレーの練習」というフレーズが聞こえてきた。ウォーターフォール型システム開発のテスト工程とプロ野球のオフシーズンって似てるかも。自主トレや個人練習が単体テストに似てるし、それから連係プレーの練習という結合テスト、実践練習・紅白戦・オープン戦なんかが統合テストやシステムテスト。

ただ、システム開発と違うのは、テスト工程がうまくいったからといって、秋に美酒を味わえるとは限らないことだな。

==

そういえば3/18から首都圏ではJR東日本のsuicaカードが私鉄・バスでの利用が可能になる。このテストってどんな感じなのだろう。ガス・水道・電気なんかと一緒で規模も品質もこれだけ大きくなると～っ、すごいな。大変だろうし、やりがいもあるだろうし。

期間・工数はどのくらいなのか？

テスト用環境・擬似システムはどのくらいの規模？

品質基準の決定方法は？

どういうテストを実施して、どういうテストを実施しないのか？

などなど。やりがい、とかいっちゃったけど、大変さのほうが大きいね。