Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 48 Ad
Advertisement

More Related Content

More from E2D3.org (20)

Recently uploaded (20)

Advertisement

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

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

×