JaSST_17Hokkaido_Slide

Size: px

Start display at page:

Download "JaSST_17Hokkaido_Slide"

あきみひらみね
5 years ago
Views:

1 新入社員が多い中で効果的なレビューを行うための方法レビューの準備からフィードバックまでの工夫ワークスアプリケーションズ風間裕也

2 目次会社と自組織の特徴レビューの位置づけと特徴レビューの改善内容フィードバックの具体例フィードバック前後の指摘内容数の変化レビュイーの意識の変化現場の声まとめと今後の展望 2

3 会社と自組織の特徴

4 会社紹介商号設立事業概要従業員数株式会社ワークスアプリケーションズ 1996 年 7 月大手企業向け基幹業務パッケージ COMPANY および HUE の開発販売サポート連結 5,631 名 (2016 年 6 月末日時点 ) インド工科大学北京大学をはじめとしたアジア TOP 層の IT 人材を多数獲得大手企業向け ERP パッケージシェア 50% で 6 年連続 No.1 日本の大手企業の約 3 割 1,300 企業グループ超が採用世界初の人工知能型ビジネスアプリケーション SHANGHAI NEW YORK TOKYOLOS ANGELS CHENNAI OSAKA NAGOYA SINGAPORE HIROSHIMA FUKUOKA TOKUSHIMA 人工知能によるビッグデータ解析学習分散処理技術による高速処理 4

5 自組織の特徴開発と QA の距離が近い設計段階で指摘できる多数の新人が配属された基本的な部分から伝える必要ありパッケージ製品の設計を教える必要あり開発チームの人数が多い全員に周知徹底させるのが難しい 5

6 レビューの位置づけと特徴

7 レビューの位置づけレビュー形式設計レビュー不具合修正の方針レビューも含むレビュー参加者開発者開発リーダー QA 管理方法 ( 公式 ) 開発標準プロセスに含まれるチケット/ タスクでレビュー実施を管理 7

8 レビューの特徴 2 カ月で約 100 回のレビューに参加した結果新人には以下の特徴があった必要な情報が資料に載っていない何が必要なのか分かっていない同じような指摘が多い毎回指摘をしていて大変 8

9 レビューの改善内容

10 改善内容次回のレビューをより良いものにするために新人でもレビューに必要な情報を理解できる最初に学ぶべき箇所を理解できることを目標に改善を試みました 10

11 方法の検討ベテランからの口伝新人に比べ人数が少ないので伝えきれないチェックリスト意図を理解してもらうことが難しい優先度が分かりづらいフィードバック資料意図も含めて理解してもらえるまず気にすべきことが分かる 11

12 フィードバック時の工夫資料の工夫具体例 ( 実例 ) を示す分かるけど実践ではと言わせない方法の工夫チーム MTG を行脚し直接説明全員が目を通し資料を理解質疑応答で細かい所もフォロー 12

13 フィードバックの具体例

14 FB 例 1 ~ 影響範囲 ~ [ 影響範囲 ] < 対象機能対象画面 > ページ < 対象パス > src/main/java/jp/co/worksap/foo/bar/.java < 影響範囲詳細 > ページにしか利用していないので影響はありません 14

15 FB 例 1 ~ 影響範囲 ~ [ 影響範囲 ] < 対象機能対象画面 > ページ < 対象パス > src/main/java/jp/co/worksap/foo/bar/.java 指摘事項なぜ影響なしと言えるのかその判断の根拠が書かれていない < 影響範囲詳細 > ページにしか利用していないので影響はありません 15

16 FB 例 1 ~ 影響範囲 ~ [ 影響範囲 ] < 対象機能対象画面 > ページ < 対象パス > src/main/java/jp/co/worksap/foo/bar/.java < 調査 > 方法 ( 方法 Grep 対象の文字列や拡張子など ) : 呼び出し階層で検索修正するメソッド名 getfoobarid で Grep 記載例文字列検索 (Grep) などを用いて影響が無いと判断した理由を記載する < 影響範囲詳細 > 呼び出し階層で検索した結果今回の用途以外で呼ばれている部分は存在せず Grep した結果 src/main/java/jp/co/worksap/foo/bar/.java が出てきたがファイル内の private 関数である getfoobarid() を呼び出しているため関係無し 16

