日科技連ホームページへ
SQiP研究会
SQiP研究会とはサイトマップお問い合わせ
ホーム > 研究会-ソフトウェア品質管理研究会 > 特別講義 > 過去の特別講義(2015年度)
ソフトウェア品質管理研究会
特別講義 2015年度
特別講義レポート: 2017年 2016年 2015年 過去のテーマ: 一覧
 
例会
回数
例会開催日 活動内容
 2015年
1 5月15日(金)

特別講義

テーマ SQuBOK® 第2版の紹介
講演者1 誉田 直美 氏
(日本電気(株) ソフトウェア生産革新本部 主席品質保証主幹)
講演者2 町田 欣史 氏
((株)NTTデータ 技術開発本部 ソフトウェア工学推進センタ)
2 6月12日(金)

特別講義

テーマ システムテストの自動化
講演者 小井土 亨 氏
((株)OSK R&D本部 品質保証部 品質管理2課 シニアアプリケーションスペシャリスト)
3 7月9日(木)~10日(金) 合宿
4 9月17日(木)~18日(金) ソフトウェア品質シンポジウム2015 本会議(会場:東京・東洋大学)
5 10月9日(金)

特別講義

テーマ メトリクスに統計手法を適用する意義、事例、ノウハウ
講演者 小池 利和 氏
(ヤマハ(株) DMI開発統括部 品質保証部 品質管理G 担当課長)
6 11月27日(金)

特別講義

テーマ UX-最新の評価法-
講演者 山岡 俊樹 氏(京都女子大学 家政学部 生活造形学科 教授)
安井 鯨太 氏(ジャストシステム株式会社 UXデザイングループ)
7 12月18日(金)

特別講義

テーマ 積極的なソフトウェア構成管理の活用方法
講演者 長沢 智治 氏(アトラシアン株式会社 エバンジェリスト)
 2016年
8 1月15日(金)

特別講義

テーマ レビューを失敗させるコツ
講演者 原 佑貴子(日本アイ・ビー・エム)
9 2月26日(金) 分科会成果発表会
戻る

第1回特別講義 レポート
日時 2015年5月15日(金) 10:20~12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ 「SQuBOK® 第2版の紹介」
「SQuBOK® 第2版の活用事例」
講師名・所属 誉田 直美 氏(日本電気株式会社)
町田 欣史 氏(株式会社NTTデータ)
司会 小池 利和 氏(ヤマハ株式会社)
アジェンダ
SQuBOK® 第2版の紹介
  • 第1版~2版 世の中の動き
  • 第2版 改訂内容
  • 第2版の解説内容紹介
  • SQuBOK® ガイドの使い方
  • SQuBOK® と世界の仲間たち
  • まとめ
SQuBOK® 第2版の活用事例
  • はじめに
  • NTTデータの標準類策定におけるSQuBOK® の活用
  • プロジェクトでのシステム開発におけるSQuBOK® の活用
  • スキルアップのためのSQuBOK® の活用
  • おわりに
アブストラクト

2007年に第1版が発行されて7年、時代の流れを受けて大きく拡充されたSQuBOK® 第2版が発行された。
第1版の作成から活動していらした誉田さんから「SQuBOK®第2版の紹介」と題して、第2版の改訂に関わる世の中の動きと、第2版の構成と改訂内容の概要を説明頂いた。最近の技術を品質視点でコンパクトにまとめているので、SQuBOK® をソフト品質の「辞書」として使うことが効果的であることを提案頂いた。
誉田さんの講演を受けて町田さんから「SQuBOK® 第2版の活用事例」と題して株式会社NTTデータでの活用事例を紹介頂いた。説明して頂いた活用事例は大きく下記の3種類に分類される。まさに「辞書」としてSQuBOK® を有効に活用した事例を紹介頂いた。

  • 自組織の標準類がSQuBOK® 第2版と照らし合わせて妥当かどうか
  • プロジェクト支援にあたってプロジェクトの状況に合わせて手法を選定
  • 自身のスキルアップ

SQuBOK® 第2版を是非手元に置いて活用してもらいたいと願うお二人の講演でした。ありがとうございました。

講義の要約

第1回の特別講演では、「SQuBOK® 第2版の紹介」と題して誉田さんから、「SQuBOK® 第2版の活用事例」と題して町田さんから講演を頂いた。

誉田さんからは第2版の構成と改訂内容の概要を説明頂いた。最近の技術を品質視点でコンパクトにまとめているので、SQuBOK® をソフト品質の「辞書」として使うことが効果的であることを提案頂いた。

町田さんから株式会社NTTデータでの活用事例を紹介頂いた。誉田さんが講演で提案された「辞書」として実務に活用した事例を紹介頂いた。

SQuBOK® 第2版を是非手元に置いて活用してもらいたいと願うお二人の講演でした。ありがとうございました。

「SQuBOK® 第2版の紹介」 誉田 直美さん

ソフトウェアの歴史は浅いが、今や経済・社会のインフラであり製品・サービスの機能・性能・特徴・魅力を決定づけるといった重要性が増大しており、重要な技術となっている。ソフトウェアの品質を確保することは、ベンダの使命である。

先人たちは製造業の品質マネジメントシステムに学びながら各社工夫して品質を確保してきた。品質の取り組みの底流に流れる考え方は普遍的であり、先人たちの取り組みを整理・体系化・形式知化してまとめることがSQuBOK® の狙いである。目まぐるしく変わるIT技術に対応する品質技術も変わっていくので、第1版から第2版への変更ではその技術の変化への対応を主な改訂ポイントとしている。

第1版~2版 世の中の動き

第1版が出版された2007年以降、iPhone・iPadが発売されYouTube、Twitter、Facebook、Lineが広まった。また、盗聴事件や位置情報履歴の保有といったセキュリティが問題となった。
目まぐるしく変化する世の中に合わせて、IT技術も変化し、それに合わせて品質技術も変わってきた。

第2版 改訂内容

改訂内容は、大きく以下の3項目であり、ほぼ全体を最新情報に更新した。また、用語の統一、文献一覧を巻末に整理するなど見易さの向上を図った。

  1. 開発技術の追加
    第1版では開発技術は樹形図を示すのみであったが、第2版では大きく3プロセス(要求分析、設計、実装)で使用する開発技術を品質の視点から解説を追加した。
  2. 安心、安全、快適な社会への対応
    専門的品質特性(使用性、セーフティ、セキュリティ)に関するソフトウェア品質技術を追加した。
  3. 国際規格の改訂への対応
    第1版では125件の国際規格を参照していたものを第2版では185件に拡大した。特に、ISO/IEC25000シリーズ(SQuaRE)及び機能安全(IEC61508)を始めとするセーフティ関連規格に対応した。
第2版の解説内容紹介

主に「品質の定義」、「セーフティ」、「日本におけるSW品質保証」、「OSSライセンス」、「設計の技法-アーキテクチャパターン」、「CI(継続的統合)」、「セキュアコーディング」について、改訂した。

SQuBOK® ガイドの使い方

ソフトウェア品質の「辞書」として、各ユーザに対して以下のような使い方を推奨する。

  1. 経営層
    SW品質の基本的な概念の理解、品質問題発生時の適用技術の妥当性判断
  2. 開発リーダやその管理者
    SW品質問題にぶつかった時の解説書
  3. 開発者
    自分の開発したSWの良し悪しの見極め方法、良いSWを開発するための技術の理解
  4. 品質保証に携わる技術者
    全体を読破し全貌を理解、問題発生時や組織的改善での利用
  5. ソフトウェアの営業に関わる方々
    SW品質技術の常識、自社の強み・弱みの把握とアピール
  6. 学生
    知識として理解し、社会に出た時一歩先んじる
SQuBOK® と世界の仲間たち

SQuBOK® は、中国版を2011年に発行しており、英語版も2015年発行を目指している。また、ドイツでworkshopが開かれるなど海外で紹介されている。

まとめ

第1版からほぼ全面に近い改訂を実施し、ソフトウェア品質技術の最新技術動向をコンパクトに整理している。知識習得や現場での業務に是非利用して下さい。

「SQuBOK® 第2版の活用事例」 町田 欣史さん

はじめに

