OSS製品における品質管理について

OSS製品における
品質管理について
― IT21の会２月例会サブテーマ ―
発表者綿貫順一（情報工学部門）
2017年2月10日（於、日本技術士会会議室葺手第２ビル）

目次
１．自己紹介
２．OSS利用における不安
３．OSSの開発の流れ
４．OSSとして開発している可視化ツール
『Ｅ２Ｄ３』で発生した品質上の課題
５．『Ｅ２Ｄ３』での品質強化活動
６．今後の展望
７．補足資料

１．自己紹介
• 氏名綿貫順一（わたぬきじゅんいち）
• 登録部門情報工学部門（情報ネットワーク）
• 趣味トライアスロン
• 最近の活動可視化ツール『Ｅ２Ｄ３』のコミッター

事例に用いるＯＳＳ E2D3 とは？？
• E2D3の名前は、Excel to D3.js の頭文字に由来。
• 表計算ソフトExcelのシート情報に対し、可視化ライブラリ
「D3.js」の機能を適用することで、データドリブン設計のビ
ジュアライゼーションを実現するツール。
• エンジニアでないと作成が難しい「D3.jsでのビジュアラ
イゼーション」を、プログラマでない方にも簡単に実現で
きることが特徴。
実際のExcelに、E2D3 を適用すると、
デモ用のページは、
http://a.e2d3.org/

① A列～D列のデータを選択し、
② データ範囲指定することで、
③プログラムコードを書かずにデータをアニメ表示できる。

２．ＯＳＳ利用における不安
• 様々な製品にＯＳＳが使われていて、個人レベルでも
無意識に使っている。
• 安心して使ったが、思わぬバグでトラブルを経験したり、
性能発揮できず活用できなかったなど、負の経験も。
気づかぬところで
ＯＳＳライブラリー
が多用されている。

個人利用でのトラブルは、自分自身で
責任を負うという点で、今回は割愛。
業務などでトラブルが発生した場合
→ 賠償問題にもなりかねない
会
社
で
は
ＯＳＳを利用する
立場などにより、
身構えておく必要
がある

ＯＳＳの利用により効率よくプロジェク
トを進めていくには、利便性の影に潜
んでいる罠に陥らないよう、注意する
ことが重要。
簡単に改造できる
簡単に入手できる
簡単に組み込むこ
とができる
OSSを、使う＆作るを経験した意見として、

利用者としての想い
『ＯＳＳプロダクトを安心して使いたい』
開発者としての願い
『ＯＳＳプロダクトを活用してもらいたい』
ギ
ャ
ッ
プ
ギャップ解消の事例紹介として、E2D3で
の品質強化活動事例を報告する

３．OSSの開発の流れ
ＯＳＳコミュニティ等が実現したい目標を定める
各コミッターが開発を進め、マスターコードに投稿
レビュアー等が、投稿されたものを試験評価
オーサー等が、マージして製品に取り込む
Ｅ２Ｄ３での実態や、他
のＯＳＳ関係者の情報
から標準的な流れを紹
介
masterブランチと呼びます
一般的な
マージの条件としては、
x件以上のLGTMがある
など、OSSコミュニティ毎
に独自ルールがある

Ｅ２Ｄ３での開発の流れ、
E2D3で実現したいビジュアライゼーションを提案
マージ（時にはセルフマージ）して製品に取り込む
各コミッターが開発を進め、マスターコードに投稿
レビュアー等が、投稿されたものを試験評価
この工程を一人で
実施していた
少ない人数で
効率重視。

４．OSSとして開発している可視化ツール
『Ｅ２Ｄ』で発生した品質上の課題
4/4に総務大臣より、
Ｅ２Ｄ３に賞をあげるの
で、出頭してください
新たな利用者が増えてきた
ときに、品質面でがっかりし
ないよう、チェックをしない
とね。
でも、毎回動作確認して動い
ているから、すぐに終わるよ。
ということで、品質強化目的で試験を実施。

