Rakuten Tech Meetup #2 基調講演

1. 森崎 修司
名古屋大学 大学院情報学研究科
https://twitter.com/smorisaki
ソフトウェア開発活動のデータとアナリティクスの3原則

2. アジェンダ
• Dev/Opsに関連するソフトウェア開発の変化
• ソフトウェア開発活動のデータとアナリティクスの3原則
– 現実を適正に表す。
– 行動につながる。
– チーム（関係者）で合意、実行できる。
• データ収集とアナリティクスの事例
– ソースコード規模遷移をもとにした開発作業の優先順位付け
– バグレポートに記録された修正コストをもとにしたレビュー分担
– ソースコードメトリクスによる欠陥予測の設計モデル(Simulinkモデル)への拡張
2

3. 開発と運用の境界の希薄化
開発(design time)と運用(run time)の境界が様々な分野で薄れてきている。
• Web/クラウド
– カナリアリリース、β版
– Phased rollout, A/B testing
• 米軍
– “Developing certifiable V&V methods for highly adaptive autonomous systems is
one of the major challenges … “
US Air Force Technology Horizons – A vision for Air Force Science and
Technology 2010-2030 (https://apps.dtic.mil/dtic/tr/fulltext/u2/a562237.pdf)
• 自動車
– 自動運転の安全性検証プロジェクト
PEGASUS Research Project: https://www.pegasusprojekt.de/en/home
3

4. Technology Horizons - 米軍の科学技術部門のレポート(2011年)
4
https://apps.dtic.mil/dtic/tr/fulltext/u2/a562237.pdf

5. PEGASUSプロジェクトの走行情報データベースに関するドキュメント
5https://www.pegasusprojekt.de/files/tmpl/pdf/AVT%20Symposium%202017%20Database%20traffic%20scenarios_Folien.pdf

6. シナリオデータベースへの入力
6https://www.pegasusprojekt.de/files/tmpl/pdf/AVT%20Symposium%202017%20Database%20traffic%20scenarios_Folien.pdf

7. CPS(Cyber Physical Systems)
• CPS(Cyber Physical Systems): コンピューター上に実世界をモデル化し、分析で
きるようにする。
a. 実世界の情報をセンサーやカメラから得る。
b. 得られた情報から傾向分析、予測、現状把握をする。
c. 傾向分析、予測、現状把握の結果を実世界にフィードバックする。
7
実世界 データ／モデル化
a. 情報を得る
b. 分析、予測、把握
c. フィードバック

8. ソフトウェア開発活動のデータとアナリティクスでは・・・
8ソフトウェア開発 データ／モデル化
a. 情報を得る
b. 分析、予測、把握
c. フィードバック
実世界 データ／モデル化
a. 情報を得る
b. 分析、予測、把握
c. フィードバック

9. 開発活動のデータとアナリティクスの3原則
a. 情報が適切である。
b. 分析、予測の結果行動に移せる。
c. 行動に合意(協力)を得られる。
9
a. 情報を得る: 適切か？
b. 分析、予測、把握: 行動に
移せるか？
c. フィードバック: 協力を得られるか？

10. 開発活動のデータとアナリティクスの3原則とアンチパターン
a. 情報が適切である。
– × 知りたいこととは違う情報を得ている。
b. 分析、予測の結果行動に移せる。
– × 良くない状況が観測されても対策しづらい。
c. 行動に協力を得られる。
– × 報告を加味せず判断する(判断側)、基準が適切でない(情報提供側)。
10
a. 情報を得る: 適切か？
b. 分析、予測、把握: 行動に
移せるか？
c. フィードバック: 協力を得られるか？

11. 事例1： ソースコード規模遷移による進捗共有
• 対象: 研究用統計ツールの委託開発（C言語/20KLOC）
• データ: 機能ごとのソースコード規模遷移のグラフをみながら、委託者・受託者が
開発の情報共有をする。
• 目的: 開発途中段階のツールでの分析結果を論文として投稿する。
ソフトウェア開発 データ／モデル化
a. 機能ごとのソースコード規模遷移
b. どの機能を優先して開発する
か決める
c. 機能の開発に割り振る
時間を変える

12. 事例1：ソースコード規模遷移グラフ
• A~Fは機能を表す。
“inspection”はレビュー実施日を、 “testing”はテスト報告の更新を表す。

13. 進行中: ツールによるタイムスタンプを利用した詳細な分析
13
Mariam B. Traoré 氏との共同研究

14. 事例2: バグレポートの分析 - 業務観点でのレビューの分担
• 分析の目的
修正コストの大きなバグ種別を特定してレビューを委託側、受託側で分担できる
ようにする。
• 分析対象
– 不具合の原因分析でレビューに原因があると判断されたバグ
– 大手銀行の外貨有価証券の取引入力、記帳管理システム
14ソフトウェア開発 データ／モデル化
a. 過去のバージョンのバグの記録
（説明）と修正コスト b.レビューで見逃した修正
コストの大きい欠陥種別を
特定する。
c. レビューの分担を欠陥
の種別で決める

15. 事例2: 不具合情報（一部抜粋）と結果
15
項目 形式 説明
原因分析 選択肢
（33項目）
「レビュー不備」「レビューア不十
分」「レビュー観点不備」等
対応工数 数値 修正に要した工数
現象、原因、
対策
自由記述 不具合の現象、原因、修正方法
の記録
・・・ ・・・ ・・・
分類 件数 平均修正コ
スト（時間）
日付に関するバグ 86 2.10
日付以外のバグ 401 1.68
全件 488 1.75
• 日付に関わるバグとそうでないバグで修正コストに統計的に有意な差があること
がわかった。
• 日付に関わるバグは委託側で集中して確認する。
分析対象データの項目 分析の結果
出典: 森崎 修司, 松本 健一, “業務観点でのレビューを目指した不具合情報の分析”, 情報処理学会研究報告 ソフトウェア工学研究会,
vol. 2013-SE-179(35), pp. 1-8(2013) 情報処理学会山下記念研究賞受賞 http://se-naist.jp/pman3/pman3.cgi?DOWNLOAD=506

16. 事例3: 設計モデルのメトリクスを収集
• 対象: 車両制御用Simulinkモデル
• 計測: モデルのメトリクス
• 目的: ソースコードメトリクスと同様の傾向があるかを確かめる。
– ソースコードメトリクスからバグが混入しやすい部分を特定できることは実証されてい
る。
16
ソフトウェア開発 データ／モデル化
a. 適切かどうかわからない
b. 参考になる分析方法はある
が確証はない
c. 結果が正確ならば
合意できる

17. まとめ
• 開発と運用の境界線の希薄化
• サイバーフィジカルシステムズとの比較
• 計測とアナリティクスの3原則
• 事例
– ソースコード規模遷移
– バグ修正コストの分析によるレビューの重点化
– 設計モデルのメトリクスによる欠陥予測
• 首都圏、東海、関西で共同研究（有償）していますので、ご興味のある方は名刺
交換お願いします。
17