NTTデータ内で、社内開発標準・開発ツールの整備、プロジェクトに対する技術支援、教育に従事している。自身の業務にSQuBOK®第2版を活用したので、その事例を紹介する。

NTTデータの標準類策定におけるSQuBOK® の活用

社内外の実績ある知見やノウハウをもとに作成したNTTデータのTERASOLUNA標準手順がSQuBOK® 第2版と合致しているかその一部を確認した。

事例1

TERASOLUNA開発手順のフロー

開発標準の中にSQuBOK® 第2版「2.15設計のマネジメント」及び「2.16実装のマネジメント」が存在するか確認した結果、TERASOLUNA開発手順のフローの中のAP基盤概要設計及びAP基盤詳細設計にあることを確認した。(設計の評価及び実装の評価は別途プロジェクト管理手順に記載)

事例2

NTTデータの品質管理の基本理念

NTTデータにおける品質管理の基本理念が、SQuBOK® 第2版「第1章ソフトウェア品質の基本概念」と一致していることを確認した。

事例3

NTTデータの品質評価

NTTデータが使用している技法(バグ成長曲線による管理、開発規模あたりのテスト項目数や摘出障害件数の管理、バグ分析)が、SQuBOK® 第2版「3.10品質分析・評価の技法にある各種技法」にある技法を活用していることを確認した。

事例4

NTTデータの人財認定

NTTデータの人財タイプであるITスペシャリストの専門分野の1つであるソフトウェアプロセスでは、「ソフトウェア品質技術者資格(JCSQE)」を取得必要な資格の選択肢の1つとしている。

プロジェクトでのシステム開発におけるSQuBOK® の活用

プロジェクトに対する技術支援で活用した事例を紹介する。SQuBOK®で基本を確認して、我流に走らずに基本を応用することが重要である。

事例5

テスト計画の策定

テスト開始前に全体テスト計画と各テスト計画レベルを立案する状況において、SQuBOK® 第2版「2.18テストのマネジメント」にあるドキュメントに関する企画、テスト計画、テストリスクマネジメント、テスト進捗マネジメント及びそれらの関連文献を参考にテスト計画を策定した。

事例6

テストの推進

設計工程が遅延したためテスト期間を短縮せざるをえない、設計書修正に要員をとられテスト要員が不足したため、限られた期間・リソースでテストを確実に実施する必要がある状況で、SQuBOK® 第2版「3.9.8リスクに基づいた技法」を参照し、テスト設計におけるリスクベースドテストを選択した。

事例7

成果物の品質強化

設計時にプロジェクト内でのレビューを実施したにも関わらず先行開発で実装・テストした際に、設計品質の問題が発覚したため、設計書の品質を再検証しなくてはならなくなった。SQuBOK® 第2版「3.8レビューの技法」を参考に、レビュー方法と技術的観点を決定した。

スキルアップのためのSQuBOK® の活用

事例として若手社員の育成及び自身のスキルアップのための活用を紹介する。
基本を押さえること、外の世界を知ってもらうことを目的に、基本知識を網羅的に学んでもらう、本来の意味を知ってもらう、他社の事例を知ってもらうことで若手社員の育成に使用している。
全体像をとらえること、個々の技術の関連や違いを知ること、言葉の意味を知ることに使用し、そこから参考文献・関連文献を詳細に調べることで自身のスキルアップに活用している。

おわりに

NTTデータにおいて、既存の標準類とSQuBOK® の対応を確認、プロジェクトの中でSQuBOK® を活用、若手社員や自分自身のためにSQuBOK® を活用している。

戻る

第5回特別講義 レポート
日時 2015年10月9日(金) 10:00~12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ 「メトリクスに統計手法を適用する意義、事例、ノウハウ」
講師名・所属 小池 利和 氏(ヤマハ株式会社)
司会 飯泉 紀子 氏(株式会社日立ハイテクノロジーズ)
アジェンダ
  • なぜソフトウェアメトリクス活用に統計手法が有効なのか
  • 事例を通じて統計手法適用のノウハウを解説
当たり前品質のマネジメント
 -開発終了後の事後分析事例
 -開発中のメトリクス管理事例
 -計画立案時の予測モデル活用事例
魅力品質のマネジメント
 -魅力品質マネジメントプロセスの概要
 -ユーザビリティテストにおける活用事例
 -音質の官能評価事例
 -市場での魅力品質評価事例
アブストラクト

ソフトウェアメトリクスは測定誤差が大きいため、データ指向による品質管理には向かないと考える人がいるかもしれません。特に理系出身で自然科学データを扱ってきた人はその傾向が強いようです。
ですが、経済学や心理学など人間の活動を研究対象とする社会科学分野では測定誤差が大きいのは当たり前のこととして、その中で研究結果の信頼性を確保しなければなりません。そのような分野では測定誤差以上の差や効果が有るかを示すために統計手法が活用されています。
ソフトウェアメトリクスは人間の活動を測定している側面が強く、まさに社会科学的データといえます。そのため、データを活用する上で統計手法は有用です。
本講義では、ソフトウェアメトリクスに統計手法を適用する意義とその際のコツを事例を通して解説します。事例には当たり前品質としての欠陥を対象としたものだけに留まらず、ユーザビリティや音質といった魅力品質に関する内容も盛り込んでいます。

講演内容

今回の特別講演では「メトリクスに統計手法を適用する意義、事例、ノウハウ」と題してヤマハ株式会社 品質保証部の小池利和さんから、講演を頂きました。
小池さんは、社内において、長年、品質活動に取り組んでいると同時に、社外におかれても、SQiP研究委員長、メトリクス演習コース主査として活動され、またソフトウェアメトリクスに関する著作も多数執筆されています。
今回の講演では、受講された皆さんが統計手法を現場活用できるように、と具体的な事例を多数交えて、非常にわかりやすい講演をしていただきました。ありがとうございました。

はじめに~本日のキーメッセージ
  • 推定誤差を常に意識することの重要性
  • これからの品質管理は、製品の良さを評価できないと、競争に勝ち残れない。
ソフトウェアメトリクスの分析に統計手法を使う意義
  • データ分析においては、2種類のエラーがある。
  αエラー(何となく信じてしまう“あわて者”)
βエラー(分析結果が信用できずアクションしない“ぼんやり者”)
どちらが正しいかは、“神のみぞ知る”、であれば、確率論をベースにした統計手法を用いる。
  • ソフトウェアメトリクスは誤差が大きいから使えない?
  誤差はあって当たり前、だからこそ、統計手法を駆使して情報を読み取るべき。
t検定を用いたデータ分析とその事例
  • 社会科学分野でt検定を用いた分析事例の紹介
    事例1:夫婦の関係満足度および生活充実感における規定因の検討
    事例2:恋人という間柄を意味する諸行為の記号学的分析
    事例3:テスト形式の違いによる学習方略と有効性の認知の変容
  3つの研究例とも、2つの群に分けてデータを収集し、その平均に「偶然とは言えない差があるかどうか」を検証する「t検定」という統計手法を用いて分析している。
  • 2群のデータの差を見る上では、「平均の差」「標準偏差」「データ数」を総合して判定する必要がある。
    その総合指標を「t値」と呼ぶ。t値の絶対値が大きいほど2群の差は大きいと言える。
    t値の計算式 t = d/s/√n d:平均の差、s:2群の標準偏差の加重平均、n:2群のデータ数
  • t値が0に近いなら2群の平均はほぼ等しく、0から離れていれば2群は違いがある、と言える。
    その離れ具合を示す指標が「P値」である。
    2群が十分離れている=等しくない=有意差あり、と判定するP値の基準は慣例的に5%とされている。
    P値が小さいほど、2群の平均は等しくない、と言える。
当たり前品質(不具合)のマネジメント
 
事例1

開発終了後データを用いた分析事例

  • 分析の目的
    不具合密度(システムテスト不具合数/新規開発行数)と不具合検出率(システムテスト不具合数/システムテスト工数)のどちらが品質指標として妥当か、を検証する。
  • 分析結果
    不具合密度と品質問題数の相関分析
    それほど高くなかった。
    リリース後の「品質問題無し群」と「品質問題有り」の2群の平均の差をt検定した。
    P値が0.36、となり5%より大きいため2群の平均値の差があると言えない。
    即ち、不具合密度と品質問題有無に関連があると判定できない。
    不具合検出率で同様の分析を行う。
    (この際、データの分布が片側に偏っていたため、「対数変換」という手法で偏りを補正する)
    結果はP値が0.002となり5%より小さくなった。
    よって、不具合検出率が小さい方がリリース後の品質問題が発生する可能性が低い、と判断できる。
    結論:品質指標としては、不具合密度より、不具合検出率の方が有効である。
