「OSSの品質管理」に対する市民共創方法
データ可視化プラットホームE2D3の事例紹介
人工知能学会 合同研究会2019
2019年11月23日
代表 五十嵐康伸
博士(理学)
著者 31名
五十嵐 康伸、一円 真治、江畑 彩、大曽根 圭輔
小副川 健、小野 恵子、河野 麻衣子、佐藤 奈津紀
澤 徳彦、篠原 剛、清水正行、鈴木 典子
竹内 秀行、都築 祐善、長久 武、西野 貴志
林 美帆、林 由佳、久住 裕司、平河 広輝
槙田 直木、松崎 剛、蓑田 恭秀、宮内 元
村上 康雄、村瀬 真琴、八木 啓、山田 祐資
山本 智、山本 優、綿貫 順一
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
背景
• シビックテック等、研究者と市民、もしくは異なる
組織に所属する市民が共創して研究する過程は、
新しい研究手法として注目 [1][2]
先行研究
• 市民がハッカソンで創出したアイデア・プロトタイ
プを元に、企業がスマートフォンのアプリケーショ
ンとしてリリースする過程 [3]
• 市民がハッカソンで創出した作品を素材にして、
その後のハッカソンにおいて、先とは別の市民が
作品を創出する過程 [4]
本研究
• E2D3(Excel to D3.js)というオープンソースソフトウ
ェア(OSS)のデータ可視化プラットホーム上にある
データ可視化テンプレート群に対して、市民が品
質管理を共創する過程について報告[5, 6]
条件A
1. E2D3メンバー同士には会ったことがない人の対が
存在
2. 組織から各メンバーに給与は支払われない。
各メンバーは自発的動機により、ボランティアとして
参加
3. 日本国内では北海道から九州まで、
また海外も含めて様々な場所に住んでいるため
オンライン上のコミュニケーションがメイン
条件B
• 2016年3月28日に告知
• 2016年4月4日に行われる「統計データ利活用ア
プリケーション・アイデアコンテスト:STAT DASH グ
ランプリ 2016」の授賞式においてE2D3が総務大
臣賞を受賞 [7]
• 告知(3/28)から受賞(4/4)の翌日までの9日間、
という短い期間で品質管理のプロジェクトを立ち
上げて、終了
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
Data Viz、データ視覚化
X =
https://d3js.org/ http://e2d3.org/
① A列~D列のデータを選択し、
② データ範囲指定することで、
③プログラムコードを書かずにデータをアニメ表示できる。
可視化テンプレートの
カテゴリ選択エリア
カテゴリーごとに、数種類から30種
類の、さまざまな可視化テンプレー
トがある
可視化テンプレートのサムネイ
ル画像上のボタンを押下すると
該当の可視化テンプレートが展
開される。
グラフを、SNS・メールなどでシ
ェアするためのボタン
グラフを、画像ファイルで保存するボ
タン
E2D3のトップメニューに戻るボタン
ある可視化テンプレート
を選択した状態
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
実際の品質強化活動
テスト仕様書作成
テスト担当者割り当て
テスト実施(各担当者)
不具合判定
Issue発行
テスト結果を記録する
テスト終了
直せそうな人にメンション
不具合
対応
テスト期間判定
対象機能をTBD化するIssueクローズ
不具合有り
不具合無し
対応完了
対応不能
全数完了
未実施
有り
テストの数が多すぎて
全数テストはまで至っていない。
TBDは、To Be Developedの略。
対象機能を開発中に仕分けする
Issueは、問題処理チケットのこと
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
不具合発生に対しIssue発行
Issueの件名
Issue発行後のやり取り
やり取りの本文中に、半角の@に続けてGitHubのアカウント名を記入すると、
対象ユーザーに通知が届く仕組みがある。(Facebookでメンションするのと同じ要領)
直せそうな人にメンション
①対象ファイルのページに移動し、
例えば、tags.ymlというファイルを修正したいと思ったら、
②最後に修正した人にメンションする
③連絡つかない場合は、過去のコントリビューターの誰かにお願いする
④修正箇所が特定できる場合は
Blameページで該当者を探す
⑤不具合発生の時期が分かっている場合は、
Historyページから該当者を探す
①該当ファイルのソースコードを確認する
Blameページで、修正をお願いする人を探す例
行番号
②修正したい個所を確認する
③修正箇所を投稿した人を特定する
修正箇所を頼りに、修正対象の事情を知っている人をメンションする
修正を行った日付を確認する
Historyページで、修正をお願いする人を探す例
このタイミングで修正された内容を確認する
(修正内容が差分表示で確認できる)
修正を行った日付を確認する
履歴情報を頼りに、修正対象の事情を知っている人をメンションする
GitHub-Graph上での修正状況
横方向の線の本数は
並行で修正してる人数
2016/3/31~2016/4/5の期間を表示
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
JIS X 0129-1の定義に準拠
• ソフトウェアの主特性 6:機能性・信頼性・使用性・効率性・保守
性・移植性信頼性の副特性 3:成熟性・障害許容性・回復性
• 移植性の副特性 4:環境適応性・設置容易性・共存性・置換性
• テストフェーズ 3:システムテスト・結合テスト・単体テスト
• テスト実施者(テスター)の想定 2:ホワイトボックステスト・ブラッ
クボックステスト
• テスト技法 2 動的テスト・静的テスト
• テスト終了条件:テスト期間の終了
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
E2D3がなにかを
知らない人が
気ままに操作しても
短期間で実施でき、最低限必要な試験内容を検討
表示が化けたりしない
フリーズしない
仕様と異なる動作をしない
Excelデータが可視化される
各種ボタンが機能する
初めて使う人が、
がっかりしない
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
工数
• 期間は2016年3月28日から4月5日の9日間
• 2016/3/28にE2D3.org ver. 0.7 のFB Group内
(49人)で品質管理チームを新設を提案
• 過去のハッカソン参加者・勉強会参加者・過去の
コミッタなど、つながりのある方々に対して協力を
呼びかけ
• その結果、22人が本品質管理PJに協力
役割(兼任を含む)
• プロジェクトマネージャー:1人
• テスト責任者兼マージャー 1人
• テスター:17人
• コミッター:15人
コミュニケションツール
• 協力者募集時:Facebook
• 品質管理の実働時:Github・Slack・Google Drive
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
• 3/28:テスト仕様書作成を開始
• 3/30:テスト仕様書を完成
• 3/31:テストを開始。同時にIssue発行、デバッグと
Pull Reqを開始
• 4/4 :テストを終了。同時に、Issue発行を終え、授
賞式
• 4/5 :デバッグとPull Reqを終了
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
可視化テンプレートは様々
動作に影響を及ぼす環境条件も様々
OS種類 利用ブラウザ Excelバージョン
条件に対する工夫
• テストエンジニアを担当するメンバは直接会
ったことのない人も多数。
1)試験仕様書などは、ローコンテクストな表現で記述
して、だれが読んでも同じ内容として理解可能となる
よう心掛ける
2)どうしても使わなければならない専門用語は、着手
前に説明資料を提供する(分野外の人にとっては、表
側、表頭、表体、頭注、などと伝えても混乱を招いてし
まう)
総務省統計局の統計表のみかたを参考
実際のE2D3の機能を確認して、試験内容を考えてみる。
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
基本機能 動作確認したい機能 No 機能確認のためのE2D3での操作と、可視化エリアの状態
Reset Data Areaボタン
提供機能の調査
(E2D3グラフのデータ
更新機能の実装及び
動作不具合に関する、
調査検証)
表体データの更新機能
(表体の最上行&最左列の値を更新)
1 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
2 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
表頭データの更新機能
(表頭の最左列の値を更新)
3 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
4 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
表側データの更新機能
(表側の最上行の値を更新)
5 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
6 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
表体&表側データの同時挿入対応
(表体&表側部分の最上行に、行データを挿入)
7 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
8 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
表体&表側データの同時削除対応
(表体&表側の最上行で、行データを削除)
9 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
10 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
表体&表頭データの同時挿入対応
(表体&表頭の最左列に列データを挿入)
11 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
12 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
表体&表頭データの同時削除対応
(表体&表頭の最左列で列データを削除)
13 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
14 [Reset Data Area]押下有りの操作の結果、可視化エリアが更新される
グラフ描画エリア機能 データ内容や描画機能が、維持されること 15 グラフ拡大縮小で、値や描画に本質的変化を誘発しない
ShareChartボタン機能 グラフ共有機能が機能すること 16
Share URLをブラウザにコピペ&Enterすることで、作成したグラフと同
じものが表示できる
Save Imgボタン機能 画像生成機能が機能すること
17
[Save img]→[ Save SVG]
→ DLファイルをダブルククリックで、作成したグラフと同じものが表示
18
[Save img] → [Save PNG]
→ DLファイルをダブルククリックで、作成したグラフと同じものが表示
Homeボタン機能 メニュー切り替え機能 19 [Home] ボタンを押下することでメインメニュー画面に遷移できること
試験内容を整理
可視化テンプレートを列挙
(合計64種類)
テスト項目を列挙
(合計19項目)
テスト環境を記録
テスターを割り当てる 修正担当者を記録
テスト環境実施結果を記録
試験仕様書を作成
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
試験結果を記録
テスト環境を記録 テスト環境の詳細を記録 テスト実施結果を記録
機能が仕様通りに動作
したら『〇』を記入
機能が仕様通りに動作
しても気になることが
あれば『〇』に加えて
コメントを記入
テスト対象外となるものは、
理由とともに除外する
旨を記録する。
不具合が見つかったら、
『×』の記入とともに、
Issue番号を記入する。
修正対応が完了したら
Merge時の番号とともに
結果を記録する。
各記号の意味
〇:合格
△:不具合報告(Issue対応済み)
▲:完璧ではないが修正した
●:最後まで直した
×:不合格(そのまま残っているのは、修正未対応)
テスト結果のラベル
1. テスト合格:テスト実施時期の条件で合格したもの。(条件付き合格も含んで
いる)
2. スコープ外:①可視化テンプレートに無い機能に対するテストであるためテスト
対象外。②元のデータ形式特性のため、テストができないため、テストのスコ
ープ外としたもの。
3. テスト省略:セルの値変更によりグラフが自動で変更されるグラフは、
「ResetDataArea」ボタンのテストを省略できるため、テストを省略したもの。
4. 運用対処:Readme.mdに利用上の制約事項を記載することで、課題解決した
もの。機能を無効化することで対応したもの。
5. 修正未達:デバッグに着手したが、期間内では修正が間に合わなかったもの。
(期間後に修正完了したものも含む)
6. 修正完了:テスト結果が不合格であったものを、期間内に修正したもの。
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
テスト結果
運用対処 20
テスト判定不能
1
修正完了 3
修正未達 5
スコープ外 87
テスト合格 349
テスト省略 22
不合格(未対応) 62
未実施 663
未実施(テスト方法
不明)
4
概要項目
総テスト数 可視化テンプレート 64種類
x テスト項目 19項目
=1216項目
テストした可視化テンプレート 32種類/64種類=50%
テスト消化率 549項目/1216項目=45.1%
テンプレート改善結果
テスト期間中に出された(以
下、同条件)Issue
4件
出されたPull Req 18件
ClosedのIssue 2件
Closed Pull Req 18件
Open(In progress)なIssue 2件
Open(In progress)なPull Req 0件
内容
1 はじめに
2 材料と方法
2-1 材料
2-2 品質管理方法の全体像
2-3 Issueの発行方法、直せ
そうな人を探す方法、メンシ
ョンする方法、修正状況の
確認方法
2-4 テスト仕様書の作成方
法
2-5 品質管理の目標
3 結果
3-1 集められたリソース
3-2 スケジュール
3-3 テスト仕様書の作成手
順
3-4 作成したテスト仕様書
3-5 記録されたテスト仕様書
3-6 テストの結果
4 今後の課題
• 今回は、E2D3はプラットホームとしての本体と、そ
の上でモジュール型開発されているグラフ可視化
テンプレートに対して品質管理を行った。
• Cytoscape等、E2D3と同様のモジュール型開発の
OSSの品質管理方法を調べることで有益な知識
が発見できる可能性がある[10]。
1. Ajail型の品質管理手法体系と本論文の内容を比較
2. CI/CD(継続的インテグレーション・継続的デリバリ
ー)における品質管理を高めるツールとしてCircle
CI・Github Actionsを取り入れたい
3. コミッターから送られてきたPull Reqに対してnode.js
で毎回自動テスト
4. Git flow、GitHub flowでGitのbranch管理にルール付
け
「OSSの品質管理」に対する市民共創方法
データ可視化プラットホームE2D3の事例紹介
人工知能学会 合同研究会2019
2019年11月23日
代表 五十嵐康伸
博士(理学)
ご清聴、ありがとうございました

「OSSの品質管理」に対する市民共創方法