「超」やさしいレビュー～開発とQAに壁はない！～

株式会社ワークスアプリケーションズ
風間 裕也
1会社紹介商号

株式会社ワークスアプリケーションズ

設立

1996年7月

事 業 概 要大手企業向け基幹業務パッケージ「COMPANY」および「HUE」の開発・販売・サポート

従 業 員 数

連結 7,599名 (2017年6月末時点)

大手企業向けERPパッケージ市場
7年連続シェアNo.1※
1,300企業グループ超が採用

グローバルR&Dを推進

世界初の人工知能型ビジネスアプリケーション

SHANGHAICHENNAISINGAPORE

NEW YORKTOKYO LOS ANGELSOSAKANAGOYAHIROSHIMAFUKUOKA
TOKUSHIMA

人工知能によるビッグデータ解析・学習
分散処理技術による高速処理

2※市場占有率推移（パッケージ市場） 販売社数シェア
出典：株式会社富士キメラ総研 ソフトウェアビジネス新市場 2011-2017年版（2010-2016年度）

Agenda●今回の前提共有のためのアンケート●

レビューを行う目的●

実際にレビュアーを体験してみよう●

レビューに参加するハードルを下げるコツ●

今後のレビューのかたち3

本日のターゲットとゴール●発表を聞いてほしいターゲット– とにかくレビューをこれからしないといけない– レビューをやっているが効果が薄いと悩んでいる●

発表のゴールとして感じてほしいこと– 気軽に行うレビューの方法もある

易しい
易しい – レビューを難しく考える必要はない
優しい優しい – レビュイーに対して厳しくあたる必要はない
4

今回の前提共有のためのアンケート

5「レビュー」といっても様々●●「レビュー」は、各組織で様々な形、方法があります
この章では、皆さんの組織でのレビュー状況についてアンケートを取ります–

レビューの種類–

レビュー方法–リーディング技法–

レビューを行うタイミング●

複数当てはまる、少しでも当てはまる場合は挙手を！

●これにより前提の認識合わせを行います6質問1：レビューの種類
要求定義

テストケース
レビュー

要件定義
基本設計
詳細設計

機能設計
レビュー

受け入れテスト
システムテスト
結合テスト
単体テスト

コーディング

コードレビュー
出典：JaSST'12 Tokyo 鈴木三紀夫 「Wモデルとは何か」
http://jasst.jp/symposium/jasst12tokyo/pdf/D4-1.pdf を元に作成

7質問1：レビューの種類
要求定義

テストケース
レビュー

要件定義
基本設計
詳細設計

今回
話す内容

機能設計
レビュー

受け入れテスト
システムテスト
結合テスト
単体テスト

コーディング

コードレビュー
出典：JaSST'12 Tokyo 鈴木三紀夫 「Wモデルとは何か」
http://jasst.jp/symposium/jasst12tokyo/pdf/D4-1.pdf を元に作成

8質問2：レビュー方法
インスペクション…最も公式的なレビュー●
チームレビュー…チームにより実施される●
パスアラウンド…成果物をレビュアーへ配布、回覧する●
ラウンドロビンレビュー…全員が順番に司会者とレビュアーになる●
ピアデスクチェック…熟練者のレビュアーと実施する●
ウォークスルー…形式的ではなく、参加者が質問やコメントする●
ピアレビュー…作成者以外と気軽に行う●
アドホックレビュー…近くの同僚に声をかける非公式なレビュー●
ペアプログラミング…プログラミング時に他者視点を取り入れる●

9

出典：SQuBOK策定部会（2014） 『ソフトウェア品質知識体系ガイド（第2版） －SQuBOK® Guide V2－』 オーム社．

質問2：レビュー方法
インスペクション…最も公式的なレビュー●
チームレビュー…チームにより実施される●
パスアラウンド…成果物をレビュアーへ配布、回覧する●
ラウンドロビンレビュー…全員が順番に司会者とレビュアーになる●
ピアデスクチェック…熟練者のレビュアーと実施する 今回話す内容●
ウォークスルー…形式的ではなく、参加者が質問やコメントする●
ピアレビュー…作成者以外と気軽に行う●
アドホックレビュー…近くの同僚に声をかける非公式なレビュー●
ペアプログラミング…プログラミング時に他者視点を取り入れる●