事例2

信頼度成長曲線を活用したテスト計画と品質管理

  • 信頼度成長曲線とは、オープンチャート(時間軸に対する累積不具合数)を数学的なモデルで表現したもの。
    F(t)=K(1-e(-λt)) t:時間、k:総不具合数、λ:不具合の検出能力
    不具合検出率は、信頼度成長曲線の傾きに相当するので、信頼度成長曲線の式を微分することでモデル化できる。不具合検出率 = F'(t)=Kλe(-λt)
    また、残存不具合件数 = Ke(-λt)となる。
    不具合検出率と残存不具合件数の違いはλ、即ち、不具合の検出能力=テストのやり方である。
    つまり、テストのやり方がさほど変わらなければ、残存不具合数は不具合検出率で代替可能である。
  • 信頼度成長曲線の課題
    テスト開始序盤では、kやλのパラメータ推定値が妥当なものとならず、また終盤においても新たなデータが追加される度にパラメータ推定値は変わってしまう。
    その対策としては、過去の類似プロジェクトのデータを活用してパラメータを推定するという手段がある。
<実施手順例>
  1. パラメータK(総不具合数)は過去プロジェクトのデータの回帰分析を行って推定する。
  2. パラメータλ(不具合検出能力)は過去プロジェクトのデータでλを推定する。
  3. 目標不具合検出率の設定は、過去プロジェクトでリリース後の品質が良かったものの最終不具合指摘率の平均から設定する。
  4. ここまでの準備ができたら、モデルを使ってオープンチャートと不具合検出率のグラフを作成し、リリース時点で不具合検出率が目標に収まるか検証する。収まらない場合はテストリソースを調整して目標に収まるよう、テスト計画をシミュレーションする。
魅力品質のマネジメント
  • 品質部門が、製品の不具合検出や管理などの「当たり前品質」ばかり追いかけていては競争力が低下する。
    ユーザ視点を持って客観的に製品の良さを評価できる能力が必要である。
    そのためには統計手法が不可欠となる。
  • 魅力品質マネジメントプロセス
    1. 魅力品質目標を設定・・・“実現可能なレベルの数値目標“ではなく、お客視点で、具体的な比較対象(ライバル社製品)に対して、どれだけ魅力があるか、を具体的に設定。
    2. 設計検証・・・・納得できる被験者を集め、ユーザ視点での妥当性確認
  • 魅力品質マネジメントの事例
    事例1

    音の官能評価
    できるだけ客観性を持たせるよう、3つ以上の製品を比較する時でも必ず2つずつの組にして比較する「一対比較法」を用いて、「対象製品」「対象製品の前機種」「競合他社製品」の3つを比較評価した。

    事例2

    操作性(ユーザビリティ)評価
    製品のユースケースを「タスク」としていくつか抽出して被験者に実施してもらい、「有効性(タスクをマニュアル見ずに実施できたか)」「効率性(タスク所要時間)」「満足度(タスク終了後にアンケート)」の3つの観点で評価した。

    事例3

    魅力品質簡易評価シート
    事例1、2は被験者集めなど非常に手間がかかる方法であるため、品質部門メンバーだけで簡易的に評価を実施できるような評価シートを作成して評価した。

    事例4

    市場アンケート評価
    製品出荷後のユーザアンケート調査を分析した。満足度と重要度の2つの指標で散布図を描き、各アンケート項目がどの象限に位置づけられるかで対策を検討しやすくした「CSグラフ」という分析ツールを導入している。

本日講演した講義でのノウハウ(コツ)のまとめ
  • 「2群の母平均の差のt検定」は適用範囲の広い万能の統計手法なので、是非、マスターして欲しい。
  • ソフトウェアメトリクスはレンジの広いデータを扱うことが多い。その偏りを補正するためには「対数変換」が有効である。
  • ソフトウェアメトリクスは測定誤差が多いので、誤差を少なくする手法を検討すべきである。
    -個々のデータではなく、「データ群」としてとらえる
    -順位尺度を用いる
  • 統計ソフトを利用するだけではなく、その原理を理解して応用範囲を広げる。
質疑応答
Q: 音の官能評価、操作性評価を行った際の被験者の数はどのくらいか?
A: 経験から8から10人。2群で評価するため、偶数の人数としている。
Q: 信頼度成長曲線の事例に関して、貴社では事例を収集できるノウハウを積むまで、どの位の期間を要したか?
A: 自社の場合、およそ5年程度要した。
Q: 不具合検出率は信頼度成長曲線との傾きに相当する、ということで“瞬間”の値であると理解したが、実際にはある程度の期間で把握する必要があるのではないか?
A: 確かに、瞬間の値では変動が大きいため、実際データを取るときは、ある期間での移動平均でデータを取っている。
第6回特別講義 レポート
日時 2015年11月27日(金) 10:00~12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ 「UXの構築と評価方法」
講師名・所属 山岡 俊樹 氏(京都女子大学 教授 家政学部 生活造形学科)
安井 鯨太 氏(株式会社ジャストシステム UXデザイングループ)
司会 金山 豊浩 氏(株式会社ミツエ-リンクス ユーザエクスペリエンス本部)
アジェンダ
  1. 既存方法の問題
  2. なぜUXが必要なのか
  3. UXとサービス
  4. UX・物語の構造
  5. 制約条件
  6. 汎用システムデザイン UX構築方法と評価
  7. UXの事例(安井 氏)
アブストラクト

現在のデザイン方法は個人の体験をベースとした発想であり、大型システムやサービスのように抽象的なオブジェクトに対応するのは難しい。また、20世紀では機能・効率が重要視されてきたが、人々の暮らしが豊かになり技術だけでなく製品(機能)にサービス(デザイン)を一体化させたサービスシステムとして顧客の価値を創造していく必要がでてきた。このサービスシステムとして顧客の価値を創造していく活動がUXである。

製品の3属性(有用性・利便性・魅力性)と物語・感情を組合せてUXを作る。この組合せをフレームと呼び、仕事を分解したタスクの中で各々のタスクにどのような体験をどう積み上げて全体を構成していくかが重要である。人間の行動は環境から制約を受けている。それゆえデザインや設計も制約条件を最初に明確化し、制約条件から因果関係を持つ要素を抽出して、その構成要素を関連付けしてシステムを構築していく。汎用システムデザインでは、アブダクション(観察など)により要求事項を抽出し、これをもとに演繹的な方法でソリューションを絞り込み,システムを構築していく。

最後に、(株)ジャストシステムが立ち上げた転職情報サイト「ピタジョブ」での活動事例を紹介する。

講演内容

第6回の例会では、京都女子大学家政学部生活造形学科教授である山岡俊樹先生に「UXの構築と評価方法」と題してご講演を頂きました。フレームワークを適用することで魅力ある製品・サービスを効率的に開発する手法を、どこが悪いのか、どこが良いのか具体例を交えて説明頂きました。最後に、山岡先生の教え子である(株)ジャストシステムの安井様から転職情報サイト「ピタジョブ」でのUX事例を紹介頂きました。

山岡先生には具体例を交えて、安井様には具体的な事例で説明頂き、UXの勘所や適用した場合の注意点などをわかりやすく講演頂きました。山岡先生、安井様、ありがとうございました。

1. 既存方法の問題

現在のデザイン方法は個人の体験をベースとした属人的で局所解となっており、その体験が良いかどうかの裏付けもない。体験・イメージが先行した甘い方針でアイデアをもとにデザインしているため、良いかどうかの検証ができない。従って、現在のデザイン方法では大型システムやサービスのような抽象的なオブジェクトに対応するのは難しい。それでは、協創で良いアイデアが生まれるのであろうか。ワークショップで議論しても時間がかかり、その結果は参加者のレベルに依存する。
協創ではなく、なぜ体験と知識とフレームに基づいた「目利き力」をつけないのか。フレームワークをもとに考えれば、容易にあるレベルのアウトプットを出すことができる。

