Downloaded 44 times
More Related Content
はじめよう！レビューのいろは
- 1. はじめよう！ レビューのいろは 山口寛子 （WACATE実行委員会）
- 2. 目次 レビューの現実 レビューとはなにか ピアレビューとはなにか レビューしてみよう レビューの計画 レビューの準備 レビュー会議をしてみよう 修正・振り返り よりよいレビューのためには
- 3. 自己紹介 山口寛子（WACATE実行委員会）１年目（２回め） 金融系SIerで金融系ではないSIをやっている SN：べにちどり（@scarletplover）
- 4. 本日の登場人物（わかばPJ） 太郎くん わかば商店関連プロジェクトの技術リーダー。 次郎くん わかば商店関連プロジェクトのテストメンバー。 設計工程でレビューアーとして プロジェクトに参画しているベテラン 三郎くん わかば商店関連プロジェクトの技術メンバー。 設計を主に担当。
- 5.
- 6.
- 7.
- 8. ある日のわかばPJレビュー① 前と同じだし大丈夫じゃない？ （不安はのこるけど時間ないしまあ） 大丈夫じゃない？ し、してきなし？？？
- 9. ①結末 テスト工程にて・・・ たいへんだ！ バグがいっぱ いだあああ やはり大 丈夫では なかった やはり大丈夫で はなかったかぁ かぁ
- 10. ある日のわかばPJレビュー ② オタクの品質 悪すぎ(ﾟДﾟ) ｺﾞﾙｧ!! あそこも できてな い テスト側の視点だ けでかたるんじゃ ねーよ ここもでき てない 結局どこ 直せばい いんで しょう？ そんなことい う暇あったら テストしｒｙ
- 11. ②結末 あのとき喧嘩してる場合じゃ ああののとときき喧喧嘩し嘩てしる場て合るじゃ 場合 なかった・・・ なかった・・・ じゃなかった・・・ リリース後にて・・・
- 12.
- 13.
- 14.
- 15. レビューの定義 SQuBOk第1版2-14 「レビューとは一般に、ソフトウェア開発工程全般で行 われる見直し作業であり、関係者が参加し多角的に検討 することで、論理の客観性と透明性、構造の妥当性、 フィールドへの適応性等を評価／確認する」 設計・テスト等、様々な開発工程で行われる 静的な見直し作業
- 16. レビューの効能？ ・事前に修正すべき個所を検出・修正することで、 テスト工程等、後工程における修正工数を減らす。 ・メンバーとシステムの認識をあわせる。 ・進捗を確認するためのレビュー・・・ 目的によって、狙う効果はさまざま
- 17. レビューの種類 教育レビュー マネジメントレビュー ピアレビュー プロジェクト終了後レビュー ステータスレビュー
- 18. レビューの種類（たとえば）① 教育レビュー 「プロジェクトに関連する技術的トピックスについて他のス テークホルダーの知識レベルを引き上げる。」 マネジメントレビュー 「上級管理者に情報を提供することにより、製品のリリース、 開発プロジェクトの継続（または中止）、提案の採用（また は却下）、プロジェクトスコープの変更、リソースの調整、 コミットメントの変更を決定する。」
- 19. レビューの種類（たとえば）② ピアレビュー 「作業成果物の欠陥と改善の機会を探す。」 プロジェクト終了後レビュー 「完了直後のプロジェクトまたはフェーズの反省を行い、将 来のプロジェクトのための教訓を得る。」 ステータスレビュー プロジェクトマネージャおよび他のチームメンバーで、マイ ルストーンに対する進捗、発生した問題、識別または制御さ れたリスクを確認する。
- 20. レビューを始める前に レビューの目的はなにか、考える 承認をもらうこと？ 問題を見つけ出すこと？ 確認すること？ 後輩を教育？？
- 21. レビューを始める前に レビューの目的はなにか、考える 承認をもらうこと？ 問題を見つけ出すこと？ 確認すること？ 後輩を教育？？
- 22.
- 23.
- 24. ピアレビューとは ピア⇒同僚の意味 同僚たちに過ちを指摘してもらう作業。 人事評価するものではない。 「作業成果物の欠陥と改善の機会を探す」レビュー 「要求定義、設計、その他の非コード成果物に起因する複雑 な問題の発見と除去には、人の知能が最適」 by インスペクション広めた人（Tom Gilb)
- 25. レビューしないとき 欠陥発生源 要求定義設計開発テスト 要求定義設計開発テスト 欠陥発見
- 26. レビューが目指すもの 欠陥発生源 要求定義設計開発テスト 要求定義設計開発テスト 欠陥発見
- 27. ピアレビューの種類 インスペクション フォーマル •成果物について、インスペクションのルールに従ってチェックを行う。 •大規模プロジェクトに適している。 テクニカルレビュー •技術リーダーが中心となってドキュメント等の問題検出・指摘を行う。 ウォークスルー •非公式なレビュー。ドキュメント作成者がレビューアーに相談する形。 カジュアル
- 28. ピアレビューの種類 インスペクション フォーマル •成果物について、インスペクションのルールに従ってチェックを行う。 •大規模プロジェクトに適している。 テクニカルレビュー •技術リーダーが中心となってドキュメント等の問題検出・指摘を行う。 ウォークスルー •非公式なレビュー。ドキュメント作成者がレビューアーに相談する形。 カジュアル
- 29. テクニカルレビュー 技術リーダーが中心となって、成果物の問題検出・指摘を行うも の。 ・インスペクションよりも非公式（カジュアル）なレビュー。 厳密なルール・データ分析を必要としない。 ※任意で作っても良い ・ウォークスルーよりも公式（フォーマル）なレビュー。 ・中小規模プロジェクトに適している。
- 30. レビューのススメ方 レビュー の計画 レビュー の準備 レビュー 会議 問題修正振り返り
- 31. レビューの出席者 進行役（リーダー） 技術リーダー。レビューアーが検出した問題をまとめ、修 正するか決める。 レビューアー レビューで問題指摘する人。 ドキュメント作成者 ドキュメント作成した人
- 32. レビューのインプット →アウトプット テクニカル レビュー レビューされる 成果物 レビュー計画・ 目的・ チェックリスト etc その他補助資料 （要求仕様など） レビュー記録 修正された成果物 レビュー分析結果 （アンケートなど）
- 33. ピアレビューで大事なこと３箇条 •意識しないで問題を検出することはできない。 •的は絞ろう！ ①どんな問題を検出したい かはっきりさせる •問題検出は先にやろう！ •成果物を直すまでがレビュー ②会議前の準備・レビュー 後のフォローをしっかりと •問題検出ができる環境 ③思いやりをもとう•お互いを尊重する。
- 34.
- 35.
- 36. レビューの計画 レビュー の計画 レビュー の準備 レビュー 会議 指摘内容 修正 振り返り
- 37.
- 38. レビューの計画 ①いつなにを レビューするか 決める ②シナリオを決める③誰を呼ぶかきめる
- 39. ①いつ何をレビューするか決める １．時期 開発工程が次の工程に行く前 大きな作業成果物→ 最初の一步の時点で行うのがよい ２．何の成果物をレビューするか 後の工程にとって重要でクリティカルなもの 複雑でよく確信がもてないもの。よく知らないもの。 変更を何回も加えたもの・・・
- 40. ②シナリオを決める １．このレビューで検出したい問題・欠陥を考える。 ・昔のプロジェクトであった問題？ ・システム上の機能・非機能で重要となるポイント ２．１で考えた問題を見つけられるシナリオを作成。 シナリオは各レビューで２つくらいまで。 ３箇条 その１ ※１回のレビューですべての間違いをすべからく見つけるということは 無理！！ 見つけ出したい問題がたくさんある場合にはレビュー会議の数を 増やす
- 41. ③誰をよぶかをきめる 呼ぶ人の基準① ・成果物の作成者 ・先行成果物の作成者 ・依存する成果物の作成者 ・インターフェイスを持つ成果物の作成者 呼ぶ人の基準② ・レビューで積極的に問題検出してくれる人⇦意外と大事 ※人数は3~7人がベスト！！
- 42. 太郎くんレビュー告知 レビュー成果物 「わかば商店開店キャンペーンWebシステム基本設計書」 （後の工程のインプットになるためクリティカルな成果物と判断） 先行成果物 「わかば商店開店記念キャンペーンWebシステムシステム概要書」 日付・場所 １２月７日（日） マホロバマインズ三浦
- 43. 太郎くんレビュー告知 シナリオ 「インプットアウトプットの条件がシステム概要書の内容 と合致しているかDB設計・画面設計・画面レイアウト・画 面遷移を確認する」 「システム概要書に記載のある非機能要件を満たしている か基本設計書を確認」
- 44.
- 45. レビューの準備 レビュー の計画 レビュー の準備 レビュー 会議 指摘内容 修正 振り返り
- 46. レビューの準備をする人 次郎君 全員 主にレビューアー
- 47. レビューの前の準備 ①レビュー出席者の心得 ３箇条 その３ ②先に問題検出をやってしまおう３箇条 その２
- 48. ①レビュー出席者の心得 思いやりをもってレビューをする！ ・ドキュメント作成者 誤字脱字をなくしておく。感謝の心をもつ。 ・レビューアー 人格批判にならないようにする。関係ない問題を出さない。 ・進行役 レビュー会議がしやすい環境を整える。 ３箇条 その３
- 49. ②先に問題検出をやってしまおう １．レビュー告知であったシナリオにそって成果物を読む ２．検出方法をきめて問題検出 ３．問題記録票を記入 ３箇条 その２ ※シナリオに関係ない誤字脱字は別途、誤字誤植記録票に記入
- 50. ※どうやって問題検出？ ・曖昧な言葉 「など」「とともに」「かんして」 ・ドキュメント同士の比較 ⇔不整合の発見 ・漏れがありそうな場所を狙い打つ 例外処理・異常処理とか
- 51. やってみよう①問題検出 レビューアー次郎さんになったつもりでレビューをしてみましょう。 ・付箋に検出した問題を記述 →優先度の高い問題を３つ選んでください ・誤字誤植・シナリオとは関係ない問題が見つかった場合には シナリオの問題を書いた付箋とは別の色の付箋に書いて下さい。 ・今回の成果物 「わかば商店開店キャンペーンWebシステム基本設計書」 ・シナリオ 「インプットアウトプットの条件がシステム概要書の内容と合致しているか DB設計・画面設計・画面レイアウト・画面遷移を確認する」 「システム概要書にある非機能要件を満たしているか基本設計書を確認」
- 52.
- 53.
- 54. レビュー会議 レビュー の計画 レビュー の準備 レビュー 会議 指摘内容 修正 振り返り
- 55.
- 56. レビュー会議の手順 ①問題記録票 を回収 ②優先度をつ けておく ③問題指摘 ④修正する問 題をきめる ⑤終了の判断 会議直前にリーダが 行うこと実際に会議で行うこと
- 57. 会議直前にリーダが行うこと ①レビューアーから問題記録票を回収 どのくらい問題が検出できているか確認 ②問題記録票の内容に優先順位をつけておく レビュー会議を円滑に進めることができる。
- 58. レビュー会議で行うこと ③問題指摘 類似の問題点も確認 ④修正する問題をきめる 優先度はどれが高い？ ⑤終了の判断 シナリオで検出できる問題は検出しきったといえる？
- 59. ここでマインドの再確認 思いやりをもってレビューをする！ 人格批判にならないこと。 シナリオにそって レビューしていること ３箇条 その３ ３箇条 その１
- 60. やってみよう②レビューその０ 役割決め ①太郎くん（リーダー）を決めて下さい。 年齢が一番若い人（自称でかまいません） WACATEの参加回数が一番少ない人 ②三郎くん（ドキュメント作成者）を決めて下さい。 年齢が一番高い人（自称でかまいません） WACATEの参加回数が一番多い人 ③太郎くんでも三郎くんでもない方々は次郎くんです。 ④太郎くん・三郎くんは役割カードを受け取ってください。
- 61. 太郎くんカード 太郎くんは本日のレビューのリーダーです。 次の打ち合わせがせまっており、三郎くんの作った設計書を20分でレビューしなければな りません。 昨今社内では品質に関するトラブルが多く、ピアレビューを会社で決められたチェックリス トの通りにやるようにと経営層から言われています。 会社で決められているチェックとは以下のとおりです。 ①レビューごとにシナリオを決めて、シナリオにそってレビューすること。 ②検出された問題について、類似する問題がないか確認すること。 ③修正する問題がどれか、会議の出席者で確認すること。 ④シナリオによって検出されるべき問題が検出されたことをレビュー会議終了時に確認する こと。
- 62. 三郎くんカード 三郎くんはドキュメント作成者です。今回の基本設計書を作 成したのも三郎くんです。 三郎くんはとても優秀な技術メンバーですが、最近沢山の仕 事をかかえていて、なかなか設計書をかく時間がとれません。 今回レビュー対象となった基本設計書については標準のフォー マットに合わせて書き終えましたが、品質等、もっと考えなけ ればならないことがあったのではないかと不安に思っています。 なお、今までのレビュー会議は毎回見当はずれな指摘が多 かったり、指摘がなかったりで、うまくいっていません。今回 はなんとかうまくレビュー会議をできるようにしたいと考えて います。 三郎くん役の方には指摘される側の役をやっていただきます。 指摘のされ方によって指摘される側がどのように感じるかを、 レビュー会議の中でふせんにメモしてください。ふりかえりで 使うので、ポジティブなもの・ネガティブなものを挙げて下さ い。
- 63. やってみよう②レビューその１ ざっと優先度をつけてみよう！ ①太郎くんはシナリオに沿って検出された問題のみを班員から集め て下さい。 ②今から5分で、太郎くんは検出された問題の優先度をつけてくだ さい。 次郎くん・三郎くんはリーダーのフォローをお願いします。 ※この後、レビュー会議を開いてもらいます。優先度は暫定でかまい ません。 三郎くんは５分間で役作りをお願い致します。
- 64.
- 65. やってみよう②レビューその２ ２０分間でレビュー会議をしてみよう！ ①三郎くんに指摘を行う想定で、レビュー会議を行って下さい。 ②思いやりを持って、かつ的確に問題指摘を行って下さい。 ③先ほどつけた優先度にそって、順番に問題指摘を行って下さい。 ④類似した問題がドキュメントにないか確認してください。 ⑤実際に修正するべき問題を決めて下さい。
- 66.
- 67.
- 68. 修正・ふりかえり レビュー の計画 レビュー の準備 レビュー 会議 指摘内容 修正 ふりかえ り
- 69.
- 70. 修正・振り返り 指摘内容修正 ①修正 •ドキュメント作成者 ②フォロー •主に進行役 ３箇条 その３ ③振り返り •全員（会議）
- 71. ①修正 ３箇条 その３ ドキュメント作成者が、誤植やレビューで指摘された内容を直 す。 レビュー記録 誤字誤植一覧表 修正修正後の成果物
- 72. ②フォローアップ 修正後の成果物 レビュー記録 フォロー 完成成果物 主に進行役の人が、修正後の成果物を確認する ・レビュー内容が反映されているか ・修正内容に問題がないか ３箇条 その３
- 73. ③ふりかえり レビュー記録ふりか えり 反省 アンケート 再発防止 レビューの プロセス改善 レビューの チェックリスト etc レビューの内容分析や結果について振り返り →次のプロジェクトに活かす ３箇条 その３
- 74. やってみよう③ふりかえり ①反省アンケートに記入してください。 ②反省アンケートによって以下のことを話あってください。 ・レビュー会議で問題があった点・良かった点・改善する べき点 ・自分が職場に持って帰ることができること
- 75.
- 76. 本講でお話したこと レビュー・ピアレビューとはなにか ピアレビューのやり方 ピアレビューで大事なこと
- 77. とはいっても・・・ 時間がなくて人が集まれないですー →メール等を使って非同期のレビューにする？ テレビ会議を使ってみる？ 時間がなくてレビューアーが準備できませんー →レビューの冒頭に概要説明＆レビューアーが読む時間をもう ける？ ※もっと知りたい方は参考文献「ピアレビュー－高品質ソフト ウェア開発のために」参照
- 78. ピアレビューで大事なこと３箇条 •意識しないで問題を検出することはできない。 •的は絞ろう！ ①どんな問題を検出したい かはっきりさせる •問題検出は先にやろう！ •成果物を直すまでがレビュー ②会議前の準備・レビュー 後のフォローをしっかりと •問題検出ができる環境 ③思いやりをもとう•お互いを尊重する。
- 79. ※注意 さっと流してしまったものは予稿集を見てください。 予稿集（12月5日（金）夜アップロード） ※補足スライドを入れた完全版を後ほど公開します。
- 80. 参考文献 Karl E.Wiegers著、大久保雅一監訳 「ピアレビュー－高品質ソフトウェア開発のために」 日経BP社、2004年 Capers Jones著, Olivier Bonsignour著, 小坂恭一翻訳 「ソフトウェア品質の経済的側面」 共立出版、2013年 森崎修司著 「なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー」 日経BP社、2013年
- 81.