10

出典：SQuBOK策定部会（2014） 『ソフトウェア品質知識体系ガイド（第2版） －SQuBOK® Guide V2－』 オーム社．

質問3：リーディング技法●

CBR(Checklist-Based Reading)–●

DBR(Defect-Based Reading)–●

要求レベルのユースケースを使用して読む技法

PBR(Perspective-Based Reading)–●

固有の欠陥タイプを摘出することに集中して読む技法

UBR(Usage-Based Reading)–●

チェックリストを利用して読む技法「設計者」「テスター」「顧客」の視点を割り当てて読む技法

アドホック

11

出典：SQuBOK Review 2017 SQuBOK V3 研究チーム 「レビュー技術動向」
https://www.juse.or.jp/upload/files/SQuBOK_Review2017_2_20171026.pdf#page=6

質問3：リーディング技法●

CBR(Checklist-Based Reading)–●

DBR(Defect-Based Reading)–●

要求レベルのユースケースを使用して読む技法

PBR(Perspective-Based Reading)–●

固有の欠陥タイプを摘出することに集中して読む技法

UBR(Usage-Based Reading)–●

チェックリストを利用して読む技法「設計者」「テスター」「顧客」の視点を割り当てて読む技法

アドホック

今回話す内容12

出典：SQuBOK Review 2017 SQuBOK V3 研究チーム 「レビュー技術動向」https://www.juse.or.jp/upload/files/SQuBOK_Review2017_2_20171026.pdf#page=6

質問4：レビューを行うタイミング
要求定義
基本設計
詳細設計
実装
単体テスト
結合テスト
システム
テスト

エキスパートによるテクニカルレビュー（適宜）
エビデンスを残す
公式レビューによる成果物レビューおよび工程完了レビュー
コミットレビュー、ペアプログラミング等
による開発者主体のレビュー
出典：SQiPシンポジウム 2014 井芹洋輝 「テスト・レビューの活用事例」
https://www.slideshare.net/goyoki/sqip2014/4 を元に作成

13質問4：レビューを行うタイミング
要求定義
基本設計
詳細設計
実装
単体テスト
結合テスト
システム
テスト

エキスパートによるテクニカルレビュー（適宜）
エビデンスを残す
公式レビューによる成果物レビューおよび工程完了レビュー

今回話す
内容

コミットレビュー、ペアプログラミング等
による開発者主体のレビュー
出典：SQiPシンポジウム 2014 井芹洋輝 「テスト・レビューの活用事例」
https://www.slideshare.net/goyoki/sqip2014/4 を元に作成

14

「レビュー」といっても様々●●「レビュー」は、各組織で様々な形、方法がある–

レビューの種類–

レビュー方法–リーディング技法–

レビューを行うタイミング

今回お話しするレビューの特徴は以下の通り–

機能設計レビュー–

気軽にレビューする–

作る途中でもレビューする

15

レビューを行う目的

16

SQuBOK Guide（ソフトウェア品質知識体系ガイド）
レビューとは一般的に、ソフトウェア開発工程全般で行われる見直し作業であり、関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性等を評価/確認する。

第1版
第1版

出典：SQuBOK策定部会(2007)『ソフトウェア品質知識体系ガイド ―SQuBOK® Guide―』オーム社．

17

SQuBOK Guide（ソフトウェア品質知識体系ガイド）
レビューとは一般的に、ソフトウェア開発工程全般で行われる見直し作業であり、関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性等を評価/確認する。

第1版
第1版

出典：SQuBOK策定部会(2007)『ソフトウェア品質知識体系ガイド ―SQuBOK® Guide―』オーム社．

レビューとは一般的に、ソフトウェア開発工程全般で行われる評価及び確認の作業のことであり、関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性などを評価し、確認する。

第2版
第2版
18