2. なぜUXが必要なのか

モノづくりの環境は変化している。20世紀では生産の効率化が重視されてきたが、21世紀に入り企画・デザインといった創造性が重要視されるようになってきた。
ヒドノミクスでは、価値を最下層から「安全性Safety」「機能性Functionality」「使用性Usability」「経験価値Pleasure Experience」「自己実現Individuation」と定義した。20世紀の視点では技術中心主義・人間中心主義であったが、21世紀に入り価値中心主義へとヒドノミクスの上位の価値へと視点が変化してきている。製品のデザインにおいても、この視点の変化を見ることができる。
人間中心設計について、ISO 9241-210で規格化されている。ただし、この規格にはコンセプトがない。本来であれば、コンセプトを作った上で対象ユーザを決めて設計すべきである。製品・システム開発においても、技術中心主義・人間中心主義からこれらを包含した価値中心主義へと移ってきている。

3. UXとサービス

人々の生活が豊かになり、単品だけではなくシステムとして価値を高めて対応する必要がでてきた。技術だけではなく、製品(機能)にサービス(デザイン)価値を包含したシステムとして顧客の価値を創造していく活動がUXである。UXに基づきサービスを構築した事例には共通事項がある。それは「顧客志向」であり「こだわり」であり、目的が明確であることがわかる。
ACM(the Association for Computing Machinery)は、UXを「機能」「ユーザビリティ」「楽しさ」の3要素からなるピラミッド構造モデルで説明した。この中で「ユーザビリティ」は重要な要素である。従来のデザイン方法は造形イメージからデザインをするので,論理と造形を一緒に検討することになるため、検討漏れが起き、様々な使い勝手の問題が発生している。恰好良いことと使い勝手とどちらが大事か良く考えて、前提条件(要件)を整理してデザインする必要がある。
デザインは「UX」「物語性」「感情」の三層構造で定義される。小さい体験の積み重ねで「UX」の閾値を超えた項目の共通事項が「物語性」となり、やがてそこからユーザに「感情」が生まれる。また、この「物語」により人と製品・システムが関連付けられ「ブランド」が生まれる。デザインするにあたって「デザインイメージ」「色彩」「フィット性」「形態」「機能・利便性」「雰囲気」「新しい組合せ」「質感」「意外性」の9項目を検討する必要がある。「物語」とは、人と製品・システムを結びつけることである。顧客にどうやって物語を伝えるか、言い換えれば、どうやって共感を呼ぶか、考える必要がある。「UX」により、ユーザに様々な経験をさせることにより共感を与えることができる。また、デザインに意味性を持たせて共感を与えることもできる。

4. UX・物語の構造

UXのマクロレベルの構造は次のようになっている。人・システム・環境といった外界とのやりとりから非日常性の感覚・獲得の感覚・憧れの感覚といった「結果(体験)」が得られ、その結果として喜び・驚き・興奮といった「感情」が湧き起こる。「体験」の内容と湧き起こる「感情」には関係がある。また、湧き起こった「感情」が物語となってブランドとなる。
製品の3属性として「有用性」「利便性」「魅力性」が挙げられる。この属性と物語・感情には繋がりがあり、これらを組合せてUXを作る。この組合せを「フレーム」と呼んでいる。仕事はタスクに分解することができ、分解したタスクの流れのなかで、各々のタスクにどのような体験をどう積み上げて仕事全体を構成しUXを作るかが重要である。

5. 制約条件

人間の行動は環境(システム)から影響を受けており、完全な自由はなく制約の中での自由である。従って、デザイン・設計時においても制約条件を考えるべきである。目的に対して人間の行動は制約条件によって決まるし、目的に対してデザインも制約条件によって決まる。制約条件から因果関係を持つ構成要素を抽出して、その構成要素の関連付けをしてシステムを作る。方針(制約条件)を最初に明確化して、システム思考でデザインしていく。従来方法では、甘いコンセプトを発散させてから収束させていくため時間がかかり、コンセプトからずれる可能性がある。厳密な構造化のコンセプトを作ってからシステムを作るべきである。
システムデザインをするにあたり、6制約条件「社会的制約」「文化的制約」「空間的制約」「時間的制約」「人間に関わる制約(思考・心理・運動)」「製品・システムに関わる制約」をグルーピングしてから発想すると良い。この方法を使うとアイデアが生まれ易く、演繹的に発想することができる。従来にない発想の良いアイデアが必要であれば、制約条件を広げて考えれば良い。

6. 汎用システムデザイン UX構築方法と評価

単純なシステムであれば発想だけで事足りる。しかしながら複雑なシステムでは感性と論理性(知識とフレームワーク)が必要となる。デザインには「使用価値(道具の機能)」「交換価値(造形)」「社会価値(社会に与える影響)」の3つの価値があり、21世紀に入り「交換価値」だけでなく「使用価値」も重要となってきた。思考法には「演繹法」「帰納法」「アブダクション拡張的推論」の3つがあり、汎用システムデザインではアブダクション(観察など)により要求事項を抽出し、これをもとに演繹的な方法でシステムを構築していく。
汎用システムデザインプロセスは「目的・目標の明確化」「システム計画」「ポジショニング・要求事項抽出・ユーザ他明確化・構造化デザインコンセプト」「可視化」「評価」からなる。従来のデザイン方法と異なり、手法が厳密で誰でも使うことができ、常に60点以上のシステムを設計することができる。

7. UX事例(安井氏)

(株)ジャストシステムが立ち上げた転職情報サイト「ピタジョブ」でのUX事例を紹介する。
企画フェーズの事例としてカスタマージャーニーマップとコンセプト評価の事例を紹介する。カスタマージャーニーマップは転職開始から終了までのフェーズを表現したもので、ユーザ体験を可視化しやすいように1枚にまとめたところがポイントである。コンセプト評価ではコンセプトがユーザの価値に合っているか、確認のため評価した。方法としては実験協力者にランディングページのみを見せ、その他の指示を与えずに、第1印象、気になる点、次に押したい箇所はどこか尋ねる方法とした。システムのコンセプトがユーザの要望に合っていない箇所がどこかわかった。また、コンセプトを作るに当たり「ターゲットユーザは誰か」をしっかり決めることは重要なことであることも改めて痛感した。
開発フェーズでは、ユーザ評価とデザインガイドラインの事例を紹介する。Web上でプロトタイプを作り、ユーザ評価に使用した。ユーザに使ってもらい評価するだけでなく、ユーザの行動も観察して課題を抽出した。デザインガイドラインでは、デザインコンセプトを決めるとともに出荷基準も定めた。
改善フェーズとして、仮説を立ててヒートマップ分析を使用してテストを実施した。分析評価ツールは有用であるが、使用するとページ速度が重くなるので注意が必要である。実践してみて、手法による評価よりも評価後の改善の仕組みを事前に整えておくことが重要であることが改めてわかった。

第7回特別講義 レポート
日時 2015年12月18日(金) 10:00 ~12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ 「積極的なソフトウェア構成管理の活用方法」
講師名・所属 長沢 智治氏(アトラシアン株式会社 エバンジェリスト)
司会 猪塚 修氏(横河ソリューションサービス株式会社 ソリューション技術本部)
アジェンダ
  • ソフトウェア構成管理の概要
-広義と狭義のソフトウェア構成管理
-ソフトウェア構成管理の構成要素
-ソフトウェア構成管理と変更依頼管理、ビルド自動化
  • ソフトウェア構成管理システム
-中央集中バージョン管理
-分散バージョン管理
-ソフトウェア構成管理システムの導入のポイント
  • 期待に応えるソフトウェアのためのソフトウェア構成管理
-ビジネスニーズとソフトウェアの品質の変化
-積極的なソフトウェア構成管理
アブストラクト

ソフトウェア構成管理は、ソフトウェア開発に常に寄り添い、活用されてきました。ソフトウェアへのビジネスニーズの変化と共に、ソフトウェアの品質への期待値も変わり、ソフトウェア開発現場も変わってきました。
今回は、ソフトウェア構成管理をテーマとし、ソフトウェア構成管理の過去、現在を俯瞰的な視点で見ていきながら、構成管理を積極的に活用している現場で行われているプラクティスやブランチ戦略なども見ていきます。

