080819_ゲーム業界交流会講演資料.pdf

ゲーム業界の勉強会での講演資料。

Transcript

1. 隣の業界，のぞいてみませ んか？ IT業界における ソフトウェア品質への取り組み 池田 暁
2. 2008/8/19 © Akira Ikeda - 2- 自己紹介 • 名前： 池田 暁（いけだ あきら） • 所属： 某製造業 ソフトウェア開発技術導入支援部門 • 職歴 – 入社後，組込みシステムの設計，ソフトウェア品質保証 業務を経て，現在は設計/テストツールの導入や， プロセス改善に関する業務に従事． 最近は変更・構成管理ツールの社内普及を主に担当． • 社外活動 – 委員等 • NPO法人ASTER（ソフトウェアテスト技術振興協会） 理事 • JaSST（ソフトウェアテストシンポジウム） 実行委員 • WACATE（ソフトウェアテストワークショップ） 実行委員長 • SQuBOK策定部会 策定メンバ • 日本品質管理学会・ACM 正会員 • その他，TEFやS-Open等の技術コミュニティに参加 – 執筆活動（単行本） • ISTQBシラバス準拠 ソフトウェアテストの基礎，センゲージラーニング，2008 • ソフトウェアテスト入門 押さえておきたい<<要点・重点>>，技術評論社，2008 • ソフトウェア品質知識体系ガイド―SQuBOK Guide，オーム社，2007 • マインドマップから始めるソフトウェアテスト，技術評論社，2007
3. 【第Ⅰ部】 ゲーム業界とIT業界の ・組織の作られ方 ・開発プロセス の概要を知ろう
4. みなさんに質問 ～IT業界にどんなイメージを お持ちですか？？？～
5. 2008/8/19 © Akira Ikeda - 5- 【質問】 みなさんの身の回りには どのようなITソフトがあるでしょうか？
6. 2008/8/19 © Akira Ikeda - 6- IT業界のソフトウェア • IT業界のソフトウェアの特徴 – 身近なソフトウェア • 社内システム • 電話 • 車 • IT業界のソフトウェアは，我々が高度な生活を送るために必要不 可欠のものとなってきた
7. 2008/8/19 © Akira Ikeda - 7- 【質問】 ITソフトに不良があったら，どうなりますか？
8. 2008/8/19 © Akira Ikeda - 8- ソフトウェアに不良があるとどうなる？ • もしソフトウェアに不良があるとどうなるのか – ソフトウェアに不良があると… • ビジネス上の損害 • 社会インフラの混乱 • 生命の危険
9. ITソフトウェアの概要 ～ゲームソフトとの比較～
10. 2008/8/19 © Akira Ikeda - 10- ゲームソフトとITソフトのおおまかな違い ゲームソフト ITソフト 主な目的 遊び ビジネス 公共インフラ 機器の制御 主な顧客 ゲームファン 企業 官公庁 価格 数千円～数百万 数万円～数百億 利用期間 数日～数ヶ月 数ヶ月～数年 納品物 ゲームROM マニュアル プログラム（LM，ソース） マニュアル 品質見解書 テスト報告書 不良があったときの受け 取られ方や対応 ウラワザ ROMの回収・交換 損害賠償 プログラムの改修 機器の回収・交換 公的機関への報告
11. 2008/8/19 © Akira Ikeda - 11- プロジェクトの違い ゲームソフト ITソフト 主な目的 遊びの提案 顧客の要求をソフトウェア 技術を使って具現化 主なプロジェクトメンバ プロデューサ ディレクター プログラマ サウンド グラフィック 企画 プロジェクトマネージャ アナリスト システムエンジニア プログラマ テストエンジニア QAエンジニア 要求の出所 プロジェクト内部 （提案型） 顧客 （受注型） 重要視される品質 官能的品質 信頼性 開発期間 半年～数年 一ヶ月～数年 プロジェクト規模 数人～数百人 数人～数千人
12. 2008/8/19 © Akira Ikeda - 12- チーム構成の違い プロデューサ ディレクタ プログラマ サウンド グラフィック 企画 テスター ゲーム業界のチーム構成 注：池田の想像 プロジェクマネージャ 設計マネージャ プログラマ （設計・実装） SE （上流設計） テストマネージャ テスター （検証・評価） 営業 IT業界のチーム構成 注：あくまでも一例
13. 2008/8/19 © Akira Ikeda - 13- ITソフトウェアの特徴 • 品質第一 • 顧客から，ソフトウェアが達成するべき“品質”が提示される – 品質目標 • カバレッジやバグ密度 – 納入物 • 品質見解書，テスト報告書 • 品質を管理する – 品質管理の導入 • 目に見えない品質をどう掴むか？ – メトリクスの導入 • 計測できない物は管理できない
14. 品質確保のための体制と 開発プロセス
15. 2008/8/19 © Akira Ikeda - 15- ソフトウェア品質の確保のための基本的な考え方 • 全社品質活動（TQCやTQMの導入） – 経営のコア技術として品質を位置づける – 不良情報の水平展開 – QCサークルなどの継続的改善活動 • 体制 – 品質を専門に扱う品質保証部の設置 • 品質保証部は品質に関する強大な権限を持つ – 出荷権限（品質保証部がNGと判断すると，出荷不可） • 品質保証部門による検査活動 – 各工程における検査により，不良の早期摘出 • 開発プロセス – ウォータフォールを改善したＶモデルを基本とする • 他のプロセスは応用と捕らえる – Ｖ＆Ｖの導入 • 検証と妥当性確認のための技術 – レビューとテスト技術 – 品質管理技術（マネジメントや品質分析・予測技術）
16. 2008/8/19 © Akira Ikeda - 16- 全社品質確保活動 • TQC（Total Quality Control） – 品質を全社（全員参加）で確保していこうというボトムアップ活動 – 品質管理を効果的に実施するためには，市場の調査，研究・開発・製 品の企画，設計，生産準備，購買・外注，製造，検査，販売及びアフ ターサービス並びに財務，人事，教育など企業活動の全段階にわた り経営者を始め管理者，監督者，作業者などの企業の全員の参加と 協力が必要である．このようにして実施される品質管理を全社的品質 管理（company-wide quality control，略してCWQC），または総合的品 質管理（total quality control，略してTQC）という • TQM（Total Quality Management） – TQCの特徴を活かしつつ，トップダウンの活動としたもの – 企業のトップが制定した経営戦略を，詳細化して品質目標，顧客満足 度目標まで落とし込んで全社的に展開する – TQCはその実現手段として位置づける TQCやTQMを運用するために品質保証部を設置する場合も多い 品質保証部の仕事は製品の検査を含め， 全社レベルで品質に関する全ての責任を持つ
17. 2008/8/19 © Akira Ikeda - 17- 品質を確保するための体制例 ＰＭ 設計マネージャ テストマネージャ 設計リーダ 設計リーダ テストリーダ テストリーダ テスター テスター テスト オペレータ テスト オペレータ ・・・ ・・・ ・・・ 設計者 設計者 ・・・ ・・・ 品質保証部門 テストチームと設計 マネージャが並列 に存在する 独立した品質保 証部が，検査活 動を行う PMはTMとDMから 情報を吸い上げ， 全体を取り纏める 密な情報交換 検査 経営部門 ・出荷に関する強大な権限 ・品質についての最終的な 責任 品 質 見 解
18. 2008/8/19 © Akira Ikeda - 18- 開発プロセス（V字モデルの例） 実装 （コーディング/机上デバッグ） 基本設計 構造設計 要求分析 受け入れテスト コンポーネントテスト 統合テスト システムテスト 詳細設計 テスト仕様 テスト仕様 テスト仕様 テスト仕様 設計工程 ----- 要求→要件→仕 様→構造と段階的 に詳細化する テスト工程 ----- 対応する設計工程 から入力されたテ スト仕様にしたがっ てテストを実施 設計工程は主にレビュー技術を利用して品質を確保， テスト工程ではテスト技術を活用して品質を確保
19. 2008/8/19 © Akira Ikeda - 19- 開発プロセス 設計工程の概要 • 要求分析（要件定義） – お客様のソフトウェアやシステムに対する要求を分析整理し，ソフトウェアの 機能として実現すべき要件として定義する – 主な成果物：要件定義書 • 基本設計 – 要求分析行程で作成された要件定義所に基づいて，ソフトウェアやシステム 全体の構成，動作を定義する – 主な成果物：基本仕様書，システムテスト項目 • 詳細設計 – 基本設計工程で作成されたシステム仕様書に基づき，ソフトウェアやシステム をモジュールと呼ばれる機能単位ごとに分割し，詳細な動作や機能，他のモ ジュールとのインタフェースを定義する – 主な成果物：詳細仕様書，統合テスト項目 • 構造設計 – 詳細設計工程で作成された動作や機能を実際にコーディングするにあたって， 詳細なプログラム構造やアルゴリズムを決定する．この際，フローチャートや PADが作成される． – 主な成果物：構造（モジュール）設計書，コンポーネントテスト仕様書
20. 2008/8/19 © Akira Ikeda - 20- 開発プロセス 実装工程の概要 • コーディング – 要求分析行程から構造設計工程までに段階的に詳細化されたお客 様の要求を，構造仕様書に基づいてプログラムコード化する • 机上デバッグ – 自分の描いたプログラムコードを，目視によってデバッグを行う 【余談】 テストとデバッグは根本的に異なる作業である！ –テストは，ソフトウェアが正しくないことを証明するために行う –デバッグは，ソフトウェアが正しいことを証明するために行う
21. 2008/8/19 © Akira Ikeda - 21- 開発プロセス テスト工程の概要 • コンポーネントテスト – 構造仕様書に基づいてテストケースを作成し，コーディングされたプロ グラムとつきあわせて確認する．この工程では主にプログラムの内部 構造に着目したテストを行う • 統合テスト – 詳細仕様書を元に，モジュール間やOS，他のシステムとの相互処理 が正しく行われるかテストする • システムテスト – システム仕様書を元にソフトウェアやシステム全体の動きを検証する ほか，使い勝手などの非機能要件についてもテストを行う • 受け入れテスト – 要件定義書を基に，ソフトウェアやシステムが実際にお客様が使える ものになっているかをテストする – この工程は顧客主導で行われることが多い
22. 2008/8/19 © Akira Ikeda - 22- Ｖ＆Ｖ（検証と妥当性確認） 【検証のポイント】 工程と，その入力と出力が定義されていること（入力成果物と出力成果物） 入力と出力の仕様が，明確かつ必要十分に適切な形式や手段で記述されていること． (例）状態遷移図，ＤＦＤ，ＵＭＬ，擬似コード 入力仕様から出力仕様への変換ルールがソフトウェア工学に則った技術と手続きに従って いること． 適切なタイミングでレビュー（公式・非公式）が行われること 実装 （コーディング/机上デバッグ） 基本設計 構造設計 要求分析 製品検査・SST コンポーネントテスト 統合テスト システムテスト 詳細設計 妥当性確認 検 証 検 証 検 証 受け入れテスト 出荷OK 入検OK
23. 2008/8/19 © Akira Ikeda - 23- Ｖ＆Ｖの実施方法 • 検証 – … レビュー • 仕様書のデザインレビュー，プログラムコードのコードレビュー • レビュー技術の活用（インスペクション，ウォークスルー等） – … ドキュメント検査 • 品質保証部門による仕様書の検査 – … テスト項目の作成手法，テスト項目レビュー • 妥当性確認 – … 製品検査 – … システム検査（ＳＳＴ：System Simulation Test)
24. 品質保証部による 検査活動の概要
25. 2008/8/19 © Akira Ikeda - 25- 不良低減の方針 基 本 設 計 詳 細 設 計 構 造 設 計 コ ー デ ィ ン グ 単 体 テ ス ト 結 合 テ ス ト シ ス テ ム テ ス ト 工 程 作 り 込 み 不 良 摘 出 不 良 不良の早期摘出 作 り 込 み 不 良 の 低 減 【不良低減の方針】 作り込み不良の低減と不良摘出タイミングを上流にスライド 上流工程にて品質を作り込む努力（基本は設計作業自体で品質を作り込む） →品質はレビューやテストで作り込まれるのではない 【参考：不良の修正コスト】 不良不良の生存期間が長ければ長いほど，不良修正コストは増大する →要求定義工程で作りこまれた不良を要求定義工程内で摘出した場合を１としたとき，要 求定義工程で作りこまれた不良を出荷後修正すると５０から200倍の費用が発生する
26. 2008/8/19 © Akira Ikeda - 26- 検査工程の例 開発計画 基本設計 レビュー 詳細設計 レビュー コーディング レビュー 構造設計 レビュー マ ニ ュ ア ル テ ス ト 項 目 コンポーネント 統合 システム テ ス ト ・検査項目 ・検査プログラム 検査準備 基本設計書検査 詳細設計書検査 構造設計書検査 マニュアル検査 テスト項目検査 ドキュメント検査 ・不良予測と 目標値管理 ・探針 品質監査 製品検査 SST 顧客出荷 開発計画監査 プログラム 開 発 工 程 検 査 工 程 • 各工程での開発 成果物（主に仕様 書）を検査部門が 検査 • テスト期間中に， 検査部門が検査 に先立って，探針 （サンプリングテ スト）を行う • 設計部門のテスト 終了後，検査部 門による製品検 査，ならびにシス テム検査を行う
27. 2008/8/19 © Akira Ikeda - 27- 各工程での品質保証の観点 ユーザニーズの分析の妥当性 要求定義の正当性 要求定義 機能の十分性 操作性の評価 性能の評価 基本設計 機能分割の正当性 データ流れ制御の正当性 詳細設計 詳細ロジックの保証 性能目標値の保証 構造設計 詳細ロジックとソースプログラムの 等価性の保証 コーディング コンポーネント単体でのテスト による確認 検出バグ数の妥当性 バグ分析 コンポーネントテスト モジュール間インタフェースの 確認 検出バグ数の妥当性 バグ分析 コンポーネントテスト プログラム全体の確認 （機能・性能） 検出バグ数の妥当性 バグ分析 システムテスト 各皇帝の品質評価 製品のできばえ評価 製品検査
28. 品質保証活動を支える技術 ～SQuBOKにおける体系～
29. 2008/8/19 © Akira Ikeda - 29- SQuBOKガイドとは • SQuBOKガイド – Guide to the Software Quality Body of Knowledge • ソフトウェア品質知識体系ガイド • 著者：SQuBOK策定部会 編 • ISBN 978-4-274-50162-3 • 定価：3675円(本体3500円＋税) • B5変 380頁 • http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?&ISBN=978-4-274-50162-3 • 特徴 – 日本発，現場主導のBOK • 国内の実務者主導，国内の取り組み多数収録 – 実務者や研究者が有する知識の可視化と構造化 国内外で培われてきた ソフトウェア品質についての地図やカタログみたいなもの
30. 2008/8/19 © Akira Ikeda - 30- SQuBOKガイドの狙いとスコープ • SQuBOKガイドの狙い 1. 品質保証に携わる方の育成に役立つものにする 2. ソフトウェア品質に関する日本の暗黙知を形式知化する 3. ソフトウェア品質に関する最新のテーマを整理し，体系化する 4. ソフトウェア品質技術の認知度向上を図る 5. ソフトウェア品質保証プロセスを確立したい組織の助けとなる • SQuBOKガイドのスコープ – ソフトウェア品質にかかわる全体 – ガイドである．既存の知識へのアクセスを提供． – 特に国内の知識へのアクセスを重視 – SWEBOK，PMBOKを排除するものではない．ソフトウェア品質にか かわる部分に焦点． – 第1版では「見積り」「設計」「実装」「プロセスモデル」等は対象外にし た． – 誰に読んで欲しいか？ • ソフトウェア品質保証エンジニア • ソフトウェア品質に関わるマネージャ，技術者，経営者
31. 2008/8/19 © Akira Ikeda - 31- SQuBOKの樹形図 2. ソフトウェア品質マネジメント 組織レベル 2.2 ライフサイクル・プロセスのマネジメント 2.4 検査のマネジメント 2.5 監査のマネジメント 2.6 教育・育成のマネジメント 2.7 法的権利・法的責任のマネジメント 2.1 ソフトウェア品質マネジメントシステム の構築と運用 2.3 プロセスアセスメント・プロセス改善 のマネジメント プロジェクトレベル(共通) 2.8 意思決定のマネジメント 2.9 調達マネジメント 2.10 構成管理 2.11 リスクマネジメント 2.12 プロジェクトマネジメント全般 プロジェクトレベル(個別) 2.13 品質計画のマネジメント 2.14 レビューのマネジメント 2.15 テストのマネジメント 2.16 品質分析・評価のマネジメント 2.17 運用・保守のマネジメント SQuBOK 1. ソフトウェア品質の基本概念 1.1 品質の概念 1.2 品質のマネジメント 3. ソフトウェア品質技術 3.1 メトリクス 3.2 品質計画の技法 3.3 要求分析の技法 3.4 レビューの技法 3.5 テストの技法 3.6 品質分析・評価の技法 3.7 運用・保守の技法
32. 【第II部】 IT業界の技術，少しずつ 取り入れてみませんか？
33. 情報源を押さえよう ソフトウェア品質に取り組む 団体/学会/イベント/資格
34. 2008/8/19 © Akira Ikeda - 34- 技術者／業界団体 • TEF: ソフトウェアテスト技術者協会 – http://www.swtest.jp/forum.html • ASTER: NPO法人ソフトウェアテスト技術振興協会 – http://aster.or.jp/ • IVIA: IT検証産業協会 – http://www.ivia.gr.jp/ • QuaSTom: 高品質ソフトウェア技術交流会 – http://www.quastom.gr.jp/
35. 2008/8/19 © Akira Ikeda - 35- 国内の学会 • 情報処理学会 – http://www.ipsj.or.jp/ • 電子情報通信学会 – http://www.ieice.org/jpn/ • ソフトウェア技術者協会 – http://www.sea.jp/ • 日本ソフトウェア科学会 – http://www.jssst.or.jp/ • 日本品質管理学会 – http://www.jsqc.org/ • 日本信頼性学会 – http://reaj.i-juse.co.jp/ • プロジェクトマネジメント学会 – http://www.spm-japan.jp/
36. 2008/8/19 © Akira Ikeda - 36- シンポジウム/ワークショップ/イベント • シンポジウム，ワークショップ – ソフトウェアテストシンポジウム（JaSST） • 全国各地で開催．東京では二日間でのべ1700人の規模． • http://jasst.jp/ – ソフトウェア品質シンポジウム，日本科学技術連盟（SQiPシンポジウム） • 日科技連SQiP研究会による，ソフトウェア品質のシンポジウム – ソフトウェアテストワークショップ（WACATE） • 若手エンジニア主体の1泊2日のワークショップ • http://wacate.jp/ • その他，メディアによるイベント – 技術評論社関連 • ソフトウェアテストセミナー – http://gihyo.jp/event/2008/test – 日程：2008/9/19 会場：東京・目黒 – 翔泳社関連 • デブサミ:Developer's Summit – http://codezine.jp/devsumi/ • Developers [Test] Summit（開催終了） – http://codezine.jp/devsumi/2008/test/ – @IT関連 • ソフトウェアテスト・ミーティング – https://itmedia.smartseminar.jp/public/seminar/view/20 • 組み込みソフトウェア品質向上セミナー – https://itmedia.smartseminar.jp/public/seminar/view/21
37. 2008/8/19 © Akira Ikeda - 37- 体系/規格 • 品質規格等 – SQuBOK（ソフトウェア品質体系ガイド） • ソフトウェア品質についての，考え方や企画，手法や技術の体系 • 国内の実務者により編纂 • 国内の独自の品質技術の紹介 • http://www.juse.or.jp/software/squbok.html – Software product Quality Requirement and Evaluation • ISO/IEC25000シリーズとして策定中 • ISO/IEC9126シリーズとISO/IEC14598シリーズを整理統合 • ISO/IEC9126「ソフトウェア品質特性」(JIS X0129) • ISO/IEC9126-1「品質モデル」（JIS X0129-1） • ISO/IEC9126-2「External metrics」 • ISO/IEC9126-3「Internal metrics」 • ISO/IEC9126-4「Quality in use metrics」 • ISO/IEC14598「ソフトウェア品質評価のための規格群」 • 品質モデルは，JIS X0129から大きな変更はない予定
38. 2008/8/19 © Akira Ikeda - 38- 資格試験 • JSTQB:JSTQBテスト技術者資格認定試験 † – http://jstqb.jp/ – 累積受験者数：2915 名 – 累積合格者数：1828 名 • 次回の試験について • 日程：2008/8/30 • 会場：東京，北海道，宮城，大阪，愛知，福岡（予定） • 対象： Foundation Level • IVEC:IT検証技術者認定試験 – http://www.ivia.gr.jp/ivec/ – 累積受験者数：433 名 – 累積合格者数：115 名 • 次回の試験について • 日程：2008/10/26（予定） • 会場：東京，大阪，名古屋（予定） • 対象：エントリーレベル１ / エントリーレベル２ / ミドルレベル３ / ミドルレ ベル４
39. 2008/8/19 © Akira Ikeda - 39- ゲーム業界がIT業界から情報を取ってくるなら • アーケードゲーム系 – 組込み系がおすすめ – ドライバやファーム関連の技術 – メカやエレキの技術も豊富 • コンシューマ系 – 一般的なアプリケーション・パッケージソフト系，組込み系 • ネットワークゲーム系 – エンタープライズ系 – ユーザ管理や決済等の技術が参考になる
40. 最近のソフトウェアテスト界の トレンド
41. 2008/8/19 © Akira Ikeda - 41- ここのところのテスト界のトレンド • HAYST法 – 実験計画法のソフトウェアテストへの応用を中心とした技法 – 富士ゼロックスにて体系化され実践されている技法 • マインドマップによるテスト設計 – テスト分析とテスト設計にマインドマップを利用したメソドロジ • NGT – 電気通信大学の西先生によるテスト観点のモデリングのための記法 • ロボットによる組込み機器のテスト – ロボットアームをスクリプトで動かし，実際に機器を操作させることでテ スト – 日本ノーベルのQuality Commanderが有名
42. 技術やツール， ここから始めてみませんか？
43. 2008/8/19 © Akira Ikeda - 43- ゲーム業界のソフトの特徴（私が考えるに） • ゲームソフトはつくり直し，つくり壊しが多い • 基本的な開発プロセスはプロトタイピングやアジャイルに近い？ • 工程をかためて一つ一つ確実に，という作り方ではない • 早期に"おもしろさの確信"を得ることを重視 – おもしろさが確信できてから，ソフトの作り込みと品質の作り込みが始 まる • しかし，大作ソフトはできるだけ早くから作り込みをしたい PS3/XBOX360 DS/携帯電話 開発スタイル 大作 アイデア重視 開発人数 数10人から数100人 数人から数十人 開発期間 1年から数年 半年から1年 開発規模 ～数十ギガ ～数百メガ
44. 2008/8/19 © Akira Ikeda - 44- とっかかりとしては，どこから始めるべきか • 開発プロセスの整備や品質保証の導入は，いきなりは重すぎる – これらは組織として取り組まねばならない • 開発プロセスが整備されていることが前提の技術は導入負荷が大きい – 欲張らず，できるところから，小さく入れていけばいい • 品質を作り込むのは誰か？ – プログラマなどの開発者 – マネージャは品質の作り込み自体にはあまり関与しない – 品質の判断や判定には強く関与する • 開発者にとって初期負荷の低いものから段階的に導入すべき – 技術導入のポイント • 個人ベースで取り組める • 事前学習が軽負荷 • ツール化できる • 捨てずに何年も使うものについてはｎちゃんと工程を区切って品質を確保 したほうが良い – ミドルウェア – エンジン – プラットホーム
45. 2008/8/19 © Akira Ikeda - 45- まずはレビュー技術と静的コード解析ツール • ゲームはミーティングやプログラムの変更が最後まで続く – おもしろさの確信を得るためには幾度とミーティングを行う • その他，プログラマとサウンド，グラフィック間のメモリ調整とか • 意思疎通や議事録作成，合意結果の追跡の問題が発生し易い – 不良の修正のほか，チューニングという名のプログラム変更 • テストプレイ後の変更 • 変更によるデグレードやサイドエフェクトの発生（修正時に不良を作り込んでしまう） • ミーティングの品質をレビュー技術で向上する – ミーティング自体の品質が上がれば，その結果が反映されるプログラムコード の品質も上がる – レビュー技術の導入 • ミーティングの目的と重要度に合わせて，レビュー技術を選択する • プログラムの頻繁な変更に静的コード解析ツールで立ち向かう – プログラムの変更に伴う不良を早期に摘出 – コーディングスタイルの統一（保守性の向上） – 危険なモジュールやコードを早期発見 • コードレビューの対象とできる
46. レビュー技術を知ろう
47. 2008/8/19 © Akira Ikeda - 47- レビューの概要 • レビューとは？ – 仕様書やコードリストなど静的な開発成果物に対し，目視による不良摘出を主 な目的とする – 日本ではデザインレビューという名前が一般的 • レビューミーティングと呼ばれることも多い • レビューにまつわる問題点 – レビュー技法が使われず，単なる資料の読み合わせにとどまる – レビューにおける様々な技法が存在すること，その目的，効果までは理解され ていない場合も有る • その他の目的 – メンバの教育 – 情報の水平展開 – プロジェクトメンバの交流促進 早期に多くの人の目に触れさせることで， 多角的な検討による不良摘出や品質向上を行う また，メンバの教育や情報の水平展開，メンバ間の交流を促す
48. 2008/8/19 © Akira Ikeda - 48- レビューの効果 • レビューの効果 – 不良を早期に摘出・修正できる – 開発生産性が向上する – 開発期間を短縮できる – テストのコストや時間を減らせる – システムのライフサイクルを通じたコストを削減できる – コミュニケーションが良くなる – レビューでは，テストではなかなか見つけられない機能や処理の抜け （例えば要求仕様の）を見つけることができる • レビュー，静的解析，テストは不良の検出という同じ目的を持つ – ３つの技法がお互いに補完している – 異なる技法は異なる不良を効果的に摘出する – テストよりもレビューの方が簡単に見つけられる不良の代表例 • コーディング規則の不遵守 • 要求仕様の不良 • 設計の不良 • 保守性の不十分性 • インタフェース仕様の不良
49. 2008/8/19 © Akira Ikeda - 49- レビューの基本的な流れ • レビューの流れ – （１）レビュー計画 • レビュー技法は？ 人選は？ 時間場所は？ テーマは？ 資料の準備 は？ – （２）レビュー実施 • 事前に資料を読み，不良や疑問点を明らかにしておく – レビューは読みあわせ会ではない • 文言のミスなど細かすぎる不良は指摘しない • 不良のみ指摘し，個人攻撃は行わない – （３）レビューの記録 • 議事録の作成 • 事実のみを記録（記録者の感想は不要） • 出た指摘とその採否は全て記録 – （４）レビュー実施結果の評価 • 議事録に記録された指摘の対応状況の追跡と評価 – 意味のあるレビューであったか？（有効な指摘はあったか？） – 適切なレビュー技法だったか？ 人選に問題はなかったか？ レビューには不良を摘出するという明確な目的がある 単なる集まりではないことを意識すべし
50. 2008/8/19 © Akira Ikeda - 50- レビューでの役割 • 一般的なレビューでは，以下の役割の人がいる – マネージャ • レビューを実施を判断 • 実施のスケジュールを立て，レビューの目的がどうであるかを判断する – モデレータ • ドキュメントのレビューを取りまとめる • 取りまとめには，レビューの計画，レビューの運営，フォローアップも含む • レビューの成功，不成功は，この人に拠ることが多い – 作成者 • レビュー対象のドキュメントに責任を持つ人 – レビューア • ある特定の技術やバックグラウンドを持つ各個人（チェッカーとかインスペクタと呼 ぶこともある．） • 必要な準備の後，レビュー対象物で，気がついたこと（例えば不良）を示したり述 べる • レビューアは，いろいろな分野や，レビュープロセスの役割を代表する人として選 ばれる – 初期（記録係）： • レビューで取り上げたこと全ての課題，問題点，未解決事項を記録する．
51. 2008/8/19 © Akira Ikeda - 51- レビュー方法 • レビュー方法とは，どのような形態でレビューを行うのか，つまりどのよう な場を設定し，どのように進めるかである • 非公式レビュー – 決まったプロセスはない – ２人１組でプログラミングしたり，技術的なリーダが設計やコードをレビューす ることがある – レビュー内容をドキュメント化することもある – レビュー担当者により，効果の大小が決まる – 目的は，金や時間をかけずにある程度の効果を出すこと • ウォークスルー – 作成者が進行を主導する – シナリオを元に，同僚のグループが机上で処理をたどる – 結末を決める – レビュー担当者が事前準備をしたり，レビューのポイントを書いたり指摘の一 覧や議事録をとる．（作成者以外の記録者が行う） – 運営により，きわめて公式的なものから，高度に公式なものまである – 目的は，ソフトウェアの内容を学習・理解し，不良を見つけること
52. 2008/8/19 © Akira Ikeda - 52- レビュー方法 • テクニカルレビュー – 不良の摘出には，同僚や技術のエキスパートが参加し，そのプロセスはあらかじめ 定義し，ドキュメント化してある – 管理者の参加しないピアレビューとして進めることがあるかもしれない – 経験をつんだモデレータ（作成者ではなく）が進行を主導するのが理想 – 参加に先立ち，事前準備が必要 – チェックリストを作ったり，レビュー・レポートを書いたり，指摘一覧をまとめたり，管理 者が参加することもある – 運営により，極めて非公式のものから，高度に公式なものまである – 目的は，ディスカッションすること，判断を下すこと，他の方法を評価すること，不良を 見つけること，技術的な問題を解決すること，使用や規則に準拠していることをチェッ クすることである • インスペクション – 経験をつんだモデレータ（作成者ではなく）が進行を主導する． – 同僚によるチェックが一般的 – 各人の役割が決まっている – メトリクスを使う – 開始，終了条件を決め，規則やチェックリストを使い，形式に基づいたプロセスで進 める – インスペクション前の準備が必要．インスペクションのレポートや指摘一覧を書く – 形式の決まったフォローアッププロセスがある – プロセス改善を目的としたり，ドキュメントを読む人を加えることもある – 目的は不良の発見である
53. 2008/8/19 © Akira Ikeda - 53- レビュー技法 • レビュー技法とは，効率的に不良を指摘するための技法 – どのような不良をどのような観点から見つけ出すか – この技法を使ったレビューの進め方としてレビュー方法がある • 七つの設計原理（富士通） – 目的 • 障害を作りこまないためにポイントにそってレビューする – 方法 • 以下の七つの設計原理にそってプログラムのレビューをする． – 単純原理 自然であれという原理． – 同型原理 形にこだわるという原理． – 対称原理 形の対称性にこだわるという原理 – 階層原理 形の階層的美しさにこだわるという原理． – 線形原理 処理の流れは直線だがよく，さらに矩形であるのがよいとする原理． – 明証原理 ロジックの明証性にこだわるという原理． – 安全原理 必然性を意識するという原理． – 効果：障害の作りこみ防止や検出
54. 2008/8/19 © Akira Ikeda - 54- レビュー技法 • PQ（パタンキュー）デザインレビュー（日立） – 目的 • 軽微な一時的障害や部分的な障害で，システム 全体がダウンしたり主機 能が使えなくなるようなシステム障害の未然防止 • PQ障害要因の早期発見，障害許容性，回復性，回復機能の性能の確認 – 方法 • システム取り纏め部門システム設計完了後，関連者を集めて，障害要因 別に組み合わせ，使用方法が最適になっているかレビュー – 効果 • 信頼性の高いシステムを効率的，効果的に構築 – 留意点 • 公共性の高い大規模システムでは必須
55. 2008/8/19 © Akira Ikeda - 55- レビューを成功させるために • レビューを成功させるためには，以下が必要 – レビュー開始前に目的を明確にする – レビューの目的にふさわしい人に参加してもらう – 不良を多く見つけることは大歓迎であり，目的に定義する – 人の問題や心理的な要素も扱う（作成者にとってもそれもプラスの経験にな る） – 対象のソフトウェアやレビュー担当者のタイプやレベルに最適のレビュー技 術を適用する – 不良を効率よく見つけられるのであれば，チェックリストを使ったり，各人の 役割を決める – インスペクションのように，公式性が高いレビューの場合，レビュー実施の技 術教育を実施する – きちんとレビューのプロセスを進めるには，管理者の支援が必要（例えば，プ ロジェクトのスケジュールにレビュー時間を予め取るなど） – レビューの方法を学習したり，プロセスを改善したりすることも目的である
56. 2008/8/19 © Akira Ikeda - 56- レビュー，まずはここから • レビューをカッチリ導入するのはなかなか大変なので，まず以下の 3つから始めてみることをおすすめ • ①現在行われているミーティングの公式度合いを決める – どのようなミーティングを行っているでしょうか？ • ②レビュー時に必要な資料のリストを作る – ミーティングを行うためにはどのような資料が必要でしょうか？ • ③レビュー時に指摘する観点のチェックリストを作る – どのような不良を摘出しますか？ – どのようなことに気をつけますか？ – どのようなことをもう一度確認しますか？
57. 静的コード解析ツールを知ろう
58. 2008/8/19 © Akira Ikeda - 58- 静的コード解析ツールの概要 • 不良と不良の恐れのあるコードを指摘 – 不良 • 不当なメモリアクセス，メモリリーク，誤ったメモリ開放，性能を悪化させる 記述，デッドロックの検出，など – 不良の恐れがあるコーディング – コーディング規約違反 • メトリクスの収集 – メトリクスを分析することで，不良のにおいがするモジュールやクラス を発見する • ライン数 • クラスやメソッドごとのライン数 • ネスト数 • サイクロマチック数 • 他関数からの呼び出し頻度 • 実行時間（クロック数） 定期的に実行することで，早期にくだらない不良を摘出 コードの変更が多発するプロジェクトであればあるほど効果が得られる つまりゲーム向き
59. 2008/8/19 © Akira Ikeda - 59- 静的コード解析の効果 • 静的解析の効果 – テスト実施前の早い段階で不良を摘出する – 複雑性の計測などのメトリクスを測定することにより，欠陥が潜む可能 性のあるコードや設計を早期に警告する – 動的テストでは簡単に見つからない不良を摘出する – リンクのように，ソフトウェア・モデル間の依存性，非依存性を見つけ る – コードや設計の保守性を改善する – 開発中に学習することで不良を予防する • 静的解析ツールで摘出できる代表的な不良 – 値を定義していない変数の参照 – モジュールやコンポーネント間のインタフェース不整合 – 定義はしてあるが，使わない変数 – 到達できない（死んだ）コード – コーディング規約の違反 – セキュリティの脆弱性 – コードやソフトウェア・モデルの構文違反
60. 2008/8/19 © Akira Ikeda - 60- 静的コード解析ツールをうまく使うには • 静的コード解析ツールをうまく使うには以下に気をつける必要あり – ツール指摘事項のスクリーニング – コーディング規約の整備 – 解析結果の有効活用指針 • レビュープロセスを設けるなど • 日立情報通信エンジニアリングでは，上記への対応のほか，以下 を実施 – スクリーニングツールの作成 • 優先度の高い指摘のみを表にする – スクリーニング工数の低減 • 各種マニュアルの整備 – 教育負荷の低減 • 事例の整理 – FAQを作成し，ノウハウの有効活用 静的解析ツールは不良を発見するため“だけ”のツールではない！ メトリクスを中心としたコードレビュー向上ツールと意識せよ！
61. 2008/8/19 © Akira Ikeda - 61- 主なツール • 主な商用ツール – 商用ツールは，不良の発見だけではなく，分析やレポート機能が充実 している – フリーツールがあまり対応していない，c/c++に対応しているソフトが 多い • PG-Relief（富士通） • QAC（東陽テクニカ） • Polispace（エーアイ・コーポレーション） • Coverity Prevent（Coverity） 等 • フリーツール – フリーツールは商用に比べると検出レベルが落ち，レポート機能が貧 弱だが，気軽に試すことができる – また，ほとんどがJava向け • Splint • FindBugs • PMD 等
62. 2008/8/19 © Akira Ikeda - 62- 静的コードツール，まずはここから • 静的コードツールを本格導入するのは大変なので，まず以下の3 点を参考にしてみてください • ①軽いツール – 気軽に実行できる軽く，短時間で解析が終了するツール • ②不良指摘は，まずは高レベルから – 指摘は山のように出るため，まずは高レベルのものだけを対象に対 策 • ③フリーツールより商用ツール – フリーツールを使いこなすためにはノウハウが貯まるまで大変 – トレーニングやサポートが充実している商用ツールがオススメ
63. いかがでしたか？ 方向は違えども，同じソフトウェアを 作る同志です． 是非お互いに知見の交流を行って，皆 でHappyになりましょう！！！