17 FB 例 2 ~ ファイルパス ~ [ 影響範囲 ] < 対象機能対象画面 > ページ < 対象パス >.js < 影響範囲詳細 > より今回のページ以外に影響はありません 17

18 FB 例 2 ~ ファイルパス ~ [ 影響範囲 ] < 対象機能対象画面 > ページ < 対象パス >.js 指摘事項違うパスに同じファイル名が存在している可能性がある < 影響範囲詳細 > より今回のページ以外に影響はありません 18

19 FB 例 2 ~ ファイルパス ~ 1 デバイスの違い (PC とスマートフォン ) src/main/java/jp/co/worksap/pc/ 以下を調査していたが src/main/java/jp/co/worksap/smp/ 以下でも同様の修正が必要だったデバイスの想定漏れに気付けた 2 似たような画面ユーザー情報登録画面の修正をしていたがユーザー情報編集画面も同様の修正が必要だった類似画面の想定漏れに気付けた 19

20 FB 例 3 ~ 新規と既存 ~ < 修正内容 > 既存テーブルに新規カラムを追加 [ 影響範囲 ] < 対象機能対象画面 > ページという新規ページを作成 < 影響範囲詳細 > 前回の出荷時点に新たにカラムを加えただけなので影響なしまた新規ページを作成しただけなので既存部分には影響なし 20

21 FB 例 3 ~ 新規と既存 ~ < 修正内容 > 既存テーブルに新規カラムを追加 [ 影響範囲 ] < 対象機能対象画面 > ページという新規ページを作成指摘事項 1 insert into VALUES (foo, bar, baz); というカラム指定なしの insert 文のSQLがあった場合不具合になる可能性があるテーブル名でGrep < 影響範囲詳細 > 前回の出荷時点に新たにカラムを加えただけなので影響なしまた新規ページを作成しただけなので既存部分には影響なし 21

22 FB 例 3 ~ 新規と既存 ~ < 修正内容 > 既存テーブルに新規カラムを追加 [ 影響範囲 ] < 対象機能対象画面 > ページという新規ページを作成指摘事項 2 作成した新規ページ上で入力したデータを DB に insert する場合そのデータを取り出す画面も対象になるテーブル名で Grep < 影響範囲詳細 > 前回の出荷時点に新たにカラムを加えただけなので影響なしまた新規ページを作成しただけなので既存部分には影響なし 22

23 FB 例 4 ~ 初期設定 ~ 概要結果一覧画面において表示順序を変更できる機能を追加元々は名前順になっていたが更新日付が最新から順になる方が分かりやすいので初期表示は更新日付の降順にする 23

24 FB 例 4 ~ 初期設定 ~ 指摘事項既存ユーザを考え初期設定は以前と同じ = 名前順にすべき概要結果一覧画面において表示順序を変更できる機能を追加元々は名前順になっていたが更新日付が最新から順になる方が分かりやすいので初期表示は更新日付の降順にするパッケージ製品においては既存動作保証が重要 24

25 FB 例 5 ~ 表示文言 ~ 概要に関する CSV 取り込みができるようにしますその中で自動実行フラグの項目に関しては 0 か 1 の値が入ります 0 が自動実行 OFF 1 が自動実行 ON になりますそれ以外の値が入った場合入力値が誤っていますというエラーメッセージを表示します 25

26 FB 例 5 ~ 表示文言 ~ 概要に関するCSV 取り込みができるようにしますその中で自動実行フラグの項目に関しては 0か1の値が入ります 0 が自動実行 OFF 1 が自動実行 ON になりますそれ以外の値が入った場合入力値が誤っていますというエラーメッセージを表示します指摘事項 1 フラグはシステム用語なので表示項目に使うべきではない 26

27 FB 例 5 ~ 表示文言 ~ 概要に関するCSV 取り込みができるようにしますその中で自動実行フラグの項目に関しては 0か1の値が入ります 0が自動実行 OFF 1が自動実行 ONになりますそれ以外の値が入った場合入力値が誤っていますというエラーメッセージを表示します指摘事項 2 メッセージを見たお客様が次のアクションをどのように行えば良いか分からない 27