講演内容

今回の特別講演では「積極的なソフトウェア構成管理の活用方法」と題してアトラシアン株式会社 エバンジェリストの長沢智治さんから、講演を頂きました。
長沢さんは、長くIT業界においてプロセス改善コンサルタントとして活動され、また「ソフトウェア品質知識体系ガイド」「C#実践開発手法」など、著作も多数執筆されています。
今回の講演では、ソフトウェア構成管理というものが、単なる成果物のバージョン管理というものではなく、ビジネスも目標を達成の為に、積極的に活用していくにはどうするか、という斬新な視点から、非常にわかりやすい講演をしていただきました。ありがとうございました。

ソフトウェア構成管理の概要
  • 広義と狭義のソフトウェア構成管理
    ソフトウェアの構成管理とは、ソフトウェア開発における成果物の変更をコントロールすることである。現在の開発において生じる複雑な多岐にわたる成果物は、人手でのコントロールには限界があり無駄を生じている。、このため、ツールなどで行うことで、人は「意図したとおりのソフトウェアを作る」という本来の責務に注力できるようになる。

    ソフトウェアの開発の現場では「様々な要求への対応」「各種タスクの並行作業」「開発拠点の分散化」「確実で適切なリリース」といった非常に複雑な業務が要求されている。
    こういった「複雑さの軽減」のために、変更依頼をトリアージ(優先順位の意志決定)し、優先順位に沿って要求の変更と機能追加/バグ改修を行い、リリースする、という変更管理のプロセスを適切に運用する必要がある。

    狭義のソフトウェア構成管理は、このプロセスにおけるソースコードなどの成果物のバージョン管理を指すが、広義のソフトウェア構成管理は、変更管理の流れ全体を指し示す。
 
  • ソフトウェア構成管理の構成要素
    ソフトウェア構成管理の構成要素は①バージョン制御②ワークスペース制御③ビルド/リリース制御④プロセス制御、の4つである。
    ソフトウェアのバージョンを管理では「自分が再現したい状況を正しく再現できること」が求められる。それ故、「①バージョン制御」で管理されるリポジトリだけでなく、状況が再現される「②ワークスペース制御」も重要である。

    また近年のソフトウェア開発では、自動ビルドにより適切なリリースを目指すケースが増えているが、この場合も「③ビルド/リリース制御」で正しい情報が正しく取りだされた上で、ビルド/リリースが行われることが重要である。

    また、多数のチームが同時並列的に開発を行うケースも増えているが、こういうケースでは、バージョン管理~自動ビルド~リリースまでのプロセスを適切に運用するための「④プロセス制御」が重要となっている。
 
  • ソフトウェア構成管理と周辺構成
    ソフトウェア開発のプロセスにおける基本要素は、①人/役割②動機/行動③成果物、の3つである。

    この3要素は「プロセスの視点」でみると、仕様変更などの「動機/行動」によって「人/役割」がアサインされて作業されることで「成果物」が作成される、という流れである。
    しかし、「成果物の視点」でみると、その成果物を作成した作業をしたのが「人/役割」であり、かつ、成果物が作成された理由が「動機/行動」である、ということで、プロセスの前後関係や動機が不確かになる、というケースが多い。プロセス改善をバージョン管理ツールの導入だけで実現しようとする場合がこのケースにあたり、なぜ機能追加が必要になったか、という本来の動機や変更の理由がわからなくない、という状況に陥りがちである。

    この問題を解決するためにある「サポートシステム」として、「(変更の)動機」、「(それを作業した)人」までを管理する変更依頼管理のシステム(IssueTrackingSystem:ITS)があり、バージョン管理(SCM)、リリース管理(CI)と組み合わせて利用されている。これによって、複雑さが軽減され、いつでも構成を識別/公開することが可能になる。
ソフトウェア構成管理システムの仕組み
  • ソフトウェア構成管理の特徴
    ソフトウェアのバージョン管理の中心は「リポジトリ」と「ワークスペース」である。

    「リポジトリ」で成果物の格納、成果物のバージョン化、成果物構成・関係のバージョン化、が行われる。かつての構成管理では、ファイル1つ1つの版管理であったが、近年の構成管理では複数ファイルの依存関係も1つの「変更セット」として管理され、構成管理では「変更セットのトランザクション」を管理するものになっている。

    「ワークスペース」では、安全な成果物の「識別」、「取得・更新」、「利用と引き渡し」が行われる。

    ただ、実際には、「上書き」や「ファイル名を変えてコミットした場合」などのケースでは、正しく成果物を再現するには、ある程度人手によるプロセスも不可欠である。

    また、より積極的に構成管理を活用するケースでは、ブランチを作成し、成果物をマージしてチェックアウト、チェックイン、という使い方になる。こういう場合は、チェックインポリシーを策定する必要がある。

    また、ソースコードの識別・再現だけでなく、ビルド/リリースの構成の識別も重要であり、これによって、バグの特定が容易になる。  ソフトウェア構成管理のプロセス管理の適切な運用は、構成管理の属人性を排除し、ミスや手間の軽減につながる。その為の手段としては、構成管理の運用ポリシーを策定し、たとえば「バグはIDが与えられていないとコミットできない」というような運用ルールを定める必要がある。
 
  • 中央集中バージョン管理
    中央集中バージョン管理(CVCS)は、中央に単一のリポジトリを置くもので、管理・制御の集中化が容易となる。例としては、SVN、Clear Case、TFSなどがある。
    正しいものが置いてある場所が、常に中央のリポジトリである、という点が明確なシンプルなシステムだが、そのため、常にリポジトリに接続する必要がある。
 
  • 分散バージョン管理
    分散バージョン管理(DVCS)は、ワークスペース毎にlocalのリポジトリを持ち、それらの分散したlocalリボジトリを中央のremoteリポジトリが管理する形態であり、Git、Mercurialなどがある。localリポジトリがある為、ワークスペース毎に独自にバージョン管理を行うことができるので、オフラインの作業環境でも対応できる、という利点がある反面、プロセスの制御が複雑で制御しにくい、という欠点もある。
 
  • ソフトウェア構成管理システムの導入のポイント
    CVCS、DVCSのどちらの構成管理を導入すればよいか、という指針は、以下の通り。
    「頻繁な変更」「地理的に分散」「複雑なブランチ戦略」「他システムとの連携が複雑」「ソーシャルコーディング」・・・これらのキーワードで一つでも当てはまるなら、DVCSが適している。
    「変更は緩やか」「リポジトリ常時接続可」「堅実な構成管理」「定型的ブランチ戦略」「他システム連携は緩い」「メンバーが構成管理に慣れていない」・・・これらのキーワードが全て当てはまるなら、CVCSが適している。

    近年では、DVCSを採用するケースが増えているが、特にDVCSが適合するケースは、以下の通り。
    「反復」「フィードバック」の多いアジャイルプラクティスを行う場合
    それぞれの目的別に複数のブランチを作って管理するモダンブランチ戦略を採る場合

    (Pull Requestが可能なGithubFlowなどがよく用いられている)
    DVCSに対応した、ITS、CIシステムを使った、“広義のソフトウェア構成管理”を行う場合
期待に応えるソフトウェアのためのソフトウェア構成管理
  • ビジネスニーズとソフトウェアの品質の変化
    売上増などのビジネスニーズを満たすためにITを積極的に活用することを、近年ではDevOps(ビジネス駆動ムーブメント)と称している。DevOpsを実現するために重要なことは、ソフトウェア成果物の「共同所有」という概念である。特に近年では、インフラのコード化が進み運用側での成果物も増えているため、開発・運用双方の成果物を互いに共有する必要性が高まっている。故に、ソフトウェア構成管理は、開発・運用の協調のための情報インフラとしても重要になってきている。
 
  • 積極的なソフトウェア構成管理
    ソフトウェア構成管理はソフトウェア開発の複雑さを軽減させるが、それだけでなく、コミュニケーション、コラボレーションを高める役割も担っている。例えば、コード単位の情報は開発者には理解できても経営層には理解できないので、ソフトウェア構成管理で経営層に理解できる“粒度”まで調整する必要がある。

    その他、アイデアがビジネスの価値になるまでの流れを重視する「Flow of Value」や、従来の構成管理より、各自の知見を集めた集合知を活用する「ソーシャルコーディング」といった開発手法を実践する上でも、ソフトウェア構成管理が活用されてきている。