出典：SQuBOK策定部会（2014）『ソフトウェア品質知識体系ガイド（第2版） －SQuBOK® Guide V2－』 オーム社．

SQuBOK Guide（ソフトウェア品質知識体系ガイド）
レビューとは一般的に、ソフトウェア開発工程全般で行われる見直し作業であり、関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性等を評価/確認する。

第1版
第1版

レビューは見直すだけではなく、次へ繋げる作業

SQuBOK策定部会(2007)『ソフトウェア品質知識体系ガイド ―SQuBOK® Guide―』オーム社．

レビューとは一般的に、ソフトウェア開発工程全般で行われる評価及び確認の作業のことであり、関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性などを評価し、確認する。

第2版
第2版
19

出典：SQuBOK策定部会（2014）『ソフトウェア品質知識体系ガイド（第2版） －SQuBOK® Guide V2－』 オーム社．

QAが行うべきこととは

出典：JaSST'18 Tokyo 柴田芳樹「私が経験したソフトウェアテストの変遷」
http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=45

20

レビューに期待していること●

製品に品質を作り込みたい–

バグを早めに防ぎたい–

コストのかからない改善活動をしたい–

レビューの後工程にあるテストの材料を得たい●

進捗度合い(ヤバさ)を知りたい●

製品や開発を新人に理解してもらいたい●

製品を良くしたい21

レビューって難しい？
●

ここまで、レビューの目的、期待していることを示しました●

それでもまだ以下のように思っている人はいるのでは？

●–

レビューのイメージがまだよく分からない

難しい？
難しい？

–

レビュアーになるのが難しそう

難しい？
難しい？

–

QAがレビューに参加しても意味がなさそう

難しい？
難しい？

次の章では、レビューをどのように行うか実際に体験してみましょう22

実際にレビュアーを体験してみよう

23

レビュー体験の目的

易しい
易しい
●
レビュー参加のハードルは低いと実感してもらう●

自分でもレビュアーとして指摘できると感じてもらう●

レビューに参加する価値を感じてもらう

体験してもらう前に、まずはレビュアーとしての心構えをお伝えします。

24

易しい
易しい

「レビュアー」という役割に気負わない

●

●

●

自分の知らないアクターになって臨む必要はない
QAであればQAとして、開発者であれば開発者としてレビューに参加すればいい

気軽な気持ちで参加しよう–

難しく考えないこと！

25優しい優しい●●最初から完璧な仕様書を求めなくていい–

いつまでもレビューが開始されなくなる–

完璧に近づける作業がレビュー書きたいものから書けばいい–●「レビュイー」に完璧を求めない

最初の一歩を踏み出そう（勢いも大事）

書いて迷ったときに聞けばいい–

後になるほど、完璧なものを求められる謎のプレッシャー…

–

途中経過をレビューしてもらうのもアリ26

例題
次の仕様に対してどんなことが気になりますか。
●●

パスワードは4文字以上12文字以下の英数字のみを許容する
パスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックする
出典：第7回Ques 山﨑崇「概説テスト分析」
https://www.slideshare.net/takashiyamasaki378/ss-55384920/25 を元に作成

27

文字列長
パスワードは4文字以上12文字以下の英数字のみを許容する
文字種

誤入力
誤入力
期間管理 回数管理
パスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックする

ロック保持期間 状態遷移

28

文字列長
パスワードは4文字以上12文字以下の許容しないとどうなる？
(ボタン制御orエラー画面)
英数字のみを許容する
文字種

誤入力
誤入力
期間管理 回数管理
パスワードを3分以内に4回以上間違って入力すると5回目の入力はどうなる？
アカウントを5分間ロックする

ロック保持期間 状態遷移29

例題を振り返って…
1. あなたと隣の人で気になる内容が違う–

自分が気付いた内容は伝えましょう–

隣の人が気付かない内容を補完し合うことができます2.

30

例題を振り返って…
1. あなたと隣の人で気になる内容が違う–

自分が気付いた内容は伝えましょう–

