レビュー祭りに参加してきた #review_fes

勉強会

祭りって言うんでちょっくら参加してきましたよ。対象は『レビュー』について。

開催場所は東洋大学 白山キャンパス＠本駒込。遠目からでも校舎が望めます。何か凄い造り。

オープニングでも少し話が触れられていましたが、ドラマの撮影等でも校舎が利用されていたんですね〜。


今回は思ってた内容と若干異なってたり、興味範囲の分野とは少し異なった部分もあったため、メモ的にはかなり怪しいかも。(^_^;) 粒度もだいぶ粗めだし(笑) 詳しい内容はより専門分野の方の書かれたブログレポートや以下のTogetterを御覧になる方がよろしいかと思われます。

オープニング

  • 細谷 泰夫氏
  • イベントきっかけについて
  • 『皆さんレビューやられてます？』→数人が手を挙げる
  • 『レビュー、上手く行っています？』→誰も手が挙がらず
  • レビューの自由度の高さ
  • レビューの効果の幅
  • レビューのエバンジェリストを一同に介し、語ってもらう。
  • 体系化・進化のきっかけを作っていきたい。
  • エバンジェリスト、講師陣の紹介。
  • 各人自己紹介

アジャイルインスペクション ワークショップ

  • 永田 敦氏、細谷 泰夫氏
アジャイルインスペクションは、ドキュメント作成の初期からサンプリングに
よるレビューを実施することにより、同種類の誤りがドキュメント全体に
作りこまれてしまうことを防止するレビュー手法です。
アジャイルインスペクションには、レビュー観点に制約を与えることによる
指摘抽出のコントロール、チェッキングレートと指摘の内容の関係など
レビュー一般に活用できる手法を実感できる仕掛けが含まれています。
今回のワークショップでは、皆さんに実際にアジャイルインスペクションを
体験してもらうとともに、現場での実践事例も踏まえた議論を行います。
  • 2008年、ひょんな偶然から教えてもらった。
  • 2年間の間、ワークショップでやっていた。
  • レビュー＝暗いイメージ。その中でワクワクする部分を見つけたい
  • テスト専門
    • 上位レベルのドキュメントを読む事にワクワクする
    • 小説を読むように:何でそうなってんのかな？
  • 2年間で200名近いワークショップ体験者
  • 単独では無く、組み合わせて使うもの。
  • 各自が工夫して使おう。

ソフトウェアインスペクション