質疑応答
Q: DevOpsの話の中で、成果物の「開発と運用の共同所有」の重要性が指摘されていたが、「共同所有」することでの具体的なメリットや事例などを聞かせて欲しい。
A: 近年は、クラウド環境を利用したサービスなどでは、開発と運用の壁がなくなる「ボーダーレス化」が進んでいる。ここでは、開発側はインフラの制約を考慮する必要があり、一方、運用側もアプリケーションの制約を考慮する必要がある。こういうケースにおいては双方の成果物の「共同所有」が非常に重要になっている。
また、オープンソースなどのソーシャルコーディングの現場では、成果物の共同所有が重要なのは当然だが、共同所有することで、今までに無かった新しい知恵を出し合っての改善が進められている。
第8回特別講義 レポート
日時 2016年1月15日(金) 10:00 ~12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 地下1階 講堂
テーマ 「レビューを失敗させるコツ」
講師名・所属 原 佑貴子 氏(日本アイ・ビー・エム株式会社 グローバルビジネスサービス)
司会 中谷 一樹 氏(TIS株式会社 生産革新本部)
アジェンダ
  1. レビューを実施する理由
  2. レビューを失敗させるコツ
  3. これからのレビュー
アブストラクト

レビューを実施することは必要なことだと理解していると思います。それにも関わらずレビューが嫌いだと思っている人、有効なレビューができていないと困っている人が大多数です。レビューは40年以上もの実績がある手法です。ここで説明する7つのコツで、レビューが開発のように面白くて楽しいものになって欲しいと思います。最後に、これまで人間がマニュアルで実施してきたレビューがこれから先どう変わっていくのか考えてみます。

講演内容

第8回の例会では、「レビューを失敗させるコツ」と題して日本アイ・ビー・エム株式会社の原さんにご講演を頂きました。「失敗させる」という興味を引くタイトル、7つのコツを7番目から順番にカウントダウンしていく構成、聴講者を巻き込んで考えるなど最後まで楽しく、そして原さんのレビューに対する熱い思いが十分に伝わった講演でした。原さん、ありがとうございました。

1. レビューを実施する理由

レビューを実施することは必要なことだと皆さん理解していると思いますが、それにも関わらずレビューが嫌いな人が大多数です。その理由は、バグを好んで入れ込む人は決していないにも関わらず、知らず知らずに入れ込んでしまったことを責められている感じがするからだと思います。また「レビューをすると品質があがる」と思われるかもしれませんが、それは単なる迷信です。レビューを実施するだけでは単にバグが検出され品質が悪いことがわかるだけです。検出されたバグを利用して改善(フィードバック)することによって、始めて品質が向上するのです。
また、有効なレビューが実施できていないと困っている人が大多数です。その理由として「効率的なレビューができていない」・「重要な欠陥が検出できない」といったことが挙げられます。突き詰めていくと「レビュー時間を確保できない」・「軽微な欠陥(誤字・脱字)しか検出できない」といったことなどが理由となります。
こういった状況に陥ってしまう理由をこれから共有していきたいと思います。

2. レビューを失敗させるコツ

これから7つのコツを説明します。カウントダウン方式になっていて7番から始まって最後は1番となっています。

7)

7つのステップ

フォーマル・インスペクションはIBM Kingston研究所のMichael E. Faganらが1960年代前半にテスト前にソースコードからバグを除去したいという思いで考案し、徐々にブラッシュアップして上流の仕様書にも適用できるようにした手法で1976年に公に発表しました。ソフトウェア工学の方から、どんなに良い手法であっても儲けが確保できなければその手法は定着しないと言われたことがあります。その点からするとフォーマル・インスペクションは40年以上もの間使い続けられている手法であり、正しく使えば必ず儲かるハズです。
レビューには7つの手順(開始基準、プラン、準備、ミーティング、リワーク、フォローアップ、完了基準)があります。この手順の中でのポイントを述べます。

  • 開始基準を満たしているか(※1)
    レビューに値する成果物かどうか、例えばゲートのレビューで成果物に次のような言葉がある時は闇雲にレビューを始めてはいけません。(To Do、要検討、~のハズ、~かも、といったような言葉)
  • レビューの計画を立てる
    テストに計画があるように、レビューにもいつからいつまでの段階で、誰が、どのような見方でレビューするか計画を立てる必要があります。会議室に集まってミーティングをすれば良いというものではありません。
  • レビューの前に個人で事前チェックをする
    レビューの前に対象の資料を配布しレビューまでに個人で事前にチェックします。軽微な欠陥(誤字・脱字、フォーマット、細かい指摘、等)をオフラインで担当者に伝えて事前に修正しておきます。レビューのミーティングでは重大な欠陥のみを持ち寄って実施するのが本来のレビューの形です。
  ※1 イテレーション開発のように徐々に開発する場合(質疑応答から)  プロジェクトの状況・前提を事前に確認してから実施して下さい。どこまでできているかを前提としてレビューして下さい。第三者的には、レビューで検出した結果が問題なのか、まだ取り掛かっていないだけなのか判断できないので要確認事項として挙げた上でプロジェクトの前提をもとに最終的に判断して下さい。
6)

6手法の使い方

レビューには代表的な6つの手法があります。厳密性の高い手法から、フォーマルインスペクション、ウォークスルー、パスアラウンド、Nフォールドレビュー、2パーソンインスペクション、個人レビュー・セルフチェックとなります。レビューを選択する基準としては欠陥検出精度、コスト負荷、時間負荷、検査の厳密性、チームワーク・組織醸成、教育効果・技術移転、専門教育(トレーニング)の必要性、記録・フォロー活動追跡、管理の難易度が考えられます。
プロジェクトのリスクや制約事項(状況やアサインできるメンバ等)に応じてレビュー手法を選択します。その選択の仕方には考え方がありますので、いくつかの事例を紹介します。

例1]

プロジェクトに時間制約が多く、レビューする時間がとれない場合

フォーマルインスペクションまたは2パーソン・インスペクションで、フェーズの立ち上がり時期にレビューします。1回目は、開発者が最初の成果物を書きあげた時期にレビューします。仕様書であれば記述(書き方)の属人性を確認し書き方のバラツキを開発の初期に抑えます。2回目は、機能性の欠如や、時間がない時は正常系の仕様に専念しがちなので例外処理の抜けがないかレビューします。このようにしておけば後のフェーズが楽になります。

例2]

品質を最優先する場合

特に人の命が関わっているようなソフトには、Nフォールド・レビュー(※2)を使います。人数と回数を複数に分けてレビューしていきます。

例3]

プロジェクトメンバの技術力の差が大きい・経験差がばらつく場合

例えば初めてレビューに参加して何をチェックしてよいかわからない場合、ベテランと二人一組で観点を教えてもらいながら同一の対象をレビューします。2パーソン・インスペクションまたはウォークスルーで、ベテランが持っている見方・考え方を継承していきます。

例4]

集合レビューができない場合

パスアラウンドでレビューします。対象の仕様書をまず最初の人がチェックした結果を記入して、次の人に渡します。次の人は、その前の人のレビューした結果の上に更にチェックした結果を記入します。このようにして、どんどんレビューした結果を追記していきます。一番最後の人が腕の立つ人でないと大変ですが、これも前の人の考え方とかが学べるので良いトレーニングとなり技術の継承ができます。

※2 Nフォールド・レビューとは?(質疑応答から)
多重度を高めてレビューする方法です。多重度には、チーム編成が多重(複数のチーム)、あるいはチームで視点を変えながら複数回レビューを繰り返すといった方法が挙げられます。いずれにしろ冗長性を高めてレビューを実施します。フォーマルメソッドとは違った厳密なルールがあり、トレーニングが必要です。
 

【参考文献】
「ピアレビュー」 Karl E. Wiegers著 日経BP社

5)

5人以上でレビューすると破綻する

5人以上でレビューしてもレビューの結果に対する議論が発散しますし、バグの検出傾向もそれほど変わりません。検出結果も重なりがちとなりますし、いくら上手くリードしても結局何が悪いのかまとめることが大変となります。