改
善
せ
ね
ば
かるく試験をした結果、多数のバグが続出
ＯＳＳのチームとして、利用者側の立場でソフトウェ
ア試験を行い、品質強化活動を行うことに決定。
ＯＳＳでは、第三者の利用観
点でソフトウェア試験をした事
例が少ないのが実態。（通常
は、開発者側での試験だけで
リリースを行うことが多い）

５．『Ｅ２Ｄ３』での品質強化活動
E2D3は、ボランティア有志の集まりなので、
ソフトウェア試験チームを結成する
ところから開始せねばならない
テストエンジニアに
名乗り出てくれる人を
募ってみることに。

第三者の観点で試験をしたいので、開発に
携わっていない人に対して募ることが重要
①ハッカソンイベントや勉強会参加者など、つなが
りのある方々に対してテストエンジニアを募る
②過去のコミッタに呼びかけ、開発していない機能
に対してテストエンジニアとして協力を持ちかける
③ソフトウェア試験に参加しやすい環境づくり、参
加のメリットを認知してもらい、幅広く技術者を募る
テストエンジニアは23名が集まる

実際の品質強化活動
試験仕様書作成
試験担当者割り当て
試験実施（各担当者）
不具合判定
Ｉｓｓｕｅ発行
試験結果を記録する
試験終了
直せそうな人にメンション
不具合
対応
全数
試験
対象機能をTBD化するＩｓｓｕｅクローズ
不具合
有り
不具合無し
対応完了
対応
不能
全数完了
未実施
有り
実際は試験の数が多すぎて、
試験終了まで至っていない。
TBDは、To Be Developedの略。
対象機能を開発中に仕分けする
Issueは、問題処理チケットのこと

試験仕様書作成
• 試験仕様書を作成に際して、事前調査にて判明した問題点
を整理。
１）64種類ある可視化テンプレートの不具合傾向が一様でない。
２）ユーザ利用環境により、不具合の有無が異なる。
（OS、Excelバージョン、ブラウザのバージョン）
３）開発時には考えていなかった操作方法で不具合が出ることがある
• テストエンジニアを担当するメンバは直接会ったことのない
人も多数。
１）試験仕様書などは、ローコンテクストな表現で記述して、だれが読ん
でも同じ内容として理解可能となるよう心掛ける
２）どうしても使わなければならない方言や専門用語は、着手前に説明
資料を提供する（分野外の人にとっては、表側、表頭、表体、頭注、など
と伝えても混乱を招いてしまう）総務省統計局の統計表のみかたを参考
実際のE2D3の機能を確認して、試験内容を考えてみる。

E2D3をChromeブラウザ
で利用した際のメニュー
可視化テンプレートの
カテゴリ選択エリア
カテゴリーごとに、数種類
から30種類の、さまざまな
可視化テンプレートがある
グラフのサムネイル画像
上のボタンを押下すると
該当の可視化テンプレー
トが展開される。
http://a.e2d3.org/
を開いた状態

可視化結果を、SNS、
メールなどでシェアする
ためのボタン
可視化結果を、画像ファイル
で保存するボタン
E2D3のトップメニューに戻るボタン
ある可視化テンプレート
を選択した状態
基本機能は比較的シンプルだが、

マウスオーバー前
の状態
データドリブン設計なので、
マウスオーバー操作などで
グラフがアニメーションする
アニメーションする結果を、
画像ファイルにしようとしても
大丈夫か？？

入力データとなるExcelシート
で、行の挿入や削除をしても
グラフは最新データに追従
できているか？？
セルの値を途中で変更しても、
データ集計が正しく処理され
るだろうか？？
タイトルを途中で変更しても、
グラフに反映されるだろうか

可視化テンプレートも、さまざま存在する。

動作に影響を及ぼす環境条件も様々。
ＯＳ種類利用ブラウザ Excelバージョン

E2D3がなにかを
知らない人が、
気ままに操作しても、
短期間で実施でき、最低限必要な試験内容を検討
表示が化けたりしない
いわゆる品質要件の検討
フリーズしない
仕様と異なる動作をしない
Excelデータが可視化される
各種ボタンが機能する
初めて使う人が、
がっかりしないことが
当初の目的。