ソフトウェアインスペクション

  • インスペクションの目的：
    • 高品質のドキュメントをはじめから生産すること
  • 欠陥予防/the prevent - do not clean princilpe
    • 欠陥を取り除き、修正する
    • はじめからよいものを書いてもらうようにドキュメントの品質を改善してもらう

  • サンプリング/インスペクション/ロギング/修正…の繰り返し。
  • Agile Inspection Iteration
    • そんなに回さない。せいぜい3回程度。
    • サンプリング重要。
  • アジャイルインスペクションのプロセス
    • 準備
      • 1:インスペクタを決める
      • 2:ルール(インスペクションの観点）をきめる
      • 3:欠陥密度の閾値を決める
      • 4:実施時間を決める
    • 実施
      • 5:ドキュメントをサンプリングする
      • 6:インスペクタにルール等の説明をする
      • 7:サンプルをインスペクションする（１０〜３０分）
      • 8:ログを取る
    • 分析・判定
      • 9:メトリクスを分析
      • 10:欠陥密度が閾値より低い場合、次のプロセスへ
        • 高い場合、ドキュメントの質の改善のために差し戻す
  • ルール：
    • 3つから７つ位のルール
    • 例：あいまいでないか？/明確か？/矛盾はないか？
  • ルール：曖昧
    • 絶対ドラゴンズに勝って欲しい。僕はウナギだ
    • 『曖昧って言葉自体、曖昧だよね』
    • 曖昧と不明確がごちゃ混ぜに。
  • 曖昧：
    • 立場が違うと見方も違ってくる。（上記ドラゴンズ）
    • 仕様書に書いたところで、違う解釈をされる場合がある。
    • 例:
      • 子供が好きなおばさんが来た
      • 太郎は自転車で逃げた花子を追いかけた
      • 父は弟に自分の部屋で勉強させた

    • 係り結び…句読点が多い、そこは日本語
      • 曖昧性を潜んでいる。
      • 細川さん『句読点を狙っている』
    • 句読点が多い場合は複数の意味に取られやすく、また文相自身に自信が無い場合が多い。
  • 多義文
    • 例
      • 全部網羅じゃなくても合格とする
      • テストケースは全部出来なかった
    • ※全部＋否定語。
  • AまたはBでないとき、Cである
    • 否定の意味が何処に掛かる？非常に危険。
      • 『入力項目は生年月日と氏名あるいはカタカナです』
  • ルール：不明確
    • データの輻輳に注意して…
    • 応答をいつまで待っても来なかったときは…
    • 出来るだけ早く応答を返す『以上』『以下』『同じ』
  • ルール：矛盾
    • 設定された閾値（表3-3）検出した個数が16個以下なら全て追加。
      • 16個以上なら…
  • ルール：設計要素
    • 要求仕様書では欠陥となる
      • ATM/ログインアカウント
    • ホントはセキュリティが問題。書かれてしまうことで意志が抜けてしまう場合がある
    • ※パラメータの指定だけでは設計問題では無い事もある
  • 重要(MAJOR)な欠陥
    • 曖昧性、不明確性、矛盾性を持ったろどきゅめんと（仕様書）の表現によりそのあとの設計、コーディングでエラーを起こして埋め込まれたお客様に影響のある故障を発生するリスクを持つ欠陥。
  • (ワークショップ)どの位欠陥があるか体験してみましょう。
    • 『スマートフォンでそろばんアプリ』の仕様書。1ページ15分かけてチェックしましょう。
    • ルール：対象　要求仕様書
      • あいまいでないこと
      • 明解であること
      • 矛盾のないこと
      • 設計要素がないこと
    • 1ページ15分。
    • 形態素分析ソフトで解析。
    • 大体A4びっしり書くと500文字。
    • トムさんからもらったエクセルでの解析デモ。
    • 次のフェーズに進むか、差し戻すか。
    • 今感じられた『感覚』が大事。
    • 対処をどうするかどうかをチームで決める。
  • ロギング：
    • 指摘して、書き手に直してもらえなかった事、ありますか？
    • →ドキュメントを書く人の『質』を上げていく事が必要。
    • ※どうやったら質が上がるか？
    • ※書き手は、欠陥と認めてますか？認識してますか？
    • ※欠陥だという気付きを与えていますか？
    • ※フィードバックはコミュニケーション
  • それでは、フィードバックを書いてみましょう。
  • 表現力が必要。
  • 分かるんだけれど直しません、ってのもある
    • 要求仕様策定者の範囲外からの指摘
    • 既知の話に対する指摘

  • インクリメンタルRV
    • 最初の1ページからレビューを始めてしまう
  • バッチ的RV
    • 百ページのSRS


(ここで細谷さんにバトンタッチ)

    • レビュー技法の使い分け
    • やってて違和感あった方居ます？
    • SPI Japanで発表した内容。

    • (1)レビュー計画(仕様書作成前)
      • 実施時期、RV観点、参加者や役割を決定
    • (2)アジャイルインスペクション(仕様書作成序盤)
      • 書けたところの体裁や記述方法等を擦り合わせ/作成序盤の観点例
    • (3)ウォークスルー(仕様書作成中盤)
      • 自信のない部分を/作成中盤の観点例
    • (4)インスペクション(仕様書作成終盤)
      • 作成終盤の観点例
  • アジャイルインスペクションの観点
    • プロジェクトに跨がるドキュメントの質に着目する。
    • ↓
    • これからの記載に展開可能な観点に絞る事が大切。
  • 現場での適用事例?
    • 組織的なアジャイルインスペクションの実施
      • プロジェクトメンバーに特定せず組織的にレビュー可能な領域
  • 過去10回分の分析結果
    • レビューイに修正有無を任せているが、殆どの指摘を受け入れて修正。
    • 設定したレビュー観点外の指摘が出て居らず、レビュー観点により指摘内容をコントロール出来ている。
      • ※狙った観点でのみ抽出させる作業にすることで、作業時間を短く（15分）している節もある。
  • レビューは毎日の習慣…ハミガキのようにするべきだ。
  • 3ヶ月ほど繰り返すと、書き手の質も向上。
    • 曖昧な文章になってないかを見る
    • 定量化すべきところを意識して文章を書くようになった。
  • 15分というタイムボックスの中での作業。
    • 1時間とかだとダレる？
  • 質疑応答タイム

昼食

昼飯はちょうど同じく参加されていたひろうぃん(TwitterID:@heroween)さんと合流し、一緒に学食で食べることに。建物施設内の綺麗さ・充実さ、メニューの安さに驚きつつも手頃な丼物をチョイス。

学生さん達の若い雰囲気に混じって、一回り、下手したらそれ以上年上になる30代のおっさん二人でガッツリと(若干量も多めだった)頂きましたよっと。いやぁ、若いって良いですねぇ〜。(´・ω・｀　)

レビューチェックリスト自慢、っん？

  • 安達 賢二氏、野中 誠氏、細川 宣啓氏
レビューではチェックリストが有効だと言われていますが、チェックリストさえあれば
効果が上がるという簡単な話ではなさそうです。
チェックリストを活用して良いレビューを行うには、何が必要なのでしょうか？
良質のチェックリストでしょうか？レビューの運営方法でしょうか？それともツールの導入でしょうか？
経験豊富なスピーカー陣の議論の中からチェックリストの有効性の本質に迫ります。
  • 進め方
    • 1人ずつ順に、言いたい事を主張します
    • 登壇者同志議論します
    • まとめます
    • （概要）
      • チェックリストの有効性の本質に迫ります（迫りたい）

※ここからのメモは罫線単位で区切っています。罫線のタイミングで講演者が変わってます。

    • 警備員が外から施錠
      • →不在となり業務プロセスに準じて作業を遂行
      • →男性の死亡を確認
    • 在宅中でも外からの施錠で『不在』と表示
      • →バグ？
      • ※ほんの5〜6年前の出来事。
    • バグを見逃してしまった原因
      • システム仕様の妥当性評価が不十分？
      • ビジネス要求を評価していなかった？
      • ビジネス要求の獲得が実施されていなかった？
    • チェックリスト?安全性
      • システム内で認識された状態と観測対象の実際の状態との間にギャップが生じた場合に
      • システムの振る舞いは安全側に倒れる設計になっているか。
    • 状態遷移表で仕様を表現
    • 妥当性
    • 利用シナリオの網羅性
      • 考えられる利用シナリオを全て網羅した上で、システムの仕様が検討されているか。
    • 連想させるチェックリスト…文章中のキーワードを拾っている。


  • システム階層と要求スコープ
  • 仕様と要求の整合性
    • この仕様は、どの要求仕様を実現するためのものか？
  • この仕様（または要求事項）は、ビジネス価値の向上に繋がっているか。（ビジネス価値との整合性）
  • なぜ、こうしたのか。（目的と手段の整合性）


  • システム上の問題点：状態遷移図を書くと良く分かる。
  • 何を書けば問題を防げるか？
  • 不在・在宅…誰得ですか？得する人は誰ですか？
    • 誰のために作ったの？目的意識の欠如もあったりする。
  • 拾えなかったチェックリストを攻めることは出来ない。
  • 事故が起きたときに出しなさい。揚げ足取る為に使ってたりも…
    • 誰得？という基本的な部分が抜けているかも。
  • Q.自社にチェックリストがあったら信用しますか？
  • Q.それは信用十分ですか？
    • 形式的チェックを飛ばす：カラスを飛ばす
  • 最低何があれば良いのか？
  • プロセス
    • こう言う手順でやると失敗率が下がりますよ、というもの。
  • チェックリストに汎用性を持たせる：ドメイン知識も失われていく
    • 強制力も増えて行く。
  • みんなで考えよう：
    • チェックリストの存在は必要か？
    • 必要：どんなものがあれば良いのか？
  • レビュー：自由度が高いために失敗する
  • ↓
  • チェックリストという『制約』を加えることでどう変わるの？


  • チェックリストを活用して良い
  • 良質のチェックリストとは何か？
  • レビューの運営方法？
  • それともツールの導入？
  • チェックリストの有効性の本質に迫る。
  • チェック内容、どうやって確認するの？
  • 踏絵？
    • 妙に現実的
  • 何か古くない？
    • 移植性の問題…
  • どんだけやんのよ！
  • 欠陥指摘ベスト３
    • 誤字脱字（欠陥じゃね〜）
    • 軽微な欠陥
    • 本質的指摘事項
  • 共通のチェックリストは使っていません！
    • 誰かが作ったものって、本当に役に立ちます？
    • 書き物ならWriting High Skillの人が作成してたらOKかも。
    • 同様のモノ：組織標準、各種基準値等々。
    • 有識者が提供することは上手く行かないことが多い。
    • 指示待ちメンバーが増えるだけでは？
      • 自ら学び、失敗を繰り返さない努力のない人は伸びない。
    • 自分たちで作成する事が基本。
      • 自ら考えないと役に立たない。形骸化を防ぐため。
    • 実務から学び取ってもらい、リスト化していく。
  • 私のレビュー概要
  • 主な視点
    • 成果物の利用者の立場など、立場を変えてみる
    • 作業の目的、リスクから見る
    • 利用者像や背景から適切な手段なのかを見る
    • 費用対効果で見る（もっと簡単に出来る有効な手段はない？）
  • レビューを行う際（あるいは前）に確認すること
    • 納期や使い道／次の作業と作業者
    • 作業者の作業状況
    • 作業内容（目的・input情報を含む関連成果物の内容・作業方法）と作業者の理解度合


ここから更に、御三方によるディスカッションへ。内容は追い切れずメモもそこまで取れなかったので、大まかな流れ、内容については下記Togetterを御覧下さい。

ガイドを用いたサンプリングレビューワークショップ

  • 細川 宣啓氏、細谷泰夫氏
レビューは、出来上がったドキュメントを読んで誤りを検出するというスタイルが多いと思います。
今回のワークショップでは、ドキュメントに対して「ガイド」を用いた作業を実施することによって、
読むだけではなかなか検出しにくい指摘を見い出す方法を体験していただきます。
そして、その方法をサンプリングレビューと組み合わせることによって得られる効果について議論し、
皆さんと共有したいと思います。
  • レビュー、うまく行ってますか？
    • 議論の場になって進まない。
    • 分量が多く長時間になる。
  • よくあるレビューの工夫
    • セルフチェック
    • チーム内での公式レビュー
    • アウトプットの方向性を擦り合わせるレビュー
  • 各レビューのフォーカスは明確ですか？
  • 限られた時間でフォーカスを意識せずにレビューすると、偏りや無駄が発生する。
  • プロジェクト依存度：低い
  • 作成序盤で適用可能。
  • 個人レビュー：誤字脱字を事前にチェックしておいて入れておく。
  • 公式レビューでその辺りのチェックは無駄。
    • レビュー戦略として本質的な部分の精査・レビューを行えるようにしておくのはアリ。
  • ワーク１：
  • ガイドをもちいた作業
  • ガイド『入出力』
    • 機能の記述レベルにフォーカスしたレビューを行う為のガイド。
入力 参照する情報・入力される情報・イベント等
↓ 出力を入力からどの様に導出するか？
出力 出力する情報・振る舞い
  • ※どうやって出力を導出するか。
  • 手順：
    • (1).レビュー対象から入力、出力を抜き出す。
    • (2).入力と出力を結びつける判定・処理を真ん中の列に抜き出し、入力、出力と線を結ぶ。
  • 指摘抽出(レビュー観点)
    • 入力：
      • 判定、処理に必要な情報の中身が明示されているか？
      • 値の範囲が明示されているか？
      • 入力元が明示されているか？
      • 参照する情報の所在は明示されているか？
    • 出力：
      • 出力先が明示されているか？
      • 出力の中身が明示されているか？
      • いつ出力されるかが明示明示されているか？
    • 判定、処理：
      • 出力を入力から導出する方法が明示されているか？
  • 記述レベルの合意
    • 結果をうけて、記載すべき記述レベルについて話し合ってみましょう。
  • 学びのポイント
    • レビュー全体を俯瞰して目的に応じたレビュー方法を組み合わせる。
    • レビューで得たい効果を得るための方法を設計する。（今回だとガイドを使った作業）
    • どのレビューを誰が出来るかを意識するとレビューのチャンスが増える。


という感じでこの後のクロージング都合により参加せず退却。

冒頭紹介された『アジャイルインスペクション』についてはもう少し深掘りして追求してみたいな〜とは思いました。
あとは『ガイドを用いたサンプリングワークショップ』について。こちらも視点を変えることで指摘する/指摘される部分を浮き上がらせ、レビューされる/する側双方の質を上げるという点では意味のある試みになるのでは、と実感した次第です。