4)

4つのロール

フォーマル・インスペクションでは、4つの役割を定義しています。レビューをリードするModerator、仕様書やソースコードを読むReader、仕様の矛盾や結果の指摘をするValidator(検証者)と作成者であるAuthorの4人です。
このレビューの会議でのポイントは作成者であるAuthorに説明させないことです。書かれたことが他の人にどのように解釈されるかを検証するのがレビューですので、読み手であるReaderが読み上げます。ここでの一番のキーポイントは「言い換え(paraphrase)」をすることです。Readerは仕様書をただ読み上げるのではなく、仕様書やソースコードに書かれている事を自分の言葉で言い換えます。言い換えることにより作成者の意図とあっているか確認します。ReaderとAuthorのやり取りと、Validatorのチェック結果をもとに作成者が欠陥なのか要確認項目なのか意図の相違なのかを判断していきます。
もう一つのポイントは会議の中では欠陥の検出に集中することです。原因や対策の議論はしません、むしろしてはいけません。ミーティングの時間が無駄に延びてしまいます。
欠陥検出に集中して議論が白熱すると、これも欠陥ではないかとか新たな見方とか出てくることがあり、これをファントム効果と言います。こういった経験をするとレビューが楽しくなってくると思います。

3)

仏の顔も三度まで

いろいろなプロジェクトでレビューを実施していくと、ある組織体とかある企業とかで検出されるバグの傾向が似てきます。プロジェクトが扱うソフトウェアの性質や開発メンバのスキルセットの差とはあまり関係なく、組織や企業の教育方法によってバグの傾向が変わってきます。組織や企業の方針や教え方によって間違い方が異なります。
何度指摘してもバグの傾向が変わらない場合には、その組織体そのものに改善するようお願いしていきます。

2)

思わず二度見

怪しい言葉であるNGワード(To Do、~のはず、~かも、「?」、といったような言葉)がフェーズの完了時に仕様書やソースコードのコメントに残っている場合は、フェーズ移行は許可できません。仕様書とかソースコードで出会ったこういったNGワードを蓄えておけば、この先のレビューで出てきた場合に必ず検出することができます。そのほか、暫定、対応、とりあえず、一旦、保留、別途、検討、といった言葉がNGワードに該当します。
このようなNGワードがどこで使われているか調べることにより、どういったところができていないのか、どのあたりが問題なのか、どういったところで困っているのか仮説を立てることができます。しかしながら、こういったNGワードが書いてあること自体が悪いわけではありません。記録してあるからこそ、後から直すことができます。担当者がどういったことで苦労しているのか、その実態をマネジメント層が理解できているかということが重要です。

1)

一発勝負レビュー

フェーズの最後に8割ぐらいできた段階でまとめて1回でレビューするべきではありません。レビューの対象が多ければ多くなるほど指摘件数が多くなります。指摘に対応する工数が確保できず、次フェーズに繰り越しになってしまいます。
一度に実施したい気持ちもわかりますが、成果物は「こまめに」レビューするべきです。バグの含有率も減少しますし、重大なバグの検出率も上がります。例えば、フェーズの立ち上がり・中間・最終(8割程度完成)の3段階で実施するだけでもバグの傾向を含めて状況が変わります。実施してみると、最初は現場から抵抗がありましたが、実際には現場の負担感も減るようです。フェーズの立ち上がりでバラツキを抑えて、中間で維持されているかチェックするとともに進捗の確認や傾向を分析し、8割程度できた段階で全部通してどうかというように見方も変えてレビューします。

3. これからのレビュー

開発手法がいろいろ進歩していく中で、人間がマニュアルで実施してきたレビューがこの先どう変わっていくのか考えてみたいと思います。
レビューで検出できるバグにはレベルの階層があると考えています。誰でも検出できる誤字脱字といったものから、抜け漏れとか保守性といった難易度の高いものまであります。標準に則っていないといった簡単なものから、表現が不統一とか矛盾しているといった検出しやすいもの、一見して読みにくいとか一意性が欠如しているといった難易度の低いバグがあります。そういった難易度の低いバグを取り除いた後でやっと難易度の高いバグを検出することができるのが実際です。多くのレビューでは、軽微なバグがノイズになって重大なバグを埋もれさせてしまうという面があります。
軽微なバグの抽出に人間の労力を使わずに、そういったところは自動化して検出できるのではと考えています。自動化ツールを使って軽微で作業的なドキュメントの品質検証を実施し、人間の思考をもっと高度な検証に使います。チェックリストに書かれていて人間が実施しなくても一定の作業でできるようなチェック項目は、自動化していくことができると考えています。夜中にこのようなツールを実行して翌朝には結果が出力されているようになれば、レビューの負担を軽減することができますし、早い段階でバグを撲滅することができるようになります。バグの潜在期間が短いうちにバグを取り去ることができるようになり、スピードアップができるのではないでしょうか。

さてここで、みなさんに問いかけたいと思います。「レビューは作業(頭を使わずに手だけ動かす)でしょうか?」。レビューはメトリクスの計測をしたり分析したり仮説を立てたり、いろいろ試行錯誤するクリエイティブな仕事だと思います。しかし、テストに比べて自由度が高いために、それゆえに扱いの難しさが先行し楽しさから遠ざかっているのではないかと思います。本来レビューは辛いものである必要はなく、また決して堅苦しいものではありません。人をあざ笑うものではなく、バグがどこからきたのかこのバグは何者なのか、バグを楽しんでもらいたいと思います。
もう1つ。「レビューを楽しいものにしていないのは誰でしょう?」答えは敢えてここでは言いませんので、みなさん自身で考えてみて下さい。レビューで人に何か言われたから面白くなくなってしまったのであれば、レビューする側になった時には、そういう風に思わせないようにして下さい。決してレビューは不必要な手法ではないので、レビューで見てもらいたいとまた思うように、開発のように面白さ・楽しさをどこかで感じてもらいたいと思います。
レビューを失敗するコツを話してきましたが、最後に、レビューをうまくやるコツについてお話しします。成果物を見ているだけではレビューが上手くいくとは思っていません。バグそのものを突き詰めていけば、それは人が作り込むものです。レビューでは、その人自身とか、その人を取り巻く環境に目を向けて欲しいと思います。そういうところにレビューで仮説を立てるヒントがあると思います。

第31年度SQiP研究会 成果発表会ルポ
〜ソフトウェア品質技術の領域を拡大し、適用する一年〜

加藤 蔵次((株)デンソー  第31年度SQiP研究会書記)
齋藤 伸介((株)メタテクノ 第31年度SQiP研究会書記)

2016年2月26日に日本科学技術連盟 東高円寺ビルにて、第31年度(2015年度)SQiP研究会の成果発表会が開催されました。
今回はその成果発表会の模様とSQiP研究会の紹介、1年間の研究活動を通して感じたことを記載します。

SQiP研究会とは

ソフトウェア品質管理研究会(SQiP研究会)は、ソフトウェアの品質管理への入門としての位置づけから、高い管理技術、開発技術を目指した議論・学習できる場として、幅広い要請にこたえる内容と品質管理分野の第一人者を指導者として高い評価を得て、今年32年目を迎えます。本研究会のメインの活動である分科会では「問題発見」、「解決手段」、「実践」という3つの視点からソフトウェア品質技術を研究、調査、実践していきます。分科会の他にも、特別講義や合宿、そしてSQiPシンポジウムを通じ、体験し気づきを得ることで、成果を出す仕組みとなっています。

研究員の職場の問題発見

  • 最先端を知る (特別講義・指導陣)
  • 他社からの新たな視点 (研究員)
  • 客観的な意見 (指導陣・研究員)

解決手段

  • 専門的知識 (指導陣)
  • 豊富な実践経験 (指導陣)
  • 深く考える (指導陣・研究員)

職場での実践

  • 相談ができる (指導陣)
  • 心の支えになる (研究員)
  • 一生付き合える仲間

今年度は、マネジメントとエンジニアリングの両面をカバーする7つの分科会と3つの演習コース、1つの特別コースが設けられ、個人や組織において有用な新技術の発明、および、既存技術の整理、実問題へのノウハウの蓄積と展開について成果をあげました。

成果発表会の模様

