2018年12月に開催されたJassT Review'18についてのレポートです
セッションの目録やスライドは以下にあります。
ここに書いているのはメモ書き程度なのでスライド閲覧をおすすめします。
http://www.jasst.jp/symposium/jasstreview18/report.html
オープニングセッション / 風間裕也氏（ビズリーチ）
jasst review開催の経緯
Jasst(ソフトウェアテストの最大のカンファレンス)において、過去3年間でレビューに関するセッションは240のうち6つしかない。必要を感じながら事例としてなかなか出てこない。
全く違う分野の人の話を聞くことによってテストレビューの本質が見えてくるのではないか？という試みから開催された。
「レビュー」は各組織で様々な形や方法がある。
1.レビューの種類：何の成果物に対するレビューであるか。
・機能設計レビュー
・コードレビュー
・テストケースレビュー
2.リーディング技法：レビュー対象をどのようにチェックするか。
・CBR (checklist based reading)・・・チェックリストを利用する手法
・DBR (defect based reading)・・・欠陥タイプを摘出する手法
・UBR (usage based)・・・ユースケースを使用する手法
・PBR (Perspective-Based Reading)・・・各立場からの視点を割り当てる手法
・アドボック
3.タイミング：どのプロセスに対するレビューであるか。
・要件定義～システムテスト に対して適宜・・・エキスパートによるテクニカルレビュー
・要件定義～システムテスト 各工程の完了時・・・成果物レビュー、工程完了レビュー
・実装時・・・開発者によるコミットレビュー、ペアプロ
4.開催形式
• インスペクション… 最も公式的なレビュー
• チームレビュー… チームにより実施される
• パスアラウンド… 成果物をレビュアーへ配布、回覧する
• ラウンドロビンレビュー… 全員が順番に司会者とレビュアーになる
• ピアデスクチェック… 熟練者のレビュアーと実施する
• ウォークスルー… 形式的ではなく、参加者が質問やコメントする
• ピアレビュー… 作成者以外と気軽に⾏う
• アドホックレビュー… 近くの同僚に声をかける⾮公式なレビュー
• ペアプログラミング… プログラミング時に他者視点を取り⼊れる
所感
普段何気なく行っているレビューですが、このように整理できることに驚きました。
目的に沿って何のレビューをどのタイミング/形式でやるか改めて考える必要があると感じます。
また、あえて違う種類やプロセスでのレビューのセッションを聞いて本質を知ろうとする発想がとても面白かったです。
S1) 「設計レビューで問題を叩き出せ！～QAの役割～」白水俊治氏（日立製作所）
汎用ソフトウェア製品開発を取り巻く環境変化と品質課題
・顧客の分野と業種が拡大
・ハードウェア性能の向上・システム構成の複雑化
・ビジネスにおけるソフトウェアの位置付けの変化(短期開発・スピード開発が増加)
・アジャイルなど 開発手法が多様化
・ソフトウェアの長命化によるライフサイクルの変化
レビューとは
レビューは書かれていないことを見つける作業。なぜなら書かれていない部分に問題は潜むため。
テストケースに記載がない動作、仕様書に記載がない動作などに不具合が潜みやすい。
レビューの良し悪しは人から暗黙知を引き出せるかどうか。
形式知・・・基準ルール/チェックリスト
暗黙知・・・知識/経験/伝聞
※ただし、プロセス改善などによって暗黙知を形式知に落とし込むと、形式知が膨大になり工数を圧迫してしまう。
ウォーターフォール開発の特徴
最初に決めたことを守り続け、段階的に詳細化していく方式。
前工程の成果物とのズレがないように、小さい単位で設計・レビューする
人から暗黙知を引き出すために
・設計プロセスだけでなく現物を確認する
製品の仕様を理解し、視点が深く変わる
・現物確認で得た知識を生かして顧客対応を行う
想定していなかった考え方や使い方を知り、視点が広く変わる
これらにより、責任感、危機感という意識が変化する
レビュー力強化について
・レビューワーは作成者とは違う視点で思考をめぐらす。俯瞰・先見・創造する。
連携機能は考慮できているか、連続して使い続けて問題ないか、障害起きた場合はどうなるかetc..
・人間心理的な忖度をしない。自己解釈で指摘や質問しないのもNG。
たぶんxxだから大丈夫だろう、嫌われたくない、早く終わらせたい etc..
・チェックリストを過信しない。
文章解釈は十人十色。思考停止の危険性。
・レビュー支援系ツールの活用
所感
フォーターフォール開発に関する話。歴史ある王道ならではの良さはやっぱりあると思います。
属人化をなるべく防いでルーチンまで落とし込み、品質が一定の水準まで保てるというメリット。
ただ、最初にもある通り開発の複雑化・短期化などの変化に対応しきれなくなっている部分はあるのかなーと思います。
・書かれていない所に問題は潜む
・顧客からフィードバックを得ることによる責任感と危機感
という点が特に印象に残りました。
S2) 「レビュー再定義」及部敬雄氏@TAKAKING22（楽天株式会社）
レビューの目的の三要素
・検査 → 品質、不具合発見(Must やらなくてはいけないこと)
・学習 → ナレッジ共有、教育(Should やるべきこと)
・強化 → よりよくする、先行投資(Will やりたいこと)
その手段としてモブプログラミング・・・同じ仕事を同じ時間に同じ場所で同じコンピュータですること
分担作業 vs モブワーク
※それぞれにメリットデメリットがあるので使い分けが必要
分担作業
朝礼/ミーティング/合意形成のためのドキュメント/レビュー/Git Flow/カンバン/タスク分割/キックオフ/レビュー/承認/引継ぎ/WBS/スクラム/ガントチャートetc…
分担作業の前後に同期する作業が必要になり、ミスコミュニケーションによる手戻り発生の可能性もある
ノウハウは同期されればチーム全員の学びになるが、されなければ個人の学びだけになる
モブワーク
同期していないではなく常に同期している
-
モブプロによる検査
・リアルタイムでフィードバック(タイポも見つけやすい)
・チーム全員合意のもとコードが組まれていく。安心感アップ
・忖度する必要がなくチームの最善を目指せる。ストレスダウン -
モブプロによる学習
・チームの学びの量が最大化する
・結果だけでなく過程も学べる
・新しい技術の習得に立ち向かいやすい
・新メンバーの受け入れや教育にも向いている（経験値が低い人をドライバーにするとGood）
・暗黙知は暗黙知のまま共通体験で伝えることができる -
モブワークによる強化
一日の最後に、成果物を冷静に見て、全体最適を考えてフィードバックを行う。
・自分たちのやった仕事を自分たちでふりかえる
・良い仕事ができたかどうか評価
・もっとよくできる余地はないか
Reviewは**Re-View（再び見る）**であって、これが本当のレビューじゃない？あなたのはFirst-Viewになってない？
所感
この話を実際聞いていた人はモブプロがしたくなったんじゃないでしょうか。笑
分担することが生産性が高いという思い込み、私は完全にありました。
分担するための時間、同期するための時間があること、ちゃんと意識したことがありませんでした。
確かに、時間かけてWBS作っても状況が変わって作り直し。。。とか全然ありますよね。
モブだと常に同期してるため、そのコミュニケーションコストがない。
ただしそれぞれにメリットデメリットがあるので状況や仕事の性質によって使い分けは必要とのこと。
なので、思考停止で分担をせず、この仕事の性質は分担とモブワークどちらのやり方が向いているかな？と一旦考えるフローを挟むべきなんだな、と思いました。
及部氏は生き生きしていて、こういう人がいるところで働いたら楽しいだろうなぁと思っていたら
「楽しくなるように仕事を改善してみる。改善のハードルが人より低いんですよね」
とおっしゃっていて、あー自分に足りないのはこれだな、と密かに反省したりしました。
S3) 「アーキテクチャのレビューについて」鈴木雄介氏（グロース・アーキテクチャ＆チームス）
アーキテクチャの役割
組み合わせでシステムを作る時代。
「適度に分割され入れ替え可能なシステム」を実現するために、アーキテクチャが重要。
良いアーキテクチャとは
アーキテクトの評価は非機能の適切さで評価可能。
機能は前提であり、非機能(保守性/性能/可溶性/セキュリティ/使用性etc)でシステムを評価する
-> 他システムやクラウドなど、非機能を内包するコンポーネントの扱いが重要 (OSSとは違う)
非機能を保証しないと、リリース時点で問題なくてもライフサイクルで保守性悪化・性能劣化などの問題が発生してくる。
アーキテクチャ設計レビュー
アーキテクチャ設計の評価は要件定義の前に行う。
1.ビジネス要件の理解
2.非機能要件の定義 ← レビュー①
3.構成の検討
4.構成の評価 ← レビュー②
①非機能要件定義のレビュー
非機能要件として整理を行う。
経産省/IPAによるリファレンスなどがあり、正解は存在しないため自分で使いやすいものを持っておくと便利。
(スライドにはそれぞれの考慮する点が書かれています)
**- 機能適合性
- 性能効率性/可用性
- セキュリティ
- 使用性
- 保守性/移植性
- レビュー観点**
②構成案の評価のレビュー
可能なら3案作る
・可能な限り非機能要件を実現する案
・技術的制約やコストを最優先にした案
・その間の案
バランスが取れた判断になっているか？
技術的オーバーキルではないか？
誰かの意見によりすぎていないか？
アーキテクチャ設計レビューの難しさ
常に事前的であり、**リスク（不確実性）**がある
技術的リスク：その構成で非機能要件が満たせるか
リスク検証
-卓上検証/PoC/プロトタイプ/先行実装/テスト
リスク対応の種類
-回避・需要・代替・低減
システムの成長リスク：成長するのか、衰退するのか
主にコスト面により、現時点で最適化されているのがベター。
- 予測型・・・追加される機能に対して同一の構造を割り当てる
- 予測増改築型・・・追加される機能に対して無理やり構造を増改築したパターン
- 犠牲型 (技術的負債)・・・最初に作る構造は最低限にし、さらに必要になった場合は捨てる
- 拡張型・・・構造そのものに拡張性を持たせる(※天才に限る)
アーキテクチャ設計は、傾聴し、整理し、働きかけて多くの人を判断に巻き込むことが必要。
所感
普段意識していないプロセスの話で目から鱗でした。
普段の業務でアーキテクチャ設計の段階の定義や評価に携わってる方って少ないんじゃないかなーと思います。
システムアーキテクチャの性能って非機能で判断できるんですね。
SREやインフラでチューニングする方などには馴染みがある部分があったりするんでしょうか。
非機能の最終的な評価は、QAとしてやりたいと思いつつ、機能だけで精一杯な現状です。。
非機能は矛盾する部分があるので、バランスをとるのは製品の性質やビジネス的な価値観によりそうですね。
個人的には技術的オーバーキルがツボでした。笑
最後に
この記事に間違いや不明点などがあれば遠慮なくご指摘ください。
(ひぃ。登壇者ご本人からいいねをされている・・・拙いまとめで恐縮です。。)