[ETロボコン2019]ETロボコンで学ぶレビュー技法 / etrobochu4-20191007

[ETロボコン2019]ETロボコンで学ぶレビュー技法 / etrobochu4-20191007

この資料は、2015年10月3日(土)に行われた、 「ETロボコン2015 中四国地区 秋の独自勉強会」で 行った演習内容を元に再構成したものです。

SlideShare版はこちら。
https://www.slideshare.net/tamagawaconan/et-53651875

以下のサイトで紹介されています。
オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 > レビューで検出する問題種別の事例
https://blogs.itmedia.co.jp/morisaki/2015/10/_-_et2015.html

3716cf98e52588e91ba25e54b3f61255?s=128

Kazuhiro Kawachi

October 03, 2015
Tweet

Transcript

  1. もう、審査で減点されない︕ ETロボコンで学ぶレビュー技法 2015年10⽉7⽇ ETロボコン中四国地区実⾏委員会 実⾏委員 河内 ⼀弘

  2. 2 はじめに この資料は、2015年10⽉3⽇(⼟)に⾏われた、 「ETロボコン2015 中四国地区 秋の独⾃勉強会」で ⾏った演習内容を元に再構成したものです。 会場︓福⼭⼤学 宮地茂記念館(広島県福⼭市)

  3. ETロボコンといえば、モデル審査ですが・・・ 3 モデルのレビュー、できてますか︖

  4. 4 今年のモデル審査、頑張っているのに、 少しのミスで評価を下げたチームがチラホラ。 ・・・モッタイナイ。

  5. 5 レビューといえば、 「いくら⾒ても問題を⾒つけられない…」 「うちは初⼼者ばかりだし…」 「やってもあまり効果がないんじゃない︖」 と感じている⼈も多いのではないでしょうか。

  6. 6 でも、こうした問題は、 レビューのやり⽅を⼯夫すれば解決できます︕ ETロボコンに限らず、仕事や学業でも役⽴つ (かもしれない) レビューを体験してみましょう︕

  7. 7 レビューの種類 マネジメントレビュー 管理者が、開発状況の把握や承認のために⾏う オーディット 法令や規則に沿っているかチェックするために⾏う ピアレビュー 成果物に問題がないかチェックするために⾏う

  8. 8 今回取り扱うレビュー マネジメントレビュー 管理者が、開発状況の把握や承認のために⾏う オーディット 法令や規則に沿っているかチェックするために⾏う ピアレビュー 成果物に問題がないかチェックするために⾏う

  9. 9 今回取り扱うレビュー ピアレビュー 成果物に問題がないかチェックするために⾏う ウォークスルー 作成者主導のカジュアルなチェック テクニカルレビュー 技術リーダー主導の成果物チェック ・経験ベース ・シナリオベース(今回取り上げる内容)

    インスペクション ルールに沿った厳格なチェック
  10. 10 レビュープロセス レ ビ ミ テ ン グ 再 作

    業 フ ロ ア プ 計 画 キ ク オ フ ミ テ ン グ 個 々 の 準 備 ( 前 準 備 ) ココはやってる ココが重要︕ JSTQB Foundation Levelシラバスで定義されているプロセス
  11. 11 レビューは段取り⼋分︕ 1. 計画 ü ⼈選する ü 役割を決める ü レビューのやり⽅を決める

    ü どこをレビューするか決める ü レビューをはじめる条件を決める。 2. キックオフミーティング ü レビュー対象物を配布する。 ü 参加者にレビューの⽬的とやり⽅を説明する。 3. 個々の準備(前準備) ü 各⾃でドキュメントをチェックする。 ü ⾒つけた⽋陥、質問、コメントをメモする。
  12. 12 4. レビューミーティング ü 議論を⾏い、結果を記録する。 ü ⽋陥について述べ、扱いを決める。 5. 再作業 ü

    ⾒つけた⽋陥を修正する。 ü どのように⽋陥を直したか記録する。 6. フォローアップ ü ⽋陥を処理したかチェックする。
  13. レビューのポイント 「観点」を決める 13

  14. 14 レビュー観点とは このレビューで、 「どのような問題を⾒つけるべきなのか」 を考えた結果導き出された、注⽬すべき点

  15. 15 どこから観点を⾒つけるのか v 規約類から ü 参加規約 ü 競技規約 ü 審査規約

    v 技術情報から ü 開発プラットフォーム ü プログラミング⾔語 ü UML⽂法 v 既存の成果物や経験から ü 前回のモデルやソースコード ü 過去の経験や失敗事例、先輩からの引き継ぎ事項 ü 他チームのモデル ü これまでの調査、分析結果
  16. 16 観点を⾒つける 審査基準に着⽬します。 [A1] [A2] [A] ⾒つけた観点には[A1][A2]といったIDを付けておきます。

  17. 観点を⾒つける 17 [B1] [B2] [B3] [B]

  18. 観点の詳細化 18 [B2-1] 振る舞い図の要素として、クラス図で定 義したオブジェクトが使われているか︖ (システム全体の振る舞いじゃないよ︖) [B2-2] 振る舞い図は審査課題で選択したことの 説明になっているか︖ (課題と関係ないこと書いてないよね︖)

    <詳細化の例> [B2-3] 振る舞い図は正確に動作するか︖ (ちゃんと動くよね︖) [B2]
  19. 19 チェック⽅法を決める ID 観点 どこを どのように B2-1 振る舞い図の要素として、 構造で定義したものが使 われているか︖

    シーケンス図、コミュ ニケーション図が描か れている箇所 ライフラインの名称が クラス名と⼀致してい ることを確認する。 B2-2 振る舞い図は審査課題で 選択したことの説明に なっているか︖ 審査課題の記述箇所と 振る舞いについて説明 しているページ 振る舞いの内容を調べ、 審査課題と⼀致してい るか確認する。 B2-3 振る舞い図は正確に動作 するか︖ シーケンス図、コミュ ニケーション図が描か れている場所 メッセージを辿りなが ら、ライントレース⾛ ⾏が継続できるか確認 する。 ↑メンバー間で認識が異ならない程度まで 具体的に書く。
  20. 20 結果を記録する No. 問題点 観点 修正⽅法 1 クラス図では「ライントレーサ」 クラスがあるが、シーケンス図に ライントレーサが出てこない。

    B2-1 ライントレーサを追加する。 2 3
  21. 〜演習〜 ⾃分たちのモデルを レビューしてみましょう。 21

  22. 22 今回取り上げる⽅法 v 名古屋⼤学の森崎修司先⽣が提唱している技法 「シナリオレビュー」を参考にしました。 v 特徴 • 「重要な問題」を早期かつ確実に検出できる。 •

    レビューアの勘や経験、そのときの気分などに左右されにくい。 • 前準備をきちんと⾏う必要がある(必要な情報や知識も含め)
  23. 対象物と配布資料 23 配布物 ・レビュー観点シート ・レビュー記録シート ・ETロボコン2015審査規約 ・A3⽩紙 レビュー対象 ・地区⼤会提出モデル <レビュー観点シート>

    <レビュー記録>
  24. ブレーンストーミング 24 ⾒つけたい問題を書き出していきます。 審査規約とか [気になった点] ・⽂字がつぶれて読みづらい です。残念︕ ・構造と振る舞いの⼀貫性が ない。⾻太さが⾜りません。 ・責務が集中しすぎています。

    激おこぷんぷん丸です。 審査コメントとか 過去の失敗とか
  25. 25 <観点のトリアージ> ⾒つけたい問題を絞り込み、 モデル観点シートに 書き出します。 1 2 3 ※今回は時間の都合で3つまでとします。 絞り⽅の例

    ・後で⼤きな問題になりそうなもの 審査で⼤減点されそうなもの、 他の箇所や後の作業に影響しそうなもの。など ・確認箇所が多そうなもの
  26. 観点を決めます 26 問題を⾒つけるためには、 具体的にどんなことに注⽬しないといけないのかを考え、 書きます(今回は3つまでとします) クラス図とシーケンス 図の⼀貫性が取れてい ないミスをなくしたい。 シーケンス図に登場するオブ ジェクトがクラス図にも記載

    されているか︖ シーケンス図のメッセージの 名前がクラス図の操作名と⼀ 致しているか︖ シーケンス図のオブジェクト 間のメッセージとクラス図の 関連線が⼀致しているか︖
  27. 探し⽅を決めます 27 どこをどういう⼿順で探していくのかを記載します。 シーケンス図に登場する オブジェクトがクラス図 にも記載されているか︖ クラス図とシーケ ンス図の記載箇所 ・2ページの2-1 ・3ページの3-2

    クラス図のクラス名を⾚ペンで囲み、 シーケンス図に同じオブジェクト名が出 ていたら、そこも⾚ペンで囲む。 ⽚⽅にしかなければ、レ印でチェックす る。 記載の細かさは、 「レビュー参加者が同じ認識を持てる程度」がベスト。 (話し合いながら、細かすぎず、⼤雑把すぎないところを探しましょ う)
  28. 実際にモデルを調べます。 28 観点シートに沿ったやり⽅ですすめましょう。 シーケンス図に登場する オブジェクトがクラス図 にも記載されているか︖ クラス図とシーケ ンス図の記載箇所 ・2ページの2-1 ・3ページの3-2

    クラス図のクラス名を⾚ペンで囲み、 シーケンス図に同じオブジェクト名が出 ていたら、そこも⾚ペンで囲む。 ⽚⽅にしかなければ、✖印でチェックす る。 1つめのシナリオが終わってから、次のシナリオへ進みましょう。 本来は観点毎に分担して調べるのですが、今回は皆で⾒ていきましょう。
  29. 29 結果を記録しましょう クラス図では「ライントレーサ」 クラスがあるが、シーケンス図に ライントレーサが出てこない。 B2-1 観点IDを記録しておけば、 どういう種類の指摘が多いのか、分析するのに役⽴ちます。

  30. 発表タイム 30 観点をどのように決めたか どんな問題を⾒つけられたか

  31. 31 成功させるポイント v ⽬的をはっきりさせる ü 「このレビューで、どんな問題を⾒つけたいのか︖」をはっ きりさせ、メンバー間で認識を合わせておくこと。 ü 段取り⼋分。準備が重要。 ü

    この技法を使うポイントをうまく絞る(トリアージ) ⾒つけたい問題の重み付けが重要 v メンバーに合った確認⽅法を決める ü 「メンバーが共通の認識を持てる確認⽅法」を記載。 細かすぎず⼤雑把すぎずのポイントを探す。
  32. 32 気をつけるポイント v 勘と経験も、うまく組み合わせる ü シナリオ化することで、勘と経験を活かしにくくなるデメ リットもある。うまく使い分ける。 経験ベースのレビューも組み合わせ、そこで⾒つかった問題 を観点リストに取り込み、徐々に形式知化していくのがよい。 v

    なんでもかんでも⽬視に頼らない ü 静的解析ツールに頼った⽅が確実に⾒つけられるものもある。 ü 中にはテストで⾒つけた⽅が低コストなものもある。
  33. 33 メリット v ノウハウを引き継げる ü レビュー観点や、その調べ⽅を後輩へ引き継げる。 モデルやソースを渡すだけだと、悪い点まで引き継がれる。 ノウハウを引き継げば、悪しき⾵習を断ち切れ、同じ失敗を 繰り返さなくなる。 v

    やったことが形に残る ü どこをどのように調べたのか記録が残り、⾒直ししやすい。 ü ⽂章化することでメンバーの意識を合わせやすくなる。
  34. 34 メリット v 時間を⾒積もれるようになる。 ü ⼿順が明確なので、繰り返すことでレビュー時間を⾒積もる ことができるようになる。 ü やみくもに時間を消費することがなくなる。 v

    不⾜スキルや調査漏れがわかる ü スキルや調査が⾜りてないと、観点を挙げることができない。 ü ⾃分たちの⼒や取り組みのどこが⾜りないのかがわかる。
  35. 35 参加者の感想 こういうやり⽅は仕事でも経験がなかったが、 確実に狙った問題を⾒つけられ、効果がありそ う。 最初に、⾒つけたい問題や観点を決め るのが難しい。 前準備にも確認作業にも時間がかかる。 計画や優先順位付けが重要そう。

  36. 36 参加者の感想 観点を書き出すことによって、いろいろな効能がありそうですね。 レビュアーによってレビューの品質がまちまちになるの防げる、 レビューを機械的に、素早く、繰り返し⾏えることによる品質の 向上など。 複数⼈で観点を出し合うことでいろいろ発⾒もありそうです。引 き継ぎにも効果絶⼤ですね。 今までの「なんか変なとこないか⾒といて」から⾶躍的にレベル アップできそうです。明⽇から仕事でも使っていきます。

  37. 参考⽂献・引⽤ 37 ソフトウェアテスト教科書 JSTQB Foundation 第3版 http://amzn.to/1FA7Atx 間違いだらけの設計レビュー [改訂版] 森崎

    修司 著 http://amzn.to/1LiS1Zo ETロボコン2015 審査規約 http://www.etrobo.jp/2015/gaiyou/shinsakiyaku.php ETロボコン2015 実施説明会資料 http://www.etrobo.jp/2015/taikai/image/PDF/01etrc2015_zent aisetumei.pdf
  38. ETロボコンの情報はこちらから︕ 38 http://etrobo.jp/ みんなでETロボコンに参加して、 設計スキル、品質スキルを⾼めましょう︕

  39. END 39