基本機能動作確認したい機能 No 機能確認のためのE2D3での操作と、可視化エリアの状態
Reset Data Areaボタン
提供機能の調査
(E2D3グラフのデータ
更新機能の実装及び
動作不具合に関する、
調査検証)
表体データの更新機能
(表体の最上行＆最左列の値を更新)
1 [Reset Data Area]押下無しでも、可視化エリアが自動的に更新される
2 [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項目）
試験時の環境を記録
試験実施者を割り当てる修正担当者を記録
試験実施結果を記録

不具合発生に対しＩｓｓｕｅ発行
Issueの件名
Issue発行後のやり取り
やり取りの本文中に、半角の@に続けてGitHubのアカウント名を記入すると、
対象ユーザーに通知が届く仕組みがある。（Facebookでメンションするのと同じ要領）

直せそうな人にメンション
①対象ファイルのページに移動し、
例えば、tags.ymlというファイルを修正したいと思ったら、
②まずは一番最後に修正した人にメンションする
③連絡つかない場合は、過去のコントリビュータの誰かにお願いする
④修正箇所が特定できる場合はBlameページで該当者を探す ⑤不具合発生の時期が分かっている場合は、
Historyページから該当者を探す
https://github.com/e2d3/e2d3-contrib/blob/master/tags.yml
を開いた状態

①該当ファイルのソースコードを確認する
Blameページで、修正をお願いする人を探す例
行番号
②修正したい個所を確認する
③修正箇所を投稿した人を特定する
修正箇所を頼りに、修正対象の事情を知っている人をメンションする
https://github.com/e2d3/e2d3-contrib/blame/master/tags.yml
を開いた状態

修正を行った日付を確認する
Historyページで、修正をお願いする人を探す例
このタイミングで修正された内容を確認する
（修正内容が差分表示で確認できる）
修正を行った日付を確認する
履歴情報を頼りに、修正対象の事情を知っている人をメンションする
https://github.com/e2d3/e2d3-contrib/commits/master/tags.yml
を開いた状態

試験結果を記録する
試験環境を記録試験環境の詳細を記録試験実施結果を記録
機能が仕様通りに動作
したら『〇』を記入
機能が仕様通りに動作
しても気になることが
あれば『〇』に加えて
コメントを記入
試験対象外となるものは、
理由とともに除外する
旨を記録する。
不具合が見つかったら、
『×』の記入とともに、
Issue番号を記入する。
修正対応が完了したら
Merge時の番号とともに
結果を記録する。

試験結果の総括
試験消化率＝47％
539件の不具合
試験通過は69件
ワークアラウンドも含め大半は対応を行った
試験期間は4日間
説明文の修正など、
軽微な不具合も計上
している。
試験実施対象は、
可視化テンプレート数と
試験実施項目数を
乗じた数になる。
総数は64×19＝1216件
実際に試験できた件数は
半分にも満たなかったが、
その後の休日などに、少しずつ
皆で対応してきている。
2016/3/28：キックオフ
2016/3/30：試験仕様書作成
2016/3/31：試験開始
2016/4/3 ：試験終了

GitHub－Graph上での修正状況
横方向の線の本数は
並行で修正してる人数
2016/3/31～2016/4/3の期間を表示
https://github.com/e2d3/e2d3-contrib/network
を開いた状態

６．今後の展望
• Excelは長い期間利用されるづけることから、CI/CDの観点での事
例を取り入れていきたい。
• 標準手法（GitHub開発手法）が普及していたおかげで、短期間で
品質強化施策を進めることが可能となった。同様の効果を享受し
ていくためにも、手法の整理、共有を図っていきたい。
• ReadMeファイルやサンプルデータの改善などの品質向上も対象
であった。非プログラマの方へも開発手法を共有することで、事務
系の方の提案などがダイレクトに製品に反映しやすくなるよう、勉
強会などで協力していきたい。
• 試験の妥当性チェックなど、試験実施そのものに対するチェックを
行う時間が少なかったが、今後はＩＶＩＡなどで提唱している『IT検証
標準工法ガイド』などで効率よく効果のある試験を追求していきた
い

【企業人として】
• OSSの利便性を享受していて収益を得ているため、何らかの
還元を行うのは社会的責任に含まれると思う。
• OSSに携わることで習得できる内容は、結果としては技術者自
身が所属している会社へ技術を還元しやすくなると考えられる。
この点からも、社会への貢献はもちろん、個人にも所属会社に
もメリットがあると思う。
• 所属会社の立場や役割とは異なる貢献を行うこととなるので、
会社業務に対して与えられた立場以外の観点で考えるきっか
けができると思う。
OSS案件にかかわっていくことに関する個人の考え

【技術者個人として】
• OSSに携わると、OSS開発者向けのツールなどを無償利用でき
ることが多い。また、企業間のしがらみなども、会社員としての
立場の時よりも少ない。結果として、ツール利用による効率化
などの面でスキルが蓄積しやすくなる。
• さまざまな技術者とダイレクトに交流することとなり、最新の技
術や手法を吸収する機会に恵まれる。
• 他のOSSプロダクトなども含め、自分で使ってみたい機能を実
現できるチャンスが広がる。
OSS案件にかかわっていくことに関する個人の考え

７．補足資料
• E2D3のシステムイメージ
• 試験内容の妥当性判断に参考となる資料
（IT検証標準工法ガイドの表紙部分の紹介）
• GitHubでのIssue一覧の例
• GitHubによるソーシャルコーディングで作成したホームページ

E2D3のシステムイメージ
基盤部分
Excelシートと
可視化領域を
結びつける機能
可視化テンプレート１
可視化テンプレート２
可視化テンプレート３
可視化テンプレート…
可視化テンプレートｎ
Microsoft
Excel
Azure
GitHub
E2D3
基盤部分
GitHub
E2D3
-contrib
基盤部開発者
可視化テンプレート
開発者
プルリクエストプルリクエスト
マージマージ
読込
表
示
利用者
Officeアプリへ
自動デプロイ
今回の品質
強化対象
は、可視化
テンプレート
部分のみ。
依存先である基盤部
への改変を行わない
前提のためデグレ
試験は行わない

IT検証標準工法ガイド（IT検証産業協会）http://www.ivia.or.jp/
より入手ができる

GitHubでのIssue一覧の例 https://github.com/e2d3/e2d3-contrib/issues
を開いた状態

GitHubによるソーシャルコーディングで作成したページ
2017/1/27に、NTTグループ内
のソフトウェア開発者を中心に
した、カンファレンスが開催。
https://ntt-developers.github.io/ntt-tech-conference-01/
参加者がGitHub上で協力し作成した

2017/1/9より作成開始
リポジトリをフォークし、
提案内容を検討する
などの活動
ホームページの骨格が
徐々に作り上げられて
いく過程
自分も参加者なので、投稿を行った。

GitHubのプロジェクト
管理ツールで当時を
振り返ると、、、

自分が投稿したファイル
投稿の意図を
伝達する

自動ツールで生成された
プレビュー画像が共有
最終案にLGTMされ
たことを受けて、
本体へマージされる
良い代替案を持つ人から、
提案＆修正を頂く。

結果としてできた、展示内容の紹介ページ
GitHub開発という手法を
参加者の大半が習熟して
いた。
そのおかげで、組織を越えた
仲間と共同作業が成功。
https://ntt-developers.github.io/ntt-tech-conference-01/
を開いた状態

ご清聴ありがとうございました

OSS製品における品質管理について

OSS製品における品質管理について

Recommended

More Related Content

What's hot

What's hot(20)

Similar to OSS製品における品質管理について

Similar to OSS製品における品質管理について(20)

More from Junichi Watanuki

More from Junichi Watanuki(6)

OSS製品における品質管理について