隣の人が気付かない内容を補完し合うことができます2. この例では何もプログラムを書いていません–

不具合を実装前に防ぐことができる例です–

もしもこの時点で指摘できれば、総コストを削減できます31

早めにバグを防ぎたい理由

出典：JASPIC SPIJapan2009 奈良 隆正「ソフトウェア品質保証の方法論、技法、その変遷」
http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf#page=3132

この章でやったこと●

簡単な題材でレビューを体験してもらった●

成果物に対してたくさん疑問点が出た（はず）–

隣の人と違う指摘ができた人–

隣の人と同じ指摘しかできなかった人●

価値があると感じたならば、例題を持ち帰ってください●

次の章では、社内の人（開発者・QAなど）に気軽にレビューに参加してもらうための話をお伝えします33レビューに参加するハードルを下げるコツ～易しく優しいレビューにする～

34

優しい
優しい

●

レビューは相談、確認の場–●

承認でも保証でも批判でも勝負でもない

自分の不足しているところを補うための相談–●

レビューとは相談である

すべて理解してほしいわけではない

自分の知識や観点や経験を活用–

知らないアクターになって臨む必要はない

35

優しい
優しい

●

レビューとは相談である

レビューは相談、確認の場–

承認でも保証でも批判でも勝負でもない

自分の不足しているところを補うための相談
レビュアーは1人ではないのですべて理解してほしいわけではない
なんとかなる
自分の知識や観点や経験を活用

●

–

●

–

知らないアクターになって臨む必要はない

36

易しい
易しい

こんな知識や経験を持っていませんか？
●

似たような過去の不具合(トラブル)事例●

お客様がどんなことに困っているか●

新人がよくやらかす事例●

コードや設計のアンチパターン●

その機能の仕様バグや裏仕様や歴史●

世の中のあるある事例●

ベテランがいつも気にしているポイント
37

易しい
易しい

こんな知識や経験を持っていませんか？
●

似たような過去の不具合(トラブル)事例●

お客様がどんなことに困っているか●

新人がよくやらかす事例●●

何か1つでもあればコードや設計のアンチパターン
レビュアーになれる
その機能の仕様バグや裏仕様や歴史●

世の中のあるある事例●

ベテランがいつも気にしているポイント
38優しい優しい●レビューをするとみんなの関心事になる

レビューをする前
成果物を知っているのは作成者本人だけ– 成果物は自己満足(Self satisfaction)にすぎない–●

レビューをした後みんなが成果物に関心を持ち、みんなで改善しようとする– チーム満足(Ourselves satisfaction)を目指す–

全員が 「もっと製品を良くしたい！」 と思っている–

これを理解していれば、レビュイーを攻撃しませんよね？39

レビューを有効活用するために易しい
易しい ● 思ったことは素直に伝えよう
知らないから言わないはダメ– 「分からない」と言うことも大事– 正常に、疑問を持とう–●
易しい
易しい QAとしての不安感も伝えよう

実装前で気付くテスト観点だったりする– 勘違いでも問題ない（不安を解消できる）–

優しい優しい ● 製品を良くするためにレビューをしよう
承認でも保証でも批判でも勝負でもない– 楽しくやろう！
–40

優しい
優しい

実際に開発リーダーから貰ったメール

今回はレビュイーである新人にとって初めての設計レビューでした。
まだ同じチームになって2ヶ月ほどですが、あんなにも緊張した彼を見たのは初めてでした 笑
レビュー後に「やってみてどうだった？」と聞いたところ、「いや～楽しかったです。」と返してくれました。
理由は、色々な視点でフィードバックをもらえたからだそうです。
彼にとっては非常に価値のある有意義なレビューとなったようです。
優秀なQAは優秀な開発者を育てますし、優秀な開発者は優秀なQAを育てますよね。
これからもビシバシ気になる点は指摘していただければと思います。

41

今後のレビューのかたち

42ここからは未来の話

43

https://www.freeimages.com/photo/blank-sign-1-clipping-path-1445187

開発技術は螺旋構造で変化している

