ソフトウェアレビューシンポジウム 2018 JaSST Review'18
ソフトウェアレビューシンポジウム 2018
JaSST Review'18
開催 2018年12月14日（金）
- ソフトウェアレビューシンポジウム 2018
- JaSST Review'18
- 「設計レビューで問題を叩き出せ！～QAの役割～」
- 「レビュー再定義」
- 「アーキテクチャのレビューについて」
- パネルディスカッション
下書きだけど公開。
時間作ってちゃんと清書する
* オープニング
ブロッコリー氏🥦
2003年からJaSSTが始まった。
過去のセッション数：２４０
その中からレビューを題材にしたセッション：６
うち３つ 風間さん🥦
うち２つ 安達さん
「設計レビューで問題を叩き出せ！～QAの役割～」
白水 俊治氏 （日立製作所） しらうず さん
重厚なソフトウェアのテストを行なっている。
レビューでの組織運営についての役についている。
・汎用ソフトウェア製品開発や取り巻く環境変化と品質課題
・ハードウェアの性能飛躍でテストの詳細設計が難しくなった
・ビジネスでのソフトウェアの開発速度が短納期になった
・アジャイル開発は不慣れ
・ソフトウェア長命化によるライフサイクルの変化
1990年の頃からのバグが今でも出てくる。そこでは資料がなくソースだけ。
→ ちゃんとそのパッチで治るのかを細かく見ている。
重い開発ルール・厳しい短期開発に悩んでいる。
レビューの考え方
レビューは机上テストと言われているが。。。
・テストは書いて ある 通りに動くことを確認
・レビューは書いてい ない ことを見つける
ことが大切。（でも「ない：ことが正しいのかの照明は非常に難しい：悪魔の証明）
社外発生不具合の８６％は仕様書に記載がないところで起きている。
記載されていて起きるのは２割。その２割を追求される。
■ レビューの良し悪しは「人」から「暗黙知」を引き出せるか
閃きが大切。
レビューの本質は有識者が作った、チェックリスト
■ ウォーターフォール≒最初に決めて守り続ける
利点：小さい単位で設計、レビューするため、内容を検証、確認しやすい
欠点：記載漏れがないか
■ ウォータフォール型開発
・プロセス改善をすると、ルールやチェックリスト類が多くなる
・問題は後半で表面化する
・設計書をちゃんと作る→時間がかかる
■ 設計書作成の流れ
企画や設計ガイド、チェックリストにそって作成され、責任者・有識者での公式の検証レビューを行なっている。
機能仕様書は細かく分類が別れて作成している。
日立さんは規定がかっちりしている。（それが弊害にもなっている？）
■ 設計ガイド・チェックリストが大量にある
・大量にありすぎれ使いこなせない。
■ 開発の流れ
計画・設計→実装→テスト
設計書・テスト計画書・品質見解
各工程で成果物を作ってレビューをしている。
計画・設計：広く深い視点で検証（利用者・テスター・システムの視線で検証）
テスト：実際に製品を動かして叩く
「気づく」「書いてもらう」他にどうしたらいいのか
日立のQAの特徴
・現物確認至上主義
- 実機を使用した検査作業で関連製品を含めた知識を得る
-
・顧客対応スペシャリスト⁉︎
- 実機検査でえた知識を持ち込み顧客対応する
・稼働品質維持活動：サポートサービス部門
・障害解決支援活動：障害調査を仕切る。場合によっては駆け付け支援・自ら報告書を作成し、顧客説明をする（品証が対応すると安心感がある。責任もあるけど
・システム品質確保支援活動：客先で設計書レビュー、テスト支援、トラブル解決支援
・開発部門との独立性
-製品出荷の最終障壁
■ QAの意識と効果
自分で確認・検査をする
｜ ∟見逃せば社外事故
｜ ∟責任感が高まる
｜ ∟危機感をもつ
｜ 障害の惨状を知る
｜ ↑
自分で顧客対応をする（障害発生→客先対応→いやだから頑張る）
｜ ∟早期の復旧、解決
｜ ∟顧客の信頼が得る
｜ 顧客意見や考え方、想定していなかった使い方を知る
→ （利用者目線での）視野が広くなる
｜
↓
自社製品の処理方式とOS、ハード、関連商品の知識を得られる。
品質活動の原動力
・自分で確認することによる「品質への責任感」
・顧客対応することによる「品質への危機感」
日立のレビューの考え方
設計、テスト＋品質の三つの枠組みでレビューをしている。
設計段階でのレビュー：設計十分性検証フェーズ
∟設計内容の検証を行う
レビューポイント：最悪の可能性を考慮していうrのか
開発者が見逃している箇所を指摘するのが目標
テストだけでは確認できていない条件を探してる
■レビューポイント
・外部仕様を網羅しているのか
より広く、より深く
テストとは異なる視点、テストでは確認が難しい条件
過酷条件、障害視点
・テストは処理の十分性が中心
∟障害時の復旧機能、原因調査資料の十分性→トラブル早期解決に
↑これができれば、客先に行かずにすむ（夜中の１時とか勘弁して）
品質監視（計画・結果の検証）
∟各検査フェーズで品質が担保できているのかを監視
・「探針」っていうフェーズがある。
開発工程のテスト終盤で、QAが検査項目の一部を先行評価して、
その品質状況分析から、以降の品質向上計画を決めるためにおこなう
・QAは作り込み、見逃し原因に対して、道義的原因（なぜなぜ）分析して
見直し視点、品質向上案をあげる。
■ 設計レビューのポイント
「人事と人智を尽くす」
設計・レビューでの重要な三大思考力
俯瞰する：
先見する：
想像する：
レビューでは、長い文章・曖昧語仕様（「できる」ではその逆は？など）・例で表現
■ レビューアは日和らない。発言し気づかせるべし。
・勝手な解釈（忖度）せず、発言する。
■ チェックリストは過信しない。
・チェックリスト＝神様ではない
・チェックリストが膨大だと、疲弊する
→ 心配だから削除できない（上層部の判断が必要だよね）
■ レビュー支援ツールすごい
・集まらなくてもレビューできる
・どこでもレビュー
・自分のレビューが終われば帰れる
・議事録の自動生成
・対面レビューが1/4に減った
〜〜資料が展開されたらまとめる〜〜
「レビュー再定義」
及部 敬雄@TAKAKING22（楽天株式会社）
レビューの目的
・品質の担保
・バグを見つける
・メンバー教育 など
レビューの期待
・欠陥の検出
・コードの改善 など
レビューの３分類
・検査：品質の担保 など
・学習：ナレッジの共有 など
・強化：リファクタリング など
レビューの目的を達成できているか
・コードの改善
・コードの理解
・コミュニケーション
目的と結果を比較すると
・目的にないけど、コメントの内容にはコミュニケーションや
製品理解も入っている
レビューって楽しい？
・検査＝やらなくてはいけない must
・学習＝やるべき
・強化＝やりたい
→実際にはやらなくてはいけないことすら難しい
エンジニアのキャリアの話
経験がついてスキルアップすると、
コードを書くのではなく、後輩の指導やら
コードレビューの時間や責任が増えてきて
コードを書く時間がなくなっていく
→ レビュー辛い
レビューやるなら楽しくやりたい
モブプロの経験を通して、
楽しいレビューについて講義する
今日の話
・モブプログラミングを始めてレビューが不要に
・でも必要だった
・我々にとってのレビューって何か
モブプログラミングとは？
チーム全員で
∟ 同じ仕事を ..
∟ 同じ時間に ..
∟ 同じ場所で ..
∟ 同じコンピューターで ..
すること
レビューがいらなくなった経緯
・分担作業
分担作業の前後に同期が必要になる。（計画→実装→結合）
→ 同期のための専門家（PM）やミスコミニュケーションのリスク
→ そこでレビューが必要になる。
・モブは、同期せずみんなで行う
→ 同期作業がないので、レビューが不要に
どっちもデリメリがある。
〜資料参照〜
モブプログラミングの検査
・レビューにおける忖度
∟ちょっといけてないけど、動いているからいいや
∟今回は指摘が多いから、これくらいにしておこう
モブプログラミングはチーム全体の活動である
・チーム全員で立ち向かってダメなら仕方ない。
→前向きな気持ちで業務に取り組める
モブプログラミングの学習
・チームの学びの量が最大化する
→ 分担作業では、個人の学びにしかならない
→ モブなら、チーム全員の学びになる
・モチベが維持しやすい
・新メンバーの受け入れや教育に
→経験値が低い人をドライバーにすると良い
→ドライバーだとわからない時に仕事を止められる。
→引き継ぎ資料だけだと役に立たないけど、実際に手を動かすから
ノウハウを得られる（Just In Time）
→形式知・暗黙知もまとめて伝えられる
→暗黙知は暗黙知のまま共通体験で伝えられる。
→なぜ作ったのか、どこに苦労したのか、学びがあったのか が共有できる
→ のためレビューがいらなくなった
それでもレビューは必要
・補足を補うためのレビュー
必要なレビュー
・Pull=Request=自分たちの仕事の成果を自分たちで見直す
→ 勢いで作ることが多いので、一日の終わりに見直して、
これが俺たちの全力なのか！？を確認する
振り返りに近い
そのレビューは本当にレビューなの？
ReーViewe 再び見る
・実際にはFirstーViewerじゃない？
→だから学習コストが発生する
もちろんメリデリがある。
・レビューは冷静である。モブは勢いの時もある
・レビューは忖度がある。モブは忖度はあまりない。
★レビューの再定義
知っている「レビュー」を見直す。
→ プロセスも見直す
→場合によってはプロセスも捨てる
完璧からの解放
・やらなくてはいけないこと は無限に湧いてくる
→ 完璧出なくてもいい。キリがないもの
→ 目指してもたどり着けるものではない（イライラする）
・ROIを考えて自分たちにできることをする
・やってダメなら割り切る
変化に対応する
他人のうまく行ったこと＝自分たちの現場 ではない
→ 状況に合わせて変化する
情緒を大切にする
・小手先のテクニックだけでどうにかなるものではない！思わない
→完璧ではないけど、それでも楽しみながら成長することができるように
→ 楽しくないと辛い→やめる
→ 人間らしくやりましょう！
モブでやっているレビューでのよかったFB
・ステークホルダー（PG経験なし）から
「コードを書いてのテストやレビューとかを知れてよかった。」
→こちらも開発の設計を知らないので、逆にそちらにも興味をもてた。
・暗黙知のままにする
→ ドライバーにする 以外の方法は？
→ １時間以上ドライバーする疲れるので、交代する
→ 新人にはそのドライバーを多めに対応させる
→ モブプログラミングしていると「大丈夫です（嘘）」が気づける
→ アクションがしやすい
→ 分担作業だと「大丈夫です（嘘）」がわかりにくい
→顔が見えるのが良い
→仕事を楽しむのは良いが、楽しくない仕事にアサインされた時の対応を知りたい
→辛い時に「やっちゃう」のが「やらないといけない」「やらなくてもいいもの」の判断を勝手に思い込んでいるだけかも
→ 楽しくないときに、辛い時に素直に判断を仰ぐ
→ 本当に辛い時は死んじゃうから、自分に素直になる
→ だめなら大人に怒られる。でも怒られたら謝れば済む（死なない）
→モブプログラミングの適正人数？
→４〜６人。それ以上だと黙る人間がでる
→会議と同じで20人のPRJでも、３０分くらい時間とってやるだけでも十分
「アーキテクチャのレビューについて」
グロース・アーキテクチャ＆チームス株式会社 代表取締役社長、日本Javaユーザーグループ 会長
アーキテクチャとは
定義：あるシステムが、どんなコンポーネントに分割され、それらがどのように統合されているのかを示したもの。
・システムの要素と関係性
システムは複数のコンポーネントの組み合わせて成立する
＊コンポーネント：部品・特定の機能を果たすまとまり
アーキテクチャのレベル感
・様々なレベルにおいて要素と関係性が存在する
・企業全体システム：isideとかYammer!とか
★アーキテクチャの役割
現代的なシステム開発
０から開発することは現代ではほぼない。
→機能を実現する手段がたくさんある（言語、OSSライブラリ、商用製品、クラウドサービス・・・）
→ 他システムとの連携。変化が激しい。
→ まだまだ増えている
組み合わせでシステムを作る時代
マイクロソフトサービスのようなシステムを開発するのではなく、
短期間で、分割された、入れ替え可能なシステム
良いアーキテクチャとは？
良さで非機能を判断する
・機能実現は前提として非機能を重視すべき
・どのような組み合わせが適切に非機能を実現するのか？
・保守性、性能、可用性、セキュリティ、使用性、クラウドサービス
・特に他システムやクラウドのような「非機能を伴うコンポーネント」の扱いが重要になる。
非機能が保証されないと
リリース時点で問題がなくても、ライフサイクルの中で、
・複雑さに夜保守性悪化
・ユーザビリティ性の限界
→なら分ければいいじゃん！
→結局結合時にバグがある。
アーキテクチャ設計レビュー
・アーキテクチャの設計工程でレビューを適切に行う
・アーキテクチャ評価まで行ってから気づいても遅い（性能と同じ）
→ アーキテクチャ設計時にレビューをする（上流工程でのレビューが重要）
設計プロセスと成果物
・ビジネス要件を理解する（ユースケース）
①・非機能要件を定義する：機能適合性
∟経産省が出しているので確認
レビュー
②・構成を検討する（構成管理図）
レビュー
・構成を評価する（評価シート）
①非機能要件を定義する
【 機能適合性 】
・ビジネスチームとの調整になる可能性が高い項目
∟非機能的な「すぐに」「早く」「素早く」表示する
∟その機能が必要なのか確認する
・【 性能効率性／可用性 】
→クラウド/仮装化によって柔軟になった項目
→ただしレガシー環境があるので気は抜かない
→キャパシティプランニングの大切
【 セキュリティ 】
【 使用性 】
・社内なら使えればいいけど、（必要性）
コンシューマ向けなら他社との差別化が必要
・特にスマホなどが注意
→ 使用性確保のために
【 保守性 】
・ライフタイムコストに影響するため、とても重要
ー 独立したスケジュールでテストができるかどうか
ー テストチームの独立性
・ログ〜監視の流れは標準化
ログの監視は必要（バグの切り分け）
・複数環境は意識する
非機能要件を定義する ーレビュー観点
システムに対して適切に設定されているか？
∟非機能的に抜け漏れがないか？
「安全性に問題ないこと」⇦安全性とは何かを専門家（部署）に確認
∟将来性が考慮されているか
∟ステークホルダーの意見が整理されているか
この時点では、ある程度の矛盾や不可能性は許容する
→「秒で処理してくれ」⇦無視せず書き留める。
②構成感の評価
構成案を作成し、非機能要件から評価する
松：なんでもできるけど、高い
竹：あれはできるけど、あれはできない
梅：どれも微妙な感じ
・バランスが取れた判断になっているか？
１００点満点はありえない。妥協点を模索
→落とし所の意図を確認する
→技術的オーバーキルではないか？（「使いたいから」⇦それはお前だけやん、、）
→誰かの意見によりすぎてないか？
リスクと戦う
・技術的リスク
紙に「できます」とは簡単にかけるけど、
本当に？ってなる。
・その構成で本当に非機能要件が満たせるのか？
∟「リスクに気づく」には、経験に寄ることが大きい
・技術的リスク
リスクの検証方法や回避方法を理解しておく。
・机上検証：ベンダーを信じず、Fit＆Gap
・システムの成長リスク
∟できれば、時点で最適化されているのが望ましい
システムの成長リスク ー 予測型
予測をして
システムの成長リスク ー 予測増改築型（温泉旅館型）
予測型を長期感
システムの成長リスク ー 犠牲型
最初に作る後続を最低限にしておき、のちに再整備する
→技術的負債（作って捨てるから予算はかかる0
システムの成長リスク ー 拡張型
構造そのものを拡張性を持たせる（※天才に限る）
まとめ
アーキテクチャの役割
・組み合わせでシステムを作る時代
・非機能要件で良さを定義する
アーキテクチャ設計は常に事前的である
・崩れていく船をみるしかできない
・つまり「リスク」がある
・技術的リスク
・システムの成長リスク
アーキテクチャ設計レビューには信念が必要
・必ずしも技術に優れていることが重要ではない
・むしろ、傾聴し、整理し、働きかける力が必要
・「誰かの意見」に従っていないのか？が大事
→「お客さんがこういったから、そうしました」⇦責任転換じゃなく、ちゃんと考えろ
バランスを持つには
様々な非機能要件を作って、社内で「これで大丈夫？」って言われても、
それは品証部で確認してくれって投げる。
レビューア（レビューイ）に寄るけど、属人化しないためには？
アーキテクチャは属人的であると諦める。
→ならその属人化した人を有意義に使うことを考える。
→レビューに一緒に参加してナレッジを収集をする
パネルディスカッション
「欠陥を見つける」以外で重要だと思っているレビューの目的
白水さん
・製品を良くしていきたい（現地対応したくないから）
・自分を楽になるようにしたく
及部さん
・メンバーがスッキリできているか
鈴木さん
・他の人の考えを取り入れる
🥦さん
・コミュニケーション
・教育
発表内容の共通点・相違点
白水さんの発表
・レビューは書いていないことを見つける
・対象によって公式レビューの出席者が決まっている
・品質への責任感と危機感
・安易に出荷させない
・「次バージョンで対応する」なども話あう
・日和らない
レビュー時の発言について
【 観点と思考 】
成果物・観点・チェックリストに対して、人間の思考→理解
レビューア→レビューイ
【 指摘するまでの思考過程 】
・順方向トレース
・アンチパターン（過去の不具合パターン）
・一貫性チェック
白水さん
Q：閃き→気づき、現場での気づき→レビューでの指摘のロジックを知りたい
A：考えていないので閃き。
想定外だから覚えておこう→思い出して発言。（考えたことがないので説明が、、、）
→ 直近あった不具合とか覚えているからそれを言う。
及部さん
Q：発言するまでの考え方を教えて欲しい
A：自分の苦手なことをミスしないように発言する
チェックリスト：これをすれば大丈夫となるから苦手。やった気になるから
人間らしいことが大切なので、相手の感覚を重視する
「ここは自身がある」「ここは苦手」を相手にきく。
鈴木さん
Q：将来の可能性、リスクに対してのレビューではどのように
A：時間軸の指摘をするように
その他
モンキーレビューとか、人にフォーカスを当てた確認をする。
自信のあるところ⇦なぜ自信があるのかを聞いてあげる。
「ここ余裕っす！」⇦怪しい
いっぱい話すところ⇦怪しい。調べたのは分かったから、それでどうなるの？
「ここの機能が自信あるっす！」
「なんで自身があるって言えるの？」
「できてるコードをググってコピペして動いたから」
「・・・（あかん）」
指摘事項の優先順位
・思いついた順
・何らかの基準に満たしたものを指摘する
・何らかの基準で並び替え、高い順に指摘する
白水さん
・思いついたことを全て言う
→間違いには指摘。
→それ以外には質問が良いのかなと、ここで思った。
及部さん
・思ったことを思ったように行っている（優先度はない）
→忖度しない。
・指摘するかどうかの優先度を考える時間がもったいないから、指摘する。
→そこからの実行の判断をチームに任せる。後回しか即判断か。
鈴木さん
・本当の理想 ⇦ここに向けて行くのではなく、
∟理想
∟現実 ⇦ここら辺に持っていけるように発言している。
・現場にいるエンジニアが一番偉い。その人が良い判断できるようなヒントを与えられるようなレビューしたい。
∟ あんまり言うと「お前がやれ」ってなるのでバランスがむずかしい。
🥦さん
正しいレビューの仕方についての教育について知りたい
白水さん
・本などたくさんあるけど、計画→レビュー→フォローアップの仕方は決まっているが。。。
及部さん
・同じ場所で色な視点を持っている人と一緒にレビューに参加して、
学んでいく。教科書には乗っていない。
鈴木さん
・レビューイ経験をさせるのが一番いい勉強になる と思う。
うまくレビューを受ける癖？を身に付けるのがいいかと
レビューの目的を達成していることを、どのように判断していますか？
どこまで行ったら、このレビューは大丈夫か？
白水さん
・全員が安心感すれば○になるかと。
及部さん
・分からないことをしない。分かる範囲でしかやらない。
→ちゃんと相手に伝わるかが大切。
→レビューがワクワクしているのか。
→やめる定義を決めておく。（５フィンガーとか）
鈴木さん
・時間は常に足りない。時間内にどこまで達成できたかでジャッジする。
→許される範囲で、出来ることをできる限りのことをする。
・参加者が不安があるとそれは解決しないといけない。
→ 安心感が大切
レビューの観点やルールを決めてレビューしても、偉い人はそれを無視して、話が飛び散る、時間がかかる、カオスになる、のどうすればいいのか
白水
・事前に意見を頂戴する。
・その人を一回外してレビューをする。
→絶対にその人がこない時間帯に開催する。
→その根回しが必要
・使っているツール
及部
・そんな人はいらないから排除する。
→その人の意見が欲しいと思っても、辛いレビューになるから排除
鈴木
・偉い人の「俺は聞いてない」にならないように根回しが必要。
→悪意のあるのは最低。悪意がないのなら、言わせるだけ言わせて終わらせる。
→多分話たいだけだから、話す場を設けていなす。