冒頭、小池委員長から、来賓された研究員の上司の方々に向けて、「そもそもSQiP研究会の活動は、どの研究員も普段の業務を行いつつ、他社の研究員と共同で論文を作成する、という“無茶なプロジェクト”である。その事を念頭に、SQiP研究会の運営について忌憚の無いご意見をいただきたい。」と挨拶が行われました。その後、各研究チームの発表が始まりました。

成果発表会は、1発表につき15分間のプレゼンテーションと5分間の質疑応答により実施されました。今回は13件の論文報告と4チームの活動報告がありました。各チーム共、この一年のSQiP研究会の活動の集大成として成果報告であるだけに、いずれも熱の入った報告でした。

SQiP研究会の成果発表会は、これまでも発表の中で寸劇が行われるなど、趣向を凝らした発表が行われてきましたが、今回も、ウクレレでBGMや効果音をつけて発表するチーム、なぜかミッキーマウスとともに?発表を行うチームなど、聞いている側を飽きさせず、楽しませる工夫も随所に見られました。

成果発表会の運営に関わった書記の立場として述べると、いずれのチームの発表も、質問時間を含めて制限時間内に見事に収まっている点が、ある意味、驚きでした。これは各チームとも、事前にプレゼンの練習を相当重ねて本番に臨んできたのだと思われました。

発表の様子
 

また、今年度の成果発表会での新たな取り組みとして、来賓された上司の方々との懇談会が、昼食時と成果発表会後の二回実施されました。ご派遣する際のお気持ちや部下の方々の取り組み・成果について指導講師の皆さまと深くお話しをされていました。
お忙しい中、参加していただいた上司の方々には終日参加する事は難しい方も多かっただけに、この昼食時の懇親会は好評だったようです。

懇談会の様子
上司の方々と指導講師の皆さま

成果発表会の終了後、最優秀論文の表彰式が行われ、その後の各分科会・コースでの反省会をもって、今年度のSQiP研究会活動が終了しました。

最後は、全員参加による情報交換会が開催されました。締めは、25年間このSQiP研究会に携わっていただき、長年、研究会の運営委員長をお務めいただいた、今期第5分科会アドバイザーの堀田文明様からご挨拶をいただき、閉会となりました。

今年度の受賞結果

成果発表会で発表された13本の論文については、指導講師による論文評価が行われました。審査結果について、鷲﨑副委員長から、「今年度、優秀賞は該当なし、最優秀賞は2件」と発表され、以下のとおり2本の論文について表彰されました。

 
最優秀賞

第6分科会(派生開発 Bグループ)
『派生開発でのユーザビリティの劣化を防ぐ方法』

第6分科会 派生開発Bグループ
指導講師・メンバーと小池委員長・鷲﨑副委員長
最優秀賞

第7分科会(欠陥エンジニアリング X2チーム)
『ソフトウェア開発における欠陥情報移転法の提案』

第7分科会 欠陥エンジニアリングX2チーム
指導講師・メンバーと小池委員長・鷲﨑副委員長

また、成果発表会でのプレゼンテーション内容についての審査も行われ、以下のチームがプレゼンテーション賞を受賞しました。

 
ベスト・オブ・ザ・プレゼンテーション賞

第3分科会(ソフトウェアレビュー 餡餅チーム)
『SBR法(ステルスベースドレビュー手法)の提案』

“SBR法の提案 ステルス情報に着目した重大欠陥検出の新しいアプローチ”

第3分科会ソフトウェアレビュー餡餅チーム
指導講師・メンバーと小池委員長
 

【鷲﨑副委員長講評】

審査は指導講師により、各論文に4名が査読を行い、「有用性」「信頼性」「構成力」「新規性」を観点に審査を行った。各観点について、今年度の論文の傾向は以下の通り。

有用性

例年に比べて、今年度は有用性の高い論文が多かった。

信頼性

有用性に比べると、やや低い傾向であった。

構成力

例年に比べて、評価が高かった。過去の研究会では、まだ「レポート」レベルの論文も散見されたが、それに比べると、今年度は、どれも、論文としての域に達していた。

新規性

例年に比べて、やや高いレベルであった。

SQiP研究会の活動を振り返って

第32年度ソフトウェア品質研究会
株式会社 デンソー
加藤 蔵次 氏

私は品質保証部門に所属しています。設計部門から異動して7年、我流でここまで品質保証業務に携わってきました。

会社の先輩から「SQiP研究会の書記をしないか。」との誘いがあり、ソフトウェアの品質保証を一通り学べる「特別コース:ソフトウェア品質保証の基礎」に参加しました。各回テーマに応じた講義とディスカッションで、遅まきながら「品質保証の基礎」を学ぶことができました。また、グループ討議での意見交換や主査/副主査からアドバイスで「そうか。」と思うことも多くありました。またアフター活動では、リラックスした雰囲気の中で参加者各自の状況を発表、ホンネで議論することができました。午前の特別講義と合せて、品質保証を担当して2~3年目の方に大変お薦めなコースです。自分自身の品質保証業務の改善に色々なヒントが得られると思います。

私自身も今回で得られた知識をこれからの業務に少しでも生かしていくことができるよう頑張っていきたいと思います。

 
第32年度ソフトウェア品質研究会
株式会社 メタテクノ
齋藤 伸介 氏

私は今年度、SQiP研究会に初めて参加させていただきましたが、初めてにも関わらず研究員かつ書記という立場での参加で、本音を言えば、かなり負担の大きい一年間でありました。

論文を書いた経験は、大学の卒業論文や、社内論文への投稿など、数回の経験しかありませんでしたが、それらはいずれも自分一人で単独で作成したものであり、今回のような他社の研究員の方々との共同作業による論文作成は全く初めての経験でした。

特に私の参加したチームは、研究員5人は関東、東海、中京、関西と別れているため、月1回の定例会で顔を合わせる以外は、ほとんどがネット上でのやりとりを介した作業でありました。ただ、やはりネット上での作業には限界があるため、SQiPの定例分科会以外にも、臨時の分科会を数度開催し、夜遅くまで議論を繰り返しての作業となりました。

論文を書く上では、まず骨子を固める、ということが最も重要ですが、この骨子を決まるまでが苦労の連続で年末近くになってもなかなか定まらず、一時は、「もう論文作成は無理なのではないか?」という所まで追い込まれた事もありました。

しかし、指導講師の方々の熱心な指導もあり、何とか論文の骨子が見えてからは、年末休みの間も「大掃除しつつ論文、年賀状書きながら論文」という状態で年を越してしまい、なんとか締切までに論文作成を終えることができました。

その苦労もあり、今回、私達のチームは最優秀賞を受賞させていただきました。今となってみれば、やはり苦労した分、得られた成果は大きかった、と感じます。

今後も、我が社としては、継続してSQiP研究会に参加を続け、IT業界の品質向上へ寄与していきたい、と考えております。

おわりに

SQiP発足から32年目となる2016年度も今年度に引き続き、「ソフトウェア品質技術の領域を拡大し適用する一年」というメインテーマを掲げ、既に2016年度の研究員の募集も開始されています。
SQiP研究会は、2年前から(1)研究成果の質の向上、(2)習得スキルの実務適用、という2つの方向性で運営されています。

(1)を目指す研究員は、SQiPシンポジウムや他の学会への論文投稿へのチャレンジもサポートしていきます。
(2)を志す研究員に対しては、1年間の活動終了後にも、実務に適用した経験を共有できる場を設け、研究会卒業後も刺激を与えあうような関係性を維持する仕掛けを作ります。

つまり、品質管理に関するベテランでも、初学者でも各自のレベル、指向にあった場が提供されているのが、SQiP研究会なのです。是非、初学者の育成や職場の将来を担うリーダーの育成としてSQiP研究会を活用していただければ幸いです。

戻る
研究会
ソフトウェア品質管理研究会
ソフトウェア品質知識体系ガイド
 
 
日本科学技術連盟

SQiPは、ソフトウェア品質管理技術・施策の調査・研究・教育を通じて、実践的・実証的な
ソフトウェア品質方法論を確立・普及することにより、ソフトウェア品質の継続的な向上を目指します。

 
 
Copyright© 2015 Union of Japanese Scientists and Engineers. All Rights Reserved.