出典：Developers Summit2018 和田卓人「技術選定の審美眼」
https://speakerdeck.com/twada/understanding-the-spiral-of-technologies?slide=1044

機能設計レビューを取り巻く環境は変化している
45

https://pixabay.com/ja/ux-プロトタイピング-デザイン-ウェブデザイン-アプリケーション-788002/

アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas© 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

出典：アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/manifesto.html

46

アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、易しい包括的なドキュメントよりも動くソフトウェアを、易しい契約交渉よりも顧客との協調を、アジャイルでは、ドキュメントよりも動くソフトウェアを重視し、計画に従うことよりも変化への対応を、変化への対応を重視している。
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
※「ドキュメントが無くていい」とは言っていない。
Kent Beck
James Grenning
Robert C. Martin
Mike Beedle
Jim Highsmith
Steve Mellor→それに合わせて、レビューも気軽なものに変化
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ward Cunningham
Martin Fowler

Ron Jeffries
Jon Kern
Brian Marick

Jeff Sutherland
Dave Thomas© 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

出典：アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/manifesto.html

47

黒船来襲：モブプログラミング

48
出典：A day of Mob Programming https://www.youtube.com/watch?v=p_pvslS4gEI

モブプログラミングは常に同期している

49

出典：HDIfes#06 開発・デザインの文化をつくる 及部敬雄 「我々は文化とどう向き合うべきか-モブプログラミングとチームと文化」
https://speakerdeck.com/takaking22/wo-hawen-hua-todouxiang-kihe-ubekika-mobupuroguramingutotimutowen-hua-number-hdifes?slide=54

モブプログラミングは常に同期している50

出典：HDIfes#06 開発・デザインの文化をつくる 及部敬雄 「我々は文化とどう向き合うべきか-モブプログラミングとチームと文化」
https://speakerdeck.com/takaking22/wo-hawen-hua-todouxiang-kihe-ubekika-mobupuroguramingutotimutowen-hua-number-hdifes?slide=56

モブプログラミングは常に同期している

常にチームとして活動することで、レビューという工程が無くなる！
ただし、レビュー行為（＝相談、指摘）は残っている
易しい
易しい

51

出典：HDIfes#06 開発・デザインの文化をつくる 及部敬雄 「我々は文化とどう向き合うべきか-モブプログラミングとチームと文化」
https://speakerdeck.com/takaking22/wo-hawen-hua-todouxiang-kihe-ubekika-mobupuroguramingutotimutowen-hua-number-hdifes?slide=56

モブプログラミング中のレビュー行為も螺旋構造の一つ？
インスペクション…最も公式的なレビュー●
チームレビュー…チームにより実施される●
パスアラウンド…成果物をレビュアーへ配布、回覧する●
ラウンドロビンレビュー…全員が順番に司会者とレビュアーになる●
ピアデスクチェック…熟練者のレビュアーと実施する●
ウォークスルー…形式的ではなく、参加者が質問やコメントする●
ピアレビュー…作成者以外と気軽に行う●
アドホックレビュー…近くの同僚に声をかける非公式なレビュー●
ペアプログラミング…プログラミング時に他者の視点を取り入れる●

52

出典：SQuBOK策定部会（2014） 『ソフトウェア品質知識体系ガイド（第2版） －SQuBOK® Guide V2－』 オーム社．

おわりに53

まとめ●

レビューといっても様々なものがある–

今回は気軽に行うレビューを紹介した●
易しい
易しい 「レビュアー」という役割に気負わない– 複数人で補完し合えば良い

優しい優しい ● 製品を良くするためにレビューをする–

レビュイーに対して攻撃しなくなる●
易しい
易しい 今後のレビューはもっと気軽になるかも–

レビューという工程は無くなるかもしれない

54

レビューのカンファレンスを開催予定
開催時期：12月中旬
開催場所：東京都内
個人的な願望●様々なレビュー事例を聞きたい●「どのように考えてレビューを行っているのか」について話したい55

ご清聴ありがとうございました（この発表も、背景にあるように沢山のレビューを経てお送りしました）56