Contenu connexe Similaire à Software Frontloading and QA (20) Plus de Yasuharu Nishi (12) Software Frontloading and QA1. ソフトウェア開発における品質の作り込み
~フロントローディングの基礎~
SQiPシンポジウム2019 併設チュートリアル3
11th Sept 2019 (Wed)
Yasuharu NISHI
電気通信大学 大学院情報理工学研究科
情報学専攻 経営・社会情報学プログラム
@YasuharuNishi / Yasuharu.Nishi@uec.ac.jp
Also Read: https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation-modified
https://www.slideshare.net/YasuharuNishi/
software-frontloading-and-qa
2. Profile
• Assistant professor:
– The University of Electro-Communications, Tokyo, Japan
• President:
– Association of Software Test Engineering, Japan - Nonprofit organization (ASTER)
• President:
– Japan Software Testing Qualifications Board (JSTQB)
• National delegate:
– ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246)
• Founder:
– Japan Symposium on Software Testing (JaSST)
• Founder:
– Testing Engineers’ Forum (TEF: Japanese community on software testing)
• Judgement Panel Chair / member:
– Test Design Contest Japan, Test Design Competition Malaysia (TDC)
• Vice chair:
– Software Quality Committee of JUSE (SQiP)
• Vice chair:
– Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME)
• Steering Committee Chair
– QA4AI Consortium
• Advisor:
– Software Testing Automation Research group (STAR)
© NISHI, Yasuharup.2
3. 本日の流れ
• はじめに: フロントローディングとは何か?
• 製造業におけるフロントローディングの要諦
• ソフトウェアのフロントローディングが目指すべき姿
• デジタル化による上流でのモデルベース検証の考え方
• バグ分析・RCA(根本原因分析)からの水平展開の考え方
• レビューの考え方
• まとめ: フロントローディングとは何か
© NISHI, Yasuharup.3
5. フロントローディングとは何か?
• “Distribute or allocate (costs, effort, etc.) unevenly, with the greater
proportion at the beginning of the enterprise or process. “
– (Oxford Dictionary)
– 「後ろよりも前でやる」
• 後ろの作業を前でやると何かいいことがある
• 四千頭身
– ワタナベエンターテインメント所属・2016年結成のトリオ
– お笑い第七世代の旗手
– 代表的なネタ:「たたみかけ方」
• https://www.youtube.com/watch?v=bhCEOSVNSco
• キーとなるツッコミ:「前半にたたみかけるな」
– 残念ながら漫才ではフロントローディングしてもいいことはほとんどない
• 四千頭身のネタはこの構造を笑いにしている着眼点が画期的である
© NISHI, Yasuharup.5
10. 本日の流れ
• はじめに: フロントローディングとは何か?
• 製造業におけるフロントローディングの要諦
• ソフトウェアのフロントローディングが目指すべき姿
• デジタル化による上流でのモデルベース検証の考え方
• バグ分析・RCA(根本原因分析)からの水平展開の考え方
• レビューの考え方
• まとめ: フロントローディングとは何か
© NISHI, Yasuharup.10
11. 時代は変わった
• VUCA
– Volatile(すぐ変わる) / Uncertain(確信が持てない)
/ Complex(複雑な) / Ambiguous(曖昧な)
– 正解が分からない世界になった
• スケーラビリティ
– スケールするやり方こそが正義な時代になった
• スケールできるツールやサービス、技術が常識になった
• デジタルトランスフォーメーション(DX)
– 多くのものをコンピュータに処理させることができる世界になった
• ソフトウェア開発はとてもDX化が遅れている
• DXできるツールやサービス、技術が常識になった
• ゆとり
– 合理的に思考し納得感を重視し共感を大事にする世代が中心の世界になった
• でもこれってゆとり世代特有ですかね?
© NISHI, Yasuharup.11
12. 変われない組織
• 開発部隊レベルの障壁
– 膨大な技術的負債
– 技術ロジスティクスの欠如
– 形骸化・官僚化した品質マネジメント
– 受動的で他律的なエンジニア
– 丸投げ体質
• 経営レベルの障壁
– 製品の多様性 or 受託ビジネス
– ミッションクリティカル性
– 「開発のあり方」を考え抜く役職の不在
– 投資能力の欠如 /イノベーションのジレンマ
– 企業レベルのハードウェア開発との融合
© NISHI, Yasuharup.12
14. イマドキのQAがトライすべき技術の例
• きちんと考える
– 高速実験する
• 逐次迅速リリース
• カナリアリリース/ABテスト/ブルーグリーンデプロイ
• シフトライト(リリース後現地自動テスト)
– みんなの知恵を集める
• ペアxxx/モブxxx/開発成果物の共同所有
• 計画ゲーム/バーンダウンチャート/ソフトウェアかんばん
• デイリーミーティング
• 振り返り
© NISHI, Yasuharup.14
15. イマドキのQAがトライすべき技術の例
• きちんと考える
– 良いことを繰り返す
• デザインパターンなど
• サービス指向でツールや技法も含んだ複合型プロダクトライン開発
– 悪いことを避ける
• バグ分析・RCA(根本原因分析)からの水平展開
• ソフトウェアトラップ分析(不具合モード分析)
– 抽象化して整理して俯瞰して脳みそをクリアにして合理的に考えて納得感を共有する
• TDD(テスト駆動開発)
• リファクタリング
• 各種モデリング/パターン/ソフトウェアトラップ
• QAアーキテクチャ/レビューアーキテクチャ/テストアーキテクチャ
• 納得感共感マネジメント
© NISHI, Yasuharup.15
20. イマドキのQAが持つべきスタイル
• 納得感の共感をマネジメントする
– ソフトウェアは、測定や手順による品質の保証が根源的にできない
• 素材は物性を測定すれば(確率的に)品質や寿命の保証ができる
• 作業内容を完全に記述しきれるものは、手順の遂行を確認すれば品質を保証できる
– ソフトウェアは究極的に「ちゃんと考える」という作業になるので、作業内容は完全には記述できない
– ソフトウェアのQAの本質は、「ちゃんと考えたと皆が納得している」ことを保証することである
• 品質が確保できたことをテストで示すこともできるが、全てをテストするのは不可能である
• 「ちゃんと考えたと皆が納得した」のに不具合が出たのであれば、
それはその組織の技術力の限界であると諦観し、
その不具合を源に技術力を向上させるのがエンジニアリングである
– 「想定外を想定できる」なんていうことをほざくのは、論理矛盾に気付かない馬鹿か、
エンジニアリングを理解していない文系か、机上の空論を振りかざす科学者のどれかである
• 「ちゃんと考えたと皆が納得する」ことを保証するために、3x5x3=45種類の保証動作を組み合わせる
– (出力/入力/環境 x 内容の理解度 x 最終成果物/ユニット/入力・中間成果物)の組み合わせになる
– プロセスやメトリクスは、低い内容理解度を表す集約指標に過ぎない
– 全員が納得感を共感している組織は、そもそも強い組織である
• QAは、開発もQAもマネジメントも、顧客も発注組織もパートナーも、
全員が納得感を共感していく「旅」である
• アジャイル開発の原則やプラクティスは、納得感を共感できるようにデザインされている
© NISHI, Yasuharup.20
25. 本日の流れ
• はじめに: フロントローディングとは何か?
• 製造業におけるフロントローディングの要諦
• ソフトウェアのフロントローディングが目指すべき姿
• デジタル化による上流でのモデルベース検証の考え方
• バグ分析・RCA(根本原因分析)からの水平展開の考え方
• レビューの考え方
• まとめ: フロントローディングとは何か
© NISHI, Yasuharup.25
27. デジタル化による上流でのモデルベース検証
• 実機/実環境よりも上流で動作する環境
• 上流における検証の設計
– まず上流を「デジタル化」する
• Excel方眼紙やテキストボックスだらけのWord、パワーポイントの仕様書は「デジタル化」ではない
• 「デジタル化」とは、コンピュータ処理が可能になるよう構造化された情報になっていることである
– QAは開発情報のデジタル化も推進していく必要がある
– 次に開発全体で、どこでどのQA観点/テスト観点/検証性質を保証するかを俯瞰する
• 開発やレビュー、テスト、シミュレーションといった各工程でどのようなQA観点を保証するか、
そのためにどのようなQA工程を配置するか、といった「QAアーキテクチャ」をデザインする
– 自動化できる検証はモデルベース検証ツールで自動検証を行う
• モデルベース検証ツールは限定された検証性質(QA観点/テスト観点)しか検証しない
– 自動化できない検証はモデルベース開発環境や仮想環境で手動検証を行う
• テスト設計は自動化できないけどテスト実行は自動化できる、といったように
完全に自動化できなくても一部自動化できるのであれば、なるべく自動化する
• 自動化しやすいように開発してもらえば開発できるところ、はQAから開発に強く投げかける
© NISHI, Yasuharup.27
30. Fully-automated VSTeP
• テスト戦略立案
– 自組織のコンテキストを把握しフォーカスを定め、
開発の自動化とテストの自動化の進度やバランス、
投資額や人員アサイン、対象プロジェクトや共通化などをマネジメントする
• 「下回り」を構築するSET的職種に腕っこきを配置するのがミソ
• テスト要求分析
– テスト観点モデルはエンジニアが徹底的に頭を使う
– どの観点群を自動化し、どの観点群は手動に留め、
自動化するために開発側に手を入れなくてはならないところ
などを決め、反復的に成長させる
• テストアーキテクチャ設計
– コンテナやフレームの設計はエンジニアが徹底的に頭を使う
– QAパイプラインを組む
• まずは、ごく限定され粒度が細かく小さい、自動化しやすい
観点やフレームだけを並べて、なるべく早く回るようにする
– それに合わせてKDTの下回りやCI環境を徐々に整備する
• テスト詳細設計
– 各フレームで用いるテストモデルを開発の仕様書や設計書と紐付ける
• 必要なモデルが無ければ開発側に作るよう働きかける
– モデルベースドテストでテストケースを自動生成する
• テスト実装・実行
– キーワード駆動テストとして(自動生成された)テストケースを
自動テストスクリプトに自動変換する
– 構築したCI環境で24時間自動実行を行う
© NISHI, Yasuharup.30
GUI 機能 データ動作環境
プラットフォーム ネットワーク
OS ハードウェア
OSの種類 OSのバージョン IEのバージョン
電子メール
31. デジタル化による上流でのモデルベース検証の注意点
• QAは「エンジニア」であって「管理屋」でも「ツール紹介屋」でもない
– 世界中で最新の技術を調べ、触れ、試し、身につけることが必要である
• QiitaやSlack、Githubといったイマドキの環境は必須である
• QAが社外のコミュニティに参加したり、コーチやコンサルタント、研究機関に有償で支援を依頼したり、
経験のある有能な人をリファラル採用する、といった施策も重要である
• ツールや環境を整備する人には腕っこきを配置する
– イマドキはSETチームと呼ばれ、高い技術とサーバントシップが要求される貴重な職種となっている
• くれぐれも「手の空いた人」や「現場で使えない人」に担当させない
• 全社一斉導入などは間違っても目論まない
– コンテキストをきちんと把握し、フォーカスを決めて取り組む
• 既に興味を持っており、高い技術を持った、開発難易度の低い、余裕のある、
喜んで協力してくれる、成功しそうなチームと一緒に共創して、まず成功事例をつくる
• ツールや環境を導入することが目的ではなく、問題解決の上流化が目的であると肝に銘ずる
– 自分たちの問題は何かを明確に答えられない限り、逆立ちしてもデジタル化による問題解決はできない
• 問題点をきちんと把握しているからこそ、独自で、しかし必要な分だけモデル化を行うという選択肢もアリになる
– コストダウンと納期短縮を目標に設定すると、まず間違いなく失敗する
• 問題解決能力の向上や、開発を「あるべき姿」に近づけること、スピードアップ、などを大きな目標にするのがよい
• 腰を据える、そのために熱意を持って経営や周囲を巻き込む
© NISHI, Yasuharup.31
32. 本日の流れ
• はじめに: フロントローディングとは何か?
• 製造業におけるフロントローディングの要諦
• ソフトウェアのフロントローディングが目指すべき姿
• デジタル化による上流でのモデルベース検証の考え方
• バグ分析・RCA(根本原因分析)からの水平展開の考え方
• レビューの考え方
• まとめ: フロントローディングとは何か
© NISHI, Yasuharup.32
34. バグ分析には大きく分けて2つある
• マクロ分析(バグの傾向分析)
– 目的
• 組織全体としてどのチームにどんなバグが多いか、を把握する
• プロダクトのどの部分にどんなバグが多いか、を把握する
• 工程のどこでどんなバグが入りやすいか、を把握する
– 代表的な技術
• フォールトプローン技術
• ODC(直交欠陥分析)
– 問題点
• 施策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある
– 基本的にフロントローディングの技術ではない
• バグの中身や開発の中身をきちんと見る習慣が失われる傾向がある
– 「QAは時間がない」は言い訳である
• 傾向という名の数値が一人歩きする傾向がある
– 管理図の統計的意味も分からずに折れ線グラフを描いて「〇〇管理図」とか言い出したりする
• よほど注意して実施しないと、形骸化と官僚化の温床になる
– マクロ分析からの間接施策(プロセスを決めろ/変えろ、この目標メトリクスを達成しろ)は最悪である
• ミクロ分析(バグのパターン化)
© NISHI, Yasuharup.34
35. バグ分析には大きく分けて2つある
• マクロ分析(バグの傾向分析)
• ミクロ分析(バグのパターン化)
– 目的
• バグ、もしくはバグの原因をパターン化して水平展開し、再発防止・未然防止を行う
• 根本原因分析(RCA: Root Cause Analysis)やなぜなぜ分析として行われる
– 代表的な技術
• キーワード分析
• 機能分析
• 現象分析
• 開発者属性分析
• プロセス分析
• 構造分析
• (欧米型)FMEAと呼ばれる一群の何か
• ソフトウェアトラップ分析(不具合モード分析)
– 問題点
• そもそも水平展開や再発防止・未然防止という用語の理解が曖昧である
• 技術(パターンの抽出方法)によっては出来の悪いマクロ分析になる
• よほど注意して実施しないと、吊し上げになり形骸化の温床になる
© NISHI, Yasuharup.35
36. バグのパターン化の(現場で使われている)技法
• キーワード分析
– 容易だが精度は低い
• 例) 「日次平均値算出機能」に対し、
類似のキーワードを含む仕様や機能にバグが多いと推測する技法
• 機能分析
– 容易だが精度は低い
• 例) 「日次平均値算出機能」に対し、機能ツリーのうち近い機能にバグが多いと推測する技法
• 現象分析
– 容易だが精度は低い
• 例) 「日次平均値算出機能」がダウンしたとすると、ダウンしたバグを集めてパターン化する技法
• 通常は意味あるパターンは抽出できない
© NISHI, Yasuharup.36
37. バグのパターン化の(現場で使われている)技法
• 開発者属性分析
– 容易だが精度は低いし、やってはいけない
• 開発者の体調や心理状態、経歴や出身に着目する技法
• 個人攻撃になったり人事評価につながるので、
中長期的に悪さの情報が隠蔽されるので品質は下がっていき官僚化していく
• プロセス分析
– 容易だが精度は低い
• 「~を読んでない」「~を知らない」「~に従わない」「~を確認しない」
「誤った~を読んだ」「~を誤って解釈した」のように分析する技法
• 構造分析
– そこそこ難しいが精度はそこそこ高い
• 例) 「日次平均値算出機能」がスタックを用いているとすると、
スタックや類似した構造を用いている設計部位にバグが多いと推測する技法
• 例) 「日次平均値算出機能」がスタックオーバーフローを起こしたとすると、
スタックなどオーバーフローを起こしうる構造を用いている設計部位にバグが多いと推測する技法
© NISHI, Yasuharup.37
38. バグのパターン化の(現場で使われている)技法
• ソフトウェアFMEAと呼ばれる一群の何か
– 故障モードを機能や現象の抽象概念だと捉えると、精度が低くなってしまう
• 欧米型は、ソフトウェアの各モジュールからの機能不動作(演算間違いや遅延など)を
故障モードと捉えるため、内部的な現象分析になってしまう
• 公表されている事例Aは、内部処理 x 能力 x 現象の3つ組に着目するため、
内部的な機能分析や現象分析になってしまう
• 公表されている事例Bは、データ間の構造の考慮不足などに着目している
• 公表されている事例Cは、瞬断時の異常や他動作中の移動など、発生条件に着目している
– 残念ながら、多くの書籍や論文、発表資料はあまり有益でないことが多い
• そもそも故障モードはハードウェアのQCや信頼性工学でも議論が分かれる概念である
– 電子素材のように固有技術的に確立しているらしい分野もあるようだ
• 精度よく使っているハードウェア組織では、
故障モードは設計ノウハウそのもののため、外部に公表する資料には掲載されない
– だからDRBFMをソフトウェア屋が読むと変化点解析になってしまう
– 著者はバグのパターン化ができないのかもしれないし、
できるけど有益なパターンを外部に公表できないかもしれないし…
© NISHI, Yasuharup.38
42. トラップの例
• 実際に各社で抽出されたトラップの例(特定できないように一部改変しているところがあります)
– 二卵性双生児
• 順序が逆のものが混在すると、混同しやすい
– 優先順位の表現で1(高い)~5(低い)と5(高い)~1(低い)が混在すると混同しやすい
– リトルエンディアンとビッグエンディアンが混在すると混同しやすい
– True/false値(1/0)がハード側とソフト側で異なる
• 対称であるべきものが一部非対称であると、混同しやすい
– アームの行きの動きのルーチンと帰りの動きのルーチンが一部異なっている
– ifdefでコンパイルし分けるコードのCPU使用率が異なるので処理が間に合わない
© NISHI, Yasuharup.42
43. トラップの例
• 実際に各社で抽出されたトラップの例(特定できないように一部改変しているところがあります)
– 二卵性双生児
• 派生開発で複数のソフトを流用して統合する際に、
統合元の前提が成立すると思い込んでしまう
© NISHI, Yasuharup.43
I1
M1
I1
M1
I1
M1 M2
I2
I1
M1
M2
cI
+H/Wによって
初期化処理I1が
1度で済む
ようになった
=1
≧2
=1
≧2
=1 ≧2
ユニット1と
ユニット2を
統合した
新しいユニット
を開発する
ことになった
初期化処理I1
に気付いていたが
なるべく手を
入れたくないため
どうせスキップ
されるからと
I1をメインループに
残してしまった
I1のカウンタは
共通初期化処理cI
を反映しないので
初期化処理が
2回動いてしまった
44. トラップの例
• 実際に各社で抽出されたトラップの例(特定できないように一部改変しているところがあります)
– 例外
• 後から追加された例外的な仕様は、設計漏れを引き起こしやすい
• 複数ある対となっている条件の両方に必要な正常処理は設計できたが、
特定の対の片方の条件だけ例外的に必要となる準正常処理が抜けてしまった
– ポットの水位の事例
– 浦島太郎
• 割り込み先から帰ってきたら、割り込み元の状態が変わっていた
– オートフォーカスの事例
– 山登り船頭
• 指示側に指示を出さずに、被指示側に直接指示を出すと、指示側と被指示側の状態が食い違う
– コンプレッサーの緊急停止の事例
– GCありのプラットフォームからGCなしのプラットフォームへのポーティングの事例
© NISHI, Yasuharup.44
53. バグ分析会議/RCAミーティングの運営
• よいバグ分析会議
– 「納得感」の「共感」を軸にしてバグの分析を行う
• 自分でも引っかかってしまうと納得できるトラップを探す
• 適切なパターン化ができた瞬間は、分析会議の参加者が
「あーそのトラップにはみんな引っかかるよねー」と納得し、皆が共感するようになる
– 開発者への敬意を前面に出す
• 悪いのはトラップであって開発者ではない、という姿勢を崩さない
– 「スキルの高いあなたで “すら” このトラップに引っかかるんですから、若い連中なんてなおのこと…」
– だからトラップ分析ではトラップとブースターを明確に区別している
• バグを作り込んだ人という扱いではなく、
トラップの情報を提供してくれる人として尊敬を前面に出すと、
前向きの会議になって共感しやすくなる
– 効率を求めてはいけない
• 分析に時間がかかるのはスキルが低いからだが、
時間をかけてよい分析をしない限りスキルは向上しない
• 途中でみんな現場に戻りたくなって分析の質が落ちるところをグッと我慢してもらう
© NISHI, Yasuharup.53
56. バグ分析のアンチパターンと効果の薄い対策
• Vaporization(その場限りの簡単なミスとして片付けてしまう)
– コーディングミス: コーディングスキルを向上するようプログラミング言語教育を行う
– 考慮不足: しっかり考慮したかどうかレビュー時間を増やし確認する
– うっかりミス: うっかりしていないかどうかレビュー時間を増やし確認する
• Exhaustion(不完全な実施や単なる不足を原因としてしまう)
– しっかりやらない: しっかりやったかどうかレビュー時間を増やし確認する
– スキル不足: スキルを向上させるよう教育を行う
– 経験不足: 経験を補うためにスキルを向上させるよう教育を行う
• Escalation(上位層に責任を転嫁してしまう)
– マネジメントの責任: トップを含めた品質文化を醸成する
• Imposition(外部組織に責任を転嫁してしまう)
– パートナー企業の責任: パートナー企業を含めた品質文化を醸成する
• Culturalization(文化的問題に帰着してしまう)
– 品質意識/品質文化の欠如: 全社的な品質文化を醸成する
© NISHI, Yasuharup.56
57. 本日の流れ
• はじめに: フロントローディングとは何か?
• 製造業におけるフロントローディングの要諦
• ソフトウェアのフロントローディングが目指すべき姿
• デジタル化による上流でのモデルベース検証の考え方
• バグ分析・RCA(根本原因分析)からの水平展開の考え方
• レビューの考え方
• まとめ: フロントローディングとは何か
© NISHI, Yasuharup.57
58. レビューの改善
• レビューの改善はフロントローディングの行き先の一つである
– まず会議術の改善と、レビュー固有の技術の改善に分ける
• 会議術の改善:モデレータを置きましょう、会議室を確保しましょう、話を聞きましょう…
• レビュー固有の技術の改善:レビュー観点の整理、レビューケースの作成、レビューアーキテクチャ
– 自分たちの開発のレベルをきちんと把握してレビューの改善を行う
• 会議術の改善で効果が出るレベル
– 上司に忖度して雰囲気が悪い、準備してきてないのでムダな時間だらけ、など
• 一貫性やトレーサビリティをチェックするだけで効果が出るレベル
– 「~が揃っているか?」「~がどこから来ているかが明確になっているか?」など
• 言語上の特性を考慮するだけで効果が出るレベル
– 「この文章は他の意味にも取れるよね?」「この代名詞はどちらを指すの?」など
• 開発者の思考のロジックトレースと指差し確認で効果が出るレベル
– 「~が書かれているか?」「~が考慮されているか?」など
• 悪さの知識を水平展開して(推測可能であるにも関わらず)思わぬバグを見つけたいレベル
– 「仕様書にこういうトラップがあるけど、どこでどう気をつけた?」など
© NISHI, Yasuharup.58
60. レビュー観点によるレビュー(ケースの)設計
• レビュー観点を明示してレビューケースの設計を行う必要がある
– レビュー観点は、個々のレビューケースの意図を示している
• レビュー観点は、レビュアーの持つ技術力を示している
– レビュー観点を蓄積していない人や組織がレビューすると、
誤字脱字チェックなどの重箱の隅レビューや、指差し確認レビューになる
– レビュー観点の不明なレビューは、意図の分からないレビューになるため、
往々にして時間がかかる割に意味の無いレビューになる
• シンプルなレビューであれば、レビュー観点だけでレビューケースになるかもしれない
– レビュー観点をきちんと列挙したりモデリングすることが、モダンなレビューでは必須である
• ダメなレビューチェックリストはレビュー観点が不明だったり偏っていることが多い
• レビュー観点の粒度や関係を適切に把握しレビュー観点を構造化/モデリングすべきである
© NISHI, Yasuharup.60
63. レビューの(副次的)役割
• 確認の役割
– 仕様との一致
– 標準との一致
– 意図した役割(顧客満足?)
• 指摘の役割
– 不具合の指摘
– 弱点の指摘
– 設計考慮事項の指摘
– リスク評価・不具合影響評価
• 設計改善の役割
– よりよい設計の提案
– 問題解決策の提案
– 代替案・回避策の提案
• マイルストーンの役割
– 進捗の報告
– 工程完了の判定
• コミュニケーション・合意の役割
– 開発者同士
– 開発者とリーダ・マネジャー
– 開発チームとステークホルダー
– 開発者と顧客
• 教育の役割
– 技術の伝達
– 良い設計を見せる
– 不具合指摘の着眼点を伝える
– トレードオフのバランスを伝える
• 監査の役割
• 作業改善・プロセス改善の役割
– 原因の検討と改善
– 申し送り事項(簡易設計ガイドライン)の作
成と周知徹底
– 次回プロジェクトへの改善
64. レビュー観点によるレビュー(ケースの)設計
• レビュー観点を明示してレビューケースの設計を行う必要がある
– レビュー観点は、個々のレビューケースの意図を示している
• レビュー観点は、レビュアーの持つ技術力を示している
– レビュー観点を蓄積していない人や組織がレビューすると、
誤字脱字チェックなどの重箱の隅レビューや、指差し確認レビューになる
– レビュー観点の不明なレビューは、意図の分からないレビューになるため、
往々にして時間がかかる割に意味の無いレビューになる
• シンプルなレビューであれば、レビュー観点だけでレビューケースになるかもしれない
– レビュー観点をきちんと列挙したりモデリングすることが、モダンなレビューでは必須である
• ダメなレビューチェックリストはレビュー観点が不明だったり偏っていることが多い
• レビュー観点の粒度や関係を適切に把握しレビュー観点を構造化/モデリングすべきである
© NISHI, Yasuharup.64
65. 本日の流れ
• はじめに: フロントローディングとは何か?
• 製造業におけるフロントローディングの要諦
• ソフトウェアのフロントローディングが目指すべき姿
• デジタル化による上流でのモデルベース検証の考え方
• バグ分析・RCA(根本原因分析)からの水平展開の考え方
• レビューの考え方
• まとめ: フロントローディングとは何か
© NISHI, Yasuharup.65