28 FB 例 5 ~ 表示文言 ~ 記載例一般用語を用いる概要に関するCSV 取り込みができるようにしますその中で実行方法の項目に関しては 0か1の値が入ります 0が手動実行 1が自動実行になりますそれ以外の値が入った場合入力値が誤っています手動実行の場合 0 自動実行の場合 1 を入力してくださいというエラーメッセージを表示します記載例お客様がどのように直せば良いか分かる文言になっている 28

29 フィードバック前後の指摘内容数の変化

30 FB 前後の指摘内容数の変化既存動作保証影響範囲テスト設計 25% 減 57% 減 115% 増前後前後前後 30

31 FB 前後の指摘内容数の変化既存動作保証影響範囲テスト設計 57% 減 25% 減 115% 増フィードバック内容を活かし事前に開発者自身が気を付けてレビューに臨んだ前後前後前後 31

32 FB 前後の指摘内容数の変化既存動作保証影響範囲テスト設計フィードバック 57% 減内容を活かした 25% 減 115% 新人の増調査方法では不十分なケースがあった前後前後前後 32

33 FB 前後の指摘内容数の変化既存動作保証影響範囲テスト設計事前にきちんと調査し 115% 増論理的に示しているため 25% 減 57% 減実装前にもかかわらずテストに関する話まで伝えることができた前後前後前後 33

34 レビュイーの意識の変化

35 レビュイーの意識 [ 品質 ] Q1. レビューで製品の品質は良くなったと思いますか? 66% 33% 1% 1. 良くなったと思う 2. 少し良くなったと思う 3. あまり良くならなかったと思う 4. 良くならなかったと思う 35

36 レビュイーの意識 [ 価値 ] Q2. 今回のレビューは上辺だけの実施でなく実質的な価値があったと思いますか? 69% 30% 1% 1. 価値があった 2. 少し価値があった 3. あまり価値が無かった 4. 価値が無かった 36

37 レビュイーの意識 [ 今後 ] Q3. レビューのフィードバックとして具体例を用いた指摘事項を紹介しましたこれは自分自身でのレビュー前確認で役立ちそうですか? 75% 25% 1. 役立つと思う 2. 少しは役立つと思う 3. あまり役立たないと思う 4. 役立たないと思う 37

38 現場の声

39 メンバーの感想影響範囲調査もレビュー時の指摘やフィードバック資料によって自分で考慮漏れに気付くことができました当時は配属数か月で右も左もわからないという状況の中レビューという場で不足している観点をおぎなってくれたことは非常にありがたかったです修正方法たくさんある中一番パッケージとしていい方針を指摘いただいたので良かったです 39

40 リーダーの感想大きかったと感じるのは新人のあまり深く考えずに何となく直してましたという姿勢が改善されたことだと思いますチーム組織にとらわれず皆で良い製品にしていこうというマインドが徐々に根付きつつあると思っていますレビューを徹底することでメンバーの調査や修正による影響の考慮などマインド的な面への影響はまちがいなくあると思う 40

41 改善要望今のフローだと工数を無駄にしない点からはまだ改善の余地があるように感じていますレビューの工数を減らす仕組みが必要だと思う資料作成や差戻しで時間がかかっていると思うのでテンプレートを増やすなどの工夫が必要 41

42 まとめと今後の展望

43 まとめ新入社員が多い中でレビューを効率よく行うための方法として実例入りのフィードバック資料を作成したフィードバックは直接説明することで全員に理解してもらえた結果としてより本質的な指摘ができるようになりレビュイーからも良い反応を貰うことができた 43

44 今後の展望フィードバック資料の第 2 弾以降を作成する資料は段階的にやるべきことを示すようにするフィードバック資料に加え理解度の確認ができる形にする今回の施策がどのように品質向上に寄与したのか出荷後の不具合を計測し定量的に示す 44

45 ご清聴ありがとうございました 45

[ ]スマートセミナーバージョンアップリリースノート

[ ]スマートセミナーバージョンアップリリースノートスマートセミナー 2.0 バージョンアップリリースノート株式会社シャノン 2010/9/18 1. はじめに...3 本リリースノートについて... 3 追加修正される機能とユーザーへの影響について... 3 2. 今回追加された新機能のご紹介...5 会場 ID の置換機能... 5 カレンダー入力インターフェースの変更... 7 活動履歴一覧機能の個別セミナー対応... 7 申込者詳細の活動履歴の日付順表示...