定員は60名だったと思うのですが、100名ぐらいが結局参加している様子で、席もいっぱいいっぱいだった事を考えると欠席者も少なかったんじゃないかと思います。
それだけ興味/注目をもって来た方が多かったって事でしょうか。
このワークショップですが、メインはハンズオンとして、実際に個々人でコードレビューを行いその結果を研究材料にするという感じ。
ソフトウェアインスペクションとは？ どうやったら効率いいのか？ というのを聞きに行くようなものじゃありませんでした。
「コレがベスト。一番効率いいっす！」なんてものはまぁないですしね。
ハンズオンの内容ですが、「仕様書」 と 「コード」 を対象に、或る人は Adhoc, 或る人は SGIT, 或る人は Guided Checklists が手渡され、その観点を元に一定時間内に欠陥を見つけ出す というものでした。
システムはWEBベースの書籍通信販売、レンタルシステムのプログラム。
コードは、JSPとServletがなんと紙ベースで配られた。結構な厚みのを。。。うへぇ
Adhocって？SGITって？ とかよーわからんままレビュー開始。紙ベースのコードなので、呼び出し先コードを探すのが、もぅイライラ(笑) しかも使える机のスペースが狭いから、ばーーっと広げることも出来んし、結局時間切れ。
IDEがないとツライ事を実感ww
AdhocとかSGITとかの説明は結局無かったんですが、周りの人のをぱっと見せてもらった感じでは、
Adhocは チェックの観点を簡単に記述したもの。「シングルサインオン」とか、「パスワード再発行」とか観点のキーワードのみって感じ。
SGITは、Adhocよりも細かくチェック観点が書かれていて、Tree形式になっていました。
○○は出来ているか？ yes ----> ××はできているか？
no ---->
のような感じで。
ChecklistsもSGITみたいに細かいチェック観点が書かれているようでしたが、表形式でした。
多分、どれが一番効率的だったか？を測りたかったのだと思いますが、私のチームではどの方式の人も欠陥はあまり発見できず ???な感じで終了。なにが ??? で詰まってしまったか？を聞いてみたら、言葉の定義が人によって違う所とか、そもそもの前提がわかんなくなったとか、わたしゃJSP/Servletなんて随分前にしか見てないから思い出すだけで時間くったとか、そんな感じでした。。あはは。。
そんな感じのイベントでしたが、頂いた資料や開催中のお話で自分なりに理解したこと、気になったキーワードをピックアップします。
まずは、講師の方の発言の気になった もしくは勝手に読み取ったキーワード。
・レビュー/テストは泥臭い所だけど、カッコいいよね。
・見つけた欠陥は全て記録し、2度と再発しないための根本原因を考える事。
・大きい範囲でやるより、小さい範囲を何回かに分けてやった方が効率がよかった
・何も見ない段階で「欠陥の仮説」をたてるのは有効。
・定型的なミスはコードで検出。検出できないものを目視で という分担を。
・何事にも楽しく行なうのが重要。個人攻撃はもっての他。
・レビューをしても評価がないと、自分の時間を削られるだけ = やりたがらない、適当に終わらせてしまう
・AssistPointの評価、同僚の評価を！
・形式的にやると決められているから、しょうがないけどやらないといけないです という状態になってしまう
・事実をベースに話す (一般的に...、普通は...、前のと比べると...という言葉は使わない)
・レビューは効率的に人を育てることができる
・レビュー専門の職種だと、1年に200程の案件のレビューをできたりする。長年の経験が或る人でも200の案件をこなしている人もあまりいないのでは!?
・なぜ、レビュー/テスト をするのか？ → 安心したいから。
・品質については、日本は一目置かれている。 (日本人が品質を話しようとすると黙って聞いてくれるらしい)
「インスペクション」という言葉に、しっかりとした定義はない。
レビューと同等の意味で使われていることの方が多い。(実装者ではレビューという人の方が多い)
ただ、レビューといってもいろんなレビューがあるから、それを分類するのにお互いの合意のもと単語を使い分けても良さそうな感じ。
いろんなレビューですが、例えば、納期前に行なう品質チェックもあれば、技術的部分のレビューもあるし、隣の人にちょっと見て〜！ってお願いするレビューもある。。。
まずはIEEE1028の抜粋記事の抜粋ww
Inspection
目的：欠陥の発見、修正の検証、ソフトウェア品質の検証
意思決定：事前に定義された対処方法を選択。発見された欠陥は修正。
参加人数：3〜6名
主導者：訓練を受けた進行役
データ収集：必須
成果物：指摘欠陥リスト、実施報告書
Technical review
目的：仕様、計画との一致の評価。変更の一貫性の判断。
意思決定：参加メンバーの提案に基づいて管理職や技術リーダーが判断
参加人数：3名以上
主導者：技術リーダー
データ収集：プロジェクト要件ではないが、参加者で共有されることが多い
成果物：実施報告書(担当、完了予定日が記録された対応予定を含む)
Walk-through
目的：欠陥の発見、代替案の検討、製品の改善、習得のための議論
意思決定：作成者の判断を参加メンバーが合意
参加人数：2〜7名
主導者：進行役、作成者
データ収集：推奨される
成果物：指摘欠陥リスト、対応予定、決定事項
私が感じたイメージですが、
Inspectionは計画的に行なうレビューで、実装前の仕様決定のような早いタイミングで行なうもの。(もちコードも対象だけど)
これじゃー仕様満たせないよね？とか、経験上ここらへんヤバいからもっと詳細に仕様書いた方がいいんじゃね？的な感じかな。
この場合は、解決方法を考えるのは無しで、ここは欠陥！とかここは再検討！とかの決定だけをバシバシやっていくのが良さそう。
今回やったハンズオンはInspectionだったんですよね？？？
Technical reviewは、コードに対して、こうやった方がコードスッキリするんじゃね？とか、こういう処理は、よく○○って名前をつける事が多いからその名前にした方が皆に伝わりやすいよ？とかそういう系のやつですかね。
Walk-throughは、「ここ、こぅしてみたんだけど、あんまり自信ないから、見てほしーどぅおもう？」ってやつですかね。
まぁ、全部やれればいいんでしょーが、只でさえ時間を削る所にされてしまうレビューですから、内容やタイミングによって選択しつつ...ですね。
やる時に、Inspectionしまーす！ とか Walk-throughtしまーす！ とか名前出したら、目的もわかって良さそうですな。
今の感想としては...実際やってみないと分かんないし、やってみながら、メンバーとこぅした方がよりいいとか楽しいとか話し合えたらいいよなぁーなんて思ってます。今日の参加者の皆さんは、みんな(形式的な)レビューをやっているという人がほとんどだったんですが、私自身経験がそんなにないんですよねー。つーことで、ぜひ、やってみたい。
まずは、勉強会とか研究会的に、サンプル用意、実際レビューしてこぅやとやりやすいねー！とか、次はこぅしてみたらどうだろう？ このツール使ってみる？ とかやってみたいなぁ。
技術とかは一人でも学べるからいいんですが...こぅいぅ事こそ、興味ある人同士集まって、試して、話して...ってしたいなぁ！
会場のアンケートでも半数以上が 「あまり上手くいっていない」 って事だった事も考えたら、とりあえず方法を先決めて形式的に入れる つーのはあんまり良くないんだろうし。
会社のみんなは、業務時間外でもやってみたい位の興味あるかなぁ??