ソフトウェア・シンポジウム 2017 in 宮崎
論文集

ソフトウェア・シンポジウムは，ソフトウェア技術に関わるさまざまな人びと，技術者，研究者，教育者，学生などが一堂に集い，発表や議論を通じて互いの経験や成果を共有することを目的に，毎年全国各地で開催しています．
第 37 回目を迎える 2017 年のソフトウェア・シンポジウムでは，この数年間で試みてきた新しい取り組み（チュートリアルや Future Presentation※ など）をさらに発展させたものにしたいと考えています．このほか，SS2016 に引き続き，論文発表や事例報告と，ワーキンググループで議論を行います．
今回は，“開かれたソフトウェア開発”をテーマに，さまざまな観点からの発表や講演を行います．ソフトウェア開発について，これまでの延長ではない捉え方をしていただ
く機会として，是非会場に足を運んでいただき，情報交換と深い議論をする場として活用してください！
ソフトウェア技術に関連するさまざまな分野の皆さまからの投稿をお待ちします．参加者の発表にはさまざまな形式があります．研究論文，Future Presentation，経験論文，
事例報告です．また，ワーキンググループでの深い議論も予定していますので，ご提案いただきますよう，よろしくお願いします．
※ ソフトウェア開発技術の進化に直接的，間接的に役立つと思われる，「先進的なアイデア」や「さまざまな技術や経験を融合した提案」などを議論するセッション．

II

開催概要

■ 日程 ： 2017 年 6 月 7 日 (水曜日) ～ 9 日 (金曜日)■ 場所 (本会議) ： 宮崎市民プラザ■ 主催 ： ソフトウェア技術者協会■ 後援 ： 情報処理推進機構■ 協賛 ： 宮崎県情報産業協会，ソフトウェアテスト技術振興協会，IT 記者会，
アジャイルプロセス協議会、オープンソースソフトウェア協会，
情報サービス産業協会，情報処理学会，電子情報通信学会，
ソフトウェア・メインテナンス研究会，日本ファンクションポイントユーザ会，
日本ソフトウェア科学会，組込みシステム技術協会，PMI 日本支部，
日本 SPI コンソーシアム，派生開発推進協議会，日本科学技術連盟，
組込みソフトウェア管理者・技術者育成研究会，TOPPERS プロジェクト，
アドバンスト・ビジネス創造協会

IIIスタッフ一覧
実行委員会

プログラム委員会

実行委員長

プログラム委員長

荒木 啓二郎 (九州大学)

片山 徹郎 (宮崎大学)

小笠原 秀人(東芝)栗田 太郎 (ソニー)

実行委員

プログラム委員

伊藤 昌夫 (ニルソフトウェア)

秋山 浩一 (富士ゼロックス)

片山 徹郎 (宮崎大学)

鯵坂 恒夫 (和歌山大学)

岸田 孝一 (SRA)

安達 賢二 (HBA)

栗田 太郎 (ソニー)天嵜 聡介 (岡山県立大学)

小松 久美子 (帝塚山学院大学)

伊藤 昌夫 (ニルソフトウェア)

杉田 義明 (福善上海)

岩崎 孝司 (富士通九州ネットワークテクノロジーズ)

鈴木 裕信 (鈴木裕信事務所)

植月 啓治 (パナソニック)

萩原 美穂 (アートシステム)臼杵 誠 (富士通)中野 秀男 (帝塚山学院大学)

大平 雅雄 (和歌山大学)

奈良 隆正 (NARA コンサルティング)

落水 浩一郎 (University of Information Technology,

野村 行憲 (アイシーエス)

Myanmar，金沢工業大学)

宮田 一平 (SHIFT)

小田 朋宏 (SRA)

三輪 東 (SCSK)

片山 徹郎 (宮崎大学)
神谷 年洋 (島根大学)
北須賀 輝明 (広島大学)
日下部 茂 (長崎県立大学)
楠本 真二 (大阪大学)
河野 哲也 (日立製作所)
後藤 徳彦 (NEC ソリューションイノベータ)
古畑 慶次 (デンソー技研センター)
阪井 誠 (SRA)
酒匂 寛 (デザイナーズデン)
佐原 伸 (法政大学)
小林 修 (SRA)
鈴木 裕信 (鈴木裕信事務所)
鈴木 正人 (北陸先端科学技術大学院大学)
高木 智彦 (香川大学)
田中 康 (奈良先端科学技術大学院大学)
張 漢明 (南山大学)
IV角田 雅照 (近畿大学)
土肥 正 (広島大学)
富松 篤典 (電盛社)
中谷 多哉子 (放送大学)
中森 博晃 (パナソニック スマートファクトリー
ソリューションズ)西 康晴 (電気通信大学)
野村 行憲 (アイシーエス)
野呂 昌満 (南山大学)
端山 毅 (NTT データユニバーシティ)
本多 慶匡 (東京エレクトロン)
松尾谷 徹 (デバッグ工学研究所)
松本 健一 (奈良先端科学技術大学院大学)
水野 修 (京都工芸繊維大学)
宮本 祐子 (宇宙航空研究開発機構)
宗平 順己 (Kyoto ビジネスデザインラボ合同会社)
森崎 修司 (名古屋大学)
諸岡 隆司 (中電シーティーアイ)八木 将計 (日立製作所)
山本 修一郎 (名古屋大学)
米島 博司 (パフォーマンス・インプルーブメント・
アソシエイツ)劉 少英 (法政大学)

V

ソフトウェア・シンポジウム 2017 in 宮崎 目次■論文・報告 テストとデバック[研究論文] 変更における状態を含むテスト網羅尺度とテストケース抽出法の提案
湯本剛（筑波大学大学院），松尾谷徹（デバッグ工学研究所），
津田和彦（筑波大学）………………

1[事例報告] 探索的テストにおける不具合発見率向上に向けた取り組み
中野直樹 （LIFULL）………………

11[研究論文] VDM++仕様を対象にしたテストケース自動生成ツール BWDM におけるif 式の構造認識に基づいたテストケース生成手法の提案
立山博基（宮崎大学大学院工学研究科），片山徹郎（宮崎大学工学教育研究部）………………

13[経験露文] 段階的なシステムテストによる IoT システム開発効率化
西村治（パナソニック）………………

22[研究論文] 例外処理を含む Java プログラムを対象としたデータ遷移可視化ツール
TFVIS の適用範囲の拡大
佐藤拓弥（宮崎大学大学院工学研究科），片山徹郎（宮崎大学工学教育研究部），
水久保直哉，田中伸英（スカイコム）………………

28■論文・報告 コード解析[研究論文] Data Race Detection Based on Dependence Analysis
Guanqun Wang，Masahiro Matsubara (Hitachi Automotive Systems, Ltd.)………………

36[研究論文] N-gram IDF を利用したソースコード内の特徴的部分抽出手法
小林勇揮（京都工芸繊維大学大学院工芸科学研究科情報工学専攻），
水野修（京都工芸繊維大学情報工学・人間科学系）

VI………………

46

[研究論文]ソースコードの品質向上を目的とした特定のコメントを検出するツールの試作
田上諭（宮崎大学工学研究科），甲斐秀一（スカイコム），
片山徹郎（宮崎大学工学教育研究部）………………

56[事例報告]ソースコードの品質向上を目的とした特定のコメントを検出するツールの試作
甲斐秀一（スカイコム），田上諭（宮崎大学工学研究科），
片山徹郎（宮崎大学工学教育研究部）………………

65■論文・報告 保守，OSS[事例報告] 「あるある診断ツール」による課題の可視化と収集データの分析事例
室谷隆（TIS）………………

66[経験論文] パッケージ製品におけるソフトウェア保守情報の活用事例
加藤英之（東芝ソリューション），増井和也（ソフトウェア・メインテナンス研究会）………………

67[事例報告] 保守と保守開発における Software Evolution の事例報告
三輪東（SCSK）………………

74[研究論文] OSS 開発者の離脱要因理解のための Politeness の質的調査
宮崎智己，大平雅雄（和歌山大学システム工学部）………………

75[経験論文] OSS 事前評価による開発リスク特定の取組み
岩崎孝司，高山修一，岩永裕史（富士通九州ネットワークテクノロジーズ），
鵜林尚靖，亀井靖高（九州大学）………………

85■論文・報告 マネジメントとチーム[研究論文] 開発者の所属企業規模を考慮したソフトウェア工学の有用性評価
村上優佳紗，角田雅照（近畿大学大学院総合理工学研究科）………………

VII95[経験論文] 自分事化影響要因に着目した中期経営計画立案・展開への共創アプローチ[現状分析～計画立案編]
安達賢二（HBA）………………

103[経験露文] 製品開発における OSS 導入のための OSS 事前評価手法確立に向けた調査
日下部茂，片平梓，青木研（長崎県立大学）………………

111………………

119[事例報告] 勉強会を活用した組織成長モデル～機能期のチームが継続的に成長するために～伊藤修司，山口真，豊田圭一郎（SCSK）■論文・報告 要求・安全・品質・メトリクス[研究論文] コードクローン変更過程における開発者のインタラクションとソフトウェア品質の関係
久木田雄亮（和歌山大学大学院システム工学研究科），
大平雅雄（和歌山大学システム工学部）………………

120[経験論文] Convolutional Neural Network を用いたフォールト数予測手法
小川直記，坂井伸圭，横内弘（日立製作所）………………

130[事例報告] 事例報告：AADL を用いた STAMP/STPA 支援岡本圭史，力武克彰（仙台高等専門学校），
大友楓雅（仙台高等専門学校情報電子システム工学専攻）………………

138[研究論文] ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察‐酒屋倉庫問題の場合‐
岡野道太郎（筑波大学大学院ビジネス科学研究科），
中谷多哉子（放送大学情報コース）………………

139[研究論文] 要件定義書からのファンクションポイント自動計測の試み
山田涼太，山田悠斗，楠本真二，柗本真佑，
肥後芳樹（大阪大学大学院情報科学研究科）

VIII………………

149

■論文・報告 形式手法、プロセス改善[研究論文] ソフトウェア開発発注者育成のための形式手法を取り入れたプログラミング教育
伊藤栄一郎（山梨学院大学），小田朋宏（SRA），荒木啓二郎（九州大学）………………

159………………

166[研究論文] 「VDM++仕様記述と分析」の定石と手筋
佐原伸（法政大学情報科学研究科）[経験論文] 日立グループにおける働き方改革の「カタ」～マルチタスクに注目した設計・開発の改善プログラム～
八木将計（社日立製作所），西原隆，真道久英，
村上悟（ゴール・システム・コンサルティング），渡辺薫（日立製作所）………………

176[経験論文] Visual 開発ツール Node-RED の導入によるプロセスの変化と考慮点
阪井誠（SRA）………………

184………………

191■論文・報告 Future Presentation[Future Presentation]
テストの遊び場を作ったら、一緒に遊びますか？
浅井真樹子（ワークスアプリケーションズ）[Future Presentation]
エンジニア人材を死滅させるマイクロマネジメントの打破～エンジニアを活かし育てるトリセツ活動の提案～
松尾谷徹（デバッグ工学研究所）………………

IX

193

■論文・報告 WG にて発表
WG2「テストプロセス改善モデルを理解する」にて発表[事例報告] TPI NEXT による現場主導のテストプロセス改善を支援するための手法の提案
高野愛美，河野哲也（日立製作所），山﨑崇（ベリサーブ），佐藤徳尚（日本ナレッジ）………………

197

WG7「エンジニアリングのトリセツ」にて発表[Future Presentation]
道徳性向上後の行動におけるアラートシステム
阿部敬一郎（東筑紫短期大学），中谷多哉子（放送大学大学院）………………

198[事例報告] ソフトウェア保守 隠蔽の構造 ～なぜ，保守作業は隠されてきたのか？～
増井和也（ソフトウェア・メインテナス研究会）………………

200■ソフトウェア・シンポジウム 2017 パンフレット………………

201■ソフトウェア・シンポジウム 2017 ポスター………………

205

Xソフトウェア・シンポジウム2017 in 宮崎

変更における状態を含むテスト網羅尺度とテストケース抽出法の提案
湯本剛
筑波大学大学院
tsuyoshi.yumoto@gmail.com

松尾谷徹
デバッグ工学研究所
matsuodani@debugeng.com

津田和彦
筑波大学
tsuda@gssm.otsuka.tsukuba.ac.jp

要旨

は，時代と共に課題を難しくしている．ソフトウェアの多様化と複雑化，再利用範囲の増大などから変更波及のソフトウェアの一部に変更を加えた場合，その変更の範囲が拡大し，かつ安易な変更による弊害など課題が山波及を探る変更波及解析（Change Impact Analysis）は積している．これらの課題に対してソフトウェア工学は実務上の大きな課題である．産業界において，変更にか十分な解を提供できていない状況にある [2]．

かる活動は新規開発よりも大きな割合を占めている．ソ

本論文では，状態遷移を持つソフトウェアにおいて，

フトウェアの多様化，複雑化，再利用範囲の増大などか変更波及がデータベースや外部変数などの保持データ

ら変更波及の範囲が拡大し，かつ安易な変更による弊害

を介して生ずる場合のテストについて考える．課題の一など課題が山積している．本論文では，変更波及のうち，つは，網羅基準である. データフローテストの全使用法

状態遷移を持つソフトウェアにおいて，変更波及がデー（AU 法）[3] を基にして, 変更波及のテスト網羅基準をタベースや外部変数などの保持データを介して生ずる場

波及全使用法（IDAU:Impact Data All Used）として提合のテストについて取り上げ，テスト網羅基準とテスト

案する．もう一つの課題は，IDAU 法を満たす具体的な設計手法を提案する．具体的な例を使って手法の適用可

変更波及のテストケースの抽出方法である. 変更波及の能性を確認し，テストケースの数を他の手法と比較し合テストの設計手法として, 順序組合せテストを提案する．

理的であることを示す．

最後に，ここで提案する IDAU 法のコストの評価、すな
わちテストケースの数を従来技法である状態遷移テストの S1 網羅基準と比較をして考察を行い, 提案する方法が

1. はじめに合理的であることを示す．

ソフトウェアの一部に変更を加えた場合，その変更の

2. 変更波及とその解析波及を探る変更波及解析（Change Impact Analysis）は，
実務上の大きな課題である．産業界において変更にかか

本節では，提案する網羅基準やテスト設計手法の前提る活動は，新規開発よりも大きな割合を占めている．ゼとなる，システムの構成と変更について定義し，変更波

ロから新規にソフトウェアを開発するケースは稀であり，及テストの課題について詳細を示す．

何らかの流用を基に変更を加える開発が主流となっている．開発方法においてもアジャイルが主流となり，変更

2.1. 対象とするアプリケーションの構成の積み重ねによって開発が行われている．
しかし，変更波及を合理的に制御する技術は，ソフト

一般的にソフトウェアは，入力 In に対して，何らか

ウェア工学とって未完成の分野である [1]．変更の背景の出力 Out を返す．ソフトウェアの機能は，何らかの入

1

SEAソフトウェア・シンポジウム2017 in 宮崎

ひとつの変更 Q について考える．変更 Q は，タスク群 T a のあるタスク T ai に対して行われたとする．変更

Q は，コードの削除や追加を含み，その結果 T ai の版
R が R + 1 に変更される．この変更の結果を T aR
i から
T aR+1とする．
i
変更 Q の波及には，３つのケースが考えられる．

1. 変更波及が無い場合．
2. 変更波及が他のタスクへ波及しない場合．
図 1: アプリケーションソフトウェアの構成

3. 変更波及が他のタスクへ波及する場合．
3. の変更波及は，タスク間の参照が図 2 に示すように力を出力に変換する処理により実現されていると考えら状態と保持データに限られるならば，該当する状態や保れる．この処理を本論文ではタスクと呼ぶ．タスクは，持データの参照を介した範囲が限られると考えられる．

該当のテストレベルからみた入力を出力に変換している

本論文では，この考え方から波及を受けるタスクを特定

１つの処理である．そのため，タスクの粒度は，テスト

し，その合理的なテスト設計について論じる．

レベルによって決まる．ソフトウェアの構成要素である

変更波及，あるいはその解析に関する研究は古くから

タスク T a の出力について考えると，T a への入力 In だ

行われている．プロダクトラインや UML 図面群を基にけでなく状態 St と保持データ（データベースや内部メ

依存関係生成モデルを用いて波及解析を行う研究がある

モリに保存されているデータ）Ds の影響を受けると考[4, 5, 6]．タスク内のデータフローを基に変更波及を詳えられる．例えば，Web アプリケーションにて予約を行細に解析した研究がある [7]．データベースなど保有デー

うタスクについて考えると，予約が可能か否かを示す状

タを基に変更波及解析を行う研究も行われている [8, 9]．

態と，予約オブジェクトの予約状況を示す保持データに一方，状態と状態遷移はマルコフ過程として実装されてよって，予約の成否が決まる．

いるので，過去の状態が未来の状態に影響しない．状態

本論文では，対象として図 1 に示すような状態と保持遷移に関する波及解析の研究は見当たらないのはそのた

データを持つアプリケーションソフトウェア (AS) につめだと推測する．

いて考える．AS の構成要素は，タスク群 T a と状態 Stと保持データ Ds とし，各タスクは外部の源泉 So から

2.3. 状態と変更波及のテストの入力 In と So への出力 Out があるとする．タスク群

T a は，その要素を T a = {T a1 , T a2 , · · · , T ai , · · · , T at }とし，変更タスクを T ai とする. 対応する入出力は Ini

変更波及は，保持データを介して変更タスクから他のタスクへ伝達する．状態や状態遷移自身は変更波及に関と Outi とする．

2.2. 変更と変更波及
AS に対して，何らかの変更を加える場合について考える．変更には，なんらかの意図がある．AS が持つ機能の変更であったり，不具合に対する変更や，性能や保守性の改善のためのリファクタリングであったりする．
本論文では，変更の意図については取り扱わず，AS の構成要素（タスク，状態，保持データ）に対する具体的な変更について考える．ただし，テスト実行をするためには，タスクを動かすことが必須となる．そのため，以
図 2: 変更タスクと変更波及降の議論はタスクに焦点を絞る．

2

SEAソフトウェア・シンポジウム2017 in 宮崎

与しないが，変更波及のテストにおいて与えるデータのントを最低限１つを含むテストケース」と定義されてい順序において状態を考慮する必要が生じる．状態 St にる [3]．この定義を変更タスクと波及タスクとの関係において, 考慮する必要がある状態を Stl とする (図 2).

置き換え「変更タスクにおいてデータの生成および更新

保持データの構成について考える．その要素を Ds ={Ds1 , Ds2 , · · · , Dsj , · · · , Dst } とし，変更波及を受けるがあるデータを使用するすべてのタスク（波及タスク）

保持データの要素を Dsj とする．保持データに対する操わらず最低限１つ含むテストケース」とし，波及全使用

作は，データのライフサイクルである「C：生成」「R：法（IDAU:Impact Data All Used）とする．

を２つのタスクを実行するまでに経由するルートにかか参照」「U：更新」「D：削除」を記した CRUD 図で定義

3. 順序組合せによるテストケース抽出法

する．Dsj を介して変更波及が生ずるのは，変更タスク

T ai において「C：生成」あるいは「U:更新」が行われ，他のタスクでその保持データを利用した場合である．こ

本節では，図２で示した変更タスクと波及タスクの組

れらのタスクを波及タスクと呼ぶ．

合せを抽出する手法として順序組合せテストを提案する．

保持データのライフサイクル上の「C：生成」「R：参

この手法で抽出するテストケースには，必ず変更タスク

照」「U：更新」「D：削除」などの操作は，無条件に行われを実行した後に波及タスクを実行する，といったようにるのではなく，操作するタスクの制御フローに沿って行

組み合わせるタスクに実行順序があるため，順序組合せ

われる．制御フローは，図 2 に示すとおり, ２階層としてと命名した．

捉えることができる．上位の制御フローはタスクの実行

3.1. 提案手法に必要となる入力情報

順序により決定する大きな制御の流れに相当する．個々のタスク内の制御フローが下位にあたる．個々のデータ
参照実行文はその制御フロー上の条件文で実行が決定さ

一般的にテストケース抽出のために必要な入力情報をれる．条件にはタスクへの入力，保持データ，状態が含テストベースと呼ぶ [10]．提案手法に必要なテストベー

まれる．

スは DFD，ER 図，CRUD 図である．以下，DFD，ER
図，CRUD 図を簡潔に説明する．

変更波及を確認するには，変更が波及した保持データを参照するデータフローに沿ってテストを設計すること• DFD（データフローダイアグラム）になる．このデータフローを決定するのは，関係するタDFD はシステムにおけるデータの流れを表現した

スクの実行順序とタスク内の制御フローであり，その制

有向グラフであり，要求分析において用いられてい御フローを決定する際に状態が影響する．よって，実際る．DFD はデータ指向設計の要として用いられ，オのテスト実行においては状態を考慮する必要が生ずる．

ブジェクト指向設計においても抽象化する前段階として実践の場で用いられている．

2.4. 変更波及テストの網羅基準
テストにおける網羅基準については，その強度を含め

DFD は，最上位のコンテキストレベルから階層として詳細化され，各階層は１枚以上の DFD から成制御フローとデータフローの観点から研究が行われ体る [11]．テストベースとして用いる場合，テストの系が作られている [3]. 最も弱い網羅基準は制御フロー

範囲は DFD で与えられるとする．DFD の階層はのみに着目した実行文網羅，次が分岐網羅であり，最もテストレベルに対応し，階層が下がると単体テスト

強い網羅基準はデータフローを含めた全パス網羅（Allとなり，上がると統合テストとなる．

Paths）である．全パステストは，すべての分岐の積でDFD はノードとエッジからなる．ノードは３種類の要素である N 個のタスク（プロセス）T a と，Mあり現実的には実現不可能のため，全使用法（All Uses）
が推奨されている [3]．

個の保持データ（データストア）Ds と，L 個の源変更波及をテストする場合，波及に関与するデータ

泉（外部エンティティ）So から構成されている．３に着目し，そのデータフローテストを行う．一般的な全種類の要素を一意に特定する際は T ai ，Dsj ，Sok

使用法は「データを定義したすべての場所から始まり，と表記する．

データを使用するすべての場所に至るまでのパスセグメ

3

SEA

ソフトウェア・シンポジウム2017 in 宮崎

エッジは，ノードからノードへのつながりを有向線

表 1: 拡張 CRUD 図

分で表記している．エッジはデータの流れを表して
おり，制御の流れは表していない．エッジの特定は，タスク

起点ノードと終点ノードを用いて行う．ある特定のデータストア

Ds1

タスクからデータストアへの入力がある場合のエッ

...

Dsj

源泉

So1

...

Sok

T a1

ジの特定は，T ai /Dsj となり，源泉から出力してタ...

スクで処理をする場合は，Sok /T ai と表す．

T ai

• ER 図ER 図はシステムにおけるエンティティ間の関係を組合せの変更タスク群 P {T a} とする．変更タスク示す図であり，UML のクラス図に対応している．

群からの出力するデータストア群を P {Ds} とする．

DFD では表現できないエンティティの詳細化やエンティティ間の関係について示しており，DFD と• ルール 2：波及タスクの特定共に用いられている．

ルール 1 で求めた P {Ds} からの入力エッジを持つ

ここでは，DFD のデータストア Dsj が持つエンタスクを波及タスク群 S{T a} として特定する．

ティティと，CRUD 図の対応から，後述する拡張• ルール 3：順序組合せテストケースの抽出

CRUD 図を作成するために用いる．よって，テス
トベースとしては，システムすべての ER 図を必要とするものではない．

拡張 CRUD 図を基に変更タスク群 P {T a} とそのデータストア群 P {Ds} を介する波及タスク群

S{T a} を組合せ，順序組合せのテストケースとする．

• CRUD 図以降からは，順序組合せを抽出してテストケースとす

CRUD 図とは，タスク T ai からデータストア Dsj
への C ：生成，U ：更新，R：参照，Ds：削除の操るまでの実施手順を詳細に説明する．

作を表した図である [12]．CRUD 図から，DFD と3.3

本論文では，タスクがデータストアに対して行う操定し，拡張 CRUD 図の変更タスク部分を作成する．

作を特定するために CRUD 図を用いる．タスク T ai

拡張 CRUD 図とは，テストベースとして与えられた
DFD，ER 図，CRUD 図から P {T a} の各 T ai と関連すルール１を用いて変更タスクとそのデータストアを特のデータストア Dsj に対する操作が U ：更新であればタスクによる操作はエッジを介した操作として

3.2

ルール 1：変更タスクの特定

ER 図では表現されていないタスクのエンティティへの操作を知ることができる．

る Sok ，そして P {Ds} となる Dsj の関係を追加して作

T ai /Dsj U と表記する．ただし，タスクが操作する
データストアが１つだけの場合は，T ai U といった成したものである．表 1 に拡張 CRUD 図の表記を示す．

省略した表記を使う．

D のいづれか，または組合せか空白である．源泉に対する情報は In か Out，または組合せか空白である．空白

拡張 CRUD 図のデータストアに対する情報は C ，U ，R，

順序組合せテストの概要

は関係が無いことを示す．

提案する手法は，2 タスク間の順序組合せを対象とす

1. 源泉からの入力エッジを持つ変更タスクの特定

る．2 タスク間の順序組合せの抽出は以下のルールを適テストケースは，外部からのテスト対象への入力か用する．

ら，外部への出力結果を確認するものであるため，
テスト入力とテスト結果のペアで構成されている．

• ルール 1：変更タスクの特定

そこで，テスト対象範囲の外からの入力，即ち Sok

対象とする DFD 内の変更タスクのうち，データス

からの入力エッジを持つ T ai を見つける必要があ

トア Ds へ出力エッジを持つタスクを選択し，順序る．この特性を持ったタスクのうち，さらに変更の

4

SEAソフトウェア・シンポジウム2017 in 宮崎

表 2: 中間の拡張 CRUD 図の例
タスク

データストアDs1
T a1 [St1 ]

Ds2

源泉

Ds3

CU

T a3 [St1 ]表 4: 完成した拡張 CRUD 図の例

C

So1

So2

タスク

So3

データストアDs1

In

T a1 [St1 ]In

T a3 [St1 ]T a2 [St1 ]あるタスク群を変更タスクの集合となる P {T a} 候

T a5 [St1 ]

Ds2

Ds3

源泉

So1

CU

So2

So3

In
C

R

In
Out

RU

Out

補とする．変更が特定の状態でのみ起こり得る場合
は，その状態を［Stl ］と記載する．

3.4

2. データストアへの出力エッジを持つタスク特定

ルール 2：波及タスクの特定

ルール 2 を用いて波及タスク群を特定し，拡張 CRUD

T ai から Dsj への出力エッジは，C か U か D の操図へ波及タスク部分を追加し図を完成させる．

作を行うことを意味する．CRUD 図から該当する出

1. データストアを介した波及タスク特定

力エッジを持つ T ai を選択する．P {T s} 候補の中から，該当する T ai を選び，変更タスク群 P {T a}

先に作成した中間の拡張図から変更タスクの操作がを確定する．

C か U か D であるデータストアに着目する．着目したデータストアに対してエッジを持つタスクが波3. 中間の拡張 CRUD 図作成

及タスクの候補となる．波及タスクとして選択する

拡張 CRUD 図には，変更タスク群 P {T a} に該当

タスクは表 3 に示す表の ○ の組合せに該当する

する Sok から T ai への入力 (In)，もしくは T ai か

タスクである．波及タスクは， C：生成，U：更新，

ら Sok への出力 (Out) の情報を付加する．特定しD：削除を選択する． - をつけた組合せは，データストアを介した影響が生じないため，組合せテスト

た T ai に対して，入力となる Sok に In を記入し，Dsj については CRUD 図を参照して C か U か D
かその組合せかを記入する．中間の拡張 CRUD 図の対象としない． × をつけた組合せは仕様上有として例示した表 2 では，3 つの源泉 {So1 ，So2

順序組合せを網羅しなくともテストできるため，組，So3 } と 3 つのデータストア {Ds1 ，Ds2 ，Ds3 } が合せテストの対象としない．

り得ない組合せであり，ありえないことの確認は，あり，2 つのタスク {T a1 [St1 ], T a3 [St1 ]} が変更タ

2. 拡張 CRUD 図の完成

スクである．この段階で作成する拡張 CRUD 図は，作業途中のものである．

波及タスク候補のうち，源泉に出力エッジを持つタ
スクを波及タスクとして特定する．波及タスクの特性を DFD より読み取り，特定する．特定した波及

表 3: タスク間のデータ共有の組合せパターン

タスクを拡張 CRUD 図に追記し完成させる．
完成させた拡張 CRUD 図の例を表 4 に示す．このP {T a}S{T a}

C

R

U

D

C
R

×

×

×

◯

◯

-

◯

-

U
D

◯

-

◯

×

◯

×

◯

例では，データストア Ds1 から源泉 So2 への流れをタスク T a2 [St1 ] が行い，データストア Ds2 から
源泉 So3 への流れをタスク T a5 [St1 ] が行っていることを示している．

3.5

ルール 3：順序組合せテストケースの抽出

拡張 CRUD 図を基に順序組合せのテストケースを抽出し，テストケース表を作成する．

5

SEA

ソフトウェア・シンポジウム2017 in 宮崎

順序組合せテストの適用評価

4

表 5: 順序組合せテストによる論理的テストケースの例

No

論理的テストケース

順序組合せ

1

概要

T a1 C → T a2 R

様を用いて，3 節で述べた実施手順を適用し，順序組合2

概要

T a1 U → T a2 R

せが抽出できることを確認する．

3

概要

T a3 C → T a2 R4

概要

T a3 C → T a2 U

本節では，旅行代理店向けフライト予約システムの仕

4.1

フライト予約システムの概要を以下に示す．

1. 変更タスクと波及タスクの組合せを抽出＜フライト予約システム概要＞
・旅行代理店用に開発したフライト予約サーバにインターネット経由でアクセスできる専用のクライアントアプリケーション．
・旅行代理店の窓口での利用を想定しており，ユーザ認証されたユーザのみ利用可能である．
・旅行代理店の窓口数 (クライアント数) は 50 としており，同時に予約処理を行うことができる．
・旅行代理店にて取り扱う全ての航空会社の飛行機の予約が可能である．
・本システムは，フライト予約サーバを仲介して複数の航空会社のシス
テムと同期をする．
・チケット情報や残チケット数は同期することで最新に更新される．
・フライトの新規予約、予約内容の更新，削除が可能である．更新と削除は新規予約したユーザのみ可能である．
・以下はシステム範囲外-チケット代金の決済（別システムと連携して行うため）．
-マスタ情報設定 (他システムとの共用マスタ設定アプリケーションがあるため）．

拡張 CRUD 図から変更タスクを選ぶ．先に作成した拡張 CRUD 図の例（表 4 を参照）であれば，

T a1 [St1 ], T a3 [St1 ] である．次に変更タスクが操作しているデータストアと，それを操作している波及タ
スクを対応付ける．例では，T a1 [St1 ] −−→ T a2 [St1 ]と T a3 [St1 ] −−→ T a5 [St1 ] である．

題材の概要

Ds1

Ds2

2. データストアに対する操作の組合せ
操作の組合せとは変更タスクと波及タスクの操作の組合せである．表 4 の例であれば，変更タスクのデータストアに対する操作である T a1 は，Ds1 に対して C と U の操作を行っている．波及タスク T a2

図 3: フライト予約システムの概要の操作は R である．組合せは C → R と U → R となる．変更タスクと波及タスク間に介在するデータ

題材となるフライト予約システムの仕様は，本研究のストアが 1 つであれば −−→ を省略して → で表し一環として評価実験の際に題材として使っているものでてもよい．また変更の発生条件となる状態が 1 つである [13]．テスト対象の分析と，テストケース設計に関あれは，[St1 ] を省略してもよい．表 4 の例におけする用語は，国際標準である ISO/IEC/IEEE29119 の定る全組合せは，T a1 C → T a2 R，T a1 U → T a2 R，

義に従い，テスト対象の論理的なサブセットを機能セッT a3 C → T a2 R，T a3 C → T a2 U の４個である．

ト（Feature set）と呼ぶ [14]．本論文では，表 6 の新規

Ds1

フライト予約を変更が入った機能セットとする．(表 6 の3. テストケース表の完成

最後の列にある◯が変更を表す．
）新規フライト予約か変更タスクと波及タスクの操作の組合せをテスト

らテストケースを抽出するための前提として用意した仕ケースとしてまとめる．表 5 にその例を示す．概様は，新規フライト予約に関連する DFD（図 4），ER

要の部分は，当該組合せが持つ入力の条件や出力の図（図 5），CRUD 図（表 7）とする．DFD に含まれる特性を仕様から抜き出して記載する．

タスク数 N は 6，データストア数 M は 2，源泉数 L は4 である．

以上の手順で，順序組合せテストに必要なテストケー
スを抽出する．ここで用いたテストケースとは，ISTQB

4.2

ルール 1：変更タスクの特定の定義による論理的テストケースに相当する [10]．具体
的な値や期待結果，該当の処理までの状態を遷移させてテストベースである DFD に含まれるタスク数 N は 6

いく手順まで定義した記述を具体的テストケースと呼ぶであるが，変更が入った新規フライト予約の変更タスク

が，本論文では扱わない．

は，表 7 の CRUD 図を確認するとフライト検索 T a1 とフライト予約 T a2 であることがわかる．図 4 から，T a1と T a2 の外部入力を確認する．T a1 は，顧客 So1 から

6

SEAソフトウェア・シンポジウム2017 in 宮崎

図 4: 新規フライト予約の DFD（一部分）

表 6: フライト予約システムの機能セット一覧

テストアイテム

機能セット

フライト予約システム

メニュー

変更

ログイン
新規フライト予約◯

予約変更 &

図 5: 新規フライト予約の ER 図（一部分）

キャンセル
予約一覧

搭乗日付と渡航先を外部入力し，T a2 は，顧客 So1 から

予約グラフ

搭乗便，クラス，人数，搭乗者を外部入力している．

同期処理＆続いて，T a1 と T a2 の内部出力を確認する．T a1 はフライト情報 Ds1 に対して検索条件を与えているのみ
で内部入力はしていないため，変更タスク群 P {T a} か

4.3

ルール 2：波及タスクの特定らは除外する．T a2 がフライト情報 Ds1 で U ，予約情報 Ds2 で C を行っていることが表 7 から読み取れる．

ルール 2 にて波及タスク群 S{T a} を抽出するために，

これらから，拡張 CRUD 図（表 8）を作る．表 8 から，タスクの外部出力を図 4 の DFD から調べる．P {Ds} に

ルール１に適合する T a2 /Ds1 U ，T a2 /Ds2 C を特定で含まれる Ds1 と Ds2 にエッジを持ち，かつ So へ出力

きる．

するタスク群が S{T a} 候補である．図 4 では，全てのタスクが Ds1 および Ds2 からのエッジを持つ．しかし，So への出力に着目すると，T a4 は該当するエッジがな

7

SEAソフトウェア・シンポジウム2017 in 宮崎

表 7: 新規フライト予約の CRUD 図（一部分）
機能セット

タスク

新規フライト
予約

T a1
T a2

予約変更

T a3

キャンセル

T a4

予約リスト
予約グラフ
同期処理

T a5
T a6

フライト検
索
フライト登
録
予約情報確
認
予約情報修
正
注文状況
最新情報取
得

表 9: 新規フライト予約の拡張 CRUD 図

エンティティ
Ds1
Ds2
フライ
予約情
ト情報
報
R

RU

タスク

Ds1

C

RU

データストア

T a1

R

T a2

RU

Ds2

源泉

So1

So2

So3

So4

Out
C

T a3

R

R

T a5

R

UD

T a6

InOut
Out
Out

CU

Out

R
CU

• T a2 /Ds1 U −−→ T a6 U
Ds1

表 8: 新規フライト予約の中間拡張 CRUD 図• T a2 /Ds2 C −−→ T a3 R
Ds2

タスク

データストア

源泉

Ds1

Ds2

So1

U

C

In

So2

So3

• T a2 /Ds2 C −−→ T a5 R

So4

Ds2

T a1
T a2

これらの変更タスクと波及タスクの操作の順序組合せ
がテストケースとなる．抽出した順序組合せが持つ入力の条件や出力の特性を仕様から抜き出して論理的テスト

いため，S{T a} 候補には入らない．

ケースとしてまとめる．表 10 に論理的テストケースとS{T a} 候補のうち、表 3 の ○ がつく組合せに相してまとめた結果を示す．

当する T ai が，ルール 2 で特定したタスクとなる．本
表 10: 順序組合せテストによる論理的テストケース

節の例の場合，P {T a} での操作は，C と U であるため，

S{T a} 候補の中で C の操作をする T ai 以外は全てルー
新規フライト予約
No 論理的テストケース
1
フライト予約後の空き情
報問合せによる同一フラ
イトの参照
2
フライト予約後の再度同一フライトの予約

ル 2 で特定したタスクとなる．
これらに該当する T ai と Ds への CRUD 操作，そして So への Out を追記し，表 9 を完成させる．

4.4

ルール 3：手順 順序組合せテストケースの抽出

3

表 9 の拡張 CRUD 図から変更タスクと波及タスクの組合せを抽出する．抽出した変更タスクと波及タスクの4組合せに対して，データストアに対する操作を明記した
5

ものは以下のとおりとなる．

• T a2 /Ds1 U −−→ T a1 R

フライト予約後の同期処理によって最新のチケッ
ト残数の計算既存注文開く画面での予約したフライトの参照
注文件数グラフ・注文履
歴の一覧への新規予約フ
ライト予約の反映

順序組合せ

T a2 /Ds1 U −−−→
Ds1

T a1 RT a2 /Ds1 U −−−→
Ds1

T a2 /Ds1 U
T a2 /Ds1 U −−−→
Ds1

T a6 UT a2 /Ds2 C −−−→
Ds2

T a3 RT a2 /Ds2 C −−−→
Ds2

T a5 RDs1• T a2 /Ds1 U −−→ T a2 /Ds1 U
Ds1

8

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 11: 新規フライト予約の画面遷移表（一部分）
遷移→
前状態↓
フライト予約
画面

フライト検
索ボタン

キャン セ ル
OrOK

[出 発 日・From・To入 力 済] フライトテー
ブルフライトテーブル
注文を開く画
面

フライト予
約画面

注文を開く

グラフ

新規予約

注文を開く
画面

グラフ

[フライト便・ク ラ ス・人数・搭乗者・
入力済] フラ
イト予約画
面

履歴

XOr 終了履歴[フライト選択済] フライト予約画面[予 約 番 号]
フライト予
約画面

グラフ

フライト予
約画面

履歴

フライト予
約画面

ログイン

5

Or 終了

フライト予
約画面

考察

えられる．4 節の適用評価にて利用したテストベースは，変更が入った機能セットに焦点を絞ったものである．4

次に，提案手法で抽出したタスク間の順序組合せと，
AS のテストケースを設計する既出の手法である状態遷移テストで抽出されるテストケースの比較を行う. 状態

節では新規フライト予約が該当する。そのため，表 11

遷移テストのテストベースとなるフライト予約システム

おける波及タスクである T a6 U は，表 7 から同期処理のの画面遷移表（表 11）を使って, 順序組合せの確認が可

タスクであることがわかるが，新規フライト予約とは別

能な網羅基準である S1 網羅基準を適用する．表 11 は，の機能セットに含まれるタスクであり，フライト予約画

4 節の提案手法適用例と適用範囲を合わせるために，新規フライト予約を行うために必要な画面と隣接する画面と隣接する画面からなる画面遷移表には現れない．そでは，新規フライト予約に隣接する画面遷移を該当する
テストベースとしている．表 10 のテストケース No3 にのため，S1 網羅基準では抽出することができない．

面遷移に該当する表としている．仕様の詳細度合いは，

DFD，ER 図，CRUD 図と画面遷移表では同等にしてい

6

おわりに

る．それは，画面遷移のイベントでのガード条件に記載したデータが DFD のエッジに記載したデータ，ER 図の本論文では，状態遷移を持つソフトウェアにおいて，

エンティティの属性と一致していることから確認できる．

変更による変更波及がデータベースや外部変数などの保S1 網羅基準を適用すると 28 の状態遷移パスとなる．28の状態遷移パスのうち，対応する提案手法で抽出した順

持データを介して生ずる場合のテストに関して，その網序組合せは，表 10 で示すテストケース No.1，2，4，5 の出する手法を提案した．DFD，ER 図、CRUD 図をテス

4 つであった．これらは, 画面遷移表のフライト予約状態
での登録イベントを起点にするもののみであった．順序

トベースとして，3 つのルールを適用することでテスト組合せに該当しない状態遷移パスは，互いのタスクで同提案した手法で組合せが抽出できることを確認するため，

一のデータを介して処理をするといったことがない．例

フライト予約システムの仕様を具体例にして適用を行っ

えば，フライト検索をした後にキャンセルをするとフラた．最後に画面遷移図（画面遷移表）から従来手法であイト予約画面に遷移するパスは，前の処理の結果によっる状態遷移テストの S1 網羅基準にて抽出した状態遷移て影響を及ぼさない．

パスと提案手法を比較して，テストケース数の削減がで

S1 網羅基準では抽出できないが，本手法によって抽出できたテストケースは，No.3 の T a2 /Ds1 U −−→ T a6 U

きる効果と，S1 レベルの画面遷移の網羅では抽出でき

羅基準である IDAU 法と, 順序組合せテストケースを抽が必要となる順序組合せを抽出できることを説明した．

ないテストケースが抽出できる効果を示した．

Ds1

提案手法に対する今後の取り組みは 2 つある．1 つは,である．このテストケースは，必要なテストケースと考9

SEA

ソフトウェア・シンポジウム2017 in 宮崎

適用範囲の明確化である. 変更のパターン（タスク内の[7] J.N. Campbell, “Data-flow analysis of softwarechange,” Oregon Health & Science University,
pp.1–118, 1990.

制御ロジックの変更, 新しい要素の追加など）に対して,どこまで適用でき, どこからは適用できないかを明らかにする.
もう 1 つは，今回の提案手法のツール化である．実[8] A. Maule, W. Emmerich, and D.S. Rosenblum,“Impact analysis of database schema changes,”

際の開発プロジェクトで扱う規模の大きいデータ設計文
書に対して本手法を適用する際には，本手法のルールをProceedings of the 30th international conference
on Software engineeringACM, pp.451–460 2008.
[9] 加藤正恭，小川秀人，“CRUD マトリクスを用いたツール化するといった方法での適用が必要になる．これらの準備を行い，実践の場に本手法を適用していく．

ソフトウェア設計影響分析手法，” 情報処理学会第 73

参考文献

回全国大会講演論文集，vol.73，pp.249–250，2011．

[1] R.S. Arnold, Software change impact analysis,[10] ISTQB/FLWG, Foundation Level Syllabus, Inter-

IEEE Computer Society Press, 1996.

national Software Testing Qualifications Board,
2011.

[2] B. Li, X. Sun, H. Leung, and S. Zhang, “A survey of code-based change impact analysis techniques,” Software Testing, Verification and Reliability, vol.23, no.8, pp.613–646, 2013.

[11] T. DeMarco, “Structure analysis and system specification,” Pioneers and Their Contributions toSoftware Engineering, pp.255–288, Springer, 1979.

[3] B. Beizer, Software Testing Techniques, Van Nostrand Reinhold, 1990. (翻訳 :小野間 彰， 山浦恒
央 :ソフトウェアテスト技法, 日経 BP 出版センター[12] A.L. Politano, “Salvaging information engineering
techniques in the data warehouse environment,”(1994)).

Informing Science, vol.4, no.2, pp.35–44, 2001.

[4] H. Gomaa, “Designing software product lines withuml.,” SEW Tutorial Notes, pp.160–216, 2005.

[13] T.Yumoto， K.Uetsuki， T.Matsuodani, andK.Tsuda, “A study on the eﬃciency of a test anal-[5] L.C. Briand, Y. Labiche, and L. O’sullivan,“Impact analysis and change management of
UML models,” Software Maintenance, 2003.
ICSM 2003. Proceedings. International Confer-ysis method utilizing test-categories based on aut
and fault knowledge,” ICACTCM 2014, pp.70–
75, 2014.

ence onIEEE, pp.256–265 2003.
[6] 小谷正行，落水浩一郎，“UML 記述の変更波及解
析に利用可能な依存関係の自動生成，” 情報処理学[14] ISO/SC7/WG26,
Softwareand
Systems
Engineering-Software-Testing Part 2:Test Pro-会論文誌，vol.49，no.7，pp.2265–2291，2008．

cesses, ISO/IEC/IEEE29119 2013(E), 2013.

10

SEA

ソフトウェア・シンポジウム2017 in 宮崎

探索的テストにおける不具合発見率向上に向けた取り組み
中野 直樹
株式会社 LIFULL
NakanoNaoki@LIFULL.com
要旨
探索的テスト（Exploratory Software Testing）は近年様々なソフトウェア開発の現場で用いられている．
弊社の開発プロジェクトにて探索的テストの導入を行い，そこで発見された課題を元に不具合発見率向上に向けた取り組みを行った.

くなるよう重要なテストのヒントを探索的テストで用いるチャーター[3]作成時のインプットの一部として用いることした．ここで使用するチャーターのインプットをチャーターエレメントと名付け，プロ
ジェクトで発見した新しい不具合の知見やソフトウ
ェア起因で本番障害につながった問題などを取り込
み，過去に発生した問題を元にチャーターを作成できるように情報をまとめ，再利用できるようにした.

1. はじめに3.2. チャーターエレメントの拡張と情報の粒度
弊社ではウェブサービスの開発，運営をしており，
社内開発，外部委託あわせて年間数百の大小様々な要件のプロジェクトが稼働している. その中で品質保証部門では，第三者検証なども行っており，様々な開発プロセスが実践されている中で，特にアジャ
イル開発プロジェクトにおいて有効とされる探索的テスト[1]に着目し，導入を行った.

探索的テストに用いるチャーターエレメントは，
定期的に新しい不具合や障害の情報の追加を行う．
その際，最適化する目的で MECE かつ使用しやすい構
成に保つことで，過剰な肥大化や，情報の陳腐化の防止を行えるようにした.

4. 今後の課題

2. 解決したい問題

チャーターエレメントをデータベース化することを検討しているが，その為には効率の良い情報抽出の仕組みが必要となる.現在はテストデバイス（PCやスマートフォンのウェブブラウザやスマホアプ
リ）などの種類別に管理しているが，将来的にはタグなどのメタデータを付与することで必要な条件をもとに検索を行えるよう検討を進める予定である

2.1. 探索的テストの多様性
探索的テストを導入するうえで様々な考え方やス
タイル[3][4][5]があり，どのようなスタイルを選択するかで探索的テスト実施時の検証内容も変わってくることがわかった．

参考文献

2.2. 不具合発見率と属人化[1] 高橋寿一; 探索的テストってなんですか？ア
ジャイル時代のソフトウェアテスト
http://jasst.jp/symposium/jasst14kyushu/pdf/S3.pdf[2] Janet Gregory, Lisa Crispin 実践アジャイル
テスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archive ソフトウェ
ア開発の実践) , 2009[3] Elisabeth Hendrickson Explore It!: Reduce Risk
and Increase Confidence with Exploratory
Testing ,2013

探索的テストの問題点としてテスト実行時の不具合発見率に個人差があり，また発見できる不具合の重要度にも偏りがあることがわかった.

3. 工夫した点
3.1. チャーターエレメントの作成
探索的テスト実施者間の不具合発見数の差が小さ

11

SEA

ソフトウェア・シンポジウム2017 in 宮崎[4] Cem Kaner, J.D., Ph.D.:
A Tutorial in
Exploratory Testing
http://www.kaner.com/pdfs/QAIExploring.pdf[5] James A. Whittaker; Exploratory Software Testing:Tips, Tricks, Tours, and Techniques to Guide Test
Design, 2009

12

SEA

ソフトウェア・シンポジウム2017 in 宮崎

VDM++仕様を対象にしたテストケース自動生成ツール BWDM におけるif 式の構造認識に基づいたテストケース生成手法の提案
立山 博基
宮崎大学大学院工学研究科
tachiyama@earth.cs.miyazaki-u.ac.jp

要旨

片山 徹郎
宮崎大学工学教育研究部
kat@cs.miyazaki-u.ac.jp

様書上の表記を、仕様の作成者が本来意図していない意
味で捉えてしまうことが起こる。実装者が、仕様書の本

ソフトウェア開発において、形式手法を用いることで、来の意図から外れた認識に基づいて実装を行った結果、仕様に曖昧さが含まれることを防ぐことができる。我々

ソフトウェアにバグが混入されてしまう。

は、形式手法 VDM を用いたソフトウェア開発におけるこの問題を解決するための 1 つの手段として、形式テスト工程の効率化を目的として、テストケース自動生

手法 (Formal Methods)[3] が提案されている。形式手法

成ツール BWDM を試作した。既存の BWDM の問題点を用いた開発では、まず、数理論理学を基盤とした形式

として、VDM 仕様中の if 式からテストケース生成を行

仕様記述言語 (Formal Specification Language) により、う際に、ネストや else if などの if 式同士の構造を認識

開発対象が持つ特性を仕様として記述する。数理論理学

していない点が挙げられる。そのため、そのような構造を基にしているため、自然言語を用いた開発と異なり、の中にある戻り値に対するテストケース生成を行えな定理証明や機械的な検査を用いて、記述した内容が正しい。本稿では、この BWDM における、テストケース生

いことを数学的に証明することが可能である。つまり、

成処理の問題点を解決するために、if 式の構造認識に基自然言語の持つ曖昧さを排除した、厳密な仕様を作成すづいたテストケース生成手法の提案を行う。提案手法をることが可能となる。

VDM 仕様に適用した結果、従来の BWDM ではテスト
ケース生成を行えなかった仕様中の戻り値に対する、テストケースの生成が可能になることを確認した。そのため、BWDM に提案手法を実装することで、テストケー
ス生成処理の問題点を解決し、BWDM の有用性が向上
すると言える。

一方で、自然言語もしくは形式手法を用いた設計のいずれにしても、実装を行った後は、作成したソフトウェ
アに対してテストを行う必要がある。テストを行うためには、テストケースの設計作業が必要であるが、人手によるテストケースの設計には手間と時間がかかる。そのため、テストケースの設計作業を効率よく行うことで、テスト工程を効率化できる。また、バグが潜みうる箇所に的を絞ったテストケースの設計を行うことも、テスト

1. はじめに実施の効率化のために重要である。
このような問題とソフトウェアテストの必要性を踏まソフトウェアは年々大規模化かつ高機能化を続け、そえ、形式仕様を基にしたテストケース自動生成ツールの結果、ソフトウェア上のバグが社会にもたらす影響も

BWDM の試作を行った [4, 5, 6]。BWDM は、形式仕様
記述言語 VDM++で記述した仕様とデシジョンテーブ
ルを入力とし、VDM++仕様を基に境界値分析を行い、テストケースを自動生成する。デシジョンテーブルとは、
ソフトウェアの入力に対する出力を表形式でまとめたものである [7]。ソフトウェアに対してテストを行う際に、

近年では甚大なものとなっている [1]。
ソフトウェアにバグが混入する原因の 1 つとして、上流工程のソフトウェア設計段階において、自然言語を一般的に用いていることが挙げられる。自然言語は元来、
曖昧さを含んでいる [2]。そのため、プログラマが、仕

13

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 1. BWDM の構成

ソフトウェアの期待出力を確認する際に有用である。
既存の BWDM の問題点として、VDM++仕様中の if
式からテストケース生成を行う際に、ネストや else if な
どの if 式同士の構造を認識していない点が挙げられる。
そのため、そのような構造の中にある戻り値に対するテストケース生成を行えない。
そこで本稿では、この問題の解決を目的として、if 式

図 2. BWDM の処理の流れの構造認識に基づいたテストケース生成手法を提案する。
具体的には、if 式の構造を認識し、条件式を生成し、それを基にテストケースを生成することによって、既存の• 期待出力データ生成部

問題点の解決を目指す。

– デシジョンテーブル読み込み– 期待出力データ導出

2. テストケース自動生成ツール BWDM

– テストケース生成
本章では、既存のテストケース自動生成ツール BWDM

BWDM が持つ機能は、以下の通りである。

の構成、機能、処理、入出力、及び、問題点について記す。

• VDM++仕様の構文解析及び情報の抽出

BWDM とは、Boundary Value と Vienna Development
Method の頭字語である。W は Value と Vienna の 2 つの V を意味する。

• 抽出した情報を基にした境界値分析• 境界値分析を行った結果を基にした入力データ生成

2.1. BWDM の構成・機能・処理• デシジョンテーブルを基にした入力データに対応す
る期待出力データの導出

図 1 に、BWDM の構成を示す。BWDM は入力デー
タ生成部と期待出力データ生成部によって構成しており、• テストケースの出力 (入力データ＋期待出力データ)

それぞれの役割は以下の通りである。
図 2 に、BWDM の処理のフローチャートを示す。処理は以下の流れで行われる。

• 入力データ生成部– VDM++仕様読み込み

1. 指定された VDM++仕様ファイルを読み込む– 構文解析

2. VDM++仕様ファイルを構文解析する– データ抽出– 境界値分析

3. 関数定義中の引数型と if 式中の条件式に関する情報を抽出する– 入力データ生成

4. 抽出した情報に対して境界値分析を行う

14

SEA

ソフトウェア・シンポジウム2017 in 宮崎

1 class SampleClass2
3 functions
4
5 sampleFunction : int*nat − > seq of char
6 sampleFunction(a, b) ==7 if(a <= 10) then8
if(-1 > a) then9“a <= 10 and -1 > a”
10else if(b > 0) then11“a <= 10 and !(-1 > a) and b > 0”
12
else
13
“a <= 10 and !(-1 > a) and !(b > 0)”
14 else15
if(b <= -3) then16“!(a <= 10) and b <= -3”17else if(a < 20) then18“!(a <= 10) and !(b <= -3) and a < 20”
19
else
20
“!(a <= 10) and !(b <= -3) and !(a < 20)”;
21
22 end SampleClass
図 3. 入力例：VDM++仕様

5. 境界値分析の結果から入力データを生成する
6. デシジョンテーブルを読み込む
図 4. 出力例：テストケース

7. 入力データとデシジョンテーブルから期待出力デー
タを導出する

BWDM は現状、整数値の入力データ生成のみの対応

8. 入力データと期待出力データをテストケースとして併せて出力するであるため、以降の説明で登場する変数の型は全て整数型であるとする。また、テストケース生成処理は、関数

構文解析は、Nick Battle 氏の開発した VDM 静的解

定義中の引数型と if 式のみを対象に行う。

析ツール VDMJ を用いて実現している [8]。境界値分析
は、抽出した引数型、if 式中の条件式のそれぞれに対し

2.2. BWDM の入出力て行い、入力データを生成する。

BWDM は期待出力の導出を、入力データとデシジョ

BWDM の入出力に関して、VDM++仕様ファイルをンテーブルの照らし合わせによって行う。この際に使用

図 3 に、テストケースファイルを図 4 に、それぞれ示す。

するデシジョンテーブルは、本研究室で開発したデシジョ

入出力に関係するファイルは以下である。

ンテーブル生成支援ツール [9] によって生成したもので• 入力ある。最終的に、テストケースを csv(comma-separated

values) 形式でファイルに書き出す。

– VDM++仕様ファイル (テキスト形式)

15

SEA

ソフトウェア・シンポジウム2017 in 宮崎

1 class ProblemClass2
3 functions
4
5 problemFunction : nat -> seq of char
6 problemFunction(a) ==7
if(a mod 4 = 0) then8
if(a > 92) then9“a mod 4 = 0 and a > 92”
10
else
11
“a mod 4 = 0 and !(a > 92)”
12
else
13
“!(a mod 4 = 0)”;14
15 end ProblemClass

図 6. 図 5 から BWDM で生成したテストケース

図 5. 現状の課題：ネストした if 式

図 5 と図 6 に、現状、問題となる if 式、及び、その if式から生成したテストケースを示す。図 5 には、a mod– デシジョンテーブルファイル (csv 形式)

4 = 0 と a > 92 の整数値 a に関する 2 つの if 式がネストしており、戻り値は文字列である。文字列中には、その戻り値を返す際に a が満たすべき条件式を表している。

• 出力– テストケースファイル (csv 形式)

図 6 の期待出力データ中に戻り値 “a mod 4 = 0 and
a > 92” に対するテストケースが存在しないことが確認できる。BWDM は境界値分析による入力データ生成処
理により、1 つ目の a mod 4 = 0 からは 3, 4, 5、2 つ目の a > 92 からは 92, 93 を入力データとして生成するが、それらの中には、“a mod 4 = 0 and a > 92” を出力する入力データは存在していない。戻り値 “a mod 4 =0 and a > 92” を出力するためには、a mod 4 = 0 and
a > 92 を満たす入力データを生成する必要がある。

図 4 の入力データ中に存在する intM in, intM in −1, intM ax, intM ax + 1 などは、図 3 中の関数定義における引数型 (int) に対して境界値分析を行い、生成した入力データである。それぞれ、「引数型 int の最小値
(Minimum)」、「引数型 int 型の最小値より 1 小さい値」、「引数型 int の最大値 (Maximum)」「引数型 int の最大値
より 1 大きい値 (Maximum)」を表す。引数型の範囲外の値 (*Min-1, *Max+1) については、桁溢れにより、プ
ログラムの動作が予測不可能であるため、期待出力デー
タは Undefined Action としている。

このような if 式による構造関係を認識し、その先の戻り値に対する入力データを生成できるように、BWDMを改良する必要がある。

2.3. BWDM の問題点
既存の BWDM は、構文解析により VDM++仕様中

3. if 式の構造認識に基づいたテストケース生
成手法についての if 式の抽出を行っている。しかし、ネスト構造や else

if などの構造は無視している。それらの構造を持つ if 式
が仕様中に存在する場合も、個々の if 式として抽出し、それら 1 つ 1 つに対して境界値分析を行い、入力データを生成している。そのため、複数の if 式が関わりあった構造の中にある戻り値に対する入力データの生成は行えない。

本章では、2.3 節で示した問題点を改良するための手法、及び、BWDM 上でその処理を行うための改良方法について述べる。

16

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 7. if 式へのインデックス付け及び満たすべき条件式の生成3.2. if 式の構造の認識及び満たすべき if 条件式の生成表 1. 図 5 における戻り値及びその際満たすべき条
件式と真偽値
戻り値

提案手法の例を、図 7 に示す。この例を基に、提案手
条件式“a mod 4 = 0 and a > 92”

a mod 4 = 0,
a > 92“a mod 4 = 0 and !(a > 92)”

a mod 4 = 0,a <= 92“!(a mod 4 = 0)”法の説明を行う。手順は、if 式に対するインデックス付
けと条件式の生成の 2 つである。

1. if 式へのインデックス付け (図 7 中の手順 1.)
if 式の構造を認識するために、構文解析を行った後に、各 if 式へインデックスを付ける。インデックス
により、ネストや else if などの構造と、各戻り値に対する条件式を確認できるようにする。図 7 中には、if 条件式が 5 つ存在している。ネスト構造の中に存在している条件式 (図 7 中の condition0 −0, condition0 − 1, condition1 − 0) は、親の条件式(図 7 中の condition0, condition1) のインデックスの数字の後に、更にインデックスとして数字を割り振る。

a mod 4 != 0

3.1. 提案手法

if 式の各出力行へ至るためには、各出力行へ至る条件
式を満たす入力データを生成すればよい。表 1 に、2.3節で用いた図 5 において、各出力行へ至るために満たす

2. 条件式の生成 (図 7 中の手順 2.)べき条件式を示す。

各出力行へ至る入力データについて、if 条件式のイ

1 つ目と 2 つ目の出力においては、if 条件式がネストしているため、満たすべき if 条件式は and で繋がったものとなる。また、else 節の後にある出力は、記述してある if 条件式を否定した条件式を満たす必要がある。

ンデックスを辿りながら、入力データが満たすべき条件式を生成する。インデックスを辿る方法は複数の手法が考えられるが、今回は各戻り値から条件式を辿る。各戻り値ごとに、if 式のインデックスを利

次節から、提案手法を実現するための具体的な処理の用して、その戻り値に至るために満たすべき条件式

流れを述べる。

を導出する。

17

SEAソフトウェア・シンポジウム2017 in 宮崎

して “a mod 4 = 0 and a > 92” を出力しているテスト
ケースを確認できる。
よって、提案手法による処理を今後 BWDM に実装することで、if 式構造の中にある戻り値に対するテスト
ケースを生成できる。

4. 考察
図 8. 図 5 に提案手法を適用して生成したテスト

4.1. 提案手法の有用性についてケース

本稿では、VDM++仕様を基にしたテストケース自動生成ツール BWDM において、if 式同士の構造の中にあ5 行目の output の出力に必要な条件式を具体例とすると、まず、4 行目の condition0 − 1 を満たす必要がある。更に、condition0 − 1 は else if の条件式であるため、2 行目の condition0 − 0 は否定する必要がある。そして、1 行目と 2 行目で if 式がネストしているため、1 行目の condition0 は満たす必要がある。

ンデックスに、更にインデックスを加える形とすることそのため、必要となる条件式は、condition0−1T rue

で、ネストした if 式の構造を表現した。そして、付与しかつ condition0 − 0F alse かつ condition0T rue となたインデックスを基に、各出力行へ至るための条件式をる戻り値に対するテストケース生成を行えない問題を解決するために、if 式の構造認識に基づいたテストケース
生成手法を提案した。
提案手法は、まず、VDM++仕様を構文解析した後に、関数定義中に登場する if 式にインデックス付けを行った。
この際、ネストの中にある if 式については、その親のイ生成した。最後に、生成した条件式を満たす入力データる。

を乱数によって生成した。
なお、ここでの condition∗T rue , condition∗F alse とは、今回提案した手法により、if 式同士の構造の中にある

a > 92 という if 条件式を例にすると、conditionT rue がa > 92、conditionF alse は、conditionT rue の a <= 92となる。

戻り値に対するテストケースを生成できることを確認できた。よって、既存の BWDM のテストケース生成処理に、今回提案したテストケース生成処理を追加で実装することで、if 式同士の構造の中にある戻り値に対するテ

3.3. 生成した条件式を満たす入力データの生成

ストケース生成を行えない問題を解決できる。

満たすべき条件式を生成した後に、その条件式を満た4.2. 関連研究

す整数値を生成する。乱数により整数値を生成し、整数値が条件式を満たせば、入力データとして採用する。

記号実行 (Symbolic Execution)[10] を用いることで、条件式を満たす整数が存在しない場合、入力データの今回の提案手法同様に、if 式が入れ子になった場合も全生成は不可能である。そのため、入力データ生成に時間ての戻り値に対してテストケース生成を行った事例とし制限を設け、一定時間が経過した場合は入力データ生成て、宮本らの研究 [11] と、高松らの研究 [12] がある。記号実行は、各戻り値に対する制約条件 (条件式) を導出

処理を終了する。

する。
ソースコード中の表明 (Assersion) の動的な自動生成

3.4. 提案手法によるテストケース

手法は広く研究されているが、その問題点として、最終
図 8 に、2.3 節の図 5 に対して、提案手法を適用する的に生成する表明は、手法中で対象プログラムの実行ことで生成できるテストケースを示す。提案手法によりデータを取得する際に用いられるテストケースに依存す

新たに生成できるテストケース中に、期待出力データとるということが知られている。宮本らはこのテストケー

18

SEA

ソフトウェア・シンポジウム2017 in 宮崎

TOBIAS と BWDM は，どちらも VDM++を用いたソフトウェア開発のテスト段階を支援する．TOBIAS は，
VDM++で記述された仕様そのもののテスト支援を行う．
これに対して，BWDM は VDM++で記述された仕様か
ら実際に実装を行ったソフトウェアへのテストを支援する点で，異なっている．

ス依存問題を改善するために、記号実行などの手法を用いたテストケース生成手法を提案した。記号実行を用いて、対象ソースコード内の全ての戻り値に対して、その制約条件 (条件式) を導出し、その条件を満たす引数を生成している。
また、オブジェクト指向プログラミングにおけるソフトウェアテストを行うには、テスト対象のインスタ

5. おわりに

ンス生成・状態の変更などの前準備のメソッド実行を、
テストケース内で行う必要がある。そのようなテスト
ケース自動生成ツールの 1 つに Seeker[13] があり、高松

本稿では、VDM++を基にしたテストケース自動生成

らは Seeker の機能拡張を行った。Seeker では、記号実

ツール BWDM における、if 式同士の構造の中にある戻行と具体的な値を組み合わせた動的記号実行 (Dynamic

り値に対するテストケース生成を行えない問題を解決す

Symbolic Execution) を用いて、ソースコード中の条件式を基に、全ての戻り値に対する引数の組を生成している。

るために、if 式の構造認識に基づくテストケース生成手

本研究で提案する、if 式の構造認識に基づいたテストに、if 条件式にインデックスを付与し、そのインデック

ケース生成手法は、インデックスを用いて戻り値から条スを基に、各出力行へ至るための条件式を生成し最終的件式を導出するため、記号実行と比較して、探索空間をに、それらの条件式を満たす入力データを乱数によって削減できる。そのため、計算効率の面で、記号実行に比生成した。

法を提案した。
提案手法ではまず、VDM++仕様を構文解析した後べて優位性が有ると言える。

提案手法により、既存の BWDM では生成できなかっ

また、VDM 仕様を基にしたテストケースの自動生成

た、if 式による構造の中にある戻り値に対するテストケー法に関する研究の 1 つに、馬場らの研究がある [14]。馬スの生成が可能なことを確認した。故に、既存の BWDM

場らの研究では、VDM 仕様記述からコーナーケースにのテストケース生成処理に、今回提案したテストケース

対するテストを行うことを目的として、テストドライバ

生成処理を追加で実装することで、if 式同士の構造の中の雛形の作成を行うツールを開発した。馬場らのツールにある戻り値に対するテストケース生成を行えない問題

は、形式手法を用いたソフトウェア開発におけるプロセを解決できる。

ス中の、単体テストにおけるテストを支援する。

以上のことから、今回の提案手法に基づいて BWDM

馬場らのツールは、現状、VDM-SL 仕様内の操作定へ入力データ生成処理を実装することで、既存の BWDM

義をテストケース作成の対象としている。そのため、の問題点を解決し、BWDM の更なる利便性の向上に繋

VDM++を対象に、関数定義からテストケースを作成する BWDM とは異なる。また、馬場らのツールから出力されるテストケースは、入力データとして記述内の条件式を表示するものである。これに対して、BWDM は条件式から生成した、具体的な数値の入力データを確認することが可能である。そのため、BWDM の出力を使ってそのままテストを実行できることが、BWDM の利点であるといえる。

がると言える。
以下に、BWDM の今後の課題を示す。

• デッドコードへの対応
戻り値に対する条件式を満たす整数が存在しない
場合、戻り値はデッドコードである。この場合、入力データ生成は行えないため、本研究では入力デー
タ生成処理を一定時間で終了する。充足不能な条件

また，VDM++仕様記述をテストするためのテスト

式に対しては、入力データ生成処理を行わず、ユー

ケース自動生成ツールとして，TOBIAS[15] がある．TO-

ザーにデッドコードを指摘する機能が必要である。

BIAS は，TOBIAS に入力されたテストパターンに従い，
テストケースを自動生成する．テストパターンとは，テスト設計者が正規表現を用いて，出力するテストケースを定義したものである．

• 未対応の定義部や構文、演算子への対応
操作定義、型定義などの定義部へは現在未対応である。また、事前条件や事後条件、let 式など

19

SEA

ソフトウェア・シンポジウム2017 in 宮崎の VDM++に存在する多くの構文にも、既存のPrototype of Test Cases Automatic Generation
Tool BWDM Based on Boundary Value Analysis
with VDM++, The 2017 International Conferenceon Artificial Life and Robotics(ICAROB 2017),
pp.275-278, 2017

BWDM は未対応である。これらの構文からテスト
ケースを生成する手法を考案し、BWDM に実装することで、BWDM の有用性が更に向上すると考えている。
• 整数型以外への対応[7] SQuBOK 策定部会, ソフトウェア品質知識体系ガイド 第 2 版, オーム社, 2014

既存の BWDM は、整数型以外の、実数型や合成型には未対応である。構文解析の際に、整数型以外の[8] Nick Battle GitHub - nickbattle/vdmj, https://github.com/nickbattle/vdmj, 2017/3/8 アクセス型の情報を抽出し、境界値分析及び入力データ生成
処理を実装することで、これらのテストケースの生[9] 西川拳太, 片山徹郎, VDM++を用いたデシジョン
テーブル生成支援ツールについて, 平成 25 年度 電気関係学会 九州支部連合大会, p.381, 2013

成が可能になると考えている。

• 両辺が変数である if 条件式への対応
if 条件式中の両辺が変数である場合、既存の BWDM
は境界値分析を行うことができないため、入力デー
タ生成を行えない。このような if 条件式から境界値を抽出する処理を BWDM に実装することで、
BWDM の適用範囲の更なる拡大を見込める。

[10] James C. King, Symbolic Execution and Program
Testing, Communications of The ACM Vol.19,
No.7, pp.385-394, DOI: 10.1145/360248.360252
1976[1] 失敗事例データベース, 失敗事例 – みずほファイ
ナンシャルグループ大規模システム障害, http://
condezine.jp/article/detail/2364, 2017/3/8
アクセス[11] 宮 本 敬 三, 堀 直 哉, 岡 野 浩 三, 楠 本 真 二,
Daikon 生 成 表 明 改 善 の た め の テ ス ト ケ ー ス
自 動 生 成 手 法 と そ の 評 価 実 験,
コ ン ピュー
タ ソ フ ト ウェア, Vol.28, No.4, pp.306-317,
https://www.jstage.jst.go.jp/article/
jssst/28/4/28_4_4_306/_article/-char/ja/
2010[2] IPA 独立行政法人 情報処理推進機構, なぜ形式
手法か, http://sec.ipa.go.jp/users/seminar/
seminar_tokyo_20150912-02.pdf, 2017/3/8 アクセス[12] 高松宏樹, 佐藤晴彦, 小山聡, 栗原正仁, 動的記号実行によるメソッドの複雑度を考慮したテストケース
自動生成, 情報処理学会研究報告 Vol.2014-SE-185,
No.27, NAID: 110009803966 2014[3] 荒木啓二郎, 張漢明, プログラム仕様記述論, オーム
社, 2002[13] Suresh Thummalapenta, Tao Xie, Nikolai Tillmann, Jonathan de Halleux, Zhendong Su, Synthesizing Method Sequences for High-Coverage Testing, SIGPLAN Notices Vol.46, No.10, pp.189-206,
DOI: 10.1145/2076021.2048083 2011

参考文献

[4] 立山博基, 片山徹郎, VDM++仕様を基にした境界値
テストケース自動生成ツール BWDM の試作について, 平成 28 年度 電気・情報関係学会 九州支部連合
大会, p.90, 2016[5] 立山博基, 片山徹郎, VDM++仕様に対する境界値分析を用いたテストケース自動生成, JaSST’16 九州,
p.32, 2016[14] 馬 場 勇 輔, 荒 木 啓 二 郎, 日 下 部 茂, 大 森 洋
一, 形 式 仕 様 記 述 の プ ロ パ ティベ ー ス テ ス ト への活用, 情報処理学会 火の国シンポジウム予稿集, https://www.ipsj-kyushu.jp/page/ronbun/
hinokuni/1005/5C/5C-1.pdf, 2017/3/11 アクセス

[6] Hiroki Tachiyama, Tetsuro Katayama, Yoshihiro
Kita, Hisaaki Yamaba, and Naonobu Okazaki,[15] Olivier Maury, Yves Ledru, Pierre Bountron and Lydie du Bousquet, Using TOBIAS

20

SEA

ソフトウェア・シンポジウム2017 in 宮崎

for the automatic geneeration of VDM test
cases, Laboratoire Logiciels, Systemes Reseaux –IMAG, http://vasco.imag.fr/Tobias/Papers/
vdm02tobias.pdf, 2017/5/10 アクセス

21

SEA

ソフトウェア・シンポジウム2017 in 宮崎

段階的なシステムテストによる IoT システム開発効率化
西村 治
パナソニック株式会社
nishimura.osm@jp.panasonic.com
要旨これに対して，IoT システムのように多様な複数組織が連携して行うシステム商品開発では，従来のブラックボッ
クステスト[3]を行うシステムテストでは非効率な面が顕在化し，新たなシステムテストの仕組みが求められていた．

様々な商品が連携し複雑化している当社の IoT システ
ム開発において，従来のシステムテストでは，テスト終盤
で不具合が収束せず，不具合対応に計画以上の時間を要し，開発納期に影響するという課題が発生している．
これを解決するために，段階的なシステムテストを導入
し，テスト終盤の不具合を大幅に削減できた．この取り組
みを本稿で紹介する．

2.2. IoT システムの例
IoT システムの例として，当社のシステム商品である「スマート HEMS」を紹介する．スマート HEMS は，図 1に示す通り，コントローラである AiSEG2 を中心に，社内の別組織で開発されたエアコンやレンジフード，他社商品の電動窓シャッターといった多様な商品が無線あるいは有線の通信で接続されており，センサー情報に基づいたエネルギー消費の見える化や，省エネのための家電の最適制御を実現している．また，AiSEG2 はインターネット
経由でサーバと接続されており，スマートフォン向けのHEMS サービスを提供している[4]．

1. はじめに
ネット家電やホームオートメーションなどから始まった家電のシステム化は，昨今 IoT システムと呼ばれるようになった[1][2]．この IoT システムは，構成する商品が多様化し，社内の異なる組織で開発された商品や他社商品を含む構成が一般的となっている．これら多様な組織で開発された商品は，品質が一定でないことに加え，不具合への対応も一律の手順では円滑に進まないケースが多くなってきた．
このため，従来のシステムテストでは非効率な面が顕在化し，新たなシステムテストの仕組みが必要となってきた．この新たな仕組みとして，段階的なシステムテストを導入することした．この導入時の課題とその解決策を事
例を踏まえて紹介する．

2. IoT システム開発の変化と課題

図 1 スマート HEMS システム構成図( 1)2.1. 背景
当社では，独立した複数の商品の組み合わせで価値を提供する商品を「システム商品」と呼んでいるが，従来のシステム商品開発は，システム商品を構成する全ての商品を単一の組織で開発し，その後別の組織が第三者としてシステムテストを実施するという体制をとるケースが多かった．

2.3. システムテストにおける課題
IoT システムにおける従来のシステムテストでは，不具1

商品カタログより一部抜粋．一部表示されていない
対応商品があります．

22

SEA

ソフトウェア・シンポジウム2017 in 宮崎

合の収束に時間がかかるという課題が発生していた．
これは，テスト終盤になっても不具合が断続的に発生している状況である．テストの前半では，一見すればわかる画面表示に関する不具合が多いが，後半になると，これら画面表示に関する不具合は減少し，システム内部の振る舞いを通信ログやデバッグログで確認しないと原因がわからない不具合が見つかるようになる．
さらに，これらの不具合が商品間の通信に関するもの(以下，通信不具合と呼ぶ)である場合，複数の組織間で整合を図りながら，不具合対応を進める必要があるため，時間がかかることになる．
このため，テスト後半に通信不具合が多発すると，不具合対応に予想以上の時間を要するという問題が発生し，納期遅延のリスクが高まる．

とする．この理由は以下のとおりである．
一般に，通信の詳細レベルのテストは，商品開発におけるプロトタイプ開発や通信の方式評価で行い，当社でも同様のフェーズで行っている．このフェーズでは，プロトタイプとしてエミュレータやシミュレータで確認しているが，これらの完成度が低い場合が多く，商品開発時では，接続に問題がなかったが，実機どうしで接続すると接続できない，あるいは，1 台は接続できるが，複数台の接続はできないといった問題が従来のシステム商品適格性確認テストの開始時で発生していたためである．
以上より，システムテストは，図 2 のような段階的なシス
テムテストとなる．

3. 課題解決に向けて
3.1. 原因
2.3 節で述べた課題である不具合の収束に時間がかかることを解決するために原因を考える．
従来のシステムテストは，ユーザーインターフェースに対する機能ベースのブラックボックステストが中心であった．このブラックボックステストでシステム商品の内部の振る舞いである通信不具合を検出するには，限界があり，効率的に不具合を検出できないテストであった．
このため，商品間の通信において，詳細レベルを確認するテストが足りていないことが原因と考える．

システム商品結合テストを導入するにあたり，主な課題を３つ説明する．

3.2. 対策案

3.3.1. テスト担当者のスキルの問題対策案として，前節で述べた足りていないテストを追加する．このテストは，システム商品の内部の振る舞いを確認するテストであるので「システム商品のホワイトボックス
テスト」と位置付け「システム商品結合テスト」と呼ぶ．一方，従来のシステムテストで行っていたブラックボックステ
ストは「システム商品適格性確認テスト」と呼ぶ．
システム商品結合テストは，システム商品の内部の振る舞いを確認するテストであるので，方式設計書に基づ
き，商品間の通信の網羅的なテストを行う．
次に，このテストの実施フェーズは，

商品開発後に行うシステムテストに位置付ける．

ブラックボックステストであるシステム商品適格性確認テストの前に実施する．

システム商品結合テスト(以下，本テストと呼ぶ)の実施にあたり，以下の観点で問題があった．

図 2 システムテストの流れ

3.3. 対策案の導入に向けた課題[通信の内容の確認スキル]
本テストは，ホワイトボックステストとして，通信の内容を確認するテストなので，従来のブラックボックステストで，ユーザインターフェースの動作を確認してきたシステム商品適格性確認テストの担当者が行えるかという問題がある．具体的には，通信モニタのログから通信シーケンスや
通信データなどを確認し，テスト結果の合否判断を行うことになる．このため，システム商品適格性確認テストの担
当者は，テストの実施はできるが，テスト結果の確認ができない可能性があり，商品開発の担当者が本テストを実

23

SEA

ソフトウェア・シンポジウム2017 in 宮崎

施したほうが良いと考える．

例えば，通信に異常が発生した場合のシステム商品の動作を確認するテストで説明する．
この場合，通信断を発生させてシステム商品の挙動を確認する．この挙動として，通信失敗がユーザに表示されるか，通信断が復旧すると，システム商品が正しく動作しているかを確認することになる．図 3 に示すような，商品
P が商品 A の 3 つの状態を取得する場合を考える．この場合，3 往復の通信シーケンスとなり，商品 P で 1 往復毎にタイムアウトが設定されているとする[5]．

[異なる組織と調整するスキル]
本テストの担当者は，仕様整合時や不具合対応時などは，商品毎に異なる組織の担当者との意思の疎通を行い，整合する必要がある．しかし，同一の組織内での商品開発のみを行ってきた担当者では，このような経験が少ないので，うまくいかないことが考えられる．さらに，自組織の利害関係を優先したりすると，不具合の修正方針
を公平に判断できず，担当する商品の変更をできるだけ少なくする方針で対応したりすることが予想され，システ
ム商品の品質が低下することが考えられる．このため組織間で公平な対応ができる第三者が対応することがより良いと考え，システム商品適格性確認テストの担当者が本テストを担当したほうが良いと考える．

図 3 通信シーケンス

3.3.2. テスト設計に方式設計書が必要
システム商品結合テストでは，通信の内容の詳細を確認する十分な方式設計書をもとにテスト設計を行う必要がある．この通信に関する方式設計書は，商品開発側で作成するものであるが，これまでは，システム商品適格性確認テストでは必要ないものであったため，その記載レベルが不明である．このため，本テストで十分な内容であることを確認する必要がある．
もしも，この設計書の記載レベルが低い場合，開発担
当者に設計書に通信内容を追記してもらう必要がある．
この設計書の確認時期については，商品開発が始まり，方式設計フェーズで確認するのが効率的と考える．

従来のシステム商品適格性確認テストでは，このようなテストは，テスト担当者が通信タイミングをみて，通信線を抜くといった手順で行うことになる．このため，確実に発生させることができず，複数回の実施が必要であり，時間のかかるテストとなっていた．また，①～⑥の全てのシーケンスで通信失敗を発生させることは非現実的で，①～⑥のいずれかのシーケンスで通信失敗となるテストとなっていた．このため，10 回実施しても通信失敗を 2，3 回し
か発生させることができないといった状況であった．
一方，システム商品結合テストでは，①～⑥の全てのシーケンスで確実に通信失敗させることを目指し，任意のシーケンスを破棄させるようなテストツールを作成し，確実に 1 回で指定したシーケンスを通信断できるようにしする．この場合，6 回のテスト実施で全てのシーケンスで通信断を発生させることが可能となる．
以上のことから，システム商品結合テストのほうがカバ
レッジの向上と実施時間の短縮が可能となり，効率的なテスト実施を行い，不具合を確実に検出できるようになると考える．

3.3.3. ホワイトボックステストのテスト工数増大への対応
一般にホワイトボックステストを実施する場合，テスト項
目が増大するという問題がある．しかし，今回は，不具合の早期検出を目的として，不足している通信内容の詳細な確認テストを追加することにしている．
このため，納期遅延リスクが増えない範囲で，テスト項
目の増加によるテスト工数の増加を許容し，テスト実施を効率化する必要がある．
すなわち，テスト工数の増加によるテストカバレッジの向上とテスト実施時間の短縮による効率化を実現することを考える．
次に，システム商品結合テストで行う通信内容の詳細なレベルでの確認方法についてその考え方を説明する．

4. 事例紹介
3.3 節の課題を解決し，システム商品結合テストを導入した事例について，当社のシステム商品であるスマート
HEMS の開発プロジェクトを紹介する．

24

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4.3. テスト工数増大への対応
4.1. テスト担当者の決定
スマート HEMS の開発プロジェクト発足にあたり，シス
テム商品結合テストのチーム体制を以下のように決定した．
 商品開発のメンバに，通信に関するスキルがあり，かつシステムテストを経験したメンバがいたので，システム商品結合テストの担当者とした．
 システム商品適格性確認テストを担当する組織には，通信に関するスキルを持つメンバもいたが，他の開発プロジェクトを担当していたので，本プロジェクトにアサインできなかった．
次に，テスト担当者は，他の組織と調整を行う必要があるので，商品の開発には関らず，システム商品結合テスト専任とした．テスト担当者を専任とすることで，開発プロジ
ェクト発足時から参加可能となり，他の組織との関係を早くから築くことができた．さらに，商品開発を担当していな
いので，個別の商品に肩入れせずに，システム商品全体を見渡し，各商品の開発を行っている様々な組織と公平に調整ができた．

3.3.3 節で述べたように，テスト工数の増加によるテスト
カバレッジの向上のとテスト実施時間の短縮による効率化を実現する方法として，テストツールの活用を提案した．
今回，スマート HEMS で開発したテストツールを紹介する．このテストツールは，意図した通信異常を確実に発生させることができるツールである．
従来のシステムテストでは，通信異常に関するテストに多くの時間を要していたので，テストツールを開発し，効率化を実現した．
説明を簡単にするため，スマート HEMS における
AiSEG2 とエアコンとの通信動作を考える．この AiSEG2とエアコンは，特定小電力無線を使って通信を行う．
この場合，図 4 の(a)に示すように，AiSEG2 はエアコンに対して要求パケットを送信するとエアコンが応答を返す
通信シーケンスを考える．この通信を図 4 の(b)に示すよ
うにテストツールがパケットを破棄して切断することでAiSEG2 がタイムアウトし，通信異常となる．この時のAiSEG2 の動作を確認するテストが可能となる．

4.2. テスト設計に必要な方式設計書の充実
4.1 節のテスト担当者は，システム商品結合テストの設計に必要な方式設計書を商品開発担当者に開発開始
時に作成依頼と提供依頼を行うようにした．さらに方式設
計フェーズで方式設計書のデザインレビューにもレビューアとして参加し，内容の確認を行い，不足していると思われる内容については追加の依頼を行った．
実際に，追加した内容としては，通信の異常系に関するものが多かった．正常系の通信に関する方式設計は，問題が少なかった．この結果，方式設計書の内容が充実
し，品質が向上した．
想定外の問題としては，システムテストが開始されると商品開発の担当者の一部が他の開発プロジェクトに異動した．この影響で，方式設計書のメンテナンスができなくなった．不具合発生時などで仕様変更となる場合，方式
設計書を変更してもらう必要があるが，担当者がいない状況となっていた．このため，緊急対応として，システム
商品結合テストの担当者が修正対応を行った．

図 4 テストツールによる効率化
システム商品適格性確認テストとテストツールを活用した場合を順に表 1 と表 2 に示す．
表 1 システム商品適格性確認テストの場合
手法

発生回数(カバレッジ)
試行回数
所要時間

25

実機 2 台の物理的な距離を離して，パケットの破棄または，遅延を実現する
要求か応答のいずれかのパケットを対象とし，破棄か遅延のいずれかを
1 回だけ発生
発生するまで何回でも平均 1 時間SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 2 システム商品結合テストでテストツールを活用し
た場合
手法

発生回数
(カバレッジ)
試行回数
所要時間

験者を専任の担当者とすることで，開発の初期段階からテスト設計，テストツールを含むテスト環境の準備ができ，システム商品結合テストをスムーズに導入することができた．
さらに，システム商品適格性確認テストの開始をスムー
ズに始めることができるようなり，システム商品適格性確認テストの担当者は，システム商品結合テストの重要性を理解した．

実機 2 台とテストツールを使って机上で容易にパケットの破棄と遅延を実現する
要求と応答で各 1 回と破棄と遅延の各 1 回で 2 回×2 回の計４回
4回
平均１５分

5.3. 今後の課題

以上のようにテストツールを活用することで，通信異常のテストは，テストカバレッジが 4 倍になり，かつ，所要時
間を約 1/4 に削減できた．
このことから，通信異常のテストでは，約 16 倍の効率化を実現できた．

5.3.1. システム商品結合テストの定着化
今回の事例では，開発側にテスト経験のあるメンバをテスト担当者に決めたが，このようなスキルを持ったメン
バは少ない．今後，システム商品結合テストを開発側が行った方式設計書に対する検証フェーズと考えた場合，定着化させるためには，開発側メンバに対するテストスキ
ルの育成が必要となる．
また，方式設計書の品質が維持できるように，システム
テストフェーズにおいても，開発側の担当者が必要であることを周知し，開発側で修正できる体制の維持が必要と考える．

5. 成果と検証
システム商品結合テストを導入した成果と検証を行う．
5.1. 不具合の早期発見を実現
システム商品結合テストを実施することで，多くの通信不具合を検出することができた．通信不具合は，システム
商品結合テスト全体の不具合の約 3/4 を占めていた．通信シーケンス，通信性能，通信競合に関するものが検出できた．
また，システムテスト全体の通信不具合の約 95％は，システム商品結合テストで検出できた．
このことから，通信不具合の多くをシステム商品結合テ
ストで早期に検出でき，システム商品適格性確認テストの前に検出することができた．

5.3.2. システム商品結合テストの効率化
IoT システムは，今後も規模が大きくなり，様々な商品が接続されていくと予想される．これに伴い，システム商品結合テストの工数も増加すると考えられる．このため，
テスト自動化による効率的なテスト実施を実現し，テスト工数の増加を最小限に抑えたい．

6. おわりに5.2. システムテストの効率化

他社商品や異なる組織で開発が行われている様々な商品で構成される IoT システム開発において，テスト担当
者の決定，通信に関する方式設計書の充実．テスト工数増大の対応を行い，システム商品結合テストを導入した．
この結果，通信不具合の早期検出が可能となり，不具合の収束を早く行えるようになり，システムテストを効率良く進めることができた．
今後の課題としては，システム商品結合テストの定着化と，システム規模拡大に対応した効率化が必要と考える．

通信不具合の対応に関しても，方式設計書に基づく指摘であるため，公平な立場で商品開発側に対応をお願いできるようになり，組織の力関係や個別の商品の都合で対応方針が決まることが少なくなり，異なる組織の開発担当者と整合がうまくでき，不具合の収束も想定範囲内で推移し，計画通りにシステムテストを完了することができた．
今回，通信の内容確認ができるスキルを持つ開発経

26

SEA

ソフトウェア・シンポジウム2017 in 宮崎

また，今回，システム商品結合テストを実施することで，通信品質が向上したと考えるので，今後の市場トラブルを未然に防ぐことができたことを確認したい．これは，商品発売後の初期トラブルの発生数を他の商品と比較する
ことで確認したい．

謝辞
今回の経験論文の作成において，忙しい中，様々なアドバイスをいただいた当社の山本氏，藤村氏，植月氏に感謝いたします．

参考文献[1] wikipedia, “モノのインターネット”,
https://ja.wikipedia.org/wiki/モノのインターネット.
[2] モ バ イ ル コ ン ピ ュ ー テ ィ ン グ 推 進 コ ン ソ ー シ アム,“IoT 技術テキスト”, リックテレコム (2016/10/28).
[3] ISTQB テスト技術者資格制度 用語集, JSTQB,
http://www.jstqb.jp/dl/JSTQB-glossary.V2.3.J02.pdf.
[4] スマート HEMS，Panasonic,
http://www2.panasonic.biz/es/densetsu/aiseg/aiseg2/
system.html.
[5] 竹政昭利 他, “かんたん UML 入門”, 技術評論社(2013/6/7).
[6] 独立行政法人 IPA,”【改訂版】組込みソフトウェア向け開発プロセスガイド”, 翔泳社(2007/11/19).

27

SEA

ソフトウェア・シンポジウム2017 in 宮崎

例外処理を含む Java プログラムを対象としたデータ遷移可視化ツール TFVIS の適用範囲の拡大
佐藤 拓弥
宮崎大学大学院工学研究科
sato@earth.cs.miyazaki-u.ac.jp
水久保 直哉
株式会社スカイコム
mizukubo@skycom.jp

片山 徹郎
宮崎大学工学教育研究部
kat@cs.miyazaki-u.ac.jp
田中 伸英
株式会社スカイコム
tanaka@skycom.jp

要旨

この問題を解決するため、我々の研究室では Java プ
ログラムの動的な挙動を可視化するツール TFVIS を開ソフトウェア開発工程において、デバッグは手間と時発した [5]。

間のかかる工程である。このデバッグにかかる手間と時間の削減を目的として、我々の研究室ではデータ遷移可

TFVIS は、データ遷移可視化と実行フロー可視化によって、プログラム実行時の挙動把握を支援する。TFVIS

視化ツール TFVIS を開発した。TFVIS は、データ遷移の可視化により、欠陥を含んだプログラムの実行時の挙可視化と実行フロー可視化によって、プログラム実行時

動把握を容易にし、プログラムが含む欠陥の特定を支援の挙動把握を支援する。TFVIS の可視化により、欠陥する。また、他の機能として、データ遷移を矢印を用いを含んだプログラムの実行時の挙動把握を容易にし、プて示すことができる。これにより、プログラムの不具合

ログラムが含む欠陥の特定を支援する。しかし、TFVIS

から欠陥の特定を容易にする。しかし、TFVIS は一部

は一部の制御構造や式にしか対応しておらず、有用性がの制御構造や式にしか対応しておらず、有用性が高いと高いとは言えない。そこで、例外処理を含む Java プロは言えない。

グラムを対象とした適用範囲の拡大を行った。これによそこで本稿では、未対応の制御構造の 1 つである、例

り、TFVIS の Java プログラム可視化ツールとしての有外処理を含む Java プログラムを対象とした適用範囲の拡用性が向上したと言える。

大を行う。具体的には、Try Catch 文を含むプログラムを可視化できるように拡張を行う。これにより、TFVISの Java プログラム可視化ツールとしての有用性の向上

1. はじめにを目指す。

ソフトウェアの開発工程において、デバッグは手間と2. TFVIS

時間のかかる工程である [1]。プログラムの故障により期待した結果を得られない場合、故障の原因である欠陥

今回適用範囲の拡大を行う TFVIS の機能と構造につを特定する必要がある。しかし、この欠陥特定の作業はいて、それぞれ以下で説明する。

困難である [2]。
効率よくプログラムの欠陥を特定するためには、プロ

2.1. 機能

グラムの動的な挙動を理解することが重要である [3]。し図 1 に、TFVIS の外観を示す。TFVIS はソースコー

かし、プログラムの動的な挙動は、一般的に不可視であドからプログラムの構造を解析した構造情報と、実行時

るため、把握することが困難である [4]。

28

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 1. TFVIS の外観の情報を基に、データ遷移図を生成する。データ遷移図

係を可視化するデータ遷移線がある。データ遷移線は、は、ループ処理や分岐などによる処理の流れの変化、変ある特定の変数が更新された際に、その更新に影響を与数の更新によるデータの移り変わりなど、プログラム実

えた変数がプログラムのどの時点で生成されたものであ行時の各メソッドの詳細な挙動を示す。

るかを示す。例えば、「a=b+c」という式が存在すると

図 1 を例に説明する。図の右側に見える個々のウィン

き、「a」の値を選択することで、更新に関わった「b」とドウが、各メソッド内の処理を示すデータ遷移図である。

「c」の値が生成された時点を赤色の矢印を用いて示す。

ウィンドウの左側にメソッドのソースコードを、中央にこのデータ遷移線を活用することで、特定の変数がどの各行で起こるイベントや変数名を、右側に処理の流れをような変数同士の関係で生成されたかを確認できる。こ示している。if 文や for 文によって、処理の流れが変化す

れにより、ユーザがデータ遷移図上で変数の不審な値をる場合、右側に濃い緑色で処理の流れの様子を描画する。

発見した場合に、データ遷移線を活用することによって、

また、メソッド中で変数の更新を行う処理がある場合、不審な値を生成した原因の特定が容易になる。
さらに、TFVIS はプログラム全体の流れを、UML の更新後の値をボックスに記述し、対応するソースコード

シーケンス図 [6] を基にした実行フロー図によって可視右側に描画する。

化する。これにより、各クラスのメソッドの使用状況や、ウィンドウの左側に見える縦に伸びるラインを描画しメソッド呼び出しの関係を表す。プログラム全体の処理てある図が、プログラム実行全体の処理の流れを示す実を実行フロー図によって可視化することで、各メソッド

行フロー図である。ライン上にある太い部分がメソッドの詳細な挙動を示すデータ遷移図の活用を補助する。

の活性区間であり、これを選択することで、該当するメ
ソッドのデータ遷移図が確認できる。メソッドの活性区

2.2. 構造

間から伸びる青い矢印はメソッド呼び出しを、赤い矢印
はメソッドの処理の終了を示す。

図 2 に、TFVIS の構造を示す。TFVIS は、解析部とTFVIS のもう 1 つの機能として、よる変数同士の関可視化部から成る。また、解析部は、構造解析部、プロー

29

SEA

ソフトウェア・シンポジウム2017 in 宮崎

3.1. 各部の拡張点
Try Catch 文への対応のために行った拡張は、以下のとおりである。
• 構造解析部の新たなイベント種別の値の定義• プローブファイル生成部の Try Catch 文に対する新たなプローブの定義• プローブファイル生成部の Try Catch 文に対するプローブの挿入• 可視化部の Try Catch 文のイベントに対する可視化

図 2. TFVIS の構造

各拡張の詳細について、以下で述べる。
ブファイル生成部、動的解析部から成る。
構造解析部では、プログラムの構造の解析を行い、解3.1.1

析結果を構造情報としてファイルに出力する。構造情報
は、プローブファイル生成部でのプローブ挿入箇所の判

構造解析部の新たなイベント種別の値の定義

構造解析部において、Try Catch 文に対し出力するイ

断と、可視化部での図表の作成に用いる。構造解析部にベント種別の値を新たに定義する。

よって、ソースコードの各行で起こるイベントを取得す

新たに定義したイベント種別の値は、Try ブロック開る。イベントとは、可視化の基準となる特定の処理であ始の値 (380)、Try ブロック終了の値 (382)、Catch ブ

り、各イベントはイベント種別の値を持つ。

ロック開始の値 (390)、Catch ブロック終了の値 (392) でプローブファイル生成部では、構造情報を基に、対象ある。

ソースコードにプローブを埋め込んだプローブファイルを生成する。プローブは、プログラム実行時の挙動の情報を出力する。なお、プローブにはいくつか種類があり、3.1.2

各コードで起きるイベントごとに挿入するプローブが変プローブファイル生成部の Try Catch 文に対する新たなプローブの定義

わる。
動的解析部は、プローブファイルから、実行時の挙動

プローブファイル生成部において、Try Catch 文のイを解析し、解析結果を実行情報として出力する。具体的

ベントに対して挿入するプローブを新たに定義する。

には、ソースコードにプローブを挿入したプローブファ
イルをコンパイルし実行することで、プローブが出力す

Try ブロックのイベント用のプローブを、Try 処理検
出プローブとする。このプローブは、実行時のインスる実行情報を取得し、実行情報をファイルに出力する。

タンスの ID、メソッド ID、メソッド実行番号、行番号

可視化部は、解析部が出力する構造情報と実行情報をを引数とする。そして、可視化で用いる Try イベント

基に、可視化を行う。

ID(380)、インスタンス ID、メソッド ID、メソッド実行
番号、行番号を、実行情報ファイルに出力する。

3. TFVIS の拡張

同様に、Catch ブロックのイベント用のプローブを、
Catch 処理検出プローブとする。このプローブは、実行時

本章では、Try Catch 文への対応のために行った拡張のインスタンスの ID、メソッド ID、メソッド実行番号、について述べる。初めに、対応のために行った各部の拡

行番号を引数とする。そして、可視化で用いる Catch イ

張について述べる。次に、改良後の TFVIS のデータのベント ID(390)、インスタンス ID、メソッド ID、メソッ

流れについて述べる。

ド実行番号、行番号を、実行情報ファイルに出力する。

30

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 4. 可視化の流れ

また、例外処理の発生箇所と実行箇所を結ぶ赤色の矢印を記述する。

図 3. 解析部のデータの流れ

3.2. 改良後のデータの流れ
3.1.3

プローブファイル生成部の Try Catch 文に対拡張後の TFVIS の解析部と可視化部における、詳細するプローブの挿入

なデータの流れについて、以下で述べる。
プローブファイル生成部において、Try Catch 文のイ
ベントに応じて新たに定義したプローブを挿入する。

3.2.1

Try ブロック開始のイベントを読み込んだ場合、Try
ブロック開始から Try ブロック終了までの全ての行の解析部のデータの流れ

図 3 に、拡張後の TFVIS に、Try Catch 文を含むプ
ログラムを適用した際のデータの流れを示す。

直前に、Try 処理検出プローブを挿入する。このときプローブが得る行番号の値は、直後の行の行番号である。

初めに、構造解析部の拡張によって、Try Catch 文に

また、Catch ブロック開始のイベントを読み込んだ場合、ついてのイベントを取得する。図 3 から、構造情報ファ直後の行に Catch 処理検出プローブを挿入する。

イルが Try ブロック開始の値 (380)、Try ブロック終了の値 (382)、Catch ブロック開始の値 (390)、Catch ブロッループ中に Catch ブロックを実行する場合、ループ

ク終了の値 (392) を持っていることが分かる。

から抜ける処理が存在する。このような処理に対応するため、メソッド開始の行の直後に、ループ中かどうか

次に、構造解析部で取得した Try Catch 文についてを示す boolean 型の変 “isLoop”の定義を挿入する。そのイベントによって、プローブファイル生成部が新たにして、ループ中であれば、“isLoop” が true になるよう定義したプローブを挿入する。図 3 から、Try ブロックに変更を行った。また、Catch ブロック終了の行の直前の全ての行の直前に Try 処理検出プローブを、Catch ブに、”isLoop” が true であれば、既存のループ周回検出

ロック開始の行の直後に Catch 処理検出プローブを挿入

プローブとループ処理終了検出プローブを実行する if 文

していることが分かる。また、ループ中であれば、ルーを挿入する。

プ周回検出プローブとループ処理終了検出プローブを実行する if 文を挿入していることもわかる。
最後に、プローブを埋め込んだプローブファイルを動

3.1.4

的解析部で実行することで、実行情報を取得する。

可視化部の Try Catch 文のイベントに対する
可視化

3.2.2

例外処理のイベントの発生に対し、データ遷移図の直前の実行の箇所に赤色で “Catch”と記述したボックスを

可視化部の流れ図 4 に、拡張後の TFVIS に、Try Catch 文を含むプ配置する。

ログラムを適用した際の可視化の流れを示す。

31

SEA

ソフトウェア・シンポジウム2017 in 宮崎

今回作成した在庫は 3 つのみのため、3 つの在庫のインスタンスを生成し、リストに格納した。このときユーザが「ID」を 3 と入力したと仮定すると、リストの 4 番目を参照したことになり、「IndexOutOfBoundsException」という例外が発生する。図 6 から、リストを参照する行に“Catch”のボックスと、このボックスから、発生した例
外処理の行までの赤色の矢印を表示しており、データ遷移図で例外処理の発生を正しく可視化していることが分かる。

4.2. 最大、最小、平均値を計算するプログラム
図 6 に、「与えられた数の最小、最大、平均値を計算するプログラム」において、TryCatch 文を含む getAve メ

図 5. SearchInfo メソッドの可視化

ソッドを可視化したデータ遷移図を示す。このメソッド
は、与えられた数の平均値を計算するメソッドである。

構造情報に基づき、実行フロー図とデータ遷移図上

今回の適用例では、このメソッドに故意に例外が発生のソースコードを描画する。また、実行情報に基づき、する処理を記述し、例外処理内の処理でデータ遷移線がデータ遷移図を描画する。

機能するか確認を行った。今回基点として選択した更新

可視化部が Catch イベント ID を含む実行情報を読み値は、getAve メソッド内のループ処理の 5 回目のループ

込んだ場合、可視化部は Catch イベントの行を例外処理で更新された変数「sum」の「16」という値である。こ

実行箇所として、その直前の実行の行を例外処理発生箇の「sum」は、「sum+=values[i]」という式からから計所として保持する。そして、例外処理実行箇所に赤色で算される値である。この更新値の算出に用いた「sum」、“Catch”と記述したボックスを、例外処理発生箇所から「values[i]」、「i」を生成した箇所をそれぞれ赤色の矢印

例外処理実行箇所まで赤色の矢印を描画する。

で描画している。このことから、例外処理を含むプログ
ラムにおいても正しくデータ遷移線が機能していること

4. 適用例が分かる。

本章では、3 章で説明した TFVIS の拡張によって、

5. 考察

Try Catch 文を含むプログラムが、正しく可視化できることを確認する。適用例として、Java で記述した「在庫

本稿では、未対応の制御構造の 1 つである、例外処理

管理プログラム」を適用し、例外処理を正しく可視化すを含むプログラムへの適用を目的とした拡張を行った。

ることを示す。また、「与えられた数の最小、最大、平具体的には、Try Catch 文を含むプログラムを可視化で均値を計算するプログラム」を適用し、TryCatch 文をきるように拡張を行った。本章では、初めに TFVIS の含むプログラムの可視化において、データ遷移線が正し拡張の評価を述べる。次に、関連研究について述べる。

く機能することを示す。

最後に、TFVIS の課題について述べる。

4.1. 在庫管理プログラム

5.1. 評価

図 5 に、「在庫管理プログラム」において、Try Catch

既存の TFVIS では、Try Catch 文を含むプログラム

文を含む SearchInfo メソッドを可視化したデータ遷移を適用した場合、コンパイルエラーが発生し、可視化を図を示す。このメソッドは、「ID」を入力として、その行うことができなかった。

「ID」を持つ在庫の「ID」と「名前」、「在庫数」、「単価」

Try Catch 文を含むプログラムを可視化するため、初を表示するメソッドである。

めに、構造解析部において、Try Catch 文に対して新た

32

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 6. getAve メソッドの可視化に定義したイベント種別の値を用いることでイベントをブレークポイントは、最も多用されているデバッグ

取得する拡張を行った。

支援手法の 1 つである [7]。ブレークポイントを用次に、プローブファイル生成部において、Try Catch

いたデバッグでは、プログラムの実行を任意の箇所

文についてのイベントに対して、新たに定義した Try

で停止し、停止した時点での各変数の値など、プロCatch 文の実行時の情報を出力するプローブを挿入する
拡張を行った。

グラムの実行状況を確認することができる。
ブレークポイントデバッグには、ブレークポイント

最後に、可視化部において、Catch イベントに対して、を設置する箇所の選定が難しいという問題点が存在

直前の実行に赤色で “Catch”と記述したボックスを描画する。プログラムの欠陥を特定するのに適当な設置し、例外処理の発生箇所と実行箇所を結ぶ赤色の矢印を箇所を選定するためには、ユーザの知識と経験が必描画する拡張を行った。

要である [7]。

以上の拡張から、既存の TFVIS では可視化できなかっこれに対して TFVIS は、ユーザが欲する情報を保た Try Catch 文を含むプログラムを、拡張後の TFVIS

持するメソッドを選択するだけで必要な情報を得るは可視化できる。また、Try Catch 文を含むプログラム

ことができ、ユーザの能力に依存せずに使用できるで、既存のデータ遷移線が機能することも確認できた。

という点で優れていると言える。

このことから、Try Catch 文への対応により、TFVIS の

さらに、TFVIS による可視化では、メソッドやプロ

実用性が向上したと言える。

グラム全体の流れを俯瞰することができる。また、
データ遷移線を活用することで、変数同士の依存関

5.2. 関連研究係を把握することができる。これらの機能から、ブレークポイントによるデバッグに比べ、ある変数が以下に、TFVIS と関連研究との比較を述べる。

どのような経緯で作られたのか調べることができ• ブレークポイントデバッグる、という点で優っていると言える。

33

SEA

ソフトウェア・シンポジウム2017 in 宮崎• JIVE

まなければならず、1 回の可視化を行うのに、2 分程度の時間がかかってしまう。

JIVE[8] (Java Interactive Visualization Environment) は、Java プログラムの実行を可視化するツー• 入力待ち状態の発生を含むプログラムへの対応

ルである。

JIVE は、実行時の処理から UML のオブジェクト
図とシーケンス図を生成する機能を持つ。また、クTFVIS はユーザからの入力を受け取る機能を持たない。そのため、入力待ち状態の発生を含むプログ
ラムを適用した場合、解析部の実行が終了せず、実エリーによる問い合わせに対応しており、例えば、

行情報を得ることができない。

「メソッド “func”が返り値に NULL を返すのはどこ• 問い合わせ機能の実装

か」といった問い合わせが可能である。問い合わせで発見した処理は、シーケンス図上でハイライトさ

TFVIS は問い合わせ機能を持たない。この問題はれ、プログラム実行時の挙動把握を支援する。

可視化対象のプログラムの処理が増加するほど、大JIVE と TFVIS を比較した場合、JIVE には、デー
タ遷移のような変数同士の依存関係を示す機能はな

きな手間となる。そのため、問い合わせ機能を実装する必要があると考えている。

い。変数更新の問い合わせが可能であるが、データ• マルチスレッドプログラムへの対応

遷移のような依存関係を調べる場合には、繰り返し

TFVIS はマルチスレッドプログラムを可視化でき問い合わせを行う必要がある。そのため、不審な値ない。マルチスレッドプログラムでは、スレッド間を見つけた際に、その原因を探るといった作業には、でデータのやり取りが行われるため、処理が複雑に

TFVIS がより効果的であると言える。

なりやすい。もし、マルチスレッドによる複雑な処理を可視化できれば、TFVIS の有用性がより高ま• Code Canvas

ると言える。

Code Canvas[9] は、IDE である Visual Studio のズーム可能なサーフェスである。Code Canvas には、スタックトレースから例外発生箇所とメソッド

以上の課題のうち、レスポンスが遅いという問題点について詳しく述べる。上記で述べたように、TFVIS が呼び出し関係を、複数のソースコードにわたって赤可視化を行うためには、読み込む対象のプログラムが終い矢印で描画する機能を持つ。

了するまで待たなければならない。また、可視化を行う

TFVIS と比較した場合、Code Canvas は例外処理ためには、いくつかの手順を踏まなければならず、1 回の呼び出し関係の把握をスタックトレースを可視化の可視化を行うのに、コードの大きさに関わらず 2 分のすることで支援するが、例外発生箇所の変数の値や時間がかかってしまう。これは、プログラムを任意の点処理の流れなどは調査できない。TFVIS による可で停止し、実行状況を把握できるブレークポイントに比視化では、例外発生箇所に不審な値がある可能性がべ、レスポンスが遅いと言える。

高いため、そこからデータ遷移を辿っていくことでしかし、関連研究でも述べたように、TFVIS による

効率よく欠陥を特定できる。この点で、TFVIS に

可視化には、メソッドやプログラム全体の流れを俯瞰でよる例外処理の可視化は有用であると言える。

きる、データ遷移線を活用することで変数同士の依存関係を把握できるといった強みが存在する。

5.3. 今後の課題

そこで、ブレークポイントデバッグを支援するツールとして TFVIS の改良を行う。具体的には、Java 言語の

以下に、TFVIS の課題について述べる。

IDE として広く使われており、プラグインの開発が可能な Rclipse[10] のブレークポイント機能と連携を行う。ブ• レスポンスの遅さ

レークポイントで停止した時点で、その時点までの実行

TFVIS が可視化を行うためには、読み込む対象のフロー図やデータ遷移図を TFVIS で表示することで、プログラムが終了するまで待たなければならない。

TFVIS のレスポンスの問題とブレークポイントデバッ
グの処理の流れの把握が困難であるという問題点を解決

また、可視化を行うためには、いくつかの手順を踏

34

SEA

ソフトウェア・シンポジウム2017 in 宮崎

できるのではないかと考える。さらに、ブレークポイン[2] Roger S. Pressman: Software Engineering A Practitioner’s Approach, McGraw-Hill Science (2001).

ト機能と合わせて、データ遷移線による変数同士の依存関係を確認することで、より効率的な欠陥の特定が可能[3] Jonathan Sillito, Gail C. Murphy, and Kris De
Volder: Asking and Answering Questions During
a Programming Change Task, IEEE Transactionsになると考える。
以上の点から、TFVIS の今後の展望として、eclipse
プラグインとして改良を行い、ブレークポイント機能とon Software Engineering, Vol.34, No.4, pp.434-451(2008).

連携することで、ブレークポイントデバッグを支援する
ツールを目指す。

[4] Andreas Zeller, (訳: 中田秀基, 今田昌宏, 大岩尚宏,

6. おわりに

竹田香苗, 宮原久美子, 宗形紗織): デバッグの理論と実践-なぜプログラムはうまく動かないのか, オライ

本稿では、未対応の制御構造の 1 つである、例外処理

リー・ジャパン (2012).

を含む Java プログラムを対象とした適用範囲の拡大を[5] Hiroto Nakamura, Tetsuro Katayama, Yoshihiro
Kita, Hisaaki Yamaba, Kentaro Aburada and行った。TFVIS は、プログラム実行時の挙動を、データ遷移可視化と実行フロー可視化によってユーザに示す。

Naonobu Okazaki: TFVIS: a Supporting Debugging Tool for Java Programs by Visualizing Data

TFVIS の可視化により、欠陥を含んだプログラムの実
行時の挙動把握が容易になり、欠陥を効率的に特定できるようになる。また、データ遷移線の機能から、データ

Transitions and Execution Flows, The 2015 International Conference on Artificial Life and Robotics,
pp.376-379 (2015).

遷移を辿ることができ、不具合から欠陥の特定を支援することができる。
しかし、既存の TFVIS では可視化できないプログラ[6] Dan Pilone, Neil Pitman, (訳: 原 隆文): UML2.0 ク
イックリファレンス, オライリー・ジャパン (2006).

ムが存在する。Java プログラムが持つ基本的な構文を含むプログラムが可視化できないことは有用性に欠ける[7] Cheng Zhang, Juyuan Yang, Dacong Yan,
Shengqian Yang and Yuting Chen: AutomatedBreakpoint Generation for Debugging, Journal of

ことを意味している。
そこで本稿では、Try Catch 文を含む Java プログラムを対象とした、TFVIS の適用範囲の拡大を行った。今Software, Vol.8, No.3, pp.603-616 (2013).

回の拡張により、TFVIS の Java プログラム可視化ツールとしての有用性が向上したと言える。

[8] Demian Lessa, Bharat Jayaraman and Czyz Jeﬀrey:

今後の課題を以下に示す。

JIVE: A Pedagogic Tool for Visualizing the Execution of Java Programs. Technical Report 2010-13,
Department of Computer Science and Engineering,• レスポンスの遅さ• 入力待ち状態の発生を含むプログラムへの対応

University at Buﬀalo (2010).

• 問い合わせ機能の実装[9] R. DeLine and K. Rowan: Code Canvas: Zooming
towards better development environments, in Proc.
of the 32nd International Conference on Software
Engineering, Vol.2, pp.207-210 (2010).

• マルチスレッドプログラムへの対応

参考文献[10] Eclipse Foundation: Eclipse - The Eclipse Foundation open source community website., https:[1] Thomas D. LaToza, Gina Venolia, and Robert DeLine: Maintaining mental models: a study of developer work habits, Proceedings of the 28th interna-//eclipse.org/

tional conference on Software engineering, pp.492501 (2006).

35

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Data Race Detection Based on Dependence Analysis
Guanqun Wang
Hitachi Automotive Systems, Ltd.
guanqun.wang.ju@hitachi-automotive.co.jp
Masahiro Matsubara
Hitachi Automotive Systems, Ltd.
masahiro.matsubara.td@hitachi-automotive.co.jp

Abstract
Concurrency issues have been a serious problem in
the whole software industry. They very often lead to
hard-to-reproduce bugs and thus are very difficult tolocate and solve. In this paper, we introduce a novel
method for detection of one major category of concurrency problems, data race. This method extracts a
Variable Dependence Tree from source code and finds
data race by analysis on the Variable Dependence Tree.
A prototype is built in Java according to the proposed
method and tested on production-level source code (Clanguage) with more than 400k LLOC. As a result, theprototype tool successfully detected all known data races
including one relying on redundant structure of software and proved the effectiveness and feasibility of our
proposed method.

1. Introduction
With the rapid growing complexity of software systems, concurrency issue has been an prevailing problem in software industry, which has drawn a lot of attentions. Since concurrency issues can easily lead to
hard-to-reproduce bugs which take a long time to locate and fix, they are one of the most urgent problems
to solve for cost control. According to a survey of Microsoft in 2007[1], over 60% of 684 software engineers
had to deal with concurrency issues on a monthly basis. Concurrency bugs usually takes several days to detect and debug, and thus most of 684 engineers would
welcome additional help on solving concurrency issues.
Another survey also showed that about 73% of the examined non-deadlock concurrency bugs were not fixedby simply adding or changing locks, and many of thefixes were not correct at the first try[2], which implies

the difficulties and costs software engineers face duringsolving non-deadlock concurrency problems.
In this paper, we will focus on data race, one maincategory of non-deadlock concurrency problem. Data
race only happens in some certain program states,
which makes its localization and fix very expensive inindustrial practice because there are too many statesin a real product’s program to check one by one. To
solve this problem, we propose a novel static methodfor data race detection based on dependence analysis.
While a lot of existing static methods suffer from false
positives, the proposed method theoretically has few
false positives. By focusing on the dependence among
data accesses instead of data accesses only, the proposed method can more effectively exclude program
states (each corresponds to a combination of data accesses) that are irrelevant to data races so that the false
positive rate can be kept in a manageable range. Regarding the target of detection, we choose source code,
the relatively downstream output of software development. The main reason is that considering the factthat data races can be introduced into the program inboth design and implementation, we want the proposed
method to cover different phases of software development as much as possible.
In the rest part of this paper, Section 2 gives a clear
definition of data race. Section 3 introduces some related work on data race detection. Section 4 describes
the proposed method for data race detection. Section
5 shows a prototype tool we built based on the method
introduced in Section 4. Section 6 describes the how
the proposed method is evaluated with productionlevel source code. Section 7 discusses about the proposed method based on the evaluation. Section 8 gives
a conclusion.

36

SEA

ソフトウェア・シンポジウム2017 in 宮崎

2. Data Race
Data race has been an important research topic since
1990s[3]. One widely used definition is:definition 1. When multiple threads1 that concurrently run without any synchronization access the same
location of memory, and at least one access is write,
data race occurs.
In this definition, we can see data race is a bug due
to unsynchronized threads concurrently accessing thesame memory. Such data access will lead to undefined
behavior, and the actual ordering of accesses on theshared memory is unknown because it is not specified
by source code. This unknown ordering may finallylead to unintended output. However, there is still arisk of bug when synchronized threads concurrently accessing the same memory. An improper synchronization can also lead to unexpected execution orderings ofthreads, which makes the final program output unintended. In fact, according to one characteristic studyof concurrency bugs, around one third of the examined
non-deadlock concurrency bugs are caused by violation to programmers’ order intentions, which may not
be easily expressed via synchronization primitives likelocks and transactional memories[2]. Because both improper synchronization and unsynchronization can leadto an unintended thread execution ordering which finally leads to an unintended program output, we think
it is reasonable to treat improper synchronizations thesame as non-synchronization in data race detection.
Therefore, “without any synchronization” is actuallyinterpreted as “without any proper synchronization”
in this paper.
One typical case of data race is shown in Figure 1.
Thread A and thread B execute concurrently. One calculation in thread B depends on two readings of variable V ar, which is updated in thread A. If the synchronization of thread A and B is improper or does
not exist at all, it is possible for thread A to update
V ar right between two read accesses of thread B, which
may finally lead to an incorrect program output.
There is another concept called race condition. Although race condition is used interchangeably withdata race in some researches, it is more often considered as a more general concept. In this paper, we adopt
the more general definition as follows,
1 Thread, task and interrupt service routine (ISR) are usedinterchangeably to represent the general unit of concurrency. It istrue that different operation systems or programming languages
may have different names for the unit of concurrency, but we are
only interested in the general concurrency issues in this paper.

Figure 1. Data race on single variable

definition 2. When the correctness of a program’s output is affected by the potential nondeterminism in timing or ordering of threads’ execution, race condition
occurs.
One interesting case is shown in Figure 2. Unlike
the case in Figure 1, this race problem happens on two
variables instead of one. More specifically, the two variables, V ar1 and V ar2 are actually a redundant variable
pair, which means V ar1 and V ar2 stands for exactly
the same thing, and they both exist due to the redundant structure of software which is applied in a lot of
critical systems for safety concerns. Thread B reads
V ar1 and V ar2, then compares their value to check if
there is a malfunction in the system. Thread A runs
concurrently with Thread B and updates both V ar1
and V ar2. If Thread A updates the values of V ar1
and V ar2 when Thread B already read V ar1 but have
not read V ar2 yet, the comparison result of V ar1 andV ar2 may be wrong and finally lead to a system failure. This kind of race problem actually happen during
development and is sometimes even more difficult tofind and fix.
According to definition 1 and definition 2, the racerelated problem shown in Figure 2 is actually a race
condition instead of data race because Thread A and
B are not accessing the same location of memory. However, this problem has almost the same mechanism
as data race except there are two variables involved.
Therefore, we think it is reasonable to improve definition 1 by changing “the same location of memory”
to “memory storing the same information”, which will
make definition 1 generalize similar problems better. In
the rest of this paper, we will use definition 3 insteadof definition 1 for data race and consider the problem
shown in Figure 2 as a data race.

37

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Figure 2. Data race on a redundant variable pairdefinition 3. When multiple threads that concurrently
run without any synchronization access memory storing the same information, and at least one access iswrite, data race occurs.
Without introducing definition 3, it is also possible
to consider a race on a redundant variable pair as a
combination of two data races, each of which includes
exactly one write access and one read access of one
variable, but we chose not to do so due to reduce false
positives (details can be found in the 5th paragraph of
Section 4.2).

3. Related Work
There are many researches done to solve the data
race. The simplest method is Mutual Exclusion Locking discipline, which requires a lock be held on every
access to a shared variable. Appropriate use of mutual exclusion locks can eliminate atomicity violationsof any data, therefore prevent data races. Another simple method is to use buffer for shared variables, whichallows a program to has a copy of certain variable atcertain time and can use it at any time necessary. However, when we have a extremely large concurrent program, both methods lead to a very high maintenancecost. In addition, for programs of systems with limited
resources (e.g. automotive control systems), it is notpractical to use mutual exclusion locks or buffer for all
variable shared between threads.
Type System can be used to prevent data race.
The basic idea is to make a programming languagethat cannot realize data race. A lot of early researches
on such type systems use locking discipline while someother ideas for the type system construction have also
emerged. Recent work can be found in [4][5]. The
main problem in type-based solution is the high costof switching to a new language and the expression limitations in the current race-free languages.
Dynamic Analysis analyzes the runtime behavior of program to find potential data race. Most dynamic race detection tools do lockset-based analysis[6]or happens-before analysis[7] or both[8]. Current dynamic methods for data race detection usually sufferfrom two main problems. One is that such methods usually require instrumentation in the source code,
which can dramatically increase the development costsometimes. The other problem is that dynamic method
can only find data race in the execution paths taken in
the detection because the whole analysis is based on
runtime behaviors. This makes dynamic detection unpractical for critical systems that run for a long time.
For some programs with much longer runtime than thetesting time (e.g. one automotive control program canrun for thousands of hours in millions of cars), it ismuch more likely that a data race appearing in actual
execution was missed in dynamic testing.
Static Analysis is used for race detection as well.
Static method is usually very flexible, therefore theperformance varies from one to the other. Among
all static methods, some recent flow-sensitive methods showed potentials for industrial use because they
have a combination of soundness and completeness.
RacerX[9] is one good example. It intentionally sacrificed some soundness for better completeness (fewer
false positives) by applying several heuristics in the detection. When elimination of false negative is not required, false positives can be controlled to a low levelwith this method. Inamori and Yamada proposed astatic method for detection of data race caused by improper use of interrupts in automotive systems [10]. It
searches for a data access pattern which ensures there
is no false negative, and runs several checks to reduce
false positives. In the target data access pattern, tworead accesses with low priority and one write accesswith high priority happen on the same variable concurrently. Since this method uses model checking toeliminate false positives in the end, it suffers from thestate explosion problem, which makes this method not
feasible for large programs.
Model Checking is a method that can find all data
race including those hard-to-reproduce ones. Unlike
dynamic methods, model checking is able to explore
all theoretically possible execution paths by analyze
a model of the program instead of the program itself. However, model checking suffers from the state
explosion problem. When the size of target programis very large, there are too many possible execution
paths to check, which takes a lot of time and memory.
In our previous work, we tried to apply a program slic-

38

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ing before model checking to solve the state explosion
problem[11]. For some complex programs, the state
explosion still appears after slicing, so we also trieda divide and conquer strategy (divided the problem
into small parts, do model checking for each and theinterfaces between them). This strategy was proved
effective, but another question comes up as how to determine which part to check first. When we know there
is a bug, it will be possible to find it earlier if we cancheck the part that is most likely to contain bugs at
first. However, this requires some techniques of bug
prediction or vulnerability analysis.

4. Detection Method
In this section, we propose a novel method for data
race detection based on dependence analysis, which
statically analyze source code and point out data racein one part of the code that the user is most interested in. The proposed method is consisted of two
main steps. The first step is extraction of variable dependence tree, and the second one is race search.
4.1. Extraction of Variable Dependence Tree
The first step of our proposed method, extractionof Variable Dependence Tree, is a technique originallyused for program slicing, which was introduced in ourprevious work[11]. Program slicing is a popular technique used for locating bugs in large programs. This
technique allows the user to focus on the code of interest, which can be the code that is most likely tohave bugs, or code related with some observed malfunction. Specifically, it means to take a slice of the
program containing all statements that may affect a
specific variable at a specific point in the program. It
was originally proposed by Weiser [12] and have beenquite a hot topic in researches since then[13].
In our proposed method, instead of taking a slice ofprogram related to one variable the user is interested
in, we take a slice of variable dependence related to one
specific variable the user is interested in and represent
it in a tree called Variable Dependence Tree (VDT).
Although in [11], VDT is ultimately used for program
slicing, the actual program slicing is not necessary fordata race detection in this paper because the detection is purely an analysis on VDT. In the rest part ofthis subsection, we will briefly introduce the concept of
VDT and several other concepts it is built on.
The study on dependence representation of program
is not a new research field. In 1987, Program Dependence Graph (PDG) was first introduced by Ferrante,
Ottenstein and Warren to make explicit both the dataand control dependences for each operation in a program. Specifically, PDG is a directed graph. In thisgraph, nodes are statements and predicates; edges incident to a node represent both the data values on
which the node’s operations depend and the control
conditions on which the execution of the operations
depends[14]. Based on PDG, Horwitz, Reps and Binkley proposed System Dependence Graph (SDG) for interprocedural slicing[15]. SDG extends PDG to incorporate sets of procedures rather than just monolithic
programs and can be considered as a set of PDGs.
Variable Dependence Graph (VDG)[11] is a concept
we developed based on concurrent version of SDG.
VDG is a graph derived from SDG in which each node
no longer represents a statement. A node in VDG
represents a variable or a constant in a specific statement with a specific execution path or a specific control
statement (e.g. if statement, while statement) with a
specific execution path. For example, the same variableappearing in two different statements is represented by
two nodes (one for each statement). The same variablein the same statement that has two possible execution
paths is also represented by two nodes (one for each
execution path). The label of each node is the nameof the variable or the control statement this node represents. Besides the name shown in label, each nodealso carries trace information of the variable or control
statement it represents. An edge in VDG represents
data dependence or control dependence between two
nodes. The method to extract a VDG from a programis discussed in [11].
Variable Dependence Tree (VDT) is a VDG pruned
into a tree. There are two types of VDT, Goal VDTand Start VDT. We will only use Goal VDT in thispaper. A goal VDT is a directed tree T (V, E) rooted
at node s, where V is the set of nodes, and E is theset of edges. The set of children of node v is denotedby C(v). ∀v ∈ V depends on ∀c ∈ C(v). The edge
between node v and its child c ∈ C(v) points from c tov.
Since the transformation from VDG to VDT is already introduced in [11], we will only briefly describe
the basic idea about it in this paper. To prune a VDG
into a VDT, we search for nodes depending on the samenode in VDG. The set of nodes depending on an arbitrary node x is denoted by D. For all edges pointing from x to d ∈ D except the leftmost one, remove
the edge, and add a new leaf node x0i as the child ofd ∈ D. The new leaf node x0i means that the dependence from x has already appeared elsewhere in thistree and therefore can be ignored, where the subscript
i is just an index to prevent redundant node labels. A
simple example is shown in Figure 3 and Figure 4. Fig-

39

SEA

ソフトウェア・シンポジウム2017 in 宮崎

S

S

A

B

C

D

E

F

G

A

B

V ar

V ar

V ar

E

E10

V ar

Figure 3. VDG extracted from variable S
F
S

I

B

D10

D

F

H

Figure 5. The pattern of data race candidate

A

C

G

E

G

Figure 4. VDT transformed from VDG in Figure 3
ure 3 shows a VDG extracted from variable S, where
all nodes represents variables. As we can see, node A
and node B both depends on node D. To prune thisVDG into VDT, we keep the leftmost edge (A, D) andremove edge (B, D). Then we add a new leaf node
D10 as a child of variable B. In this way, the VDG in
Figure 3 is pruned into the VDT in Figure 4. Whenthe resources (e.g. time, memory) is limited, a partial
extraction of VDT is also possible, which is introducedin [11].
By adopting VDT, we are able to eliminate all artificial orderings in the program and make potential
parallelism explicit. Since variables are represented as
nodes, it is more efficient to use VDT to detect data
race happening on specific variable(s). In the real-life
application, it is usually efficient and effective to extract a VDT from a certain error flag or output variable
the user is interested in. If the user does not have information about such a variable and just wants to reach afull coverage of the dependence in the program, which
is not recommended because of the efficiency concerns,
the user can extract a VDT from each final output ofthe program.
4.2. Race Search
In the algorithm of race search, a concept called interference dependence is used. The early definition andapplication of interference dependence can be found in
Krinke’s work[16]. According to Krinke, interference
dependence occurs when a variable is defined in one
thread and used in a parallel executing thread. Specifically, in a VDT, if an edge connects two nodes withdifferent thread information, this edge represents aninterference dependence. In [17], Krinke also showed
how to analyze interference dependence efficiently.
In our proposed method, we find data race candidates based on dependence analysis. Specifically, if
multiple threads affects the memory storing the same
information, this situation is considered as a data race
candidate. Then data races are extracted by filtering
these candidates through priority and reality checks.
After adopting the concept of VDT and interference
dependence, the situation considered as data race candidate can be interpreted to “In a VDT, 1 there are
multiple interference dependences, 2 variable(s) storing the same information appear on the descendant sideof each interference dependences.” Figure 5 shows anexample of such situation in VDT. There are two interference dependences (drawn as dotted arrows), whichmeans the value of S is affected by multiple threads.
Variable V ar appears on the descendant side (bottomside in the tree) of each interference dependence, whichmeans that value of S depends on two readings of V arwhile these two readings are obtained in a thread different from where S is defined. When the thread where
S is defined and the thread(s) where two readings ofV ar are done execute concurrently, the value of S may
be different for a different execution ordering, thus anunintended value becomes possible, which is exactly
the data access problem we showed in Figure 1. The
details on priority and reality checks will be introduced
later in this section.
It is important to notice that the variables storing
the same information on the descendant side of interfer-

40

SEA

ソフトウェア・シンポジウム2017 in 宮崎

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

int x1 , x2 , a , b , c ;int DI0 ;int e r r f l g ;void main ( void ) {x1=a +1;
x2=b+1;i f ( x1 != x2 ) {e r r f l g =1;}}
void c a l c ( void ) {c=DI0 ;
a=c ∗ 2 ;b=c+c ;
}

Start
Input
Extract Variable Groups
Pick A GroupnoInterference For
All Variables?
yes

Figure 6. Sample code for data race due to indirect
influences of data access

Reality Check

fail

pass
ence dependence (V ar in the case of Figure 5) are notnecessarily the same variable, they can also be a redundant variable pair (two variables storing the same information because of redundant structure), which corresponds to the case in Figure 2. Of course, in order torecognize redundant variable pairs, the user has to collect additional information about redundant variables
before data race detection. Fortunately, such information can usually be extracted from design documents.
One interesting fact is that even when the user cannot recognize redundant variable pairs, the data race
on redundant variable pairs can still be partially detected. For the case shown in Figure 2, it is possiblethat V ar1 and V ar2 finally depend on the same variable in VDT. For instance, this variable can be some
raw sensor data, and V ar1 and V ar2 are calculated
based on it by different calculation methods. We did
not confirm if such case actually exist in evaluation,
but it is theoretically possible. Figure 6 shows a sample
code of this case. Main() and calc() are two functions
running concurrently. a and b are redundant variables
used to calculate x1 and x2 respectively in main(). If
x1 and x2 are not equal, an error flag is triggered. In
calc(), a and b are calculated based on variable c (rawsensor data) with different methods. Indeed, data race
happens on the redundant variable pair a and b. However, the dependence on the same variable (variable cin the sample code) makes such data race no different
from those on single variable. Thus it can be successfully detected even when we do not recognize a and b asa redundant variable pair. Nevertheless, the information on redundant variable pairs is still helpful because
it makes the data race detectable at a higher level in
VDT.
When locating data race candidates as introduced

Priority Check

fail

pass
Recordyes
yes

Any Groups Left?
no
OutputStop

Figure 7. Flowchart of race risk search

above, a kind of data race is intentionally excluded in
detection. No matter in the typical definition of data
race (definition 1) or the extended definition (definition
3) used in this paper, data race happens when only two
concurrent accesses of the same variable exist, one ofwhich writes and the other reads. In fact, data race
on a redundant variable pair can also be considered
as a combination of two such “1 read & 1 write” data
races. However, all “1 read & 1 write” data races are
excluded in detection for a lower false positive rate.
In a large concurrent program such as an engine control program, it’s normal to see many such “1 read &1 write” data races, but they rarely cause real problems in practice since they are easy to find and fix byconventional methods.
The algorithm of potential race search is shown in
the flow chart in Figure 7. The input block takes a
VDT, information on thread execution priority as well

41

SEA

ソフトウェア・シンポジウム2017 in 宮崎

as redundant variable, and reality information as input.
Reality information refers to the information about if
some threads can run concurrently in reality. This
information can include synchronization information,
hardware limitations, limitations of the runtime environment and so on. Then “Extract Variable Groups”
process traverses the VDT to extract nodes representing access to the variable that store the same information and divides them into groups by variable (e.g.
V ar in Figure 5). After extracting variable groups,“Pick A Group” process randomly picks one group for
further analysis. Decision block “Interference For All
Variables?” checks the paths from picked nodes to aclosest common ancestor. If there are interference dependences in multiple paths, a data race candidate isfound and the algorithm goes to decision block “Reality
Check”. If not, the algorithm jumps to “Any Groups
Left?” block.
“Reality Check” and “Priority Check” block reduce
false positives by checking if the threads involved indata race candidates can actually run concurrently
without synchronizations during runtime. “Reality
Check” checks concurrent execution limitations thatare not determined in the program under test (e.g. external synchronizations, limitations of hardware platform or runtime environment). In a program with optimized resource consumption and complexity, it is normal that only some threads can run in a specific scenario and some threads can never do even if it is not
explicitly set in the program. For example, a thread
for situation when car speed is equal to 0 and a thread
for situation when car speed is higher than 100mph
can never run concurrently. “Priority Check” checks
the execution priority of threads involved in the data
race candidates. Given the OS or hardware platform
where the program runs, some threads are not allowed
to run concurrently due to execution priorities. For example, in a lot microcontrollers, threads with the samepriority are executed sequentially instead concurrently,
therefore there can never be data race between them.
It should be noticed that rules in both checks are flexible and should be adjusted based on the program under
test or the goal of testing.
When both checks pass, the algorithm will go to“Record” block. Otherwise, the algorithm jumps to“Any Groups Left?” block. “Record” block records
candidates that passed the checks as potential data
races. Decision block “Any Groups Left” checks if there
is any extracted variable group left. if there is any, thealgorithm goes back to “Pick A Group” block to pickup a new group and search for potential data race. If
not, the algorithm ends.

Figure 8. Overview of prototype tool

Figure 9. Screen capture of D-FORCE

5. Implementation
We built a prototype tool called D-FORCE in Javafor the proposed detection method introduced in Section 4. As shown in Figure 8, it takes inputs including
source code, redundant variable information, thread information (priority and entry point of each thread) andreality check information (which threads may run concurrently) to generate data race list. For an efficient
implementation, we assumed the target programs are
only written in C language without loss of generality.
One screen capture of the D-FORCE is shown in Figure 9. Since it is also used in our other researches, only
area A and B are used for data race detection. Area
A shows the extracted VDT, and area B is a sourcecode reference window, which shows the corresponding
source code of selected node in VDT so that the user
gets a visual confirmation of actual source code.
Figure 10 shows a sample source code. If we extract

42

SEA

ソフトウェア・シンポジウム2017 in 宮崎

a VDT from variable x, it will be visualized in area A
as shown in Figure 11. This is a standard result of thefirst step of our proposed method, extraction of VDT.
Each node has an icon followed by a label. The icon
shows data type. If the node represents a variable,
a green round icon with a “v” inside is shown, justlike the one before label “x (L:16@func)”. If the node
represents a constant, a gray icon with a “c” inside isshown, just like the one before label “2 (L:21@calc1)”.
If the node represents a control statement, a diamondshape icon is shown, just like the one before label “[if](L:12@func)”. If a node represents anything that already appeared somewhere else in the VDT (such as
the D10 in Figure 4), the icon is a yellow stop sign,
just like the one before “x1 (L21@calc1)”. Label gives
more details about the node. For example, label “x(L:16@func)” means the node represents variable x online 16 of function f unc. A label “[if] (L:12@func)”
means the node represents the if statement on line 12
of function f unc. When a variable node is at the write
side of an interference dependence, the variable icon ismarked with a red arrow and a “” mark is added tothe beginning of the label.
The result of potential race risk search on the VDTis also shown in Figure 4. At the root node, the“(risk=1)” shows that there is one potential data race
detected. A “=ic1=” mark is added at the beginningof the label “x (L:16@func)”, which indicates that thisvariable is the common ancestor related with the firstdetected data race. “=rd1=” and “=wo1=” indicatesthe corresponding variable are one side of the interference dependence related with the first detected data
race. When such a result is available, D-FORCE also
automatically generates a file with all formation aboutlocations of interference dependences and the common
ancestor, based on which the user can understand how
the potential data race can happen and trace back to
the exact problematic statements in the source code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

int a , b , c , x , x1 , x2 ;int DI0 ;unsigned char e r r f l g =0;
void c a l c 1 ( void ) ;void c a l c 2 ( void ) ;void i n p u t ( void ) ;void f u n c ( ) {calc1 ( ) ;calc2 ( ) ;i f ( x1 != c | | x2 != c ) {e r r f l g =1;}
else {
x=x1 ;}}
void c a l c 1 ( ) {x1=a ∗ 2 ;b=x1 ;}
void c a l c 2 ( ) {x2=a<<1;b=x2 ;}
void i n p u t ( ) {a=DI0 ;}

Figure 10. Sample source code

6. Evaluation
The feasibility of the proposed method in industrial
use is confirmed in our evaluation. We ran D-FORCEon obsolete version code of two different powertrain
ECUs (Electrical Control Unit) developed in Hitachi
Automotive Systems. 100% (4 out of 4) data races actually encountered during development were successfully detected while the number of false positives wasmaintained in a manageable range.
Both sets of source code are written in C and havemore than 400k LLOC (Logical Lines of Code). DFORCE was executed in Windows 7 running on a PC
with a Intel Core i7 870 CPU (2.93GHz) and 16GB

Figure 11. One example of VDT visualization in
D-FORCE

43

SEA

ソフトウェア・シンポジウム2017 in 宮崎

RAM. The whole analysis finished on both sets ofsource code within 15 minutes. Redundant variable information and thread information were obtained manually by reviewing design documents. Since we noticed that some false positives appeared in initialization threads, we manually excluded all initialization
threads during data race detection, which can essentially be considered as a kind of reality check.
Among 4 known data races, 3 of them have the samedata access pattern, which is exactly the typical caseshown in Figure 1. The other one is a data race ona redundant variable pair as shown in Figure 2. All 4
data races were confirmed as bugs leading to system
failure in previous development. According to our observation, false positives still exist, so a more accurate
measurement on completeness is necessary in the future work, after which we can decide the direction forfurther improvements of the proposed method.

7. Discussion
In the proposed method, we did not use synchronization information to find data race candidates because we wanted to detect data race due to both “nosynchronization” and “wrong synchronization”. Obviously, synchronization is partially used in the priority
check to reduce false positives, but there are still somesynchronization informations that can be helpful but
are currently not used. For instance, information oninterrupt disables are used in the work of Inamori and
Yamada[10] to reduce false positives while it is not usedin our method at all. Such underutilization of synchronization information has pointed out one possible
direction for us to further reduce false positives.
Dependence analysis in the proposed method allows
data race detection to focus on interference in dependence instead of accesses on certain variables. This
enables detection of data race resulted from indirect
influences of data access. The code in Figure 6 is also
an example for this feature. When variable c is updated in one thread, a concurrently running thread
does not necessarily have to read exactly variable cmultiple times to cause a data race. In the threadwhere c is updated, variable a and b are defined basedon c. A concurrently running thread can also cause adata race by reading a and b and using their values
together for some other calculation (a and b might becalculated from different c values). In this case, there
are at most two accesses on variables shared among
threads (a and b), so it is very hard to detect by conventional methods without generating many positives.
In our proposed method, this is not a problem due todependence analysis.

1
2
3
4
5
6
7
8
9

int a ;
void c a l c ( int ∗ pt ) ;void main ( void ) ;a =0;
c a l c (&a ) ;}void c a l c ( int ∗ pt ) {∗ pt=3 ;}Figure 12. Sample code for data access throughpointer
While a lot of data race detection methods have trouble analyzing program with pointers, dependence analysis in our proposed method helps to find out which
piece of memory is accessed when pointers are involvedin the data access. One example is the sample code in
Figure 12. Main() and calc() are two function thatrun concurrently. They actually access the same variable a, but the write access in calc() is done througha pointer passed to it. Since pointers are also included
the dependence analysis, it is very easy to figure out
the two threads are accessing the same variable a inour proposed method.
It is also important to notice that our proposed
method is naturally compatible with programs containing parallel threads even if we only mentioned concurrent threads so far. For the proposed method, the only
difference brought by parallel threads is that the data
accesses can not only be concurrent, but also simultaneous (physically at the same time). This difference
cannot affect how we identify data race candidates orthe correctness of checks applied to filter them, so the
proposed method can also detect data races in programwith parallel threads as long as we have information
about which threads run in parallel.
When a data race happens, the program’s output
may still be correct after certain processing in the program. Such situations are relatively rare, but still possible. The data race that does not affect the correctness of a program’s output is referred to as “benign
data race”[18]. Our proposed method cannot completely distinguish benign data race, which seems like aproblem. However, recent researches showed that it is
impossible to guarantee that a data race never affects
the correctness of a program as long as the compiler or
hardware can be changed[19]. Therefore, we chose toinclude “benign data race” in the detection results.

8. Conclusion
In this paper, we proposed a novel method for data
race detection based on dependence analysis. A pro-

44

SEA

ソフトウェア・シンポジウム2017 in 宮崎

totype tool is build in Java to realize the proposed
method. By running the prototype tool on productionlevel code of two real industrial products, the proposed
method proved to be feasible for data race detection inindustrial practice. However, more empirical validationis still necessary in the future. Besides the programs weused for evaluation in this paper, the proposed methodshould also be tested on more programs for a moreaccurate measurement of soundness and completeness,after which we may be able to make necessary improvements (e.g. further reducing false positives by a better
utilization of synchronization information such as interrupt disable and mutex).

References[1] P. Godefroid and N. Nagappan, “Concurrency at
microsoft: An exploratory survey,” in CAV Workshop on Exploiting Concurrency Efficiently andCorrectly, 2008.
[2] S. Lu, S. Park, E. Seo, and Y. Zhou, “Learning from mistakes: a comprehensive study on realworld concurrency bug characteristics,” in ACM
Sigplan Notices, vol. 43-3, pp. 329–339, ACM,
2008.
[3] R. H. Netzer and B. P. Miller, “What are race conditions?: Some issues and formalizations,” ACM
Letters on Programming Languages and Systems(LOPLAS), vol. 1, no. 1, pp. 74–88, 1992.
[4] E. Castegren and T. Wrigstad, “Reference capabilities for concurrency control,” in LIPIcsLeibniz International Proceedings in Informatics,
vol. 56, Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2016.
[5] C. S. Gordon, M. J. Parkinson, J. Parsons,A. Bromfield, and J. Duffy, “Uniqueness and reference immutability for safe parallelism,” in ACM
SIGPLAN Notices, vol. 47, pp. 21–40, ACM, 2012.
[6] S. Savage, M. Burrows, G. Nelson, P. Sobalvarro, and T. Anderson, “Eraser: A dynamic data
race detector for multithreaded programs,” ACM
Transactions on Computer Systems (TOCS),
vol. 15, no. 4, pp. 391–411, 1997.
[7] A. Dinning and E. Schonberg, “Detecting accessanomalies in programs with critical sections,” in
ACM SIGPLAN Notices, vol. 26, pp. 85–96, ACM,
1991.

[8] R. O’Callahan and J.-D. Choi, “Hybrid dynamic
data race detection,” in ACM SIGPLAN Notices,
vol. 38, pp. 167–178, ACM, 2003.
[9] D. Engler and K. Ashcraft, “Racerx: effective,
static detection of race conditions and deadlocks,” in ACM SIGOPS Operating Systems Review, vol. 37, pp. 237–252, ACM, 2003.
[10] Y. Inamori and N. Yamada, “Static interruptrace detection method for c program in vehicle,” IPSJ Transactions on Consumer Devices&Systems (CDS), vol. 3, no. 3, pp. 76–84,
2013.
[11] M. Matsubara, K. Sakurai, F. Narisawa, M. Enshoiwa, Y. Yamane, and H. Yamanaka, “Modelchecking with program slicing based on variable
dependence graph,” in First International Workshop on Formal Techniques for Safety-Critical
Systems (FTSCS 2012), p. 88, 2012.
[12] M. Weiser, “Program slicing,” in Proceedings of
the 5th international conference on Software engineering, pp. 439–449, IEEE Press, 1981.
[13] B. Xu, J. Qian, X. Zhang, Z. Wu, and L. Chen, “A
brief survey of program slicing,” ACM SIGSOFT
Software Engineering Notes, vol. 30, no. 2, pp. 1–
36, 2005.
[14] J. Ferrante, K. J. Ottenstein, and J. D. Warren,“The program dependence graph and its use in optimization,” ACM Transactions on Programming
Languages and Systems (TOPLAS), vol. 9, no. 3,
pp. 319–349, 1987.
[15] S. Horwitz, T. Reps, and D. Binkley, “Interprocedural slicing using dependence graphs,” ACM
Transactions on Programming Languages and Systems (TOPLAS), vol. 12, no. 1, pp. 26–60, 1990.
[16] J. Krinke, “Static slicing of threaded programs,”
ACM Sigplan Notices, vol. 33, no. 7, pp. 35–42,
1998.
[17] J. Krinke, “Context-sensitive slicing of concurrent
programs,” ACM SIGSOFT Software Engineering
Notes, vol. 28, no. 5, pp. 178–187, 2003.
[18] S. Narayanasamy, Z. Wang, J. Tigani, A. Edwards, and B. Calder, “Automatically classifying
benign and harmful data races using replay analysis,” in ACM SIGPLAN Notices, vol. 42, pp. 22–
31, ACM, 2007.
[19] H.-J. Boehm, “How to miscompile programs with”
benign” data races.,” in HotPar, 2011.

45

SEA

ソフトウェア・シンポジウム2017 in 宮崎

N-gram IDF を利用したソースコード内の特徴的部分抽出手法
小林 勇揮

水野 修

京都工芸繊維大学 大学院工芸科学研究科 情報工学専攻

京都工芸繊維大学 情報工学・人間科学系

y-kobayashi@se.is.kit.ac.jp

o-mizuno@kit.ac.jp

要旨た．また語の重み付け手法では IDF（Inverse Document

Frequency）という大域的な語の重み付け手法が利用されるが，この IDF には単語 N-gram に対して適用できない欠点があった．しかし，近年の研究により，この IDF
を単語 N-gram に対して適用する手法が提案された [14]．
本研究では，この N-gram IDF を利用してソースコー
ド中の特徴的部分を抽出する方法を提案する．この研究の動機としては，今までの IDF では一語の単語に対してしか語の重み付けができず，単語 N-gram に対して重み付けができなかった．IDF をソースコードに対して適用するときに，一語の場合はソースコード中でその語がどのような処理をするときに特徴的なのかが分かりづらい問題がある．例えば，ある語「name」の重みづけが大きくなったときに，その語が「int name」や「name = 0」など，宣言されたときが重要なのか，代入があったときが重要なのかが分からなかった．しかし，この N-gram
IDF を利用すると，それを区別することができるため，
ソースコードに対して利用すると有効性が得られると考えた．本研究の実施にあたっては，先行研究でのアルゴ
リズムの公開されている実装1 を用いた．

従来の大域的な語の重み付け手法である IDF（Inverse

Document Frequency）には，単語 N-gram に対して適用できない欠点があった．しかし，近年の研究により，IDF
を単語 N-gram に対して適用する手法が提案された．本
研究では，この N-gram IDF をソースコードに対して適用し，ソースコード中の特徴的部分の抽出に応用できると考えた．具体的には，局所的重み付けである TF（TermFrequency）と N-gram IDF を利用した語の重み付け手法
である T F-IDF N−gram を用いて，ソースコードごとの特徴語の抽出を行った．そして，その特徴語の行ごとの出現頻度を求めて，ソースコード中の特徴的部分の抽出を行った．まず，サンプルプログラムを用いて特徴語抽出の評価実験を行い，ソースコードにおいても特徴語をある程度抽出できることを示した．次に，Apache Ant の公開されているソースコードを用いて特徴的部分抽出を行い，またソースコードの変更による特徴的部分の変化についても調べた．その結果，ソースコードから特徴的部
分の抽出をすることができた．また，その抽出した特徴的部分は，ソースコードの変更によってもソースコード
全体の相対位置の変化が少ないことを示した．

2準備

2.1 語の重み付け手法

1

はじめに語の重み付け手法（term weighting scheme）はテキス
語の重み付け手法（term weighting scheme）はテキス

ト解析において重要な技術である．その中で，代表的な

ト解析において重要な技術であり，情報検索や文書クものとして TF-IDF（Term Frequency-Inverse Document

ラスタリングなど幅広い分野で利用されている．そこ

Frequency）がある．TF-IDF は，文書中に出現する特定の単語がどのくらい特徴的であるかを識別するための指標で，情報検索 [13]，文書クラスタリング [3]，特徴語抽
出 [6]，映像中のオブジェクトマッチング [12] など，幅で，この語の重み付け手法をソースコードに対して適用
し，ソースコード中の特徴的部分を特定することによって，開発者がソースコードに対してリファクタリングや
メンテナンスをする際の役に立つのではないかと考え

1 https://github.com/iwnsew/ngweight

46

SEA

ソフトウェア・シンポジウム2017 in 宮崎

be」の方が文書に出現する割合が低くなるため，「Osakabe」の方が大きい重み付けをしてしまう．しかし，大阪大学大学院情報科学研究科の白川真澄らによる研究 [14]により，単語 N-gram に対しても IDF を適用することができることが発見された．この手法は，文字列が出現す
る Web ページをシャノン・ファノ符号によって表現した
とき，空文字からの情報距離が対象の文字列の IDF となることを利用している．具体的には，以下の式（4）によって単語 N-gram g に対する IDF を計算する．

広いアプリケーションで利用することができる．また，複数の観点 [2] [11] [7] から理論的説明が与えられており，多くの人が TF-IDF を利用する根拠となっている．
本研究では，この語の重み付け手法をソースコードに対して利用することにした．次の節で，TF-IDF について
詳しく説明していく．

2.2 TF-IDF
TF-IDF のような語の重み付け手法は，一般的に，局
所的重み付けと大域的重み付けの二つの要素からなる．
局所的重み付けは，ある文書に対する語の出現頻度から計算され，対象とする文書によって重みは変化する．一方，大域的重み付けは，文書集合全体における語の文書頻度から計算され，語の重みは対象とする文書によらず一定である．TF-IDF は具体的には，以下の式（1）により語 t の文書 d ∈ D における重みを計算する．
T F-IDF(t, d) = t f (t, d) · log|D|d f (t)IDF N−gram (g) = log(4)

ここで，|D| は D の文書数，d f (g) は文書集合 D における g の文書頻度，θ(g) は g を構成する各単語の論理積，

d f (θ(g)) は文書集合 D における θ(g) を満たす文書数である．また，各単語の論理積とは，文書集合において gを構成する各単語が含まれている文書である．

3(1)

ソースコードに対する N-gram IDF の適用
ここではソースコードに対して N-gram IDF を使用す

ここで，t f (t, d) は文書 d における語 t の出現頻度，d f (t)るにあたって，どのような前処理をしたり，注意事項がは文書集合 D における t の文書頻度，|D| は D の文書数あるのか挙げる．

である．

また，ソースコードに対してのみ N-gram IDF を使用

この式（1）の中で，局所的重み付けは以下の式（2）

したいので，ソースコード中のコメントがあるならそれで表される．

T F(t, d) = t f (t, d)|D| · d f (g)d f (θ(g))2を取り除き，その取り除いたソースコードに対し N-gram(2)

IDF を使用することにする．

また，大域的重み付けは以下の式（3）で表される．

IDF(t) = log|D|d f (t)3.1 単語の分割(3)
ここではソースコードの単語の分け方について説明す特に，大域的重み付けである IDF [8] は様々な語の重みる．英語などのテキストは基本的に空文字によって単語付け手法で採用されている．IDF が様々な語の重み付けを分割する．しかし，ソースコードを単語に分けるとき，手法として採用されている理由として，式（3）のようなプログラマや開発環境によって空文字の有無が発生する．

簡潔さとロバスト性が挙げられる．実際に，IDF は様々

例えば，「 a = b + c 」と「 a=b+c 」がある．このとき，な文献 [2] [11] [9] において理論的にロバストであるこ

前者は「a」「=」「b」「+」「c」の 5 文字で認識し，問題とが示されている．

はない．一方，後者は空文字がないため，「a=b+c」の 1
文字で認識してしまうと問題が発生する．この問題を解

2.3 N-gram IDF

決するために，ソースコードを単語に分ける際の規則は
以下のようにする．実験では，C と Java のプログラミン

従来の IDF の欠点として，単語 N-gram に対して適用

グ言語に対して単語分けを行った．

できないことがあった．単語 N-gram に対する IDF は，その連続する単語のつながりが不自然であるほど大きい重• 基本的にスペース区切りで単語を分ける．

み付けをしてしまっていた．例えば，「Osaka University」• 以下の記号は一単語としてみなす．
!?”’#$%&|(){}[]=<>+-*/\˜ˆ@:;,.

と「Osaka be」では単語のつながりが不自然な「Osaka

47

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4. N-gram g とその語の長さ（N-gram の N）と d f (g)，d f (θ(g)) を求める．

これにより，ソースコードを単語に分けていく．
さらに詳しく説明をするために，この規則を適用してソースコードを単語に分けるときの一つの例を挙げる．

5. d f (g)，d f (θ(g)) の値と式（4）を利用して，N-gram
IDF を求める．

例えば，次のようなソースコードがあるとする．
例）name.name_get()=1+2;

6. 求めた N-gram g からそれぞれのソースコードごとの t f (g, d) を求める．

これを前述の規則に適用すると，「name」「.」「name_get」
「(」
「)」
「=」
「1」
「+」
「2」
「;」の 10 単語に分かれる．ここで注意すべきところは「name_get」が 3 語に分かれな

7. 5. と 6. の結果より，式（5）から T F-IDF N−gram (g, d)を求める．

いことである．これはソースコードにおいて記号の中でも「_」が変数の名前の一部として利用されるためであていることが多いため，この記号を一語として見なさな

8. 求めた T F-IDF N−gram (g, d) の値で N-gram g を降順に並び替え，その上位の g を特徴語とする．

いことにした．また，Java などの言語では変数の名前のここで d f (θ(g)) の値を計算することは，単語の論理積に一部に「_」以外の記号を使うことがある．例えば，「$」

対する出現頻度を計算する必要があるため計算量が多い．

や「@」，「%」などが挙げられる．しかし，そのような

また，N-gram g の種類が非常に多いため，ソースコード

場合は先頭で始まったり，特徴的な使い方をされること中から選ぶ N-gram g を絞ることも必要である．よって，が多いため 1 語として見なすことにした．

ここでは白川真澄らの文字列解析手法を使った実装方法

る．特にこの「_」が変数の名前の一部として利用されを用いた．まず，あらゆる N-gram g の中からある程度数

3.2 ソースコード中の特徴語判定方法

を絞るために，拡張接尾辞配列 [1] を用いた極大部分文字列の抽出 [10] を行う．この極大部分文字列を N-gram

本研究では，ソースコード中の特徴的部分を発見す

g とする．次に d f (θ(g)) の値を計算するためにはウェー

るためにソースコード中の特徴語を判定する．そのた

ブレット木 [5] を利用することで計算量の短縮を行った．

めに，語の大域的重み付けである N-gram IDF と語の局

ウェーブレット木というデータ構造が文書頻度の計算処

所的重み付けである TF（Term Frequency）を利用した理においても高速に行えることは Gagie ら [4] が示して

T F-IDF N−gram を利用する．具体的には，式（2）と式（4）より，N-gram g のソースコード d ∈ D における重みは以下の式（5）で表される．
|D| · d f (g)T F-IDF N−gram (g, d) = t f (g, d) · log
d f (θ(g))2いる．

3.3 ソースコード中の特徴的部分抽出方法(5)

本研究では，ソースコード中の特徴的部分を抽出する

ここで，ソースコード d ∈ D は，D をソースファイルにあたって，ソースコードを行単位で確認し，特徴語が群とし，その中の任意の一つのファイル中のソースコー

出現した行を数えていくことにした．そして，特徴語がドを d とし，ソースファイル単位で分割する．よって，出現した回数を縦軸に，ソースコードの行数を横軸に

t f (g, d) はソースコード d 中の g の出現回数，d f (g) は gが出現するソースファイル数，d f (θ(g)) は θ(g) を満たす
ソースファイル数である．
この式（5）を利用して，ソースコード中の特徴語を求めていく．以下に，その手順を示す．

取ったヒストグラムを作成する．そして，ヒストグラムの値が高くなっている行に注目して，その部分を特徴的部分として判定する．
また，ソースコード中の特徴的部分を抽出するときにはソースコードを行単位で確認する．そのため，ソース
コードを単語ごとに分割していくときには行ごとに単語1. 語の重み付けをするためのソースファイルを複数用意する．

に分割することにする．

2. それぞれのソースファイルのソースコード中のコメントを取り除く．

3.4 研究設問

3. それぞれのソースコードを単語ごとに分割していく．

部分を抽出するにあたって，確かめたい研究設問についここでは本研究の目的であるソースコード中の特徴的

48

SEA

ソフトウェア・シンポジウム2017 in 宮崎て説明する．

/* header files */# include <stdio .h># include <stdlib .h>

本研究で利用している N-gram IDF は元々テキスト文
書の語の重み付けとして利用されているものである． そ/* main */int main(void) {FILE *fp;
char * filename = " sample .txt";
int ch;のため，それをソースコードに利用した第 3 章の節 3.2の特徴語判定方法でソースコード中における特徴語を見つけることができるのかという問題がある．また，ソー/* フ ァ イ ル の オ ー プ ン */if (( fp = fopen (filename , "r")) == NULL) {fprintf (stderr , "% s の オ ー プ ン に 失 敗 し ま し た .\n", filename );exit( EXIT_FAILURE );}スコード中の特徴的部分を抽出する際に，見つかった特徴語が本当に特徴語である必要もある．よって，以下のような研究設問を設けた．

/* フ ァ イ ル の 終 端 ま で 文 字 を 読 み 取 り 表 示 す る */while (( ch = fgetc (fp)) != EOF ) {putchar (ch );}RQ1. ソースコード中から特徴語を抽出できるのか/* フ ァ イ ル の ク ロ ー ズ */fclose (fp );第 3 章の節 3.3 で説明した方法では，作成したヒストグラムを利用して，ソースコード中の特徴語が出現した

return EXIT_SUCCESS ;}回数が多い行を特徴的部分として抽出する．そのため，
このヒストグラムを利用して，ソースコード中の特徴的

図 1. C 言語関数辞典 fgetc のサンプルプログラム4

部分の特定ができる必要がある．これを確かめるため，
以下のような研究設問を設けた．

まず，1 つ目の実験ではサンプルプログラムを用いてRQ2. ソースコード中から特徴的部分を抽出できるのか

ソースコード中の特徴語抽出の評価実験を行った．この最後に，もし特徴的部分が抽出できるなら，その抽出を用いてソースコード中の特徴的部分抽出の実験を行っした特徴的部分がソースコードの変更によってどのようた．この実験結果を用いて RQ2，RQ3 について答える．

実験結果を用いて RQ1 について答える．
次に，2 つ目の実験ではオープンソースプロジェクトに変化するのかを調べたい．例えば，抽出した特徴的部

4.1 サンプルプログラムを用いた特徴語抽出

分がソースコードの変更によって消えていったなら，その特徴的部分が何らかの変更が必要なソースコードで「C 言語関数辞典2 」の Web ページで公開されているサある言えるかもしれない．また，抽出した特徴的部分がンプルプログラムを用いて特徴語抽出の評価実験を行っ

ソースコードの変更によって消えずにそのまま存在するなら，大幅な変更を加える必要のないソースコードであた．C 言語関数辞典では，C 言語の関数やマクロの使いると言えるかもしれない．したがって，そのような特徴方に関する説明を主にしている．この Web ページでは，関数やマクロの説明がヘッダファイル別やアルファベッが分かると開発者がソースコードに改良を加える際に何ト別などによって分類されて，掲載されている．また，かの手助けになるかもしれない．よって，以下のような関数の説明によってはサンプルプログラムを使って説明

研究設問を設けた．

をしている場合がある．例えば，関数 fgetc ではサンプ
ルプログラムを使って説明をしている．そのサンプルプ

RQ3. ソースコードの変更によって特徴的部分にはどのような変化があるのか

ログラムは図 1 である．このようなサンプルプログラム
からコメントを除いて特徴語抽出を行う．また加えて，
このサンプルプログラムでは文字列の出力の際に日本語4が使われているので，特徴語を計算する前にすべての日

実験方法

本語を「JAPANESE」に変換した．
第 3 章で述べた研究設問を調べるために，2 つの実験を行った．

2 http://www.c-tipsref.com/

49

SEA

ソフトウェア・シンポジウム2017 in 宮崎

このサンプルプログラムを複数用いて特徴語抽出の評

たソースコードの参照先がわかるように一つ一つ区
切る．

価実験を行う．具体的には，C 言語関数辞典内のサンプ
ルプログラムを集めてきて，それぞれのサンプルプログ

2. Apache Ant の全コミットのログを集めてきて，ソー
スコードファイルに対するすべての変更履歴を調べる．

ラムで説明している関数名をファイル名とし保存する．
また，それぞれのサンプルプログラムのファイルの正解
語はそのファイルで説明している「関数の名前」を含むものとする．例えば，図 1 のサンプルプログラムの場合，

3. 変更履歴を探索していき，ファイル B のソースコー
ドの一部をその変更があったファイルのソースコー
ドに置き換えていく．もし，変更があったファイル
がファイル A なら，ファイル B を書き換えた後にN-gram IDF を求める．

「fgetc」を含む単語 N-gram が正解語となる．さらに，サンプルプログラムは，Web ページ内のヘッダファイル一覧から「stdio.h」「stdlib.h」「string.h」「ctype.h」の 4 つのヘッダファイルを選択し，その中の関数の説明の際にサンプルプログラムを使用している箇所から集めた．集

以降，3. を繰り返すことによって，ファイル A の N-gram

めたサンプルプログラムのファイル数は全部で 94 個に

IDF を全て求めることができる．
この求めた N-gram IDF を用いて，T F-IDF N−gram をそれぞれのファイルについて求めて，行ごとの特徴語の出現頻度を表したヒストグラムを作成していく．また，
ソースコードの変更による特徴的部分の変化について
は，横軸がソースコードの行数，縦軸が変更回数のヒートマップを作成し，特徴語の出現回数によって行ごとに色を変化させる．そして，その特徴的部分の色の変化によって，ソースコードの変更による特徴的部分の変化について調べることにする．

なった．
評価実験では第 3 章の節 3.2 で説明したソースコード
中の特徴語判定方法を用いて行う．それぞれのサンプルプログラム中の特徴語に順位付けをし，1 位の特徴語にそのサンプルプログラムの関数名が入っていたら正解として数え，その正解率を調べた．正解率 R は正解数をa とし，D をファイル数とすると，以下の式（6）で求
める．
a
R=
(6)
D
したがって，この正解率の値でソースコード中の特徴語抽出の評価実験を行う．

5

4.2 Apache Ant を用いた特徴的部分抽出

実験結果

5.1 RQ1:ソースコード中から特徴語を抽出できるのか

Apache ソフトウェア財団が開発しているオープンソー
スのソフトウェアプロジェクトである Apache Ant というビルドツールソフトウェアの Git リポジトリ5 を用いて特徴的部分抽出の実験を行った．
また，ソースコードの変更による特徴的部分の変化についても調べるため，特定のファイルの変更があった際の N-gram IDF を全て求める．具体的には，以下のようにして特定のファイル（以下ファイル A とする）の変更
時のすべての N-gram IDF を求めることにする．

サンプルプログラムを用いた特徴語抽出の実験を利用して，RQ1 に答えていく．例えば，図 1 に対して特徴語抽出を行い，語の長さが 2 語以上で上位 10 位以内の単語 N-gram を表 1 に示す．表 1 により，最も特徴的な単語 N-gram が「 ( ch 」となっていて，次いで「 ( fp 」，
その後に 4 つの単語 N-gram が同じ特徴度になっている
ことがわかる．さらに，このソースコードの正解の特徴
語は「 fgetc 」を含むものとしていたので，それを含む
単語 N-gram「 ch = fgetc ( fp ) 」は第 3 位となっている．
このようにして，C 言語関数辞典から集めてきた全 94

1. 現時点6 の Apache Ant のソースコードを全て集めてきて，一つのファイル（以下ファイル B とする）にする．また，ファイル B を作成する際は集めてき個のソースコードのファイルに対して特徴語の抽出を行い，評価を行った．
まず，全てのサンプルプログラムに対して行った特徴
語抽出の評価実験の結果をまとめた表が表 2 である．こ4 参照元 http://www.c-tipsref.com/reference/stdio/fgetc.html (参照日2017/02/01)
5 https://github.com/apache/ant
6 実験では 2016 年 10 月 18 日時点

こで正解数とは，単語 N-gram を順位付けしたときの 1
位の特徴語が正解の語を含んでいるサンプルプログラム

50

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1. fgetc のサンプルプログラムに対する特徴語抽出の結果
語の長さ

t f (g, d)d f (g)d f (θ(g))

IDF N−gram

T F-IDF N−gram

単語 N-gram g

2
2
2
5
6
4
6
2
3
7

2
3
1
1
1
1
1
2
2
1

5
20
3
3
3
3
4
20
20
2

5
20
3
3
3
3
4
20
20
3

4.233
2.233
4.970
4.970
4.970
4.970
4.555
2.233
2.233
4.385

8.465
6.698
4.970
4.970
4.970
4.970
4.555
4.465
4.465
4.385

( ch
( fp
putchar (while ( ( ch =ch = fgetc ( fp )) { putchar () ! = EOF ) {fp )( fp ); } while ( ( ch =gram を順位付けした際に，その中に順位は関係なく正解語が入ってるファイルの数である．表 3 より，全ファ
イル 94 個に対して正解語を含む単語 N-gram が入ってたファイルの数は最大で 50 となっていて，約半数近くのファイルがヒットしていないことがわかる．さらに，語の長さが増えていくたびに値が低くなっていき，語の長さが 9 語以上で 0 になる．このことから，正解率が低かったのはプログラムが単語 N-gram を作成する際に，その単語 N-gram に正解の語が含んでいないものが約半
数以上あったからと推測した．そのため，ソースコードの特徴を考えたテキストとは違う単語 N-gram の作成の必要があると考える．
また，適合率は語の長さが 3 語以上から 7 語以上まで
で 6 割を超え，6 語以上で最大値 0.857 をとる．よって，語の長さが 3 語以上の連続した語に対して特徴語の抽出を行うと，正解率が 0.319 で，適合率が 0.682 となり，どちらの値も比較的高い値になる．このことから，語の長さが 3 語以上の連続した語に対して特徴語の抽出を行い順位付けをすると，上位の語がソースコードにおいて特徴語である可能性が高くなることがわかる．
以上の結果より，ソースコード中から 3 語以上の連続した語なら，比較的高い確率で特徴語を抽出できるといえる．

表 2. ファイル数 94 個に対する特徴語の正解率
語の長さ N 語 [以上]

正解数

正解率

16
23
30
27
19
12
8
4
0

0.170
0.245
0.319
0.287
0.202
0.128
0.085
0.043
0.000

1
2
3
4
5
6
7
8
9

表 3. ファイル数 94 個に対する特徴語のヒット数とその適合率語の長さ N 語 [以上]

ヒット数

正解数

適合率

50
47
44
39
29
14
10
7
0

16
23
30
27
19
12
8
4
0

0.320
0.489
0.682
0.692
0.655
0.857
0.800
0.571
0.000

1
2
3
4
5
6
7
8
9

の数である．また，正解率は式（6）を用いて計算している．表 2 より，正解率は長さ 3 語以上のときに最も高くなっていることがわかる．しかし，正解率自体は 0.319 と5.2 RQ2:ソースコード中から特徴的部分を抽出できるのかあまり高い値にはならなかった．そこで，サンプルプロ
グラムに対して特徴語抽出を行った際のヒット数と適合率についても調べ，表 3 に示す．ここで，適合率 R-Prec

ここでは，Apache Ant を用いた特徴的部分抽出の実は，ヒット数を h，正解数を a とすると以下の式（7）で
表す．



a


h
R-Prec = 0験を利用して，RQ2 に答えていく．

(h >0)(h = 0)

はじめに，RQ1 の実験の結果を利用して，語の長さが3 語以上の単語 N-gram に対してのみ特徴語を求め，ソー
スコードのファイルを代表する特徴語とした． さらに，
T F-IDF N−gram の値で並び替えた上位の単語 N-gram を(7)

ヒット数 h とは，ファイル中のソースコードの単語 N-

51

SEA

ソフトウェア・シンポジウム2017 in 宮崎

特徴語とする時に，上位 100 位以内の単語 N-gram を特徴語として候補を絞り込むこととした．
また，事前の実験で上位 100 位以内の単語 N-gram を特徴語とした結果，同じ行に複数の特徴語が出現する
ことが分かった．行あたりの特徴語の数によって特徴的部分を特定する際に，ある一部の行の特徴語の数が大きくなると，その行以外の値が相対的に低くなり特定が難しくなる． 同じ行に複数の特徴語が出現する理由
としては，特徴語の中に似た語の組み合わせで，かつT F-IDF N−gram の値が近いからである．例えば，表 4 のような場合がある．この表は「 elementAt ( i ) 」と「 .
elementAt ( i ) 」が特徴語となっていて，残りの 4 つは
2 つの特徴語を含む単語 N-gram を幾つか挙げたものである．この場合，表の出現箇所を見ると，2 つの特徴語の出現箇所が重なってしまっていることがわかる．この問題に対処するために，特徴語の出現箇所からそれ以降の順位の特徴語を含む単語 N-gram の出現箇所を除くことにした．これを適用すると，2 つの特徴語の出現箇所
はそれぞれ「 elementAt ( i ) 」のとき出現箇所はなくな
り，「 . elementAt ( i ) 」のときの出現箇所は 618 と 840になる．これ以降，特徴語の出現箇所は以上のようにして求める．
次に，Apache Ant のどのソースコードに対して特徴的部分の抽出を行うか決める．2016 年 10 月 18 日時点
で，Apache Ant では全 1222 個の拡張子が java のソース
コードファイルが存在する．そのため，ある程度特徴量の高い可能性があるソースコードに絞って実験を行いた
い．よって，2016 年 10 月 18 日時点の Apache Ant の全1222 個のソースコードファイルに対して特徴語抽出を行い，大域的重み付け N-gram IDF の高い値が比較的多いものを探し出した．その結果の比較的多かったファイルの幾つかを表 5 に示した．この中から，「Main.java」と「Javadoc.java」を選んで実験を行った．
まず，2013 年 7 月 17 日時点の「Main.java」に対して特徴的部分抽出を行った結果について説明する．図 2 は
特徴語の出現箇所を行ごとに数えていき，行ごとの特徴
語の出現頻度をグラフにしたヒストグラムである．グラフから特徴的部分を値が 10 以上のグラフに注目して考えていく，まず 660 行から 700 行あたりが一番高くなり，次に 150 行から 200 行あたり，270 行から 300 行あたりが高くなっている．また，370 行から 400 行あたりも少し高くなっている．
一番値が高くなった 660 行から 700 行あたりは，

図 2. 2013 年 7 月 17 日における Main.java における特徴語の出現頻度「Main.java」のソースコードでも見た目からも特徴的なものになっていた．それは，プログラムの引数の使用方
法の文字列の出力をする関数（関数名 printUsage）であった．そのため，文字列を表示させるための関数を複数使用していた．次に値が高くなっていた 150 行から 200 行
あたりや 270 行から 300 行あたりは「Main.java」のソースコードでは実行時に与えられた引数の処理をする関数（関数名 processArgs）になっていた．さらに詳しく見ていくと，150 行から 200 行あたりは引数の条件分岐のコードとなっていて，270 行から 300 行あたりはビルド
ファイルがなかったときの条件分岐のコードになっていた．また，次いで値が高くなっていた 370 行から 400 行
あたりは，与えられた引数の処理をする際のそれぞれの引数で指定された値を変数に保存したり，その値が無効なものならエラー処理をする関数がいくつか並んでいた．
これらの関数は関数 processArgs 内の 150 行から 200 行あたりの引数の条件分岐のコードで利用されていた．
よって，「Main.java」において特徴的部分は大きく分けて 3 つ挙げられる．

• 1 つ目は，660 行から 700 行あたりのプログラムの引数の使用方法の文字列を出力する関数 printUsage• 2 つ目は，関数 processArgs で具体的には 150 行から 200 行あたりの引数の条件分岐のコードと 270 行
から 300 行あたりはビルドファイルがなかったときの条件分岐のコード

52

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 4. 同じ行に複数の特徴語が出現する理由
語の長さ

T F-IDF N−gram

4
5
6
8
6
6

25.96325.76916.942
11.2958.227
0.835

単語 N-gram g

出現箇所 [行]

elementAt ( i ). elementAt ( i )names . elementAt ( i )( names . elementAt ( i ) ). elementAt ( i ) ). elementAt ( i ) .

618,812,832,835,836,840
618,812,832,835,836,840
812,832,835
812,832
812,832,836835

表 5. 大域的重み付け N-gram IDF の高い値が多かったファイル
ファイル名

参照先

Javadoc.java
BlockSort.java
ZipOutputStream.java
CBZip2InputStream.java
CBZip2OutputStream.java
IntrospectionHelper.java
Zip.java
ZipFile.java
Main.java

ant/src/main/org/apache/tools/ant/taskdefs/
ant/src/main/org/apache/tools/bzip2/
ant/src/main/org/apache/tools/zip/
ant/src/main/org/apache/tools/bzip2/
ant/src/main/org/apache/tools/bzip2/
ant/src/main/org/apache/tools/ant/
ant/src/main/org/apache/tools/ant/taskdefs/
ant/src/main/org/apache/tools/zip/
ant/src/main/org/apache/tools/ant/• 3 つ目は，370 行から 400 行あたりの与えられた引数の処理をする際のそれぞれの引数で指定された値を変数に保存したり，その値が無効なものならエラー処理をする関数群

図 3. 2013 年 10 月 27 日における Javadoc.java における特徴語の出現頻度

また，2013 年 10 月 27 日時点の「Javadoc.java」に対して特徴的部分抽出を行った結果，図 3 に示すヒストグ

5.3 RQ3:ソースコードの変更によって特徴的部分には
どのような変化があるのか

ラムを得ることができた．これに基づき，次のように特徴的部分を抽出できた．

Apache Ant を用いた特徴的部分抽出の実験を利用して，RQ3 に答えていく．この実験で求めた「Main.java」と「Javadoc.java」の変更時のそれぞれの特徴語を用いて，10 行ごとの特徴語の出現回数を求めた．その値をヒートマップの値として，横軸を行数，縦軸を変更回数
としてヒートマップを作成した．
まず，「Main.java」の全変更時に対して特徴的部分抽出を行い 10 行ごとの特徴語の頻出度をヒートマップにした結果について説明する．その結果を図にしたのが図4 である．このソースコードの変更回数は 167 回で，行数は最大で 870 行であった．一番上が初期の古いソース
コードの特徴量の分布を表していて，下に行くにつれて
新しいソースコードの分布になっていく．図 4 を見ると，
ソースコードの行数が徐々に増えていき，頻繁に変更がされていることがわかる．図 4 より，5.2 節で説明した• 1 つ 目 は ，50 行 か ら 710 行 あ た り の「cmd.createArgument(」と い う コ ー ド を 含 む 関
数群• 2 つ目は，関数 execute 内の 760 行あたりで関数呼び出しをしているソースコード• 3 つ目は，870 行から 940 行あたりと 1050 行から1200 行あたりの関数 execute を実行するために何らかの引数に値をセットする関数群
以上より，「Main.java」と「Javadoc.java」のソースコー
ドについて，出力したヒストグラムから特徴語の出現頻度の値が高くなっている部分と低くなっている部分が存在し，その値が高くなっている部分の周辺を特徴的部分として抽出することができた．

53

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 4. Main.java における特徴語出現頻度の時系列

図 5. Javadoc.java における特徴語出現頻度の時系

的推移

列的推移

特徴的部分の値が高くなっていることがわかり，それぞ6

まとめ

れのソースコードの特徴的部分はソースコードの変更があってもソースコード全体の相対的な特徴的部分の位置

本研究では，単語 N-gram に対して重み付けができる
N-gram IDF をソースコードに対して利用してソースコー
ド中の特徴的部分の抽出を行った．具体的には N-gram
IDF を利用した語の重み付け手法である T F-IDF N−gramを用いて，ソースコードごとの特徴語の抽出を行い，その特徴語の行ごとの出現頻度を求めて特徴的部分の抽出を行った．
適用実験の結果より，N-gram IDF を用いた語の重み付け手法である T F-IDF N−gram を利用すると，ソースコー
ド中の特徴語を抽出でき，その特徴語の行ごとの出現頻度から特徴的部分を抽出することができた．また，その特徴的部分はソースコードの変更によってソースコード
全体の相対位置の変化が少ないということがわかった．
今後の課題としてはサンプルプログラムを用いて特徴語抽出を行った際の，単語 N-gram の特徴語候補のヒット数の改善がある．今回の研究では，複数ある単語 N-gramの数を絞るために拡張接尾辞配列を用いた極大部分文字列の抽出を利用している．しかし，この単語 N-gram の選択方法ではヒット数が少なかったことから，ソースコー
ドに対して有効な単語 N-gram を選択しないのかもしれない．よって，異なるソースコードの特徴を利用した単語 N-gram の選択方法が考えられる．

の変化は少ないことがわかる．
同じく，「Javadoc.java」の全変更時に対して特徴的部分抽出を行い 10 行ごとの特徴語の頻出度をヒートマップにした結果 (図 5) について説明する．このソースコードの変更回数は 191 回で，行数は最大で 1552 行であった．
図より，「Javadoc.java」においてもソースコードの行数が徐々に増えていき，頻繁に変更がされていることがわ
かる．また，5.2 節で説明した特徴的部分の値が高くなっていることがわかり，それぞれのソースコードの特徴的部分もソースコードの変更があってもソースコード全体の相対的な特徴的部分の位置の変化が少ないことがわかる．この「Javadoc.java」においては更新回数が 50 回あたりなどでソースコードが大幅に変更があっても，それに合わせて特徴的部分がソースコード全体の位置に合わせて移動している．このことからも，特徴的部分の位置の変化が少ないことがわかる．以上より，ソースコードの変更によって特徴的部分の位置が他に移ることはなく，ソースコード全体の相対的な特徴的部分の位置の変化が少ないことがわかった．

54

SEA

ソフトウェア・シンポジウム2017 in 宮崎

参考文献[12] J. Sivic and A. Zisserman. Video google: A text
retrieval approach to object matching in videos. In
ICCV, pp. 1470–1477, 10 2003.

[1] M.I. Abouelhoda, S. Kurtz, and E. Ohlebusch. Replacing suﬃx trees with enhanced suﬃx arrays. In Journalof Discrete Algorithms, Vol. 2, pp. 53–86, 3 2004.

[13] H.C Wu, R.W.P. Luk, K.F Wong, and K.L. Kwok. Interpreting tf-idf term weights as making relevance decisions. In ACM Transactions on Information Systems,
Vol. 26, pp. 13:1–13:37, 6 2008.

[2] A. Aizawa. An information-theoretic perspective of
tf-idf measures. In Information Processing and Management, Vol. 39, pp. 45–65, 2003.

[14] 白川真澄, 原隆浩, 西尾章治郎. コルモゴロフ複雑性に基づく idf の単語 n-gram への適用. In DEIM
Forum, 第 A 巻, pp. 3–5, 2015.

[3] B.C. Fung, K. Wang, and M. Ester. Hierarchical document clustering using frequent itemsets. In Proceedings of SIAM International Conference on Data Mining(SDM), pp. 59–70, 5 2003.
[4] T. Gagie, G. Navarro, and S.J. Puglisi. New algorithms on wavelet trees and applications to information retrieval. In Theoretical Computer Science, Vol.
426-427, pp. 25–41, 4 2012.
[5] R. Grossi, A. Gupta, and J.S. Vitter. High-order
entropy-compressed text indexes. In SODA, pp. 841–
850, 2003.
[6] K.S. Hasan and V. Ng. Conundrums in unsupervised
keyphrase extraction: Making sense of th state-of-theart. In Coling, pp. 365–373, 8 2010.
[7] D. Hiemstra. A probabilistic justification for using tfxidf term weighting in information retrieval. In International Journal on Dgital Libraries, Vol. 3, pp. 131–
139, 9 2000.
[8] K.S. Jones. A statistical interpretation of term specificity and its application in retrieval. In Journal ofDocumentation, Vol. 28, pp. 11–21, 1972.
[9] D. Metzler. Generalized inverse document frequency.
In CIKM, pp. 26–30, 10 2008.
[10] D. Okanohara and J. Tsujii. Text categorization withall substring features. In SDM, pp. 838–846, 4 2009.
[11] S. Robertson. Understanding inverse document frequency: On theoretical arguments for idf. In Journalof Documentation, Vol. 60, pp. 503–520, 2004.

55

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ソースコードの品質向上を目的とした特定のコメントを検出するツールの試作
田上諭
宮崎大学 工学研究科
tanoue@earth.cs.miyazaki-u.ac.jp

甲斐秀一
株式会社スカイコム
h-kai@skycom.jp

片山徹郎
宮崎大学 工学教育研究部
kat@cs.miyazaki-u.ac.jp

1. はじめに

要旨

コメントは，ソフトウェアの動作に影響を与えずに，
自然言語で自由に記述できる．そのため，コメントを用いるとソースコードでは表現できない内容も記述できる．
例えば，TODO コメントは，ソースコードに存在する課
題をコメントとして追加することができ，適切に記述す

TODO コメントと言ったマーキングの役割をするコ
メントや不適切なコメントを検出できるようになると，ソースコードの品質向上に役に立つ．本稿では，ソースコードの品質向上を目的として，特定のコメントを検出するツールを試作する．試作するツールでは，正規表
現を利用し，検出文字列のパターンを XML(Extended
Markup Language) ファイルに設定できる．これにより，検出したい特定のコメントを検出できる．新たに検出したい特定のコメントが出てきた場合も，検出文字列のパターンとして追加することにより，柔軟に対応でき
る．株式会社スカイコムの協力で LOC(Line of Code)が 5000 行以上のプロジェクトを対象に試作したツールを適用し， 適合率及び再現率を調査した．調査した結果，検出文字列のパターン調整することにより再現率は100 ％を，適合率は 80 ％を，それぞれ達成した．また，一度設定した XML ファイルは，他のプロジェクトでもそのまま適用でき，再利用可能なことが確認できた．試作したツールを用いることで，マーキングの役割をする
コメントやソースコードに存在する不適切なコメントを検出できる．マーキングの役割をしているコメントや不適切なコメントを減らしていくことで，ソースコードに存在する課題の削減や理解容易性の向上が図れる．

ることで有力な情報となる．例えば，Google C++ Style

Guide[1] では，TODO コメントを記述することが推奨されている．このようなマーキングの役割をするコメン
トは，ソースコードに存在する問題点を見つけるのに有力な情報となるので，コメントとして残しておくことが推奨される．
しかし，TODO コメントは，その存在を忘れてしまう可能性があり，TODO コメントが存在したままの状態になってしまうことがある．TODO コメントが表している課題を修正した時点で，TODO コメントは削除されるべきである．すなわち，TODO コメントなどのマーキングの役割をするコメントは，ソースコードに課題が残っていることを調べるために，必要に応じて検出する必要がある．
また，マーキングの役割をするコメントとは別に，ソースコードに存在すると問題のあるコメントが存在する．
例えば，処理そのものを説明しているコメントである．
このようなコメントは，ソースコードを読めば理解できるので，存在する意味がない．単に読む量が増え，手間となる． 本研究では，このようなコメントを不適切なコメントと呼ぶ．不適切なコメントの詳細については，2章で説明する．不適切なコメントは，目視による確認で

56

SEA

ソフトウェア・シンポジウム2017 in 宮崎

リスト 1. 改修履歴コメント
1
2// 平成 18 年 6 月 1 2 日 田 上 修 正/* 2 0 1 6 / 0 8 / 1 2 田 上 修 正 */リスト 2. 意図が曖昧なコメント
1
2

発見可能であるが，人的資源の不足や開発の遅れから，十分な確認作業が行われない可能性があるので，ツールによる支援が必要となる．

リスト 3. 処理そのものを説明しているコメント
1
2
3

そこで本研究では，ソースコードの品質向上を目的// 暫定的な処理// とりあえず 0 で

4// こ こ で 1 0 回 ル ー プ す る
while ( i < 10) {i ++; // i を イ ン ク リ メ ン ト す る}として，特定のコメントを検出するツールを試作する．
試作するツールは，正規表現を利用し，検出文字列のパている恐れがある．また，改修履歴コメントは改修

ターンを XML(Extended Markup Language) ファイルがされていく度に，コメントが増えていき，ソース[2] に設定できる．この XML ファイルの検出文字列のパ
ターンにマッチするコメントを検出する． 一度設定したXML ファイルは，その他のプロジェクトでも再利用できる．新たに検出したい特定のコメントが出てきた場合
は，検出文字列のパターンとして追加することにより，柔軟に対応できる．本ツールを利用することにより，特定のコメントを検出できる．マーキングの役割をしているコメントや不適切なコメントを減らしていくことで，ソースコードに存在する課題の削減や理解容易性の向上が図れる．

コードが読みにくくなる．以上の理由から， 改修
履歴のコメントを残すのではなく，バージョン管理
ツールを利用するべきである．

• 意図が曖昧なコメント
意図が曖昧なコメントの例を，リスト 2 に示す．リスト 2 に示した意図が曖昧なコメントは，どのような意図で書かれているのかよくわからないコメントである．意図が曖昧なコメントが存在すると，読み手によって解釈が異なる場合があり，混乱を招いて

本稿の構成は，次のとおりである．2 章では，不適切しまう．

なコメントを定義する．3 章では，試作したツールの外• 処理そのものを説明しているコメント

観とその機能を説明する．4 章では，ツールの実装方法について説明する．5 章では，ツールの適用例について

処理そのものを説明しているコメントの例を，リス説明する．6 章では，ツールの考察を行う．7 章では，本ト 3 に示す．リスト 3 に示したコメントは，処理そ稿についてまとめる．

のものを別の言葉で言い換えただけのコメントである．このようなコメントは，ソースコードの読み手

2. 不適切なコメントに追加情報を一斉提供せずに，単に読むソースコー
ドの量を増やすだけである．処理そのものを説明し不適切だと考えられるコメントの候補をあげ，コメンているコメントは，今回試作するツールで検出する

トか不適切かどうかアンケートを行った．アンケートののは難しい．本稿では，このコメントは検出対象と対象は，株式会社スカイコムの開発者 16 人である [3]．

はしない．その理由については，7 章の今後の課題

アンケートにおいて 8 割以上が不適切だと答えたものを，で説明する．

不適切なコメントと定義する．以下に，不適切なコメン

3. 試作ツールトの分類とその理由を示す．

• 改修履歴コメント

試作したツールは，Java 言語で開発した．Java 仮想

改修履歴コメントの例を，リスト 1 に示す．リスト

マシンがインストールできる環境であれば，任意の OS

1 に示した改修履歴コメントは，改修履歴が書かれているコメントである．コメントがメンテナンスされずにソースコードの現状とは異なった内容になっ上で動作する．
ツールの外観と機能，「コメントを解析」機能の詳細，
XML ファイルについて，以降それぞれ説明する．

57

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 1. ツールの外観

コードでファイルを開く．

3.1. ツールの外観と機能

ユーザーがメニューバーの「ファイル」をクリックする

本研究で試作したツールの外観を，図 1 に示す．試作と，ファイルメニューを表示する．ファイルメニューかしたツールはメニューバー，編集エリア，表示エリアから，下記に示す 3 つの機能を利用できる．

ら構成している．ツールのユーザーは，メニューバーからメニューアイテムを選択することによって，ツールの• ファイルを開く
ユーザーが「ファイルを開く」をクリックすると，ファイルオープンダイアログを表示する．ユーザー
が，ファイル―オープンダイアログからファイルを選択すると， ファイルの内容を編集エリアに表示
する．

機能を利用できる．
ユーザーがメニューバーの「設定」をクリックすると，
設定メニューを表示する．設定メニューから，下記に示す 1 つの機能を利用できる．

• 文字コード
ユーザーが「文字コード」にカーソルを合わせると更に２つのメニューを表示する．
「UTF-8」と「ShiftJIS」である．ユーザーは，どちらかを選択することができ，起動時は「UTF-8」をデフォルトで選択している．ユーザーが文字コードを選択すると，試作したツールは選択した状態の文字コードで編集エ
リアのコードを開き直し，次回以降は選択した文字• ファイルを保存
ユーザーが「ファイルを保存」をクリックすると，ファイルセーブダイアログを表示する．ユーザーがファイルの保存先及びファイル名を入力し，ファイ
ルセーブダイアログの「Save」ボタンをクリックす
ると，編集エリアの内容を読み込みファイルに保存
する．

58

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 2. パターンにマッチしたコメントを表示する
タブ
図 3. 全てのコメントを表示するタブ• 複数ファイルのコメントを解析
ユーザーが「複数ファイルのコメントを解析」をクリックすると，ファイルオープンダイアログを表示
する．ユーザは，ファイルオープンダイアログから複数のファイルを選択できる．ユーザがファイルを選択すると，それぞれのファイルの内容を読み込み，それぞれコメントを解析する．その後，それぞれの解析結果を表示エリアに表示する．

ントの表記が (//)，(/* */) であるプログラミング言語
であれば，どんな言語でもコメントを解析できる．
「コメントを解析」は，まずソースコードに存在する全てのコメントを抽出する．次に，XML ファイルに記述されている検出文字列のパターンに基づきマッチングする．検出文字列のパターンにコメントの記述内容がマッチした場合，マッチしたコメントとして検出する．検出したコメントが検出対象のコメントかどうかは，最終的には人により判断する必要がある．

ユーザーがメニューバーの「編集」をクリックすると，コメントの解析結果は，表示エリアで確認できる．表

編集メニューを表示する．編集メニューから，下記に示示エリアは，検出文字列のパターンにマッチしたコメン

す 2 つの機能を利用できる．

トを表示するタブと，全てのコメントを表示するタブの• 編集エリアをクリア
ユーザーが「編集エリアをクリア」をクリックすると編集エリアの内容をクリアする．

２つに分けている．
「検出したコメント」タブを，図 2 に示す．このタブでは，パターンにマッチしたコメントを確認できる．解析結果をクリックすると，編集エリアにおいて，そのコメントのある行に移動する．
「全てのコメ• 表示エリアをクリア
ユーザーが「表示エリアをクリア」をクリックすると表示エリアの内容をクリアする．

ント」タブを，図 3 に示す．このタブでは，ソースコードにある全てのコメントを確認できる．解析結果をクリッ
クすると，編集エリアにおいて，そのコメントのある行に移動する．

ユーザーがメニューバーの「実行」をクリックすると実行メニューを表示する．実行メニューから，下記に示す

3.3. XML ファイル

1 つの機能を利用できる．
• コメントを解析
ユーザーが「コメントを解析」をクリックすると編集エリアの内容を読み込み，コメントの解析を行う．
試作したツールは，コメントを解析した結果を表示
エリアに表示する．詳細については，次節で述べる．

XML ファイルの例を，リスト 4 に示す．XML ファイ
ルでは，Java 言語が利用できる正規表現 [4] で検出文字
列のパターンを記述することができる．
リスト 4 に記述した検出文字列のパターンで，検出可能なコメントは「//TODO メソッドを分かりやすくする」，「//将来は，データをファイルから読み込めるようにする．
」といった，「TODO」という単語が含まれてい3.2. コメントを解析るコメント及び「将来」という単語が含まれているコメントである．また，「//2017/3/03 田上 修正」といったコメントは，行コメント (//) とブロックコメント(/* */) に対応している．行コメント及びブロックコメ「(?=.*\d{2,4}[.\-/年] \d{1,2}[.\-/月]\d{1,2}日

59

SEA

ソフトウェア・シンポジウム2017 in 宮崎

リスト 4. XML ファイルの例
1
2
3
4
5
6
7
8
9
10
11
12

<? xml version = " 1.0 " encoding = " UTF -8 " ? >< comments >< comment type = " T O D O コ メ ン ト " >< regularExpression > TODO </ regularExpression >< regularExpression > 将 来 < / regularExpression ></ comment >< comment type = " 改修履歴コメント " ><! - - 検 出 す る 日 付 フ ォ ー マ ッ ト は 以 下yyyy / mm / d d 、 y y y y . mm . d d 、 y y y y - mm - d d 、 y y y y 年 m m 月 d d 日 ( y y y y は 2 桁 以 上 4 桁 以 下 ) - - >< regularExpression >(?=.*\ d {2 ,4}[.\ -/ 年 ] \ d {1 ,2}[.\ -/ 月 ] \ d {1 ,2} 日 {0 ,1}) </ regularExpression ></ comment ></ comments >つけるだけならば，「((<OTHERS>*)(<LINE_COMMENT>|{0,1})」の正規表現がマッチするコメントである．
「//Todo:イ ン デ ン ト を 綺 麗 に す る ．」と い う コ
メントを検出したい場合は，TODO という検索ワー
ドを大文字と小文字を区別付せずに判断するようにXML ファイルを変更する必要がある．正規表現により，リスト 4 の 4 行目を，「<regularExpression>(?i)
TODO</regularExpression>」に変更する．なお，「?」などの正規表現に使われる特殊文字を検出文字列のパターンとしたい場合は，「?」の前に「\」を追加し「<regularExpression>\?</regularExpression>」とする必要がある．

<BLOCK_COMMENT>)(<OTHERS>*))*」の構文規則の記述ですむ．今回試作したツールでは，コメントを取得して，そのコメントと検出文字列のパターンが一致しているかを調べたい．そこで，構文に一致した際にそのコメントを取得するコードを追加している．
この文法ファイルを JavaCC でコンパイルすると，CommentParser.java な ど の ファイ ル が 生 成 さ れ る ．
CommentParser.java には，CommentParser というクラスが記述されている．生成されたパーサの使用法を，リスト 6 に示す．リスト 6 の 2 行目で，CommentParser のインスタンスを作成している．コンストラクタに，引数として StringReader 型の文字列を渡す．このパーサに渡された文字列が，構文解析される．構文解析は 5 行目のpaser.comment() が実行されるタイミングで実行される．
コメントの解析結果は，String を格納する ArrayList イ
ンスタンスである comments に保持される．この方法で全ての行コメントと，ブロックコメントを抽出できる．

4. 実装
試作するツールの「コメントを解析」機能は，コメン
トの抽出及びパターンマッチにより構成する．以降，それぞれについて述べる．

4.1. コメントの抽出
コメントの抽出には，JavaCC(Java Compiler Com-

piler) を 用 い る ．JavaCC は ，Java 言 語 が 利 用 で
き る パ ー サ ジェネ レ ー タ と し て よ く 使 わ れ る [5]．
EBNF(Extended Backus Naur Form)[6] に似た文法で文法ファイルを記述しコンパイルすると，Java 言語で記述されたパーサを自動生成する．
コメントの抽出に利用している文法ファイルを，リスト 5 に示す．リスト 5 の 23 行目の定義で，行コ
メント (//) に一致する字句か判断でき，24 行目の
定義で，ブロックコメント (/* */) に一致する字句か判断する [7]．それ以外のものは，コメントの抽出には必要ないので，25 行目で<OTHERS>の字句と判断し，
34 行目から 41 行目で構文解析を行う．コメントを見4.2. パターンマッチ

コメントの解析は，XML ファイルを読み込み解析する．XML ファイルを，リスト 4 に示した．
このファイルから，<comments>の子要素の子要素である<regularExpression>の内容を取得する．取得には，DocumentBuilderFactory クラス [8] を利用する．取得
したコメントと取得した内容それぞれのパターンがマッチしているか判断し，パターンにマッチしたものを，「検出したコメント」タブに表示する．

60

SEA

ソフトウェア・シンポジウム2017 in 宮崎

リスト 5. コメントの抽出に使っている文法ファイル CommentParser.jj
12
3
4

options {STATIC = false ;UNICODE_INPUT = true ;
}

5
6
7

PARSER_BEGIN ( CommentParser )package CommentParser ;8

import java . util . ArrayList ;import Dictionaly .*;import ResultData .*;

9
10
11
12
13
14
15

public class CommentParser {}PARSER_END ( CommentParser )

16
17
18
19

SKIP :{< SPACE :([ " " ," \ t " ," \ r " ," \ f " ])+ >
}

20
21
22
23
24
25
26
27
28
29
30

TOKEN :{
< LINE_COMMENT : " // " (~[ " \ n " ," \ r " ])* ( " \ n " | " \ r \ n " | " \ r " )? >| < BLOCK_COMMENT : " /* " (~[ " * " ])*( " * " )+ (~[ " / " ," * " ](~[ " * " ])*( " * " )+)* " / " >| < OTHERS :~[] >}ArrayList < String > comment ():{Token lineComment , blockComment ;ArrayList < String > result = new ArrayList < String >();

31
32
33

}
{
( ( < OTHERS >*)( lineComment = < LINE_COMMENT >{ result . add ( lineComment . image ); }| blockComment = < BLOCK_COMMENT >{ result . add ( blockComment . image ); })( < OTHERS >*))*{ return result ; }

34
35
36
37
38
39
40
41
42

}

5. 適用例

理解不足であることを示すコメントが見つかった．理解不足であることを示すコメントの例を，リスト 7 に示す．

株式会社スカイコムの協力で LOC(Line of Code) が

このような理解不足であることを示すコメントも，不適

5000 行以上のプロジェクトを対象に試作したツールを適用し，適合率及び再現率について調べた [3]． 本稿での適合率は，検出結果の中にどれだけ検出すべきコメン
トが含まれたかを表し，計算式は以下となる．

切なコメントかどうかのアンケート調査は行っていない

適合率 =検出できた検出すべきコメント数
検出した全コメント数

が，今回の検出対象とした．
計測の方法は，検出すべきコメント及びコメントの総数を目視で確認する．その結果とツールを用いて解析した結果により，適合率及び再現率を計算する．

(1)

まず，設定ファイルの調整のためにあるプロジェクト

また，再現率は検出すべき検出対象のコメントのうち，に適用する．このプロジェクトの詳細を， 表 1 に示す．

どれだけ検出できたかを表し，計算式は以下となる．

また， 適用した結果を， 表 2 に示す．このプロジェク

検出できた検出すべきコメント数
再現率 =
検出すべきコメント数

トの 1 回目は，XML ファイルに記述した検出文字列のパターンに原因があり，再現率，適合率がともに満足な(2)

数字ではなかった．その後，検出文字列のパターン調整を行い，3 回目には，再現率が 100 ％となり，適合率が今回の検出対象となるコメントは，TODO コメント

85.2 ％と 8 割以上の適合率になった．

と不適切なコメントである．ソースコード分析の結果，

61

SEA

ソフトウェア・シンポジウム2017 in 宮崎

リスト 6. 生成されたパーサの使用法
1
2
3
4
5
6
7

public ArrayList < String > comments = new ArrayList < >();
CommentParser paser = new CommentParser ( new StringReader ( new String ( " // hello " ));try {comments = parser . comment ();} catch ( CommentParser . Par seExcepiton e }{e . prin t St ac k Tra ce ();}定量分析を行った．結果として，コメントの多いソース
コードは，フォールト潜在率が高いという傾向が示され

リスト 7. 理解不足であることを示すコメント
1
2

た．本稿で試作したツールでは，特定のコメントを検// なぜか動く// 挿入する必要があるかもしれない

出できる．不適切なコメントを検出することによって，フォールトの温床となっているソースコードを見つけることができる．見つけたソースコードを修正することに

表 1. 初めに適用するプロジェクトの詳細
LOC
6854

コメント総数
1990

より，フォールトを減らしていくことができる．

検出すべきコメント数
23

開発者がソフトウェアプロジェクトを短期間でリリースするために，最適でない解決手段を選択することを表す造語として，技術的負債がある [11]．技術的負債には，他のプロジェクトでも，設定ファイルが利用できるこ

不注意によって混入するものと，意図的に導入するもとを確認するために，このプロジェクトで利用した設定のがある [12]．意図的に導入された技術的負債は，Self-

ファイルを別のプロジェクトにも適用した．調整した設

Admitted Techical Debt と呼ばれる．これは，ソース
コードコメントから見つけることができる．従来の研究では，Self-Admitted Techical Debt の検出は，目視に大きく依存していた [13]．そこで，Maldonado 氏は自然言語処理技術を利用し，自動的に Self-Admitted Tchical
Debt を検出する方法を提案した [14]．しかし，[14] では
再現率を 100 ％にできていない．試作したツールでは，文字列検出パターンを用意することで再現率を 100 ％にできる．

定ファイルを適用するプロジェクトの詳細を，表 3 に示す．また，別のプロジェクトに適用した結果を，表 4 に示す．実行回数 1 回目で，再現率が 100 ％で適合率が92.3 ％と高い結果を得ることができた．良い結果を得られるように調整した設定ファイルが，他のプロジェクトにもそのまま利用できることが確認できた．

6. 考察

grep コマンド [15] やテキストエディタのテキスト検索機能を用いても，試作したツールと同様のことができる．しかし，これらは，ソースコードすべてを検索してしまうために，print 文にある自然言語及びメソッド名や変数名として利用されているものまで検出してしまい，
適合率が低くなる．本ツールでは 一度全てのコメントを抽出し，抽出したコメントに対して検出文字列のパター
ンとマッチしているかどうかを判断する．このことにより grep より適合率を高くできる．

不適切なコメントを検出するツールは，他にも開発されている．中村氏 [9] は，Eclipse プラグインとして不適切なコメントを検出するツールを開発している．このツールでは，本論文と同様に XML ファイルを利用し検出
文字列のパターンを定義することができる．しかし，パ
ターンマッチによる正規表現は使えない．試作したツー
ルでは，正規表現を利用し検出文字列のパターンの記述ができるので，柔軟に定義できる．
阿萬氏 [10] は，コメントが多くなっているソースコー

本稿の正規表現によるパターンマッチでは，適合率

ドには，コメントがなければ理解できないようなソース

を 100 ％にすることは難しい．今回，適用したプロジェ

コードが多く存在し，そのようなソースコードがフォー

クトにはパーサのコードがあり，それを説明するためのルトの温床になり，フォールトが増えているのではとのEBNF(Extended Backus Naur Form) がコメントに記述されていた．このコメントに，なくてもよいという意

懸念から, コメントとフォールト潜在との関係に関する

62

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 2. 初めに適用したプロジェクトの適用結果
実行回数
1
2
3

検出すべきコメント数
23
23
23

検出した全コメント数
31
29
27

検出できた検出すべきコメント数
20
23
23

適合率
64.5
79.3
85.2

再現率
87.5
100
100

本稿の方法でも，正規表現の記述方法の工夫や検出表 3. 調整した設定ファイルを適用するプロジェク

対象のコメントによっては，適合率を 100 ％にでき

トの詳細る．しかし，正規表現によるパターンマッチのみで

LOC
9394

コメント総数1584

検出すべきコメント数
24

は限界がある．例えば，学習させたデータに基づいて，適切なコメントか判断する検出手法の提案などが必要となる．

味を持つ正規表現の「?」があり，曖昧なコメントを検• 処理そのものを説明しているコメントのみの検出処理そのものを説明しているコメントに使われる単語は，他のコメントにも頻繁に現れる．そのため，処理そのものを説明しているコメントをパターン
マッチで検出しようとすると，多くの適切であるコ
メントを拾ってしまう．コメントの周辺の情報を取得し，前後の繋がりをもとに，コメントの内容が処理の説明かどうか判断する検出手法の提案などが必要となる．

出するための検出文字列のパターンである「?」にマッチしていため，不適切なコメントして検出していた．適合率を 100 ％にできるような検出方法の考案が，今後の課題である．

7. おわりに
本稿では，ソースコードの品質向上を目的として，特定のコメントを検出するツールを試作した．試作したツールを用いることで，ソースコードに存在する不適切• メンテナンスされていないコメントの検出
適切に書かれたコメントでも，メンテナンスされていない場合は，不適切なコメントになりううる．
バージョン管理ツールである git などの情報を利用し，コメントの周辺が変更されているにも関わらず，コメントが修正されていないところを検出するなどの方法で，メンテナンスされていないコメントを検出できると考えている．

なコメントやマーキングの役割をするコメントを検出できる．なお， 検出したコメントには，検出対象以外のコメントも含まれてしまうことがあるので，目視による確認が必要となる．また，新たな検出対象のコメントが出てきた場合も，検出文字列のパターンとして追加できる．
試作するツールは，正規表現を利用しているので様々なコメントに対して柔軟に対応できる．
株式会社スカイコムの協力で LOC が 5000 行以上のプロジェクトを対象に試作したツールを適用し， 適合率

参考文献

及び再現率について調査した．調査した結果，検出文字
列のパターン調整することによって，再現率は 100 ％を，[1] StyleGuide: Google C++ Style Guide. https://
google.github.io/styleguide/cppguide.html

適合率は 80 ％以上を，それぞれ達成した．また，一度設定した XML ファイルは，再利用可能なことが確認できた．本ツールを利用することにより，特定のコメント[2] XML:“Extensible Markup Language (XML) 1.0(Fifth Edition)”, W3C Recommendation, 2008

を検出できる．マーキングの役割をしているコメントや不適切なコメントを減らしていくことで，ソースコードに存在する課題の削減や理解容易性の向上が図れる．

[3] 甲斐秀一, 田上諭, 片山徹郎, “ソースコードに存在する不適切なコメントを検出手法の適用事例”, ソフト
ウェア・シンポジウム SS2017 発表予定, 2017．

以下に，今後の課題を示す．

• 適合率の向上

63

SEAソフトウェア・シンポジウム2017 in 宮崎

表 4. 調整した設定ファイルを適用したプロジェクトの適用結果
実行回数1

検出すべき検出対象のコメント数
24

検出した全コメント数
26[4] クラス Pattern: Pattern (Java Platform SE8).
https://docs.oracle.com/javase/jp/8/docs/
api/java/util/regex/Pattern.html.

検出できた検出すべきコメント数
24

適合率
92.3

[14] E. d. S. Maldonado, E. Shihab, and Nikolaos
Tsantali, “Using Natural Language Processing
to Automatically Detect Self-Admitted TechnicalDebt”, IEEE Transactions on Software Engineering, DOI:10.1109/TSE.2017.2654244, 2017.

[5] JavaCC: JavaCC - The Java Parser Generator.
https://javacc.org/.

[15] Grep: GNU Grep 3.0．https://www.gnu.org/
software/grep/manual/grep.html[6] ISO JTC1/SC22: “ISO 14977:1966”, International
Organization for Standardization, 1996．
[7] 青木峰郎: “普通のコンパイラをつくろう”, ソフトバ
ンククリエィティブ株式会社, 2009.
[8] ク ラ ス DocumentBuilderFactory:
DocumentBuilderFactory (Java Platform SE8). https://docs.oracle.com/javase/jp/8/docs/api/
javax/xml/parsers/DocumentBuilderFactory.
html.
[9] 中村大賀， “ソースコードコメントのテキスト分析”,
社団法人 情報処理学会 研究報告 SE-163, pp.287–
294, 2009.
[10] 阿萬祐久， “オープンソース・ソフトウェアにおけるコメント記述及びコメントアウトとフォールト潜
在との関係に関する定量分析”，情報処理学会論文誌
Vol.53 No.2, pp.612-621, 2012.
[11] W.Counnigham, “The wycash portfolio management system”, in Addedum to the Proceedingson Object-oriented Programing System, Languages,
and Application, pp.29-30, 1992.
[12] M.Fowler:
Techicaldebt
https://martinfowler.com/bliki/
TechnicalDebtQuadrant.html

再現率
100

quadrant.

[13] A.Potdar, and E. Shihab, “An exploratory study
on self-admitted techical debt”, IEEE International
Conference on Software Maintenance and Evolution, pp.91-100, 2014.

64

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ソースコードに存在する不適切なコメントの検出手法適用事例
甲斐 秀一 1)
田上 諭 2)
片山 徹郎 3)
1) 株式会社スカイコム h-kai@skycom.jp
2) 3) 宮崎大学 工学研究科 {tanoue, kat}@earth.cs.miyazaki-u.ac.jp

要旨■ 周辺処理を理解せず追加したと推測されるコメント(例) 「なぜか」「おそらく」「かもしれない」

本研究では、ソースコード（最終的にはソフトウェア）の品質向上を目的とし、ソースコード内に存在する不適切なコメントを検出可能なツール(以下、本ツール)の開発および評価を、宮崎大学と共同で行った。不適切なコメント
として検出した箇所のソースコードを見直すことによって、品質およびメンテナンス時の作業効率の向上を図ると共に、不適切なコメントが及ぼす影響やコメントの重要性を理解するための教育ツールとしても利用可能なものを目指して取り組みを行った。

前述のアンケート結果をもとに、不適切になり得る単語を一覧化した定義ファイルを用意し、定義した単語を全コメント中から検出することで不適切なコメントの検出を行うこととした。なお、定義する文字列には正規表現も使用可能にしているため、検出文字列のパターンは柔軟に対応可能である(例えば、日付フォーマットを含むコメントの検出等も可能)。

3. 本ツールの評価
1. はじめに当社開発部門が保有する複数ソースコードに本ツールを適用した結果、主に以下の効果が得られた。
■ 不適切なコメントの目視確認が不要となり、過去の実装も含めて容易に見直しが可能となった。
■ 検出対象コメントの定義を柔軟に拡張できるため、ツールを実行して検出結果の傾向を分析し、定義ファイルを拡張していくことで検出精度が上がった。
■ 検出した不適切なコメントの位置から、その周辺処
理に潜在する課題や見直しが必要な可能性のある処理の検出に成功した。
(詳細はスライド参照)

ソースコードに用いられるコメントは、プログラムの処理には直接影響を与えないため、内容について重要視されにくい傾向にある。当社でのソースコードレビュー時においても、コードに注視してチェックを行うため、コメント
内容の細かいチェックまでは実施しない傾向があった。
そのため、不適切なコメントを含んだソースコードが、知らぬ間に徐々に蓄積されていた。読み手にとって理解の妨げとなるような不適切なコメントが存在する場合、メンテナ
ンス時の作業効率を悪化させ、バグの混入に繋がり、結果として製品の品質を低下させる可能性が考えられる。
そこで本研究では、ソースコードの品質向上を目的として、不適切なコメントを容易に検出する仕組みを適用した場合の効果を検証するため、本ツールの開発および評価を行った。

4. おわりに
不適切なコメントを検出し、その周辺箇所を見直すこと
によって、品質およびメンテナンス時の作業効率の向上に繋がることが確認でき、改めてコメントの重要性を認識した。また、本ツールを利用することによって、効率良く不適切箇所を検出できることを確認した。
今後は、不適切なコメントだけでなく、コードとコメントが一致していない箇所の検出を可能とするなど本ツールを拡張することによって、さらなる開発全体の作業効率化を促進したい。

2. 不適切なコメントの検出方法
検出すべき不適切なコメントについては、当社開発部
門内でアンケート調査を実施して定義した。アンケート調
査の結果、社員が不適切と考えるコメントのほとんどが、単語によってパターン分けできることが判明した。(詳細はスライド参照)
以下に検出したパターン例を挙げる。
■ 意図が曖昧なコメント(例) 「暫定」「仮」「未定」

65

SEA

ソフトウェア・シンポジウム2017 in 宮崎「あるある診断ツール」による課題の可視化と収集データの分析事例
室谷 隆
ＴＩＳ株式会社
Muroya.takashi@tis.co.jp

要旨
4. データ分析結果
昨年のソフトウェアシンポジウムにて，『「保守あるある診断ツール」による保守課題の可視化事例』というタイト
ルで，ツールの検討過程，コンセプト，使い方の知見などを紹介させて頂いた．この後運用主体の業務を診断する
診断項目を作成，使い勝手の改善を行ない，2016 年末
までに 220PJ(565 名)に適用し，約 13 万件のデータを得た．この診断結果データの分析を行い，興味深い知見が得られたため事例の追加報告として発表する．

世の中に存在するセルフアセスメントツールは，アセス
メントモデルのプラクティスが実施できているかを直接問うものが多く，プラクティスを理解していないと回答が難し
く，時間がかかるものであった．
このため，設問の内容を，「共通フレーム 2013」のタス
クや「SPEAK-IPA」のプラクティスを身近で発生している
問題事象に変換することで回答し易くした．[1]

全 診 断 の 内 ， 直 近 の デ ー タ (2016 年 度 上 期 実 施分)48PJ，268 名，約 6.8 万件を分析した結果，当初目論
見通りの効果が確認でき，更に以下の知見が得られた．
1． 定性分析結果
経験則として認識されている保守課題が，分析結果
からも裏付けられた．
・属人化，有識者不足
・ノウハウの蓄積がない
・計画外作業（突発作業）が多発 等
2．定量分析結果
設問毎の平均値を横軸に，回答者別の標準偏差を縦軸にして，散布図を作成し，ゾーン分けして分
析．
・A ゾーン：
課題感が低く(高い平均値)，PJ 間で差異が大きい・B ゾーン：
課題感が低く(高い平均値)，PJ 間で差異が小さい・C ゾーン：
課題感が高く(低い平均値)，PJ 間で差異が小さい・D ゾーン：
課題感が高く(低い平均値)，PJ 間で差異が大きい
PJ の優れた事例の横展開で，改善がスムーズに進む D ゾーンに多くの課題が集まっている事が分かった．今後，この事例の横展開を，保守/運用の標
準プロセスの構築と合わせ，エンハンスメント（保守）革新という活動を進めて行く事となった．

3. 利便性の改善と適用範囲拡大

参考文献

保守 PJ へ本ツールを展開する過程において，運用主
体の PJ や顧客から，運用版設問の作成要請があった．
設問内容を検討した結果，ITIL のプロセスを参考にして作成，展開した． また，利用者から 30 分で終了できなく，使いづらいとの意見も多く寄せられたため利便性を向上させるよう変更を行った．

[1] 1．独立行政法人 情報処理推進機構 技術本部
ソフトウェア・エンジニアリング・センター編、共通フレーム 2013
2.独立行政法人 情報処理推進機構 技術本部
ソフトウェア・エンジニアリング・センター
SPEAK-IPA（Rev.1.0.2.0）

1. ツールの概要「あるある診断ツール」はセルフアセスメントツールの一種であり，以下の特徴を持っている．
1． 短時間（約 30 分）で実施可能
2． 生産性や品質の低下を招いている問題事象をチェックするだけ
3． 保守/運用を特徴付ける 8 つの視点を持つ

2. 設問の特徴

66

SEA

ソフトウェア・シンポジウム2017 in 宮崎

パッケージ製品におけるソフトウェア保守情報の活用事例
加藤 英之
東芝ソリューション株式会社

増井 和也
ソフトウェア・メインテナンス研究会ージョンが 1999 年にリリースされてから，ライセンス契
テムは，単一法人向けとして人事・給与機能のみの初期バ

要旨

約数を拡大しつつ 18 年余りになろうとしている（図 1-1）。

開発が済んだソフトウェアは，システム上で稼働を開始

すると，ある種のソフトウェア保守 1)対応が必要となる。

稼働中ソフトウェアへのこの保守対応（含む利用者サポート）は，利用者にとって無償か有償かに関係なく，稼働がして 30 年以上となる事例もある 2) 。保守対応の間で得ら終了するまで何らかの形で継続する。その継続期間が時とれる情報は，処理機能の操作等の Q&A，クレーム，要望，障害情報(事象，原因，回避策，再発防止策等)，修正版リ
リース情報，保守作業のための運用停止情報，修正に伴う仕様・設計 ・プロ グラム・テス ト仕様・作業エビデン
ゆる 5W1H 情報を含み，多岐にわたる。ソフトウェアの開ス・承認過程など，1 件の保守対応にもさまざまで，いわ

図 1-1

発完了時の完成文書が完成時点の状況を示す比較的均一

本体製品のメジャーバージョンは現在 V6 である。初版

で静的な情報であるのに比べ，保守対応情報は時間軸を持より現在まで，グループ企業を統括する複数法人対応の強った動的でかつ多様な情報の集まりといえる。

化，基盤技術や動作可能環境の最新化など，大幅な内部設契約顧客数の推移(1999-2016)

これらの情報には，システム，ソフトウェア，人間系の計更新は複数回行っている。また，企業等の人的資源管理

問題や障害といった瑕疵情報を含み，その量や種類の多さの周辺業務をサポートするオプションサブシステムの製品レパートリの拡張も継続して行っている（図 1-2）。現は一般的にシステムの信頼性のあるべき姿から誇らしい

ことではないとの認識３)がある。そのため，保守対応情報

在のオプションライセンスサブシステムは，従業員の教育は社外への開示はもちろんのこと，社内の他部門への開示
も統計処理した一部データを除き，生の個別保守情報（特ラーニング，人材育成など計 9 のオプション機能を持つまに恥かしい事例と印象付けられるようなもの）が積極的にでに進化している。

管理，能力・目標管理，タレントマネージメント管理，e-

開示されることは少ない。
本論文は，パッケージ製品の顧客別アドオンソフトウェ
ア保守専任チームが管理する保守情報を，外部への開示は制限しているものの，厳重なセキュリティ権限管理や顧客との機密保持契約遵守の下，可能な範囲で部門間共有を積極的に行い，さまざまな効果が出ている事例を総括的に報告するものである。

1. 対象ソフトウェアシステムの概要
本論文の対象システムは大規模企業グループ向け Web

ベースの人財管理パッケージシステム 5) である。対象シス

図 1-2 対象システムのサブシステム拡張（進化）

67

SEA

ソフトウェア・シンポジウム2017 in 宮崎

なお，多様な業種に広がる顧客企業等の業態や勤務形態している。

4. 対象システムのソフトウェア保守体制にきめ細かく対応するため，顧客の求めに応じ，個別アド
オン機能のライセンス提供の提案と契約締結により顧客別アドオン開発・導入を行う場合がある。アドオンソフト

製品本体及び各オプション製品単位に保守担当チーム
ウェア契約自体は，個別顧客の導入効果や利用満足度の向ムが別にある（図 4-1 参照）。以下，アドオン保守統括チがあり，また顧客別のアドオンを束ねて保守する担当チー
上及び本製品提供側の売上増となり，双方にとってメリットがある。

ームが保守情報をどう活用しているかを中心に報告する。
しかし，製品及びアドオンのそれぞれのソフトウェアを併せた場合は，製品のみの導入に比べ，保守対応の困難性
ンアップ，PC（端末）の OS やブラウザなどのアップグレが増す。たとえば，対象システム製品のメジャーバージョ

ードなど，周辺環境の変化に個別保守対応が必要となった場合が発生する。アドオンソフトウェアの保守対応を円滑に提供していくには，製品・アドオンの各機能ソフトウェ
ア間の関連を確実に制御できる高度なソフトウェアの保守対応やソフトウェア構成管理技術が必要となってくる。
本論文は，対象システム製品の保守情報管理を通じて保（注）HW:ハードウェア，OS:オペレーティングシステム，MW:守対応の活用事例および課題とその対策について述べる。
また，このアドオンソフトウェアの保守対応も対象に含

図 4-1

ミドルウェア，PKG:パッケージ製品

めて述べることにする。

対象システムの保守体制のイメージ図

5. 保守情報管理システムの概要

2. 対象システムの規模と顧客保守契約

現在，本管理システムには対象システムの全製品，アドドオン部分，本製品特化した保守作業ツール等を併せ， 1
現状の対象システムの規模は，製品本体部分，顧客別ア

オン機能に関するインシデント対応情報やそれに問い合る。これまでの登録件数の推移を図 5-1 に示す。

わせに回答するための情報が約７万件超が登録されてい千万行を超える。なお，この行数はコメント行も含めて数えている。
顧客が本製品を導入する場合，本体ライセンス費及び，必要とするオプションライセンス費，アドオン機能提供費を支払う。また，その後の保守費として導入した部分に対応する年間保守費が発生する。しかし，製品戦略上，主要パッケージ製品 6) の保守サービス費よりも抑えられた保守契約になる傾向がある。さらに既存顧客が今後の IT 予算計画立案を行う際には，当該顧客から保守費減額交渉要
図 5-1

求が発生することが珍しくない。

3. 対象ソフトウェアの保守発生状況

保守情報管理システムの登録件数推移

シデント情報の検索画面，検索で絞り込んだ情報の CSV

本管理システムの主な機能は，登録画面，登録済みイン出力機能などがある（図 5-2 参照）。

対象システムで発生する保守事案（以下，インシデントと呼ぶ）の情報は，保守情報管理システム（以下，単に本JIS X0161 で定義された保守プロセスで入出力されるデー

管理システムと呼ぶ）に登録する。登録保守情報の範囲は，タや情報だけでなく，製品の仕様・動作環境・顧客情報・
一部営業情報，アドオンの機能，操作，制限，注意点，事例，追加・改良見積もりなどの問合せ情報に関するものなども含む。本管理システムは，インシデント情報の登録自体が最終目的ではなく，問合せに対する回答を行う場合に，
図 5-2

本管理システムの過去の問合せを検索することで，ワンストップで回答や対応の情報にたどり着けることを目的と

68

保守情報管理システムの画面イメージ

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 6-1

務用 PC で行う。利用上の制限は，ログイン画面の表示が出力した情報の加工は，CSV ダウンロードした側の業

保守情報管理システムで管理する主な項目一覧

ロックアウト機能をもつパスワード管理され，登録 ID か許可されたドメインに限定されている。また，ログインはつ適正なパスワード以外は利用ができないか，権限によって検索範囲が制限される。また，誰がどんな操作をしたかのログも取られている。

6. 保守情報管理システムで管理する項目
本システムで管理する主な項目を表 6-1 に示す。特に，
で，各種派生資料（含む CSV 出力後の加工資料）の更新
顧客が現在利用している製品リリースバージョンは重要にも注意を払っている。顧客別製品構成管理情報が別にあると，インシデント情報以外の資料も相互に閲覧が必要になり，必要な確認作業が増加する。

7. 本管理システムの情報管理者と入力者
本システムへの登録（初期入力）は，ヘルプデスク，顧ものが 90%以上である。その他全国にいる営業担当者，受客から直接入ってきた情報を登録する保守担当者による
注前提案 IT 技術者等が登録する場合がある。また，回答や再質問のような追加情報入力は，それぞれの回答担当者
や回答を受けた側が行う。
なお，回答や対応のやり取りは，きめ細かく迅速に行う
が，クローズは特に急がない（早期クローズを最大目標とするようなことはしない）。インシデントのクローズ（完了）の目的は「終わったことにしよう」と安心や達成感を与えるものではなく，必要なインシデント対応記録を漏れなく記録できたことを十分確認できたことを証明するためのものと考えている。そのため，いったん追加入力は収まったが，何年かして，不再現の現象が再発して，追加現
象発生情報の入力がなされることも珍しくない。クローズされていると（もう済んだインデントだから余計なことを（表 7-1 参照）。

しないという）情報入力の漏れの発生リスクが高くなる

また，たとえクローズ状態でも，クローズ案件を除外しなければ，検索対象から外れることはない。また，クローズ状態から非クローズ状態に戻すことや，クローズ後の入力も特に制限なく可能としている。滞留残件（非クローズ
インシデント）数の増減のみで一喜一憂するようなソフト
ウェアの保守作業品質の管理発想は，結果的に必要な保守
記録をすべて記録しようとする努力を阻害することになり，保守対応プロセスとしての成熟度は高くないと考えて
いる。

69

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 7-1

インシデントの早期クローズのデメリット

8. 保守情報の活用事例(課題と活用効果)（課題２）保守対応の終わりが不明確。やって当たり前の（課題１）緊急事態に常に対応できる専任体制は保守コス
世界で業務アピール度が低い
ト増大のリスクがある。
（対策２）重大インシデントが発生すると営業部門や品質（対策１）顧客から保守サービスの費用対効果の向上（コ
保証部門が客先窓口になって対応する必要が発生するこスト低減とサービス向上の両方を進める）を求められる。
とも珍しくない。この場合，保守対応チームは社内においコストの多くは緊急障害に備えた体制維持に多くが取らても，フォローを受けるチームの中心となる。また，障害れる。緊急障害の発生予測精度を高めるため，過去インシ解消に向け目覚ましい活躍をしても，その評価はやって当
デント情報（情報精度が高いことが前提）を分析し，事前たり前というものが多い。特に大きな部門として，開発組に対応準備をしておく。レビジョンアップ後のデグレード
織と一緒の場合，顧客，営業部門，品質保証部門から見た（機能低下），顧客担当者の異動に伴う不慣れ，顧客端末
とき，そのような障害を発生させた責任追及がメインとな
ＰＣ環境の変化，季節的な利用機能の変動など，過去に発り，努力不足または対応能力が低い要員が対応した場合に生した構成の変更・変化後のインシデントの発生傾向をは復旧不可能であった障害を，素早く復旧させた保守対応
分析し，緊急インシデントの防止対策（事前に判明した障能力（技能）に対しての評価を受けることが少ない。
害や利用制限のアナウンス，障害発生時の利用者対処方法，
保守担当者が開発の一員（障害を起こした犯人）と見ら障害を防止する運用方法や設定変更のアナウンス，初心者
れ，そのような不当な評価を受けることがないよう，過去が間違いやすい操作の事例紹介，対応の事前準備。）を検Mean Time To Repair の短縮，予防保守による障害発生数のの障害対応の平均工数，復旧までの期間の短縮（MTTR:
トを抑えるようにする(図 8-1)。

討し準備することで発生コストの計画を行い，予定外コス

削減（MTBF: Mean Time Between Failure の伸長）の傾向のデータを本管理システムから採取・分析した。そして，従来の同様の障害に対して，どれだけ少ない工数，短い時間で解消できたか，予防保守で同種障害を過年度に比べどれだけ少なくできたかをアピールすることを心掛けた。
さらに，この他に月単位，半期単位，経年で総インシデントの集計，分析を行い，インシデントの状況とオプショ
図 8-1

ン製品の保守契約開始の関係等，営業部門への情報提供を
保守情報の活用例１：今後発生するインシデント
行い，既存顧客の営業活動重点分野を決める参考にしてもの予測精度向上らう。また，インシデントの時系列分析（顧客別，全顧客）結果と，インシデント対応残件状況報告の定例会開催を顧客に提案する。この時，営業や提案ＳＥも同行を調整し，

70

SEA

ソフトウェア・シンポジウム2017 in 宮崎

顧客部門から次期予算の提案計画などを構想段階から話の作業が発生。モチベーション向上が困難

ちに最適な提案を提供できる可能性が高くなる(図 8-2)。ま（対策４）緊急事態の発生は，本来計画的に作業をするこ

た，製品に対する顧客の評価や製品やサービスの課題もタては，教科書にもポジティブに書かれることもなく，悲惨イムリに話を聞くことができ，製品やサービス改善を顧客で計画的でない作業に感じることが多い。特に，緊急対応志向で進めることができるようになった。

の経験が浅いソフトウェア技術者にとっては，障害対応優題として聞くことができ，準備を行い正式決定されたら直とが是として教育されてきたソフトウェア技術者にとっ先という大きなプレッシャーを感じながらの作業をつらく感じることもある。
一方，中堅クラス以上の技術者の場合は，早期の障害解消対応を求められるだけでなく，障害の原因や再発防止策の報告書の原稿作成対応を迫られる。また，自身が原因でない場合でも，利用者，顧客，営業部門，品質保証部門から厳しい叱責を受けなければならない立場となる場合がある。
このような場合も，本システムに蓄積されている障害対
図 8-2

保守情報の活用例 2：保守作業の価値アピールに応記録から最適と考えられる対応プロセスを関係者で選択，共有，対応することで，対応の進捗の同一認識と対応

活用

作成物の本システムへの登録で，報告資料の定型部分の流用（文章部分のコピペはご法度）ができ，進捗可視化が可能となる。結果として，次にすべことや対応に苦慮する場（課題３）保守作業の作業環境改善という名目での予算合の相談先が明確になり，対応ミスが減る。以前の類似障化・調達には困難が伴う害対応に要した期間や工数に比べ早く・安く・確実に対（対策３）製品の競争力を高めるための機能強化調達予算応できたことを実感できるようになり，障害対応作業にお化は承認されやすいが，一般的に保守対応コストの削減，

いても達成感やチームワーク感を得られるようになり，メンバの士気が向上した(図 8-4)。

保守サービスのタイムリさ向上，保守担当者の作業負荷低減の体制強化など，保守作業整備を達成するための調達予算をあらかじめ入れておくことが難しい場合がある。特に企業業績が思わしくないときはなおさらである。
そこで，本管理システムから，インシデント対応工数やコストデータを分析し，インシデント対応で費用対効果が一番高い調達先や内製対応した時との比較，現行の体制で達が必要な根拠を示すことができるようになった(図 8-3)。
のバックログの増加状況をデータで示すことによって，調たとえ，今期予算がなく，新たな調達が難しい場合でも，
図 8-4

これらのデータから来期の予算確保の裏付けデータとして活用ができるようになった。

保守情報の活用事例４：保守要員のモチベーショ

ン向上に活用9. 管理システム運営上の課題と対策
9.1. 担当者の初期入力と情報更新の負担感
本管理システムは，インシデント対応や各種問合せ対応の記録が必要十分に行われてこそ意味がある。たとえ，10
図 8-3

万件近い保守対応記録があったとしても，それらの入力内
保守情報の活用例３：保守作業改善の予算化に活容にばらつきや重要な記録項目の入力に漏れがあると利用用価値が小さくなる。

（課題４）障害が発生すると緊急の原因調査・報告・謝罪

そのためには，重い緊急障害対応（入力する時間がない）

71

SEA

ソフトウェア・シンポジウム2017 in 宮崎(図 9-2)。

や逆に取るに足らないと感じたインシデント対応（こんなアピールし，コストの問題を削減していこうとしている

些細なことはいちいち入力する必要を感じない）の場合，入力自体を強制されるとソフトウェア技術者にとっては大きな負担感を感じることが多い。
それを解消するため，入力を個人の作業義務として位置付けるのではなく，定例保守打ち合わせ時に，各担当から必要事項を報告し，互いの状況を共有する。突然参加したメンバには無駄や退屈と感じることが多いが，それは保守る(図 9-1)。

チームの一体感がないことから発生すると動機づけをす
図 9-2

保守技術者の仕事は担当割り当てを受けて，誰ともコミコスト問題への対応ュニケーションをせず，ひたすら対応する個人プレーの仕

9.3. 製品統括責任者の役割事ではない（過去対応事例を効率的に活用した保守プロセ
スの理解）という認識を持ってもらうようリーダが指導する。入力を誰かに任せ（振）れば，もっと短い会議時間に本対象システムの製品の収益を統括する責任者は，新規なると考えるのは，結局保守情報が共有されず，情報内容
導入顧客の増加によるライセンス収入，既存顧客の保守料の不正確さ，陳腐化，活用の形骸化の要因となりやすい。
収入が主な収入となる。保守料収入は安定的な収入と考えられるが，新規導入顧客のライセンス収入はどうしても変動が避けられない。そのため，期初には保守コストを抑えて，本来保守費として計画している以上の利益を出し，変動が避けられない新規ライセンス収入が下振れしても利益予算達成が可能になるようにすることになる。保守コストを抑えた計画を立てることにより，期初に発生したイン
シデント対応への臨時調達も含めた手厚い対応が手薄になる可能性がある。ソフトウェア保守部門が独立していれば，そんなことはできないはずであるが，現状はソフトウ
ェアに関する部門は販売・開発・保守も一緒になっているケースが少なくない。
図 9-1

このような場合も，本管理システムを活用している営業
インシデント棚卸ミーティングのイメージ
担当者の活動状況の把握や実際の状況を知るための連絡を取り合い，プロスペクト（受注見込み案件）の受注可能

9.2. コスト障壁

性のリアルな状況を入手する。また，営業活動にも顧客から顔を知られている保守チームのメンバが積極的に協力

予定外コストの多くはクレームや緊急作業依頼の対応

し受注活動支援も行い，結果として製品統括責任者の防衛により発生する。クレームや緊急作業依頼は，客先からだ的対応を防いでいる。

けでなく，社内の営業部門，提案ＳＥのほか，品質保証部

10. 結論門，セキュリティ統括部門，知的財産部門，その他監査部門などのスタッフ部門からも来る。
これらの対応記録も本システムに登録し，過去どのよう

ソフトウェア保守作業やその作業から発生する記録情な対応をして，どういった対応課題が発生し，どうすれば報は多くの場合，隠される傾向にある。しかし，そういっ
効率よく対応できるかのノウハウを蓄積するようにする。
た保守情報は顧客満足度，顧客サービスレベル，製品品質
そして，営業担当者や別システム提案者が顧客訪問する前
状況，弱点対策分野絞り込み，周辺分野の製品開発参考デに，当該顧客のインシデント情報，最近インシデント対応ータなどに有効で貴重なデータである。本論文では対象と状況を閲覧することを関係部門と調整することで，保守チなるパッケージシステムで管理している保守情報の内容
ームの存在価値を高め，営業や提案ＳＥにファンや理解者とその活用方法・課題等について説明した。ソフトウェア
を増やし，保守チームへの体制強化や作業改善の提案の味
保守チームがこの情報を管理し，営業部門，提案部門，品方になってもらうよう働きかける。
質保証部門，開発チーム，パッケージ保守チーム，ヘルプ
さらに，顧客が設定する運用系パラメータや開発経験のデスクチームなどと共有することにより，次のビジネス拡
ない他の製品のアドオンソフトウェアの保守も第三者と大に的確につながる糧の一つとなることは間違いない。
して保守担当を引き受けることを行い，コストメリットを

72

SEA

ソフトウェア・シンポジウム2017 in 宮崎

そのためには，保守情報をネガティブにとらえず，入力，開示をためらう発想を捨てる。開示された側も問題を起こしたことに対し，責める側の立場に回ることで，自分に責任がないことを強調するような未成熟な対応に終始しない。
その前提で，保守対応に関連するチームや組織全体がよ関係部門間や顧客との連携が強まり win-win の関係を築きり組織能力向上に向けた保守情報の活用を考えることで，上げることができる可能性をソフトウェア保守情報は秘
めていることが，本論文から分かった。

参考文献
1) JIS X160:2012 ソフトウェアライフサイクルプロ
セス (ISO/IEC/IEEE/EIA 12207;2008 の一致規格)
2) ユーザ企業ソフトウェアメトリックス調査 2014
第 7 章 保守調査 日本情報システムユーザ協会
3) ソフトウェア開発データ白書 2016-2017 9 章「信頼性の分析」 IPA
4) ソフトウェア開発プロジェクトの生産性評価に関する事例 佐藤浩明 Unisys Technology Review
第 129 号 2017 年 9 月
5) http://www.toshiba.co.jp/cl/sol/gene/6) http://www.oracle.com/jp/corporate/pricing/e-pl101005-101005a-n-176288-ja.pdf
7) ソフトウェア開発データ白書 2016-2017 3 章「分析について」 IPA

73

SEA

ソフトウェア・シンポジウム2017 in 宮崎

保守と保守開発における Software Evolution の事例報告
三輪 東
SCSK 株式会社azuma.miwa@scsk.jp
はじめに 15 年間進化を続けている同一 Software に関する事例報告である．Software も機能追加を繰り返し，大幅に進化した．加えて，その Software に関わる人々の活動や，それらを支える多様な構成要素も進化を遂げた．
本報告では，Software そのものの変化の歴史では無く，それをとりまく周辺活動の変化に焦点をあて，進化の推移を報告したものである．

Software Evolution の 考 え 方

私の考える
Software Evolution と は 「 事 業 を 継 続 す る た め のSoftware にかかわる活動全般」を言う．Software と直接関わる活動全てを含み，かつ，Software への間接的な活動も含めるのが，私の考えだ．間接的なものとは，教育・組織・営業・事業戦略など周辺の活動全てを言う．
Software 周辺には Software そのものに影響を与える
様々な活動があり，複雑に関連している．それらに境界を設け無視することは出来ない．相互依存[1]の関係である．

事なことは，ハードのＳを現場で生みだしたことであり，共感の無いトップダウンで与えたハードのＳに従わせてはいないことだ．ここではかなりの時間と忍耐を必要とした．急激な成長は期待できないので，小さな成果を積み上げていくしかない．あきらめずに改善活動を継続する．気づくと，様々な部分で徐々に効果が出てくる．ついに改善の効果を全員が実感できるようになる．さらに改善のアクセ
ルが踏まれる．共感と改善の好循環が生まれる．ここが動乱期→安定期に移った状態だ．その後も，改善と共感の好循環を止めない運営を続けた．特に，安定期以降
は，ツール活用を推進し，さらなる進化を加速した．ふりかえりの時間を増やし，KPT を推進することで，自然と改善が進んだ．気づけば，遂行期に移行していた．

最後に 常に，成果にはタイムラグがある[1]ことを理解し，第 5 水準のリーダーシップ[5]やコッターの 8 段階変革
プロセス[6]などのリーダーシップを継続することが大事．
U 理論[7]の co-evolution プロセスは非常に参考になる．
現在は，「答えのない勉強会」を加えて，改善と共感の好循環を維持する努力を行っている．

タイトルについて 本事例では，保守と開発は相互依
存で一体の関係と捉え，Software Evolution として表現している．しかし，一般的には理解されにくいと考え，分
かり易さのために「保守と保守開発における」を追加し
た．

参考文献
[1]

進化の背景 我々の活動は全て相互依存で実現され学習する組織 システム思考で未来を創造する，ピーター・Ｍ・センゲ，訳者：枝廣淳子・小田理一郎・中小路佳代子，英治出版，ている．自身の変化がさらなる変化の連鎖を生む複雑な世界．加えて，今は変化の速い VUCA 時代．短時間で前提が大きく変わるなど，素早い変化・適応が求められる．
今回の Software Evolution の事例は，環境が大きく変化する過程で，我々が生き残るために真剣に取り組んだ
結果として，こういうかたちになったという一例である．気
づけば，全員のセンサーでしなやかに全体最適に向けて進化する，アメーバのような活動体になった．現在も好循環の成長サイクルが持続できている．

ISBN978-4-86276-101-9[2]

マッキンゼーの 7S『フリー百科事典 ウィキペディア日本語版』（http://ja.wikipedia.org/）2017
年 3 月 11 日 18 時 （日本時間）現在での最新版を取得
https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%83%E3%82%AD%E3%83%B3%E3%82%BC%E3%83%BC%E3%81%AE7S[3]

PMP 教科書 Project Management Professional 第 5 版，キム・ヘマルドン，
訳者：株式会社トップスタジオ，
翔泳社，ISBN978-4-7981-3729-2[4]

weblio 辞 書 （ http://www.weblio.jp/ ） で「タックマンモデル」の検索結果
2017 年 3 月 11 日 23 時 （日本時間）現在

報告上の工夫 Software Evolution には段階があり，[5]それぞれに特徴があった．それらを可視化するために，
タックマンモデル[3][4]を用いて説明した．

ビジョナリー・カンパニー② 飛躍の法則，ジム・コリンズ，訳者：山岡洋一，
日経 BP 社，ISBN978-4-8222-4263-2[6]

進化の推移 キーワードは「相互依存」，「共感」，「ソ企 業 変 革 力 ， シ ョ ン ・ Ｐ ・ コ ッ タ ー ， 訳 者 ： 梅 津 祐 良 ， 日 経 BP 社 ，ISBN978-4-8222-4274-9[7]

フトの S・ハードの S」[2]の 3 つ．成立期→動乱期は，個人仕事が中心であり，チーム同士の相互依存関係が薄かった．そこを壊し，助け合いを通じて共感を創り，相互関係を生み出した．その共感を通じてソフトのＳに働きか
けつつ，ハードの S を生み出す活動を行った．具体的には，共感をコーディネートしながらソフトのＳを育み，成果
物やプロセスの共通化を通じて，ハードのＳを揃える．大U 理論 過去や偏見にとらわれず、本当に必要な「変化」を生み出す技術，
Ｃ・オットー・シャーマー，訳者：中土井僚・由佐美加子，英治出版，
ISBN978-4-86276-043-2[8]

あなたの話しはなぜ「通じない」のか，山田ズーニー，ちくま文庫，
ISBN978-4-480-42280-4[9]

チームが成長し続ける「ラーニングサイクル」 IT 現場を強くする 究極のチームビルディング，斉藤 秀樹，日経 BP 社，ISBN978-4-8222-7186-2[8],[9]はプレゼン資料にて参照

74

SEA

ソフトウェア・シンポジウム2017 in 宮崎

OSS 開発者の離脱要因理解のための Politeness の質的調査
宮崎 智己
和歌山大学 システム工学部
s181052@sys.wakayama-u.ac.jp

大平 雅雄
和歌山大学 システム工学部
masao@sys.wakayama-u.ac.jp

要旨

1. はじめに近年，オープンソースソフトウェア (OSS) は企業の

近年，オープンソースソフトウェア（以降，OSS と呼ソフトウェア開発でも積極的に再利用されている．OSSぶ）は様々な用途で幅広く普及しており，個人ユーザに開発者の多くはボランティアとして OSS プロジェクトによるエンドユースのみならず，企業におけるソフトウェ参加するが短期間でプロジェクトを離脱することが知ら

ア開発にも積極的に再利用されている．しかしながら，れている．そのため，多くの OSS プロジェクトでは，プ再利用する OSS がいつまで開発保守されるのか分から

ロジェクトに長期間貢献する開発者が慢性的に不足してなかったり，不具合が発見された場合に確実に修正されおり，プロジェクトの安定運営およびプロダクトの品質

るかどうかが不透明なため [7]，OSS の利用を躊躇する維持に関する重大な懸念を抱えている．OSS プロジェク

ソフトウェア開発企業も少なくない．

トに参加する開発者の Politeness（コミュニケーション

OSS の多くはボランティア開発者によって開発保守されている．ボランティア開発者が OSS プロジェクトで中心的な役割を担うようになる（コア開発者になる）には，長期的な貢献を通じてコア開発者としての資質の有無を認められる必要がある [8, 15] が，ボランティア開発者の多くは約 1.5 年以内でプロジェクトから離脱する [2]ため，多くの OSS プロジェクトにおいてコア開発者が慢性的に不足している．特に大規模 OSS プロジェクト
では，ユーザから不具合報告や機能改善要求が多数寄せられるため，少数のコア開発者へ過度な負担がかかることが多い [9]．コア開発者の離脱はプロジェクトの安定運営に支障を来すだけではなくプロジェクトの消滅や品質の低下に繋がる恐れがあるため，ボランティア開発者の参入障壁を取り除く [13, 14]，コア開発者の負担を軽減する [1, 12]，コア開発者候補者を早期に発掘する [5, 16]など，様々なアプローチから OSS プロジェクトの安定運営のための支援方法が研究されている．
我々の研究グループでは，コア開発者の離脱の予兆を検知するための手法の構築に取り組んでいる．手法構築の予備調査として，OSS プロジェクトで開発者が情報交換するために利用する開発者向けメーリングリストを対象に，開発者の Politeness（コミュニケーション上の配上の配慮）に着目して我々が実施した先行研究 [18, 19]
では，プロジェクト離脱直前に Politeness が急激に変動するコア開発者の存在を明らかにした．

Politeness の急激な変動は開発者の離脱の予兆を検知する手法の構築につながる可能性がある．離脱の予兆検知手法を構築できれば，長期間プロジェクトに貢献する
重要な開発者の離脱をプロジェクト管理者等が早期に察知し，離脱を防ぐための方策の立案に役立つことが期待される．しかしながら [18, 19] では，開発者の Politenessが急激に変動した理由や，開発者の離脱と Politeness の急激な変動とにどのような関係があるのかについては詳
細な分析をおこなっていない．
本稿では，Politeness が急激に変動する理由と離脱原因との関係を明らかにするために，コア開発者が離脱する直前 3ヶ月間の開発者メーリングリストへの投稿の内容を目視する定性的な調査を実施する．本調査の結果，離脱直前に Politeness が大きく低下するコア開発者はコミュニティ内で他の開発者と意見が対立していたことを確認した．一方，離脱直前に Politeness が大きく上昇したコア開発者の離脱理由については明示的な手がかりを見つけることができなかった．

75

SEA

ソフトウェア・シンポジウム2017 in 宮崎慮）[3, 17] を定量化するツール [4] を用いたケーススタ

Politeness と定量化ツール

2

ディをおこなった [18, 19]．開発者の Politeness に着目
本章ではまず，Politeness の概念について説明する．

した理由は，OSS 開発は他の開発者との協調作業を基本とするため，(1) 継続的に貢献するコア開発者は協調

次に，[18, 19] で用いた Politeness を定量化するための作業を円滑にするために他の開発者に対して配慮あるコ

ツール Stanford Politeness について説明する．

ミュニケーションをしているはずであるが，(2) コア開

2.1

発者が離脱する際には，本業が急に忙しくなる，他の開発者と対立するなどによりコミュニケーションの質が変

Politeness

Politeness[3, 17] とは，日本語の「丁寧さ」や「礼儀正しさ」とはニュアンスが異なる概念であり，円滑な人間関係を確立・維持するための相手への配慮を指す．人
は，ポジティブフェイス（他者に認められたい・評価されたいという欲求）とネガティブフェイス（他者から批判されたくない，行動を妨げられたくないという欲求）の二つのフェイスを持っており，コミュニケーションをおこなう相手のポジティブフェイスとネガティブフェイ
スの両方を保つために Politeness を適切に表現する必要がある．
Politeness Strategy[3] とは，Politeness を示すための具体的な表現方法である．我々は，他者との会話の中で様々な種類の Politeness Strategy を使い分けながらポジ
ティブ・ネガティブフェイスを考慮している．
表 1 に，Politeness Strategy を示す．Politeness Strategy の例をいくつか説明する．相手のポジティブフェイ
スを保つための Politeness Strategy の 1 つに Gratitudeがある．Gratitude は，“I appreciate you.” や “Thankyou for 〜.” といったように，相手に対する感謝を示すための表現である．Gratitude を受け取った相手は，話し
手から評価されていることを明示的に認識することができるためポジティブフェイスが保たれる．一方，Hedges
は，相手のネガティブフェイスを保つための Politeness
Strategy の 1 つである．Hedges は，“It appears that〜?” や “I suggest 〜.” といったように，表現を曖昧にすることで相手のネガティブフェイスを侵害しないようするための表現である．

化する（Politeness が変化する）可能性がある，と考えたためである．
ケーススタディの結果，OSS プロジェクトに長期間参加しているコア開発者の Politeness は，短期間でプロジェクトを離脱した開発者より統計的に有意に低い値を示すことが明らかになった．さらに，OSS プロジェクトに長期間参加しているコア開発者であっても Politenessが急激に変動した場合，その直後にプロジェクトを離脱するコア開発者が存在することを明らかにした．しかしながら [18, 19] では，実際のコミュニケーションの内容については十分に分析をおこなっておらず，なぜ開発者の Politeness が急激に変動したのかや，なぜ Politenessの急激な変動がプロジェクトの離脱を招いたのかなどの理由については不明なままである．
本稿では，Politeness が急激に変動する理由と離脱原因との関係を明らかにすることを目的として，Politenessの急激な変動を示したコア開発者のコミュニケーションの内容を目視により確認する．[18, 19] の知見に加え，本調査により，開発者の Politeness の変動とプロジェクト
離脱との関係が明らかになれば，開発者の離脱の予兆を検知する手法を構築する上での重要な手がかりとなることが期待できる．
以降ではまず，2 章において本研究で用いる Politenessの概念について説明する．また，Politeness を定量化するためのツール Stanford Politeness について説明する．

3 章では，開発者の Politeness と活動継続性との関係を調査した我々の先行研究 [18, 19] の概要と結果を示す．4
章では，開発者の Politeness の急激な変化とプロジェク
ト離脱との関係を明らかにするために行った調査結果について議論する．5 章で関連研究を示し，最後に 6 章において本研究の今後の研究方針について議論し本論文を
まとめる．

2.2

Stanford Politeness

本研究では，開発者の Politeness を分析するために，開発者メーリングリストから取得するコミュニケーショ
ンデータに対して Stanford Politeness[4]1 を適用する．

Stanford Politeness とは，言語表現に込められた Politeness を定量化するツールである．
1 https://github.com/sudhof/politeness

76

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1. Politeness Strategy（影響の強さの順に上から並べたもの）
Politeness 値を上げる Strategy
Politeness 値を下げる Strategy

Strategy

該当単語や文の例

Strategy

該当単語や文の例

Gratitude

I appreciate
thankDirect start

So 〜.
But 〜.

Deference

great, nice, awesome

Factuality

really, actually

Indirect (btw)

By the way

Please start

Please 〜.

Please〜 please

2nd person start

You 〜.
Your 〜.

Counterfactual modal

Could you 〜?
Would you 〜?

Direct question

What 〜?
Why 〜?

Greeting
Apologizing
Hedges
1st person start
Indicative modal
1st person pl.
1st person
2nd person

hi, hello, hey
sorry, woops
think, appear, feel
I 〜.
My 〜.
Can you 〜?
Will you 〜?
we, ourI, my, mine
you, your, yourself
表 2. Stanford Politeness[4] を適用した例

No.

例文

Politeness 値

1

OK, thanks for your suggestion. I will change that. Regards, first name.

0.997

2

Oh dear. My question is already slipping down the list into obscurity... I guess I must be
the only person using eclipse 3.4 who would like to be able to do this.

0.507

3

So, what was the solution for this problem then??

0.122

表 2 に，OSS 開発者のメーリングリスト上の議論に対3 番目の文章の Politeness 値は 0.122 と低い値となっている．これは，文中に含まれる “So, what...” の部分がPoliteness 値を下げる Politeness Strategy である Direct
start に該当しており，相手を不愉快にさせる可能性の高い表現であるためである．
Stanford Politeness は，大きく分けて 2 つの処理からなる．図 1 に処理方法の概要を示す．
まず，入力テキストの構文解析をおこない，テキストに含まれる単語と Politeness Strategy を検出し BOW(Bag of Words) ベクトルを作成する．なお，Stanford
Politeness には構文解析機能がないため，本研究では構して Stanford Politeness を適用した例を示す．表 2 中のPoliteness 値とは，Stanford Politeness を用いて Politeness を数値化した値である．Politeness 値は 0 から 1 の間の値をとり，値が大きいほど相手を配慮する表現が取り入れられていることを示す．例えば，1 番目の文章のPoliteness 値は 0.997 と高い値を示している．これは，文中に含まれる “thanks” が Politeness Strategy の Gratitude に，“suggestion” が Politeness Strategy の Hedgesに該当しているためである．2 番目の文章は，単語数が多く情報量の多い文章ではあるが Politeness Strategy を含んでいないため，0.507 と中間の値が算出されている．

77

SEA

ソフトウェア・シンポジウム2017 in 宮崎• 企業とは異なり離脱の要因と考えられる業績や役職等による社会的ストレスの影響を受けにくいこと,-.'.$/0/1$

Politeness
Strategy
検出

テキスト&'"(%"!"#$"%

PS検出済み
テキスト

SVM

)*+
Politeness値• 同じプロジェクトを対象とした先行研究が数多くありケーススタディにより得られる知見の妥当性を確保しやすいこと

図 1. Stanford Politeness における Politeness 値の算出方法• 開発者メーリングリストを通じてやり取りされた
メールデータがすべてアーカイブされており，かつ，容易に取得可能であること

文解析ツールである Stanford Parser2 を用いて入力テキ

3.2

ストの構文解析をおこなう．
次に，作成した BOW ベクトルを機械学習アルゴリズ

ケーススタディでは，以下の 2 点を主に分析した．

ムの 1 つであるサポートベクタマシン (SVM)[6] により学習させる．SVM の学習データには，Stanford Polite-(1) プロジェクトに長期間参加した開発者と短期間参加した開発者の Politeness の違い

ness Corpus[4] が用いられている．Stanford Politeness
Corpus は，Wikipedia ユーザのトークページ3 から抽出した 4,353 の質問と Stack Exchange4 から抽出した 6,604の質問に対して，人手により Politeness を評価した値からなるデータの集合である．最後に，入力テキストをSVM で判別し Politeness 値を算出する．

(2) プロジェクトに長期間参加したコア開発者の Politeness の経時的変化とプロジェクト離脱との関係(1) の分析を実施するにあたり，まずプロジェクトに参加した開発者を定義する必要があった．開発者メーリ
ングリストでは，投稿を 1 度だけおこなってそれ以降は
1 度も投稿しないような開発者も多数存在するため，そのような開発者を「プロジェクトに参加した」と見なすのは適切ではない．また，開発者の投稿数が 1 度のみといった様な少ない場合に関しても，プロジェクトに貢献していると見なすことは適切ではない．したがって，90
日以内に 1 度以上投稿した，かつ総投稿数 10 件以上の開発者を「プロジェクトに参加した」と見なし，「プロジェ
クトに参加した」開発者の投稿（他者の投稿に対する返信も含む）を分析の対象とした．次に，プロジェクトに長期間・短期間参加した開発者を区別するために，前述の条件を満たし，かつ，270 日以上開発者メーリングリ
ストに投稿をおこなった開発者を長期開発者，それ以外
を短期開発者と定義した．その結果，長期開発者 183 名,
短期開発者 173 名を抽出した．
(2) の分析では，長期開発者 183 名の中から投稿数の多い順に上位 10 名をコア開発者と定義し，コア開発者の Politeness の経時的変化とプロジェクト離脱との関係を分析した．

3. 先行研究の概要
本章では，[18, 19] における分析内容と結果について
概説する．

3.1

分析内容

対象プロジェクト

[18, 19] では，大規模 OSS である Apache HTTP
Server プロジェクトにおける開発者メーリングリスト
から抽出したメールデータに対して Stanford Politenessを適用し，開発者の Politeness とプロジェクト離脱（あるいは継続性）との関係を理解するためのケーススタ
ディを実施した．分析対象は，プロジェクトが設立された 1995 年 9 月から 2016 年 3 月時点の約 21 年間分のメールデータである．
Apache HTTP Server プロジェクトを選択した主な理由は以下の通りである．
• 20 年以上存続しているプロジェクトでありコア開発者の中にも離脱者が多数存在すること
2 http://nlp.stanford.edu/software/lex-parser.shtml
3 http://en.wikipedia.org/wiki/Wikipedia:User pages
4 http://stackexchange.com/about

78

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Politeness 値：長期開発者 vs. 短期開発者

0

築できているため，Politeness を過度に意識する必要がない，あるいは，他人行儀な改まった態度を示す必要が

2000

2005

2010

2015

2000

2005

2010

Politeness

500
300

Mails

Politeness

Mails

100

的に参加する開発者は，他の開発者との良好な関係が構

Mails
Politeness

100の結果，長期開発者の Politeness は短期開発者よりも有意に低い値を示すことが分かった．プロジェクトに長期

Dev#2

300

500

Dev#1
Mails
Politeness0.0 0.2 0.4 0.6 0.8 1.0

結果の詳細については紙面の関係上割愛するが，検定

0

3.3.1

分析結果

0.0 0.2 0.4 0.6 0.8 1.0

3.3

2015

ないということが示唆される．

2010

2015

2000

0

プロットしたグラフを示す．青の折線が Politeness 値，

2000

赤の折線が投稿件数を示している．なお，単純に月毎に

2005

2010

2010

Politeness

2015

500
300
100

Mails

Mails
Politeness

0100の投稿に対する返信を含む）の Politeness 値を時系列にPolitenessMails

図 2 に，コア開発者が投稿したメール（他の開発者

2005

Dev#6

Mails
Politeness

300

500

コア開発者の Politeness 値の経時的変化

0.0 0.2 0.4 0.6 0.8 1.0

Dev#5

3.3.2

0.0 0.2 0.4 0.6 0.8 1.0

500
0

100

300

Mails
Politeness

2015

2000

2005

2010

Politeness

2005

Mails

300
0

2000

Politeness0.0 0.2 0.4 0.6 0.8 1.0

Dev#4

100

Mails

500

Dev#3
Mails
Politeness0.0 0.2 0.4 0.6 0.8 1.0

Ortu らの研究 [11, 10] では，不具合修正プロセスにおける開発者の Politeness と不具合修正時間との関係を分析しているが，高い Politeness 値を示す議論を通じて解決される不具合は比較的長い時間を要することが明らかになっており，本ケーススタディの結果とも共通する現象を捉えていると思われる．

2015

データを集計してプロットすると投稿件数の少ない期間

2000

2005

2010

Politeness

500
300
100

Mails

2015

0.0 0.2 0.4 0.6 0.8 1.0

2010

Politeness2005

0.0 0.2 0.4 0.6 0.8 1.0

0

2000

期間において活動（メール投稿）している開発者は存在

Mails
Politeness

0100

図 2 から見て取れるように，Dev#1 を除いて，コア開発者であっても分析対象である約 21 年間のすべてのPoliteness

500
Mails

平均をプロットしたグラフであることに注意されたい．

Mails
Politeness300

め，Politeness 値，メール件数ともに，3 か月間の移動

Dev#8
0.0 0.2 0.4 0.6 0.8 1.0

Dev#7の外れ値の影響を受けてグラフが読み取りづらくなるた2015

せず，どこかの時点でプロジェクトを離脱している．ま0から離脱したコア開発者のプロジェクト離脱６ヶ月前か

2000

2005

2010

2015

500
300
100

Mails

Mails
Politeness

0100に変動する開発者が確認された．表 3 に，プロジェクト

Politeness

500
Mails

特に，プロジェクトを離脱する際に Politeness 値が急激

Mails
Politeness300

時期により Politeness 値が変動することが確認された．

Dev#100.0 0.2 0.4 0.6 0.8 1.0

Dev#9

た，コア開発者間で Politeness 値に個人差があること，

2000

2005

2010

2015

ら離脱 3ヶ月前までの期間とプロジェクト離脱直前 3ヶ月間の期間のメール投稿数と Politeness 値の平均値を示す．
表 3 から，Dev#2，Dev#3，Dev#4，Dev#7，Dev#8，

図 2. コア開発者が投稿したメールの Politeness 値

Dev#10 の 6 名のコア開発者に関して，プロジェクト離
脱直前に 0.11〜0.20 の Politeness 値の変動（上昇，もしくは低下）が確認された．

の時系列変化（3ヶ月移動平均）

79

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 3. 離脱したコア開発者のメール投稿数と Politeness 値（月平均）(A) 離脱 6ヶ月前から離脱 3ヶ月前まで(B) 離脱直前 3ヶ月間
Politeness 値の変動 (B-A)
メール投稿数
Politeness 値
メール投稿数 Politeness 値

Dev#2

25.7

0.56

11.0

0.68

0.12

Dev#3

32.3

0.58

6.0

0.39

-0.19

Dev#4

15.7

0.66

0.3

0.73

0.07

Dev#5

4.0

0.49

3.0

0.48

-0.01

Dev#6

13.0

0.75

9.0

0.75

0.00

Dev#7

7.7

0.47

1.3

0.58

0.11

Dev#8

1.0

0.92

1.7

0.72

-0.20

Dev#9

13.0

0.64

0.7

0.66

0.02

Dev#10

2.7

0.54

0.3

0.40

-0.14

Politeness の急激な変動が開発者がプロジェクトを離脱する予兆なのであれば，開発者の離脱の予兆を検知する手法を構築する上での重要な手がかりとすることができる．離脱予兆の検知手法を確立できれば，プロジェク
ト管理者等が開発者の離脱を未然に阻止するための対策を講じることが可能になる．
3.4

目視による調査4

コア開発者がプロジェクトを離脱する直前に Politenessが大きく変動している理由を明らかにするために，開発者メーリングリストに投稿された離脱直前 3ヶ月間分のメールを目視により調査する．

4.1

先行研究の問題点

調査対象

図 2 に示したように，数年間プロジェクトに参加し対象開発者の離脱直前 3ヶ月間の以下の項目を調査対ているコア開発者であってもプロジェクトを離脱するこ象とし，Politeness の急激な変動とプロジェクト離脱理とが分かった．また，プロジェクトを離脱する直前には由を明らかにする．

Politeness 値が大きく変動する，すなわち，コア開発者のコミュニケーション内容の質が変化していることが分かった．
しかしながら，[18, 19] ではコア開発者の投稿内容までは詳細に分析できておらず，なぜ開発者の Politeness
値が急激に変動したのかについては不明なままである．
そのため，Politeness の急激な変動（コミュニケーショ
ンの質的変化）がプロジェクトの離脱の予兆と見なすことができるか，すなわち，Politeness の急激な変動と開発者の離脱との間に明確な関係が存在するのかが不透明である．
そのため本稿では，プロジェクト離脱の直前に Politeness の急激な変動を示したコア開発者の中から，Politeness 値が低下した開発者と Politeness 値が上昇した開発者をそれぞれ 1 名選定し，プロジェクト離脱の直前の開発者の投稿内容を目視により確認・分析する．

• 開発者が投稿した内容（メール本文）• 投稿の Politeness 値• 本文に含まれている Politeness Strategy
次に，3.3.2 頁で述べた Politeness 値が急激に変動した
開発者の中から調査対象者を選出する．表 3 より，Dev#4や Dev#10 は離脱直前 3ヶ月間に投稿したメール数が著
しく少ないことがわかる．同じ開発者が投稿したメールであっても，Politeness 値はメールによって大きく異なる
ため，Dev#4 や Dev#10 は外れ値によって Politeness 値の平均値が変動した可能性がある．そのため調査対象者
は，離脱したコア開発者のうち，投稿数の多い Dev#2 お
よび Dev#3 とする．Dev#2 は，離脱直前に Politenessが上昇しているパターンの開発者，Dev#3 は，離脱直前に Politeness が低下しているパターンの開発者である．
次節ではこれら 2 名の開発者を対象とした調査結果について詳しく述べる．

80

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4.2

れているため，ネガティブな文脈で使われる単語等にも調査結果

Politeness 値を大きく下げる効果があると思われる．
2 つ目の投稿は，Politeness 値を大きく下げる Politeness Strategy が含まれておらず，1 つ目の投稿と比較すると高い Politeness 値を示している．しかし，1 つ目の投稿と同様に，メモリリークを引き起こす変更に対して強く反対していることが読み取れる．また，1 つ目の投稿と同様に，相手のネガティブフェイスを明示的に侵害する表現がいくつか見られる．
3 つ目の投稿では，1st person よりも 2nd person のPoliteness Strategy が多用されている．また，Politeness
値を大きく下げる Politeness Strategy の Factuality (“infact”) も使用している．本文からは，メモリリークを引き起こす問題について強く相手を批判している様子が読み取れる．
これらのことから，この時期に Dev#3 には納得できない変更があり強く反対意見を述べた結果，Politeness
値を大きく下げることに繋がっていることが分かった．
したがって，この変更に関するプロジェクトの方針に賛同できなかったため，Dev#3 は直後にプロジェクトを離脱するという選択を取ったと思われる．

本節では，投稿内容を目視した結果について述べる．
まず，離脱直前に Politeness が低下しているパターンの開発者である Dev#3 の調査結果を示す．Politeness が急激に低下するということは，他の開発者のネガティブ
フェイスを侵害する表現が増えていることを意味しており，Dev#3 とその周辺の開発者の間に何らかの対立や緊張状態が生まれている可能性がある．
次に，離脱直前に Politeness が上昇しているパターンの開発者である Dev#2 の調査結果を示す．Politeness の上昇は，コミュニティに新たなメンバを迎える際，新人に友好的であることを古参メンバが示すための態度として我々の社会生活でも経験する事象であるが，Dev#2 の場合は直後に離脱している．これまで友好関係を築いていた他の古参メンバとの対立が生じたり，何らかの理由でコミュニティに一定の距離を取り始めた結果，「よそよ
そしく」なっている可能性がある．

4.2.1

Dev#3

表 4 に，Dev#3 の投稿内容の例，本文に含まれる Po-

liteness Strategy，および，本文の Politeness 値を示す．
プロジェクト離脱直近 3ヶ月分の Dev#3 の投稿をすべて目視した結果，この時期の Dev#3 は他の開発者と意見が折り合えず，口論にまで発展していることが分かった．口論の原因は，他の開発者が変更したコードに不具合が含まれていることを Dev#3 が指摘しているが，他の開発者からは理解が得られないといった状況によるものである．
例えば，表 4 の 1 つ目の投稿は，コードの変更によりメモリリークを生み出す可能性をその理由とともに指摘している．本文中に含まれる “actually” や “In fact” は，Politeness 値を大きく下げる Politeness Strategy である
Factuality（表 1 参照）に該当する．Politeness 値を上げる Politeness Strategy である 1st person や 1st person
start など（I, my, we など）も数多く含むが，Factualityの効果を相殺するほどではない．Politeness Strategy 以
外にも，“VERY big mistakes” や “too dangerous” といった相手のネガティブフェイスを損害する直接的な表現が目立つ．Stanford Politeness Corpus には，Politeness
Strategy 以外にも単語単位で人手による評価が加えら

4.2.2

Dev#2

表 5 に，Dev#2 の投稿内容の例，本文に含まれる Po-

liteness Strategy，および，本文の Politeness 値を示す．
プロジェクト離脱直近 3ヶ月分の Dev#2 の投稿をすべて目視した結果，Dev#2 がおこなった変更に関して
フィードバックした他の開発者に対する返信や，他の開発者の投稿したパッチに対して賞賛する内容の投稿が確認できた．
例えば，表 5 の 1 つ目の投稿は，パッチの投稿に感謝の意を伝えるためのものである．本文中に含まれる Politeness Strategy は Deference の “great” と Gratitudeの “thanks” のみであるが，それ以外の情報が少ないた
め高い Politeness 値を示している．
2 つ目の投稿は，他の開発者が作成したパッチに対して感謝の意を伝えるとともに，さらなるパッチの検証を
他の開発者に依頼するものである．Hedges や Gratitudeなど Politeness 値を大きく上げる Politeness Strategyが複数含まれている．一方，Politeness 値を大きく下げる Factuality（“really”）も含まれているが，前向きな文脈の中で使用されている（“I’d really prefer we ∼.”）

81

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 4. Dev#3 の投稿内容の例（本文中の太字は Politeness Strategy に該当）
id

本文

Politeness Strategy

スコア

1

I am actually pretty sure that allocating brigades out of the bucket allocator is a VERY big mistake. In
fact, I am close to asking that change to be backed out because it is too dangerous. When we first designed
buckets and bucket brigades, we made one VERY clear distinction. Bucket brigades are allocated out of apool, because that stops us from leaking memory. Buckets shouldn’t be allocated out of a pool, because nobody
knows which pool to allocate them from. Basically, we said that in Apache, it is safe to just drop a bucket
brigade because the pool cleanups will free the memory. It is not safe to just drop a bucket, it must either
be left on the brigade to be cleaned up by the brigade cleanup function, or it must be destroyed when it isremoved from the brigade. By allocating bucket brigades out of the bucket allocator, we have removed theprotection that the pool cleanups used to give us. I may be wrong about how the bucket allocator works,
but I don’t believe I am. Basically, this change will make Apache leak memory on some requests, and it goesagainst the original design of buckets and bucket brigades. In fact, allocating the brigades out of a pool wasa requirement, because some people at the meeting were afraid of memory leaks with bucket brigades.

Factuality, 1st person pl., 1st person,
1st person start

0.08

2

I am vetoing this change until I get a clear description of the problem it is solving. I have explained multiple
times why it is a bad change, but I can’t oﬀer any other solutions until I know why it is needed. It will not.
If you ever create a brigade with a NULL pool, you will have memory leaks. I dare say that every filter
ever written will leak if the feature implemented with this patch is ever used. I have already posted one code
segment in the core output filter that proves the memory leak exists. Trust me when I tell you that there are
hundreds more, and some of them are in 3rd party modules that you don’t control. ++1, but they should go
into an external library so that projects like serf have access to them. Happily, I don’t have to worry aboutthat.

1st person, 1st person start, 2nd person

0.38

3

No, that is a solution, in fact, it was part of the original design. What you’ve done is said “The brigade
may not live long enough”, but you haven’t explained how that is the case. You also haven’t explained why
moving the buckets to another brigade won’t work. Which I have a very hard time believing, because that is
how Apache works today. You also haven’t answered the problem that even WITH this change, you stillneed to move the buckets to a new brigade. At the end of the day, this change doesn’t get you anything,because you still have to do the brigade migration that you say you can’t do.

Factuality, 1st person, 2nd person, 2nd
person start

0.05

ため大きな影響はなかったと考えられる．結果として，分析対象とした．同様のパターンを持つ開発者は Dev#2

Politeness 値が 0.99 と非常に高い値を示しているものと思われる．
3 つ目の投稿では，メールクライアント Thunderbirdとプロバイダの相性から問題が生じ，メールの復旧作業に入るために活動をできないことをコミュニティに伝えている．また，他の開発者へのアドバイスも含まれており，
Gratitude や Apologizing，Hedges といった Politenessを上げる Politeness Strategy を多く含んでいる．
このように，表 5 以外のものを含めても，Dev#3 とは異なり Dev#2 の投稿内容からはプロジェクト離脱の予兆を示す言動を読み取ることはできなかった．しかしながら，Politeness の上昇後に離脱するという現象は不可解である．何らかの理由によりすでに離脱を決めている，あるいは，離脱しようとしている過程での人間の意
識の現れとも考えられるが推測の域を出ない．
コア開発者の離脱直前の 3ヶ月分のメールデータは 1
名で数十件を目視する必要があった．また，メールによって非常に長い本文を含む場合もあったため，本稿ではまず，Politeness が上昇したパターンを持つ Dev#2 のみを以外にも，Dev#4 や Dev#6，Dev#8 が該当するため，
今後はこれらの開発者の分析を進め離脱理由を明らかにしたい．ただし，いずれの開発者の離脱理由は投稿内
容からは読み取れない可能性もある．その場合は，他のプロジェクトを対象に追加分析をしたり，可能であれば離脱した開発者へのインタビューを実施し，Politenessの大きな上昇とプロジェクト離脱との関係を明らかにし
たい．

5

関連研究

Politeness 分析に関しては Ortu らの研究 [11, 10] が関連研究として挙げられる．OSS 開発で利用されている不具合管理システムのコメントデータに対し Politeness 分
析を適用し，開発者の Politeness と不具合修正時間の関係を分析したものである．分析の結果，Politeness の高いコメントが寄せられた不具合は，Politeness の低いコメントが寄せられた不具合よりも修正時間が長く必要となることを明らかにしている．3 章において述べたよう

82

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 5. Dev#2 の投稿内容の例（本文中の太字は Politeness Strategy に該当）
本文

id

スコア

Politeness Strategy
Gratitude,ence

Defer-

0.90

1

Looks great! Thanks for the patch :)2

Thanks for the feedback, Kaspar. Other than shifting the one #ifdef case to the correct line of code, I believe
the patch is complete, I’ve tried to state my case for no further changes. If you would like to propose further
changes, I’d really prefer we defer these to 2.2.24-dev so we can T&R already. I’m pretty sure you alreadyagree with me that the flexibility to disable a particular cipher in light of exploit research in the very fresh
openssl code base makes this patch pretty critical to release for legacy, as well as stable. Even if you can givethe patch your +1, we still need one more individual to chime in before we can finish this backport, and as
I mention, OpenSSL’s CVE-2012-2333 suggests that this patch is a showstopper. Can one more person take apass through the code, since Stefan didn’t have a chance to re-review this week?

Gratitude, Hedges,
Factuality, 1st person pl., 1st person,
2nd person

0.99

3

Sorry, I’m not ignoring the list (entirely). Seems Thunderbird and my ISP have decided not to dance anymore
and it looks like I’m spending Thursday doing some fundamental email restructuring (sigh). Hopefully I’ll havethe list traﬃc back sometime by Friday, thanks to Jeﬀ, Reindl, and Steﬀen for your review, I didn’t read
Ruediger, Rainer, or Jim as voting one way or another - even with my vote there is still a missing PMC +1 forrelease. Rainer, are your observations a regression? Because the security issues are relatively minor, I took
this opportunity to update to a slightly refreshed autoconf (not a radically new version, nor the last in thatversion minor which barfs on our configure. in and m4 files)... so it’s possible I had introduced this. If not aregression, please confirm.

Gratitude, Hedge,
Apologizing , 1st
person pl., 1st person, 2nd person,
Direct start

0.87に，Politeness の高いコミュニケーションは一見望ましの結果，Politeness が大きく低下した開発者はコミュニ

いように思われるが，問題を効率的に解決するという観ティ内で意見衝突をしていることが確認された．開発者

点では必ずしも必要ではなく，チームワークの高いチー

間の意見衝突は開発者のプロジェクト離脱を促す要因のムでしばしば見られるフランクな会話の方が良い場合が

1 つとして考えられるため，Politeness の大きな低下は開発者のプロジェクト離脱の予兆とみなすことができる．
プロジェクト管理者は Politeness が大きく低下した開発者に対してなんらかの処置をすることで，その開発者の離脱を未然に防止することができると考えられる．一方で，離脱直前に Politeness が大きく上昇した開発者は他の開発者に感謝をしていることが確認されたが，明確な離脱理由を見つけることはできなかった．そのため，プロジェクトの離脱と Politeness の上昇に普遍的関係が存在するかを明らかにするために，さらなる分析をおこなう必要がある．
今後の課題としては，本研究で分析した対象開発者以外の開発者に対しても分析をおこない，開発者のプロ
ジェクト離脱と Politeness の変動の関係についての知見を得たいと考えている．本研究では開発者の離脱直前の3ヶ月間を分析対象としたが，開発者の離脱の予兆を察知する期間として適切であるかは確かではない．今後より詳細な分析をおこない，開発者の離脱の予兆を察知するための適切な期間を明らかにしていきたい．

あることを示唆するものである．我々の先行研究においても [18, 19]，プロジェクトに長期間参加する開発者のPoliteness はその他の一般開発者に比べて統計的に有意に低いことを示しており，Ortu らの研究とは目的が異なるものの得られた知見は矛盾するものではない．
OSS プロジェクトへ参加する開発者の離脱阻止の支援という観点では，Steinmacher らの研究 [13, 14] が挙げられる．Steinmacher らの研究は，プロジェクトへこれから参加したいと考えている開発者の参入を妨げる要因について分析したものである．ドキュメントの不足や不親切な対応など，新人にとって障壁となる計 58 種類の要因を明らかにしている．本研究は古参メンバの離脱要因を理解し離脱の予兆を検知する手法を構築することを目的としており，アプローチが大きく異なるものの OSS
プロジェクトの安定運営の支援という観点では互いに補完しあうものである．

6. まとめと今後の課題
本研究では，開発者のプロジェクト離脱と Politenessの変動の関係を明らかにするために，Politeness の急激な変動を示したコア開発者のメールを目視した．目視

83

SEA

ソフトウェア・シンポジウム2017 in 宮崎

7. 謝辞[11] Marco Ortu, Giuseppe Destefanis, Mohamad Kassab,
Steve Counsell, Michele Marchesi, and Roberto
Tonelli. Would you mind fixing this issue? an empirical analysis of politeness and attractiveness in softwaredeveloped using agile boards. In 16th International
Conference on Agile Processes in Software Engineeringand Extreme Programming (XP 2015), pp. 129–140.
Springer International Publishing, Cham, Switzerland,
2015.

本研究の一部は，文部科学省科学研究補助金（基盤(C): 15K00101）による助成を受けた．

参考文献[1] John Anvik, Lyndon Hiew, and Gail. C. Murphy. Whoshould fix this bug? In Proceedings of the 28th international conference on Software engineering (ICSE ’06),
pp. 361–370, 2006.

[12] Jin-woo Park, Mu-Woong Lee, Jinhan Kim, Seungwon Hwang, and Sunghun Kim. Costriage: A costaware triage algorithm for bug reporting systems. In
Proceedings of the Twenty-Fifth AAAI Conference on
Artificial Intelligence (AAAI-11), pp. 139–144, 2011.

[2] Christian Bird, Alex Gourley, Prem Devanbu, Anand
Swaminathan, and Greta Hsu. Open borders? immigration in open source projects. In Proceedings ofthe 4th International Workshop on Mining Software
Repositories (MSR ’07), 2007.

[13] Igor Steinmacher, Tayana Uchoa Conte, Christoph
Treude, and Marco Aurélio Gerosa. Overcoming open
source project entry barriers with a portal for newcomers. In Proceedings of the 38th International Conference on Software Engineering (ICSE ’16), pp. 273–284,
2016.

[3] Penelope Brown and Stephen C Levinson. Politeness:
Some Universais in Language Usage. Cambridge University Press, Cambridge, UK, 1987.
[4] Cristian Danescu-Niculescu-Mizil, Moritz Sudhof, Dan
Jurafsky, Jure Leskovec, and Christopher Potts. A
computational approach to politeness with application
to social factors. In Proceedings of 51st Annual Meetingof the Association for Computational Linguistics (ACL’13), 2013.

[14] Igor Steinmacher, Tayana Conte, Marco Aurélio
Gerosa, and David Redmiles. Social barriers facedby newcomers placing their first contribution in open
source software projects. In Proceedings of the 18th
ACM Conference on Computer Supported Cooperative
Work & Social Computing (CSCW ’15), pp. 1379–
1392, 2015.

[5] Mohammad Gharehyazie, Daryl Posnett, Bogdan
Vasilescu, and Vladimir Filkov. Developer initiationand social interactions in oss: A case study of theapache software foundation. Empirical Software Engineering, Vol. 20, No. 5, pp. 1318–1353, 2015.

[15] Yunwen Ye and Kouichi Kishida. Toward an understanding of the motivation open source software developers. In Proceedings of the 25th International Conference on Software Engineering (ICSE ’03), pp. 419–429,
2003.

[6] Steve Gunn. Support vector machines for classification
and regression. Technical Report, School of Electronics and Computer Science, University of Southampton,
1998.

[16] Minghui Zhou and Audris Mockus. What make longterm contributors: Willingness and opportunity in oss
community. In Proceedings of the 34th International
Conference on Software Engineering (ICSE ’12), pp.
518–528, 2012.

[7] IPA（独立行政法人情報処理推進機構）. 第 3 回オープンソースソフトウェア活用ビジネス実態調査（2009 年度調査）, 2009.

[17] 宇佐美まゆみ. ポライトネスという概念. 月刊 言語,
Vol. 31, No. 1, pp. 100–105, 2002.
[18] 宮崎智己. OSS 開発における活動継続性と Politeness の関係. Technical report, 和歌山大学システム工学部 2016
年度卒業論文, 2017.

[8] Chris Jensen and Walt Scacchi. Role migration and advancement processes in ossd projects: A comparative
case study. In Proceedings of the 29th International
Conference on Software Engineering (ICSE ’07), ICSE
’07, pp. 364–374, 2007.

[19] 宮崎智己, 山谷陽亮, 東裕之輔, 大平雅雄. OSS 開発コミュ
ニティの進化の理解を目的としたコミュニケーション分
析：Politeness 分析適用の試み. 情報処理学会 マルチメ
ディア，分散，協調とモバイル (DICOMO2016) シンポ
ジウム論文集, pp. 703–713, 2016.

[9] Audris Mockus, Roy T Fielding, and James D. Herbsleb. Two case studies of open source software development: Apache and mozilla. ACM Transactions
on Software Engineering and Methodology (TOSEM),
Vol. 11, No. 3, pp. 309–346, 2002.
[10] Marco Ortu, Bram Adams, Giuseppe Destefanis,
Parastou Tourani, Michele Marchesi, and Roberto
Tonelli. Are bullies more productive?: Empirical study
of aﬀectiveness vs. issue fixing time. In Proceedingsof the 12th Working Conference on Mining Software
Repositories (MSR ’15), pp. 303–313, 2015.

84

SEA

ソフトウェア・シンポジウム2017 in 宮崎

OSS 事前評価による開発リスク特定の取組み
岩崎 孝司 高山 修一 岩永 裕史
富士通九州ネットワークテクノロジーズ㈱Iwasaki.takashi@jp.fujitsu.com
takayama_@jp.fujitsu.com
iwanaga_hiroshi@jp.fujitsu.com

鵜林 尚靖 亀井 靖高
九州大学ubayashi@ait.kyushu-u.ac.jp
kamei@ait.kyushu-u.ac.jp

要旨

コスト増大等のプロジェクト全体の問題になってしまう様な事態も発生しており、開発初期のリスク管理が重要視されている。
その様な OSS 利用時の問題に対応する技術として、開発開始前や開発工程前半で OSS 利用時のリスクを判断する OSS 事前評価手法[2-7]がある。OSS 事前評価手法は企業向け情報サービスやＩＴソリューションを提供する企業では普及しつつあり、世の中では事前評価を含む
コンサルタント業務をビジネスとして行う会社もある。一方、
富士通 QNET を含む設計開発会社では事前評価手法は存在するものの十分に普及、運用されていない状況である。本研究では、OSS 事前評価指標を開発現場に浸透させるため、普及、運用を考慮した OSS 事前評価手法を考案した。普及、運用の課題については第二章で詳細を述べる.
(2) OSS 研究の状況
OSS を実際に利用する前に評価する事前評価技術の研究は 2010 年までに多く取り組まれ、その有効性が評価されてきた[2-7]。同時に事前評価を正しく実施するための開発プロセスの研究やツール開発も積極的に取り組みが行われた[8-10]。 現在ではソフトウェア工学の１つの独立した研究分野として「オープンソフトウェア工学」が提唱されソースコードの評価やプロセスに留まらず、OSS
コミュニティの人的リソースの相互関係やビジネスモデルの研究が行われており、事前評価技術を含む、多面的な観点での研究となっている[13]。
(3) 論文の構成
以降、本論文の第二章では OSS の事前評価の課題を、開発現場での普及、運用の観点を含めて述べる。第三章では開発現場への普及を目的に、本手法を開発者が持つ品質要求を元に OSS 事前評価を行う手法とした事を述べる。第四章では、事前評価指標を品質要求に結び付けたやり方について、本手法での実現方法を述べる。第五章では本手法の全体像を実施手順、スコアリ
ングルール、事前評価の結果作成されるレポートの例で紹介する。第六章では本手法を既存の開発プロジェクトを元に検証した結果、手法により、抽出したリスクがプロジェクトで発生した問題に対応しており、評価手法が有

昨今のソフトウェア開発において、OSS を利用した開発が徐々に増えてきている。また、利用した OSS に起因する問題が開発後半で発生し、開発コスト増や納期遅延といった問題が発生することも珍しくない。OSS を利用す
る前に OSS の利用リスクを判断する事前評価の技術や開発プロセスは既存の研究でも実施されてきたが、開発現場で一般的に活用されるには至っていない。本研究では開発現場への導入を主眼に置き、開発者が OSS を利用する際に意識している品質要求から OSS の利用リスクを判断できる OSS 事前評価手法を考案した。本手法は、品質要求と OSS を事前に評価した事前評価指標を関連付け、開発者にリスク評価結果を示す事前評価レポートを作成する手法とした。考案した手法を、当社内で実際に開発を行ったプロジェクトに対して適用し、リスクの事
前評価結果と実際の開発で発生した OSS 利用時の問題を比較した。結果、今回試行の対象としたプロジェクトで実際に発生した問題に対しては、本手法を用いてリスクを検知できる事を確認した。

1. 背景(1) 企業での OSS 利用状況
近年のソフトウェア開発において、OSS(Open Source
Software)を利用した開発が一般化しつつある。全国のソフトウェア関連企業の 50%を超える企業で OSS を利用した開発が行われている[1]。ＷＥＢ系システム構築や企業向けの情報システムの様な一般的な情報システムの構築に加えて、通信ネットワークシステムやＩｏＴ（Internetof Things）システムの様な組込みシステムの開発においても、OSS を用いた開発が急増している。富士通九州ネットワークテクノロジーズ株式会社（以降、富士通 QNET）
社内の場合でも年々OSS の利用率が上昇し、最近では
約 50%のプロジェクトで OSS を利用した開発が行われている[11]。
OSS を利用したプロジェクトの問題として、利用した
OSS の問題が開発工程後半で発覚し、納期遅延や開発

85

SEA

ソフトウェア・シンポジウム2017 in 宮崎

効であったことを述べる。第七、八章にて、本研究のまとめと今後の課題を述べる。

表１．品質要求カテゴリと品質要求

2. OSS 事前評価手法の課題
OSS を利用する前に OSS の利用リスクを予測する OSS
事前評価手法は、OSS 利用の拡大とともに重要視されてきている。OSS 事前評価技術やプロセスの適用は、一部では普及しているが、組込み開発を中心として、設計開発を実施する会社では、必ずしも普及しておらず組織的な運用に至っていないのが現状である。
本研究で、現在の評価方法の問題を確認するため、OSS 事前評価を実施する既存の評価モデルである、
QSOS[2]、OpenBRR[8]、RepOSS[4]、 OMM[10] の調査を実施した結果、「用語がおおまかで曖昧」，「スコアリングルールが曖昧な項目が半数」，「公開されたリポジトリがない」といった課題を認識した[11]。また、開発現場に
事前評価手法が普及しない理由を以下の様に考察した。
・開発者は、提示された事前評価指標を１つ１つ解釈
し、開発者自身が持つ品質要求と結び付けてリスク分析をしなければならない。そのため、リスク評価が開発者の能力に依存する。
・評価方法が曖昧で理解しづらい。例えば、既存研究では「ユーザビリティ」（使用性）という項目があるが、お客様の使い勝手を指すのか、OSS 自体の使い勝手を指すのか、一見して分かりづらい。
・事前評価指標が多種であり、全評価指標を調査し、検討するにはコストがかかり過ぎる。
・開発する製品の要求性能や要求品質により OSS への要求性能や要求品質が変わるため、事前評価が一意には評価できない
これらの課題から、OSS 事前評価手法開発の課題を以下とした。
(1) 開発現場が理解しやすい手法の確立
OSS 事前評価時の観点を開発者側から見た品質要求で定義して、開発者が理解しやすい評価手法を開発する事にした。例えば、「ユーザビリティ」は、開発者からみた OSS の使い勝手と、システムの利用者から見た使い勝
手の品質要求に分けて定義し、開発者が理解しやすい評価手法とした。詳細は表 2 を参照、ユーザビリティの例
は使用性に対応している。
また設計開発の場合は、開発者の利用する OSS に対する品質要求は開発するシステムや製品によって異なる
ため、品質要求のレベルも異なってくる。これらの異なる
品質要求レベルに対応できる手法とする。

86(2) 事前評価作業のコストの明確化と削減
OSS を利用する開発者は開発コスト削減や開発スピード向上を目的としており、事前評価作業や指標取得を実施する事に大きな負担を感じている。開発者の負担を軽減するためにも、事前評価作業におけるコストの明確化を図る共に、不要な作業を除去して、より小さなコストで評価を実施できる手法とする。
(3) 個人のスキルに依存しない事前評価作業の実現
従来研究の評価モデルでは、事前評価指標と OSS の品質要求を、開発者が自身の知識やスキルを元に対応させ評価する必要があった。本手法は開発者の知識やスキルに依存せず、一定の精度で利用する OSS のリスクを予測できる手法とする。

3. OSS 利用者の品質要求について
本手法を、開発者の品質要求から OSS の利用リスクを判断できる手法とするため、開発者の OSS 品質要求としてどの様な要求事項があるかを抽出した。
品質要求を抽出する際の観点としては、システム・ソフ
トウェア製品品質（JIS X 25010：2013）の品質要求のカテゴリを参考として、表 1 の７つの分類を採用し、OSS 利用の観点から各カテゴリに対応する品質要求を定義した。
具体的な品質要求の抽出に当たっては、研究チームの企業と大学側で、役割分担してまずは素案を作成した。
企業側からは、OSS を利用した開発を行っている開発者（開発経験 10 年前後）複数名で実際の開発現場での品質要求をカテゴリ毎に抽出した。大学側は、先例の研究
により明確になっている事前評価指標（表３参照）[11]から類推される品質要求を抽出して品質要求の素案とした。
次に、作成した品質要求の素案を元に当社の開発プ
ロジェクトのメンバにヒアリングを実施した。ヒアリングの範囲としては、8 プロジェクトの開発リーダ、開発担当の技術者を対象とした。ヒアリングにより追加された品質要求は25 項目挙がったが、各カテゴリにより、項目数のばらつき

SEAソフトウェア・シンポジウム2017 in 宮崎

表２．カテゴリ毎の品質要求項目

図１ 品質要求のアンケート結果

があり、1 項目しか品質要求が挙がらなかったカテゴリもあれば、7 項目以上品質要求が挙がったカテゴリもあった。
項目数を極力そろえるため、類似項目の統合や有識者による再検討を経て、各カテゴリの品質要求項目を 2～4
項目に見直し整理した。整理後の品質要求を表 2 に示す。
抽出した品質要求について当社において過去１年間
で OSS を利用した開発リーダ（述べ 50 名）に対して、品質要求の重視度のアンケート調査を実施した。アンケー
トは、各品質要求に対しての重視度を、5:重視する 4:やや重視する 2:やや重視しない 1:重視しないの４段階で開発リーダに選択させた。
アンケート結果を図１に示す。アンケート時点の品質項
目数は 23 件（後の整理統合により、最終的には表 2 に示す 19 件となった）であり、23 件中、ほとんどの項目は 3点以上の評価結果となり、半分以上の項目は 4 点以上（重視する、やや重視する）という結果になった。
これらの結果により、定義した品質要求は、開発現場での品質要求を適切に捉えたものであると判断した。
一方、平均値として相対的に低い値となった品質要求

87

が 4 項目存在した。それぞれ「OSS のリリースが迅速で早期に機能を利用できる」（品質要求 b）、「OSS のプログラ
ム構造が容易でホワイトボックス化しやすい」（品質要求u）、「ソースコード中のコメントが豊富で読解性が良い」（品質要求 v）,「他の代替可能な OSS がある」(品質要求w)であった。
品質要求 b については、既に OSS を開発母体に使用しており、早期の機能提供より OSS も安定を重要視する
プロジェクトで低く評価された。当社の開発の多くはこの様な派生開発であることが平均値を低くした要因として挙げられる。ただし、先進分野(IoT 等）の新規開発においては、技術の進化速度が速く、リリースの迅速性を重視する開発も存在するため、品質要求として有益であると判断した。
品質要求 u,v については、OSS の利用方法によりプロ
ジェクトの回答が分かれており、OSS をブラックボックスで利用するプロジェクトは重視度低く評価する傾向があり、改造して利用するプロジェクトは重視度を高く評価する傾向があった。OSS を改造して利用するプロジェクトが存在する事に加え、元々ブラックボックスで利用を計画していたプロジェクトでも結果的にコード解析や改造が必要になることを鑑み、品質要求としては有益であると判断した。
品質要求 w については、そもそも OSS の代替が念頭にないプロジェクトが多く存在した事が原因と考えられる。
これは、派生開発の特徴に加え OSS の選択を顧客からの指定で決定されるプロジェクトが、品質要求の重視度を低く評価した事が原因であった。ただし、複数の OSS候補に対して可能性を配慮することは、選択した OSS に
大きなリスクが発生した場合には不可欠な品質要求となりえるため、開発者へ啓蒙の意味があると判断してそのまま採用した。

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表３ RepOSS による事前評価指標の分類

表４．品質要求カテゴリと採用した事前評価指標

表３は日本 OSS 推進フォーラムプレスリリースを出展に作成 http://ossforum.jp/node/126

4. 品質要求項目と事前評価指標の対応

特に、本研究の先行調査で、書籍数、Web サイト数、MaxNesting（ネスト数）、複雑度に関するソフトウェアメトリ
ックス(5 種)の事前評価指標は OSS の品質と相関関係が深い事が確認されており[11]、該当する品質カテゴリの評
価に結び付けることにした。
複雑度については、 5 種類の指標の相関関係がほぼ同一であったため、代表的な指標である AvgCyclomaticのみを採用した。
先行研究で研究された事前評価指標(RepOSS)とソフ
トウェアメトリックス(Understand)の事前評価指標を品質要求と対応付した結果、使用性の中にある書籍やドキュメ
ントに関する品質要求や、信頼性にある OSS 自体のバグに関する情報やコミュニティの活動状況に保守性に関するリスク評価は、RepOSS の事前評価指標やメトリックス値と対応付ける事ができた。
しかし、品質要求によっては、品質要求を満たせる事
前評価指標が存在しないものも発生した。性能や使用性のカテゴリに、そのままでは、事前評価指標が対応できな
い品質要求が存在した。
性能では、「OSS が指定された性能を満たす事ができる」や「性能測定のための環境作りが容易にできる」の品
質要求がこれに相当し、使用性では「正常系が正しく動作しており，早期に機能を確認できる」が相当する。本来、対応する指標がないという事はリスクを判断する材料がな
く、リスク有との判断をしてリスク管理の対象とするやり方が一般的である。今回の手法では極力、事前評価指標
を品質要求に結び付ける事にした。例えば、「正常系が正しく動作しており，早期に機能を確認できる」について抽出した品質要求項目と、品質要求を評価可能な事
前評価指標の対応付けを行った。対応付けの母集団として採用した事前評価指標は、過去の研究で提案された
事前評価指標とソースコードの静的解析ツールで計測したソースコードメトリックス値とした。今回の研究ではコード解析ツールとし TechMatrix 社の Understand を採用した。
過去の研究で提案された事前評価指標は、日本ＯＳＳ
推進フォーラムが提供するオープンソースソフトウェア評
価情報リポジトリ（RepOSS）の事前評価指標を採用した。
これは他の研究組織の提唱する事前評価指標と比較し多種であり、系統立てて事前評価指標が定義されていたためであった。
加えて、Understand を用いて、オープンソースコードのソフトウェアメトリックスを計測した。Understand は、ソース
コードを解析し、100 種類に及ぶソフトウェアメトリクスを計測可能である。ソフトウェアメトリックスには、複雑度を表すサイクロマチック複雑度や、結合性を表わす LCOM(結合性の欠如)、CBO（結合されクラスの数）、規模を表す
LOC(コード行数)などが含まれる[11]。
これらの事前評価指標と抽出した品質要求の関連付けを実施した。表 4 に対応付けを行った品質評価指標の例と品質要求のカテゴリを示す。

88

SEA

ソフトウェア・シンポジウム2017 in 宮崎

は、多くのユーザに利用される OSS であれば、正常系動作が保証されている可能性は高いと考え、ダウンロード
数や世の中の利用実績を関連指標として対応付けた。
しかしながら、ダウンロード数や世の中の利用実績が示す結果が良好であっても、品質要求が満たされるとは限らないため、結び付けた品質要求に対する事前評価
指標の関連度を設定した。
品質要求に評価指標が直接関連する場合は関連度大(5点)とし、直接的に関連しないが、品質要求に何らかの関連があるものは、関連度を関連中(3 点）、関連小(1 点）として対応付けを実施した。
性能については、既存の事前評価指標には対応する
評価指標は見つからなかった。例えば、他の導入事例等
で性能に関する情報があっても、システムが動作する環
境が違っていたり、性能評価のデータ自体が大変古いものであったりと有効に利用できないものが多かった。そこで、社内の利用実績やノウハウといった社内情報を評価
指標に組み入れる事にした。これによって、実績の有無、件数に加えて、社内情報ならではの OSS を利用したシステムの特性や動作環境等の情報が把握でき、定性的に性能のリスクを検討できる可能性がある考えた。
最終的に採用した評価指標を表 5 に示す。以上の様に、当初 200 個強あった事前評価指標を今回抽出した
品質要求に関連するもののみに絞り込んで、事前評価の仕組みに盛り込んだ。

表 5 採用した事前評価指標

5.1. 手法の実施手順
OSS を利用して開発を行うプロジェクトでは、開発開始前に以下の手順で OSS の事前評価を行う。
(1) 品質要求アンケートの作成
OSS への品質要求の重視度を開発者の判断で記載する。重視度としては、重視する。やや重視する。やや重視しない。重視しない。の 4 段階の評価とした。
(2) 事前評価指標の算出研究に先駆け当社で過去利用した OSS 約 120 種に
つ い て 、 大 学 側 で 一 般 的 な OSS 事 前 評 価 指 標(RepOSS)とソフトウェアメトリックスについて、算出を行い、データベース化を実施した。
評価したい OSS の事前評価データがデータベース中にあれば、算出作業は不要であるが、データベース中になければ、新たに調査を実施して事前評価データを算出する。
(3) スコアリング
品質要求毎に予め事前評価指標を対応付けており品
質要求毎のスコアが算出される。
(4) 事前評価レポートの作成
品質要求毎に品質要求の重視度と事前評価指標のスコアを開発者にレポート形式で通知する。開発者は品質要求の重視度に対して、事前評価のスコアが下回る場合、品質要求にリスク有と判断できる。

5. OSS 事前評価手法について
本研究の OSS 事前評価手法は、開発者が利用する
OSS への品質要件により変動する開発リスクを予め判断し、開発計画に反映するための手法である。従来手法と比べて、以下の特徴を持つものとした。
・開発者が OSS 利用時に意識している品質要求毎にリスク予測が可能となり、開発者の視点に近いリスク特定が可能となる。
・開発者が特別な知識やトレーニングなしに、一定のリスクを予測可能となる。
・開発者が複数の品質要求側面から網羅的に品質リスクを判断できる様になる。

5.2. スコアリングルール
スコアリングを実施するに当たり、開発者が理解し易い
様に、5 点満点で評価する様にした。
スコアは品質要求とそれらのカテゴリ毎に集計される。
ここで品質要求 Qi(i=1～n)は、そのカテゴリ内で、図１に示したアンケート結果によって重みづけられる。重み付けの方法は、カテゴリに属する品質要求に対して、アンケー
トの結果から各品質要求の重みの合計が 100%となる様に、重み付けを行った。ただし重み付けについては厳密

89

SEA

ソフトウェア・シンポジウム2017 in 宮崎には計算せずに、5%もしくは 10%単位で重み付けを実施した。
例えば、「機能適合性」の 3 つの品質要求の重視度の平均値は、「OSS 自身が実現したい機能を満たしている」
は 5、「OSS のリリースが迅速で早期に機能を利用できる」
は 2.6、「正常系が正しく動作しており，早期に機能を確認できる」は 4.8 であった。これらの平均値からそれぞれの項目の重み(Bi)は、それぞれ 40%,20%.40%とした。
品質要求のカテゴリ毎の品質要求値(QV)は、品質要求の値(Qi)に重みを考慮し,以下の式で算出した。また、
図２にスコアリングルールを示す。

図 2 品質要求カテゴリのスコアリングルール

QV= ∑𝑛𝑖=1(𝑄𝑖 ∗ 𝐵𝑖)
品質要求に対するカテゴリ毎の事前評価指標のスコア(SV)も品質要求値のカテゴリ値(QV)と同様の重み(Bi)で算出した。品質要求毎の事前評価データのスコアを(Si)とするとき、品質要求カテゴリでの事前評価データのスコア(SV)は、以下の式で算出した。
SV= ∑𝑛𝑖=1(𝑆𝑖 ∗ 𝐵𝑖)
ここで各々の品質要求に対する事前評価データのス
コア値(Si)は、複数の関連する事前評価指標より、算出される。品質要求に対応するそれぞれの事前評価指標に対して、品質要求に対する関連度(Ri)を決定した。関連
度は、5 点満点として、関連大 5 点、中 3 点、小 1 点とした。それぞれの事前評価指標のスコア(Ei)は、5 点満点とし、指標毎にスコアの決定方法を定めた。例えば、書籍数や WEB サイト数の様に数値化可能なデータは、相対的に 5 段階評価でスコアを決定した。マニュアルの有無
等の２極値であるものは、1 点、5 点とした。またデータ取得ができなかった場合は、スコアを 0 点とした。
事前評価指標の品質要求ごとのスコアは以下の式とした。
また、図 3 にスコアリングルールを示す。
Si =∑𝑚
1=1(𝐸𝑖∗𝑅𝑖/5)(𝑚−𝑚0 )

※m は品質要求に結びついた事前評価データの数、m0 は Ei=0 データ取得不能で評価できなかった事前評価指標の数を示す。

5.3. 事前評価レポート
開発者から見た品質要求と事前評価指標によるスコアリ
ング結果から、OSS の事前評価レポートを作成し、開発

90

図 3 事前評価値のスコアリングルール
前にＯＳＳ利用時のリスクを特定できる様にした。事前評
価レポートは、OSS の全体像を示す総括パートと個別の品質要求のスコアを示す品質要求評価パートの 2 つで構成される。
総括パート（図 4 参照）では、OSS 基本情報①として、
OSS の公開ディレクトリやライセンス情報や機能概要が示される。総合判定チェック②として、各品質要求カテゴリのレーダチャートが記載される。レーダチャートでは、品質要求に対する期待度と事前評価指標によるスコアがカ
テゴリ毎に正規化され、レーダチャートの形状から、要求に対する期待度とスコアの関係が判断できる様になっている。ここで、事前評価指標のデータが一切取得できず、
事前評価の評価値が決定できなかったカテゴリについて
は、スコア値を 0 としてレーダチャート上に表示した。レー
ダチャート上は要求を大きく下回る結果となり、リスク項目として表示される。
③に社内での OSS の利用状況、問題発生状況、社内ノウハウの一覧が表示される。
品質要求パート(表 6 参照)では、品質要求カテゴリ④毎に、品質要求⑤に対して、開発者が選択した重視度⑥と事前評価データによりスコアリングした事前評価スコ
ア⑦（評点）が記載される。これらの品質要求毎のスコアを品質要求の重み付けを加味してカテゴリの重視度と価値を求め、（算出方法は 5.2 スコアリングルールを参照）、
カテゴリ評価⑧とした。総合評価⑨は。カテゴリ評価の重視度と評価値を比較し、評価値が重視度以上であれば○：リスク低、評価値が重視度より低く差が 2 点以下であれば△：リスク中、2 点より大きければ、×；リスク大とした。

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 6 事前評価レポート 品質要求パート

図 4．事前評価レポートの例 総括パート
ここで△と×の閾値 2 点は 5 段階評価の中間点(1,3,5)の間隔から設定した。閾値の正当性については検討の余地があったが、後のトライアル結果を見て判断する事にした。総合評価が△、×の品要求項目については、評価結果に関する理由をコメント⑩として記載し、特に原因となった事前評価指標の内容を記載した

表 7 発生した OSS 利用時の問題

6 事前評価手法のトライアルと評価結果の工数が発生した問題（問題 2）や初期調査が不完全であったため、開発後半でハードウェアの互換性が発生した問題（問題 3）がそれに当たる。これらの問題も何らかのリスク管理ができていれば、開発工程遅延や予定外の対応工数が不要であったと考え、問題として抽出した。
問題 1,2 は、問題の原因が OSS1,OSS2 のインターフェ
ースや処理手順にあり、問題の解決には、OSS1,OSS2 双方の修正が必要となったため、両 OSS の問題とした。
問題 1 の内容は、OSS の処理に不要な処理が入っており、動作は正常に動作するが、システムの要求性能に至らかったという事象であった。また不要な処理を除去するために OSS の改造を実施したが、OSS の内容理解に多くの時間を費やすことになり、工程遅延を招いた。
問題 2 は、OSS の機能を利用する際、必要なパラメー
タ設定などのドキュメントやサンプルコードが不足しており、利用方法が不明であった。利用方法を理解するため、OSS 内部の解析に多くの時間を費やす事になった。
問題 3 は、OSS を利用した際、システムで利用するハードウェアに対応していないことが工程途中で判明し対応を実施しなければならなかった。この問題も急遽 OSSを解析して、独自の改造を実施した。
各問題ともに、直接の原因に対応する品質要求に加えて、「実現したい機能を実現できる。」とソースコードの解析で苦労をしたことから、ドキュメントやホワイトボックス化に対する品質要求が問題発生の品質要求として挙げられた。

研究した事前評価手法を用いて、事前評価手法の効果を評価した。評価対象として、2015 年度下期から 2016年度上期に開発を完了したプロジェクト 12PRJ の内、任意の 4PRJ を対象とした。1 プロジェクトで複数の OSS を利用している場合があり、評価対象となった OSS は 6 種類であった。
トライアルは、開発メンバにより、品質要求の重視度を回答してもらい、トライアル実施チームにより、事前評価レ
ポートを実施し、作成した事前評価レポートを元に実際に開発を実施した開発メンバとレビューを行い、事前評
価レポートと開発実績を比較する事で実施した。
開発実績で問題が発生した項目は、事前評価時のリ
スクがどの様に検知されたかを確認するため、原因のレビューを実施した。また、カテゴリ毎に評価として、事前評
価レポートを元に、カテゴリ毎にリスク予測と開発実績を比較した。開発実績は、品質要求のカテゴリ毎に○：問
題発生はなかった。△：問題までは至らないが、ＯＳＳ導入に課題があった。×：ＯＳＳ利用の問題が発生した。の三段階で評価した。
6.1 発生した OSS 利用時の問題とリスク検出の調査結果
今回のトライアルで評価を実施した OSS6 種について、延べ 5 件の OSS 利用時の問題が顕在化した。ここで挙げる問題については、OSS の機能的な障害(バグ)に加えて、OSS 利用時の問題を含んでいる。例えば、OSS の機
能自体に問題はないが OSS の利用方法調査に想定外

91

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 8 発生問題と品質要求の対応

表 9 性能の品質要求評価の詳細

表 10 使用性の品質評価の詳細

表 11 互換性の品質評価の詳細

表 8 に問題発生に関連があった品質要求の一覧と事
前評価の結果を示す。延べ 14 種の大半にあたる 12 種の品質評価指標でリスク大（×）の評価であった。
問題１の直接原因と対応する品質要求の評価詳細を
表 9 に示す。性能については、社内での利用実績とノウハウで評価しており、利用実績無しの場合の評価は１、ありの場合は 3、類似システムでの利用有りの場合 5 の評価とした。ノウハウも同様に 1、3 として、ノウハウに性能の記述がある場合を 5 とした。これらのデータに品質指標との関連度を 5 点満点で設定し、5.2 項に示すスコアリング
ルールで計算した結果が関連度反映後のスコアとなる。
いずれの OSS もノウハウ、実績もほぼないため、関連度
反映後のスコアは 1.2、0.6 と大変低くなっており、要求の重視度 4 を大きく下回っている。これにより、リスク大（×）との評価結果となり、問題 1 の発生リスクを抽出できた。
問題 2 の直接原因と対応する品質要求の評価詳細を
表 10 に示す。品質要求は、5 つの事前評価指標で評価される。WEB サイト数、書籍数、SLIDESHARE は、当社
でデータを収集した全 OSS の事前評価指標から相対的に 1～5 点でスコアを算出している。マニュアルやユーザ会については有無で 1 点もしくは 5 点の評価としている。
問題 1 の例と同様に関連度反映後のスコアを算出した結果は、それぞれ、3、2.5 であった。要求の重視度は 5 であり、OSS2 はリスク大、OSS1 はぎりぎりの点数リスク中と評価された。OSS1,2 共にほぼ問題 2 の発生リスクを抽出できた。
問題 3 の直接原因と対応する品質要求の評価詳細を
表 11 に示す。互換性については、OSS のバージョン互

換性と複数ハードウェアの対応で評価した。評価の詳細を表 11 に示す。複数バージョンの対応は、対応していた
ため 5 点となった。複数ハードウェア対応は、OSS3 は対応していないため、1 点となった。関連度は 3 であり、スコ
アは 1.5 点となった。結果、品質要求の重視度 4 に対して下回っており、問題 3 の発生リスクを抽出できた。更に、機能適合性や保守性についても、同様に事前評価結果を確認して、問題に対するリスクを抽出できたことを確認した。
6.2 品質カテゴリ毎の評価
次に、作成した事前評価レポートを元にトライアルチームが開発チームに開発時の問題発生状況をヒアリングした。ヒアリング時には、開発チームの回答がリスク予測
結果に左右されない様、カテゴリ毎のリスク予測結果は伏せて、カテゴリ毎の問題発生状況を、問題発生、多少問題あり（多少問題があったのもの開発に大きな支障はなかった）、問題なしの 3 択で回答して貰った。表 12 に
事前評価レポートでのリスク判断件数と開発チームでのヒ
アリング結果を示す。
リスク予測と開発チームの評価を比較した件数の集計結果を以下に示す。
・リスク予測が実績評価と一致した件数 17 件
・リスク予測より実績評価と悪化した件数 2 件
・リスク予測より評価と好転した件数 22 件
(1) リスク予測が実績評価と一致したカテゴリの分析
リスク予測が評価と一致したカテゴリは、6.1 項で述べた
リスク予測が問題として顕在化したカテゴリ 10 個に加え

92

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 12 品質カテゴリ毎のリスク予測と開発チームでの評価

表 14 機能適合性カテゴリの事前評価詳細

表 15 OSS 毎のリスク予測＞実績のカテゴリ件数

表 13

リスク低で、問題が発生しなかったカテゴリて、リスク低で問題が発生しなかったカテゴリ 5 個とリスク中で多少問題があったカテゴリ 2 個であった。
リスク低で、問題が発生しなかったカテゴリの評価を表 13に示す。いずれもカテゴリについての重視度が低く、開発者から見ても問題の顕在化の可能性が薄い品質要求であった。予測通り、問題は発生せず、リスク予測と結果が一致した。
リスク中で多少問題があった２カテゴリは、問題 2 に関連するカテゴリであった。
開発チームは、OSS1,2 の信頼性のカテゴリを多少問題ありと評価した。これは問題 2 の対応中にソースコード
を解析し、ソースコードの構造が大変複雑であった事か
ら開発上では問題ないものの、OSS の品質に開発チームが懸念を持った事から、多少問題ありの評価となった。
信頼性に対する事前評価結果もリスク中との結果となっており、正しくリスク予測ができたと判断した(2) 事前評価より結果が悪化したカテゴリの分析
事前評価より、結果が悪くなってしまった 2 項目については、リスクが高いにも関わらず、リスクに対する配慮が低下してしまう可能性があるため、重要な問題と認識した。
その原因として、問題発生に対応した品質要求のリスク
評価結果はリスク大であるものの、同一カテゴリの他の品質要求の評価結果がさほど悪くなかったため、カテゴリとしてのスコアが良くなってしまった事が挙げられる。
表 14 に該当カテゴリの 1 つである機能適合性カテゴリの事前評価詳細を示す。問題発生に関連する品質要求
は「実現したい機能が実現できる。」であり、これはリスク大との判定結果であったが、残る 2 つカテゴリの内、１個がリスク低であり、カテゴリ全体としては、リスク中の判定と
なった。

93

現在のカテゴリ評価は品質要求の重み付けでスコアを計算し判定しているが、これに加えて、カテゴリ内品質要求のリスク大の有無を考慮して、リスク大の項目がある場
合、カテゴリ評価をリスク大にするといったカテゴリ評価方法の改善が必要と考えた。
(3)事前評価結果より結果が良好なカテゴリの分析
事前評価でリスク有と判断したが、問題なしとなったカ
テゴリが 22 個存在した。
リスク管理において顕在化しないリスクも当然あり得る
ため、事前評価結果より結果が好転することは止むを得ないが、不要なリスク項目が数多くある場合、開発者に余計な負担がかかってしまう。また多数のリスクがある場合、重点的に扱われるリスクを明確にするためにも、リスクの検出の精度を向上させる必要があると判断し、リスク予測
より結果が向上した品質カテゴリの分析を行った。
分析の結果、大きく 2 つの原因があると分析した。
1 つ目は、OSS 評価方法の問題である。表 15 に、OSS 毎の問題発生の有無、リスク予測より実績が向上したカテゴ
リ数ならびに、事前評価レポートに記載された OSS の利
用実績件数を示す。
OSS(OSS1～3)は、リスクが顕在化して、問題が発生した OSS であり、当然リスク予測の精度が上がっている。一方問題発生がなかった OSS は、ほとんどの品質カテゴリ
でリスク予測より、実績が向上しており、過剰にリスクを予測した結果になった。
OSS1～3 は、社内では新規導入（もしくは導入実績が少ない）が OSS4-6 は、社内の利用実績が比較的多く、
複数のプロジェクトで使われており、従来の使い方であれば新たな問題が発生することは稀である。今回のトライア
ルでも OSS4-6 について問題発生はなく、予測したリスクも顕在化することはなかった。
利用実績が少なからず OSS リスク予測に有効な事は理解していて評価指標に盛り込んでいるが、利用実績がスコアに関与する影響は必ずしも高くない。利用実績がSEA

ソフトウェア・シンポジウム2017 in 宮崎

スコアに与える割合を補正して、事前評価のスコアに与える影響を上げればリスク予測の精度向上に貢献できると分析した。
2 つ目は、品質要求に対する重視度の定義である。リ
スク予測より実績が向上した品質要求カテゴリの多くに重視度が想定よりも高いものが多く見受けられた。現手法
では、重視度を開発プロジェクトの主観で決定している。
例えば、性能での「OSS が指定された性能を満たす事ができる」という設問は、文言の捉えようによっては、顧客から要求される性能とは無関係に、「重視する」と回答される可能性があり、今回のトライアルでもその様に回答したプロジェクトも見受けられた。品質要求の重視度についても、設問内容を含めて、改善の余地があると判断した。

手法の検証作業も併せて、評価レポート作成を行ったた
め、最初のレポート作成には 2 週間、作業が慣れてきた
後半でも 2-3 日を要している。正確な作成時間の計測を進めると共に、スコアリング等、一部ツール化、自動化を図り、コストの削減を実施していく。
謝辞
当社が過去に利用した OSS 約 170 種について、延べ3 万種に及ぶ OSS の事前評価データを収集して頂いた九州大学）鵜林研究室の学生の皆様に感謝致します。

参考文献[1] 独立行政法人情報処理推進機構：第3 回オープンソース

7 まとめ
本研究では開発現場への普及や運用の容易性を目的に開発者の持つ品質要求を元に OSS 利用リスクを特定する手法を考案し、トライアルを実施した結果、以下の評価結果を得た。
・OSS 利用時発生した問題 5 件について、品質要求単位、品質カテゴリ単位の双方で、リスク高、中として検知できた。
・リスク予測と開発チームの評価実績が一致したカテゴリ
数は 17 個であり、全カテゴリ数 42 個に対して約 4０%の確度でリスク予測がトライアル結果と一致した。
以上により、本手法は予測精度向上の余地はあるが、リスク評価の手法として有用であると判断した。

8 今後の課題(1) リスク予測精度向上の課題
リスク予測において、問題発生を検知できた反面、過剰にリスクを検知している可能性がある。品質要求の入力のやり方やスコアリング方法など、更なる改善の余地が残っている。本稿の執筆時、トライアルは継続中である。
トライアル終了時に、データを再度集計、分析して、手法にフィードバックしリスク予測精度を向上させていきたい。
(2) 予測コストの明確化と更なる削減
本手法の実行において、大きく 2 つのコストが必要となる。1 つは、評価のための事前評価情報の収集コストであり、これは共同研究者である九州大学の研究にて、1OSS
当たり、30 分～2 時間とのベンチマーク結果が得られている[12]。取得手順マニュアルの整備や自動化を進めて、更なる運用コスト削減を進めていきたい、
2 つ目は、事前評価レポートの作成時間である。今回

94

ソフトウェア活用ビジネス実態調査(2010).
[2] Atos: Quali_cation and selection of open source software(QSOS), version 2.0. (2013).
[3] Duijnhouwer, F.-W. and Widdows, C.: Open Source Maturity Model, Capgemini Expert Letter (2003).
[4] Northeast Asia, O.: RepOSS: A Flexible OSS Assessment Repository (2012).
[5] Petrinja, E., Nambakam, R. and Sillitti, A.: Introducing the opensource maturity model, Emerging Trends in
Free/Libre/Open Source Software Research and Development, 2009. FLOSS'09. ICSE Workshop on, IEEE,
pp. 37{41 (2009).
[6] Taibi, D., Lavazza, L. and Morasca, S.: OpenBQR: aframework for the assessment of OSS, IFIP International Conference on Open Source Systems, Springer,
pp. 173-186 (2007).
[7] Wasserman, T. and Das, A.: Using FLOSSmole Datain Determining Business Readiness Ratings, WoPDaSD(2007).
[8] Deprez, J.-C. and Alexandre, S.: Comparing assessment
methodologies for free/open source software: OpenBRR
and QSOS, International Conference on Product Focused Software Process Improvement, Springer, pp. 189203 (2008).
[9] Petrinja, E., Sillitti, A. and Succi, G.: Comparing OpenBRR, QSOS, and OMM assessment models, IFIP International Conference on Open Source Systems, Springer,
pp. 224{238 (2010).
[10] Petrinja, E. and Succi, G.: Assessing the open source development processes using OMM, Advances in Software
Engineering, Vol. 2012, p. 8 (2012).
[11]情報処理学会：第190回ソフトウェア工学研究会製品開発におけるOSS導入のためのOSS事前評価に向けた初期
調査 松本、山下、鵜林、亀井、深海、岩崎(2016)[12]日本ソフトウェア科学会：第23会ソフトウェア工学の基礎ワークショップ(FOSE2016) 開発現場への導入を想定したOSS事前評価手法確立に向けた調査 松本、山下、鵜林、亀井、大浦、高山、岩崎(2016)[13] コンピュータソフトウェア,Vol33.No1(2016) pp28-

40,:Open Source Software Engineering 伊原 大平

SEAソフトウェア・シンポジウム2017 in 宮崎

開発者の所属企業規模を考慮したソフトウェア工学の有用性評価
村上 優佳紗近畿大学大学院総合理工学研究科
m.yukasa@gmail.com

角田 雅照
近畿大学大学院総合理工学研究科
tsunoda@info.kindai.ac.jp

要旨の企業においてソフトウェア開発に従事している者の割合は 69%であり[7]，300 人未満の中小企業及びそこに所属する開発者が，日本のソフトウェアベンターのボリュームゾーンであるといえる．
ただし，ソフトウェア工学の最先端研究が，ボリュームゾーンである，これらの企業に所属する開発者のニーズに応えられているかは明らかでない．ソフトウ
ェア工学の研究の有用性や方向性について検討した研究がいくつか存在するが[8][11]，これらの企業はFacebook や Microsoft など，規模の大きなソフトウェ
ア開発会社に所属する開発者を対象としている．中小企業と大企業では，各ソフトウェアプロジェクトに従事するメンバー数や，開発対象のソフトウェアの規模が異なることが多いと考えられる．このため，所属する企業の規模が異なれば，技術者のニーズも異なる可能性がある．
本研究では，ソフトウェア工学の最先端研究が，中小企業に所属する企業のニーズに対応できているかどうかを分析する．ソフトウェア工学の最先端研究が大企業のニーズに応えることも重要であるが，ボリュームゾーンである中小企業のニーズの考慮も怠るべきでないと考える．分析では，ソフトウェア開発企業に所属する開発者に対し，ソフトウェア工学の最先端研究が自分の業務に有用であるかどうかを評価してもらった．その後，開発者が所属する企業の規模によりデータを層別して分析を行った．また，開発者による研究の有用性評価を支援するために，開発者の業務に関連する研究カテゴリとそれら属する研究の評価を，協調フィルタリングを用いて予測し，精度を評価した．

ソフトウェア工学の研究目標を設定する際，開発者の総数が多いボリュームゾーンのニーズを考慮する必要がある．日本では 300 人未満の中小企業及びそこに所属する開発者が多数を占めており，ここがボリュームゾーンといえる．ただし，ソフトウェア工学の最先端研究が，これらの企業に所属する開発者のニーズに応えられているかどうかは明らかではない．そこで本研究では，ソフトウェア工学の最先端研究が，中小企業に所属する企業のニーズに対応できているかどうかを分析した．具体的には，ソフトウェア開発企
業に所属する開発者に対し，最先端研究が自分の業務に有用であるかどうかを評価してもらった．その後，開発者が所属する企業の規模によりデータを層別して分析を行った．その結果，所属する企業の規模によって，業務に関連する研究カテゴリに差異が見られた
が，研究の有用性及び興味の評価については，規模による差異は見られなかった．

1.

はじめに

近年，ソフトウェアは企業の基幹業務システムや機器に組み込まれて広く利用されており，社会基盤として欠かせないものとなっている．このため，ソフトウ
ェアに高い信頼性が求められるようになっているが，その一方で，大規模なソフトウェアを短期間で開発することも同時に求められている．このようなソフトウ
ェア開発が成功する確率を高めるために，ソフトウェ
ア工学による開発の支援が求められる．
ソフトウェア工学による開発の支援を検討する際，開発者の総数が多いボリュームゾーンのニーズを考慮する必要がある．中小企業関連立法では，ソフトウ
ェア業・情報処理サービス業について，資本金 3 億円
以下または従業員 300 人以下を中小企業としている[2]．従業員 300 人未満の企業の割合は 99%，それら

2.

関連研究

ソフトウェア工学の研究がソフトウェア開発に対して与えた影響について分析した取り組み（Impact
Project）[9]では，プログラミング言語や構成管理ツー

95

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1
従業員数
300 人未満
300 人以上 1000 人未満
1000 人以上

6
5
5

表 2
従業員数
300 人未満
300 人未満(経験年数 3 年以上除く)
300 人以上
1000 人未満1000 人以上

回答者の概要経験年数 3 年未満(人)

回答者数(人)4
5
5

平均経験年数(年)
6.7
1.2
1.2

修士号取得者(人)2
2
1

回答者が関連する開発工程

要求分析
33%

基本設計
67%

詳細設計
67%

テスト
100%

プログラミング
83%

開発支援
33%

プロジェクト管理
17%

0%

50%

50%

100%

75%

0%

0%

20%

60%

60%

80%

80%

20%

0%

20%

60%

60%

100%

80%

0%

20%

ルなどに対して，ソフトウェア工学がそれらの発展にどのように寄与してきたかを分析している[3][12]．その結果，この取り組みでは，研究が実際の開発方法に影響を与えていることを結論づけている．ここから，
これまでのソフトウェア工学の研究に有用性がある
ことはわかるが，最先端の研究も同様に有用なのか，また，どの程度の割合の研究が有用なのかは明らかではない．
ソフトウェア工学の研究の方向性について示唆した研究として，Rubin らのもの[11]が挙げられる．
Google や Facebook などの先端のソフトウェア開発会
社に所属する開発者にインタビューし，彼らが直面する問題を明らかにするとともに，その問題に基づき，開発者が必要な情報に素早くアクセスすることをサポートする研究が望まれることなどを示している．ただし，この研究では，先端のソフトウェア開発企業以外の開発者のニーズは明らかにしていない．
本研究と類似した取り組みとして，2 つの従来研究[1][8]が挙げられる．これらは同じ研究グループによって実施されたものであり，ソフトウェア開発企業に所属する開発者が，最先端の国際会議の論文の要約（1-2 行）を読み，それに対して研究の価値があるかどうかを 5 段階で評価している．その結果，7 割前後の研究が，価値があるという結果となっている．調査方法は基本的に Zimmermann ら[1][8]と同様の方法であるが，本研究とこれらの研究との違いは 3 つある．1
つ目は各研究に対する評価の観点である．本研究では，「自分の業務に有用であるか」という観点で評価してもらっていることであり，これが従来研究との最も大きな違いである．2 つ目は，所属する企業の規模の違いに着目して分析していることである（従来研究ではマイクロソフトなど巨大企業に所属する開発者が回答者の主体となっている）．3 つ目は，個別の研究内96

容に対して，より詳細な説明資料を読んでもらった上で評価してもらったことである．その結果，後述する
ように，上記従来研究と異なり，最先端の研究に対する有用性の評価は低くなっていた．

3.

データ収集

分析で用いるデータは，ソフトウェア開発企業に所
属する開発者から，アンケートフォーム（Google フォーム）を用いて収集した．研究に対する有用性などの評価について，以下の手順に従って回答してもらった．
1. 業務に関係する研究カテゴリを最大 5 つ（3 つは必須）選ぶ．
2. 上位 3 件の研究カテゴリに関する論文の資料を読む．
3. 「業務に役立つか」，「興味を持ったか」について，それぞれ 5 段階（1 が最低，5 が最高）で評価する．
研究カテゴリの分類や，各カテゴリに含まれる研究
論文については，ソフトウェア工学の国際会議で最も権威のある ICSE (International Conference on Software
Engineering)の，2016 年開催分のものを参考にした．
具体的には，会議の各セッションを研究カテゴリとした．研究カテゴリの詳細については，4.2 節で後述する．各カテゴリ（セッション）には論文が 4 本程度含まれる．回答者の負担を減らすため，それらを直接読んでもらうのではなく，日本語の要約資料[6]を回答
者に読んでもらった．資料は一本の論文につき 2，3
ページのスライド形式となっており，比較的読みやす
い内容となっている．
また，各開発者について，以下の項目について回答してもらった．

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 3

研究カテゴリの概要及び回答者の業務に関連する割合

No.

カテゴリ名

1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27

Android (android で動くソフトウェアに関する研究)
Performance (ソフトウェアの性能)
Empirical (ソフトウェア開発データの分析)
Symbolic Execution (シンボリック実行によるソフト解析)
Compilers and Emerging Trends (コンパイラ・最新トピック)
Energy and Videos (ソフトウェア省電力化・ビデオの活用)
Open Source (オープンソースソフトウェア)
Defect Prediction (ソフトウェアの欠陥予測)
Synthesis (自動プログラム生成)
API (Application Programming Interface)
Code Smells (コーディングの方法論)
Architecture (ソフトウェアの構造)
Testing (ソフトウェアのテスト)
Effort Estimation and Search (開発工数見積もり)
Product Lines (プロダクトラインによるソフト再利用)
Repair and Model Synthesis (プログラムの自動修正)
Languages (ソフトウェア開発言語)
Debugging (ソフトウェアのデバッグ)
Requirements (ソフトウェアに対する要求)
Dynamic Analysis (ソフトウェアの動的な解析)
Security (セキュリティ)Collaborative (ソフトウェア開発の人的要因)
Software Quality (ソフトウェアの品質)
Program Analysis (プログラムの解析)
Concurrency (ソフトウェアの並行実行)
Maintenance (ソフトウェアの保守)l

取得学位（学士，修士など）
実務経験年数所属する企業の従業員数（300 人未満，300 人
以上 1,000 人未満，1000 人以上）担当する開発工程

論
文
数
4
4
3
4
4
4
2
4
4
3
4
3
8
3
4
4
4
4
4
4
4
4
3
4
4
4

総計

300 人
未満

300 人
未満
3 年未満

2%
4%

4%
4%
4%
2%
4%
20%
2%

11%

8%

11%

8%

3001,000 人

1,000 人
以上

7%

8%
8%

7%

8%
8%

6%
17%
6%

17%
8%

4%
9%
7%
2%
2%
4%
9%

6%
11%
6%

8%
8%
8%

6%

13%

17%

7%
21%

23%

7%
7%
7%
7%

8%
8%

8%

7%
7%

8%
15%

25%

14%

8%

6%

分析の目的を明確にするために，以下の 4 つのリサ
ーチクエスチョンを設定した．
l
RQ1: 業務に関連する研究カテゴリに偏りはあるか?
l
RQ2: 所属する企業の規模によって，関連する研究カテゴリに差異は生じるか?
l
RQ3: 最先端研究の内容は業務に有用か?
l
RQ4: 所属する企業の規模によって，研究の有用性に差異は生じるか?

務する 16 人である．回答者の概要について，所属企業の従業員数別に層別したものを表 1 に示す．従業員数 300 人未満の会社の回答者グループでは，開発経験年数が 3 年を超える回答者が 2 名いたが，その他のグループでは経験年数が 3 年未満であった．このため，以降の分析において企業の規模別に回答傾向などを確かめる場合，経験年数が 3 年以上の回答者を除外した場合についても示す．
業務に関連する工程:回答者の業務に関連する工程について，所属企業の従業員数別に層別したものを表2 に示す．テストとプログラミングに関してはほとん
どの回答者が関連し，設計に関しても半数以上の回答
者が関連している．要求分析や開発支援などについて
は，300 人未満の従業員数の企業の場合，経験年数が浅い場合（表の 2 行目）は関連していないが，それ以外の規模の企業の場合，割合は低いが関連している場合があった．

4.1.

4.2.

l
l
l

4.

分析

回答者の概要アンケートの回答者はソフトウェア開発企業に勤業務に関連する研究カテゴリ

ICSE での研究カテゴリを表 3 に示す．会議での各

97

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 4

セッションを各研究カテゴリとした．カッコ内は，セッションに含まれる研究の内容を考慮して筆者らが日本語に訳したものである．Testing のみ 2 つのセッションがあったため，合わせて 1 つのセッションとして扱った．各セッションにつきおおむね 4 本程度の研究論文が含まれる．
回答者全体の傾向 (RQ1 に関する分析 ): 業務に関連すると回答のあった研究カテゴリについても表 3に示す．総計は従業員数別に層別しない場合に関連があると答えた割合を示す．3 章で説明したように，少なくとも 1 人あたり 3 つのカテゴリを選択しており，
その総選択数（少なくとも回答者 16 人×3 カテゴリ）を分母として割合を算出している．その他の列は層別して同様の方法により割合を算出している（各列で合計 100%としている）．
全体でも 36%（26 カテゴリ中 9 カテゴリ）のカテ
ゴリが業務と関連があると答えられていなかった．これは，一部の研究が現時点では一般的な開発と関連が薄いためであると考えられる．例えば Compilers andEmerging Trends (コンパイラ・最新トピック)や Energy
and Videos (ソフトウェア省電力化・ビデオの活用)などが該当する．
開発支援を業務とする回答者は若干いたにも関わらず， Empirical (ソフトウェア開発データの分析)な
どの分析関連のカテゴリは選択されていなかった．このことから，従業員数が 300 人未満の場合（このグループには経験年数が 3 年以上の回答者が含まれる），または，経験年数が 3 年未満の場合，開発支援の業務においてデータ分析は関連が弱い（優先順位が低い）
可能性がある．
上記の分析結果より，RQ1 に対する答えは，「偏りがある（業務と関連が弱い研究カテゴリがいくつか存在する）」となる．
企 業 規 模 別 の 傾 向 (RQ2 に 関 す る 分 析 ):Performance (ソフトウェアの性能)や Collaborative (ソフトウェア開発の人的要因)などについては，従業員数 300 人未満の会社の回答者グループでは，業務との関連が弱かった．なお，300 人以上の企業で上記それぞれに関連があると答えている回答者は 4 人であり，例外的な回答者 1 人が答えたわけではない．表 2 で示したように，回答者が関連する工程に大きな違いがないことから，それらがこの結果に影響している可能性は低い．300 人以上の企業に所属する回答者の経験年数は 3 年未満であるが，300 人未満の企業に所属する回答者は 3 年以上の経験を持つ開発者も含まれていることから，経験年数についても影響している可能性が低い．この結果は，開発対象とするソフトウェア

研究の有用性および興味（従業員数別）

従業員数
300 人未満
300 人未満(経験年数 3 年以上除く)
300 人以上 1000 人未満
1000 人以上

表 5

有用性
2.2

興味
3.6

2.2

3.1

2.4
2.4

2.9
2.7

研究の有用性および興味（学位別）
最終学位
学士他
修士号

有用性
2.3
2.3

興味
3.0
3.5

の性質の違いや，開発体制の違い（プロジェクトあたりの開発者数の違いなど）が影響している可能性がある．これらは企業の規模との関係が強いと思われる．
API (Application Programming Interface) や Open
Source (オープンソースソフトウェア)については，従
業員数 300 人未満の企業の回答者については業務との関連が強く，それ以外の企業の回答者の業務とは関連が弱かった．経験年数 3 年未満と 3 年以上両方の開発者がこれらを回答していたことから，経験年数が結果に影響している可能性は高くないと考えられる．また，前述のように関連する工程に大きな違いはないことから，開発対象のソフトウェアの規模が比較的小さ
く，API や OSS の影響が相対的に大きいことが，このような結果につながった可能性がある．
これらの結果より，関連する（担当する）工程に大きな差がなくても，所属する企業の規模が異なる場合，業務に関連が強い研究カテゴリが異なってくる可能性があるといえる．よって，RQ2 に対する答えは「差異が生じる」となる．
4.3.

研究の有用性などに対する評価

本節では RQ3，RQ4 に関する分析結果を述べる．
各研究カテゴリに含まれる研究論文に対して，業務に有用かどうか，研究内容に興味があるかどうかを評価してもらった結果を表 4 に示す．所属する企業の従
業員数別に層別したが，規模によって有用性の評価に大きな違いはなかった．評価の平均値は 3 を下回って
おり，ソフトウェア工学の最先端研究は，一般的なソフトウェア開発に対して業務改善などの即効性は強くない可能性がある．
表 4 において，研究の有用性と比較して，研究に対する興味は低くなかった．ただし，興味の平均値は回答グループによって異なっていた．研究に対する興味は，大学院などで研究に取り組んだ経験があるかどうかが影響している可能性がある．そこで回答者を取

98

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 6
No.
有用度
回答数

表 7
No.
興味
回答数

研究カテゴリ別の有用度の平均値

1
2
7
9
10
12
13
2.0 3.0 2.5 3.0 2.5 2.5 2.2
2
3
2
2
2
2
7

2
4.0
2

19
2.3
4

20
2.3
3

23
2.5
2

24
2.3
4

27
2.2
6

研究カテゴリ別の興味の度合いの平均値
7
4.0
2

9
10 12 1318 19 20
23 24 27
3.0 4.5 3.5 2.7 1.5 3.3 2.7 3.0 3.3 2.7
2
2
2
7
2
4
3
2
4
6

得学位別に層別した結果を表 5 に示す．修士号取得者のほうが研究に対する興味が平均的に高かった．それぞれの研究論文に対する興味の強弱は，企業規模とは関係が弱く，取得学位との関連が強いと考えられる．
これらの結果より，RQ4 に対する答えは「差異は生じない」となる．
カテゴリ別の，研究の有用度に対する評価の平均値
を表 6 に，興味の度合いの平均値を表 7 に示す．データ件数が少ないため，ここでは層別せずに平均値を算出した．表では，回答が 2 件以上あったカテゴリのみを示し，平均値が 3 以上となったものを太字で示している．表中の No.は表 3 のものに対応する．個別に見た場合でも，研究の有用性の評価は全体的に低く，Performance (ソフトウェアの性能)と Synthesis (自動プ
ログラム生成)のみ平均値が 3 以上となった．
興味の度合いについては，半数以上の研究カテゴリ
で平均値が 3 以上となっていた．ただし，Languages(ソフトウェア開発言語)に関しては，有用性，興味の度合いとも 2 を下回っており，全カテゴリで最も低い値となっていた．研究内容は C 言語に関するものが多かったが，回答者と C 言語の関連が弱かった可能性も考えられる．なお，カテゴリ別の有用度と興味の度合いについて相関係数を算出すると 0.47 となった．
このことから，有用性と興味の度合いはある程度関連があると考えられるが，回答者は有用性と興味の度合いをある程度独立して評価していると考えられる．
これらの結果より，RQ3 に対する答えは「一部の研究カテゴリを除き，有用であるとはいえない」とな
る．

5.

18
1.5
2

研究カテゴリの推薦

いくつかの最先端研究は回答者（開発者）に興味を持たれていた．開発者が興味を持ちそうな研究カテゴ
リを，あらかじめ推薦システムによって提示することができれば，開発者は読む論文を絞り込むことができる．例えば，推薦システムはある開発者に対し，「業務と関連のある研究カテゴリは保守とテストである．

99

そのうち，テストの研究に対して興味を持つと予測される」などと提示する．興味を持ちそうな研究を容易に知ることができれば，最先端研究を知ろうとする技術者も増え，そのような技術者の一部が研究者に対して有用性に対するフィードバックを行えば，それぞれの研究の有用性に対する再考察が進む可能性がある．
そこで本章では推薦システムによって，開発者が興味を持ちそうな研究カテゴリを，高い精度で推薦可能かどうかを実験により確かめた．同様の推薦システム
は文献[14]でも提案しているが，文献[14]ではソフト
ウェア開発技術を推薦しているのに対し，本研究ではソフトウェア工学の研究を推薦している．そのため，
必ずしも同様の精度が得られるかが明らかではない
ため実験により精度を確かめた．
実験では，業務に関連するカテゴリの推薦と，興味の度合いの予測を，協調フィルタリングを用いてそれぞれに行った．4.2 節で示したように，業務に関連するカテゴリは開発者によって異なるため，まず関連するかしないかを判別予測した．例えば「開発者 A の業務に関連する研究カテゴリは，保守，テストである」などと予測する．次に，興味の度合い（5 段階評価）の数値を予測した．例えば，「開発者 A は保守の研究に対する興味は低く，テストの研究に対する興味は高い」などと予測する．
上記の推薦における説明変数は，開発者のプロフィール，すなわち経験年数，関連する開発工程，所属する企業の規模とした．目的変数は関連の強い工程と，研究に対する興味の度合とした．関連する開発工程，
所属する企業の規模についてはダミー変数化した．ダ
ミー変数化とは，例えば要求工程が関連している開発者では 1，そうでない開発者では 0 となるような変数を設定することを指す．判別予測，数値予測の精度評
価時にはリーブワンアウト法を適用した．リーブワン
アウト法では，全データのうちの 1 件を予測対象とし，それ以外を過去（既知）データとすることを，繰り返
して行う．

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 8

u1
u2
…
ui
…
um

5.1.

表 9

協調フィルタリングで用いるデータ
p1
v11
v21
…
vi1
…
vm1

p2
v12
v22
…
vi2
…
vm2

…
…
…
…
…
…
…

pj
v1j
v2j
…
vij
…
vmj

tk
r1k
r2k
…
rik
…
rmk

協調フィルタリングによる判別予測精度

ユーザベース
アイテムベース

表 10

適合率
30%
20%

再現率
24%
22%

F1 値
27%
21%

協調フィルタリングによる数値予測精度
ユーザベース
アイテムベース

絶対誤差平均値
1.16
1.23

協調フィルタリングの概要

協調フィルタリングは，ユーザにとって好ましい，または役立つと考えられるアイテム（書籍，音楽など）を推薦するための手法として用いられている[4][10][13]．
「協調」とは，ユーザの知識を利用することを意味し，「フィルタリング」とは，大量のアイテ
ムの中から，役立つアイテムだけを選び出して推薦することを意味する．一般的な協調フィルタリングで推薦を行う場合，各ユーザが各アイテムを（5 段階の数
値などで）評価していることが前提となる（システム
によっては，ユーザがそのアイテムを閲覧したかどうかを評価の代わりに用いることもある）．あるユーザが未評価のアイテムが，そのユーザにとって役立つと考えられる場合，そのアイテムを推薦する．
協調フィルタリングの主なアルゴリズムとして，ユーザベース手法とアイテムベース手法の 2 つがある．
ユーザベース手法は，「アイテムの評価（好み）が似たユーザは，どのアイテムに対しても似た評価を行う」と仮定し，推薦を行う．具体的には，各ユーザの各ア
イテムに対する評価を要素とするベクトルを，ユーザごとに作成し，そのベクトルのなす角をユーザの類似度とする．そして推薦対象のユーザが未評価で，かつ類似したユーザの評価が高いアイテムを推薦する．ユーザベース手法を用いた推薦システムとして，
Resnick ら[10]の GroupLens が挙げられる．GroupLens
は，Usenet にある多数のニュース記事から，ユーザの好みに合うと予測される記事を選び出して推薦するシステムである．
アイテムベース手法は Sarwar ら[13]によって提案されたアルゴリズムであり，アイテム間の類似度に基づいて推薦を行う．アイテムベース手法の場合も，各ユーザの各アイテムに対する評価を要素としてベクトルを作成するが，ユーザごとにベクトルを作成するのではなく，アイテムごとに作成し，類似度を計算する．すなわち，「あるグループのユーザに高評価されるアイテムは，類似の性質を持っている」と仮定し，推薦対象のユーザが高い評価を行っているアイテムと類似度の高いアイテムを推薦する．
協調フィルタリングを用いた推薦では，表 8 のよ100

うな m×n のマトリクス形式のデータを想定する．ui∈{u1, u2, ..., um}は i 番目の開発者を表し，pj∈{p1, p2, ...,pj}は開発者のプロフィール（経験年数など）を表す．
また，tk∈{r1k, r2k, ..., rmk}はある研究カテゴリ k の評価
結果を表す．
5.2.

評価尺度

判別予測の評価尺度として，適合率，再現率，F1値を用いた．これらは，推薦システムの評価尺度として広く用いられているものである[5]．適合率は，「業
務に関連がある」と予測されたうち，実際に関連があった割合を示す．再現率は，全ての関連があった研究
カテゴリのうち，「関連がある」と予測されたものの割合を指す．F1 値は，適合率と再現率のバランスを考慮して一つの指標としたものである．これらの値が大きいほど，判別予測の精度が高いことを示す．
数値予測の評価尺度には絶対誤差を用いた．絶対誤差は予測値と実測値（実際の評価値）との差の絶対値
であり，値が小さいほど数値予測の精度が高いことを
示す．
5.3.

予測結果

判別予測の結果を表 9 に示す．アイテムベースよりもユーザベースのほうの精度が高かったが，F1 値
が 27%と非常に低い判別予測精度となった．数値予測の結果を表 10 に示す．こちらについてもユーザベ
ースの予測精度がわずかではあるが高かった．ただし，絶対誤差の平均値が 1 を少し超えており，高い精度であるとまではいえなかった．
この結果より，業務との関連が強い研究カテゴリを判別予測することは容易ではないといえる．ただし，データの件数が増えれば予測精度が高まる可能性もある．実験で用いたデータにおいては，業務に関連する研究カテゴリの絞り込みについては，各開発者で行う必要があるといえる．それらに対する興味の度合いの高低については，ある程度は協調フィルタリングにより予測可能であるといえる．また，推薦に用いるアSEA

ソフトウェア・シンポジウム2017 in 宮崎

ルゴリズムにはユーザベースが適しているといえる．

6.

考察

ソフトウェア工学は特に他の工学分野と比べて開発現場と密に関わっているため，理論中心で現場への適用が想定されていないような研究は，あまり推奨されない． ICSE はソフトウェア工学の理論中心というよりも，実験を考慮した研究が比較的多いとみなし，本研究の実験題材として採用した．
研究論文のグルーピングを行う際には，以下の 3
点をクリアできるよう考慮する必要がある．
lグループの定義が正しいl
論文が所属するグループが正しいl
論文数に偏りが出ない
研究論文を分類するために，著者らで新たなグループを考慮することもできたが，論文によってはどのカ
テゴリに何が属するのかの判断が難しく，論文の数にも偏りが出る可能性があり，上記 3 点が満たせない可能性があった．各セッションに基づいて論文を分類しても特に違和感はなかったため，やや乱暴ではあるが会議のセッションを研究カテゴリとして用いた．
Zimmermann ら[1][8]の研究では，「研究の方向性が正しいか」を聞いており，この観点からは各研究の評価は高かった．それに対し本研究では，実際の業務でソフトウェア工学が有用であるかどうかが重要であると考え，評価してもらった．一部の回答者は業務経験年数が長かったが，有用性の評価は低かった．このことから，業務経験の短さが必ずしも有用性の評価につながっていないと考える．また，研究内容に対する興味については低くなかったため，回答者が内容を理解していないとはいえないと考える．
著者の一人の実務経験に基づくと，実務経験が 1
年ほどあれば，技術の有用性が理解できる程度の知識は習得しており，少なくとも，自分が担当する業務に関しては，研究の有用性に対する判断はある程度正しく行えると考える．ただし，経験年数が少ないと，自分が担当している工程が少ないため，担当した経験の少ない分野については有用性が低くなる可能性がある．特に上流工程に関する研究の評価については，経験年数のより長い被験者を対象に調査をする必要があると考える．

7.

トウェア開発者に対し，業務に関係する研究カテゴリを最大で 5 つ選択してもらい，そのカテゴリに属する研究（1 カテゴリにつき 4 つ程度の研究）が自分の業務に有用かどうか，興味を持ったかどうかを 5 段階で評価してもらった．その結果，以下の傾向が見られた．
l
業務と関連が弱い研究カテゴリがいくつか存在した．例えば Compilers and Emerging Trends (コンパイラ・最新トピック)や Energy and Videos (ソフトウェア省電力化・ビデオの活用)などのカテゴ
リは関連があるとの回答がなかった．
l
所属する企業の規模によって，関連する研究カ
テゴリに差異が見られた．例えば API や OSS は，
従業員数 300 人未満の企業に所属する開発者の業務と関連が強く，それ以外の関連が弱かった．
lPerformance (ソフトウェアの性能)と Synthesis(自動プログラム生成)に関する研究を除き，最先
端の研究は業務に有用であるとはいえなかった．
l
開発者が所属する企業の規模によって，研究の有用性及び興味の評価に差異は生じなかった．
ただし，興味については開発者の取得学位が影響している可能性がある．
l
業務に関連する研究カテゴリを予測した場合の精度が低かった．ただし，研究に対する興味の度合いについては，ある程度の精度で予測可能であった．
今後さらに分析を行う必要があるが，今回の分析では有用性の評価が高くなく，ソフトウェア工学の最先端研究が中小企業のニーズに応えられているとは必ずしもいえなかった．今後の予定は，回答者を増やすとともに，入社年数の長い回答者を増やして分析結果の信頼性を高めることである．
謝辞 本研究の一部は，文部科学省科学研究補助費（基盤 C：課題番号 16K00113）による助成を受けた．

参考文献
[1]

[2]

おわりに

本研究では，最先端のソフトウェア工学の有用性に対するソフトウェア開発者の評価を，開発者が所属する企業規模に着目して分析した．企業に所属するソフ

[3]

101

Carver, J., Dieste, O., Kraft, N., Lo, D., andZimmermann, T.: How Practitioners Perceive theRelevance of ESEM Research, In Proc. ofInternational Symposium on Empirical Software
Engineering and Measurement (ESEM), no.56,
10pages, 2016.
中小企業庁：中小企業の定義について，http://
www.chusho.meti.go.jp/pamflet/g_book/h22/teigi.ht
ml.
Estublier, J., Leblang, D., Hoek, A., Conradi, R.,
Clemm, G., Tichy, W., and Wiborg-Weber, W.:

SEA

ソフトウェア・シンポジウム2017 in 宮崎

[4]

[5]

[6]

[7]
[8]

[9]

[10]

[11]

[12]

[13]

[14]

実験参加協力のお願い

Impact of software engineering research on thepractice of software configuration management,
ACM Transactions on Software Engineering andMethodology (TOSEM), vol.14, no.4, pp.383-430,
2015.
Goldberg, D., Nichols, D., Oki, B., and Terry, D.:
Using Collaborative Filtering to Weave an
Information Tapestry, Communications of the ACM,
vol.35, no.12, pp.61-70, 1992.
Herlocker, J., Konstan, J., Terveen, L., and Riedl, J.:
Evaluating collaborative filtering recommendersystems, ACM Transactions on Information Systems(TOIS), vol.22, No.1, pp.5-53, 2004.
情報処理学会 ソフトウェア工学研究会 国際的研
究 活 動 活 性 化 WG ： ICSE2016 勉 強 会 ,https://sites.google.com/site/sereadings/icse2016.
経済産業省：平成 27 年特定サービス産業実態調
査，2016.
Lo, D., Nagappan, N., and Zimmermann, T.: Howpractitioners perceive the relevance of software
engineering research, In Proc. of Joint Meeting on
Foundations of Software Engineering (ESEC/FSE),
pp. 415-425, 2015.
Osterweil, L., Ghezzi, C., Kramer, J., and Wolf A.:
Determining the Impact of Software Engineering
Research on Practice, Computer, vol.41, no.3,
pp.39-49, 2008.
Resnick, P. Iacovou, N., Suchak, M., Bergstrom, P.,
and Riedl, J.: GroupLens: An Open Architecture forCollaborative Filtering of Netnews, In Proc. ofConference on Computer Supported Cooperative
Work (CSCW), pp.175-186, 1994.
Rubin, J., and Rinard, M.: The Challenges of
Staying Together While Moving Fast: An
Exploratory Study, In Proc. of International
Conference on Software Engineering (ICSE),
pp.982-993, 2016.
Ryder, B., Soffa, M., and Burnett, M.: The impact ofsoftware engineering research on modern
programming languages, ACM Transactions on
Software Engineering and Methodology (TOSEM),
vol.14, no.4, pp.431-477, 2005.
Sarwar, B., Karypis, G., Konstan, J., and Riedl, J.:
Item-BasedCollaborative
Filtering
Recommendation Algorithms, In Proc. ofInternational World Wide Web Conference (WWW),
pp.285-295, 2001.
秋永知宏，大杉直樹，柿元健，角田雅照，門田暁
人，松本健一:協調フィルタリングに基づくソフトウェ
ア開発技術の推薦，電子情報通信学会技術報告,
ソフトウェアサイエンス研究会, SS2005-13, pp.7-13,
June 2005.

我々は，ソフトウェア開発企業で開発業務に従事したことのある方で実験参加の協力をしていただける方を募集しています．詳細は以下 google フォームのサイトに記載しております．お問い合わせは，本研究の著者までお願いします．
https://goo.gl/forms/n5UKrffJRAfkKFXz1

102

SEA

ソフトウェア・シンポジウム2017 in 宮崎

自分事化影響要因に着目した中期経営計画立案・展開への共創アプローチ[現状分析～計画立案編]
安達 賢二
株式会社 HBA
adachi@hba.co.jp
要旨
弊社のこれまでの経営計画立案・展開は、経営企画部門と役員クラスの事前調整に基づくトップダウンアプローチであった．その結果、実務層は実施すべき施策が指定された全社計画に合わせて部門・部署計画を立案、展開していた．結果的にやらせる／やらされる運営が中心となり、躍動感やワクワク感のない、当事者意識・参画
意識が薄い（あるいは、ない）、“こなす”仕事が多いと感じていた．また、全社レベルの計画・展開と実務レベルの実質的な実践内容が乖離している場合もあった．
2016 年に新社長が就任し、創立 50 周年(2014 年)に掲
げた新テーマ“IT で幸せに挑む”の実践・実現に向け、社員一人ひとりが当事者となり事業を進めることで“仕事を通じた幸せ”を獲得してもらうため、人がものごとを自分事として継続的に実施することに影響を与える要因（自分事化影響要因、とする）に着目した社員参画型共創ア
プローチを採用し、中期経営計画立案を進めることとした．
現時点は中期経営計画が発行される直前であるため、まずは現状分析～計画立案に至る過程とその中で得られた効果、および今後の課題を明確にする．

1. はじめに企業はその組織方針や中長期計画、および年度計画に基づき運営されるケースが多い．弊社は 1964 年に創業（現在 52 周年）、社員数約 800 名、札幌に本社とデー
タセンター、北海道内 6 営業所、東京支社、関西にも拠点を置く（北海道では老舗の）SIer である．弊社におけるこれまでの計画立案・展開は、経営企画部門と役員クラスの事前調整に基づくトップダウンアプローチが主流であった．その結果、実務層は「年度で実施すべき施策は与えられるもの」との認識下で展開された全社計画内容に依存し、それに合わせる内容で部門部署計画を立案、展開していた．結果的にやらせる／やらされる運営となり、躍動感やワクワク感のない、当事者意識・参画意識が薄103い（あるいは、ない）、どこか他人事のように“こなす”仕事が多かったと思われる．それでいて当該領域に対する社
員の問題意識は薄く、慣習の恐ろしさをも感じてもいた．
2015 年度に就任した新社長の意向もあり、創立 50 周年に掲げた新テーマ“IT で幸せに挑む”の実践・実現に向け、社員一人ひとりが当事者となり事業を進めることで“仕事を通じた幸せ”を社員に獲得してもらう中期経営計画とすることを目指すことになった。
その命を受けた経営企画部門の主担当者が、これまで
社内外問わず、関係者が自ら現状分析～改善計画立案とその実践を当事者として取り組む場を作りファシリテー
トするサービス（SaPID(*1)）を提供してきた筆者に（2016年 5 月初旬）支援依頼してきたことから当取り組みが動き始めた．

2. 活動内容
2.1. 当初のアプローチ提案
中期経営計画とは、弊社の経営を 3 ヵ年単位で計画
し、最終年度（3 年後）の目標達成に向けて施策を実践する基盤となるものである．
次期中期経営計画発行予定時期が 2016.12～2017.1 頃と期間的な余裕があること、実態に即した実効性のある計画にしたいこと、社員との直接的なコミュニケーションを重視する方針であった等の理由から、中期経営計画立案に対し、自分事化影響要因に着目した社員参画型共創アプローチを提案した．
社員参画型共創アプローチとは、社員一人ひとりが普段の実務での出来事や感じていることを自分の言葉で（付箋等に）記述し、その情報をきっかけにして主に以下の内容を明らかにすることを意図している．
(1)弊社らしさや実務で大事にしていること(2)こういう会社になってほしいという将来像

SEA

ソフトウェア・シンポジウム2017 in 宮崎と、背後に存在する事象や問題・課題などを明らかにす
る．

(3)弊社の強み：他社より秀でた点、ウリ(4)弊社の弱み：実存する課題や問題、困り事(1)～(4) の情報を可能な限り社員から直接収集し、その結果を分析することにより、事実に基づく弊社の実情や社員の想い、そして社長を中心としたトップマネジメントの考えを融合させ、実効性ある（段階的な）施策を反映した
中期経営計画を立案し、一人ひとりの社員が当事者意識を持ちながら実践することにつなげる方法として提案した．
このようにトップダウン偏重型のアプローチから脱却し、トップから実務を行う社員までが一体となり、共に新しい組織や事業を創りあげる、という意味から“共創アプローチ”と命名した．

当初は筆者がファシリテータとなりワークショップを運営した．抽象度が高い内容、事実かどうか不明な事項、真意が不明の表現などを“質問を契機にした対話”により掘り下げ、周囲のメンバー（他者）にも理解できる具体的な内容として書き換えて共有する．

2.2. 社員による関連情報収集と分析
それぞれの社員からの意見、コメント収集やその結果共有による Q&A の実施実績は以下の通りである．
表 1：社員の意見、コメント収集～結果共有活動実績
参画
実施日
実施内容
2016 年者数
5 月初旬 新入社員ワークショップ25
5/18
新任課長代理ワークショップ16
6/20
管理職選抜ワークショップ
17
7/8
新任主任ワークショップ
22
7/15
串刺懇談会ワークショップ
7
8/3
経営管理部門管理者ワークショップ
10
8 月末
経営管理部門ワークショップ
40
9/1
部門長ワークショップ
16
9/12-13
役員合宿ワークショップ（全員出席）
12
9/29
データセンター部門ワークショップ
15
11/25
技術部門管理者ワークショップ
11
11/26
公共部門管理者ワークショップ
15
12/6-7
技術部門意見交換会
1512-1 末社長による Town Meeting(計 5 回)224
計 445 名／800 名（56％）
課長以上の管理層参画率＝80%超

写真 1：ワークショップの様子

写真 2：ワークショップ中の分析過程

社員からの意見、コメント収集の手段は、主にワークショ
ップ形式を採用した。参加者に各 5 人前後のチームになってもらい、2.1.に示した(1)～(4)それぞれに対する各自の意見、コメントを付箋に記述し、その内容をきっかけにして相互に対話しながら本当に言いたいこと、伝えたいこ

主な付箋（要素）の処理（洗練）が終わったところで、それぞれのチーム、もしくは参加者全員で収集（列挙）した個
別要素を分類し束ねる、表題を付与する、因果関係が成り立つ要素間を矢印で結ぶ（原因→結果）ことによるモデ

104

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ル化・構造化を行う。これを関係性分析と呼ぶ．（図 1）構造化した結果を導き出すことを促進する．参加者自らが記述した要素を、自ら分析し、構造化することで、メンバー全員の総意である結果が導出されるため、参加者
全員が腹落ちしやすく、自分事化しやすい結果を獲得することができる．

①収集した情報（要素）を列挙する②類似の要素を束ね、表題をつける

写真 3：ある部門のこういう会社にしたいよね要素群
なお、筆者がファシリテータを自ら務めたのは当初から
2016/9/1 に実施した部門長ワークショップまである．それまでのワークショップにて進行方法やファシリテートの仕方を確立し、主催する経営企画部門に技術移転し終えた．以降のワークショップ運営、ファシリテートは経営企画部門に委ね、筆者は次の段階となる収集済み全データの分析･構造化に軸足を移した．
2.3. 収集した全データによるモデル化・構造化③要素間の因果関係があれば→で連結し構造化する（因果関係分析によるモデル化・構造化）
図 1：関係性分析の流れ(例)

全社中期経営方針、および計画を立案するため、それぞれのワークショップにより収集した(1)～(4)の情報（要素）をすべて電子化し、関係性分析を行い、以下のモデ
ル化・構造化を行った．（図 2）

分析対象は以下の 2 つである．
・(1)＋(2)から
弊社の特長を統合した
こういう会社にしたいよねモデル
・(3)＋(4)から
わが社のよい点＋問題・課題構造図

・こういう会社にしたいよねモデル
・わが社のよい点＋問題・課題構造図

ファシリテータは、要素の洗練や分析、モデル化・構造化に対しての答えを提供するのではなく、これらの進行促
進と答えの出し方をガイドする.見落としや異なる見方などのヒントを提供することで、参加者自らが要素を洗練し、105

これまで実施してきた個別ワークショップでも同じモデル・
構造図を構築しているが、それらは“参加者層”から見えている限定した情報に基づくものである．情報の抜け漏
れ、偏りが存在し、全社経営方針・計画立案の入力情報として相応しくない．よって中期経営計画立案のために全データによるモデル化・構造化が必要との判断した．

SEA

ソフトウェア・シンポジウム2017 in 宮崎

実際には 2016 年 10 月中旬にそれまでに実施・収集した情報をデータ化し、分析・モデル化した上で、その後のワーク結果により都度更新することで対応した．
モデル化、構造化する理由・利点は以下のとおりである．
・事業活動のよい循環・悪い循環が俯瞰できる・解決すべき問題・課題を特定しやすくなる
・施策による効果目標を設定しやすくなる
・施策による効果をシナリオ化でき、予測しやすくなる

2.4. 解決すべき問題・課題（候補）の定義①収集した情報のデータ化＆分類（一部）
収集したさまざまな情報（要素）の洗練は（ワークショッ
プの時間･工数的な制約から）ファシリテーション過程で検出した要素に絞って対応したため、分析結果と上記モ
デルには解決手段の裏返し事項などが残存していた．
例えば「～不足」（例：プロジェクトマネージャ不足）がそれにあたる．この情報は「～（例：プロジェクトマネージャ）を増やすと（ある問題が）解決する」という意図を持った情報であり、解決したい問題・課題ではなく解決手段の提案となっている．この情報をそのままにすると、本当に解決したい問題・課題に対する解決手段の他の選択肢を排除してしまい、実効性のある施策を導出しにくい状態となる．
②会社の特長とこういう会社にしたい要素の因果関係分
析から構築した「こういう会社にしたいよねモデル」

よって、この段階で解決すべき問題・課題は何か？を再整理し、解決すべき問題・課題の候補として定義することとした．（例：ロスコンプロジェクト化の防止）
2.5. 中期経営計画のテーマの再確認
限られたリソースや制約条件の中で、最も有効な施策を実践するためには、沢山の解決すべき問題・課題の候補群の中から選りすぐった問題・課題を特定し、限りあるリソースを集中投下する必要がある．
この段階でその判断基準となる中期経営計画のテーマ
を今一度再確認した．

2.6. 社長主催タウンミーティングの実施③わが社のよい点＋問題・課題要素の因果関係分析から構築した「よい点＋問題・課題構造図」
図 2：こういう会社にしたいよねモデル／
よい点＋問題・課題構造図の構築

以上の情報収集、分析結果から社長、役員、および経営企画部門が中期経営計画の骨子を検討した．その結果を携えて社長自らがタウンミーティング（札幌・東京に

106

SEA

ソフトウェア・シンポジウム2017 in 宮崎て計 5 回）を開催し、ワークショップに参加できなかった社員などを中心にこれまでの取り組みの経緯や情報収集・分析結果、今後の方向性（中期経営計画の考え方など）などを説明した．
また、説明後には参加者からの質問一つひとつに社長が自らの考えを伝達した．

・感情的な内容であってもその背景を常に冷静に掘り下げ、真意を把握する
3.3. 事実情報の収集実存しない情報を基に計画を立案するようなことはあってはならない．しかし、多くの社員から意見･コメントを収集すると事実かどうか把握できないもの、疑わしいものが混在していることが多い．
一方で、収集前に「事実でなければなりません」などの注意を述べてから収集を始めると、とたんに参加者の手が止まり、大事な情報も出てこなくなる傾向がある．

2.7. 中期経営方針と中期経営計画の立案
以上のように収集した情報（要素）を分析・構造化し、解決すべき問題候補と中期経営計画のテーマに基づいて、解決すべき問題・課題を特定し、役員と経営企画部
門が中期経営方針を策定、中期経営計画を立案した．

よって、意見・コメント収集時には“テーマ”以外の制約を可能な限り排除した上で記載してもらい（大事な情報を逃さないように）、その内容をヒントに掘り下げる（事実かどうかを把握して実存しない場合は排除する）対応を行った．
また、“問題・課題”という表現が硬い、難しいと受け取ると手が止まることを考慮して“普段の実務における困り事”を書いてもらうようにした．

3. ワーク設計のポイント
当初の支援依頼を受けてワークショップをデザインした際に重視した主なポイントを記す．
3.1. 社員の参画・自分事化を促進「実務の自分事化」「仕事を通じた幸せの獲得」「幸せな社員が顧客を幸せにする」を目指す上で、社員の参画は不可欠である．その意味で、アンケート収集などの間接的な手段ではなく、あえて直接対話の機会となる（社員間交流も促すことを目指して）ワークショップやワールド
カフェ形式（Ｔｏｗｎ Ｍｅｅｔｉｎｇで実施）を採用した．
自らの表現で記載した付箋や他者が記載した付箋をメンバーと相互に理解し、一緒に全体像を創りあげる．
構成要素、全体像の両面に納得し、合意を形成する．
以上の過程を踏むことで成果物の内容に対する自分事化を促進する．
また、可能な限り定例開催される昇格者向け社内研修の場を活用するなど社員への負担軽減に考慮した．

3.4. 明るい未来とよい点から始める
意見・コメントを収集する順番は、以下のとおりである．
(1)弊社らしさや実務で大事にしていること(2)こういう会社になってほしいという将来像(3)弊社の強み：他社より秀でた点、ウリ(4)弊社の弱み：実存する課題や問題点、困り事

3.2. 安全な場の提供
テーマに対して参加者が忌憚のない意見、コメントが出せるように安心、安全な場を提供することが重要である．
そのような場を提供するために実施した事項を列挙す
る．
・役員、管理者、実務者のワークの分離
・チームメンバーはあらかじめ運営側で設定することで、不仲、不毛な争い等が発生するリスクを最小化する
・情報収集･共有時の匿名性の確保
・ファシリテータ自らぶっちゃけ話を提供する

107

計画立案などを目的とした現状把握情報として一般的に収集されるのは問題･課題関連情報である．存在する問題や課題を捉えることでその対策としての計画を立案することが可能である．しかし、問題･課題情報から収集し始めると、参加者の顔が曇り、後ろ向きな場が出来やすい．それでは“共に創る：共創”は実現しにくくなってしまう．
よって、前向きで発展的な場を作り、新しい組織を一緒に創りあげる、参加者が前を向いて取り組んでもらえるよ
うに、(1)～(3)に関連する情報を先行して収集し、前向きな場を作り上げてから(4)を取り扱うこととした．
3.5. 自分事化に促すアプローチ
以上のワークは、自分事化影響要因を考慮した対策
を、適切なタイミング、必要な箇所に配置し、構成した．

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4. 当アプローチの効果（表 2）
この対策群（アプローチ）により、ワークショップの参加者である社員が自ら現状を把握し、ありたい姿とのギャップを埋めるために必要な施策を自分事として実践することを促進する．

以上のアプローチにより、このあと 2017.4.1 からの 3 か
年計画となる中期経営方針・計画を発行し、その実践に移行する．これまでの実践結果と現時点での効果を記載
する．

表 2：自分事化影響要因とその対策
自分事化影響要因
今回の対策
自分が言ったこと、決めた ・ワークショップにて自らのことに責任を持ちやすい． 表 現 で書き出した要素を誰かが言ったことは自分事 基に分析・構造化を実践しにしにくい．
てもらう．
自らのことを周囲に理解し ・自分の困り事を書いてもてもらいたいと（内心）思っ らうところから始める．
ていることが多い→理解し ・その内容と真意をチームてくれるとうれしい．
メンバーがリアルに理解す
自分の困り事を解消するた るワークを行い、その結果
め な ら 積 極 的 に な り やす を分析・構造化に活用すい．
る．
一人だと継続できないこと ワークショップではチームとも仲間とならやれる．
して取り組んでもらう．
価値を感じていれば、自分 ・自分が考える“こうなりたでもできる/できそうだと思う い姿”を表明してもらうとこことには挑戦する．
ろから始める．
・自分の困り事を書いてもらう．
・なりたい姿と問題構造のギャップを埋めるために、
チーム全員で必要な事項を決定（合意）する．
できなかったこと・わからな 沢 山 の問 題 ・ 課題のどれかったことができる・わかる に取 り組 めば合 理 的 、現ようになると楽しい．
実的なのかを構造化により明らかにする（自ら答えを導く）．
自らのニーズ・要求がよく 実務での困り事、感じていわかっていない．問題や要 ることを書いてもらい、その求ではなく（自分が知って 情報から（適切な質問によいる）手段を提示してしま り）背後に存在する問題・う．
課題を明らかにする．
場に行動が左右されやす 安心、安全な場を提供し、い．
(1)～(4)の情報を生の声として獲得する．

4.1. 社員の積極的な参画を獲得＜実施前の不安＞
ワークショップを実施しても冷めた態度を取る社員や管理者が多数存在することになるのではないか．
＜実施結果＞
いざワークショップを開催してみると、ほぼ例外なく参加者がみな積極的に参画し、実践していた．特に意外だったのは、普段は強権発動的な行動・言動が目立つ社員や、一匹狼的なリーダが、ワーク時のチームメンバーと共にバランスのよい真っ当な意見・コメントを出しつつ分析や構造化も積極的に進めていたことである．
普段は内弁慶的に振舞っている社員であっても、同じ役
割層等他者の目に晒されること、およびファイシリテータ
により極論やバランスを欠くコメントには別の見方や事実確認を行うため、出過ぎた行動が融和・抑制された可能性がある．このアプローチには極論や自分勝手な筋違いな内容等が除去される効果があるのではないか．一方で、（誰でも自分は正しいと思っているので）自分の意見・コメ
ントが通らないことを心の奥底に溜め込んだ可能性もあるため、今後も継続観察していく必要がある。
4.2. 長所・強みが悪循環に加担していることに気づいた＜実施前＞
事業、業務上の好循環、悪循環は、それぞれ長所・強み・よい点／短所・弱み・悪い点だけで構成されていると思っていた．
＜実施結果＞
今回は長所・強み・よい点／短所・弱み・悪い点すべての要素による関係性分析を行った結果（図 2 を参照）、弊社の誰もが認める長所・強みの一部が、事業の悪循環に加担している可能性が把握できた．（表 3）
このことは、今後弊社が目指す姿をあらためて考え直す
きっかけとなった．

108

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 3：強みが悪循環要因へ加担する（例）例： 強み「トータルサービスを提供している」→解釈「何でも出来る」→受取「ぼんやりしていて特長がない」→結果「新規顧客獲得がなかなか進まない」＝悪循環要因の一つ

選りすぐった事項に対して施策を打ち出されている．
仮に、これまでと同じ（同類の）施策が存在していたとしても、自分事として捉えて取り組む可能性が高いと言える．
現在、各部門・部署の中期経営計画立案中であるため、今後の取り組みで自分事としての実践をさらに促進し、その成果を確認する必要がある．

5. 当アプローチの課題

4.3. 社員の想いとトップの想いの融合を促進

当アプローチの主な課題とその対策を明示する．

＜実施前の不安＞
実務層の想いとトップの想いが折り合わない可能性が高
いのではないか．

課題 1：全社事業計画はどの部門にも適用可能な施策として提示しているため組織の状況や特長に適応できるアプローチを設計する必要がある．
↓
その対策各部門による施策具体化検討開始時に、施策の目的、背景、現状、体制、制約条件などを共有し、効果的か
つ現実的なアプローチを設計してもらう．そのうえで小さく試行した結果を活用してから部門内展開につなげるよう促す．

＜実施結果＞
実務を通じて社員が何を見ているのか、どう感じ、何を想っているのかを把握したうえで、トップの想いと融合することができた．これまでも現状評価に基づき計画を立案してきたが、社員の生の声を取り入れ、その背後にある事実を把握した上でトップの想いとつなげたのは初めてのことである．
今後「実務の自分事化」「仕事を通じた幸せの獲得」「幸せな社員が顧客を幸せにする」を目指す上で大事な階段を一つ昇ったと言えるのではないか．

課題 2：人間の感情論をも取り扱うため、比較的高度な
ファシリテーション技術が必要になる．
↓
有識者が先行実施しながら、進行方法やファシリテー
トの仕方を確立し、ファシリテータ候補者に技術移転する．（→参照 2.2.）

このような結果となったのはこの取り組みが、「社員の（仕事を通じた）幸せ」と「顧客の幸せ」の実現を目指しているからではないかと思う．
4.4. 解決すべき問題・課題（候補）の明確化による実効性ある施策導出

課題 3：人の心を動かすのは簡単ではないため、継続して手間／時間をかけていく必要がある．
↓
その対策
即効性のある手法は存在しない．わかってもらえるまで粘り強く、一貫して対話を重ね、以降もさまざまな局面で繰り返しミッション・ビジョン・価値観を伝え、その実現を目指す実践を継続していく．

＜実施前の状態＞
これまでの中期経営計画、年度事業計画で打ち出されてきた施策は、弊社の（そのときどきの）現状に対して間違いではないものの抽象的、一般的な内容であったり、表現は異なるものの何年経っても同類の内容が繰り返されることが多かった．そして実務層や管理層からの生の声を反映したとは言いがたい状態であったため、施策に対する社員の当事者意識は薄く、実務とは別物的に扱われている印象もあった．

6. 今後の活動予定＜実施結果＞
今回のアプローチでは、実務層・管理層から直接声が上がった内容を基に、解決すべき問題として捉えなおし定義した（→2.4.参照）候補群から、中期経営方針に沿って2017 年 4 月からいよいよ中期経営計画の実践に入る．
しかし市場環境の変化は激しいため、計画した施策を実践するだけではなく、併せて中期計画に対する四半期単位のふりかえりと計画見直しを実践していく．

109

SEA

ソフトウェア・シンポジウム2017 in 宮崎

また、今後の実践課程で社員が仕事を通じた幸せを実感できるようになったのかを 2011 年から隔年で実施している社員満足度（ES）調査の幸福 5 指標（心身の健康・
経済的安定・良好な人間関係・仕事への情熱・周囲への貢献）などの指標を活用して評価していく予定である．
今回立ち上げた中期経営方針・計画はあくまでも弊社の全社員が一体になり“ＩＴで幸せに挑む”＝「実務の自分事化」「仕事を通じた幸せの獲得」「幸せな社員が顧客を幸せにする」“を実現するための準備でしかない．実現に向けた実践はこれからが本番である．
これからスタートする各種施策の実践においても、それぞれの社員が当事者意識を持って日々の業務に邁進し、仕事を通じた幸せを実感してもらえるように、そして変化が激しい市場環境に適応しながら弊社が目指す姿をより効果的に、効率的に実現できるように運営していきたい．

参考文献[1] ソフトウェアプロセス改善カンファレンス 2012（SPI
Japan 2012）システムズアプローチに基づくプロセス
改 善 メ ソ ッ ド ： SaPID が 意 図 す る コ ト （ Systems
analysis ／ Systems approach based Process
Improvement methoD）〜プロセスモデルをより有効活用するために／そして現場の自律改善運営を促進するために〜
http://www.jaspic.org/event/2012/SPIJapan/session3
A/3A4_ID023.pdf[2] SaPID 実践事例より～改善推進役がやるべきこと／
やってはいけないこと
現 場 が 自 ら の 一 歩 を 踏 み出 すために
http://www.jaspic.org/event/2013/SPIJapan/session2
B/2B3_ID011.pdf

110

SEA

ソフトウェア・シンポジウム2017 in 宮崎

コンテンツ開発プロジェクトとソフトウェア開発プロジェクトのマネージメント知見の類似性探究の試行報告
日下部 茂
長崎県立大学片平 梓
長崎県立大学要旨

青木 研
長崎県立大学の経験をもとにした段階的な実践力の養成をカリキュラ
ム内だけで実施することは困難である．図 1 に情報シス

創造性にもとづいて知的作業成果物を作成するというテム学科のカリキュラムツリーを示す．例えばプロジェ

観点から，ソフトウェアの開発と映像のようなコンテン

クトマネージメントに関して，座学が二年の後期，プロツの開発には共通点があると考える．例えば，開発支援

ジェクト型のチーム型演習が三年開講されるものの，カ

技術の進歩でルーチン作業の負荷は削減される傾向があ

リキュラム内で以前の経験の結果の振り返りを行いながると同時に，大規模複雑化が進み上流工程では明確な見らプロジェクトマネージメントの実践力を向上させるサ

通しを得にくいけれども，上流工程での欠陥は後工程でイクルを複数実施することは難しい．

大きな問題となってしまう可能性が高い．本発表では，

我々はこのような問題に対して，課外での開発・創作

類似性がある領域のプロジェクトのマネージメントには活動を積極的に支援すると同時に，その知見の蓄積や共類似性があるとの仮定の下，大学での教育研究活動にお有も推進している．本発表では，そのような取り組みのいてコンテンツ開発プロジェクトにソフトウェア開発プ一つとして行っている，大学内でのコンテンツ開発プロ

ロジェクト管理の知見を適用する試みと，その予備評価

ジェクトにソフトウェア開発のプロジェクトマネージメ

について述べる．

ントの知見を適用する試みとその予備評価について述べる．
本稿の構成は以下の通りである．第 2 節で，今回の取1. はじめにり組みで対象とした映像コンテンツ作成プロジェクトについて説明する．第 3 節で，適用を試みたソフトウェア

著者らが所属する長崎県立大学の情報システム学部・開発のプロジェクトマネージメントの知見を説明する．

情報システム学科は，平成 28 年度から改組新設された

第 4 節は，学生視点での振り返りを行う．また，第 5 節学科である．一般の情報工学系の学科と比べ，デザイン・は，考察と今後の課題を述べる．第 6 節でまとめを行う．

コンテンツ系の教員の比率が高く，IT 分野における「アイデアを形にする能力」を重視し，「デザインもできる技

2. 映像コンテンツ作成プロジェクト

術者」や「 技術もわかるデザイナー」の育成を目指している．創造性を発揮して知的作業成果物を作成すると

本節では，ソフトウェア開発のプロジェクトマネージ

いう点から，ソフトウェアの開発と映像を含む多様なメ

メントの知見を適用した，大学内でのコンテンツ開発プ

ディアコンテンツの開発には共通点があると考え教育研

ロジェクトについて説明する．

究を進めている．
教育研究内容については，要素技術の知識やスキルだ

2.1. プロジェクトの目的

けでなくシステム開発やプロジェクトマネージメントの実践力も重視し，カリキュラム内だけでなく課外の活動

映像制作をおこなうには様々な技術やノウハウが必要も含めて継続的な改善に取り組んでいる．しかしながら，とされ，そのすべてを横断的に網羅して一度に教育するこ

様々な制約から，すべてに関して，座学だけでなく実際とは困難である．そこで，PBL(Project-Based Learning)

111

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 1. 情報システム学科のカリキュラムツリーの手法を用い，短編映画製作を企画して，学生と教員，ている．このような環境の中で，これらの作品に対抗し映像制作の専門家の共同作業による実践的な映像制作をうる作品作りのノウハウを，学生自ら経験的に学んでい試行する課外活動プロジェクトを実施している．その過く教育方法の確立を目指す．

程では以下を得ることを目指す．

2.2. プロジェクトの概要• 参加学生に対する教育効果

映像制作を後述のように，プリプロダクション（企画，• PBL による教育ノウハウの蓄積

脚本，ロケハン），プロダクション（撮影），ポストプ• 教育のための教員の実践的技能の向上

ロダクション（編集，整音，色補正，CG 等）のフェー
ズに分けて考えた上で，プロジェクトを実施する．さら• 公的なコンペティションによる作品評価と実績に，用いる要素技術を段階的に高度化し，プロジェクト

教員や専門家との PBL 型の共同作業を通して学生が主を段階的に高度化，複雑化していく．

体的に学び，コンペティションで採択されるレベルの作
品作りを目指しながら，定型的な教育が難しい映像制作

プリプロダクションの技術とノウハウの模索と蓄積を試行する．
現在，映像系コンペティションは，海外においては戦略的な国家予算をつぎ込んだアジア諸国の大学の作品，
国内においてはプロモーション目的で映像プロダクショ• 短編映画作品企画：参加学生を募り，短編映画の作
品企画を立てる．
• 脚本制作：企画に沿って脚本制作をおこなう．

ンが制作した作品といったものが，インターネットを通• ロケハン 脚本推敲：脚本から撮影場所を決定する．

して広く応募されており，極めてレベルが高くなってき

112

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ロケハンによる撮影条件の検討から，脚本の推敲を重要とされ，上流工程が重要視され上流工程からモデル

おこなう．

を活用することも普及している．同様に，映像分野でもVFX(ビジュアルエフェクト) を用いた工程の複雑化が進

プロダクション

む一方，上流工程からプレビズを活用するといった上流• 出演者決定 リハーサル 美術製作 撮影準備：出演者を決定し，脚本の読み合わせなどリハーサルをおこ重視の傾向が強くなっている．さらに，どちらも，プロなう．出演者には，一部プロを援用する．美術の設状況に応じてテーラリングや改善を継続的に行うことが計と製作をおこなう．美術製作には一部プロを援用重要という点でも共通点がある．

セスを一旦構築すればそれで終わりということはなく，する．カメラテストや撮影許可の申請など，撮影準

3.1. アプローチの概要

備をおこなう．

• 撮影：撮影をおこなう．撮影にあたっては，機材運

今回のアプローチでは，要素技術もマネージメント技

搬車，出演者とスタッフの移動用のロケバス等の車術も段階的に高度化させていくという前提で，最初の両をレンタルする．照明には一部プロの援用と機材段階では，プロジェクトで用いる要素技術も適用するマレンタルをおこなう．

ネージメントの知見も高度なバックグラウンドがなくとも取り組みやすいものを中心とした．まず，入門的な要

ポストプロダクション

素技術を用いて映像コンテンツを作成するプロジェクト• 撮影後の編集，整音，色補正，CG 制作等をおこなう．

を実施，その後プロジェクトマネージメントの担当者が，ソフトウェア開発プロジェクトのマネージメントの入門• コンペティション応募準備 上映会（公開講座）準
備：コンペティションのリサーチや英語字幕の制作など，コンペティション応募準備をおこなう．上映

的な教材を読み，自身の体験の振り返りを行い適用可能な知見について考察した．

会（公開講座）用のプレゼン準備と，開催場所の確

3.2. 教材の概要

保，上映機材の手配をおこなう．

今回は，入門的な教材として， トム・デマルコの「プ• コンペティション応募 上映会（公開講座）開催

ロジェクト管理」がわかる本 [1] を採用した．その書籍では，章の見出しレベルで，以下の内容が紹介されてい3. 探究アプローチる 1．

この節では，コンテンツ開発プロジェクトでも適用可

1. プロジェクト管理は心の管理

能な，ソフトウェア開発プロジェクトのマネージメント

2. 生産性を向上させるオフィス環境の知見を探究する今回のアプローチについて説明する．
我々は，類似性がある領域ではプロジェクトの効果的

3. チーム力を上げるなマネージメントにも類似性があるとの仮定にもとづいて取り組みを行っている．ソフトウェアの開発と映像

4. プロジェクトを成功させる組織のようなコンテンツの開発では，創造性にもとづいて知5. デマルコのプロジェクト管理術的作業成果物を作成するという点だけでなく様々な類似性があると考える．開発支援技術の進歩でルーチン作業

6. ソフトウェア開発におけるリスク管理の負荷は削減される傾向があると同時に，大規模複雑化

7. リスク管理の手順が進み上流工程で明確な見通しを得にくい上に上流工程での欠陥は大きな問題となってしまう，といった点など

プロジェクト管理については，プロジェクトマネジメ

共通点が多いと考える．ソフトウェア開発では，効率のント協会 (PMI: Project Management Institute) が発向上や品質の向上には要素技術だけでなく，ソフトウェ

行している PMBOK ガイド (A Guide to the Project

アの開発プロセスも含めたライフサイクルプロセスが

1 節レベルの見出しは付録参照

113

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Management Body of Knowledge)[2] をはじめとしてガイドや入門書が多数あるが，高度なバックグラウンドがなくとも読みやすいものを今回の教材とした．

4.2. 生産性を向上させるオフィス環境「生産性を向上させるオフィス環境」については，4 項
目中，3 項目について共感し，1 項目は共感しなかった．

4. 事後分析
職場を楽しいところにするためには 「職場に小さな混
この節では，学内プロジェクトのマネージメントの担乱を導入」ということで，コンテストの開催やブレイン

当者による振り返りを紹介する．また，各大項目ごとに，ストーミングが提唱されているが，これは積極的に行っ共感を感じた小項目と，共感しなかった小項目をカウンていきたい．12 月に開催したクリスマス会は，そのいトした結果を示す．特に学生が共感したものについてはい例だと感じた．そのときに行った「青春選手権」といその内容を引用 (一部改編) して示した．

う企画は，元々はまだあまり話したことないメンバー同士や，初めて参加したメンバーとの仲を深めることが目的だったが，私自身を含め，とても刺激になった．また，

4.1. 「プロジェクト管理は心の管理」

プロジェクトチームの今後の方針や動きについてのブレ「プロジェクト管理は心の管理」の 8 項目中，7 項目

インストーミングを行ってみたいと思った．コンテスト，

について共感し，1 項目は共感しなかった．

というほどのことではないが，脚本，編集，撮影，演出などで競うということも今後やっていきたい．
」

管理者が陥る七つの錯覚 「『気をつけたい 7 つの錯覚』のような状態に実際に陥った．進捗管理をまめに行い，4.3. チーム力を上げる

各連絡はもっと確実に頻繁に取れ，もっと簡単により自動化したシステムでスケジュール管理や進捗管理が行え，「チーム力を上げる」に関しては，10 項目中，3 項目

多少厳しいことを言った方がいいはずだ，などをいつもについて共感し，4 項目は共感しなかった．3 項目につ考えていた． 部下を働かせるのではなく，働く気にさ

いてはどちらでもなかった．

せるとあったことに気づきを得た．
」

4.4. プロジェクトを成功させる組織
品質第一主義は開発者の自尊心 「『マーケットの要求』に対するものとして，プロジェクトチームの実績をはや「プロジェクトを成功させる組織」に関しては，6 項

く作りたい，という自身の気持ちや，後に延ばせば延ば

目中，2 項目について共感し，2 項目は共感しなかった．

すだけ結局雑になるのでは，という疑問から，品質やメ2 項目についてはどちらでもなかった．

ンバーの意向を無視して『自尊心』を満たせていないと伝染する管理者の怒り 「怒りは恐怖の別の表現，とい感じた．作品でも，結果として詰め込んだスケジュール

うことであるが，確かに私自身に当てはまる．このままでの撮影で疲労や焦りで後半はあまりいい演出を行えな

完成できないのではないか，今更このような変更をしてかった．
」

うまくいくのだろうか，今の段階でこの話合いをして撮影までに間に合うのだろうが，というような不安からつ生産性向上に関する法則とリスク管理 「リスク管理が足りてないということは痛感した．無駄な時間が多い．

いイライラすることは頻繁にある．実際にその場で怒りを表現したことはあまりないが，恐らくメンバーは察知

しかし，映画制作から無駄をなくしていいのだろうかとして気を遣ってくれていると思う．私が感情的になっての懸念もある．楽しんでやること，遊び心が，より良いいては，円滑に動かないことも考えられるので，むしろ作品を生み出すとも考えられるので，バランスを意識し私がメンバーの心情を汲んで話合い等を進めていけたらなくてはいけないと考える．
」

と思う．
」

114

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4.5. デマルコのプロジェクト管理術

4.6. ソフトウェア開発におけるリスク管理「デマルコのプロジェクト管理術」に関しては，10 項「ソフトウェア開発におけるリスク管理」に関しては，

目中，1 項目について共感し，7 項目は共感しなかった．

2 項目についてはどちらでもなかった．

12 項目中，共感する項目はなく，8 項目は共感しなかった．4 項目についてはどちらでもなかった．この結果は，ソフトウェア固有の事項が該当しないといった，領域の計画の変更を恐れてはならない 「今回の撮影でもあっ違いによるものなのか，まだリスク管理を考える域までたが，撮影の日になって突然脚本の内容や演出を変更す

達していないためなのか，といったいくつかの理由が考ることがある．もちろん，必要なことであり，よりよいえられるため，今後より詳細な分析を続ける予定である．

作品とするため，その変更についてはむしろプラス方向で捉えている．しかし，その変更により，撮影時間が伸「大人」のプロジェクト管理 「リスクについては本当

び，スケジュール通りに動かない．そこで，撮影も後日，に管理できないと感じている．起きてほしくないことを話合いも後日，と，日程が延期されていく．自分自身の，放置，または，なんとかなる，で片づけている．書き出

実績を得なければ，もっと作品を作らなければ，というしてまとめて，対策を考えることも行いたい．
」

焦りも相まって，延期されていく（予定のスケジュールを変更する）ことにとても抵抗がある．抵抗はあるが，4.7. リスク管理の手順

仕方ない，私の計画ミスだ，と考えてきたが，この節を読んで腑に落ちた．実際，撮影のスケジュールは，限ら「リスク管理の手順」に関しては，共感する項目はな

れた時間で撮影を終えるため，詰め込んだスケジュール

かった．この結果に関しては，領域の違いによるものなになっていた．疲労や空腹から，全体の空気も悪くなっのか，まだリスク管理を具体的に考える域まで達してていた．私のミスだ，と自分を責めることは簡単だが，いないためなのか，今後より詳細な分析を続ける予定でそれは責任と向き合っていない．より柔軟な対応を心掛

ある．

けたい．
」

5. 考察と今後の課題
プロジェクト初期は少人数で 「設計段階では少数精鋭で会議を行う，ということは取り入れてみたい．各部でソ フ ト ウェア 開 発 の 領 域 で は ，例 え ばの責任者が全体の現状を把握できてないことで，部と部

CMMI(Capability Maturity Model Integration)[3]2のようなプロセスモデルや TSP(Team Software Pro-での連携が取れていない．どの段階で少数でのミーティ

cess)/PSP(Personal Software Process)[4] [5] 3 のようなプロセステンプレートが提案され，実際に活用もさングを行うかは考える必要があるが，作品の初期段階で行いたい．
」

れている．当初はそのようなものを利用してコンテン
無駄な会議の減らし方 「よく『参加できなくてごめん』

ツ系のプロジェクトの教育を実施できないかとの検討とメンバーから言われる．プロジェクトチームの方針とも行った．しかしながら，ソフトウェアの開発とコンして，来られるとき，来られるメンバーが来る，というテンツ系の開発では考慮すべきことは必ずしも同じでことになっている．しかし，参加してもらわないと困るはない一方，コンテンツ領域において今回の趣旨にそっ人ももちろんいる．その一方，実際，無駄だと思うミー

た形で利用できるテンプレートや参照モデルを見つけ

ティングの時間もある．
「次のミーティングで何をする」

ることができなかった．

という宣言により，誰が来なくても大丈夫か，というこ

また，仮にそのようなものがあったとしても，プロとをはっきりさせたい．参加できないことを申し訳なく

ジェクト管理やプロセスの教育は，学生自らがある程度思わせることを減らすことで，より気軽な集まりにできの開発経験を経てその必要性を感じてからでないと，効

たらいい．
」

果的に実施することが困難である可能性がある．著者の
2 CMM & CMMI are registered in the U.S. Patent and Trademark Oﬃce by Carnegie Mellon University.
3 TSP & PSP are service marks of Carnegie Mellon University.

115

SEA

ソフトウェア・シンポジウム2017 in 宮崎

一人は，個人レベルのソフトウェア開発 PSP(Personal

Software Process) のインストラクタとして大学でそのトレーニングコースを講義・演習として行った経験がある．PSP は，CMM(Capability Maturity Model, CMMIの前身) のレベル 5 相当の組織でのエンジニアを想定して提案されており [6] ，学生にとっても有用でないかと考えた．しかしながら，実際には該当科目を選択する学生数も多くなく，トレーニングコースの完了率も高くな
かった 4 ．そういった経験もあり，モデルやテンプレートがあったとしても，学生がもつ知識やスキルのレベル，
プロジェクトでの学生の役割やプロジェクトの特性などに応じて，プロジェクト遂行時に学生が実際にどのよう
図 2. PSP のプロセスフロー

なことに必要性や重要性を感じるのか，といった観点で知見を集めることは重要と考えている．
学生が納得しやすいという観点で，4 節のような振り返りは有用である一方，系統だった整理・分類という観点では十分ではない．最終的には，多数の初学者を念頭に置いた学内の教育研究だけでなく，一定の経験をもつ
ソフトウェア開発者やコンテンツ開発者の双方にとって有用な一般化された知見の構築も目指すしている．そのような観点では，ソフトウェア開発領域で一定の評価を得ている CMMI-DEV(開発のための CMMI) といった参照モデルや PSP のようなテンプレートのフレームワー
クは有効と考えている．

PSP では図 2 に示すようなベースのプロセスフローと，プロセス要素が段階的に高度化されたプロセスのテンプレート 3 が定めれらている．また，CMMI では表 1のように複数のプロセス領域が系統的にモデル化されて図 3. PSP の段階的高度化いる．このようなソフトウェア開発領域で一定の評価を得ているものを参考にすることで，ソフトウェア開発と

6. おわりにコンテンツ開発での類似点や相違点も含め，双方の領域の開発者にとって有用な知見を取りとめることができる

創造性にもとづいて知的作業成果物を作成するという考えている．

観点から，ソフトウェアの開発と映像のようなメディア

このような取り組みが成功すれば，ソフトウェア開発

コンテンツの開発には共通点があると考え，大学内でのにおいて例えば UX(ユーザーエクスペリエンス) が重視

コンテンツ開発プロジェクトにソフトウェア開発のプロされる場合はコンテンツ開発の知見が有用になり，コン

ジェクトマネージメントの知見を適用する試行とその予テンツ開発において例えばデジタル化が進展するとソフ

備評価について述べた．ソフトウェア開発のプロジェク

トウェア開発の知見の有用になる，といったことが予想

トマネージメントの知見であっても，おおむね，領域にされる場合に，どのようなプロセス領域を重視し，どの非依存ともいえるものは，メディアコンテンツの開発プ

ようにチームや個人レベルのプラクティスに反映すればロジェクトのマネージメントにも適用できる可能性が高よいか系統的に取り組めると考えている．

いという評価を得た．しかしながら，ソフトウェア固有の事項に関連付けられていたり，種々の想定を必要とす

4 このような傾向は，PSP を採用している他大学でも類似の傾向があると聞いている．

116

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1. 開発のための能力成熟度モデル統合 (CMMI-DEV) のプロセス領域
段階表現での成熟度レベルとプロセス領域
2: 要件管理 (REQM: Requirements Management)
2: プロジェクト計画策定 (PP: Project Planning)
2: プロジェクトの監視と制御 (PMC: Project Monitoring and Control)
2: 供給者合意管理 (SAM: Supplier Agreement Management)
2: 測定と分析 (MA: Measurement and Analysis)
2: プロセスと成果物の品質保証 (PPQA: Process and Product Quality Assurance)
2: 構成管理 (CM: Configuration Management)
3: 要件開発 (RD: Requirements Development)
3: 技術解 (TS: Technical Solution)
3: 成果物統合 (PI: Product Integration)
3: 検証 (VER: Verification)
3: 妥当性確認 (VAL: Validation)
3: 組織プロセス重視 (OPF: Organizational Process Focus)
3: 組織プロセス定義 (OPD: Organizational Process Definition)
3: 組織トレーニング (OT: Organizational Training)
3: 統合プロジェクト管理 (IPM: Integrated Project Management)
3: リスク管理 (RSKM: Risk Management)
3: 決定分析と解決 (DAR: Decision Analysis and Resolution)
4: 組織プロセス実績 (OPP: Organizational Process Performance)
4: 定量的プロジェクト管理 (QPM: Quantitative Project Management)
5: 組織実績管理 (OPM: Organizational Performance Management)
5: 原因分析と解決 (CAR: Causal Analysis and Resolution)

るリスク管理に関する知見は，今後の取り組みでより詳

連続表現での区分
プロジェクト管理
プロジェクト管理
プロジェクト管理
プロジェクト管理
支援
支援
支援
エンジニアリングエンジニアリングエンジニアリングエンジニアリングエンジニアリング
プロセス管理プロセス管理プロセス管理プロジェクト管理
プロジェクト管理
支援
プロセス管理プロジェクト管理
プロセス管理支援[3] CMMI, http://cmmiinstitute.com/ (2017 年 5月 19 日参照)

細な分析を行う必要があると考える．
どちらの領域の開発でも，今後も引き続き支援技術が[4] Team Software Process, http://www.sei.cmu.

進化しルーチンワークは省力されると同時に，より一層

edu/tsp/ (2017 年 5 月 19 日参照)

大規模複雑化が進み，プロジェクトマネージメントの重要性も増すためこのような取り組みの重要性も増すと考[5] Watts S. Humphrey, A Self-improvement Pro-

えている．また，外部環境の変化，要素技術の進展，開cess For Software Engineers, Addison-Wesley Pub,
2005.

発プロセスの上流重視の傾向などもあり，一定の知見が確立したとしても継続的な見直しが必要と考えている．

[6] Watts S. Humphrey, Software Process Improve-

今後は，カリキュラム内外でのプロジェクト経験，「企業研究」や「インターンシップ」といった科目での実務者との交流や現場体験からのフィードバックなども通して，蓄積，共有される知見の高度化を目指す予定である．

ment A Personal View: How it Started and Where
it is Going, Softw. Process Improve. Pract. 12:
223-227, Wiley InterScience, 2007.
付録： トム・デマルコの「プロジェクト管理」がわ

参考文献

かる本

[1] 吉平健治，トム・デマルコの「プロジェクト管理」
がわかる本，秀和システム，2007の知見 (大項目と小項目)

1. プロジェクト管理は心の管理(a) プロジェクト失敗の本当の原因は?
(b) 管理者が陥る七つの錯覚[2] Project Management Institute, PMBOK (ProjectManagement Body of Knowledge) Guide,(c) 「管理ごっこ」をしていませんか?
(d) 品質第一主義は開発者の自尊心

http://www.pmi.org/pmbok-guide-standards/
foundational/pmbok (2017 年 5 月 19 日参照)(e) パーキンソンの法則は当てはまらない(f) プログラムは夜できあがる

117

SEA

ソフトウェア・シンポジウム2017 in 宮崎(g) 生産性向上に関する法則とリスク管理(h) リスク図による日程の解釈(h) プレッシャーと生産性の関係(i) 不確かなものへの不安

2. 生産性を向上させるオフィス環境

7. リスク管理の手順(a) 仕事に集中できるオフィスとは(a) リスク管理の五つのステップ(b) オフィス環境進化論(b) リスク発見の方法(c) 職場を楽しいところにするためには(c) リスクを隠してしまう会社文化(d) 破滅シナリオの提案

3. チーム力を上げる(e) 見えないリスクを発見する(a) 最高の人材を揃える(f) ソフトウェア開発でのリスク(b) 退職にまつわる無駄なコスト(g) リスク・エクスポージャー(c) 結束したチームがもたらす利益(h) インクリメンタル手法によるリスク軽減(d) 自己修復システムを使う(i) EVR による進捗管理(e) 結束させるためのチームの潰し方(j) 感度分析(f) チームを形成するための不思議な作用(k) 臆病なマネージメント(g) 部下，チームメンバを好きになれ(h) 体を使った採用術

4. プロジェクトを成功させる組織(a) 脅迫は効かない(b) 匿名性を使い「悪い情報」を伝達(c) 病んだ政治は避けられない(d) 伝染する管理者の怒り(e) 対立が仕様書をあいまいにする(f) 対立は仲裁によって解決する

5. デマルコのプロジェクト管理術(a) 失敗プロジェクトを打ち切る勇気が必要(b) 管理者の直観をモデル化する(c) 計画の変更を恐れてはならない(d) ソフトウェアのサイズを測定する(e) 開発プロセスに対しての考察(f) デバッグ時間を削減するには?
(g) 間違いを知らないのは一番怖い(h) プロジェクト初期は少人数で(i) 無駄な会議の減らし方

6. ソフトウェア開発におけるリスク管理(a) リスクのないプロジェクトには手を付けるな(b) 「大人」のプロジェクト管理(c) リスク管理と危機管理(d) リスク管理を行う理由(e) リスクを無視すると(f) 不確定性を数量化する(g) 不確定な日程の見積もり

118

SEA

ソフトウェア・シンポジウム2017 in 宮崎

勉強会を活用した組織成長モデル～機能期のチームが継続的に成長するために～
伊藤 修司
SCSK 株式会社
Shuuji.Itou@scsk.jp

山口 真
SCSK 株式会社
Makoto.Yamaguchi@scsk.jp

豊田 圭一郎SCSK 株式会社
Keiichirou.Toyoda@scsk.jp

要旨(3)「参加型勉強会」の成果
この活動の大きな成果は 4 つある①多様なメンバーの参加
多様なメンバーで議論することで,メンバーの考え方や発言に新たな可能性がみえた.
②現場のコミュニケーションが活性化
勉強会の中でチームの強みと実例を共有することで,チームの枠組みを超えた会話や連携が生まれた.
③積極的な発言を引き出す
全体会議で対立を恐れない積極的な発言が増えた.
④新しい知識やスキルへの意欲
旬のテーマや普段使わない手法を体験することで,組織やチームの外側にも目が向くようになった.結果,現場を改善しようとするや行動が増えた.

1. はじめに基幹系システムを保守・運用する組織やチームは,そのシステムが稼働し続ける限り,もしくは契約が続く限り,一定の経験を有するメンバーを中核に据えた体制を維持する必要がある.今回の事例報告では,機能期の段階に突入した組織が,メンバーを入れ替えずに更に成長していくための手法として,「参加型勉強会」を適用した事例を紹介する.

2. 事例概要(1) 「参加型勉強会」について
座学によるスキルや知識の習得を目的とした「通常の勉強会」とは異なり,グループワーク中心でアウトプット重視の勉強会である.この会の共通キーワードは「正解はありません」.物事の捉え方や考え方をバージョンアップする
気づきやヒントを得るための場で,参加者全員が主役になることができるのがポイントである.

(4)今後の課題
今後の課題として考えているのは 3 つ①全体とチームで中長期ビジョンと戦略の向き先を合わせる②プロジェクト内で柔軟な配置転換と育成③コミュニケーション量と質の可視化
組織成長モデルとして,今回示した勉強会の効果はごく一部分である.今後も活動を継続することで,有益な成果,
知見として発表できるように努めたい.

(2)「参加型勉強会」で工夫した点
運営にあたり,以下の 3 つの点を工夫した①こまめにふりかえりを実施
勉強会後やプロジェクトの節目に,KPT でふりかえりを実施し,各自の考え方の変化を可視化した.回を重ねるごとに学びの意識の高まりや前向きな意見が増えてきた.
②報告レポートで共有
毎回,報告レポートを作成して勉強会に参加できなかったメンバーとも内容を共有し,次回参加のきっかけとした.
③ランチ開催多様な参加者を募るためランチ形式での開催を優先.
業務後は参加が厳しいメンバーも参加しやすくなり,発言や考え方に多様性が生まれた.

参考文献[1] 翔泳社 Project Management Professional 第 5 版
P530-P534 （ISBN978-4-7981-3729-2）[2] チームが成長し続ける「ラーニングサイクル」 IT 現場を強くする 究極のチームビルディング P18-P19
斉藤 秀樹著 日経 BP 社
（ISBN978-4-8222-7186-2）[3] すばる舎リンケージ これだけ！,KPT P103-P106（ISBN978-4-7991-0275-6）

119

SEA

ソフトウェア・シンポジウム2017 in 宮崎

コードクローン変更過程における開発者のインタラクションとソフトウェア品質の関係
久木田 雄亮和歌山大学大学院 システム工学研究科
kukita.yusuke@g.wakayama-u.jp

要旨

大平 雅雄
和歌山大学 システム工学部
masao@sys.wakayama-u.ac.jp

このような懸念を払拭するために，コードクローンの検出手法 [1, 5, 10] や分析手法 [6, 7, 9] がこれまで盛んに

本稿では，コードクローン追跡ツール CCT (Code

研究されてきた．これら既存研究の多くは主に，ある時Clone Tracer) を用いて，コードクローンの変更に関与した開発者らとソフトウェア品質との関係について分析

点のソフトウェアシステムに含まれるコードクローンとする．CCT は，コードクローンの作成・利用過程におけンの変更がソフトウェアシステムの品質に与える影響にる人的影響を調査することを意図して設計されたコード

着目している．コードクローンの存在により，あるソー

クローン追跡ツールである．分散型バージョン管理シス

スコードに対する変更が他のソースコードに対してどの

テム Git を対象としたコードクローン追跡機能に加え，ように影響するかを把握することが困難になるため，結不具合管理システムと連携することで不具合を混入した果として品質が低下する可能性が高いと考えられていたコミットとその作成者を特定し分析するための機能を備ためである．しかしながら，これまでの膨大な量の研究えている．本稿では，3 つのオープンソース開発プロジェ

を通じて，コードクローンの存在と品質に明確な関係がクト（RxJava, c:geo, Jackson databind）を対象として認められる事例とそうでない事例が混在して報告されて行った社会ネットワーク分析の結果について報告する．

おり，未だ統一的なコンセンサスは得られていない [15]．

ソフトウェアシステムの品質，あるいは，コードクロー

そのため，特に近年では，ソフトウェアシステムの改良・保守の過程でコードクローンがどのように拡散し

1. はじめにていくのかを詳細に分析するためのクローン追跡手法[4, 8, 14] に注目が集まっている．ソフトウェアシステム
長きに渡るソフトウェアシステムの改良・保守の過程の開発において広く利用されているバージョン管理シス

では，生産性の向上を目的として既存コードが頻繁に再テムに記録された全変更履歴に基づいて，リビジョンを利用されることがある．その結果，「同一の」または「類1 つずつ辿りながらコードクローンの変更により不具合が混入される過程を正しく理解し，不具合の混入を未然に防ぐための対策につながると期待されている．

似する」コード片（本稿ではコードクローンあるいは単にクローンと呼ぶ）がソースコード全体に遍在することも少なくない．ソースコード全体にコードクローンが多

本稿では，我々[12, 16] が提案したコードクローン追跡

数存在する状況においてコードクローンに変更を加える

ツール CCT (Code Clone Tracer) を用いて，コードク

必要性が生じた場合，変更箇所が多岐に渡ることから多ローンの変更に関与した開発者らとソフトウェア品質とくコストが必要となったり，変更漏れにより新たな不具の関係について分析を行い，プロジェクトにおいてコー合を混入してしまう恐れがある．すなわち，改良・保守

ドクローンを作成することは悪影響を与えるものであるの初期段階では有益な手段であった既存コードの再利用

かをコードクローンに関係する Issue や開発者間の繋がが，結果的にその後の生産性や品質を低下させる原因とりから確認する．CCT は，コードクローンの作成・利用なる可能性がある．

過程における人的影響を調査することを意図して設計さ

120

SEA

ソフトウェア・シンポジウム2017 in 宮崎

れたコードクローン追跡ツールである．分散型バージョʁϨϑζϥϱ

ン管理システム Git を対象としたコードクローン追跡

機能に加え，不具合管理システムと連携することで不具ʁϜʖζ൅ਫ਼Ϩϑζϥϱ







਎Ϩϑζϥϱ
ࢢϨϑζϥϱ
















合を混入したコミットとその作成者を特定し分析するための機能を備えている．本稿では，3 つのオープンソー

図 1: リビジョンの親子関係の特定

ス開発プロジェクト (RxJava, c:geo, Jackson databind)を対象として行った社会ネットワーク分析の結果についWて報告する．

$%

5HY 

$%5HY 

$%5HY 

$%&5HY 

$%&本論文の構成は以下の通りである．続く 2 章では，まず，
コードクローン追跡ツール CCT (Code Clone Tracer)の実装について詳述する．3 章では，CCT の処理結果$

5HY 

%&&%を用いて，コードクローン変更過程における開発者のイ
ンタラクションとソフトウェア品質との関係を調査する$

ための分析方法について述べる．4 章では，3 つのオー
プンソース開発プロジェクト (RxJava, c:geo, Jackson

databind) を対象として行った社会ネットワーク分析の結果を示し，分析結果を考察する．最後に 5 章において，本稿をまとめるとともに本研究の今後の課題を示す．

%&

5HY 1
ຎྭ$・⿊実線はリビジョン関係を⽰しているϓΟ΢ϩʤ̘ͺϓΟ΢ϩ໌ʥ

௧Յ

รߍ
͵͢

รߍ

ࡡঈ

図 2: コード片特定対象ファイルの決定（リビジョンの親子関係は図 1 と同じ）

コードクローン追跡ツール CCT2$αʖχฤಝఈ
ଲেϓΟ΢ϩ

本章では，コードクローンの作成・利用過程における人的影響を調査するため実装したコードクローン追跡ツー

ンの追跡の 4 種類の処理を順に行う．以下ではそれぞれ

ル CCT (Code Clone Tracer) について述べる．CCT は，の処理について説明する．

に存在するコードクローンの追跡を想定しており，高速(1) Git におけるリビジョンの親子関係の特定：CCT
は分散型バージョン管理システム Git を対象とするたにクローンを特定することができる粗粒度なクローン

め，従来の集中型バージョン管理システムを対処とした特定方法 [13] を用いてクローンを追跡する 1 ．また，不クローン追跡 [4, 8, 14] のように時系列でリビジョンを

数千から数万リビジョンからなるソフトウェアシステム

では，コードクローン追跡機能とコードクローン分析機

1 つ 1 つ順に辿る方法は適用できない．そのため，以下の手順でリビジョンの親子関係を特定する（図 1）．まず，分析対象リポジトリに含まれるリビジョンの情報を能のそれぞれについて詳細に説明する．

取得する．次に，リビジョン毎に親リビジョンと子リビ

具合管理システムと連携することで不具合を混入したコ
ミットとその作成者を特定する機能を備えている．以降

ジョンを特定し（図 1 左），各リビジョンの親子関係を2.1記録する（図 1 右表）．リビジョンの親子関係を整理し

コードクローン追跡機能ておくことで，図 1 の Rev.1 や Rev.5 のように，複数の親リビジョンや子リビジョンを持つリビジョンが参照

分散バージョン管理システム Git を対象としたコード可能になる．

クローン追跡を実現するために，リボジトリに保存されているすべてのリビジョンを対象に，(1) リビジョンの(2) 各リビジョンに含まれる全コード片の特定：ファ親子関係の特定，(2) 各リビジョンに含まれる全コード

イル変更情報を基にして各リビジョンのコード片特定対

片の特定，(3) コードクローンの特定，(4) コードクロー

象ファイルを決定し（図 2），[13] と同様にブロック単位でコード片を特定する（図 3）．

1 実際，クローンの特定までの処理（コード片抽出，正規化，ハッまず，分析対象リポジトリのコミット履歴から，リビ

シュ化）は，CRD (Clone Region Descriptors)[4] ベースのクローン追跡ツール ECTEC ( Enhancement of CRD-Based Clone Tracker
for Evolution of Clones ) [8] の一部を再利用して実装している．

ジョン番号，コミット日時，コミッタ名，追加・変更・削

121

SEA

ソフトウェア・シンポジウム2017 in 宮崎ſřƀƇ ʰɥŚſʰʰɥƀƇʰ ʫɨŚƈſʰʰɥƀƇʰ ʫɩŚƈʫʫ Ś
ƈ

67(3
 

ſřƀƇ ʰɥŚſʰʰɥƀſʰʰɥƀʫʫ ŚƈſʰʰɥƀƇʰ ʫɨŚƈſʰʰɥƀƇʰ ʫɩŚ
ƈ

67(3
  

ſɛřɛƀƇɛʰɛŚſɛʰʰɛƀſɛʰʰɛƀɛʫɛʫɛŚƈſɛʰʰɥƀƇɛʰɛʫɛŚƈſɛʰʰɥƀƇɛʰɛʫɛŚƈ

W
5HY 









5HY 









5HY 









5HY 









5HY 











Q

Q





図 3: ブロックの検出・正規化・ハッシュ化の流れ（[13] より抜粋）除されたファイルについての情報（コミット情報と呼ぶ）を取得する．次に，分析対象リポジトリの最初のリビジョ

5HY 1ン（リポジトリに初めてコミットされたファイル群からຎྭέϫʖϱ͹௧੽
Qͺύρεϣ஍構成されるリビジョン）を調査し，最初のリビジョンをέϫʖϱ௧੽ࣨഌ

構成する全ファイルを特定する（図 2 における Rev.1）．
コミット情報を用いて，各リビジョンに加えられたすべ

Q

αʖχฤ

έϫʖϱॄ߻

図 4: コードクローンの追跡（リビジョンの親子関係は図 1 と同じ）ての変更（ファイルの追加・変更・削除）を，最初のリビジョンを起点として，リビジョンの親子関係に従って順次遡り最新のリビジョンまでコード片特定対象ファイド片が特定される．コードクローンの特定処理においてルを決定する．マージコミット（図 2 における Rev.5）

は，まず，[13] と同様の方法（図 3 の STEP3&4&5）で，では，変更の衝突が発生する場合がある．衝突がない場特定されたブロックを定められたフォーマットに整形す合，マージ元の 2 つのコミットとの差分情報を取得し，る．STEP3 において，ブロックに含まれる変数名とリテ変更が加えられたファイルをコード片特定対象ファイル

ラルは特殊文字にすることで正規化し，変数名やリテラとする．衝突が発生していた場合，衝突を解消するまで

ルのみが異なるようなクローンを特定できるようにする．

の履歴が抜け落ちていることがあるため，そのリビジョ

さらに，STEP4 において，正規化されたブロックの文

ンに存在するファイル情報を基にしてすべてのファイル

字列をもとにハッシュ値を算出する．そして，STEP5 にをコード片特定対象ファイルとする．なお，ソースコー

おいて，ハッシュ値の一致するブロックをクローンとし

ド以外のファイルは分析対象ではないため除外する．

て特定する．このコードクローン特定処理を前述の前処

コード片特定対象ファイルに対して行うコード片特定

理によって特定できた全てのリビジョンのコード片に対処理について以下で説明する．まず，最初のリビジョン

して行うことで，各リビジョンに存在するコードクローを構成する全ファイルに対してブロック単位でコード片ンを特定できる．

を特定する．図 3 の STEP1 でソースコードに対して字(4) コードクローンの追跡：コードクローンの追跡処

句解析，構文解析を行い，STEP2 でブロックの種類，条理では，最初のリビジョンに含まれるすべてのコード片

件式，シグネチャ，クラス名を特定する．ブロックとは，のハッシュ値を比較し，同じハッシュ値を持つコード片

クラスやメソッド，for 文や if 文などのブロック文を指の集合をクローン集合としてまとめ，以降のリビジョン

す．ブロック単位でコード片を特定した後，最初のリビでのクローン集合の前後関係を特定できるようにする．

ジョンを起点として以降のリビジョンを構成するファイ

具体的には，以下の方法でクローン集合の前後関係を特ルについてもコード片を順次特定する．このとき，最初定しクローン集合をリビジョン間で追跡する（図 4）．

のリビジョン以降のリビジョンでは，ファイルの変更情

まず，次の子リビジョンに存在しているクローン集合

報に基づいて，変更が加えられたファイル（図 3 のコーに含まれるコード片のハッシュ値を調べ，直前のリビジョ

ド片特定対象ファイル）のみに対してコード片を特定し，ンのクローンのハッシュ値と比較する．ハッシュ値が一変更がなかったファイルのコード片は前のリビジョンの致した場合は，前のリビジョンに存在するクローン集合

コード片情報を再利用する．

と同じクローン集合であるので要素数を前後のリビジョ(3) コードクローンの特定：前述の前処理により，すべてのリビジョンに対してブロック単位ですべてのコーンで比較する．要素数の増加によるものか，ハッシュ値が変化しない変数名やリテラルの変更によるものかを判

122

SEA

ソフトウェア・シンポジウム2017 in 宮崎

下の処理によって実現している．

W
5HY 









(1) 開発者の特定処理：クローンの作成・利用過程に関与した開発者を作成者（オリジナルのクローンを作成ࡠ੔ं

5HY 










ཤ༽ं

5HY 



した開発者）
・利用者（既存のクローンを他の場所に移植した開発者）
・変更者（ハッシュ値の変更を伴わないクรߍं

ローンに対する変更をおこなった開発者）
・削除者（ファ5HY 



5HY 



イルの削除などによりクローンを削除した開発者）の 4

ࡡঈं





種類に分けて特定し，リビジョンと紐づける（図 5）．

ࡡঈं(2) 不具合混入リビジョンとファイルの特定処理：これまで紹介した機能はすべて Git リポジトリから得られ5HY 1ຎྭ৿‫و‬έϫʖϱॄ߻ࡡঈ͠Ηͪέϫʖϱॄ߻รߍέϫʖϱॄ߻ร਼໌͵ʹรԿ

รߍέϫʖϱॄ߻གྷો਼รԿ

る情報に基づいた処理であり，クローンの作成・利用過程に関与した開発者が混入した不具合に関する情報は別ʀࣰત໾һͳ఼ત໾һͺέϫʖϱ௧੽ͳέϫʖϱ௧੽ࣨഌΝනͤ

途，不具合管理システム（Bugzilla や Jira など）から

図 5: コードクローンの追跡と開発者の分類（リビジョンの親子関係は図 1 と同じ）取得する必要がある．本ツールには，SSZ アルゴリズム[11] を用いて不具合混入コミットを特定し，不具合を混入した開発者を分析する機能を実装してる．
別後，前のリビジョンのクローン集合を親集合，次のリ
ビジョンのクローン集合を子集合と解釈し，クローン集(3) コードクローンと不具合紐づけ処理：本ツールで行ったコードクローン追跡処理と不具合混入リビジョン

合間にリンクを張る．ハッシュ値だけの比較では追跡漏とファイルの特定処理の結果から得られる開発者と不具れが起きてしまうため，ハッシュ値の比較でリンクを張合の関係を用いて，コードクローンと不具合を紐づけるることができなかったクローン集合に対して [8] で用いらことによって，クローン・人・不具合の紐付けできる．

れている手法と同様に CRD の類似度比較（CRD はコー
ド片のブロックの種類やソースコードにおける位置情報

分析：開発者のインタラクションとソフト
ウェア品質

3

を含む表記形式で，この文字列が類似するかを比較）によってクローン集合間にリンクを張る．リンクが張られることがなかったクローン集合は，新たなクローン集合

本章では，コードクローン変更過程における開発者のが作成されたものと解釈し，該当クローン集合を以降のインタラクションとソフトウェア品質の関係を調べるた

リビジョンでの追跡対象とする．最後に，前のリビジョ

めに CCT を用いて行う分析と，分析で用いたデータセッ

ンにのみ存在するクローン集合は削除されたものと解釈

トについて述べる．

して追跡対象から除外する．
従来の追跡ツールである ECTEC[8] では全てのコード

3.1

目的

片に対してリンクを張ることによって，コードクローンの追跡を行っていた．本ツールではコードクローンのみ

ファイルの作成・変更に関与する開発者と品質を分析にリンクを張ることによってコードクローンの追跡を実した研究 [3, 2] から，開発者のインタラクションとソフ現しているので，コードクローンとは関係のないコード

トウェア品質には密接な関係があることが知られている．

片の追跡判定処理をする必要がなくなり，コードクロー

例えば文献 [3] では，安定して成長している OSS 開発プンの追跡にかかる処理時間を削減できる．

ロジェクトでは潜在的に密なコミュニティが存在しており，そのコミュニティに属する開発者同士が同じファイ

2.2

コードクローン分析機能

ルの変更に関与していることを明らかにしている．すな
わち，特定の開発者からなるグループでの密なインタラ

CCT はコードクローン追跡機能に加えて，コードク
ローンの作成・利用に関与した開発者とコードクローン

クションがソフトウェア品質に寄与することを示唆するの品質との関係を時間を遡って分析するための機能を以変更されてきたファイルよりも多数の開発者によって変ものである．一方，文献 [2] では，一人の開発者によって

123

SEA

ソフトウェア・シンポジウム2017 in 宮崎

更が加えられてきたファイルの方が欠陥が含まれやすい(2) 開発者の特定：次に，各コードクローンを変更（追加，修正，削除）した開発者の情報を CCT の処理結果から取り出す．

ことを明らかにしている．文献 [3] とは反対の結果ではなく，開発者の疎なインタラクションを通じて同一ファイルに対する変更が行われるとソフトウェア品質の低下(3) ネットワーク情報の作成：(1), (2) の情報を用いを招くということを示唆したものである．

てコードクローンとコードクローンの変更に関与した開これらの研究成果は，ファイル単位での分析によりファ発者を紐付け，Pajek 形式のネットワークデータを作成

イルの作成・変更に関与した開発者とソフトウェア品質する．

の関係を示したものであった．そこで本稿では，コード(4) コードクローンと開発者の関係の可視化：(3) にクローン単位の分析でも同様の結果を導くことができる

より Pajek を用いてコードクローンと開発者の関係を無のかどうかを確かめることを目的とする．コードクロー

向グラフとして可視化する．

ンとソフトウェア品質の関係については多数の研究がとって有害である場合とそうでない場合が混在しており，(5) 開発者のインタラクションの可視化：さらに，(4)から同一クローンの変更に関与した開発者のみを紐づけることにより開発者のインタラクションを無向グラフと統一的なコンセンサスは未だ得られていない．さらに，

して可視化する．

存在しているが，コードクローンがソフトウェア品質に

コードクローン変更過程における開発者とソフトウェア

3.3

品質の関係について調べた研究はまだ多くないため，既

データセット

存研究では示されていないコードクローンの長期的な本稿では，GitHub3 で活発に活動を行なっている 3

メンテナンスのための新たな知見を提供できる可能性がつのオープンソース開発プロジェクト（RxJava, c:geo,

ある．

3.2

Jackson databind）を対象として分析を行う．RxJava はリアクティブプログラミングを支援するライブラリであ

分析方法

る．c:geo は Android 向けの GPS 機能を使ったゲーム
本稿では，コードクローン変更過程における開発者のアプリケーションである．Jackson databind は JSONのインタラクションを Pajek2 により可視化し分析する．

形式のデータを扱うことを支援するライブラリである．

Pajek とは人と人，人とモノの関係などをネットワーク
として表現し分析するためのネットワーク分析ツールの1 つである．分析では，課題管理システムに報告された

表 1 に各プロジェクトの基本統計量を示す．

課題 (Issue) に関係しているコードクローン（Issue 混入

開発者の数と Issue 未混入クローンの変更に関与（Issue

クローン）と Issue 解決のためにコードクローンの変更とは関連のない理由でコードクローンを変更）した開に関与した開発者との関係を Pajek により可視化する．

発者の数を指す．プロジェクト間でばらつきがあるもの

表 1 中の「Issue 混入 CC 変更」，
「Issue 未混入 CC 変更」とはそれぞれ，Issue 混入クローンの変更に関与した

また，対比のため，Issue の解決とは全く関係のないコーの，プロジェクトの開発者の約 1 割〜3 割程度がコード

ドクローン（Issue 未混入クローン）とその変更に関与

クローンの変更に関与していることが見て取れる．なお，した開発者との関係を可視化する．すなわち，品質に問題のあるコードクローンの変更に関与した開発者のイン

Github では Issue の種類をプロジェクト毎に自由に定義するタグで管理する仕様になっておりプロジェクト間

タラクションと，品質に問題のないコードクローンの変に共通のタグが存在しないため，本データセットにおけ更に関与した開発者のインタラクションとを比較する．

る Issue には不具合に関するものから機能拡張（エンハ

具体的には以下の手順で分析を行う．

ンスメント）に関するものまで含まれている．特定の種(1) Issue 混入クローンと未混入クローンの分別：まず類の課題のみを指すものではないことに注意されたい．

初めに，CCT の処理結果から得られる情報を基に，Issue

Issue の種類を厳密に区別するためにはすべての Issue をと紐づいた Issue 混入クローンと，Issue と紐づいていな

目視する必要があるため，本データセットでは区別しな

い Issue 未混入クローンとに分ける．

いこととしたが，分析結果に影響を与える可能性があり本研究の今後の課題とする．

2 Pajek, http://vlado.fmf.uni-lj.si/pub%20/networks/pajek/

3 https://www.github.com/

124

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1: 対象プロジェクトの統計量

プロジェクト名

RxJava

c:geo

対象期間

2014/08/30∼2016/06/29

2011/07/11∼2016/07/21

2011/12/23∼2016/07/21

1,397

9,821

3,260

73
18

107
28

114
17

リビジョン数
開発者総数
開発者数（人）(∗)

コードクローン（セット数）

Issue 数（件）

Issue 混入 CC 変更者

Jackson databind

Issue 未混入 CC 変更者

17

27

11

CC 合計
Issue 混入 CC

289
104

2,660
2,008

1,610
1,223

Issue 未混入 CC

185

652

387

Issue 合計
CC 関連有 Issue

1,892
35

5,849
405

1,307
241

CC 関連無 Issue

1,857

5,444

1,066

(∗) 開発者総数とは，プロジェクトでコードを変更したことのあるすべての開発者の数である．直下の 2 項目（Issue 混入/未混入 CC 変更）はコードクローン (CC) の変更に関与した開発者の数を示すもので，それら 2 項目の合計とはプロジェクト全体の開発者の合計は一致しない．

表 1 中，「Issue 混入 CC」，
「Issue 未混入 CC」とはそれ分析結果と考察

4

ぞれ，変更されたコードクローンの内，Issue が混入していたものと未混入だったもの数を意味している．それぞ

本章では，前章で述べたデータセットに対して Pajek

れを足し合わせたものが合計と一致する．なお，コードを用いて可視化した開発者のインタラクションをプロ

クローンは，クローンとなっているコード片の総数ではジェクト毎に示し結果を考察する．

なくクローン関係にあるコード片集合（セット数）を示

4.1

すものである．コードクローンはリビジョン数の違いを考慮してもプロジェクト間で大きな差異があることがわ

Pajek で可視化した開発者のインタラクションを可視化した結果を図 6〜図 11 に示す．すべての可視化結果
において，赤色のノードは Issue 混入クローンを，緑色かる．特に，c:geo では 2,008 セットの Issue 混入クローンが存在しており，コードクローンに対する変更の多く
は Issue に関連したものである．Jackson databind も同のノードは Issue 未混入クローンを表す．黄色のノード

様に，コードクローンの変更の多くは Issue に関連してが開発者である．

いることが見て取れる．

図 6, 8, 10 は，コードクローンを変更した開発者と変表 1 中，「CC 関連有 Issue」，「CC 関連無 Issue」と更されたコードクローンの間をエッジで結び，コードク

はそれぞれ，報告された Issue を解決するためにコードクローンの変更を伴ったものとコードクローンの変更
は伴わなかったものを意味している．それぞれを足し合

概要

ローンとコードクローンの変更に関与した開発者の関係（開発者とコードクローンのインタラクション）を，Issue
混入クローンと Issue 未混入クローンとで対比できるよ

わせたものが Issue 合計と一致する．RxJava について

うに可視化したものである．

は，報告された Issue に占める CC 関連有 Issue は少な

図 7, 9, 11 は，図 6, 8, 10 のグラフから，同じコード

い (35/1,892) が，c:geo および Jackson databind につクローンを変更したことのある開発者間をエッジで結び，いては比較的多くの Issue がコードクローンの変更に関

コードクローンの変更に関与した開発者同士の関係（開係していることが見て取れる．

発者間のインタラクション）のみを抽出し可視化したものである．開発者とコードクローンのインタラクションと同様に，Issue 混入クローンと Issue 未混入クローン

125

SEA

ソフトウェア・シンポジウム2017 in 宮崎(a) Issue 混入（密度：0.603）(b) Issue 未混入（密度：0.394）

図 6: コードクローンと開発者の関係 (RxJava)(a) Issue 混入（密度：0.614）(b) Issue 未混入（密度：0.529）

図 7: 開発者の関係 (RxJava)とで対比できるようにしている．開発者間のインタラク

ドクローンの変更に関与していることが分かる．

ションは，開発者同士が同じコードクローンを共同で作一方，図 7 からは Issue 混入クローン数 (104) は Issue

成・変更・利用したことを意味する．つまり，図 7, 9, 11

未混入クローン数 (185) よりも少ないにもかかわらず，のグラフが密になっているということは，開発者同士が

図 7(a) の方が若干ではあるが密な構造になっているこ

同じコードクローンを共同で作成・変更・利用したこととが分かる．コードクローンは開発担当者の異なる複が多いということを示している．各グラフの密度はある数のファイルに散在していることが多いが，いずれかのグラフの辺の数とそのグラフの可能な辺の数の最大数でファイル中のコードクローンを変更した場合にはその他割ったものである．

のファイル中のコードクローンも変更する必要が生じや次節では，これらの可視化結果をプロジェクトごとにすい．特に Issue 混入クローンでは，コードクローンの

考察する．

4.2

変更により Issue を混入させる，あるいは，Issue を解決するためにコードクローンを変更する必要があるため，

RxJava

コードクローンを含むファイル間の依存関係が Issue 未

表 1 より，RxJava は他の 2 プロジェクトに比べて変混入コードクローンの変更よりも強く現れやすいものと更されたクローンセット数（CC 合計: 289, Issue 混入考えられる．結果的に，Issue 混入クローンの変更に関

CC: 104, Issue 未混入 CC: 185）が少ないことが分かる．

与した開発者同士のインタラクションは，Issue 未混入

図 6 からも変更されたコードクローンの数に違いがある

クローンの変更に関与した開発者同士のインタラクショ

ものの，開発者とコードクローンのインタラクションのンよりも密になるものと思われる．

基本構造に大きな違いがないことが見て取れる．実際，
図 6(a), (b) のどちらも 5, 6 名の開発者が数多くのコー

126

SEA

ソフトウェア・シンポジウム2017 in 宮崎(a) Issue 混入（密度：0.891）(b) Issue 未混入（密度：0.333）

図 8: コードクローンと開発者の関係 (c:geo)(a) Issue 混入（密度：0.597）(b) Issue 未混入（密度：0.351）

図 9: 開発者の関係 (c:geo)

4.3

Issue 混入クローンを変更する場合の方が開発者同士のc:geo

インタラクションが密になっていることが分かる．Issue

表 1 より，c:geo は他の 2 プロジェクトに比べてリビ未混入クローンの変更では，Issue 混入クローンの変更

ジョン数が最も多く，変更されたクローンセット数（CC
合計: 2,660, Issue 混入 CC: 2,008, Issue 未混入 CC: 652）が非常に多いことが分かる．一方，コードクローンの変とは異なり数名の開発者がより多くの繋がり（エッジ）を持っているが全体としては比較的疎な構造担っていることが分かる．

更に関与した開発者自体は十数名多い程度（Issue 混入

CC 変更者: 28, Issue 未混入 CC 変更者：27）であるため，
図 8 のグラフではコードクローンのノードとそのエッジがグラフ要素の大半を占める．その結果，開発者とコー

4.4

Jackson databind

表 1 より，Jackson databind のリビジョン数 (3,260)
は c:geo (9,821) の 1/3 程度であることが分かる．一方，ドクローンのインタラクションの詳細を読み取ることがIssue 混入 CC および CC 関連有 Issue は 1/2 程度である

できないが，少なくとも少数の開発者が多数の Issue 混

ため，Jackson databind におけるソースコードの変更は入/未混入クローンの変更に関与していることは見て取

3 つのプロジェクトの中で最もコードクローンの変更にれる．RxJava と同様，少数の中心的な開発者がコードよるものであることが読み取れる．図 10 からは，Issue

クローンの変更において重要な役割を担っていると思わ混入クローンの変更では 2 名，Issue 混入クローンの変れる．

更では 1 名の開発者がほとんどのコードクローンの変更

図 9 からは，コードクローンの変更に関与した開発者に関与していることが分かる．

の数はほぼ同じであるが，Issue 混入クローン数 (2,008)
が Issue 未混入クローン数 (652) よりも相当多いため，

127

図 11 からも，同様のことが見て取れる．Jackson

databind では，1,2 名の中心的な開発者が作成したソー

SEA

ソフトウェア・シンポジウム2017 in 宮崎(a) Issue 混入（密度：0.855）(b) Issue 未混入（密度：1.223）

図 10: コードクローンと開発者の関係 (Jackson databind)(a) Issue 混入（密度：0.235）(b) Issue 未混入（密度：0.231）

図 11: 開発者の関係 (Jackson databind)

スコードには多くのコードクローンが含まれており，そ社会ネットワーク分析ツール Pajek によって可視化しの他の開発者がそれらコードクローンを利用した結果をた結果，以下の知見が得られた．

表しているものと思われる．Jackson databind において
も，Issue 混入クローンの変更の場合の方が 2 名以外の開発者のインタラクションも若干密な構造になっている．

Issue 未混入クローンの変更の場合は，1 名の開発者のみが全ての開発者とインタラクションが存在する構造になっており，他の開発者同士の繋がりはほとんど存在し• いずれのプロジェクトにおいても少数の開発者のみ
がコードクローンの編集の大多数に関与しており，Issue の存在の有無に関わらず各プロジェクトにおける開発者とコードクローンのインタラクションの全体構造に大きな違いはなかった（図 6, 8, 10）．
• Issue 混入クローンの変更に関与した開発者同士のインタラクションは比較的密な構造になる（図 7, 9,

ない．

本稿では，コードクローンの編集過程における開発11），すなわち，コードクローンに何らかの問題がありそれを解決するためには多くの利害関係者の協力を必要とする．問題のあるコードクローンの編集者のインタラクションとソフトウェア品質の関係を理解

は多数のソースコードの変更という観点だけではな

する事を目的として，我々が提案しているコードクロー

く，それぞれの担当者との調整や協力という観点か

ン追跡ツール CCT (Code Clone Tracer) を用いて，3らも影響範囲がより大きくなる可能性がある．

つのオープンソース開発プロジェクト（RxJava, c:geo,

本稿では，CCT の処理結果をもとに社会ネットワー

Jackson databind）を対象とした社会ネットワーク分析を行った．

ク分析を行ったが，まだ基本的な分析を終えた段階であ

5. まとめと今後の課題

り，より有益な知見を提供するためには今後はさらに分

128

SEA

ソフトウェア・シンポジウム2017 in 宮崎

析を精錬する必要がある．本研究の今後の課題としては[3] C. Bird, D. Pattison, R. D’Souza, V. Filkov, and P. Devanbu. Latent social structure in open source projects.
In Proc. of the 16th ACM SIGSOFT Int’l Symp. on
Foundations of Software Engineering (FSE ’08), pp.
24–35, 2008.

以下のようなものが挙げられる．

• Issue の種類を分別する（本稿では不具合なのか機能拡張なのか等を区別していない）．

[4] E. Duala-Ekoko and M.P. Robillard. Clone region descriptors: Representing and tracking duplication insource code. ACM Trans. on Software Engineering andMethodology (TOSEM), Vol. 20, No. 1, pp. 3:1–3:31,
2010.

• Issue の内容を識別するとともに変更されたコード
クローンの内容を分析する（本稿では Issue の内容
やコードクローンの変更内容を詳細に把握しておらずコードクローンの変更理由は不明なままである）．

• Issue の内容を識別する（本稿では Issue の内容を詳細に把握していないのでコードクローンの変更理[5] S. Ducasse, M. Rieger, and S. Demeyer. A language
independent approach for detecting duplicated code.
In Proc. of the IEEE Int’l Conf. on Software Maintenance (ICSM ’99), pp. 109–118, 1999.
[6] N. Göde and R. Koschke. Frequency and risks ofchanges to clones. In Proc. of the 33rd Int’l Conf. on
Software Engineering (ICSE ’11), pp. 311–320, 2011.

由は不明なままである）．

• ファイル単位の従来の分析結果 [3, 2] と比較して，
コードクローンの編集過程においてのみ特徴的な現象を抽出する（本稿ではファイル単位での分析は[7] J. Harder. How multiple developers aﬀect the evolutionof code clones. In Proc. of the 2013 IEEE Int’l Conf. on
Software Maintenance (ICSM ’13), pp. 30–39, 2013.
[8] Y. Higo, K. Hotta, and S. Kusumoto. Enhancementof crd-based clone tracking. In Proc. of the 2013 Int’lWorkshop on Principles of Software Evolution (IWPSE ’13), pp. 28–37, 2013.

行っていないため，前述の知見はコードクローンの変更に関してのみ観察される事象でない可能性がある）．

[9] E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner. Do code clones matter? In Proc. of the 31st Int’l
Conf. on Software Engineering (ICSE ’09), pp. 485–
495, 2009.

• 開発者とコードクローンのインタラクションを時系列に可視化する（本稿では，過去のデータを一度に可視化しているためコンテキストが失われている）．

• 分析対象とする OSS プロジェクトデータを増やす，
あるいは，企業のプロジェクトデータを対象にする（本稿では，Github 上の 3 つの OSS プロジェクトを対象にしたのみ）．

謝辞[10] T. Kamiya, S. Kusumoto, and K. Inoue. Ccfinder: A
multilinguistic token-based code clone detection system for large scale source code. IEEE Transactions
on Software Engineering (TSE), Vol. 28, No. 7, pp.
654–670, 2002.
[11] J. Śliwerski, T. Zimmermann, and A. Zeller. When dochanges induce fixes? In Proc. of the 2005 Int’l Workshop on Mining Software Repositories (MSR ’05), pp.
1–5, 2005.
[12] 大平雅雄, 久木田雄亮. コードクローンの作成・利用過程における人的影響を調査するための追跡ツールの試作.
情報処理学会 ソフトウェア工学研究会, 第 2016-SE-193
巻, pp. 1–25, 7 2016.

本研究の一部は，文部科学省科学研究補助金（基盤(C): 15K00101）による助成を受けた．

[13] 堀田圭佑, 楊嘉晨, 肥後芳樹, 楠本真二. 粗粒度なコード
クローン検出手法の精度に関する調査. 情報処理学会論文誌, Vol. 56, No. 2, pp. 580–592, 2015.

参考文献[14] 堀田圭佑, 肥後芳樹, 楠本真二. Crd を用いたコードク
ローンの生存期間と修正回数に関する調査. 情報処理学
会論文誌, Vol. 55, No. 2, pp. 947–958, 2013.

[1] I.D. Baxter, A. Yahin, L. Moura, M. Sant’Anna, and
L. Bier. Clone detection using abstract syntax trees.
In Proc. of the Int’l Conf. on Software Maintenance(ICSM ’98), pp. 368–377, 1998.

[15] 堀田圭佑, 肥後芳樹, 楠本真二. 生成抑止，分析効率化，不具合検出を中心としたコードクローン管理支援技術に関する研究動向. コンピュータソフトウェア, Vol. 31, No. 1,
pp. 14–29, 2014.

[2] C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu. Don’t touch my code!: Examining the eﬀects
of ownership on software quality. In Proc. of the Joint
Meeting of the European Software Engineering Conf.
and the ACM SIGSOFT Symp. on the Foundationsof Software Engineering (ESEC/FSE ’11), pp. 4–14,
2011.

[16] 久木田雄亮, 大平雅雄. コードクローンの編集過程における開発者の潜在的社会構造に関する分析. 2016 年度情報処理学会関西支部大会 支部大会講演論文集, 第 2016 巻,
9 2016.

129

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Convolutional Neural Network を用いたフォールト数予測手法
小川 直記
株式会社 日立製作所
naoki.ogawa.od@hitachi.com

坂井 伸圭
株式会社 日立製作所
nobuyoshi.sakai.wx@hitachi.com

横内 弘株式会社 日立製作所
hiroshi.yokouchi.dn@hitachi.com
要旨て，効率的に多くのフォールトを発見することが重要である[15]．
我々のユースケースベースのソフトウェア開発[9]でも，品質指標を用いてテスト戦略を立てており，テストの十分性を判断するための品質指標の一つとして，「摘出フォールト数の目標値」を用いてきた．「摘出フォールト数の目標値」は，テストの計画時に予測し，テスト後に実際にテストで摘出されたフォールト数と比較して，品質状況の判断に用いる．また，値の算出は，過去のプロジェクト情報や開発対象のユースケースごとの仕様書を基に，有識者の経験から推定する必要がある．そのため，有識者に作業が集中することでプロジェクトのボトルネックとなり，さらにフォールト数の予測値が有識者の経験に依存してしまう．
本研究では，ユースケースベースのソフトウェア開発を対象として，仕様書の情報と過去のプロジェクト情報から，
ユースケースごとのフォールト数を予測する手法を提案する．過去のフォールト数と仕様書の文章データ，仕様書のページ数等の数値データを CNN[3]で学習させることで，フォールト数の予測を行う．本研究では，我々が実際に行った過去のソフトウェア開発プロジェクトのデータからフォールト数の予測を行い，定量的評価を行う．また，評価の結果，実際のプロジェクトで使用可能な程度の精度でフォールト数の予測が可能なことがわかった．

ソフトウェア開発のテスト工程において，いかに品質を確保しつつ，テストの効率を上げるかは重要な課題の一つである．そのために，品質状況を判断し，品質と効率のバランスを最適化する必要がある．そこで，我々は品質状況を判断するための指標の一つとして，「摘出フォールト数の目標値」をテストの十分性を判断するために用いている．この際，高い精度で予測出来なかった場合
は，過剰なテストを実施してしまう．しかし，高い精度の予測には開発者やテスト担当者が長年培ってきた経験が必要であるため，有識者に作業が集中してしまい全体のボトルネックとなってしまっていた．本研究では，過去のソ
フトウェア開発プロジェクトのデータから Convolutional
Neural Network（以下 CNN と略す)を用いてフォールト数の予測を行い，定量的評価を行う．評価の結果，実際のプロジェクトで使用可能な精度でフォールト数の予測が可能なことがわかった．

1. はじめにソフトウェア開発において，テスト工程の工数が全工程に占める割合は大きく，例えば，新規開発の場合では結合テストと総合テストを合わせると，全工程の 28.6%を占め，改良開発においては 33.2%を占めるという報告[19]がある．このような中で，ソフトウェア品質を確保するためのテスト工程においては，実運用に耐えられる品質を確保しつつ，効率的にテストを実施することが必要である．
しかし，効率のためにテスト工数を減らすと，摘出フォールト数が少なくなるため，品質が下がり，品質確保に注力してテスト工数を増やすと，摘出フォールト数は頭打ちになるため，テストの効率が下がるというトレードオフの課
題がある．
そこで，テスト工数を適切に割り当てるテスト戦略を立

2. 関連研究
フォールト数の推定では，開発プロジェクトの工程ごとに，フォールト数を推定するモデルが提案されている．例
えば，フォールト数の推移を時間や工数の関数として定義したレイリーモデルを使用する方法がある[12]．レイリ
ーモデルでは開発工程ごとのフォールト数が予測できる利点はあるが，モデルの形状パラメータの設定が必要であり，モデルに即していない場合は利用できない．また，

130

SEA

ソフトウェア・シンポジウム2017 in 宮崎

形状パラメータを過去のプロジェクト実績から設定する方法も提案されている[16]が，ユースケースベース単位で設定する場合，過去のプロジェクト実績から適切なデータを抽出するのは難しい．ファイル単位でコードメトリクス
や変更履歴から，フォールト数やフォールト密度を予測する手法[5]も存在するが，ファイルがどのユースケース
で使用されるか推定することは難しいため，ユースケース
ベースでのフォールト数予測に適用することは難しい．他にも製品のフォールト数が推定できるシステムとして，
SQE[1]が提案されている．しかし，ウォーターフォール型の画一的なソフトウェア開発時に製品全体への適用を想定されており，反復的かつユースケースベースの開発に適用するのは難しいことや，初期値の設定に経験が必要である．
また，品質を確保し，テストやレビューを効率的に行うために，フォールトを含んでいそうなモジュール(fault-prone module)を推定する研究は数多く行われている[2][18]．例えば，コードメトリクスや開発履歴のメトリクス，
プログラムをテキストマイニングした結果を用いて，分類
木[4]やロジスティック回帰，機械学習[6]で推定する手法が提案されている．また，fault-prone module の中でもSecurity[7][14]や Buffer Boundary Violation[17]等の特定の分野に特化した研究もおこなわれている．ただし，モ
ジュール単位での推定であり，実際のプログラムが既に存在することが前提であることや，フォールト数の推定は行っていない．

3.2. CNN を用いた有識者の思考のモデル化
本研究では，ユースケースの規模と仕様書の内容から，経験をもとにフォールト数を予測していた有識者の思考を，CNN で模倣する．ユースケースの規模の情報として仕様書のページ数，ドキュメント数，単語数の数値データを使用し，ユースケースの難しさの情報して仕様書の文章データを使用する．ユースケースの規模の情報としては，他にも開発予定工数やコード量を使用することが考えられる．しかし，開発予定工数は有識者の経験で予測しているため，経験に依存する．また，コード量は異なる
ユースケースで使用されているコードがあることや，機能単位ではないため，コードとユースケースの対応付けが難しい．そのため，ユースケースの規模の情報として仕様書の数値データを用いる．有識者の思考を模倣するた
めに，CNN を用いてユースケースごとの仕様書の数値データと仕様書の文章データの特徴を学習させる．ここで，本研究で入力として扱う仕様書とは，ユースケースごとに
概要，外部仕様，内部仕様が記載されたものを指す．
3.3. CNN の構造

本研究では，有識者が仕様書の内容を読み，フォー
ルト数の予測をすることを，CNN を用いて模倣する．

図 1 に本研究で用いた CNN の構造を示す．但し，各Convolution Layer 及び Fully Connected Layer に対しての Dropout Layer は省略している．また，各レイヤの上にレイヤの名称と行，列，深さの順で次元数を記述する．但し，列，深さについて，存在しない場合は省略して記述
する．本手法では活性化関数は全て ReLU 関数を用いている．Output Layer で ReLU 関数を用いた理由として，
フォールト数は 0 件が最小値となるからである．また，最適化アルゴリズムには Adam[11]を使用し，コスト関数には最小二乗誤差を用いた．

3.1. 従来のフォールト数予測

3.4. 入力値の前処理

従来は，有識者がユースケースの規模と仕様書の内容から，経験をもとにフォールト数を予測していた．有識者がフォールト数を予測する場合は次のような作業を行う．
まず，予め過去のユースケ―スの規模とフォールト数の実績値から，統計的に係数を算出しておく．予測する際に，算出された係数を用いて，新しいユースケースの規模に係数を掛け，予測値のベースとなる値を算出する．
次に，有識者は仕様書の内容を読み，ユースケースの難しさを考慮し，経験によってベースとなる値を補正することでフォールト数を予測する．

本手法では Input1，Input2 の入力値に対して，それぞれ次の前処理を行う．
 Input1
入力する仕様書は，MeCab[20]を用いてわかち
書きし ，単 語 単位 に区 切る ．仕 様 書の 類似 性を
CNN に判別させるために，Word2Vec[8]を用いて196 次元の単語の分散表現とする．また，仕様書を500 単語ずつに分け，1 つの仕様書を複数の仕様書として扱う．例えば，2000 単語の仕様書があった
場合，4 つの仕様書として扱う．また，500 単語に満たない場合，足りない部分は零ベクトルでパディングをする．CNN は主に画像処理で用いられる技術

3. CNN を用いたフォールト数予測手法

131

SEA

ソフトウェア・シンポジウム2017 in 宮崎Input1 は全て同じ値を入力とする．一般に CNN では多数の学習データが必要だが，多数のデータを得ることが難しい場合，疑似的にデータを増やすことが行われる．例えば，画像処理の分野では 1 枚の画像の明るさを変更したり，拡大，縮小，回転変形を加えたりし，データ数の問題を解決する．また，このようにデータを増やすことで，ノイズに強い学習モデルが生成できる．本研究では 1 つの仕様書を複数の仕様書に分割することで，同等の効果を得ることを目指す．

であり，隣接情報を考慮した特徴を抽出することが出来る．自然言語処理では隣接した単語の特徴を抽出することで，単語の並び順を考慮した文脈の特徴を抽出が可能となることが期待できる．
Input2
学習データに偏りが出ないように，仕様書のペー
ジ数，ドキュメント数，単語数の 3 つの数値データについて，平均 0，分散 1 となるように正規化を行う．
Input2 は 1 つのユースケースに対して 1 つが定まるが，Input1 で 1 つの仕様書が複数の仕様書に分割される．この際には分割された仕様書に対して，

図 1 : 本手法における CNN の構造

数を N としたとき，それぞれの値は以下の式(1), (2)で求められる．
̂∑ |𝑥 − 𝑥|
(1)
MAE =
𝑁

4. 評価
4.1. 評価尺度
フォールト数予測精度の評価尺度として，MAE(Mean
Absolute Error)，SD(Standard Deviation)の 2 つの指標を用いた．フォールト数の実測値を𝑥, 予測値を𝑥̂，データ

SD = √

132∑(𝑥 − 𝑥̂)2
𝑁

(2)

SEA

ソフトウェア・シンポジウム2017 in 宮崎

MAE は予測値のずれを表し，SD はユースケースごとにフォールト数の予測値がばらつかないかを示す

せた効果の検証のために，仕様書の文章データのみから予測した結果と，仕様書ページ数，ドキュメント数，単語数の 3 つの数値データのみから予測した結果も併記し，それぞれ(仕)，(数)と付記する．

指標であり，MAE，SD 共に小さい値は精度がよいことを表す．

表 3 : 同じプロジェクトの過去バージョンの学習デー
タからフォールト数を予測した結果

4.2. 評価データ
本研究では，開発プロセスや開発対象が類似している 2 つの製品 A，B を用いて検証を行った．検証のために過去のプロジェクトのデータを学習データ，テストデー
タの 2 つに分けて精度の検証を行った．ここで，学習データのバージョンはテストデータのバージョンより前のバージョンである．学習データ，テストデータに用いたバー
ジョン数とユースケース数をそれぞれ表 1，表 2 に示
す．

学習製品
A
A(仕)
A(数)
B
B(仕)
B(数)

表 1 : 学習データのバージョン数とユースケース数
製品
A
B

バージョン数
9
4

予測製品
A

B

MAE
1.22
3.04
7.35
3.72
4.09
1.72

SD
0.89
1.80
11.58
2.16
2.51
1.51

さらに，A と B を混ぜて学習させることで，学習データ
数を増やし，予測精度が上げられないか検証した結果を表 4 に示す．ここで，A と B を混ぜたデータを A+B と表記する．

ユースケース数7524

表 4 : 別プロジェクトのデータを混ぜた学習データ
からフォールト数を予測した結果
学習製品
A+B
A+B(仕)
A+B(数)
A+B
A+B(仕)
A+B(数)

表 2 : テストデータのバージョン数とユースケース数
製品
A
B

バージョン数2
2

ユースケース数
11
12

5. 評価結果

予測製品
A

B

MAE
1.27
3.61
7.74
1.40
5.54
2.37

SD
0.85
2.29
21.72
1.04
3.37
4.48

次に，学習の収束状況を評価するために，製品 A，Bのフォールト数予測における，5epoch ごとの MAE，SD の値を図 2～5 に示す．ここで A+B(学)は本手法のモデル
がフォールト数を予測するための表現力を有しているかを示すため，学習データを用いてフォールト数を予測したものである．

5.1. 結果
学習回数を 1500epoch とし，1500epoch 目のモデルで
製品 A，B のフォールト数を予測，評価した結果を表 3に示す．また，仕様書の文章データと数値データを合わ

133

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 2 : 製品 A のフォールト数を予測した時の MAE の 5epoch ごとの推移

図 3 : 製品 A のフォールト数を予測した時の SD の 5epoch ごとの推移

図 4 : 製品 B のフォールト数を予測した時の MAE の 5epoch ごとの推移

134

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 5 : 製品 B のフォールト数を予測した時の SD の 5epoch ごとの推移
1.98[件]であり，A と B を合わせて学習したモデルの場合の予測値では，有識者の精度以上となった．

6. 考察

6.2. 1500epoch での評価値の妥当性

6.1. 本手法の予測精度

本研究では，学習を 1500 回で打ち切って評価を行っている．しかし，固定回数での学習打ち切りでは，偶然精度の高い値になっただけの可能性がある．そこで，図 2，
4 において MAE の値に注目すると，A+B を学習データとした時，200epoch 程度で小さな振動はあるが，一定値に収束していることがわかる．予測値の小さな振動は，過学
習を抑えるために Dropout を実施していることが原因と考えられる．また，図 3，5 より SD の値に関しても，一定
epoch で収束している．よって，適当な回数で打ち切っても予測精度への影響は少なく，固定回数での打ち切りは実用上問題ないと考えられる．

表 3 より，製品 A では本手法の予測精度が最も高く，仕様書の文章データと数値データを合わせることで精度がよくなる効果が見て取れる．一方，製品 B では数値データのみが最も精度が高くなっている．製品 A，B では表
1 より，学習したユースケース数が 3 倍程度異なっている
ため，学習データ数が異なる．製品 B では学習データが十分でないため，学習しきれていない可能性がある．表4 より，開発プロセス，開発対象が似ている A，B のデータを混ぜ，学習データ数を同じにして学習させた場合，A
は予測値がほぼ同等であるが，B の予測値は改善が見ら
れ，A，B 共に本手法の予測値が最も高くなっている．一方，仕様書のみや数値データのみの場合，A と B を混ぜると精度が悪くなっている．以上により，仕様書の文章データと数値データを合わせることで，どちらか一方だけでは表せないユースケースの特徴が存在し ，本手法のCNN モデルで学習できていると考えられる．また，ユース
ケースの特徴は，開発プロセス，開発対象が似ている場
合，共通している部分があると推測できる．そのため，製品 B は製品 A と比べ，学習ユースケース数が少なかったが，本手法のモデルを使用することで，少なかったデー
タを別プロジェクトのデータで補って，精度の高い予測ができたと考えられる．この結果は，異なるプロジェクト間で汎用的なモデルが生成できるということを示唆している．
ここで，参考までに，我々の有識者による予測値のデータから MAE と SD を算出した所，それぞれ 1.50[件]，6.3. モデルの妥当性
学習データに対して，MAE と SD が 0 に近づかなかったり，振動し続けていたりする場合，入力値に対して出力値を表現することが出来ないモデルであり，学習モデルとして妥当ではない．図 2～5 において，MAE，SD の値
は 0 付近に収束しており，本研究における仕様書からフ
ォールト数を予測するために妥当なモデルであるといえる．
6.4. 本手法の限界
本研究では，ある製品プロジェクトの過去のバージョン
でフォールト数の予測を検証した．さらに，学習に使用していないプロジェクトのフォールト数を予測出来れば，適

135

SEA

ソフトウェア・シンポジウム2017 in 宮崎

参考文献

用範囲が広がる．そこで，製品 A，B をそれぞれ学習データとし，製品 B，A のフォールト数をそれぞれ予測できるか検証を行った．しかし，表 5 に示す通り，学習に使用していないプロジェクトへの適用は実現できなかった．本
研究では，仕様書の文章データと，仕様書のページ数，
ドキュメント数，単語数からフォールト数の予測を行ったが，コードメトリクス等の導入していないデータをいれることで，学習に使用していないプロジェクトのフォールト数を予測できる可能性はあり，さらなる検証が必要である．

[1] 橋本 弥一郎, 平島 俊一, 古賀 恵子, 横山 陽一,
森 文彦, ソフトウェア品質評価システム"SQE”, 日立評論, vol. 68, No. 5(1986-5), pp.55-58 , 1986.
[2] Ohlsson, N., Alberg, H. Predicting fault-prone
software modules in telephone switches. IEEE
Transactions on Software Engineering. 886-894.
1996.
[3] LeCun, Y., Bottou, L., Bengio, Y., Haffner, P.,
Gradient-based learning applied to document
recognition. Proceedings of the IEEE. 2278-2324.
1998.
[4] Khoshgoftaar, T. M., Allen, E. B., Deng, J. Using
regression trees to classify fault-prone softwaremodules. IEEE Transactions on Reliability. pp.
455-462. 2002[5] Ostrand, Thomas J., Elaine J. Weyuker, Robert M.
Bell. Predicting the location and number of faults inlarge software systems. IEEE Transactions on
Software Engineering. pp. 340-355. 2005
[6] Kim, S., Whitehead Jr, E. J., Zhang, Y. Classifying
software changes: Clean or buggy?. IEEE
Transactions on Software Engineering. pp. 181-196.
2008.
[7] T. Zimmerman, N. Nagappan, L. Williams.
Searching for a Needle in a Haystack: Predicting
Security Vulnerabilities for Windows Vista. In
Proceedings of the 2010 Third International
Conference on Software Testing , Verification andValidation (ICST '10). pp. 421-428. 2010.
[8] Mikolov, T., Sutskever, I., Chen, K., Corrado, G. S.,
Dean, J., Distributed Representations of Words andPhrases and their Compositionality. In Advances inneural information processing systems. pp.
3111-3119, 2013.
[9] Sakai, N., Nakanishi, M., Yokouchi, H., Improving
User Experience in a Large-scale Software
Development Project. In Proceedings of 6th World
Congress for Software Quality (6WCSQ). pp.
106-116. 2014.
[10] Kim, Y. Convolutional Neural Networks for
Sentence
Classification.
arXiv
preprint
arXiv:1408.5882. 2014.
[11] Kingma, D., Ba, J., Adam: A method for stochastic
optimization. arXiv preprint arXiv:1412.6980. 2014.
[12] 安藝優子, 野中誠. 摘出済み欠陥を考慮したレイリーモデルに基づくソフトウェア欠陥予測手法. In 経

表 5 : 学習に使用していないプロジェクトのフォールト
数予測精度
学習製品
A
B

予測製品
B
A

MAE
8.57
3.94

SD
9.56
2.35

7. おわりに本研究では，CNN を用いてフォールト数の予測モデ
ルを構築し，実際の開発プロジェクトのデータを用いて，
ユースケースベースでのフォールト数予測を行い，評価した．評価の結果，実際のプロジェクトで使用可能な精度でフォールト数の予測が可能ことを明らかにし，有識者の経験に頼っていた部分を機械で置き換えられる可能性を示した．
また，CNN に学習させるデータが足りない場合，開発プロセス，開発対象が似ている別プロジェクトの製品のデータを混ぜて学習させることで，精度を上げられることがわかった．一方で，学習に使用していないプロジェクトの予測へは適用できなかったため，さらなるモデルの改良や別の手法の適用を考える必要がある．
今後の課題として，他プロジェクトや，ユースケースベースの開発以外でのプロジェクトでの検証を行うことが考えられる．本研究ではユースケースベースの開発以外の仕様書を読み込ませ，フォールト数の予測ができるかは検証していないため，より汎用的に使える手法かの検証をしていく必要があると考えている．
また，本手法では仕様書のみからのフォールト数の予測を行った．そこで，コードメトリクスや開発履歴[13]の使用していないデータを導入し検証することや，仕様書等のドキュメントがない場合にでも適用できるフォールト数
予測手法を考案していく必要があると考えている．

136

SEA

ソフトウェア・シンポジウム2017 in 宮崎

営情報学会 全国研究発表大会要旨集 経営情報学会 2010 年秋季全国研究発表大会 . pp. 27-27.
2010.
[13] 畑秀明, 水野修, 菊野亨. 不具合予測に関するメト
リクスについての研究論文の系統的レビュー. コン
ピュータ ソフトウェア, pp.106-117. 2012[14] Scandariato, R., Walden, J., Hovsepyan, A., Joosen,
W. Predicting Vulnerable Software Components via
Text Mining. IEEE Transactions on Software
Engineering. pp. 993-1006. 2014.
[15] 中野大輔, 門田暁人, 亀井靖高, 松本健一. バグ
モジュール予測を用いたテスト工数割り当て戦略の
シミ ュレーショ ン. コンピュータ ソフトウェア . pp.
118-128. 2014.
[16] 田中公司, 生駒卓志, 津田和彦. ワイブル分布を用いたソフトウェア欠陥予測手法の検討. In 経営情
報学会 全国研究発表大会要旨集 2015 年秋季
全国研究発表大会 . pp. 21-24. 2015[17] Meng, Q., Zhang, B., Feng, C., Tang, C. Detecting
Buffer Boundary Violations Based on SVM. In
Information Science and Control Engineering(ICISCE), 2016 3rd International Conference on. pp.
313-316. 2016.
[18] Kaur, I., Bajpai, N. An Empirical Study on Fault
Prediction
using
Token-BasedApproach.
In Proceedings of the International Conference on
Advancesin
Information
Communication
Technology & Computing. P.32 2016.
[19] ソフトウェア開発データ白書 2016-2107. 独立行政法人情報処理推進機構(IPA) 技術本部 ソフトウェ
ア高信頼化センター(SEC). 2016[20] MeCab:
Yet
AnotherPart-of-SpeechandMorphological
Analyzer,(http://taku910.github.io/mecab/)

137

SEA

ソフトウェア・シンポジウム2017 in 宮崎

事例報告：AADL を用いた STAMP/STPA 支援岡本圭史，力武克彰
仙台高等専門学校{okamoto, yoshiaki}@sendai-nct.ac.jp

大友楓雅
仙台高等専門学校情報電子システム工学専攻
a1602006@sendai-nct.jp

要旨

また[3]では，手動分析と自動分析を組み合わせることで分析結果を充実させるというアプローチを提案している．
本稿では，[2]の分析法を STPA の手順に組込み，[3]の提案を試みる．

本稿では，アーキテクチャ記述分析言語 AADL による
安全分析手法 STAMP/STPA 支援事例として，特にハザード誘発要因識別の支援事例を報告する．

3. 事例：AADL を用いた CF 識別支援
1. はじめに複雑化したシステムの安全分析に対応するため，システム理論に基づく事故モデル STAMP(Systems-Theoretic
Accident Model and Process)及び STAMP に基づく安全分析手法 STPA(STAMP based Process Analysis)が提唱された[1]．STPA では，ハザードを識別，コントロールスト
ラクチャー（Control Structure，CS）を構築し(Step1)，それを 基 に ，コン ポ ーネ ン ト間 の非 安 全 制 御 動 作 (Unsafe
Control Action, UCA)を識別し(Step2-1)，得られた UCAの誘発要因（Causal Factor，CF)を識別する(Step2-2)．
STAMP/STPA では分析者の発想に重きを置くことで，従来法では気づきにくい要因に気付きやすくしている．
他方 AADL(Architecture Analysis and Design Language)を用いて，人と機械支援の相補的分析の提案[2]や，
STPA の一部自動化[3]が行われている．そこで，AADL
を 用 い た STAMP/STPA 支 援 法 の 提 案 を 目 標 と し ，AADL による STAMP のモデル化と STPA Step2-2 支援の事例を報告する．

2. STAMP/STPA と AADL
AADL はアーキテクチャ記述・分析言語であり，AADL
モデルにアノテーションを追記することで分析が可能になる．安全分析用アノテーションを定義した拡張に Error
Model Annex があり，安全分析をツール実行できる．
AADL と STAMP はともにコンポーネントベースである
ため，STAMP の CS は AADL モデルとして記述できる[2,3]．また STPA Step2-1 のタイプは Error Model Annexの エ ラ ー タ イ プ を 用 い て 定 義 で き る ． [2] で は ， Fault
Impact Analysis(FIA)を用いたハザード分析を行っている．

138

踏切への STPA 適用事例[4]を参考に CS を AADL モデルとして記述した．さらに FIA を用いて UCA 候補や CF候補の影響範囲を指摘し，その結果を参考に STPA を実施した．なお FIA を実施するために，Step1 のタイプをエラーソースとして， コンポーネント内やコンポーネント間のタイプ伝搬をエラー伝搬として，AADL モデルにそれぞれ追記した．
STPA Step2 支援に FIA を用いることで，分析対象
UCA を引き起こす CF を識別できた．具体的には， CFの影響範囲に分析対象 UCA が含まれることをツールにより指摘できた．また，CF が別のコントロールループの
UCA を引き起こすことも指摘できた．
以下の課題を確認した．1）分析項目に応じた AADL
モデル要素の詳細化が必要である．2）Step2-1 支援を実施するには，ハザードへの到達判定が必要となる．しかしハザードはシステムの状態であるため，モデルの改善が必要である．3)FIA は単一要因からの影響範囲のみ指摘可能であるため，複合要因の識別には FIA 以外あるいはモデルの改善が必要となる．
参考文献[1] Leveson, N. Engineering a Safer World: Systems
Thinking Applied to Safety. MIT Press, 2011[2] Procter,S.
andHatcliff,
J.
An
Architecturally-Integrated, Systems-Based Hazard
Analysis for Medical Applications, Formal Methods
and Models for Codesign (MEMOCODE), 2014
[3] Feiler, P. et al., Improving Quality Using
Architecture Fault Analysis with Confidence
Arguments, 2015[4] シ ス テ ム 安 全 性 解 析 WG ， は じ め て のSTAMP/STPA，情報処理推進機構，2016

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察‐酒屋倉庫問題の場合‐
岡野道太郎
筑波大学大学院ビジネス科学研究科
okano@gssm.otsuka.tsukuba.ac.jp

要旨

中谷 多哉子
放送大学 情報コース
tinakatani@ouj.ac.jpの一手法である KAOS[1] を用いる．KAOS については２章で詳述するが，簡潔に述べると，KAOS はシステム

本稿は，要求仕様書に書かれるべき，設計・実装・テの目標であるトップゴールからゴールの詳細化を繰り返ストに必要な情報を獲得するためにはどのような手法をすことで要求を獲得する手法である．我々の今までの研用いればよいかの知見を得ることを目標とする．この目

究ではゴールを「状態 P から状態 Q への状態遷移」と標へのアプローチとして，ゴール指向要求分析の一手法

し，詳細化手法として，状態遷移を詳細化するマイルス

である KAOS を用いる．この手法はシステムの目標でトーン分解 [1] と，状態 Q を詳細化する要素分解 [2] をあるトップゴールから，ゴールの詳細化を繰り返すこと

利用してきた．つまり，状態 P は詳細化しなかったが，により要求を獲得する．本稿ではゴール P → Q の詳細化

詳細化する必要がないのだろうかということについて，手法として，状態遷移→部分を詳細化するマイルストー

本稿では考察する．その結果，分解を行わないと依存性

ン分解と，状態 Q を分解する要素分解を用いる．そのに関して問題が生じ，設計に必要な情報が欠けることが際，状態 P については分解していないが，状態 P を分判明したので，依存性に対する提案を行い，「酒屋倉庫問解する必要があるかについて考察した．考察を行うため題」の事例を用いて提案を評価する．

に「酒屋倉庫問題」のゴール分解を行った．すると，状本稿の構成を以下に述べる．まず第二章で用語の説明

態Ｐを分解しないと依存性に関して問題が生じることがを行う．第三章で，上述した状態 P の分解について「酒判明した．そこで本稿では状態Ｐの部分を分解し，依存屋倉庫問題」を利用して考察する．第四章では，考察時に性を明記する表記法を提案する．関連研究では本稿の手生じた問題を解決する手法を提案し，その手法を酒屋倉

法と他の要求抽出手法との関連について議論し，今後の庫問題に適用する．第五章では，提案手法について考察

研究において本稿で取り上げた達成ゴール以外のゴール

する．第六章では関連研究として，本稿と i*[3],UML[4]について述べる．

の関連について述べる．第七章では今後の研究について述べ，第八章でまとめる．

1. はじめに

2. 用語の説明
2.1. KAOS について

ソフトウェア開発は，要求分析の後，設計・実装・テストの各工程が続く．そのため要求分析では，設計・実
装・テストに必要な情報が獲得される必要がある．このKAOS は，ゴールを要求獲得に活用する，ゴール指「設計・実装・テストに必要な情報」は何であり，その情向要求分析の一手法である．はじめにシステムが満たす報を要求分析の工程で獲得するには，どのような手法をぺきゴールをトップゴールとして１つ挙げ，そのゴール用いればよいかの知見を得ることが本稿の目標である．

を詳細化して，いくつかのゴールに分解し（この「詳細この目標へのアプローチとして，筆者はゴール指向分析

化により分解されたゴール」をサブゴールと記す），サ

139

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ブゴールを再度詳細化してサブゴールのサブゴールへ分をまとめてエージェントと記す）が実現できる Single–

解するというように，詳細化を繰り返す．すると，トッ
プゴールでは，多くの人が関わり，実現に複雑な過程をagent goal に分解される．この Single–agent goal は，対象システムのエージェントが実現する場合「要求」とな経るとしても，最終的には１人あるいは１システム（こり，それ以外のエージェントが実現する場合「期待」とれをエージェントと呼ぶ）が満たせる程度のゴールとななる．

る．このとき分解を終了し，末端ゴールをエージェント

つまり，文は意図を含むか否かにより，記述的な「ドに対する要求とする．このようにＫＡＯＳを用いれば，メイン知識」「，システム固有情報」と，規範的な「要求」，

要求はゴールの詳細化によって抽出できるが，そもそも，「期待」とに分かれる．よって，「設計・実装・テストに必「ゴールとは何か，「設計・実装・テストに必要な情報は要

要な要求仕様書で表現されるべき文」は，対象システム

求だけなのか」，「詳細化はどのように行うのか」についに関する文なので（「期待」を除いた）
「要求」，
「ドメイ

ては説明していない．そこで，まず，「設計・実装・テス

ン知識」，「システム固有情報」であるといえる．すなわ

トに必要な情報は要求だけなのか」について説明する．

ち要求以外にも必要な情報はあるが，少なくとも要求は必要であると言えるので，まず要求について分析する．

2.2. 設計・実装・テストに必要な情報と要求の関係

そして「要求」はゴールを分解することによって得られる．次に「ゴールとは何か」について説明する．

「設計・実装・テストに必要な情報」は，要求仕様書に文や図としてまとめられる．図は文章で表現すること

2.3. ゴールとは何かも可能なので，「設計・実装・テストに必要な情報」は文で表現することが可能であるとみなすことが出来る．そゴールとは，Lamsweerde[1] によると，「エージェン

して文を Lamsweerde は図 1 のように分類している [1]．

トの協調によって満足すべき意図を示した規範的な文」であるとしている．ゴールにはいくつかのタイプがある（詳細は「６．今後の研究」にて述べる）が，本稿では達成ゴールを取り扱う．達成ゴールは，振る舞いを表した
ゴールの一種で，状態遷移の連続であると [1] では定義している．よって，達成ゴールは「状態 P から状態 Q へ状態への遷移が完了している」のように記述できる．このような状態遷移を本稿では P → Q と表現する．P が状態変化が起こる前の状態（本稿では事前状態と呼ぶ），

Q は状態変化が起こった後の状態（本稿では事後状態と呼ぶ），→は P から Q へ状態が遷移する過程について表している．なお達成ゴールを [1] では，様相論理を用い
図 1. 文の分類（[1] を元に作成）て P →◇ Q で表現している．本稿ではそこまで厳密な定義をせず，ある状態から別の状態に遷移すれば，その文は意図を含むか否かにより，prescriptive な文と，de-scriptive な文に分けられる．本稿では前者を規範的な文，
後者を記述的な文と記す．記述的な文は，自然法則のよ

状態遷移を P → Q と表現し，それを達成ゴールとする．
よってトップゴールも達成ゴールの形式で書かれる．
そして詳細化すると最終的に要求が達成ゴールの形で得うなシステム開発者の意図とは関係なく従わなければな

られるが，どのように詳細化したら，要求が得られるからない domain property と，本システム開発上，そのについては説明していない．そこで次に詳細化の方法にようになっているという（例えば，本社は東京にあるな

ついて述べる．

ど）domain hypothesis がある．本稿では，前者をドメ
イン知識，後者をシステム固有情報と記す．そして規範

2.4. 詳細化はどのように行うのか的な文はゴールであり，このゴールは多くの人が関わる

Multi–agent goal から，詳細化を繰り返すことにより，一人または一システム（本稿ではこれらの人とシステム

140

達成ゴール P → Q の詳細化を，本稿では２つの方法で行う．一つは P → Q のうち，状態遷移（→）を分解

SEA

ソフトウェア・シンポジウム2017 in 宮崎

するマイルストーン分解であり，もう一つは Q の部分問題である．酒屋倉庫問題における本稿に関係のある事を分解する要素分解である．

項についてのみ，以下に記載する．

マイルストーン分解は [1] で述べられている．マイル• 酒屋についてストーン分解とは，P から Q への状態遷移が起こる過程において，マイルストーン M の状態を経るのであれ– 酒屋には倉庫係，受付係がある

ば P → M と M → Q に分解できるとする分解法である．
要素分解 [2] は，P から Q への状態遷移が起こったとき，事後状態 Q がいくつかの要素｛Q1 ,Q2 ,・・・Qn ｝か• 入庫について– 倉庫係はコンテナ入りの酒を倉庫に保管し，積ら成り立つとき，状態遷移 P → Q を事前状態 P，事後

荷票を受付係へ渡す

状態を各要素として分解する方法である．すると，P →– 積荷票の項目はコンテナ番号と搬入年月，日

Q1 ,P → Q2 ,・・・P → Qn に分解できるが，それだけでは時，内蔵品目と数量の繰り返しである｛Q1 ,Q2 ,・・・Qn ｝という各要素が存在する状態になるだ• 出庫についてけで，それが結合した状態にならないので，｛Q1 ,Q2 ,・・・

Qn ｝→ Q という状態遷移も付加することもあるとする– 受付係は出庫依頼を受ける分解法である．例えば，「お皿の上にスパゲティが盛り付けてある」を分解するとき，「お皿がある」「スパゲティ– 出庫依頼を基に倉庫係へ出庫指示書を出すがある」だけでは，お皿の上にスパゲティがあるかどうかわからない．そこで「お皿とスパゲティがある状態か– 出庫指示書の項目は注文番号，送り先名，コンテナ番号，品名，数量である

ら，スパゲティをお皿の上に盛り付けられている」とい– 出庫依頼の項目は，品名，数量，送り先名でうゴールを追加して分解する．なお要素分解における要ある素は，分解時に着目する視点によって様々に変わる．例– 在庫がない場合は依頼者に電話連絡し，在庫不足リストに記載する

えば，ユースケースに着目して，ユースケースごとに分解することも考えられるし，構成部品に着目し，部品ごとに分解することも考えられる．さらに機能に着目し，機能ごとに分解することもあり得る．

– 在庫不足リストの項目は，送り先名，品名，数量である– 空になる予定のコンテナを倉庫係に知らせる

2.5. 詳細化と本稿での考察との関係（出庫指示書に記載）– 倉庫内のコンテナ数はできる限り最小にする

我々は既に，達成ゴールをマイルストーン分解と要素– 出庫指示書の項目は，注文番号，送り先名，コ分解を用いて詳細化し，要求を導き出し，それとドメイ

ンテナ番号，品名，数量，空コンテナ搬出マー

ン知識・システム固有情報をもとに実装が行えるものがクである

あることを，電気工事の事例により示した [2]．
しかしここで疑問がある．状態遷移→と状態 Q は分

なお，
「在庫なし連絡」のための計算機プログラムと解したが，事前状態の P は分解する必要はないのだろう

は，本稿では，以下の項目の「在庫なし連絡票」を作る

か．本稿ではその事前状態 P の分解について考察する．

こととする．

• 在庫なし連絡票：注文番号，送り先名，品名，注文数量，不足数量

3. 事前状態 P の分解の必要性「酒屋倉庫問題」による考察

ここで，「帳票出力が行われている」というゴール分解
酒屋倉庫問題とは，情報処理 [5] に記載されている「あを行うと，図 2 のような分解を一例として挙げることがる酒類販売会社」（以下酒屋と記す）における「受付係できる．これ以外の分解方法も可能ではあるが，本稿での仕事（在庫なし連絡，出庫指示書作成，在庫不足リス

は問題点が明示しやすいため，この分解を元に議論を進ト作成）のための計算機プログラムを作成する」という

める．

141

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 2. 一般的な帳票作成のゴール分解
ここで図 2 の表記法について述べる．この表記はKAOS を基にしている．すなわち，始めにトップゴー

点により表現が異なる場合がある．このため同じ最終状

ルを挙げ，トップゴールをマイルストーン分解か要素分

図 2 に対し，帳票が「在庫なし連絡票」，「出庫指示

態のゴールでもラベルの表現が違うことがある．

解を行ってサブゴールを挙げる．この際，マイルストー書」，「在庫不足リスト」であることをトップゴール直下

ン分解を行ったか，要素分解を行ったかについては，注のサブゴールにそれぞれ適用すると，図 3 のようになる．

釈として記述している．さらに各サブゴールに対し，マ

ここで「Ｎ→Ｌ１：在庫なし連絡票の出力項目の求め

イルストーン分解または要素分解を適用して詳細なサブ方が決まっている」について議論する．このゴールは事ゴールを導いている．このとき図 2 のように，ゴールと前状態Ｎ，すなわち「帳票出力項目が決まっている」をサブゴールの間にある円と，各サブゴールが線で結ばれ満たしている必要がある．このゴールで示す「帳票」とている場合がＡＮＤ分解，ゴールから各サブゴールに線が出ている（この場合，１本の線の間に１つの円がある）
場合がＯＲ分解である．ＡＮＤ分解は，サブゴールの全は「在庫なし連絡票」，「出庫指示書」，「在庫不足リスト」の３つを指し，これらすべてが完了していないと事前状態Ｎを満たしていないことになる．しかし，Ｌ１のてが成立しないとゴールが成立しないものであり，ＯＲ

状態「在庫なし連絡票の出力項目の求め方が決まってい

分解は，サブゴールの一つが成立すればゴールが成立する」に遷移するためには「Ｍ→Ｎ１：在庫なし連絡票のるものである．ゴールの記号の内部に書かれている文字列をラベルと呼ぶ．本稿では，ラベルの前半にＰ→Ｑ等，
状態遷移が始めに記されている．そして，その後に「帳票の要求が抽出されている」などの状態が記されている．
つまり，ラベルの前半にゴールの状態遷移，後半に最終出力項目が決まっている」は満たす必要はあるが，「Ｍ→
Ｎ２：出庫指示書の出力項目が決まっている」を満たす
必要は必ずしもない．つまり，現状の表記法ではＮ→Ｌ
１を実行するためには，Ｍ→Ｎ１，M →Ｎ２，Ｍ→Ｎ３が必要となってしまっているが，M →Ｎ２，Ｍ→Ｎ３は状態Ｑの状態を表すものとする．したがって，状態Ｐの必ずしも必要ではなく，その分，成立条件が厳しくなっ

状態はＰを最終状態に持つゴールのラベルに記されていてしまっている．この問題を以下「問題１」と記す．

る．本来，最終状態が同じゴールの場合，ラベルの後半

また「Ｌ→Ｇ１：在庫なし連絡票のレイアウトが決まっも同じ表現になるはずであるが，同じ状態を指しても視ている」について議論すると，在庫なし連絡票のレイア

142

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 3. 酒屋倉庫問題のゴール分解ウトを決めるためには，「在庫なし連絡票の出力項目がが成立するためにはＰ→Ｍが成立しなければならない場

決まっている」とともに，「在庫なし連絡票を出力するメ

合，ゴールＭ→Ｑが達成するか否かは，ゴールＰ→Ｍがディアが決まっている」必要がある（ここでメディアと達成するか否かの結果に影響されるといえる．このようはＡ４の大きさのＰＤＦ等，出力先を示す）．そこで，に，ゴールＭ→Ｑの事前状態の成立が，ゴールＰ→Ｍの

Ｌ→Ｇ１のゴールの事前状態としては，「Ｎ→Ｌ１：在庫達成結果による場合，ゴールＭ→ＱはゴールＰ→Ｍに依なし連絡票の出力項目の求め方が決まっている」と「Ｐ存しているといい，この関係を依存性という．

→Ｍ１：在庫なし連絡票を出力するメディアが決まって問題１は事前状態 P を分解しないことにより生ずる問いる」の両方が満たされなければならない．ただし，「Ｐ題であり，事前状態の範囲，すなわち依存性の範囲を広→Ｍ１：在庫なし連絡票を出力するメディアが決まってく取りすぎている問題である．問題２は事前状態を分解いる」はレイアウトを決める直前までに決まっていればしたり，並行処理を認めたりした場合，それを認めなけよいのであって，「Ｎ→Ｌ１：在庫なし連絡票の出力項目

れば必ず成立していたが，認めることにより成立するかの求め方が決まっている」と同時並行で行ってもかまわ

どうか確かではなくなる可能性がある場合の問題である．

ない．一般的に出力先等，大まかな事項を決定してから依存性は，「設計・実装・テストに必要な情報」である．

出力項目等の詳細項目を決めるので，Ｐ→Ｍ，Ｍ→Ｎ，

なぜならば，もし依存性の情報がなく要求Ｐ→Ｑが成立

Ｎ→Ｌという遷移にしただけであり，順序は必須ではな

しているかテストを行おうとすると，事前状態Ｐが成立い．ところが図の表記法だと，同時並行を認めないようしていない状態でテストを行う可能性もあり，その場合に見えてしまい，その分，事前状態の成立条件が厳しく

正しく実装されていても，テストに失敗する．したがっなってしまっている．この問題を以下「問題２」と記す．

てテストを行う者にとって，テスト対象の依存性は必要

これら問題１，２は依存性の問題といえる．本稿におな情報といえる．
「設計・実装・テストに必要な情報」をいて依存性とは，ゴールＰ→Ｍ，Ｍ→Ｑに対し，Ｍ→Ｑ

獲得することが本稿の目的なので，依存性の問題を解決を達成するには事前状態Ｍが成立しなければならず，Ｍ

しないと，本稿の目的は達成できないことになる．そこ

143

SEA

ソフトウェア・シンポジウム2017 in 宮崎• Ｌ→Ｑのサブゴールにおいて，このときまでに，各帳票の出力項目とその求め方だけでなく，メディアも決まっていないといけないため，Ｌ⊃Ｌ１等の他で，問題１，２の解決法を次の章で提案する．

4. 提案手法にＬ＞Ｍ１等も加え，Ｌ⊃Ｌ１，Ｌ＞Ｍ１→Ｑ１等とした

ここでは，以下の表記法を提案する．
ゴールＰ→Ｑにおいて

なお，事前状態を分解したとき，その分解した状態が，• （問題１解決のための表記法）事前状態Ｐがいくつかの要素｛Ｐ１，Ｐ２，Ｐ３・・・Ｐｎ｝に分解可能
で，それらの要素の一部が成立すれば事前状態が成他のゴールの最終状態として存在するときは，その状態立したとみなせる場合，事前状態Ｐの後に⊃をつけ，なのでＮ１という状態名を使っている．もし分解された

その要素を列挙することにより，その列挙した状態

事前状態が，他のゴールの事後状態にも表れず，初期状が成立すれば，事前状態が成立したとみなす．例え態Ｐでもない場合は，別の状態名をつけ，その状態の内ば，事前状態Ｐが｛Ｐ１，Ｐ２，Ｐ３｝に分解可能

容を注釈に記載する．

名を使う．たとえば，Ｎ⊃Ｎ１→Ｌ１の分解された事前状態Ｎ１は，Ｍ＞Ｐ１→Ｎ１の最終状態Ｎ１と同じ状態

で，Ｐ１を満たせば事前状態が成立したとみなせる

5. 提案手法に対する考察

場合は，Ｐ⊃Ｐ１→Ｑと記述する．

• （問題２解決のための表記法）事前状態の分解を認めなければ成立した状態で，事前状態の分解を認めることにより，成立するかどうかが確かではない場

まず，この提案した表記法により，問題が解決したかを確認する．

後に＞をつけ，その状態を列挙することにより，そ• 問題１については，「在庫なし連絡票の出力項目の求め方が決まっている」のゴールはＮ⊃Ｎ１→Ｌ１の列挙した状態が成立しなければ，事前状態が成立となり，このゴールは在庫なし連絡票以外には依存しないものとすることができる．例えば，Ｐ→Ｑが，しなくなっている．すなわち，依存する範囲を的確

Ｐ→Ｍ，Ｍ→Ｑと分解でき，Ｐが｛Ｐ１，Ｐ２，Ｐに示していることなり，問題は解決した合や，その成立を明示したい場合は，事前状態Ｐの

３｝，Ｍが｛Ｍ１，Ｍ２，Ｍ３｝，Ｑが｛Ｑ１，Ｑ２，
Ｑ３｝に分解可能な時，Ｍ⊃Ｍ１→Ｑ１の事前状態• 問題２については，「在庫なし連絡票のレイアウトが決まっている」のゴールはＬ⊃Ｌ１，Ｌ＞Ｍ１→

Ｍ１が成立する際に，Ｐ１，Ｐ２が成立する必要がＱ１となり，このゴールは在庫なし連絡票のメディある時（Ｐ３は必須でない）Ｍ⊃Ｍ１，Ｍ＞｛Ｐ１，

ア (出力先等）と出力項目の求め方に依存している

Ｐ２｝→Ｑ１と記述する．

ことを明確に示している．すなわち，依存する範囲を的確に示していることなり，問題は解決した

この表記法を基に図 3 を分解すると，図 4 のようになる．

つまり，問題１，２は本提案の表記法により適切になり，

本提案によって変わった点は，ゴールラベルの前半に依存性が的確に示せるようになった．本稿のゴール分解記述される状態遷移を表す部分である．

手法は KAOS を基にしているが，KAOS では依存性が明白に示せなかったことは，問題１，２が生じたことか• Ｍ→Ｎのサブゴールにおいて，このゴールはＰ→Ｍと並行して行っても問題を生じないため，Ｍ＞Ｐ→らもわかる．新たに本稿が提案する記法を導入することによって，依存性が明確に記述できるようになった点に

Ｎ１等，Ｐの時点すなわちはじめから実行可能であ

本稿の新規性，有用性がある．

ることを明記した．

ただし，本稿では事前状態Ｐを分解しているが，その• Ｎ→Ｌのサブゴールにおいて，Ｎは，それぞれの帳票に対する事前状態が成立していればよいので，Ｎ際，分解の妥当性は保障していない．つまり，事前状態⊃Ｎ１→Ｌ１等，該当する帳票の状態のみを事前状

態Ｐに含まれているかということを保障するのは，その態に挙げるようにした分解を行った者の責任である．

ＰをＰ１，Ｐ２に分解した場合，Ｐ１は，本当に事前状

144

SEA

M>P→N2:出庫指示書の出力項目が決まっている

145

P→M3:在庫不足リストを出力するメディアが決まっているsakaya3 (1/1)

N⊃N1→L1:在庫なし連絡票の出力項目の求め方が決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

N⊃N2→L2:出庫指示書の出力項目の求め方が決まっているN⊃N3→L3:在庫不足リストの出力項目の求め方が決まっている

P→M2:出庫指示書を出力するメディアが決まっている

Ｐ→Ｍ１：在庫なし連絡票を出力するメディアが決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

L⊃L3,L>M3→Q3:在庫不足リストのレイアウトが決まっているL⊃L2,L>M2→Q2:出庫指示書のレイアウトが決まっている

L⊃L1,L>M1→Q1:在庫なし連絡票のレイアウトが決まっている

M>P→N1:在庫なし連絡票の出力項目が決まっている

L→Q:帳票レイアウトが決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

N→L:帳票出力項目の求め方が決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

M→N:帳票出力項目が決まっている

マイルストーン分解

M>P→N3:在庫不足リストの出力項目が決まっている

Ｐ→Ｍ：帳票出力するメディアが決まっている

P→Q:帳票の要求が抽出されている

ソフトウェア・シンポジウム2017 in 宮崎

図 4. 提案手法による酒屋倉庫問題のゴール分解

SEA

ソフトウェア・シンポジウム2017 in 宮崎

本稿で行っているマイルストーン分解は，状態遷移に

ゴール分解を行っている．マイルストーン分解は，振る基づく分解であるが，状態遷移はプロセスによって実現

舞いゴールである達成ゴールを分解していることから，されるので，プロセス分解を行っているといえる．また，振る舞いの分解といえる．そして本稿の記述法により振要素分解は，最終状態の構成要素に着目して分解を行っる舞いゴール間の依存性を示すことができるようになっているが，それは構造を分解していることになる．そした．そこで，依存性を辿っていくことにより，一連の振て，「酒屋倉庫問題」の事例では，マイルストーン分解とる舞いの流れを辿ることができる．このような振る舞い

要素分解の両方を用いている．したがって，今回の事例の流れを記述した図が「振る舞い図」であり，ＵＭＬ [4]はプロセス分解のみを行っているのでも，構造による分においては，アクティビティ図等が，振る舞い図に相当

解のみを行っているのではなく，両方の分解を適切に切する．

り替えることによって分解が実現できているといえる．
一般にシステムは，一連の情報処理プロセスが続いて実要素分解は最終状態を各要素に分解している．その際，行される．この際，各プロセスの入出力データにはデー

最終状態のデータ構造に着目し，データを構成する各要タ構造が存在する．よってシステムを分析するには，プ素に分解して，データ構造を表すことも出来る．そのよロセスの分析と各プロセスの入出力データのデータ構造

うな構造を表す図には，ＥＲ図やＵＭＬのクラス図等の分析の両方が行える必要がある．マイルストーン分解と構造図がある．

要素分解を適切に組み合わせることにより，このプロセ
ス分析とデータ構造分析が適切に行える．
次の章では，この依存性とプロセス分解を表現する振つまり本稿の表記法は，構造図と振る舞い図の両方をる舞い図や構造による分解を表現する構造図について，

１つの図の中に統合している．実際の要求分析は，本稿既存の他の研究と本稿の関係について議論する．

の酒屋倉庫問題の事例で示したように，プロセス分析と構造分析が適度に切り替えられて行われる．したがってこの分析結果は別々の図ではなく，統合した１つの図に

6. 関連研究

書かれることによって，その関係性が明示できる．その点で，本稿の表記法は優れている．ただし，実際にデー

本稿はゴール指向要求分析のＫＡＯＳを基にしていタベースのテーブルを定義するときは，プロセスは不要

る．ゴール指向要求分析では，この他に i*[3] がある．i*

であり，データベースの構造のみが必要となる．そのよでは，ゴールとアクター間の依存性をＤの記号を用いてうな場合は，テーブル構造のみを明記できるＥＲ図がふ表すことにより明示している．ＫＡＯＳでは要求をエー

さわしい．

ジェントに割り付けることにより，要求 (ゴール）とア
クターを含むエージェントの関係を明示することができる．さらに本稿の研究により，要求（ゴール）間の依存関連研究と本稿の関係についてまとめると，本稿はＫ性も明記できるようになった．i*は KAOS のようにトッ

ＡＯＳに新たな表記を加えることにより，依存性が明記

プゴールと要求の関係を明示できないので，本稿の表記できるようになり，これとマイルストーン分解，要素分法は，i*で表記できる依存性に加え，トップゴールから解により，依存性，振る舞い，構造を１つの統合した図の関係もゴールの詳細化により明示できる点で i*よりもで示せるようになった．前章で述べたとおり，システム

多くの情報を表記できるといえる．ただし，as–is 分析のを分析するには，プロセスの分析と各プロセスの入出力

場合，各エージェントが行っているゴールがトップゴー

データのデータ構造分析の両方が行える必要がある．プルを意識しているかどうかは定かではないため，この場ロセスの振る舞いと依存性，入出力データの構造を１つ合，トップゴールを明示しない i*のほうが描きやすい可の図で示せる点で，本稿の提案は優れており，有用性は能性はある．しかし to–be 分析においては，各エージェある．ただし，場合によっては，それらのうちの一部のントのゴールはトップゴールに貢献すべきであるので，情報のみが必要な場合があり，その場合には，依存性をトップゴールから各自のゴール，要求との関係が示せる

示す i*や振る舞いを表すＵＭＬの振る舞い図 (アクティ

本稿の表記法のほうが望ましいといえる．

ビティ図等），構造を示すＥＲ図やＵＭＬの構造図（クまた，本稿ではマイルストーン分解と要素分解によりラス図等）のほうがふさわしい．

146

SEA

ソフトウェア・シンポジウム2017 in 宮崎

7. 今後の研究

ゴールから要求が抽出できることを確認する必要がある．
我々は [6] において，酒屋倉庫問題は，以下の点が抜け

本稿では達成ゴールのゴールの詳細化について議論していることを指摘した．

た．しかしゴールには達成ゴール以外のゴールもある．
ゴールは，図 5 に示すように分類される [1]．すなわち，• 注文番号は出庫指示書の出力項目として挙げられているが，どのように生成されるか明示されていない• 積荷票からどのように出庫を割り当てるか，明示されていない
ゴール分解中に，これらの点が抜けていることを発見できるか確認することも必要となる．

8. まとめ本稿は，要求仕様書に書かれるべき，設計・実装・テ
図 5. ゴールの種類（ゴールタイプ）（[1] を元にストに必要な情報を獲得するためにはどのような手法を作成）用いればよいかの知見を得ることを目標とした．要求仕様書に書かれるべき情報は，要求，ドメイン知識，シス

まずはじめにソフトゴールと振る舞いゴールに分かれ，

テム固有情報であるが，本稿ではこのうち要求を獲得す

振る舞いゴールは本稿で取り上げた達成ゴールの他に，る手法について対象とした．要求を獲得するアプローチ

維持ゴールや回避ゴールがある．ソフトゴールは，「レス

として，ゴール指向要求分析の一手法である KAOS を

ポンスが３秒以内にあること」のような望ましい状態を用いた．この手法はシステムの目標であるトップゴール

示したゴールであり，非機能要求の中には，ソフトゴー

から，ゴールの詳細化を繰り返すことにより要求を獲得

ルで表現できるものもある（セキュリティ等は回避ゴーする．本稿ではゴール P → Q の詳細化手法として，状ルで示すものもある）．また，達成ゴールは最終状態で態遷移→部分を詳細化するマイルストーン分解と，状態ある「よいことがいつかは起こる」形のゴールであるが，Q 部分を分解する要素分解を用いた．その際，状態 P に

回避ゴールは「悪いことは起こらない」という形のゴー

ついては分解していないが，状態 P を分解する必要があ

ルであり，「不正アクセスが起こらない」といったセキュ

るかについて考察した．考察を行うために「酒屋倉庫問

リティ要求を表現することができる．維持ゴールは「よ題」のゴール分解を行った．すると，Ｐの部分を分解しいことが起こり続ける」であり，「システムが稼働し続けないと，依存性に関して問題が生じることが分かった．

ている」という運用・保守に関する要求を表現すること

そこで本稿では状態Ｐの部分を分解し，依存性を明記すができる．非機能要求やセキュリティ要求，保守・運用

る表記法を提案し，酒屋倉庫問題で確認した．本提案にの要求は，設計上必要な情報なので，「要求仕様書に書より，依存性，振る舞い，構造を１つの統合した図で示くべき内容」であるが，本稿ではそれらについて触れらせるようになった．既存の手法でも i*は依存性，ＵＭＬ

れていない．今後研究する必要がある．その際に，達成は振る舞いや構造を示せるが，依存性・振る舞い・構造

ゴールと i*,UML 等は関連があったが，他のゴールとのの関連を１つの図で示せる点で，本稿の提案は優れてお関連性はどうなのかについても研究する必要がある．達り，有用性がある．本稿で取り上げなかったゴールから，

成ゴール以外のゴールもＫＡＯＳでは表現できるが，も非機能要求やセキュリティ要求，保守・運用の要求が抽し i*やＵＭＬでは表現できない場合，ゴール抽出をＵＭ出できる．これらも設計・実装・テストに必要な情報なのＬのみで行うと，要求仕様書に書くべき要求が抜けるこ

で，今後研究する必要がある．また，本稿は酒屋倉庫問とになるからである．

題の一部しかゴール分解していないので，ゴール分解をまた，本稿では酒屋倉庫問題の一部しか取り上げて完成させ，設計・実装に必要な要求が欠けていることがいない．酒屋倉庫問題のゴール分解を完成させ，トップ検出できるかどうか確認することも今後の課題である．

147

SEA

ソフトウェア・シンポジウム2017 in 宮崎

参考文献[1] Axel van Lamsweerde, Requirements Engineering:
From System Goals to UML Models to Software
Specifications ,Wiley,2009.
[2] 岡野道太郎・中谷多哉子, 状態と状態遷移に着目した
ゴール指向要求分析手法の考察, 知能ソフトウェア工学研究会 (KBSE) , 電子情報通信学会技術研究報告: 信学技報 Vol.116 No.493,2017,pp25–30[3] i* homepage, http://www.cs.toronto.edu/km/
istar/(2017/3/12)[4] WHATIS

UML,

http://www.uml.org/

what-is-uml.htm(2017/3/12)[5] 山崎利治, 共通問題によるプログラム設計技法解説，
情報処理 Vol25 No9(1984).

[6] 岡野道太郎・中谷多哉子, 出力データに着目したゴー
ル指向分析による機能要求抽出方法の提案‐酒屋倉庫問題のケース‐ , ソフトウェア エンジニアリング
シンポジウム 2015, 情報処理学会 ソフトウェア工学
研究会,pp107 – 114

148

SEA

ソフトウェア・シンポジウム2017 in 宮崎

要件定義書からのファンクションポイント自動計測の試み
山田涼太 山田悠斗 楠本真二 柗本真佑 肥後芳樹
大阪大学大学院情報科学研究科{r-yamada, y-yuto, kusumoto, shinsuke, higo}@ist.osaka-u.ac.jp
要旨報システムの開発においても，要求内容に設計または開発に関する工程が含まれる場合には，原則 FP の見積り

一般にソフトウェア開発プロジェクトの見積りでは，及びその根拠を示すことが必須となりつつある [4]．そのまず開発規模が見積もられ，それを用いて工数や予算

一方，FP の導入における様々な課題のため，ベンダー・の見積りが行われる．開発規模の尺度として，最近ではユーザ企業ともに FP は十分に普及していない．1 つ目のファンクションポイント (FP) の利用が重要視されてい課題は，見積りのための基礎データが必要であることでる．一方で，FP を導入する上での幾つかの課題があり，ある．新規プロジェクトに対する FP を計測したとしてそれらの対策として計測の自動化が期待されている．

も，その値を工数に変換するためには，ある程度，過去

本稿では，開発の上流工程で作成される要件定義書をプロジェクトの FP 値と工数の情報が必要となる．次に，対象とした，FP 自動計測の試みについて報告する．提計測者の判断による誤差が生じる点である．詳細な部分案手法では，要件定義書のうち機能仕様についての記述の FP の計測には測定者の判断が必要となる．同一のソを提案するテンプレートを用いて書き換え，書き換えら

フトウェアからの FP 計測であっても，計測者によってれた仕様を解析し，計測に必要な要素を抽出することで誤差が生じてしまうという問題点が指摘されている [5]．

FP 計測を行う．4 種類の小規模な要件定義書を対象に

例えば，同じ組織の人間が同じアプリケーションに対し提案手法を適用し，手動での計測と比較することで精度て測定した場合は 12%，違う組織の人間が即していた場を確認した．その結果，3 つの要件定義書では手動計測

合は 30%以上の誤差が出るという報告もされている [6]．

と同様の値が，残りの 1 つの要件定義書では手動計測よ最後に，導入教育が必要である．FP 法を用いるためにり若干大きな値が計測された．

は，FP 計測方法や，見積りについての知識を身につけなければならない．それらの課題の 1 つの対策として，計測の自動化が考えられる．

FP 計測の自動化に関する研究としては，UML(Unified
Modelling Language) 図で記述された設計図からの計測[7, 8]，Web アプリケーション・プログラムからの計測

1. はじめに
一般に，ソフトウェア開発においては初期段階での[9, 10] 等があり，幾つかの制約を置いた上である程度正確な FP 値の計測が可能となっている．しかし，開発のソフトウェア開発規模の見積りが重要である [1] ．不正
確な見積りはプロジェクト失敗の原因になることも報告

上流工程で作成される主に自然語で記述された要件定義されている [2]．正確な見積りの実現を目指し，ソフト書を対象とした FP 自動計測手法は著者らの知る限りは

ウェア開発規模の見積りに関する研究が盛んに行われて存在しない．

いる．

本研究では，要件定義書 [11] を対象とした，FP 自動

見積りの基となる開発規模の尺度としてはソースコー

計測手法について検討する．まず，小規模な自然語で書ドの行数がよく使われていたが，最近ではファンクショ

かれた仕様に対して，仕様がどのように記述されていれンポイント (FP) [3] の利用が重要視されている．政府情

149

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ば計測が可能かを確認・調査する．その結果に基づいて，
自然語記述からの FP 計測方法を提案する．提案手法で

計測対象

は，機能仕様を FP 計測のためのテンプレートを用いた書き換え，書き換えられた仕様を解析して FP を計測す

他システム

成績管理
アプリケーション

成績登録

生徒管理
アプリケーションる．更に提案手法に基づいた計測ツールを試作し，様々なプロジェクトの仕様書で検証することで評価を行った．
以降，2 章では研究の背景となる諸用語や関連研究につ

EQ

成績表

参照

生徒名簿

成績検索

いて述べる．3 章では今回提案する自動計測の手法について述べる．4 章では実際に自動計測を行った結果と考

平均点を
含む

察について述べる．最後に 5 章で本報告のまとめを述
べる．

成績一覧
印刷

2. 準備

 成績表…内部論理ファイル(ILF) 生徒名簿…外部インターフェイスファイル(EIF)
 成績登録…外部入力(EI) 成績検索…外部照会(EQ) 成績一覧印刷…外部出力(EO)

図 1. 基本機能要素の例

本章では研究の背景となる諸用語や関連研究について

外部出力 (EO)

簡単に述べる．

計測境界外へのデータ出力を含む処理のうち，出力データに導出データを含むもの

2.1. ファンクションポイント法

外部照会 (EQ)

ソフトウェアの規模を見積もる手法の 1 つにファンク

計測境界外へのデータ出力を含む処理のうち，出力

ションポイント (FP) 法 [3] がある．FP 法は，ユーザかデータに導出データを含まないものであり，処理がら見た機能の量を計測する手法で，A.J.Albrecht によっ

ILF を更新しないものて 1979 年に提案された．画面や帳票，ファイルなどを通じた情報の入出力に着目し，それらを種類別に数え例として，図 1 に学生の成績管理アプリケーションと上げ，種類数を加重合計した値を機能量としている．以

そこに含まれる基本機能要素を示す．計測対象である成降，IFPUG 法 [12]，MarkII 法 [13]，COSMIC 法 [14] 等，

績管理アプリケーション内でデータが更新される成績表

様々な FP 法が提案されてきている．本研究では IFPUG

は ILF，成績管理アプリケーション内にはなく，成績管法を対象とし，以降，FP 法とは IFPUG 法を意味する

理アプリケーションから参照される生徒名簿は EIF となこととする．IFPUG 法は，Albrecht 版の使い勝手や曖る．また，データ入力によって成績の登録を行う成績登昧な部分を改良したバージョンであり，ビジネスアプリ

録処理は EI，成績表から平均点などの派生データを含ケーションソフトウェアを対象として欧米で広く使用さまないデータを出力させる成績検索は EQ，成績表かられている．IFPUG 法では，ソフトウェアの持つ機能か平均点などの派生データを含むデータを出力させる成績

ら 5 種類の基本機能要素を以下に示す [15]．

一覧印刷は EO となる．上記の 5 種のうち，ILF と EIF
はデータファンクション (以降，DF)，EI と EQ と EO

内部論理ファイル (ILF)

はトランザクションファクション (以降，TF) と呼ばれ，計測対象のアプリケーション内でデータが更新されそれぞれ計測に必要な要素が異なる [15]．

る論理的な関連を持ったデータの集合• DF

外部インターフェイスファイル (EIF)
計測対象のアプリケーションによってデータが参照– 種別…ILF，EIF

されるデータの集合 (データは更新されない)– DET(Data Element Type)…アプリケーショ
ン上で参照される項目の数

外部入力 (EI)
計測境界外からのデータ入力によって ILF の更新– RET(Record Element Type)…データ群の属性内のサブグループの数

を行う処理

150

SEA

ソフトウェア・シンポジウム2017 in 宮崎• TF

在庫不足情報は、– 種別…EI，EQ，EO

依頼番号と 送り先名と 銘柄と 数量を 持つ– DET…重複を除いた入出力項目の数に，該当処理において下記のものがあれば 1 ずつ増やデータ群です。

したもの

図 2. cabocha による解析例∗ きっかけ (処理が行われるトリガー．ボタンなど)

3. 提案手法∗ メッセージ (エラーメッセージなど)

本章では今回提案する計測手法について述べる．

– FTR(File Type Reference)…TF に関わる DFの数

3.1. 提案する FP 計測の流れ
上述した要素を用いて各機能の複雑度を計測し，その上で FP の値を求める．

2. で述べた通り，FP 法はユーザから見た機能の量を計測する手法であるため，要件定義書に記載されている• DF の複雑度情報を用いることで，計測することは可能である．しか表 1 を参照し DF の複雑度を決定する．例えば RET

し，一般には，必要な情報が省略されている場合も考えが 1，DET が 26 の ILF があった場合，表 1 より複られ，必ずしも全ての情報が記載されているとは限らな雑度は低となる．

い．そこで，幾つかの小規模な仕様書に対して，どの程度詳細に記述されていれば，自動計測が可能かどうかを• TF の複雑度確認した．その結果，以下のような仮説を仮定した．

EI，EO，EQ のそれぞれに対して用意されている
対応表を用いて，TF の複雑度を決定する．例えば，EI は，表 2 を参照し複雑度を求める．FTR が 2，
DET が 14 の EI の場合，複雑度は中となる．

A1 DF 計測の基となるアプリケーションで扱われるデー
タは，アプリケーションが行う処理（機能）での入力や処理の中で使われる項目として表れている．また，表の形で記載されることもある．

• 複雑度からの FP 計測
A2 DF において，DF が持つ項目についての情報は仕抽出された基本要素の複雑さ毎の個数を表 3 に代入様に明記されている必要がある．

し，それぞれに設定されている重み数を掛けて足し合わせた値が FP となる．前述の例であれば，複雑

A3 DF の種別は，TF において参照する DF が明記されていれば更新されるか否かが分かる．

度「低」の ILF(RET：1，DET：26) であれば重みは 10 となる．また，複雑度「中」の EI(FTR：2，

A4 DF の DET は，TF において参照する DF と入出力項目が明記されていれば特定することができる．

DET：14) であれば重みは 4 となる．
2.2

自然言語解析ツール cabocha

A5 TF 計測の基となるアプリケーションが提供する機能は，処理を表す文章や図を用いて表現されること

cabocha は Support Vector Machines(SVM) に基づ
く日本語係り受け解析器である [16]．入力として与えられた文中の各単語の品詞と各文節の係り先を取得する．

が多い．

A6 TF の種別は，仕様に含まれた特定の用語および出力項目と参照する DF から判別できる．

図 2 に解析例を示す．矢印はその文節の係り先を表している．図 2 からは，
『このデータ群は、』という文節は『データ群です。』に係り，『依頼番号と』という文節が間

A7 TF において，全ての TF に「きっかけの有無」が存在する．

接的に『持つ』という文節に係っていることが分かる．

151

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1. ILF と EIF の複雑度
PP
PP
DET
PP
1-19 20-50 > 50
PP
RET
P
1
低
低
中

表 2. EI の複雑度
PP
PP
DET
PP
1-4 5-15
PP
FTR
P
0-1
低
低

> 15
中

2-5

低

中

高

2

低

中

高

>5

中

高

高

>2

中

高

高

表 3. FP の算出のための計算表
低
中
高

ILF

□× 7=□□× 10=□□× 15=□

EIF□× 5=□□× 7=□□× 10=□

EI□× 3=□□× 4=□□× 6=□

EO□× 4=□□× 5=□□× 7=□

EQ□× 3=□□× 4=□□× 6=□

合計FP

A8 TF において，DET の根拠となる「入出力項目」「メ
ッセージの有無」および FTR の根拠となる「関わる DF」についての情報は仕様に明記されている必

要件定義書

機能仕様

品質仕様

…

書き換え

要がある．

計測用の仕様以上の仮説に基いて，以下の４つのステップを提案する．

要素の抽出

また，概要を図 3 を示す．

計測に必要な要素
自動計測

1. 要件定義書における機能を説明する部分の文章を自FP

動計測用テンプレートに合わせて計測用の仕様へと変換する．

図 3. 提案する FP 計測手法の概要

2. 変換した仕様から計測に必要な要素を抽出する．
• 一般には図表参照と記載されている部分について，文章で記述されていること．

3. 解析結果を用いて FP を計測する．

図 4 にて例を示す．例えば「ログインは図４の画面を3.2. 提案手法の前提用いて行う．
」と記載されている場合，「ログイン画面では、名前とパスワードを入力し、ログインボタンを押す

今回の提案手法は，3. の最初で述べた小規模な仕様書ことでログインを行う。」と図を参照せずに，文章としに対する試行結果に基づくものであるので，いわゆる在て記載する．

庫管理等のビジネスアプリケーションに関する要件定義書が対象となる．また，要件定義書では，機能を説明す

3.3. テンプレートを用いた書き換える部分の文章において以下の条件を満たすものとする．

• 主語，述語，目的語が整った誤解の生まれない文であること．

計測には大きく分けて，DF と TF の計測が必要であり，それぞれの計測において必要な要素が存在する．そ

152

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ログイン画面(処理名)処理は、（入力項目）を入力することによって、（項目|DF名）を(用語)します。
（DF名）を参照し、(項目)を得ます。
(メッセージ名）というメッセージが表示されることがあります。

名前
password
ログイン

用語・・・登録，更新，削除，表示，出力，印刷など

ログイン画面では、名前とパスワードを入力することでログインを行う。

図 5. TF のテンプレートを出力したか」「何を参照したか」のみをテンプレート

図 4. 図から文章への変換に合わせて記せばよいため，FP 計測の知識がない者であっても変換は容易である．

れらの要素を持った仕様であれば，理論的には自動計測は可能であるが，前述の「主語，述語，目的語が整った
誤解の生まれない文」であっても自由度が存在するため，
今回はテンプレートを用いて書き換えを行う．

3.3.2

DF のテンプレート記述

DF の計測に必要な要素は以下の通りである．
3.3.1• 種別…ILF，EIF

TF のテンプレート記述• DET…アプリケーション上で参照される項目の数

TF に必要な要素は以下の通りである．

• RET…データ群の属性内のサブグループの数• 種別…EI，EQ，EO

RET とは，１つの DF の中に混在している異なる意• DET…入出力項目の数 (重複は除く)+1(きっかけの有無)+1(メッセージの有無)

味合いを持つデータのまとまりの数を指す．しかし，仕• FTR…関わる DF の数

サブグループであるかを判別することは，仕様の中で直様から得られる要素を用いて対象の DF がどの DF の接的な言及が行われていない限り不可能である．そのた

今回の計測では全ての TF にきっかけがあると仮定しめ，本研究では RET を常に 1 として数えることとした．

ているので，テンプレートに沿って書き換えられた文章

よってテンプレートに沿って書き換えられた文章のみでから FP 計測を行うためには，「種別」「入出力項目」「メッ

FP 計測を行うためには，その文章から「種別」「アプリ

セージの有無」「関わる DF の数」といった情報が得られケーション上で参照される項目の数」といった情報が得なければならない．計測に必要な要素を含み，かつ判別られなければならない．計測に必要な要素を含み，かつの容易な文章を作るためのテンプレートが図 5 である．

判別の容易な文章を作るためのテンプレートが図 8 であ図 5 のテンプレートに変換する際，処理に入力項目やる．実際に図 8 のテンプレートを用いて変換を行うと図参照，メッセージが存在しない場合はそれぞれ「(入力9 上部にある文章は，図 9 下部のように変換される．

項目) を入力することによって、」や「(DF 名) を参照して、(項目) を得ます。」，「(メッセージ名) というメッセー

3.4. 自然言語解析による要素の抽出

ジが表示されることがあります。」の部分を記載しない．
実際に要件定義書内の文章をテンプレートへと書き換

先述したテンプレートに沿って書き換えた仕様から

える．交通費登録内容の照会という機能 [17] を用いて説FP 計測に必要な要素を以降で述べる方法で抽出する．

明する．当該機能は，図 6 のような文章で記述されている．これをテンプレートに変換した場合，図 7 のように

3.4.1

なる．上記の通り，「UI に」などのような FP 計測に関係

DF からの要素抽出ない部分が取り除かれ，計測に必要な要素のみが残った

図 8 のテンプレートにおける (項目) は当該 DF が持ことが分かる．また，基本的に「何を入力したか」「何つ全項目である．しかし DF の FP 計測に必要なものは

153

SEA

ソフトウェア・シンポジウム2017 in 宮崎「所有する項目の数」ではなく「アプリケーション上で精算データの照会は、UIに社員番号と登録日付を入力することで、画面中央に利用日と目的と金額と交通機関とFromとToを表示する。
エラーが起きた際にエラーメッセージが表示される。
社員番号と登録日付を基に、交通費精算ファイルを参照することで利用日と目的と利用金額と交通機関とFromとToを得る。

参照される項目の数」であるため，このテンプレートからでは DET が数えられない．また，種別についての言及もない．そこで，前述した TF の情報を用いて以下のように判別を行う．

• DET の判別

図 6. 変換前の文章

当該 DF のテンプレートにて示された項目のうち，TF の中で一度以上使用された項目のみを DET として数え上げる．

精算データの照会処理は、社員番号と登録日付を入力することによって、利用日と目的と利用金額と交通機関とFromとToを表示します。
交通費精算ファイルを参照し、利用日と目的と利用
金額と交通機関とFromとToを得ます。
また、入力データに誤りがあった際エラーというメッセージの表示を行います。

• ILF と EIF の判別
当該 DF が一度でも EI 内にて登録や更新が行われていた場合は ILF，そうでない場合は EIF として判別する．例として「A を更新する。」と記述さ

図 7. 変換後の文章れていれば A は ILF と判別される．

3.4.2

そのようなデータがない，つまり DF の項目をそのTF からの要素抽出

まま出力していれば EQ と判別する．

図 5 のテンプレートにおける (入力項目)，(出力項目)
は DET の一部である入出力項目に相当し，(データ群)
は処理に関わる DF を示している．また，「〜というメッ

3.4.3

TF でない処理についてセージが表示されることがあります」という文によってメッセージの有無が判別できる．従って，このテンプレー

今回の計測上，仕様の書き換えの際に TF ではない処

トで，「入出力項目」「メッセージの有無」「関わる DF の理を TF のテンプレートを使って変換してしまう場合が数」は文章から直接読み取れる．

あり得る．今回の手法では，EI, EQ, EO の判断のため

一方で「種別」については明記が行われていない．そ辞書に登録している「更新」や「表示」「出力」等の用

こで，このテンプレートから該当 TF の種別が EI，EQ，語が存在しない場合，EI，EQ，EO ではないとして TF

EO の 3 種の内どれに該当するのかを以下の 2 段階で判別する．

としては扱われないため，計測には問題ない．

• EI と EQ，EO の判別方法
EI と EQ，EO の判別を使われている用語で行

3.4.4

う．具体的には，「登録」，「更新」といった外部入力

重複処理について

FP 計測において，処理内容が同一の処理は重複処理と呼ばれる．この重複処理は複数存在しても 1 つしか計

に関する用語であれば EI，「表示」，「出力」といった用語が用いられているなら EQ，EO といった判

測しないルールとなっている．そのため，図 10 のよう別を行う．判別のための用語は，辞書に別途登録しに同一の項目を持つ処理が複数存在した場合，それらをておく．

重複処理と判断し，1 つしか数えないようにする．

• EQ と EO の判別方法
EQ と EO の判別には，動詞の目的語となる項

3.5. FP の計測

目を用いて判別を行う．具体的には，FP 計測規則

[12] に則って，DF に含まれていないデータ（項目）

ここまでのステップにて FP 計測に必要な要素が全てが出力されていれば，トランザクションにおいて何揃うため，2．1．で記述したように要素から複雑度およらかの処理を行っていると判断して EO と判別し，び FP を算出する．

154

SEA

ソフトウェア・シンポジウム2017 in 宮崎

処理名(DF名)は、（項目）を持つデータ群です。

図 8. DF のテンプレート

データベース名
データ項目
図書情報
出版社，題名，著者名
利用者情報
氏名，利用者番号

種別 入力
項目

図書検索A

EQ

図書検索B

EQ

出力
項目

参照した メッセージ
DFの有無

図書 題名，
番号 著者名図書 題名，
番号 著者名

図書
情報
図書
情報

有り
有り

処理名以外の全項目の内容が一致
「図書検索A」と「図書検索B」は重複処理と判断

図 10. 重複処理となる例

要件定義書

図書情報は、出版社と題名と著者名を持つデータ群です。
利用者情報は、氏名と利用者番号を持つデータ群です。

機能仕様

品質仕様

…

手動による書き換え

計測用の仕様cabochaによる自然言語解析
試作ツール

図 9. DF のテンプレート記述への変換

計測に必要な要素
自動計測FP

3.6. 計測ツールの実装

図 11. 計測フローと計測ツールの役割

これまでに述べた方針に基づく FP 計測ツールを Java
言語を用いて試作した．計測ツールの役割は「cabochaを用いた自然言語解析による計測に必要な要素の抽出」
および「DF や TF の種類などの cabocha では抽出できない要素の判別」，そして「要素を用いた FP の算出」
である．図 11 に本研究における FP 計測の流れと計測
ツールの関係を示す．

4.1. 対象システムの概要
今回自動計測の対象とした 4 つのシステムの概要を記す．

1. 旅費精算システム
交通費の管理を行うシステムである．社員が出張

計測の流れは以下の通りである．

にて支払った交通費を登録しておくことで上司がそ

1. 要件定義書のうち，機能に関わる部分の文章を意味
内容が明確となるよう手動で変換する．

れを確認，承認できる．また，承認されたものについては銀行への支払い命令が行われる [17]．

2. 書き換えた文章をテンプレートを用いて計測用の仕2. 図書システム

様に手動で変換する．

図書の管理を行うシステムである．図書の登録や増冊，検索や削除などが行える．ある企業の社内勉

3. 計測用の仕様に cabocha による自然言語解析を行い，計測に必要な要素を抽出する．

強用資料に記載されているものである．

3. 酒屋問題
酒の在庫管理を行うシステムである．積荷として4. 3．で抽出した要素を用いて，FP 計測を行い結果を運ばれてきた酒の銘柄や本数の登録や，出庫指示な

出力する．

どが行える [18]．

4. ケーススタディ

4. 健康情報サイト
病院や健康情報について扱うサイトである．健康

本章では，対象となる 4 つの仕様書に対して自動計測

診断が行われている病院の検索や健診情報の登録がを行った結果及び考察をまとめる．

行える [19]．

155

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 4. 計測結果
図書システム

旅費精算
手動

DF

ILF
EIF

7

17

10

EI
TF

EQ
EO
FP

自動

7

17

10

12
52

20
20
69

手動

14

14

0

12
52

20
20

自動

0

13
40

69

7
10

手動

14

14

酒屋問題

0

13
40

44

7
10
44

4.2. 提案手法の計測結果と手動計測結果の比較

自動

14

14

3
12
38

手動

14

14

0

9
24

健康情報

21

21

0

12
27

3
12
41

自動

21

21

0

30
75

41
4
96

30
75

41
4
96

高く，結果として今回のように付随処理の分多く計測される可能性も高い．この問題に関しては，自動先述した 4 つのシステムの要件定義書に対して，FP

計測後の結果をファイル出力し，利用者の手によっ

計測の熟練者 (一部は FP 計測における国際資格であるて修正・変更を行う方法による解決が望ましい．

CFPS[20] の有資格者）による手動計測結果および計測ツールによる自動計測結果を表 4 に示す．表 4 より，手動で計測した結果と比べ，酒屋問題において TF と FP

2. DF が明記されていない場合の対応
今回は DF や TF について記述が正確に行われているという条件で FP 計測手順を提案したため，有が 3 ずつ多く計測されていることが分かる．

資格者が計測した際の値と近いものを得ることができた．しかし，実際の要件定義書の中には DF につ4.3. 考察いて明示的に記載されていないケースが存在する．

1. 誤差についての分析
旅費精算システム・図書システム・健康情報サイ

その場合，今回の研究にて提案した手法をそのままトの要件定義書に対しては，手計算で得られた FP

扱われているデータ項目の集合を DF の候補とすると同様の値を得ることができたが，酒屋問題に関しということを考えており，今後その詳細を検討するては誤差が生じた．この原因について考察する．

予定である．

適用できないため，一つのアイデアとして，TF で酒屋問題における誤差の原因を調べたところ，本5. あとがき

来無視すべき付随処理を計測していることが原因であった．付随処理とは TF として扱われる処理に本研究では，自然言語で書かれた仕様書からの FP 自おいて，本来の処理に付随して行われる処理の事を

動計測の実現を試みた．その方法として，テンプレート

言う．酒屋問題においては酒の在庫情報を更新するを用いて仕様を書き換えた上で，自然言語解析を用いて「在庫情報更新処理」が相当し，この処理は本来出FP 計測に必要な要素を抽出し FP 計測を行う手法を提案した．4 つの仕様書を対象とし，提案手法を用いて自動計測を行った．その結果，3 つの仕様書においては手庫の指示を担う出庫指示票を出力する処理である「出庫指示票出力処理」に付随して行われる処理であったが，今回の提案手法での計測では別々の処理計算で見積りが行った場合と同様の FP を算出することとして計測された．FP 計測においてこの付随処理は無視される，つまり計測されないものであるが，その処理が付随処理であるかどうかは FP 計測の知ができた．残り 1 つの仕様書では手計算で得られた FPと異なる値が得られたことから，その原因に対する考察を行った．

識がある者でしか判断できず，またツール側から判本研究の今後の課題としては，下記のような事が考え断することもできない．そのため，FP 計測の知識られる．

があまりない者がテンプレートへの変換を行った場
合，この付随処理も含めて記述してしまう可能性が

1. 適用事例の追加

156

SEA

ソフトウェア・シンポジウム2017 in 宮崎

今回取り扱った 2 つの要件定義書は最大でも FP

IEEE Transactions on Software Engineering, Vol.
16, No. 1, pp. 64-71, IEEE, 1990.

が 100 程度のものであり，また，FP が小さいために要件定義書内で扱われる処理も種類が少ない．そ[6] B．Kitchenham. The problem with function
points. IEEE software, Vol. 14, No. 2, p. 29, IEEEのため，FP が大きく，また，多種多様な要件定義書への適用を行いそこで生じた問題点を解決するこComputer Society, 1997.

とで，本研究の実用性を高める．

[7] T. Uemura, S. Kusumoto, and K. Inoue. Function-

2. 手法の改善

point analysis using design specifications based on
the united modelling language.Journal of software
maintenance and evolution:Research and practice,

テンプレートを用いた書き換えコストの調査やテンプレート記述以外のより計測に適した記述方法の提案，および穴埋め式記述を用いたツールの開発にVol. 13, No. 4, pp. 223-243, IEEE Computer Society, Wiley Online Library, 2001.

よるより記述量の少ない計測手法の提案などによって本研究における手法そのものの改善を行い，本研究およびツールの有益性を高める．

[8] G. Cantone, D. Pace, and G. Calavaro. Applying function point to united modeling language:

謝辞

Conversion model and pilot study.Software Metrics, 2004．Proceedings．10th International Symposium on, pp. 280-291. IEEE, 2004.

本研究を進めるにあたって，貴重なご助言を頂きました株式会社 NTT データ 鵜澤仁氏，一般財団法人経済[9] T. Edagawa, T. Akaike, Y. Higo, S. Kusumoto,
S. Hanabusa, and T. Shibamoto. Function point

調査会 大岩佐和子氏，押野智樹氏に深く感謝申し上げます．
本研究は一部，日本学術振興会科学研究費補助金基盤研究（S）（課題番号：25220003）の支援を受けている．

参考文献

measurement from web application source code
based on screen transitions and database accesses.
Journal of Systems and Software, Vol. 84, No. 6,
pp. 976-984, Elsevier, 2011.
[10] P. Fraternali, M. Tisi, and A. Bongio. Automating
function point analysis with model driven development. In Proceedings of the 2006 conference of[1] B．Boehm, C．Abts, S．Chulani. Software de- velopment cost estimation approaches - A survey. Annals of software engineering, Vol. 10, No. 1-4, pp.

the Center for Advanced Studies on Collaborative
research, p. 18. IBM Corp．, 2006.

177-205, Springer, 2000.
[2] R．L．Glass. Facts and fallacies of software engi-[11] IEEE Computer Society． Software Engineering
StandardsCommittee, IEEE-SA Standards Board.

neering, Addison-Wesley Professional, 2002.

IEEE recommended practice for software requirements specifications, IEEE, 1998.

[3] A．J．Albrecht. Function point analysis. Encyclopedia of Software Engineering, Vol. 1, pp. 518524,Addison-Wesley Professional, 1994.

[12] IFPUG: Function Point Counting Practices Manual, Release 4．3. International Function Point[4] 総務省行政管理局. 政府情報システムの整備及び管Users Group, 2010.

理に関する標準ガイドライン実務手引書. 政府情報システムの整備及び管理に関する標準ガイドライン[13] C．R．Symons. Software sizing and estimating:Mk

実務手引書, p. 122, 内閣官房情報通信技術 (IT) 総

II FPA (function point analysis), John Wiley &Sons, Inc．, 1991.

合戦略室,2015.

[5] G．C．Low, D．R．Jeﬀery. Function points in theestimation and evaluation of the software process.

[14] 山口正明 (著) 調重俊 (監修) . ファンクションポイ
ント cosmic‐ ﬀp 法実践ガイド―組込み系・リアル

157

SEA

ソフトウェア・シンポジウム2017 in 宮崎

タイム系に最適なソフトウェア規模・工数の見積り
方法, 日科技連出版社, 2007.

[15] 柏本隆志, 楠本真二, 井上克郎, 鈴木文音, 湯浦克
彦, 津田道夫. イベントトレース図に基づく要求仕様書からのファンクションポイント計測手法. Vol.

41,No. 6, pp. 1895-1904, 2000.
[16] Cabocha/南瓜 https://taku910.github.io/cabocha/.
[17] 日本ファンクションポイントユーザ協会. ファンク
ションポイント計測コース演習編課題テキスト,2014.

[18] 山崎利治. 共通問題によるプログラム設計技法解説.
情報処理, Vol. 25, No. 9, p. 934, 1984.

[19] 経済調査会調査研究部第二調査研究室. Web サイト
制作費の見積りの現状と課題, 2015.
[20] CFPS 概 要. http://www.jfpug.gr.jp/app-def/S102/wp/?page id=1374.

158

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ソフトウェア開発発注者育成のための形式手法を取り入れたプログラミング教育
伊藤 栄一郎
山梨学院大学
e-itoh@ygu.ac.jp

小田 朋宏
株式会社 SRA
tomohiro@sra.co.jp

要旨

荒木 啓二郎
九州大学
araki@ait.kyushu-u.ac.jp

フトウェア開発者の視点に立ったものである．PBL においても学生は主に開発者として模擬プロジェクトに参品質の高い仕様記述は開発における手戻りを減らし最加する．しかしながら，ソフトウェア開発における仕様

終成果物であるソフトウェアシステムの品質を高めるた

記述工程は開発者のみが行う工程ではない．システムがめに重要な工程である．仕様記述は開発を計画するドメ

解決すべき問題に対してシステムの仕様が妥当であるこ

イン専門家とその実現を担当する開発者の双方が記述やとを確認するためには，ドメイン専門家が仕様記述を理

レビューを通して関与すべき工程である．したがって，解し適切なフィードバックを行うことが必要である [2]．

品質の高い仕様記述を得るためにはドメイン専門家と開したがって，ソフトウェアの仕様記述に関する基本的な発者の双方において仕様記述に関する知識と技能を高め

知識および技術は，開発者のみならずドメイン専門家もる必要がある．我々は，品質の高い仕様記述を得るため習得することが望ましい．

の手法として形式仕様記述に着目し，将来企業において仕様記述の品質を高める技術として形式仕様がある[3]．形式仕様とは，構文および意味論が厳密に定義されている記法によって，解釈に曖昧性のない仕様を記述する技術である．モデル規範型の仕様記述言語では手続きや関数の事前条件および事後条件を表明することで，手続きや関数が満たすべき仕様を高い抽象度で記述することができる．経済性や成果物の品質の観点から多くの成功事例があるが [4, 5, 6]，ソフトウェア開発全体においてはまだ適用は一部に止まっている．Hall は [7] において，
形式手法に関する誤解の 6 番目に「形式手法はユーザに受け入れられない」という誤解を挙げて，ソフトウェ
アシステムの受託開発におけるユーザ企業側に受け入れられないという誤解から形式手法の普及が遅れていると指摘している．この誤解は現在においても改善されていない．
我々は，システム発注者のための形式仕様の基本的な技術として，事前条件および事後条件の表明に着目した．
表明は，プログラミングの入門段階から導入することができ，適切な課題設定によって必ずしも高度な数学知識に依らなくても記述することが可能である．本研究では，
小規模なプログラミングの演習で事前条件および事後条
件を扱うことによって，形式仕様のエッセンスを学ぶこ

ソフトウェアシステムの発注者側として開発に携わることが予想される大学生へのプログラミング導入教育において，形式仕様のエッセンスであるプログラムの正当性，手続きの事前条件と事後条件について講義を行い，ビジュアルプログラミング環境上での演習およびペーパー
テストを実施した．本論文では，講義の内容と結果，および講義向けに開発したビジュアルプログラミング環境への拡張機能を説明し，議論する．

1. はじめにソフトウェア開発において仕様記述をはじめとする上流工程は開発の経済性や成果物の品質を高める上で重要な工程である．専門教育においてもソフトウェア工学などを通して多くの大学においてソフトウェア開発のライ
フサイクルや分析，仕様記述，設計に関する技術教育がカリキュラムに組み込まれている．
近年では，PBL (Problem Based Learning) を通して，実社会で求められているソフトウェアの開発を経験する
ことで技術だけでなくシステム開発者としての基本的な姿勢を学ぶ訓練が行われている [1]．それらの多くはソ

159

SEA

ソフトウェア・シンポジウム2017 in 宮崎とができるのではないかという仮説を立てた．プログラ
ミング導入教育を目的とした講義において，形式仕様の基本的な要素である事前条件および事後条件の表明についての知識をレクチャーし，演習として簡単な問題をプ
ログラミング入門向けのビジュアルプログラミング環境
上で表明を行う課題を与え，ペーパーテストを実施した．
第 2 節では演習のために開発した表明付きビジュアル
プログラミング環境 Assertch について紹介する．第 3 節ではプログラミング導入教育で実施したレクチャーや演習，試験を説明し，その結果を示す．第 4 節では実施した結果について考察を行い，最後に第 5 節ではまとめと今後の課題を示す．

2. 表明付きビジュアルプログラミング環境 Assertch

図 1. Phratch 環境の画面例

プ ロ グ ラ ミ ン グ 教 育 を 目 的 と し て Scratch[8] やViscuit[9] を始めとするビジュアルプログラミング環境が開発され，小学生から大学生を対象に適用されている．
ビジュアルプログラミング環境は，構文を覚えるなどの学習者の負担を最小限に止めながら，プログラムを構築することのエッセンスを実践を通して学ぶことを可能にしている．
我々は，プログラミング導入教育の中でプログラムの正当性や表明の概念を導入するために，Scratch に類似したブロック型のビジュアルプログラミング環境である
Phratch に表明ブロック等を追加する拡張機能として，Assertch を開発した [10]．Phratch は オープンソース
として公開されており1 ，2017 年 3 月現在も活発に開発が続けられている．
図 1 に Phratch 上で簡単なプログラムを作成した画面例を示す．画面は大きく左側，中央，右側に 3 分割されている．画面左にはプログラムを構成するための「ブロック」と呼ばれる部品がカタログとして分類されて提供されている．ユーザがカタログ上部で分類を選択す
ると，カタログ下部にその分類に含まれるブロックが縦方向に並べられて提供されている．ユーザはブロックを
カタログ上から画面中央のスクリプトエリアにドラッグ＆ドロップによって配置する．図 1 の例では，スクリプ
トエリアには，いわゆる FizzBuzz 問題のプログラム（1から 100 までの数を数え上げ，もし 15 の倍数であればFizzBuzz あるいは 5 の倍数であれば Buzz，3 の倍数で1 http://www.phratch.com/

160

あれば Fizz，いずれでもなければその数を表示する）がブロックを使って組み立てられている．画面右側の上部
では，各変数の値や，タートルグラフィックスやユーザとの対話を行うエージェントとしてロボットが表示されている．

Assertch は，Phratch に表明を始めとする仕様記述に有用なブロックを追加する拡張モジュールである．現在
Phratch の標準アドオンとして提供されており，AddOn
メニューから Assertch を選択することでネットワーク
経由で自動的にインストールすることができる．図 2 に，表明ブロックを収めた設計カタログを示す．
「を確認するブロック」は，一般のプログラミング言
語における assert 文に相当し，引数として与えられたブロックを評価実行し，true であれば実行を継続し，false
であれば表明エラーとして停止するブロックである．
「事
前条件ブロック」は，内側にブロックを抱え込む構造を持つブロックで，内側のブロックに対する事前条件を表明するブロックである．引数として与えられたブロックを評価実行し，true であれば内部に抱えたブロックを実
行し，false であれば表明エラーとして停止する．
「事後
条件ブロック」は，内側のブロックに対する事後条件を表明するブロックである．内部に抱えたブロックを実行した後で，引数として与えられたブロックを評価実行し，true であればプログラムの実行を継続し，false であれば表明エラーとして停止する．事前条件と事後条件の両方を表明する「事前条件事後条件ブロック」も提供されている．いずれの表明ブロックも，表明エラーが発生した

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ブロックの色を黒色から赤色に変化させることで，どの表明が守られなかったかをユーザに示す．エラーとなった表明ブロックの色は，「表明エラーをリセットするブロック」によってリセットすることができる．
これらの表明ブロックを利用することで，プログラミ
ング学習者であるユーザは仕様記述とプログラムの関係について以下のことを学ぶことができる．

• 試行錯誤の結果たまたま動くプログラムができるのではなく，プログラムの目的と前提条件を明確にした上で，ブロックを合理的に選択しプログラ
ムを組み立てること• プログラムに誤りがあった時に，各部分で期待した条件に照らし合わせて，どのブロックに問題があるかを特定すること• プログラムを作るだけでなく，意図した通りの動作が行われるかをテストすること• プログラムを拡張する時に，元のプログラムの設計意図に適合した改変を行うこと
これらの技術を学ぶことによって，仕様記述がプログラ
ムの開発においてどのような役割を担っているかを体得するための環境を提供することが，Assertch の開発目的である．

3. プログラミング導入教育への適用
現在，多くの大学の様々な課程においてプログラミン
グ導入教育が行われている．山梨学院大学経営情報学部
は，経営学と情報科学をまたがる専門的な知識と技能の習得によって，新しい時代を担う情報技術者・情報管理者を育成することを目標の 1 つにしている．ソフトウェ

図 2. Assertch で拡張された表明ブロック

アシステムのユーザ企業側においてシステム開発に携わる人材を育成することが期待されていることから，プロ
グラミング教育においては開発者としての視点だけでなく発注者として求められる知識や技能を学習することが，プログラミング導入教育を行う講義において求められる．
平成 28 年度後期に「情報処理論」として以下の内容の講義を実施した．

• アルゴリズムとプログラミング言語• グラフアルゴリズム

161

SEA

ソフトウェア・シンポジウム2017 in 宮崎• プログラムの正当性

題した．

うち，アルゴリズムとプログラミング言語は Phratch，
プログラムの正当性は Assertch を利用して講義および演習を行った．

3.1. 結果
授業では全受講者 79 人のうち最終試験を受験した 72

プログラムの正当性の演習では，二次方程式の解の 1

人を評価の対象とした．そのうち 61 人が演習後のレポーつを求めるプログラムを表明ブロックを使って作成し，レトを提出し，9 人は課題において表明ブロックを使いこポートとして提出する課題を出した．受講者に対して，二なしていた．27 人は表明は適切でなかったが求められた√

b −4ac次方程式 ax2 +bx+c = 0 の解法として，x = −b± 2a2

プログラムを完成させた．

の公式を示した上で，この式が多くの前提条件，すなわ

演習の結果とペーパーテストの結果の関係を表 1 に，ち事前条件を持っていることを説明し，その事前条件や演習の結果と表明に関する設問の正解/不正解による分事後条件を洗い出しながらプログラムを構成するように

布を表 2 に示す．演習において適切な表明を付けてプロ指示した．

グラムを完成させた受講者は，表明がプログラムの委託

形式仕様記述工程では，ドメイン知識や実現する機能および受託それぞれにおいてどのような役割を果たすかの特性から様々な事前条件や事後条件を発見し，それらという設問に対する正答率は 0.67 であり，その他の設を適切な機能単位に記述する作業が行われる．これを簡問，すなわちプログラミング言語およびアルゴリズムに単なプログラムの作成で模擬的に体験させるために，二関する設問に対する正答率は 0.77 であった．表明に不次方程式の解法を課題として選んだ．二次方程式の解の足はあったがプログラムを完成させた受講者はそれぞれ

1 つを求めるプログラムを構成するためには，これらの事前条件および事後条件を発見し，適切に表現し，それらの事前条件および事後条件を満たすようにブロック群
を合理的に構成しなければならない．
プログラム全体の事後条件は ax2 + bx + c = 0 だが，
a = 0 の場合には分母が 0 となるので，上記公式は単純に適用できない．そこで，a = 0 を事前条件とした副プ
ログラムを構成する必要があるが，その場合には a = 0
により事後条件は bx + c = 0 となり，一次方程式の解法
を使うことができる．さらに，一次方程式の解法において，a = b = 0 の場合には事後条件が c = 0 となるため，
c = 0 ならば任意の数が解となり，c ̸= 0 ならば解なしとなる．また，a ̸= 0 の場合には，判別式によって実数解があるかどうかを判定しなければならない．
実習において，受講者は以上のような事前条件および事後条件の抽出を行い，表明ブロックによってそれらを表現し，表明ブロックに内包されるブロック群を合理的に構成することで課題を遂行する必要がある．図 3 にAssertch での正答例を示す．
学期の最後に定期試験としてペーパーテストを実施した．ペーパーテストでは，アルゴリズム，プログラミン
グおよび正当性それぞれについての基本的な用語の理解，プログラムやアルゴリズムの実行に関する穴埋め，そして，事前条件や事後条件がプログラム開発の委託や受託にどう関係するのかを自由形式で記述する問題を出正答率が 0.63 および 0.77 と，適切な表明を付けた場合

162と大きな差はなかった．プログラムが未完成だった受講者は，表明と委託/受託に関する設問では正答率が 0.53と，プログラムを完成させた受講生グループと比較して低い正答率にとどまった．その他の設問においては正答率に大きな差はなかった．レポート未提出の場合には，いずれの設問についても低い正答率になった．結果として，表明の意義に関する理解は，演習において表明そのものを適切に使いこなしていたかに関わらず，プログラ
ムを完成させたかどうかで差がついた．

4. 議論
表明ブロックを用いた演習結果とペーパーテストでの表明に関する設問での正答率の関係について，プログラムが完成したか否かが差をつける因子であることがわかった．考えられる説明としては，表明ブロックの利用を意識して課題に取り組んだことによって，たとえレポー
トとして提出したプログラムでの表明が不完全であっても，表明という概念について適切な理解を得ることに繋がったと考えられる．
受講生の一部が既に一定のプログラミング技術に習熟していたことの影響も考えられるが，表 2 から，アル
ゴリズムやプログラミング言語に関する設問では得点が低いが表明の設問には正答できている受講者や，逆に表SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 3. Assertch での二次方程式解法の正答例

演習結果

表 1. 演習結果とペーパーテストの正答率「表明と委託/受託」 その他の設問の表明付きでプログラム完成
表明なしでプログラム完成
プログラム未完成
レポート未提出

163

正答率

正答率

0.67
0.63
0.41
0.33

0.77
0.77
0.71
0.57

SEA

ソフトウェア・シンポジウム2017 in 宮崎

グラミング環境に表明機能を追加することで，正しいプ
表 2. ペーパーテストにおける表明以外の設問の得ログラムについて学ぶ機会を提供することを試みた．演

点と表明設問の正答の人数分布

習の中で，プログラムが期待した動作をしなかった時に，表明以外の得点

-31
32-35
36-39
40-

表明設問

表明設問

正解

不正解

9
9
11
6

4
6
15
12

プログラムの誤りなのか仕様の誤りなのかを考え修正する受講生の姿を観察した．
「情報処理論」にプログラムの正当性および表明に関する講義や演習を取り入れて 2 期目が経過した．今後もプログラミング環境の改善を行いつつ，教材や演習内容の改善に務める．

6. 謝辞

明の設問には正答できなかったがアルゴリズムやプログ
ラミング言語の設問では得点が高い受講生が少なくない本研究を遂行するにあたって Jannik Laval 氏，阿部ことが示されており，プログラミングの知識や技能は表

和広氏，中小路久美代氏，山本恭裕氏より多くの助言

明や仕様記述に関する理解とは必ずしも直結していないを受けた．ここに謝意を記す．有益なご指摘を頂いた査と考えられる．すなわち，将来ソフトウェアシステムの読者の方々に感謝する．本研究の一部は, JSPS 科研費

ユーザ企業において発注者としての役割を担う技術者を(26330099) の助成を受けたものである.

育成する上で，アルゴリズムやプログラミング言語の知識や技能だけで適性を判断するのではなく，表明に関す

参考文献

る知識や技能によって適切な仕様記述を行うための教育が必要である可能性を示唆している．

[1] 井上明, 金田重郎. “実システム開発を通じた社会連
携型 PBL の提案と評価.” 情報処理学会論文誌, Vol.
49, No. 2, pp. 930-943, 2008.

演習に用いたプログラミング環境については，多くの改良の余地があることがわかった．特に，演習において表明に記述する式が複雑になり，受講生の時間や労力の多[2] Oda, T., Yamomoto. Y., Nakakoji, K., Araki, K.,
and Larsen, P. G. “VDM Animation for a Wider
Range of Stakeholders”. In Proceedings of the 13th
Overture Workshop, pp 18-32, 2015.

くが式をブロックで組み立てることに費やされてしまっていた．ブロック式のビジュアルプログラミング環境であることの欠点であり，条件式をテキスト形式で入力可
能なブロックを導入するなどして解決する必要がある．

[3] Fitzgerald. J. and Larsen, P.G. “Modelling Systems– Practical Tools and Techniques in Software Development, Cambridge University Press, 1998.

5. おわりに
ソフトウェアシステムを開発するための技術者の不足が叫ばれて久しい．情報システム開発の要求およびその複雑さは，これからも増えていくことが予想されている．
そこで求められる生産性と品質を獲得するためには，品
質の高い仕様を記述することができる技術者が必要である．従来のソフトウェア開発を受託する技術者の育成[4] Fitzgerald. J, Larsen, P. G., and Sahara, S. “VDMTools: Advances in Support for Formal Modeling in
VDM”, ACM Sigplan Notices, Vol. 43, No. 2, pp.
3-11, 2008.
[5] Kurita, T., and Nakatsugawa, Y. “The Applicationof VDM++ to the Development of Firmware for a
Smart Card IC Chip, Intl. Journal of Software andInformatics, Vol. 3, No. 2-3, pp. 343-355, 2009.

により開発者の数を増やすだけでなく，仕様を策定するユーザ企業側においても，品質の高い仕様を記述する知識と技能を持った技術者を確保することが求められる．
本研究では，将来ユーザ企業またはソフトウェア開発[6] IPA/SEC. “厳密な仕様記述における形式手法成功事
例調査報告書”, 独立行政法人情報処理推進機構 技

企業において技術者として開発に携わることが期待される受講者に，プログラミング教育向けのビジュアルプロ

164

SEA

ソフトウェア・シンポジウム2017 in 宮崎

術本部 ソフトウェア・エンジニアリング・センター,

2013.
[7] Hall, A. “Seven myths of formal methods.” IEEEsoftware, Vol. 7, No. 5, pp. 11-19, 1990.
[8] Maloney, J., et al. “The scratch programming language and environment.” ACM Transactions on
Computing Education (TOCE), Vol. 10, No. 4: 16,
2010.
[9] Harada, Y., and Potter, R. “Fuzzy Rewriting.” End
User Development, Springer Netherlands, pp. 251267, 2006.
[10] Oda, T., Araki, K., and Larsen, P. G. “ViennaTalk and assertch: building lightweight formal
methods environments on pharo 4.” in Proceedingsof the 11th edition of the International Workshop
on Smalltalk Technologies (IWST16), pp. 4:1-4:7,
2016.

165

SEA

ソフトウェア・シンポジウム2017 in 宮崎「VDM++仕様記述と分析」の定石と手筋
佐原 伸
法政大学情報科学研究科
ss@shinsahara.jp
要旨
形式仕様記述言語VDM++で仕様を記述し，それを分析できる産業界の技術者を育てることは簡単ではない．
しかし，長年にわたって囲碁や将棋を学習し，多くの技術者や学生に，VDM++による仕様記述方法を教えた経験から，「仕様記述と分析」を定石や手筋を使って教育することが，囲碁や将棋の教育と同様に有効だと考えた．特に，仕様記述に重要な不変条件(invariant) ・事後条件(post-condition)・事前条件(pre-condition)の記述を容易にできるよう，定石と手筋を集めて検索可能にすれば比較的容易に「仕様記述と分析」行うことができる．
このような「定石集」を試作し，評価した結果，3節で述べるように，かなり役立ちそうである事が分かった．また，これらの定石をコンピュータ化すれば，検索や「仕様の一部」の自動生成に活用できる可能性もある．

0. はじめに
産業界の技術者は要求仕様や設計仕様のVDM++による仕様記述に困難を感じる人が多い．特に，不変条件，
事後条件，事前条件の記述ができない．手続き的記述には慣れているが，状態を宣言的記述で表現することに慣れていないため，記述することが難しいようである．
例えば，顧客のデータベースをインスタンス変数「i客DB」で表し，そこに新しい客「a新しい客」を追加する操作（operation）では，事後条件を
post i客DB = i客DB~ union {a新しい客}と記述すればよいのであるが，これがなかなか書けない．ここで，’~’は，インスタンス変数の旧値（操作が実行される前の値）であり，集合の合併演算子unionを使って，引数で与えられた「a新しい客」を要素に持つ集合「{a新しい客}」と合併した集合が，「i客DB」（操作が終わった後のインスタンス変数「i客DB」）と等しいと書けばよい．
このような「手筋」（仕様中のいくつかの場所で役立つ方法）を「集合に要素を追加する手筋」として整理し，仕様記述
例と説明を与えておけば，仕様記述の上達に役立つ．囲碁や将棋では，このような手筋や定石が整理され蓄積されていて，囲碁の場合，アマチュア初段程度の実力でも2万個ほどの定石と手筋を使いこなさなければならないとされている．逆に言えば，定石や手筋を使いこなせれば，アマチュア初段程度の実力を発揮できるということであり，VDM++仕様記述の定石と手筋を整理して蓄積すれば，VDM++アマチュア初段レベルの技術者を養成できることになる．
しかし，囲碁や将棋のように仕様記述と仕様検査のための定石と手筋を集めようとして，文献1, 2, 3, 4など，関連しそうな文献を調べたが，いずれも証明が中心1であり，産業界向けの例題としては適当なものがなかった．そこで，筆者の作成した実用的なモデルをセミナー用に縮小したモデル群と，文献5を中心に定石と手筋を収集して，これを整理し，評価を行った．

1

筆者たちは，証明を使わずに仕様をテストする手法を中心に産業界へのVDM普及を行っている．現存するVDMのツールも，すべて仕様をテスト実行する仕様アニメーション機能しか提供していない．

166

SEA

ソフトウェア・シンポジウム2017 in 宮崎

評価は， 「定石と手筋集」作成では参考にしなかった既存文献（文献5と6）上の例題を使って，どの程度定石と手筋が使われているかを調べた．その結果．すべての不変条件，事後条件，事前条件の記述に，この「定石と手筋集」の定石と手筋が使われていた事が分かった． 3節で．収集した定石・手筋がどの程度有効であるかの実験結果を示した．
収集した定石・手筋の構成は以下のとおりである:

1. 仕様記述
2.
3.
4.

分析
ツール
マニュアル

分析を追加したのは，記述した仕様を分析するための重要な技術である検証と妥当性検査について，開発現場の技
術者に 知識があまり無いからである．
ツールとマニュアルの章を追加したのは，これらの知識がないと実際の普及の上で大きな障害になることが分かったからである．ただし，本論文では紙幅の関係で4.マニュアルについては省略した．

1. アイデア
1.1 仕様記述についてのアイデア「1. 仕様記述」では，次の観点で定石・手筋を整理した．すなわち，VDM仕様の特定の場所でよく使う記述方法を定石と呼び，VDM仕様のいろいろな場所でよく使う記述方法を手筋と呼ぶ．
定石は，事前条件，事後条件，不変条件でよく使う仕様記述方法であるので，下記のように分類した．
1.1.1 定石
1.1.1 事前条件
1.1.2 事後条件
1.1.3 不変条件
1.1.1, 1.1.2, 1.1.3 は「規則」と「定石」を記述している．ここで，「規則」とはVDM++の文法規則のことである．例えば，関数の場合の事前条件式は，式中で局所名以外の名前はパラメータ名しか使えない．これも一種の「定石」ではあるので「規則」として記述した．
「1.1.3 不変条件」定石は，下記のように分類した．
1.1.3.1 型の不変条件
1.1.3.2 インスタンス変数の不変条件
1.1.3.2.1 インスタンス変数の正当性
1.1.3.2.2 インスタンス変数同士の制約「1.1.3.1 型の不変条件」中には，例えば「1.1.3.1.1.1 データが意味的に正当か確認する」定石(IDはJIT_wf_1)があり，例えば以下のように，レコード型である予約明細型は予約明細を表しているの，属性f座席集合は空集合ではないという制約を記述している．この定石は，3節の「定石・手筋の評価」の結果，かなり使われていることが分かった．
types
public 予約明細 ::f顧客名 : 顧客名
f列車番号 : 列車番号
f乗車駅 : 駅番号
f降車駅 : 駅番号
f座席集合 : set of 座席番号
inv

167

SEA

ソフトウェア・シンポジウム2017 in 宮崎

w予約明細 == w予約明細.f座席集合 <> {};「1.1.3.2.2 インスタンス変数同士の制約」中には，例えば「1.1.3.2.2.2 写像の定義域・値域2同士の部分集合関係を記述する」定石(IDはJII_ibV_subset2)があり，例えば以下のように，インスタンス変数同士の制約条件を記述する．
types
public 管制官 = token;
public 空域 = token;
public 航空機 = token;
public 当直集合 = set of 管制官;
public 管制 = inmap 空域 to 管制官;
public s位置 : 位置 := {|->};
instance variables
public s当直集合 : 当直集合 := {};public s管制 : 管制 := {|->};
public s許容数 : 許容数 := {|->};
public s位置 : 位置 := {|->};
inv
rng s管制 subset s当直集合 anddom s管制 subset dom s許容数 andrng s位置 subset dom s管制
ここでは，3つのインスタンス変数同士の部分集合関係を記述しているが，例えば，この内の３番目は，インスタンス変数「s位置」の値域「rng s位置」は，インスタンス変数「s管制」の定義域「dom s管制」の部分集合であるという制約を記述している．
もちろん，インスタンス変数同士の制約は「対象問題分野」の知識がなければ記述できないのであるが，定石に基づいて「写像型を使ったインスタンス変数の定義域や値域に部分集合関係はないか?」という疑問を持ち，調べることによって制約を発見して記述するきっかけになる．この定石も，3節の「定石・手筋の評価」の結果，使われていることが分かった．
手筋は，下記のように分類した．
1.２手筋
1.２.1 成功手筋
1.２.2 失敗手筋
1.２には手筋として成功手筋と，失敗手筋を記述した．本稿では，成功することが多い手筋を成功手筋と呼び，失敗することが確実，または失敗することが多い手筋を失敗手筋と呼ぶ．
この中には，定石と呼んでよいものもかなりあるが，仕様中のほとんどの個所で使えるパターンが多く，手筋とした．
以下の定石・手筋の説明では，紙幅の都合上ごく一部しか紹介していないが，全部で定石・手筋は129個ある．このため，定石や手筋を一意に識別するため，VDMの証明に関する教科書（文献9）の証明IDの命名法を参考にして，定石と手筋のIDを付けることにした．この命名法で付けられたID名は，人間に分かりやすい名前を短縮したものなので，人間が読むにはやや分かり難くなるが，証明IDや囲碁の定石名などと同様に，最終的に3千から2万個ほどになる可能性があるため，唯一性と検索容易性を優先した．
成功手筋は，さらに以下のように分類し，整理した．すなわち，2写像の定義域・値域は，キーとデータの対応を持つ表だとイメージすればよい．キーの集合が定義域であり，データの集合が値域である．

168

SEA

ソフトウェア・シンポジウム2017 in 宮崎

1.2.1.1

物の集まりの型 {集合, 写像, 列}を使う手筋
1.2.1.1.1集合を使う手筋
1.2.1.1.2写像を使う手筋
1.2.1.1.3列を使う手筋

さらに，集合，写像，列を使う手筋は，内包式3を使う手筋と，限量式4を使う手筋と，その他の手筋に分けた．
「1.2.1.1.2写像を使う手筋」の中には，「1.2.1.1.2.1.2 写像に要素を追加する」手筋(IDTSCMCR_Append_++)があり，写像の上書演算子++と写像の旧値を使用し，写像の旧値と追加する写（maplet）を写像化したもの(写を’{‘と’}’で囲うと写像になる)を上書(定義域のキーが重複した場合，演算子++の右辺により上書き)した写像が，追加後の写像と等しいことを示している． この手筋に従えば，事後条件の記述と，操作本体の記述が容易になる．また，この定石は，3節の「定石・手筋の評価」の結果，かなり使われていることが分かった．
instance variables
public s許容数 : 許容数 := {|->};
public 委託する: 空域 * nat ==> 許容数
委託する(a空域, n) == (s許容数 := s許容数 ++ {a空域 |-> n};return s許容数)
pre
a空域 not in set dom s許容数
post
s許容数 = s許容数~ ++ {a空域 |-> n};
失敗手筋は，以下のように分類した．
1.2.2.1 ブール演算で注意すべき失敗手筋
1.2.2.2 集合で注意すべき失敗手筋「1.2.2.1 ブール演算で注意すべき失敗手筋」の中の「1.2.2.1.2 含意演算子と全称限量子 forall の組合せで注意す
べき失敗手筋．」は「forall e in set S & false となる式で，S が空集合の場合は，forall 式は常に true になる．」(手筋 ID
TFB_tautology)というものだが,VDM が使用している一階述語論理の日本語テキスト中で, 筆者の知る限り,この定理に言及したものは無いため,VDM++仕様記述の初心者は必ず間違えるため手筋とした.

1.2 分析についてのアイデア
分析は，仕様を分析し欠陥を修正する．VDM++の分析で利用できるツールの機能は，内部矛盾がないことを検証する検証機能として組合せテストと証明課題生成があり，仕様が顧客の要求を満たしているかを検査するため回帰テス
ト機能がある．このため，次のように分類した．
2 分析
2.1 検証2.1.1 組合せテスト
2.1.2 証明課題生成
2.2 妥当性検査
34

内包式はデータの範囲と条件を指定して物の集まりを作り出す式である．
限量式は，物の集まりのすべての要素が条件を満たすか，ある要素が条件を満たすかを判定する式である.

169

SEA

ソフトウェア・シンポジウム2017 in 宮崎

2.2.1 回帰テスト
例えば，「2.1.2 証明課題生成」の定石(ID Veri_PO)は，教科書には記述されていないツールの証明課題生成結果をどう使うかを，VDMTools 設計者の Peter Gorm Larsen 教授にインタビューして得た結果を記述している．
すなわち，「ツールで生成された証明課題は，VDM 本来の手法としては証明するのであるが，産業界の技術者向けに作られた VDM のツール群は証明機能を支援していない．そのため，生成された証明課題をレビューすることにより，未記述の事前条件や不変条件を見つけ，仕様の品質を高める．」

1.3 ツールについてのアイデア
VDM++を支援するツールは，Overture ToolsとVDMToolsとvdmjの３つあり，各々の長所を組合せて使用すると効果的である．そこで，以下のように分類した．
3. ツール
3.1 Overture Tools と VDMTools と vdmj の協働
3.1.1 ツールによるエラーの修正
3.1.1.1 エラー特定の手筋
3.1.1.2 テスト実行の手筋
3.1.1.3 テスト結果の比較の手筋
3.1.2 ツールによる回帰テスト
3.1.3 ツールによる組合せテスト
例えば「3.1.1.2 テスト実行の手筋」(ID TU_EC_PE_VT)は，「Overture Toolsは，エラーがあるとエラーの無い部分の実行もできない．VDMToolsは，完成した部分からテスト実行できる．構文エラーや型エラーがある時でも，エラーの無い実行可能な部分をテスト実行したい場合はVDMToolsを使う．」であり，アジャイル的に仕様を組み立てていく時は
VDMToolsの方が有効であるが，「3.1.2 ツールによる回帰テスト」手筋の中の「3.1.2.1 ツールによる回帰テスト使い分
けの手筋」(ID TU_RT_OT_VT)によると，「Overture Toolsは比較的簡単に回帰テストケースを作成できるので，テストケースがさほど多くない回帰テストはOverture Toolsで行い，テストケースが非常に多い場合はVDMToolsを使う．
Overture Toolsの回帰テストライブラリーは，VDM++の名前がtest（大文字も可）で始まる操作をテストケースとして自動的に探索し実行してくれるため，回帰テストの行数が少なくて済む．ただし，Overture ToolsとVDMToolsの回帰テス
ト・ライブラリを切り替え，テストケース記述もVDMTools用に追加しなければならない．一方，VDMToolsの方が，大量の回帰テストケースを実行できた実績がある．」であり，アジャイル的な仕様作成が大体終わり，回帰テストを使う最初の段階ではOverture Toolsを使う方が有効であり，大量のテストケースによる回帰テストを行う時はVDMToolsの方が安心であることが分かる．

1.4 マニュアルについてのアイデアマニュアルの手筋の分類は以下のとおりである.
4.マニュアル4.1 Overture Tools のマニュアル
4.2 言語仕様の要約版
4.3 VDMTools のマニュアル
4.4 vdmj のマニュアル
これらを要約すると,VDM++の初心者は「日本語マニュアルのため読みやすい」手筋「4.3 VDMTools のマニュアル」(ID MU_VT)を使い,実際に仕様を書く時は「4.2 言語仕様の要約版」(ID MU_OT_Quick)を参照すればよい.
VDM10 などの最新の情報を調べるには「4.1 Overture Tools のマニュアル」(ID MU_OT)が必要になり,「4.4 vdmj のマニュアル」は「GUI 版はなく,コマンド版のマニュアルであり,プロ向きの記述である」(ID MU_VJ)は,VDM++初心者には必要ないが,VDM++上級者には必要になることがある.

170

SEA

ソフトウェア・シンポジウム2017 in 宮崎

2. 主要な定石と手筋
1節で紹介した定石と手筋以外の、3節「定石・手筋の評価」で使われている主要な定石と手筋を,紙幅の許す範囲で紹介する.

1.2.1.1.2.1.3

写像から削除する手筋

種類による

式による

式に使え

分類

分類

る名前

定石 | 手筋 | 規則 |注意事項}ID

手筋

<-:
dom

-

TSCMCR_Delete{定石 | 手筋

| 規則 | 注意事項}ID説明

写像から要素を削除する手筋で，写像型の定義域削減演算子<-:と，削除する写像の定義域集合を得る演
算子domを使用して，写像の旧値から削除本の要素を削除したものが，削除後の写像と等しいことを示している。
例 1.2.1.1.2.1.3.1:

写像「i蔵書」の旧値から削除本の要素を削除したものが、削除後の写像i蔵書と等しいことを示している例。
types
public 蔵書 = map 蔵書ID to 本;
public 貸出 = inmap 利用者 to 蔵書;
instance variables
private i蔵書 : 蔵書 := {|->};
private i貸出 : 貸出 := {|->};
inv 蔵書に存在する(merge rng i貸出, i蔵書);
operations
public 蔵書を削除する: 蔵書 ==> ()蔵書を削除する(a削除本) == is not yet specified
post i蔵書 = dom a削除本 <-: i蔵書~;例 1.2.1.1.2.1.3.2: 写像「s許容数」の旧値から空域集合に対応する要素を削除したものが削除後の写像「s許容数」と等しいことを示している。
public 使用をやめる : 空域 ==> () --TSCMCR_Delete
使用をやめる(a空域) ==s許容数 := {a空域} <-: s許容数
pre a空域 in set (dom s許容数 ¥ dom s管制)
post s 許容数 = {a 空域} <-: s 許容数~;

171

SEA

ソフトウェア・シンポジウム2017 in 宮崎

1.2.1.1.1.1.1 集合に要素を追加する手筋。
種類
による
分類
手筋

式によ
る分類

式に使える名前

定石 | 手筋 | 規則 | 注意事項}ID

union

旧値が使えるのは、事後条件式の中だけである。

TSCSCR_Append{定石 | 手筋 | 規則
| 注意事項}ID説明

集合の合併演算子unionを使用してインスタンス変数に1要素を追加する手筋である
例 1.2.1.1.1.1.1:

集合の合併演算子unionを使用してインスタンス変数に1要素を追加する式の例--操作本体で使う場合の例
i客DB := i客DB union {a新しい客}―事後条件で使う場合の例
post i客DB = i客DB~ union {a新しい客}
public 出勤する : 管制官 ==> () --TSCSCR_Append
出勤する (a管制官) ==s当直集合 := s当直集合 union {a管制官}
pre a管制官 not in set s当直集合
post s当直集合 = s当直集合~ union {a管制官};

1.2.1.1.1.1.2 集合から要素を削除する手筋
種類
による
分類
手筋

式によ
る分類

式に使える名前

定石 | 手筋 | 規則 | 注意事項}ID\(集合の差)旧値が使えるのは、事後条件式の中だけである。

TSCSCR_Delete{定石 | 手筋 | 規則
| 注意事項}ID説明

集合の差演算子\と集合の旧値を使用し，旧値と削除する要素（を集合化したもの）の差が集合の値と等しいことを示した例である。
例 1.2.1.1.1.1.2:

集合の差演算子\と集合の旧値を使用し、旧値と削除する要素（を集合化したもの）の差が集合の値と等しいことを示した例である。
--操作本体で使う場合の例
i客DB := i客DB ¥ {a削除する客}―事後条件で使う場合の例
post i客DB = i客DB~ ¥ {a削除する客};public 退勤する : 管制官 ==> () --TSCSCR_Delete
退勤する (a管制官) == s当直集合 := s当直集合 ¥ {a管制官}
pre a管制官 in set s当直集合 ¥ rng s管制
post s当直集合 = s当直集合~ ¥ {a管制官}

172

SEA

ソフトウェア・シンポジウム2017 in 宮崎

3. 定石・手筋集の評価
ここでは，本定石・手筋集がどの程度有効であるかを，定石と手筋の収集に使っていなかった参考文献5と6を使って評価した．

定石と手筋

定石·手筋使用率

文献5
化学プラント仕様

文献6
航空管制システム
最上位仕様

100%

100%

写像に上書演算子を使って追加
TSCMCR_Append_++6写像から定義域削減演算子<-: を使って削除
TSCMCR_Delete

3

集合の合併演算子unionを使って追加
TSCSCR_Append

1

集合の差演算子¥を使って削除
TSCSCR_Delete1

データが意味的に正当か確認
JIT_wf_1

3

写像のドメイン同士に部分集合関係がある
JII_ibV_subset2

1

集合内に存在することを確認
TSCSQ_exsists_set

3

表6. 定石・手筋集の評価
上記2つのVDM++仕様については，すべての不変条件，事後条件，事前条件が，本定石・手筋集に記述されたものであった．また，全部で19個所ある定石と手筋の適用個所で使われている定石と手筋はわずか7種類であり，今後より多くのモデルのデータを集めることにより，主要な定石と手筋を特定できる可能性が強いことが分かった．
当然のことながら,集合型を中心とした仕様記述は集合に関する手筋を使い,写像型を中心とした仕様記述は写像と集合に関する手筋を多用するので,成功手筋の中で集合と写像と列5で手筋を分類したのは有効だった.
これらのVDM++仕様は定石と手筋の使用率が高いものを選んだわけではなく，たまたま最初に評価した2つのVDM++仕様だった．
現在のデータ数では，まだ「本定石・手筋集の有効性が高い」と言い切ることはできないが，一応定石と手筋集は役立ちそうだといえる．

4. 関連研究
文献 1. 2.など,関連ありそうな情報を探したが,今のところ囲碁や将棋やチェスの定石と手筋という観点から「定石と手筋集」を作成・整理しようという関連研究は無かった.

5列型を使った仕様はまだ評価していないが,過去の経験から,確実に有効であろうと考えている.

173

SEA

ソフトウェア・シンポジウム2017 in 宮崎

文献 3. 4. 6.7.などの VDM の証明に関する教科書は,本研究のヒントになる情報は多いが,VDM 仕様の証明が主題であり, 仕様記述の際に活用しようというものではない. 文献 12.も,囲碁などの棋譜や音楽の楽譜からの発想で,証明譜を使い,それを証明に活用しようというものであり,やはり仕様記述の際のヒントにしようというものではない.

5. 結論と追加研究
産業界でのVDM++仕様記述で一番困難な，不変条件，事後条件，事前条件のパターンを定石・手筋集として試作した．
本定石・手筋集の有効性はある程度確認できたので，今後，実用的なモデルの定石・手筋使用率をさらに調べるていく予定である．調査対象モデルとしては，文献5の原子力追跡機モデル，筆者のカレンダー・ライブラリ， 文献9のNetwork Security Policy Modelなどを考えている．
VDMの証明についての教科書である文献7と文献9は，不変条件，事後条件，事前条件例を見つけ出すためにかな
り役立つことが分かったので，重点的に調べていく予定である．
定石・手筋から仕様の骨格を生成でき,ツールに組み込んでいくことも可能である.例えば,Overture ToolsのEdit
Template機能(文献 13.参照)で,下記のような「写像に要素を追加する．」手筋(ID TSCMCR_Append_++)用の”appendpp”という名前のテンプレートを記述しておくと,
types
public ${TypeName} = ${TypeName0};
instance variables
public ${instancevariable} : ${TypeName} := ${statement};
operations
public ${operationname}: ${argTypes} ==> ${resultType}${operationname}(${arg1}, ${arg2}) == (${instancevariable} := ${instancevariable} ++ {${arg1} |-> ${arg2}};
return ${instancevariable})pre${arg1} not in set dom ${instancevariable}
post${instancevariable} = ${instancevariable}~ ++ {${arg1} |-> ${arg2}};
post$ {instancevariable} = $ {instancevariable}~ ++ {$ {arg1} |- > $ {arg2}};

エディター画面でappendppとタイプしてからコントロール・キーとスペース・キーを同時に押すことにより,テンプレートのテキストが挿入され,エディターで${instancevariable}部分をs許容数に変えると,すべての${instancevariable}がs許容数に変わり,下記のようになる.
types
public TypeName = TypeName0;
instance variables
public s許容数 : TypeName := statement;
operations
public operationname: argTypes ==> resultType
operationname(arg1, arg2) == (s許容数 := s許容数 ++ {arg1 |-> arg2};

174

SEA

ソフトウェア・シンポジウム2017 in 宮崎

return s許容数)
prearg1 not in set dom s許容数
post
s許容数 = s許容数~ ++ {arg1 |-> arg2};
作成した手筋テンプレートはまだ1つであるが,今後,徐々に追加していく予定である.
なお，現在コンサルティング中のプロジェクトで本定石・手筋集の一部を教育し，実プロジェクトで試行していく予定で
ある．

参考文献
1. JÖRG ACKERMANN, FORMAL DESCRIPTION OF OCL SPECIFICATION PATTERNS FOR BEHAVIORALSPECIFICATION OF SOFTWARE COMPONENTS, 2005
2. ANDREW IRELAND AND BILL J. ELLIS AND TOMMY INGULFSEN, INVARIANT PATTERNS FOR
PROGRAM REASONING, 2004
3. CLIFF B JONES, CASE STUDIES IN SYSTEMATIC SOFTWARE DEVELOPMENT SECONDEDITION, 1990
4. CLIFF B JONES, SYSTEMATIC SOFTWARE DEVELOPMENT USING VDM, SECONDEDITION , 1990
5. ジョン・フィッツジェラルド他著, 酒匂寛 訳, VDM++によるオブジェクト指向システムの高品質設計と検証, 2010
6. JIM WOODCOCK, MARTIN LOOMES, SOFTWARE ENGINEERING MATHEMATICS: FORMAL METHOD
DEMYSTIFIED, 2007
7. JUAN C. BICARREGUI, JOHN FITZGERALD), PETER A. LINDSAY, RICHARD MOORE, BRIAN RITCHIE,PROOF IN VDM: A PRACTITIONER’S GUIDE, 1995
8. 佐原伸, IPA, 対象を如何にモデル化するか?, 2013
9. JUAN C. BICARREGUI (ED.) PROOF IN VDM: CASE STUDIES, 1998
10. VDM — THE VIENNA DEVELOPMENT METHOD, ANDREAS MULLER, APRIL 20, 2009
11. DANIEL JACKSON. SOFTWARE ABSTRACTION : LOGIC, LANGUAGE, ANALYSIS . THE MIT PRESS,CAMBRIDGE, 2006
12. Kokichi FUTATSUGI1, Joseph A. GOGUEN2, and Kazuhiro OGATA: Verifying Design with
Proof Scores, 2008
13. PETER GORM LARSEN, KENNETH LAUSDAHL, PETER TRAN-JØRGENSEN, JOEY COLEMAN, SUNE
WOLFF, LU´IS DIOGO COUTO AND VICTOR BANDUR: OVERTURE VDM-10 TOOL SUPPORT:
USER GUIDE, VERSION 2.4.6, 2017

175

SEA

ソフトウェア・シンポジウム2017 in 宮崎

日立グループにおける働き方改革の「カタ」～マルチタスクに注目した設計・開発の改善プログラム～

八木 将計
株式会社日立製作所
masakazu.yagi.zd@hitachi.com

西原 隆
ゴール・システム・コンサルティング株式会社
nishihara@goal-consulting.com

真道 久英
ゴール・システム・コンサルティング株式会社
shindo@goal-consulting.com

村上 悟
ゴール・システム・コンサルティング株式会社
murakami@goal-consulting.com

渡辺 薫
株式会社日立製作所
kaoru.watanabe.lm@hitachi.comになってきている．
このような流れの中，ソフトウェア開発の改善活動に取り組んでいる組織が多くあるものの，必ずしも十分な改善効果を上げているわけではない．なぜならば，ソフトウェ
ア開発では，製品の特性や開発者のスキル，ビジネス環
境など，様々な要素が絡んでおり，その改善効果は，
SEPG，SQA，コンサルタントなどの支援者や改善推進者の力量に依存してしまっている．
一方，ソフトウェアを含む開発・設計の現場は，多くの場合，一つの開発・設計業務に集中しているわけではな
く，さまざまな業務を切り替えながら仕事をする「マルチタ
スク」となっている．このマルチタスクは，ソフトウェア開発における QCD に悪影響を及ぼすことが多い[2][3][4]．
日立グループでは，2011 年から開始した企業変革である Hitachi Smart Transformation Project (通称：スマトラ)の一環として，設計・開発の「働き方改革」に取り組んできた．その働き方改革では，上述のマルチタスクの低減に注目することで十分な改善効果を上げることができることがわかってきた．そこで我々は，このマルチタスクに注目した改善手順を日立グループの働き方改革の「カタ(標準型)」として整理・標準化した．
本報告では，この働き方改革の「カタ」である「チームマネジメント A3」と，それに基づく改善プログラムを提案する．このチームマネジメント A3 に基づく改善プログラムを用いることで，ある程度，改善支援者や推進者の力量に依存せずに改善活動を進めることが出来ており，現在まで日立グループにて 1,000 人以上が関わる規模に拡大している．

要旨
本論文では，日立グループにおける働き方改革の「カタ(標準型)」を報告する．具体的には，ソフトウェアを含む
設計・開発において，日立グループでの改善活動で得られた知見を整理・標準化したチームマネジメント A3 というフォーマットとそれに基づく改善プログラムを提案する．
提案手法では，QCD に様々な悪影響を及ぼすマルチタ
スクの低減を改善目標とし，マルチタスクを見える化する
タスクボードと毎朝のスタンドアップミーティングで問題をあぶり出し，KPT による解決志向アプローチと TOC 思考
プロセスによる原因追及アプローチの組合せで改善を推進する．このチームマネジメント A3 により，助言を得やす
くなったなどの定性的効果だけではなく，残業時間 30%減や納期遵守率 27%増などの効果も得た．また，働き方改革の 展開 が容 易にな り， 現在 ， 日 立グ ル ー プにて
1,000 人以上が関わる規模に拡大している．

1. はじめに製品の短納期化・多機能化といった市場要求の変化などの背景により，ソフトウェアを含む製品の開発・設計において，従来の開発スタイルの維持では，会社の競争
優位性の確保が難しくなってきている．そのため，ソフトウ
ェア開発においても，常に「改善」が求められる．また，近年，「働き方改革」として，様々な業種・業態にて，働き方の見直しとそれによる生産性向上が求められており[1]，ソフトウェア開発でも例外ではなく，さらなる改善が必要

176

SEA

ソフトウェア・シンポジウム2017 in 宮崎

2. 問題解決手法における課題【課題 2 の対策】：タスクボードとスタンドアップミーティン
グ[5][6]
一般的に，上述のマルチタスクは感覚的には認識されているが，客観的にどのようにマルチタスクになっているかが分かっていないことが多い．そこで，設計・開発チーム内のタスクを見える化・共有するツールであるタスク
ボードとスタンドアップミーティング(詳細は 3.4 節)を実施
することで，客観的にマルチタスクの状況把握を行う．

組織の問題解決手法や改善手法は，さまざま存在しているが，概ね QC ストーリー(表 1)のような手順となる．
表 1 問題解決型 QC ストーリｰ
1)テーマの選定
2)計画の立案
3)現状の把握
4)目標の設定5)要因の解析6)対策の立案・選定
7)効果の確認
8)歯止め

あるべき姿と現状のギャップから改善のテーマを決定する
改善の計画を立案する
事実のデータを収集し，現状を把握する
把握した現状と選定したテーマに基づき，具体的な目標値を決定する
より深い分析により，問題の原因を特定する特定した問題の原因を取り除く対策を立案し，選定する対策を実施し，その有効性を確認する問題が再発しないように歯止めを行う【課題 3 の対策】：解決志向アプローチ
タスクボードとスタンドアップミーティングにて，マルチタスクの状況を見える化すると，様々な問題点が浮き彫りになってくる．しかし，改善活動開始当初は，明らかになる問題の数が多すぎるため，本腰をいれて取り組むべき根本問題が簡易な問題に埋もれてしまっている場合が多い．そこで，それら簡易な問題について，解決志向アプ
ローチを用いた改善を行うことで，枝葉を取り除く．我々は，この解決志向アプローチとして，KPT (良い点:Keep，
問題点:Problem，改善案:Try) を用いた週次のふりかえ
りを用いている[7][8](詳細は 3.5 節)．
【課題 4 の対策】：原因追求アプローチ
上記の解決志向アプローチを進めて行くと，どうしても解決できない根の深い問題が残ることになる．その問題について，原因追求アプローチで原因の深堀りし，根本的な問題解決を行う．
我々は，この原因追及アプローチとして，組織の問題解決に用いられる，TOC (Theory of Constraints：制約理論) 思考プロセス[10][11]を応用している(詳細は 3.6 節
参照)．

我々は，上記の手順について，下記のような課題があるため，改善の効果が改善支援者や推進者の力量に依存してしまうと考えている．
【課題 1】：テーマに何を設定してよいかわからない【課題 2】：現状把握が主観的になりやすい【課題 3】：情報過多となり，根本問題がわからない【課題 4】：根本問題に対する解決策を導出できない

上述の知見に基づき，我々は日立グループにおける働き方改革の「カタ(標準型)」として，整理・標準化している．具体的には，「チームマネジメント A3」と呼ぶ A3 一枚(PowerPoint で 8 スライド)の標準的な問題解決フォーマットを規定した(図 1)．チームマネジメント A3 フォーマットの概要を以下に示す．
【1 枚目】：タスクボード&スタンドアップミーティングの運用ルール
解決志向【2 枚目】：よかったこと・工夫点
アプローチ【3 枚目】：現状の問題分析【4 枚目】：重点改善項目【5 枚目】：根本原因分析
原因追求【6 枚目】：対策案検討
アプローチ【7 枚目】：対策の実行計画【8 枚目】：実施評価と横展開

3. 日立グループにおける働き方改革の「カタ」
3.1. 働き方改革の「カタ」：チームマネジメント A3
日立グループでは，全社の企業改革であるスマトラ活動の一環として，「働き方改革」を推進してきた．その経験から，特に設計・開発においては，以下のような進め方をすることで，前章に示す問題解決の課題を解決することができ，結果，改善支援者や推進者の力量にある程度依存しない形で改善効果を得ることが出来るという知見を得た．
【課題 1 の対策】：マルチタスクの低減
ソフトウェア開発の QCD に悪影響を与える「マルチタスク (詳細は 3.3 節)」の低減をテーマとして固定する．

177

SEA

ソフトウェア・シンポジウム2017 in 宮崎① チームマネジメント運用ルール

チーム名

 導入～定着（期間：前半 3 ヶ月程度）
タスクボードの運用をチーム内に定着させ，以下の定性的効果を得る．
 仕事内容の共有／コミュニケーションの円滑化
 トラブルの早期発見と早期対策／相互支援
 仕事の計画ミス・抜け漏れ防止
 根本原因分析～チーム個別改善施策検討（期間：後半 3 ヶ月程度）
タスクボードの運用のふりかえりから，チームマネ
ジメント A3 に則り以下を実施する．
 十分な設計時間を確保する上での重要な阻害要因の特定と重点改善項目の決定 根本原因分析とチーム個別改善施策および期待効果の検討・合意(改善施策には，TOC の手法を始め，アジャイ
ル 開 発 の 手 法 ， XDDP (eXtreme Derivative
Development Process)[12][13]，リーン製品開発[14]などの各種手法を適宜取り入れる) （可能な場合）チーム個別改善施策の実行～
成果の確認③ チーム個別改善活動（期間：6 ヶ月～12 ヶ月）
上記のチーム個別の改善施策を本格的に実行し，定着させる．
④ 継続的改善
上記のサイクルをチーム単独で（もしくは最小限の TOC 有識者の支援で）継続実行する．

⑤ 根本原因分析

ルール（実施日時・内容）
B-Dの根拠 (仮説)・ XXXXX

月曜日 9:30 までにTO-DO欄に１週間分 各人がタスクを貼り出す
週次計画＜付箋の色＞
黄：テーマX211関係、青：テーマY671関係、赤：飛び込み対応＜付箋のサイズ ＞
75mm×50mm：半日 75mm×2mm：２時間
TO-DO：今週実施計画タスク
タスクボードの Doing：本日実施中タスク
レーン
Suspend：タスク実施後 中断したタスク
Done：完了タスク
タスクの移動

必要条件

行動

B

D

C

D’

共通目的
A

対立

毎日9:30-9:45 一人ずつ付箋を移動させながら報告
司会は週ごとのもちまわりとする

振り返り

金曜日 16:00-17:00

その他

1日で完了しなかったタスクには赤丸をつける

C-D’の根拠(仮定)・ XXXXXX
・ XXXXXX② Keep：チームマネジメント導入 工夫と成果⑥ 対策案検討

タスクボードを活用したチームマネジメントを実施する中で、以下のような工夫と成果をえた （タスクボードの項目以外も含む）

実施したこと・工夫したこと実施理由と成果

・業務計画時、各業務を細分化して遂行時間を見積仕事を進める行動ができるようになってきた
タスクボードによる作業の可視化と朝会による共有

・メンバー個人の作業量の偏りを調整できるようになっ
てきた

効果

難易度

（大:３, 小:１）

（難：１,易：３）

1 XXXX

CCPM

２

３

◎

2 YYYY

XDDP

３

１

△

3 ZZZZAAAAAA

２

２○

4 ZZZZBBBBBBB

１

２

×

仮定

対策案

評価

備考

【 取り組む改善案 】
タスクボードにペンディング欄を設置

・保留になっている業務をリーダーが迅速に把握して保留原因の問題解決が早くできるようになってきた

CCPM③ Problem：現状の問題分析⑦ 対策案実行計画

改善されていないチームの現状の問題
飛び込み作業が多く業務遂行を阻害している。原因を調査したところ下記のようなデータを得られている。

目的

XXXXXXXX

対策

CCPM

成功基準
飛び込み作業理由

頻度（発生件数）

影響度（工数）

納期の25%短縮

担当

活動実施項目
必要事項の洗い出し

作業量の見積ミス

32

69

QAからの問い合わせ

25

78

不具合対応

19

48

準備

Yagi

ルールの原案作成

Yagi

関係部署との協議

Yagi

試行実施

All

ルール改善

Yagi

全テーマへの展開

All

試行

展開

予実

上

１月
中

下

上

２月
中

下

上

３月
中

下

予

実
予
実
予
実
予
実
予

実
予
実

⑧ 実施評価と横展開④ 重点改善項目【重点改善項目】

60

営業からの問い合わせによる突発業務発生の低減

営業からの飛び込み

31%

50
40
30
20

【設定の理由 】
XXXXXXXXXX

10
0
1Q

【 成果】
XXXXXXXXXX

2Q

3Q

4Q

【 横展開】YYYYYYYYYYY

図 1 チームマネジメント A3 フォーマット

3.3. マルチタスクの QCD に対する影響
3.2. チームマネジメント A3 による働き方改革の進め方
前節に示すチームマネジメント A3 を用いた改善プロ
グラムは，4～8 名程度のチームによる活動を基本とし，チームの改善推進者が改善支援者(TOC の有識者)の支
援の下，チームマネジメント A3 にしたがって，自チームの改善を推進していく．活動の全体像は，以下のようになる．
① 準備（期間：1～3 ヶ月）
2～3 回のワークショップを通じて，チームマネジメン
ト A3 の手法の学習する．
② チームマネジメント A3 導入（期間：6 ヶ月）
6 ヶ月間，チームにてタスクボードを運用する．また，
隔週 1 時間，チームの改善推進者が TOC の有識者と面談しながら，チームマネジメント A3 を 1 枚目から順番に作成する(チームよって進捗は異なるが，典型的には隔週で 1 枚のぺースとなる)．

178

ソフトウェアを含む開発・設計の現場は，多くの場合，一つの開発・設計業務に集中しているわけではなく，複数の開発を抱えていたり，突発に発生する不具合に対応したり，問い合わせ対応や会議などのその他さまざまな業務を切り替えながら仕事をする「マルチタスク」となっている．ここでの「マルチタスク」とは，目的や内容の異なる
複数の作業タスクを切り替えながら仕事をすることとする．
つまり，内容的に一つの塊になっているタスクを中断して，別のタスクを実行し，もう一度中断したタスクに戻ってくるような仕事の仕方のことをさす．
このマルチタスクは，タスクの切り替えに段取り時間な
どのオーバーヘッドがあるため，全てのタスクをシングル
タスクでシーケンシャルに実行するよりも多くの時間がかかってしまい，工数圧迫や遅延の要因となり，開発コスト増大にもつながる[5][15]．また，一般的に人間の思考は
シングルタスクであるため，マルチタスクになると生産性が 40%低下するとも，IQ が 15 ポイント低下するともいわれ

SEA

ソフトウェア・シンポジウム2017 in 宮崎ている[2]．加えて，タスク切り替えで集中力が削がれることで，ケアレスミスなどの作業品質の低下を招き，工数圧
迫によるプレッシャーなどで，成果物や製品の品質を低下させる．
さらに，過度なマルチタスクは，精神疾患を生み出すともいわれており，QCD の側面だけでなく，組織全体の能力が奪われることにつながる[3][4]．
チームマネジメント A3 による働き方改革では，このマ
ルチタスクの低減を改善の目標と設定している．

担当者

ＴＯ－ＤＯ
（今週の予定）・・・資料作成

AAAさん・・・資料作成・・・資料作成

BBBさん・・・資料作成

Ｄｏｎｅ（完了）
・・・資料作成・・・打合せ・・・打合せ・・・打合せ・・・資料作成・・・打合せ・・・資料作成

CCCさん

Ｄｏｉｎｇ
（本日のタスク）・・・資料作成・・・打合せ・・・打合せ3.4. タスクボードとスタンドアップミーティング
図 2 タスクボードの例
マルチタスクを見える化する有効な方法として，タスク
ボードとスタンドアップミーティングがある[5][6]．タスクボードとは，その週の予定タスクを貼る「ToDo」欄，本日実施しているタスクを貼る「Doing」欄，完了したタスクを貼る「Done」欄を最小限とした，ボードである (図 2)．スタンド
アップミーティングは，毎日 15 分程度のチームでの作業
タスクの確認・共有を目的とした立って行うミーティングである．チームメンバー各自のタスク(付箋など)をタスクボー
ドに貼り，毎日のスタンドアップミーティングで共有することで，マルチタスクも含め，チーム内のタスクの状況を見える化することが出来る．
タスクボードの運用は，以下のようなサイクルとなる．
① 週に一度，自分自身の一週間分の作業タスクを
一日未満に分解して計画し，付箋に書き，タスク
ボードに貼り付ける．
② その計画に対して，毎日のスタンドアップミーティ
ングにて，付箋を動かしながら，作業状況や問題点をチーム内で共有，問題発見を迅速にし，解決を早める．

3.5. 解決志向アプローチ
解決志向アプローチとは，問題やその原因を追求す
るのではなく，改善策とその効果に焦点を当てる心理療法を基礎とした手法であり，トライ&エラーでふりかえりな
がら簡単に改善できるものは改善してしまおうというものである．
チームマネジメント A3 では，タスクボード&スタンドアッ
プミーティングで明らかになってきたマルチタスク，特に飛び込みタスクの要因などさまざまな問題が明確になる
ので，KPT などを用いた週次のふりかえりで手をつけやすい問題から改善していく[7][8]．
3.6. 原因追求アプローチ

チームマネジメント A3 では，まず，このタスクボード&
スタンドアップミーティングで現状を見える化，特に，多くの場合にマルチタスクの大きな要因となっている｢飛び込みタスク(計画外タスク)｣がわかるような運用を行う．ここで，飛び込みタスク(計画外タスク)とは，週次計画で計画しておらず，週中でやならければならなくなったタスクであり，他者からの依頼の他に自分自身の計画漏れも含むタス
クである．

179

原因追求アプローチとは，なぜなぜ分析に代表される，問題の原因を深堀して追求し，その根本原因を解決する方法である．
チームマネジメント A3 では，解決志向アプローチを繰り返しても解決できない深い根本問題について，原因追求アプローチを用いる．具体的には TOC 思考プロセスを原因追及アプローチとして用いる．
TOC とは，エリヤフ M ゴールドラットが開発した企業利益を決定づける「制約条件」にフォーカスすることによって，全体最適を実現し，最小の努力で最大の効果をあげる経営管理手法である[16]．TOC 思考プロセスは，TOCにおける組織の問題解決のための手法である[9][10][11]．
表出している症状に個別対処するのではなく，組織の目
標達成を阻害している本質的な中核問題(悪い方針や評価基準)を明かにし，それを解決した“あるべき姿”を描き，それを実現するためのプランを策定する体系的な原因追及アプローチの問題解決手法である．

SEA

ソフトウェア・シンポジウム2017 in 宮崎

3.7. チームマネジメント A3 の各項内容

B-Dの根拠(仮定：Assumption)
・XXXXX【1 枚目】：チームマネジメント運用ルール
チームマネジメント A3 フォーマットの 1 枚目は，タスクボードやスタンドアップミーティングの運用ルールである．
運用ルールは各チームの個別事情があるため，それぞれの事情に合わせたカスタマイズをしてもらう．

必要条件 Needs

行動 Action

B

D

共通目的 Objective

対立

A
C

【2 枚目】：チームマネジメント導入の工夫と成果
チームマネジメント A3 フォーマットの 2 枚目は，タスク
ボード運用での週次ふりかえりで出た解決志向アプロー
チの結果における良い点(KPT の Keep，Try)をまとめたものである．また，チームごとで独自に工夫・改善した点についてもまとめる．
まずは，タスクボードによるチームマネジメント導入の定性的効果を感じることで，本格的な業務改善のモチベーションを高める．

D’

C-D’の根拠(仮定：Assumption)
・XXXXXX・XXXXXX

図 3

対立解消図

【6 枚目】：対策案検討
チームマネジメント A3 フォーマットの 6 枚目は，5 枚目の根本原因分析に対して，考えられる対策案を列挙し，効果と難易度から実行する対策を決定する．5 枚目にて対立解消図を用いている場合，ジレンマを発生している仮定に対する対策を考えることで，ジレンマを取り除く方法を検討する．

【3 枚目】：現状の問題分析
チームマネジメント A3 フォーマットの 3 枚目は，週次ふりかえりで議論し，2 枚目の解決志向アプローチでは改善しきれない，現状の問題点(KPT の Problem)を纏めたもの．できるだけ客観的にチーム内の現状を把握するために，定量的に纏める方がよい．

【7 枚目】：対策案実行計画
チームマネジメント A3 フォーマットの 7 枚目は，6 枚目で決定した対策案の実行計画である．まず，実行にあた
り改めて，対策の目的，対策内容，成功基準を明確にする．ここでは，対策が実際に目的を達成し，成功したことを認識するために，成功基準が重要となる．ハッキリとそうであると判定できる基準でなければならず，できる限り定量的に記述するようにする．次に，その目的，対策内容，成功基準を実行する計画を期間，担当者なども含めて立案する．

【4 枚目】：重点改善項目
チームマネジメント A3 フォーマットの 4 枚目は，3 枚目の結果を受けて，チーム内で取り組む改善項目とその理由である．3 枚目同様，できるだけ客観的にチーム内の現状を把握するために，定量的に纏める方がよい．ただし，客観的に見た場合に合理性に欠いていても，チーム内での合意形成を重視する．そのため，3 枚目とは直接関係のない改善項目でも構わないが，その後の進め方
は慎重に行う必要がある．

【8 枚目】：実施評価と横展開
チームマネジメント A3 フォーマットの 8 枚目は，7 枚目
を実際に実行した結果の評価を纏めたものである．定量的なデータとして成果を纏める．また，データの収集は追加負荷のかからないものを選ぶと良い．例えば，タスクボードの付箋のカウントなどである．また，残業低減などの目的に対応する「効果」に関するデータと，対策の適用累計などの「実施」に関するデータを取るとモチベーショ
ンにも繋がるためよりよい．ただし，実際には，チームマ
ネジメント導入の 6 ヶ月では，成果が出ていないことが多いため，「こうなればよい」という予測の特性となる．

【5 枚目】：根本原因分析
チームマネジメント A3 フォーマットの 5 枚目は，4 枚目の重点改善項目に対して，その根本原因を分析したものを纏める．フォーマットは，TOC 思考プロセスで根本原因分析に用いる対立解消図[9][10][11](図 3)などを用いて行う．この対立解消図は，「改善したいけどできない」というジレンマを整理し，そこに潜んでいる仮定(Assumption)
を明かにする．

180

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4. チームマネジメント A3 による働き方改革の効果

100%計画内タスク80%
60%

4.1. 飛び込みタスクの低減例
本手法による働き方改革の具体的な改善内容は，チームの特性などによっても全く違っている．本節では，個別全てのチームを示すことはできないので，典型的な改善パターンを述べる．特に，マルチタスクの大きな要因の一つである飛び込みタスクの低減について述べる．
本手法の導入初期の段階では，見える化と解決志向
アプローチによって飛び込みタスクが減る．具体的には，
初期はチームメンバーそれぞれがタスクをばらすこと(週次計画)に慣れていないため，自分自身の計画漏れによる飛び込みが多く(図 4)，解決志向アプローチによる改善を行うことで，その自分起因の飛び込みタスクが減り始めることが多い．良く用いられる飛び込み削減のための施策は，以下のようなものがある．
 ペアで週次計画をチェック(計画のピアレビュー)
 月曜日に計画していたのを，金曜日に計画し，月曜日に見直す リーダーによる週次計画レビューの徹底
 タスクの不明点リストの導入
 リーダーからの作業指示のフォーマット化
その後，自分起因以外も含めた飛び込み削減のために解決志向アプローチで改善をしていくが，それだけでは，大きな改善効果が出なくなってくるので，その状況下で見えてきたチームの根本的な問題について，TOC 思
考プロセスに原因追及アプローチを用いて，チーム個別の改善施策を検討し，実行する．典型的な飛び込みタス
クの低減は，図 5 に示す形となる．

２０％

その他

２６％

飛び込み
タスク内訳

不具合対応

２０％

20%
0%

飛び込みタスク(計画外タスク)

第1-2週

第3-4週

第5-6週

第7-8週

第9-10週

第11-12週

特急飛び込みタスク

図 5 飛び込みタスク低減の実績例
4.2. 定性的効果
本手法による働き方改革のヒアリングに基づく定性的効果を以下に示す．主に，タスクボードを導入したことによる効果と，解決志向アプローチの効果が多い．
① 情報共有について 自分以外の担当者がどのような業務を実施しているのか分かるようになった．
 タスクボードへ貼り出して見ることにより，業務の優先順位を整理し易くなった．
 メンバー個人の作業量の偏りが把握し易くなってきた．
 毎日実施することで，大きい項目を細分化する意識，および一つ一つ片付けて後戻りが無いようにする意識が強くなった．
② ミス防止について 業務計画時，各業務を細分化して遂行時間を見積もって仕事を進める行動ができるようになってきた．
 数週間停滞していると忘れがちであったが，相手をフォローアップできるようになったとともに，予定作業として準備できるようになった．
 保留になっている業務をリーダーが迅速に把握して，保留原因の問題解決が早くできるようになってきた．
 助言を得やすくなった．
 業務時間を正確に見積もるため，業務を細分化
して本人が意識しない問題を指摘され，問題発
生前に問題を解決できた．

計画時の洗い出し漏れ

自分起因の
飛び込み
１２％
作業時間見積もり誤り

他部門からの
問合せ等

約40%減

40%

２２％

図 4 飛び込みタスクの内訳実績例③ 課題抽出について
 飛び込み作業について件数，内容が分析でき，チーム内の飛び込み業務に対する考え方を整理できた．
 設計手配業務の不定期な割込が，業務遅延要

181

SEA

ソフトウェア・シンポジウム2017 in 宮崎

因となっていることが判明した．手配業務は，専任者を決め，各設計者より適宜手配業務を移管することで手配業務による遅延時間は低減している．
作業内容を先送りした事を忘れてしまい，次のプ
ロジェクトで問題になる事がある．忘れないようにするため欄を設置して注意を促すようにした．
業務遅延の要因（内容，自責，他責）を把握し，発生頻度を記録することで，頻度の高い問題や遅延要因に焦点を当てた改善活動ができた．

削減による期間短縮
リードタイム：5 日 → 1 日 (仕様変更対応日数)
クレーム件数：6 件/案件数 70 件 → 0 件/案件数
135 件
生産性：1.5 倍 (対応案件数) ※人員および残業の増加無しに達成
チームワークに関するアンケート Ocapi[17]：10 点/10 点満点 ※平均は 5～7 点程度．






4.4. 適用チーム数の推移④ その他の成果
 職場での会話が格段に増えた／今まであまり話さないと思っていた若手が実は結構積極的にキチンと話せることがわかった．
 従来は打ち合わせの雰囲気が悪く・対立的な会話が顕著だったが，毎朝笑顔で情報共有し，気持ちよく仕事を開始できるようになった．
 個人・家庭の事情を共有し，助け合う雰囲気が，より強くなった．時短勤務や家庭の事情による遅刻・早退等を責める雰囲気や気持ちが軽減された．
 若手が仕事の段取りを覚えて自分で仕事をこなせるようになった．また報告や連絡の内容・タイミ
ングが的確になってきた．

本手法による働き方改革を取り組んでいるチーム数の推移を図 6 に示す．本手法は，2014 年下期から検討を開始，試行を経て，2015 年下期から本格的に展開を開始した．図 6 に示すとおり，口コミでの評判も手伝って，2015 年下期から取組みチーム数が倍増している (現時点で，のべ 1,000 名以上が改善活動に参加している)．
また，展開規模が拡大しているが，その間 TOC の有識者
は 3～4 名と大きくは変動していない．そのため，チーム
マネジメント A3 で標準化したことによって，支援者の負荷を増やさずに，効率的に業務改善を進めることができると考えられる．
本手法整理開始

チーム数累計

140

本格適用

123

120
100

4.3. 定量的効果

80

本手法を全展開した部署（18 チーム）の 1 年間の活動にて，下記のような大きな定量的な効果を得ている．ただし，当該部署では本手法以外の施策にも取り組んでおり，それらの総合的な結果である．また，それらの相乗効果があるため，本手法の効果のみを切り出すのは困難と考える．
 設計 Fix 以降の変更手戻り時間：70%削減
 納期遵守率：71% → 98% (内部管理指標)
上記以外の部署においても，下記のような定量的成果を得ている．ただし，仕事の変動による影響が大きいこと，着手まもないチームも多く，全てのチームで定量的効果を検証できているわけではない．また，本手法に加え，並行して実施した他施策との相乗効果が含まれる．
 残業時間(休出含)：720 時間/月 → 480 時間/月(33%減)
 納期遵守率：52% → 75% (内部管理指標)
 納期遵守率：平均遅延日数を半減
 リードタイム：仕様決定までの問い合わせ数 20%

182

60

60

46

40
20

15

15

2013下

2014上

0

2014下

2015上

2015下

図 6 本手法適用チーム数累積の推移

5. まとめ
本報告では，日立グループにおける働き方改革の知見と経験を整理・標準化した「カタ(標準型)」として，チー
ムマネジメント A3 と，それに基づく改善プログラムを提案した．提案手法では，ソフトウェアの QCD に悪影響を与えるマルチタスクに注目し，その状況をタスクボードとスタ
ンドアップミーティングで明らかにする．そこから浮き彫りになる問題点について，まず KPT による解決志向アプローチでふりかえりながら，改善できるところから継続的にSEA

ソフトウェア・シンポジウム2017 in 宮崎

改善を行い，解決志向アプローチでは解決しきれない根の深い問題について，TOC 思考プロセスによる原因追及
アプローチを用いることで，問題原因の深堀を行って，根本原因の改善を行う．チームマネジメント A3 はこのステップをまとめたフォーマットであり，改善支援者や改善推進
者の力量に依存しやすい改善活動において，ある程度属人性を排除し，改善効果を生みやすい構成としている．
結果，チームマネジメント A3 という標準フォーマットを用いることで，改善チーム数を倍増，のべ 1,000 名規模の活動に拡大することに成功した．
また，実際の改善効果として，このチームマネジメント
A3 による改善プログラムの結果，「メンバー個人の作業量の偏りが把握しやすくなった」「タスクを一つずつ片付けることで後戻りを減らすようになった」「助言を得やすくなった」などの定性的効果に加え，残業時間 33%減，設
計変更手戻り時間 70%減，納期遵守率 27%増，などの定量的効果もあがっている．

東京，2008.
[11] 岸良裕司，全体最適の問題解決入門－「木を見て森も見る」最強の思考プロセス－，ダイアモンド社，
東京，2008.
[12] 清水吉男，失敗しない派生開発(Software People
Vol.8)，技術評論社，東京，2006．
[13] 清水吉男，「派生開発」を成功させるプロセス改善の技術と極意，技術評論社，東京，2007．
[14] 稲垣公夫，開発戦略は「意思決定」を遅らせろ! ─ト
ヨタが発想し、HP で導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」，中経出版，
2012.
[15] エリヤフ・ゴールドラット，クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?，ダイ
アモンド社，東京，2003.
[16] エリヤフ・ゴールドラット，ザ・ゴール―企業の究極の目的とは何か，ダイアモンド社，東京，2001.
[17] “組織変革プロセス指標 Ocapi,” https://ocapi.jp

参考文献[1] “首相官邸「働き方改革の実現」”
http://www.kantei.go.jp/jp/headline/ichiokusoukatsu
yaku/hatarakikata.html[2] “Multitasking: Switching costs.” Research in Action.
20 March 2006.
http://www.apa.org/research/action/multitask.aspx[3] エドワード M. ハロウェル，” マルチ・タスクが「脳力」を奪う,” ハーバードビジネスレビュー，2005.
[4] 八木将計，西原隆，真道久英，村上悟，渡辺薫，“マルチタスクが「QCD」を奪う！～日立グループ
1,000 人に広がる 働き方改革 6 ヶ月プログラム～,”ソ フ ト ウ ェ ア 品 質 シ ン ポ ジ ウ ム 2016(SQiP2016),
2016.
[5] 西原隆，栗山潤，TOC/CCPM 標準ハンドブック―ク
リティカルチェーン・プロジェクトマネジメント入門，
秀和システム，2010．
[6] “プロジェクトファシリテーション実践編:見える化ガ
イド,”
http://www.objectclub.jp/download/files/pf/Manage
mentBySeeingGuide.pdf[7] 天野勝，これだけ！KPT，すばる舎，2013.
[8] “プロジェクトファシリテーション実践編:ふりかえりガ
イド,”
http://objectclub.jp/download/files/pf/Retrospective
MeetingGuide.pdf[9] エリヤフ・ゴールドラット，ザ・ゴール 2 ―思考プロセス，ダイアモンド社，東京，2002.
[10] 村上悟，問題解決を「見える化」する本，中経出版，

183

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Visual 開発ツール Node-RED の導入によるプロセスの変化と考慮点
阪井 誠株式会社 SRA
sakai＠sra.co.jp

要旨

提案されている．
Node-RED は Visual IoT ツールと呼ばれており[4]，サーバーサイド Javascript 環境である Node.js およびそのミ
ドルウェアである Express.js 上で動作する．Node.js はイベント駆動で動作し，いわゆるクライアント 1 万台問題が生じないと言われるほど高性能であるが，非同期処理プロ
グラミングは容易ではない．Node-RED はプログラムコン
ポーネントであるノードを線でつなぐ事で順次処理と非同期処理を簡単に記述できる．また，多様で多機能なノードが豊富にある，一瞬でデプロイが可能，といった特徴から快適で効率的な開発を実現している．すでに日本でもユーザ会のほか[5]，書籍や雑誌の記事もあり[6]，IoT ツールとしてだけでなく，Web サービスなど様々な開発が行われている
これらのツールを導入するとソフトウェア開発プロセスは大きく変わると思われる．しかし，ツールの技術情報は多いものの，プロセスの変化に関する報告は GeneXus に関して開発プロセスを変えるものとして報告があるなど[2]，
ごく一部に限られている．また，上流からのアプローチであれば開発規模も比較的大きく，コンサルタントを依頼できる可能性があるが，下流からのアプローチのツールを導入する場合は，当初は規模が小さいことが多いので外部に委託することが難しい．このことが，プロセスを大きく変えるツールの導入を難しくしている．
本論文では Node-RED によるソフトウェア開発の経験者にアンケートを行い，ソフトウェア開発のプロセスにどのような変化があったのかを調査し，その原因を考察した．
アンケートを実施した経験者の開発対象は，社内サービ
ス，プロトタイプ，テストダブル（ドライバ，モック，スタブ），
自社パッケージ，ユーティリティなどである．また，アンケートで調査した内容は，品質，コスト， 開発期間に対する選択式の評価および自由記述，要件定義，設計，プロ
グラミング，テスト，リリースに対して従来との違いについて，自由記述で行った．
以降の章では，Node-RED の概要と長所・短所，アンケートの方法と結果，考察，そして最後にまとめの順に報告する．

本論文では Node-RED を導入したソフトウェア開発プ
ロジェクトの経験者にアンケートを行い，ソフトウェア開発にどのような変化があったのかを調査した．経験者 8 人に対するアンケートの結果，品質と開発期間の評価が高かったものの，ツールの導入だけでは必ずしも効果が得られず，（１）ツールの知識やノウハウを共有すること，（２）特性を活かした設計で品質を作りこむこと，（３）実装を繰り返して常に確認すること，(4)上流から利用すること，が効果的なソフトウェア開発につながることが分かった．
プロセス改善を目的として多くの企業でツールが導入されているが，必ずしも成功していない，本研究の知見を参考に，より効果的なプロセス改善が行われることが期待される．

1. はじめに「プロセスやツールよりも個人と対話を」とアジャイルソ
フトウェア開発宣言には書かれている[1]．これはソフトウ
ェア開発におけるプロセスやツールの重要性を認めたう
えで，個人との対話の重要性を宣言したものである．特に開発言語のように成果物と直接関わるソフトウェア開発
ツールは，プロジェクトの成否に大きく影響する．このため，ツールを先に決定しておいて，経験のある開発者を採用することも多く行われている．このようにソフトウェア
開発に大きな影響を与えるので，新しいツールを導入する機会は少なく，開発プロセスに大きな影響を与えるにも関わらず，その知見はあまり多くない．
その一方で，計算機の性能向上や技術の発展によって，効率的なソストウェア開発が可能になった．上流からのアプローチとしてはデータモデリングや画面・帳票まで自動生成する GeneXus[2]，モデルをベースにプログラムのパターンを定義する事で仕様書を実行する X-TEA
Driver [3]などがある．逆に下流からのアプローチとしては，本論文で扱う Node-RED をはじめとして，高機能なシステムを簡単に作成するビジュアル開発ツールが数多く

184

SEA

ソフトウェア・シンポジウム2017 in 宮崎

2. Node-RED
2.1. Node-RED の基本
Node-RED は Visual IoT ツールと呼ばれ，Web ブラウ
ザ上のエディタでプログラミングする．左の領域にある長円のプログラムモジュールをノードと呼び，中央の編集領域に配置し，ノード間を接続してフロー（処理）を作成することでプログラミングする．ノードに名前を付加できるが，単に配置するだけでも設定に応じた内容が表示される．
最もシンプルなフローは図１のようになっている．左端がインジェクトノードでデフォルトの timestamp がセットされている，このノードの左にあるボタン部分をクリックすると，現在時刻が msg オブジェクトとして次のノードに送られる（クリックでなく，定期実行することもできる）．右端にあるのがデバッグノードで，受け取った msg オブジェクトの一部またはすべてを右側のデバッグタブに表示する（コンソール出力も可能）．インジェクトノードに文字列等をセットすることも可能だが，ここでは中央のファンクションノード
で“Hello world!”を msg.payload に代入している．
ここで，インジェクトノードの代わりに http ノード，デバッ
グノードと並列に http response ノードを接続すると，レスポ
ンスボディに“Hello world!”を返す web API になる（図2）．デバッグノードの出力であるｍｓｇオブジェクトは JSON
形式なので，コピーして別のインジェクトノードのデータとしてペーストすれば，後続の処理を手分けして開発できる．インタフェースがすべて msg オブジェクトに統一されているので，処理の変更や追加が容易なのである．
編集領域は複数のタブで構成されていて，複数のフロー間をリンクでつなぐこともできるので，大きなシステムは，タブを切り替えて開発することが可能である．フローを修正した場合は右上のデプロイボタンが赤くなり，これを押すことで瞬時に実行が可能になる．
標準で用意されているノードには，データをセットする

図 1 基本構造

図 2 Web サービスの例

185

SEA

ソフトウェア・シンポジウム2017 in 宮崎

チェンジノードや，分岐処理をするスイッチノードなどがあり，簡単なプログラムであればプログラムコードを書かずに設定だけ実装できる．また，標準ノードのファンクション
ノードでは javascript でプログラムを書くことができるほか，
フローの一部のノード群をサブフローとして一つのノードにまとめることができる．サブフロー以外にも Javascript とHTML でカスタムノードを作成できる．サブフローには入口，出口，名称以外は設定できないが，カスタムノードは標準ノードのように設定用の UI を持ち，多くのカスタムノードがライブラリとして npm(Node Package Manager)で公開されている．
2.2. 長所
Node-RED の長所をまとめると以下のようになる．

ートして，他の Node-RED 環境にクリップボードを介してインポートして簡単に利用できる．さらに，作業分担の界面にデバッグノードをつないで msg オブジェクトをダンプし，その値を設定したインジェクトノードで開始すれば繋がっていないフローを別々に開発できる．これらの方法を組み合わせると，複数人で効率的に開発できる．
2.3. 短所
Node-RED の長所をまとめると以下のようになる．
単体テスト：カスタムノードにユニットテストを組み込むことは可能だが，フローの一部をテストする標準的な方法がない．このため，フロー全体をブラックボックステストする必要がある．
発展途上：Node-RED の機能は日々進化しているが，（改善しつつあるものの）複数人で同時編集できないなど，まだ不十分なところがあるほか，一部のノードに不具合が残っている．

非同期処理が簡単に扱える：図１の様にノードを一列に並べると順次処理になる．図 2の http と表示されている http レスポンスノードと，msg と表示されているデバッグ
ノードの様に，ノードの出力を複数のノードに接続すると非同期に処理が行われる．また，配列やオブジェクトを分割して非同期処理する split ノードがあるほか，ファンクションノードから node.send()メソッドで非同期に msg オブジ
ェクトを送出することも可能である．

方式設計が重要：小規模なシステムは実装を優先しても問題ないが，多機能なシステムを小さな工数で作れてしまうので気づかないうちに複雑になり混乱することがある．規模が大きくなる場合は，従来のソフトウェア開発と同じように，msg オブジェクトや永続化対象のデータ構造
や，ソフトウェアアーキテクチャをあらかじめ設計する必要がある．

アルゴリズムが可視化される：ノードの名称とその順序で処理が可視化される．ノードに和名を付けたり，コメント
ノードでドキュメントを記述することも可能である．
多機能なノード（モジュール）：Node-RED には HTTP，
TCP，UDP，WEB ソケット，MQTT，Twitter など各種通信が簡単に行えるノードが標準であるほか，さらに多くの通信やデバイス制御，DB アクセス，SNS，BOT などが数多くノードがコントリビュートされている．中でも Dashboard というライブラリは，Web 画面を簡単に作成でき，デプロイ
なしにデータの入出力ができるので，テスト用のドライバ，
スタブ，モックなどいわゆるテストダブルの開発が簡単にできる．
デプロイが一瞬：コンパイルやビルドが不要で，デプロ
イが 1 瞬で実行できる．常に動作を確認しながら開発できるので，仕様通りに動作する部分を徐々に増やしながらインクリメンタルに開発することで，品質の高いソフトウ
ェアを開発可能である．

ループが特殊：複数のデータを処理する場合，ファン
クションノード内のループ，ファンクションノード＋
node.send()，split ノード＋join ノードなどの方法があるが，複数のノードで順次処理を繰り返す場合は，フローがループ状になるので，慣れるまではわかりにくい．
マージ・保守に工夫が必要：従来の言語のように diff
で差分をとったものを patch でマージすることができない．
このためバージョン管理が容易でない．開発環境のコードを本番環境にマージするには手作業が必要になる．

3. アンケート
3.1. アンケート方法
Node-RED を用いた開発を行っている 8 人の経験者にアンケートを行った．
各経験者は Node-RED を用いて社内サービス，プロト
タイプ，テストダブル（ドライバ，モック，スタブ），自社パッ再利用が容易：カスタムノードやサブフローによるモジュール化のほか，Node-RED 内でフローの一部をコピー＆ペーストできる．また，フローの一部や全体をエクスポ

186

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ケージ，ユーティリティなどを開発している．全てのプロジ
ェクトはいわゆるウォーターフォール型開発の工程を持っていたが，ばらつきはあるものの厳格な工程完了の審査は行われていない．Node-RED は生産性が高いことから選択された．
アンケートはメールで依頼し，いわゆる QCD とプロセスの変化をアンケートした．品質，コスト， 開発期間に対しては 4 段階の選択式（重複選択可）の評価と自由記述でアンケートした．従来のプロセスとの違いは，要件定義，設計，プログラミング，テスト，リリースに対して自由記述
でアンケートした．
3.2. アンケート結果
品質，コスト，開発期間のアンケートは選択肢毎の比率を集計し（図 3），コメントを確認した．複数選択を許しているので，合計は 100％でない．評価は総じて良かったが，複数選択なので評価の良かった点だけでなく，
Node-RED の問題点も明らかにすることができた．
図 3 品質，コスト，開発期間のアンケート結果

品質に対して評価が良かった理由は以下のような内
容だった．







サクサクと実装，実行，確認・修整の作ってのループが良かった内製にこだわるよりも品質が良い
コード量が減った
試作に有効
非同期処理が容易（promise は間違いやすい）
フローを意識してシンプルな作りになった

図 4 プロセスの変化のアンケート結果

このようにデプロイが一瞬，高機能，ビジュアルなど
NodeRED の長所が品質に対して評価が高かった．逆に評価が低かった理由は以下のような内容だった．






設計からテストまでシームレスにでき効率が良い
処理部に注力できた
このように長所が評価された．逆にコストに対して評価が低かった理由は以下のような内容だった．

単体テストができない
コード検索ができないのでバグが見つけにくい

これらはマイクロサービス化などの工夫はできるものの，
Node-RED の短所が品質に影響を与えていたと考えられる．バグがほとんどなかったとしている回答者も 2 名いる
ので開発プロセスの違いが大きいと考えられる
コストに対して評価が高かった理由は以下のような内
容だった．








diff が取れない
ドキュメントが少ない
必要なノードを探すのに時間がかかった
繰り返し処理に苦労した

Node-RED の短所が指摘されたが，下の 2 つは知識やノウハウを共有することで改善できると考えられる．
開発期間に対して評価が高かった理由は以下のような内容だった．

非同期処理が容易
高機能なコンポーネントが多い

187

非同期処理が容易

SEA

ソフトウェア・シンポジウム2017 in 宮崎








カスタムノード作成で効率化できた開発のスピード感が半端ない
他の人のフローを簡単にインポートできる
実装にいきなり入れる
効率よく開発できる
大きな手戻りがなかった

確認していたプロジェクトの評価が高く，そのような実装を進めないと詳細仕様を決め難い開発に向いていると考えられる．ただし，データの定義やアーキテクチャはしっかりと設計する必要がある．
4.2. プロセスの変化
プロセスの変化に関しては，上流はポジティブな評価だったが，プログラミング・テスト・リリースに関しいては評価が拮抗するかやや低評価，保守に関してはネガティブな評価のみがあった．
上流に関してのポジティブな意見は以下のようなものであった．

ここでは品質で挙げられた点のほか，インポート・エク
スポート，常に動作させることで高品質ななること，が挙げられた．逆に開発期間に対して評価が低かった理由は以下のような内容だった．


自作部分の作りで効率や保守性が変わる
ドキュメントが少ない
品質の悪いノードがあった
必要なノードを探すのに時間がかかった







ここではサブフローやカスタムノードなど再利用の仕組
みをどう使うか，あるいは全体の作りなど，Node-RED に適した設計が重要であること，発展途上のツールであることなどが指摘されたプロトタイプが早くできると説明も早く，意見を貰いやすい
曖昧な要求でもとりあえず作り始めることができる作ったものから要件を確定していくことが可能
大まかな処理の流れをすぐにフローとして実装可能
設計とプログラミングのイテレーションが容易

このようなコメントをした回答者は，設計以降の問題を指摘しながらも，全体としては好意的な表現であった．具
体的には，以下のような内容だったプロセスの変化は，自由記述で書かれた内容からネガティブ評価，ポジティブ評価，変化なし（およびどちらともいえない）の 3 段階を判断して集計した（図 4）．上流においてプロトタイピングが可能な点に対して評価が高かった反面，プログラミング，テスト，リリース，保守に関して
は管理面の課題が多く挙げられていた．プロセスの変化の詳細は考察で検討する．






4. 考察


4.1. 品質，コスト，開発期間
アンケートの結果，特に品質と開発期間に対しての評
価が良かった反面，コスト面ではある程度の経験が必要であることが指摘された．
Node-RED は高機能なノードを組み合わせて，とりあえ
ず動かすことが簡単．デプロイも一瞬なので作りながら設計と実装を進めると，品質が確認されたフロー（処理)を増やしていくことができる．その反面，単体テストができな
い，コード管理が困難であるなどツールの特性を理解する必要があり，それがアンケートに反映されたと考えられる．
プロジェクト毎の特性で見ると，知識が不足している回答者を除くと，要件が曖昧で実装しながら詳細な仕様を

Inject ノードにより，実装したフローをすぐに動作させやすく，デバッグノードでの確認も容易
flwos.json（Node-RED の保存ファイル）などほんの少数のファイルをリリースするだけでよく，管理しやすい
ユニットテストはカスタムフローや API 単位しかできないが，不安は少なかった
コード管理系だけどうすれば・・・Node-RED だけで開発環境になればすばらしいものになりそう（保守は）基本的に容易だが，開発環境を残しておかないと詳細な内容を確認し辛かった
ユニットテストはカスタムフローや API 単位しかできないが，不安は少なかった

それ以外の設計以降でネガティブな表現をした回答
者は，上流のプロセスに変化がないとしていた．また，
QCD の項目で良い評価とされていた内容を書きながらも，
Node-RED 流の開発スタイルをつかみ切れていない様子
であった．




188

単体テストをどのように行うのかわかりませんでした
複数人数での開発が少し手間取る
外部リソースのノードの設定が外だしに出来なくて，

SEAソフトウェア・シンポジウム2017 in 宮崎

リリース後にとても煩わしかった
Node-RED の癖にあわせた設計は必要．設計次第
簡単な反面，リリース後の不具合も増える可能性がある
コード全体の検索が出来ないため，複雑なシステムは保守しにくくなるでも当てはまる」と信じる人が実に多い．”と書かれている[7]．ソフトウェア開発ツールにはそれぞれの特性があり，よく理解したうえでふさわしいプロセスで利用しないとその効果を十分に得ることはできない．本論文の結果は，要件が曖昧で高い生産性が求められるプロジェクトに適した Node-RED という 1 ツールの導入に関しての調査結果から得られたものであるが，このような視点は他のツールにも重要である．
近年，アジャイル開発の再定義の一つとして注目されているモダンアジャイル[8]は次の 4 つの基本理念によって定義されている．

これらから，Node-RED を利用する場合は，上流から実装を開始する．特性を理解して設計する．動作をきちんと確認しながら作り上げる．といったことが必要だと考えられる．
4.3. Node-RED の特性と結果






以上のことをまとめると，実装を進めないと詳細仕様が決め難いプロジェクトに有効であり，その実施には以下のような点が重要であると考えられる．


人々を尊重する
安全な状態を前提とする
素早い実験と学習価値を継続的に届ける

今回調査したプロジェクトは一定期間のタイムボックス管理を行う一般的なアジャイル開発ではない．しかし，アンケートの結果から得られた知見は，モダンアジャイルの基本理念と通じるものであり，Node-RED がソフトウェア開発のアジリティ（機敏さ）を高めるものであると考えられる．
今後も Node-RED を利用するプロジェクトを増やして，そのノウハウを蓄積するとともに，より良いプロセスに関する知見も増やしていきたい．

ツールの知識やノウハウを共有すること特性を活かした設計で品質を作りこむこと実装を繰り返して常に確認すること
上流から利用することプロセスの視点でいうならば，Node-RED を導入する
場合は，他のツールと同じように情報共有や教育が重要であるだけでなく，既存のプロセスをそのまま適用するのではなく，積極的に変更することが，プロセス改善につながると考えられる．

謝辞

5. おわりに
アジャイルソフトウェア開発宣言には「計画に従うことよ
りも変化への対応を」と書かれている[1]．新しいツールや技術を導入するには，従来通りのプロセスのままでは難
しく，適切に変化させなくてはならない．
本論文では Node-RED によるソフトウェア開発の経験者 8 人にアンケートを行い，ソフトウェア開発プロセスにどのような変化があったのかを調査し，その原因を考察した．
アンケートの結果，新しいツールを導入する際には単にツールを利用するだけでなく，ツールの知識やノウハウを共有して特性を活かした設計を行い，実装と確認によって品質を上流から作りこむなど，主体的にプロセスを変更することが，プロセスの改善につながっていたことが分かった．また，Node-RED は発展途上であるので，バージョンアップのフォローも必要になるであろう．
書籍 「ソフトウェア開発 55 の真実と 10 のウソ」には，“ソフトウェアの世界には，「一つのツールや技法が何に189

アンケートのご協力いただいた西根さん，陣内さん，
奥嶋さん，澤本さん，畑中さん，中島さん，佐々木さんに感謝いたします．

参考文献[1] Beck 他 ， ア ジ ャ イ ル ソ フ ト ウ ェ ア 開 発 宣 言 ，
http://agilemanifesto.org/iso/ja/manifesto.html，
2001．
[2] 松山, 鯵坂,飯ヶ谷, 情報システム開発におけるソフ
トウェア資産の上流シフトへの対応, ソフトウェア・シンポジウム 2016 in 米子, 2016.
[3] 渡 辺 ， X-TEA Driver ， デ ィ ー ビ ー コ ン セ プ ト ，
http://dbc.in.coocan.jp/xeadDriver.html，2004..
[4] JS Foundation，Node-RED is a visual wiring tool for
the Internet of Things，https://nodered.org/．
[5] Node-RED User Group Japan https://nodered.jp/，

SEAソフトウェア・シンポジウム2017 in 宮崎[6] 桑野，ブラウザでお絵描き I/O!Node-RED で極楽コンピュータ・プログラミング (インターフェース
SPECIAL)，CQ 出版，2016.
[7] Glass, ソフトウェア開発 55 の真実と 10 のウソ, 日経
BP 社, 2004.
[8] Smith, Agile 2016 Keynote: Modern Agile,
https://www.infoq.com/news/2016/08/agile2016-mod
ern-agile, 笠原，Agile 2016 の基調講演: モダンアジ ャ イ ル , https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile, 2016.

190

SEA

ソフトウェア・シンポジウム2017 in 宮崎

テストの遊び場を作ったら、一緒に遊びますか？
浅井 真樹子株式会社 ワークスアプリケーションズ
asai_m@worksap.co.jp

き，開発者や製品に貢献できるようになる．そういう活動ができる場所を作ってみたら楽しく学べ，ソフトウェアテス
トとソフトウェア製品の役に立つのではないかというのが今回提案するアイデアだ．
具体的な活動イメージの一つを紹介する．

要旨
テストの遊び場は，ソフトウェアテストに関する色々な技術のスキルアップを目的に，泥まみれになって遊べる
体験型の場所があったら楽しそうだというアイデアである．
ソフトウェアテストの発展への貢献と世界中のエンジニアと交流できる可能性を秘めている，私にとっての野望でもある．

2. こんな悩みはないだろうか？
テスト設計や自動テストを始めたいが，どのように始めたら良いか分からない．
テスト設計について情報はたくさんあるが，どの手法が自分に適しているのか分からない．
網羅的にテストして保証したいが，どこまでやればい
いのか分からない．
テストの目的に対して，実施しているテストが妥当なのか，十分なのか心配だ．
品質指標の妥当性が分からない．
新たな手法に取り組んでみたいが，失敗したら困るのでチャレンジできない．
他社の事例を参考にしたが上手く扱えなかった．
自社の状況を公開できないので適切なアドバイスをもらえない．
などといったことに悩んでいないだろうか？今現在はなくても，過去に悩んだことはないだろうか？

1. はじめにテストはとてもクリエイティブでプロフェッショナルな楽しい仕事なので，もっとスキルアップしたい！しかしお勉強
スタイルで学習するのはツラいし限界がある…．と考えていたとき，ふと思いついたのが泥んこになれるテストの遊び場である．
テストの遊び場は，リスクフリーで，自分で考えたことや色々なメソッドを実験でき，みんなで交流することでフィードバックがもらえる場所．
ソフトウェアテストの活動は，要求分析，計画，設計，実施，バグ報告，管理や分析，自動テストなど，多岐にわたるが，テストの遊び場ではテストに関するあらゆるものを自由に扱いたいので，敢えて「テスト」とだけ称している．
扱う対象は幅広く自由に選択するが，現物を入手しやすい対象を 1 つ選択して複数人で扱うことを想定している．これは 1 つの対象を共通に扱うことで，比較したり客観的に評価したり具体的にアドバイスしあうことが可能になり，オンライン・オフラインの垣根なく議論でき，空中戦になりにくいと考えたからだ．
参加者は初心者から有識者まで，色々な立場でソフト
ウェアとその品質に携わる有志に集ってほしい．

悩みや疑問を解消したくても，時間がない，知識がな
い，相談できる有識者がいない，予算がない，試しにやってみて失敗できる状況ではない，など色々な障壁があり，なかなか解決の糸口を見い出せないということはないだろうか？
こうした悩みに対して，失敗してもリスクがなく自由に実験でき，体験を通して自らに適した解決の方法を見つけ出せるのがこの遊び場だ．

自分の腕を試し，色々なエンジニアと交流して腕を磨

191

SEA

ソフトウェア・シンポジウム2017 in 宮崎

3. テストの遊び場での遊び方

4. さいごにテストの遊び場でテストに関わるあらゆるものを自由に扱うことは前述の通りだが，具体的にイメージしやすいよ
うに，テスト設計を対象に例を示す．

遊び場での体験を通して，自分の悩みが解消し，自分の強みを確認でき，興味の対象や思考パターンなどが分かる．色々なメソッドの使い方や優れている点を，実際に体験しながら，ときに失敗しながら学べる．悩みを率直に語り合うことができ切磋琢磨できる．

まずはテストの対象を決める．これは既に公開されていて，誰もが入手して使えるものにする．例えば「ブラウザのテスト」をすると決めた場合，どのブラウザを対象にするのかを検討して選択する．今回は Google Chrome を対象にすると決めたとする．
次にテストの手法やテストする範囲を決める．既に出荷されている製品なので，外部仕様に対するブラックボッ
クステストをやることにしてみる．
さらに Google Chrome のどの機能を対象にするのか検討する．Google Chrome には設定や画面の表示や検索などの他に Google Chrome 上で動作する色々なサービスやアドオンが提供されているので，各機能をどのような単位で集めるかまたは分解するかを検討する．例えば検討の結果を元に機能一覧を作ってみるだけでも対象製品の特性に対する理解が進み，各自のこだわりや思考パターンにも気づけることだろう．
テストするのに扱い易い単位が作れたら，どういうメソッドを使ってテストを設計してみるかを検討する．自分が普段使い慣れている手法を披露したり，新たな手法を取り入れてみたり，試してみたい手法について参加者同士でアドバイスしたりすることもできるだろう．

活動を通して生まれた成果物は共有でき，ナレッジとして蓄積されることで色々な立場でテストに携わる人々のテスト活動に貢献できるし，開発にフィードバックすることもできる．どんな学びをどれほどたくさん持ち帰るかは参加者の自由だ．
会社や対象ドメインの垣根を超えて，より具体的な体験を通して学びを得る．
そういう遊び場があったら，一緒に遊びたくなるだろう
か？どういうテストだったら一緒に遊びたくなるだろうか？
遊び心をもって真剣に取り組む．そこからクリエイティ
ブでプロフェッショナルな楽しいテストに出会えるのではないだろうか．

参考文献なし

こうしてテストを設計する過程で色々な学びを得られるのはもちろんだが，実際にバグを見つけたら当該製品の開発者にフィードバックすることもできるし，バグをナレッ
ジとして設計にフィードバックすることもできる．
テスト設計に入る前に目的を明確化したり，計画を作成したり，メトリクスを定義しても良い．テスト設計の成果物を元に自動テストを書いてみることもできるし，テストケ
ース作成を練習してみても良いし．また作成したテストケースを用いてテストを実行してみるのも良い．
どういう遊び方をするにしても，手元で扱える対象をみんなで共通に扱うので，個別具体的に議論できるので成果を得やすいのがポイントだ．

192

SEA

ソフトウェア・シンポジウム2017 in 宮崎

エンジニア人材を死滅させるマイクロマネジメントの打破〜エンジニアを活かし育てるトリセツ活動の提案〜
松尾谷徹
デバッグ工学デバッグ工学研究所
matsuodani@debugeng.com

要旨と扱い方＝「トリセツ」(取扱説明書) を明らかにする必要がある．

企業の IT 関連職場において，エンジニアの悲痛な叫

ソフトウェア以外の伝統的な機械や電気の分野においびを聞くことが増えている．叫びの多くは，日々の仕事ては，エンジニアを貴重な人的資源とし，雇用側はそのとして，その活動の意味が見いだせない無駄な作業に忙活躍の場と処遇を一般的な雇用者とは区別して提供し，殺されていることから生じている．現代の若者に我慢が育成している．何故ならば，彼等の貢献によって製品や不足していると切り捨てる管理職も存在するが，決してサービスの価値を高め，企業や組織を維持発展させていそうではない．

るからである．

エンジニアは，製品やシステムやサービスにおいて，日本におけるソフトウェア産業は，歴史的な経緯から維持するだけでなく付加価値を生み出すことが求められエンジニアも含め人的資源を消費原料的な作業工数としている．その原動力はクリエイティブな人的資源によるて取り扱ってきた．管理（監督）の現状は，非熟練者に創造的な工夫や変革であり，規範的なプロセスの遵守だ

よるマニュアルに沿った作業の監督と位置付け，量的生

けでないことは明白である．

産性，品質の底上げ，納期遵守といった低レベルの管理

しかし，多くの職場レベルのマネジメントは規範的なに留まっている．

側面が詳細に強化され，厖大な手続き的な作業を押し付

では，どのようにしてこの慣習的な問題を解決して行けるマイクロマネジメントが蔓延している．結果的に，

くのか．ここは次の項目に分けて考える．

付加価値を生まない活動にクリエイティブ人材を投入することになり，付加価値が生まれないばかりか，人材を

1. 現状の認識と対策としての見える化

疲弊させ，組織自身をも衰退させている．この現状を明

2. マイクロマネジメントの原因と対策

らかにし，この流れを断ち切るための提案を行う．

3. あるべき姿に対するコンセンサス
4. 現実的なトリセツのテーラリング

1. はじめに
2

この主張は，エンジニアの地位獲得を進めようとするものであるが，経済的な地位など利己的なものでは無い．
現代のエンジニアに求められているパフォーマンスを発現状の認識と見える化
大手広告企業における悲しい事件をきっかけに，企業の職場における管理の問題が明らかになりつつある．顕揮し，社会や組織に貢献するために，雇用主や社会に求在化した問題とは労務管理の最低限のレベルである労働めるものである．エンジニアが付加価値生産性を高める

時間ですら長年に渡って違法状態であり，それを自律的クリエイティブな成果を出すには，自由な発想と試行錯に改善出来なかったことである．事件は，超過した労働誤が必須であり，それをサポートするエンジニアの処遇

時間が原因ではなく，クリエイティブな人材に対する管

193

SEA

ソフトウェア・シンポジウム2017 in 宮崎

理規範＝トリセツが未成熟で，封建時代の滅私奉公のよの実現性は高い．

うな主従関係の考え方に近い人的資源管理に本質的な原

職場の状況を客観的に見える化するための計測手段と因がある．

して，質問紙，分析ツールなどを作成するのはさほど困識者が指摘するように，本質的な問題は２つに分類で難ではなく，実績もある．実際の運用方法については検

きる．１つは組織の末端における職場が閉鎖的であり，討が必要で，匿名で第三者が行い，人事評価など意図し未熟な管理が行われてもそれを検知し回避することがでない利用による弊害を防ぐ必要がある．

きないことにある．逆に隠ぺいし悪い方向に強化されて事例もある．

3

マイクロマネジメントの原因と対策

もう１つは，末端の職場で異常な管理を行う者の管理規範にある．多くの場合は，管理に関して未熟な者が独

なぜマイクロマネジメントのような不適切な管理が自善的な考えで管理行為を行うことにあるが，その職場や然発生的に多発するのかについて考える．マネジメント

組織において慣習化している場合もある．

の中に人的資源のパフォーマンスを高め育成する機能が，

この項では，職場の閉鎖性について考える．問題が顕重要な要素として含まれていることを否定する者はいな

在化するのは，事件となった場合や，パワハラとして強い．しかし，末端の職場において大義名分的な育成機能

い被害を受けた者が訴えた場合など，かなり悪い状況でより，日常の習慣的な管理機能が優先され結果として逆ある．この現象は，大学ではアカハラであり，家庭ならに人的資源のパフォーマンスを抑圧するケースが生じてDV である．現実として，これらのパワハラ類は顕在化に至らないが潜在的な状況を含めると，閉鎖的な主従関いる．習慣的な管理機能とは，進捗報告や予実管理，コ係において多発しており，根底には上司部下の関係を封チャレンジ的ではな実態は実効性の低い文書作成と打ち建的な身分関係と誤解している国民的な未熟から生じて合わせに忙殺される．

ンプライアンスや QCD 関連のレビューなどであるが，おり，簡単に解決できない問題である．

問題を起こす管理・監督者の多くは，人的資源管理のよって，国民性を変える前に，職場における過剰な閉職務に対して未経験でかつ専門的な知識も訓練も受けて鎖性を減らし，問題の兆候を検出する仕組みが必要であいない場合が多い．具体的には，エンジニアが職位が上る．いじめ事件などの事例では，組織側は隠ぺいの意図

がり，未経験の管理・監督の職務に就く場合である．常が強く，組織側の調査結果はでは「いじめは無かった」

識的に考えると，高学歴で社会人となりそれなりの実務となり，後から第三者による調査（アンケートや聞き取を経た者が，マイクロマネジメントのような稚拙な行動り）で深刻な状況と兆候があったことが明らかになるこに走るとは考え難い．何らかの原因が存在するのではな

とが多い．

いか．

見える化の手段としては，簡便な調査紙によるアン原因として考えられるのは，管理・監督の職務を身分ケート調査から，心理測定尺度の研究で明らかになった的な地位としてとらえ，君主的で指示命令すること＝管構成概念を用いてその構成因子ごとの得点と，ビッグ理者と考える時代錯誤的な勘違いである．経営学におけデータを用いた判別分析（AI 技術）を行う方法が考える人的資源管理の基礎知識からしても，現代ではあり得られる [1, 2]．

ない管理規範ではあるが，パワハラやアカハラの原因因IT 分野においては，JISA の援助を基に 2001 年に実子としては強い．

施したエンジニアのパートナー満足調査（PS 調査）がでは，何故このような稚拙な思い込みに走るのか．そある [3]．この調査は IT 系のエンジニア約 1500 名に対の原因は，職場の閉鎖性にあるのではないか．配属後，して主に「仕事満足」の観点から分析した [4]．閉鎖性

その職場一筋ですごし，社外の学会や業界どころか，社の打破のためには，これに加えて「不満足」の観点を追

内の他部署とも社会的なつながりを持たないため，常識加する必要がある．

的な社会経験が無く，未成熟で独善的な行動に陥ると考もう一つのひな形は，職場のリーダシップ研究で良くえられる．

知られている「PM 理論」から，エンジニアが強い「不次項のあるべき姿とは分けて，人的資源管理の前提と満足」を生む因子を探る方法である [1, 5]．
「苦手な上司しての「トリセツ」が必要である．ベからず集のような／良かった上司」の比較研究も行われており，この方法

事例と対策的なものや，人を扱う管理への入門書的なま

194

SEA

ソフトウェア・シンポジウム2017 in 宮崎

とめ方が考えられる．

好奇心であり，これが欠如している職場では，チャレン
ジ精神が疲弊しクリエイティブ活動が芽生えない．この

4

あるべき姿を求めて「寛容性」「開放性」を柱にして，日本的な価値観である「育成」「チーム」などを加えた概念を想定している [9]マイクロマネジメントのようなとんでもない状況とは別に，目指すべきトリセツについて考える．理想ではな

5

現実的なトリセツ

く，現実的な姿としては，先行する成功例から学ぶ必要がある．理想とは演繹的な規範から導かれるもので，教トリセツについて，3 項ではトリセツ以前の課題につ

科書的な美しい姿である．現実的な姿とは，事例などでいて考え，4 項ではあるべき姿について考えた．ここで実証されたものを意味する．具体的には，客観的な計測は，実際にトリセツを展開する局面について考える．展

や，実際のチームやプロジェクトの事例を基にした取り開する局面とは，展開対象の職場や組織の状況を考慮し，組みである [6, 7]

さらに既存の目指す考えも取り入れテーラリングを行う

ソフトウェアエンジニアのドメスティックな特徴もあ局面である．

るが，大きな括りでこの問題を捉えると，クリエイティ

テーラリングの概要を図 1 に示す．テーラリングのたブな活動と生産活動との対比問題と見ることができる．

めの情報は，トリセツを展開する職場や企業に適合させ

クリエイティブな活動が 21 世紀の産業を牽引しているるためのもので，２つの要素が考えられる．1 つは，貢ことは，多くの賢者が述べており，産業界においても献目標と示したもので，企業や社会で既に認められたエ

Google，Amazon など 21 世紀に躍進した多くの企業でンジニアの倫理やコンピテンシー（行動特性）である．

実証されている．この分野における先進的な考え方は，雇用側からすれば，トリセツの前提となるエンジニアのリチャード・フロリダによるクリエイティブ・クラスの義務や組織への貢献に関する期待（要求）である．

中の Super-Creative Core が近いと考えている [8]．

具体的な内容としては，企業であれば採用要件として「トリセツ」が目指す方向は，組織がクリエイティブ

求めるエンジニアの資質であり，その内容は「チャレンな成果を出すための人的資源管理をステークホルダに解ジ精神」「やる気」などと表明されている．これらを汎りやすく示すことにある．ステークホルダとは職場を含用化すると，エンジニア倫理であり，現代において高い

め経営層や関係する顧客などを指す．具体的な「トリセ支持をうけているのは IEEE の Software Engineering

ツ」は，時代や状況によって変化するので，変化に対応

Code of Ethics である [10, 11]．
現実的なトリセツへの反映は，エンジニアの義務の確認である．これらの倫理が達成されているからこそ，して行く必要がある．あるべき姿は，抽象的であるが基本となる考え方に他ならない．
経済成長の実証研究から，成長に必要な要素が明らか

エンジニアにクリエイティブな成果を期待し，良い処遇になっており，それらのほぼすべては人的資源に関するものであり「才能」「寛容性」「経験への開放性」などが指摘されている [8]．
「才能」とは，スキルと野心であり，具体的には高学歴でかつチャレンジ精神を持つ人的資源である．多くの企業の採用基準であり，これは達成されている．
「寛容性」とは，多様性を認めることであり，エンジ
ニア側からすると自由度である．陳腐化の早い分野において技術を維持して行くには，論文を読み，学会などの情報源に参加し，考え試して技術習得を自律的に行うための自由が必要不可欠である．管理・監督側は，その自由度を認め確保する寛容性が必要である．マイクロマネ
ジメントは，これに逆行している．

図 1: トリセツのテーラリング「経験への開放性」とは，新しい技術や経験に対する

195

SEA

ソフトウェア・シンポジウム2017 in 宮崎

参考文献（トリセツ）を提供する．
もう 1 つは，対象とする職場の成熟状態である．マイ
クロマネジメントなど未成熟な状態と，クリエイティブ[1] 堀洋道，吉田富二雄，“心理測定尺度集 ii,” 2001．

な活動が進行している状態では掲げるトリセツの内容は変える必要がある．具体的な内容は，テーラリングによ[2] 松尾谷徹，“It に現場力は存在するのか: その計測と評価の試み,” ソフトウェア・シンポジウム，pp.1–8，
2014．

り職場の状況に合わせて解りやすく現実的な表現にする必要がある．
トリセツの内容自身は職場によって多少変化するが，エンジニアが主体的に働く原動力は，外発的報酬ではな[3] 松尾谷徹，“パートナー満足 (ps) と人的リソースのく，内発的報酬であることを理解する必要がある．IT 系

パフォーマンス,” プロジェクトマネジメント学会

エンジニアの内初的報酬は，満足度調査の結果から次の誌，vol.4，no.1，pp.3–8，2002．

通りである [4]．

[4] 榎田由紀子，松尾谷徹，“Happiness & active チー
ムを構築する実践的アプローチ: チームビルディン• 仕事から得られる「やりがい」• 自律的な工夫や進め方の自由「柔軟性」

グスキルの開発 (¡ 特集¿ コミュニケーション・マ• キャリアパスや自己成長「安定性」

vol.7，no.1，pp.15–20，2005．

ネジメント),” プロジェクトマネジメント学会誌，• 同僚からの敬意や良いチーム「仲間」

6[5] 三隅二不二，“組織におけるリーダーシップの研究(リーダーシップ–集団過程の社会心理学 (特集))–(現
実の集団におけるリーダーシップの研究),” 年報社

おわりに会心理学，vol.14，no.11，pp.63–90，1970．

日本のソフトウェア産業は，1980 年代から高学歴のエンジニアを長年に渡って雇用し活動してきた．しかし，世界的な IT 技術やサービスの進歩と比べると，相対的[6] “感動するチーム,” http://itpro.nikkeibp.co.
jp/article/COLUMN/20090525/330593/．

には衰退していると認めざるを得ない状況にある．その[7] 増 田 礼 子 ，“混 成 チ ー ム に お け る チ ー ム 力
向 上 の た め の 三 者 ヒ ア リ ン グ 活 用 事 例,”

一つの原因は，極端な例であるがここで取り上げたマイクロマネジメントのような，エンジニアに対する人的資源管理の稚拙さにある．

https://www.juse.jp/sqip/symposium/archive/2015/day2/files/ronbun_B3-4.pdf．

その原因は，職場の閉鎖性や封建的な主従関係と真面
目な国民性から生じており，改善されるどころか維持さ[8] 井口訳リチャード・フロリダ，“新クリエイティブ
資本論,” 2014.12．

れ強化すらされている．海外では，エンジニア倫理とそれに答える雇用側の処遇が，社会習慣として定着している．エンジニア倫理については，我が国でも多くの識者[9] 森本千佳子，“プロジェクト成功のためのコミュニが論じているが，雇用側の処遇＝人的資源管理について

ケーション・ファシリテータ活用,” プロジェクトマ

はあまり議論されていない．

ネジメント学会誌，vol.14，no.4，pp.23–28，2012．

ここでの提案は，エンジニア倫理を持つエンジニアに対する，企業や社会のエンジニアに対する処遇改善であ[10] “Software
engineeringcodeofethics,”https://www.computer.org/web/education/

る．どっちが先かと言う鶏と卵の議論もあるが，後者が不足していると考えている．ここでの提案は，閉鎖性を

code-of-ethics.

打ち破るための見える化，エンジニアを指示命令で使う[11] “ソ フ ト ウェア エ ン ジ ニ ア の 倫 理（ 翻 訳 ）,”http://ethics.acm.org/wp-content/uploads/

リーダーシップは長期的な成果を生まない，良い人的資源管理のプラクティスを実証主義で積み上げる，実践には職場の現状に応じてカスタマイズが必要，などである．

196

2016/07/SE-code-jpn.pdf?60549e．

SEAソフトウェア・シンポジウム2017 in 宮崎

TPI NEXT による現場主導のテストプロセス改善を支援するための手法の提案
高野 愛美 河野 哲也
株式会社日立製作所{manami.takano.pj，tetsuya.kouno.cb}@hitachi.com

山﨑 崇
株式会社ベリサーブ

佐藤 徳尚
日本ナレッジ株式会社

takashi.yamasaki@veriserve.co.jp

norihisa-sato@know-net.co.jp

要旨

理解ができずに，改善策の検討が難しい．
2 つ目は，改善項目が多く，優先順位の判断が難しい，とい

本報告では，TPI NEXT[1]による現場主導のテストプロセス

う問題である．TPI NEXT が改善の指針として提供するクラスタ

改善を進める際に現場のチームが陥りやすい問題に対して支セットにより大まかな改善スコープを特定できるが，詳細な改善援するための手法を提案する．TPI NEXT による現場主導のテの優先度は現場チームの状況により判断が必要である．そのストプロセス改善で陥りやすい 2 つの問題，１）チーム内で現状ため，同じスコープ内の改善項目が多い場合，優先順位の判のテストプロセスを共通理解していないため，改善策の検討が断が難しい．

難しい，２）改善項目が多く，優先順位の判断が難しい，に対し

3. 問題解決のための手法の提案て支援するための 2 つの手法，１）現状のテストプロセスを可視化するための PFD[2]の活用，２）一定の指針による改善項目の2 章で述べた 2 つの問題に対して，2 つの手法を提案する．

絞り込みを提案する．また，現状のテストプロセスを可視化する

1 つ目は，現状のテストプロセスを可視化するための PFD の対象を判定するために，TPI NEXT のチェックポイントがプロセ活用である．PFD により現状テストプロセスを可視化することで，ス表現できるかどうかを整理した結果を報告する．

チームが現状のテストプロセスに対して共通理解し，改善策の

1. はじめに検討を行えるようになる．また，可視化する対象は，チェックポイ
ントを基準にプロセス表現しやすいかどうかで判断する．このた

近年，テストプロセス改善技術への関心が高まっており，導め，各チェックポイントがプロセス表現できるかを整理し，その結入する企業が増加している[3]．我々ソフトウェアテスト技術振興

果を PFD 化の指針として提供する．

協会 テストプロセス改善研究会では，テストプロセス改善モデ

2 つ目は，一定の指針による改善項目の絞り込みである．各

ルである TPI NEXT を取り上げ，現場主導のテストプロセス改チームメンバが TPI NEXT によるアセスメントを行い，その結果善を支援するための研究を行っている．

のばらつきを指針として改善項目を絞り込むことで，優先順位

本報告では，TPI NEXT による現場主導のテストプロセス改の判断ができるようになる．チーム間で評価結果がばらついた

善を進める際に陥りやすい問題を支援する手法を提案する．

チェックポイントは，プロセスが暗黙的であると考えられ，これらは可視化することで作業や成果物の抜け漏れの防止などの改

2. TPI NEXT による現場主導のテストプロセス
改善で陥りやすい問題

善が見込めるため，優先的な改善対象とする．

参考文献
TPI NEXT は，現場主導で取り組みやすいテストプロセス改[1]

善モデルであるが，コンサルタントなどの支援を受けずに現場のチームだけで，テストプロセス改善に取り組む場合，スムーズに改善を進めることは難しい．TPI NEXT によるテストプロセス
改善を進める際に陥りやすい 2 つ問題を示す．
1 つ目は，現状のテストプロセスを共通理解していないため，改善策の検討が難しい，という問題である．TPI NEXT は，改

[2]
[3]

善策の検討において，現状のテストプロセスの可視化には言及していないため，TPI NEXT の枠組みのみでは，現状の共通

197

Vries,G. D. et al., TPI Next Ⓡ :Business Driven
TestProcess Improvement, UTN Publishers. (薮田ほか(翻訳), TPI NEXTⓇビジネス主導のテストプロセス改善, 株
式会社トリフォリオ)
清 水 吉 男 ， PFD(Process Flow Diagram) の 書 き 方 ，
http://soft-koha-hp.la.coocan.jp/process/PFDform3.pdf
河野ほか，パネルディスカッション：普及が始まったテスト
プロセス改善技術導入・実践着手のために考えるべきこと，ソフトウェアテストシンポジウム 2017 東京, 2017

SEA

ソフトウェア・シンポジウム2017 in 宮崎[Future Presentation] 道徳性向上後の行動におけるアラートシステム
阿部 敬一郎*１*2

中谷 多哉子*2*１

東筑紫短期大学*2

要旨
道徳教育支援システムの一部である，高次な道徳的行為の発現を促すためのタスク管理システムを提案する．
既存のクラウドサービスを使用し，教師と学生，学生と学生とで学内外での実践とその達成率を可視化する．

1. はじめに「情報倫理」の研究は我々の生活で一般的なことである．しかしながら文書化されたルールや倫理では，世界のあらゆるシチュエーションをフォローしきれない．規則にないことは何をしても許されるという考えは危険である．
ルールや倫理のリストを作ることがなくても，物事の善し
悪しが議論できるためのサポートに，成人向け道徳教育が必要であるとする．
しかし成人に道徳の教育をすることは容易ではなく，成人向けの道徳教育の成果を研究する例も殆ど無い．
本研究は卒業までという時間の中、社会に出る前の大学生の道徳教育方法を作る挑戦をする．大学生への道徳教育の定義を，『①学生自身が高い道徳性の考え方を理解し，②高い道徳性で議論し，③高い道徳性を実社会で発動し，④それを認識するまでが含まれる』とした．論文[1]の中で①～②は成功することができたが，③の道徳性の高い行動の発動と④の認識に課題が残った．
ジャック J. フィリップス[2]が教育・研修の成果をまとめるシート類を参考にし，「アクションプランワークシート」を作成した．高次の道徳性を意識して行動の計画を立て，振り返りによって高次の道徳性の発動を認識できる．目標を立てるのは上記①②の直後の教室なので，教師や学生同士のアドバイスにより高次の道徳的意識はある．
つまりタスクも計画された時点で，高次な道徳性によるものと言える．
タスク管理は次の 2 点で道徳教育に効果的である．１
つは道徳的行動には発動の制限が厳しくないため，忘れがちである点である．公の場において発動目標を立てることで，意図的に行動を取れる状況を設定できる．2 つは高次な道徳的意識を促せることである．道徳的行動は意識の持ち方で高低が変わる．タスクを先生や学生同士で共用することで，決めた行動を取るだけでなく，行動意

放送大学大学院

識に高い道徳性を気づかせる環境に置ける．
具体的な道徳的行為であるが，現段階において判断できる行為は限られている．執筆者の勤務する大学における「建学の精神」の一部，「勇気の心，親和の心，愛の心」は実験対象の学生に行動が促しやすい．具体的な行為は挨拶・礼と掃除が例に上がる．挨拶・礼は場の雰囲気を正し，感謝の気持ちや相手を思いやる気持ち，敬愛の心を持って行うと高次な道徳性になる．挨拶の言葉
やおじぎをするという行為ではわからない．行為を起こす
前に高次の道徳性を気づかせ，発現したらすぐ記録することが望ましい．その時の気持ちがわかるのは本人だけだからだ．
頭で理解していても高い道徳性を発現させ行動に移れるかは別問題である．この度のアラートシステムは道徳的目標の内容と意識の気づき，計画時にアラート（アラームを鳴らす・バイブレーションで知らせる）を出すこと，その行動の達成度を教師と学生，学生同士とで共有する手法について提案する．

2. クラウドシステムの準備と管理手法
2.1. “Wunderlist”の紹介
Wunderlist はクラウド型タスク管理 Web アプリケーションである．機能概要は以下の通り．
(1) 5 人までタスクを共有することができ，共有者
はお互いにタスクを振ることができる．
(2) タスクは開始時間とアラートとして注意を促す時
間，タスク完了見込み時間を設定でき，タスクを始めてから終わるまでの時間をカウントすることができる．毎日，毎週のように繰り返すタスクも設定が可能．
(3) 目標の設定，アラート，タスクの完了ボタンを押したとき，プッシュメールでグループメンバに自動で告知がされる．
(4)

198

スマホアプリケーションでも Web サイトでもSEA

ソフトウェア・シンポジウム2017 in 宮崎

タスク管理が行えるサービスである．
以上の機能から，道徳的行動の管理方法を紹介する．
2.2. 道徳的行動の管理方法と評価

題が見えるはずだ．その問題を埋める教育や支援システ
ムを構築，実験することでより完成度の高い，成人・大学生向けの道徳教育を目指す．

参考文献

高い道徳性を得た学生が，高次の道徳性を得た同級
生や先生のアドバイスを受けながら行動目標を自ら設定しなければならない．道徳性を評価することを考えると，人が集う場所に赴く時間が行動を発現しやすい．例えば
通学中や休み時間，授業後の時間や掃除当番のような他人と接点を持てる時間や公共的義務の執行中が挙げられる．高い道徳性を発現できる時間と場所を特定した
ら，タスクを自ら課し，教師とある時は学生にも目標を共有する．学生同士で目標を共有することは，高次の道徳性を発現する補助として期待できる．また学内の当番のように，学生が一緒に活動するときは，お互いが目標を立ててもよいし，共通の 1 タスクを代表者が管理してもよい．
目標とした行為が一定の時間を要する場合は，開始時と終了時にスマホの管理画面のボタンを押す．操作が複雑に感じる場合は終了したときのみでもよい．そのときの行為または意識が目標に届かなかった，あるいは予想以上だった場合は，理由をコメントとして残す．入力が面倒なら音声で残してもよい．タスクが完了すると，情報の共有者にメールが自動で届く．計画して初日に当たるときは学生や先生から「いいね」などのコメントで褒めたり，励ましたりして計画の達成をサポートできる．報告がない
ときはリマインダーを送り，行動を促してもよい．すべての報告に先生がすべて答えることは難しいので，学生同士の双方向教育を効果的に活用することが望ましい．ただしコメントを出し合える，学生同士の仲の良い雰囲気を構築する課題は残る．
計画した行動をリアルタイムに把握し，タイミングよく人による評価や励ましをすることで，高次の道徳的な行為にやりがいをみつけやすくなる．繰り返すことで行為と考え方が習慣化し，大学生への道徳教育の定義の達成に近づく．目標とする期間の終了後にタスクの成否を集計
し，行為を発動するときの気持ちは教師が L.コールバー
グの道徳性の発達段階[4]に照らして 6 段階で評価する．

[1] 阿部敬一郎，辰己丈夫，村上祐子，中谷多哉子，“道徳教育支援システム化に向けたモラルジレンマ”，
信学技報, vol. 116, no. 493, KBSE2016-44, pp. 3136, 2017 年 3 月.
[2] J. J. Phillips, How to Measure Training Results: A
Practical Guide to Tracking the Six Key Indicators,
New York: McGraw-Hill, 2000.
[3] Wunderlist,
https://www.wunderlist.com/ja/download/(2017 年 3月 16 日アクセス）[4] Anne Colby, F., Lawrence Kohlberg, S.: The
Measurement of Moral Judgment. Volume I.
Cambridge University Press, New York (1987).

3. ディスカッションと考察
教材，授業を可視化することで道徳教育レベルを合わせること，行動の達成度合いを可視化することで，母集団の道徳性の発現を比較することを目指した．高次の道徳性を発現できない母集団が生まれたとしたら，児童向けの道徳教育とは違い，対象者が大学生や成人ゆえの問

199

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ソフトウェア保守 隠蔽の構造～なぜ，保守作業は隠されてきたのか？～

増井 和也 ソフトウェア・メインテナンス研究会
masui@ye4.fiberbit.net
１． はじめにズ」等，あえて「保守」の存在を薄める表現も頻繁に見かける。

本報告は，ソフトウェア保守作業が現場の実作業量に比べ，大(2) 例 2)：次期開発に保守を紛れ込ませる

幅に少なくなるよう隠蔽される原因，構造，弊害，対策提言につ企業等において，新規開発が低品質のまま稼働され，投資計画

いて一般事例を基に総括的に報告するものである。なお，本報告

上の保守費より稼働後保守費が大幅に増大しそうな場合がある。

で使う「ソフトウェア保守」（または単に「保守」）は，JIS X01602)

計画差（失敗）を隠すため，当該保守作業を次期開発体制の中での保守プロセス規格 JIS X01613)が示す定義とする。

行い，前開発の保守費がゼロか，想定以下のように見せる。

２． 現場の保守作業量と周辺対応の乖離(3)事例 3)：アウトソーシングによる隠蔽

ソフトウェア技術者が参画するプロジェクトで新規開発 36%，
保守(メインテナンス)に類するもの過半数との報告がある

稼働後のソフトウェア保守作業を外部委託（保守対応社員の転

1)

。40

籍も行う）し，低価格の成果物請負契約とする。保守案件で複数

年超ソフトウェア現業経験を持つ報告者も「保守作業が新規開発更改したソフトウェアを「開発成果物」とし保守費を隠す。

作業よりはるかに多い」に違和感はない。

５． 保守作業隠蔽の弊害

国立国会図書館登録和書書籍名で「開発」を含むソフトウェア

保守作業の隠蔽は現場疲弊を起こす。隠すためには，担当者に

4)

関連図書の最近登録数は 1,500 件を超える 。しかし，現場の作対し，保守作業を他作業とは別に対応させる必要がある。当該担

業量とは相関せず，「保守」を含む同登録数は 40 と僅かである。

当者はキャリアアップ，作業報告・記録といった，業務として当また，IT 教育機関の教育内容はソフトウェアの新規制作想定が然与えられるべき時間を隠し保守に充てることになる。それでも大半に見える。現場で多数発生するはずの作成済みの設計やプロ不足する場合，さらなる残業・休日出勤での対応となる。IT 部門

グラムの見直し技法，修正デグレード防止や回帰テスト効果的・の構造的多忙要因の一つに保守の隠蔽があると報告者は考える。

効率的実施方法，ソフトウェア稼働後の構成管理要点等，保守技

6.

術を向上させる教育実践は聞かない。保守対応もあるだろう IT 企

是正すべき点と研究者や現場担当者への期待

現場の疲弊をもたらす保守作業隠蔽の解消を進める対策として，業の新人集合教育で，完成済みソフトウェアに対し，事前予告な

開発と保守の明確な組織的分離が必要と報告者は考える。両者がしの保守課題を次々と与え，適切なソフトウェア保守の教育を積分離され，相互牽制が機能することで，それぞれの作業量や品質極実施している企業は，少なくとも広報情報等からは見えない。

が客観視できる。ソフトウェア関連の研究者，スタッフ，担当者，

情報処理推進機構が取りまとめた IT 担当者として持つべきス

教育者が，保守そのものの研究・改善・教育から逃避せず，連携・キル・知識項目 5)6)の中に，JIS X0161 を詳細に意識した「保守」

情報共有し，積極的に保守についての実態把握を期待する。

は少ない。最近の改定で少し増えたようだが，情報処理技術者試

7.

結論

験のシラバスにもソフトウェア保守は概要・付け足し程度である。

ソフトウェア作成作業誕生以降，保守は隠蔽されてきた。そのIT 業界誌の法人対応事例記事では，システムを新規に再構築・隠蔽の弊害がソフトウェア現場の技術者に対する過重労働増大のリプレースし，ソフトウェアの保守・運用コストを劇的に削減で要因となっている。ソフトウェアの新規開発が減る時代に入り 8)9)，

きたとの記事は多い。しかし，実態として増え続けるソフトウェ

今後も増大し続ける保守作業の存在を明確に認知し，保守組織のア保守作業を，リプレースが困難な状況で，保守担当が技術面・開発組織からの分離，そのあるべき姿探求が必要な時が来ている。

プロセス面で保守の課題をどう克服してきたかの記事は少ない。

参考資料・コンテンツ等

３． 現場保守作業を隠蔽させてきたレガシーパラダイム

1)

報告者の経験や研究から，乖離の最大の原因はソフトウェアを「エンタプライズ系ソフトウェア技術者 個人の実態調査
2008」 情報処理推進機構 3.3 (3) (g)扱う企業・研究・教育・行政の全体が「開発善／保守悪」または

2)「保守は開発の付け足し」のレガシーパラダイムに長年固執してJIS X160:2012 ソ フ ト ウ ェ ア ラ イ フ サ イ ク ル プ ロ セ ス(ISO/IEC/IEEE/EIA 12207;2008 の一致規格)きたためと考える。その結果，保守作業自体の存在や量の多さを3)

不当に悪者扱いし，実態より極端に少なく見せる保守隠蔽を助長

JIS X0161;2008 ソフトウェア技術-ソフトウェアライフサイ
クルプロセス-保守（ISO/IEC/IEEE 14764:2006 の一致規格）してきた。現場の部門や技術者自身も保守作業は必要悪な付随作

4)

業と考え，誇らしげに公表することが憚られてきたと分析できる。
４． ソフトウェア保守隠蔽の構造例
ソフトウェア保守作業はどのようにして隠蔽されてきたのか，
その構造的な要因 3 例を示す。

国立国会図書館サーチ;’17 年 5 月時点，書名に「ソフトウェア開発」を含む書籍検索ヒットは 1,500 件

5)「IT スキル標準 V3 2011」 情報処理推進機構 2012

6)「i コンピテンシ ディクショナリ」情報処理推進機構 20157)

「ソフトウェア開発データ白書 2016-2017」情報処理推進機(1)例 1)：開発の範囲を最大限広げ，その分保守の範囲を縮小

構 2016

国際規格 3)が示す「保守」の範囲は修正規模に関係なく，改良

8)(Enhancement)，訂正(Correction)ともに保守で，同じ保守プロセ～ISO14764 による～
馬場辰男他

スをガイドする。しかし，ある公的な調査 7)では，保守は「改良9)ソフトウェア保守開発

増井和也，2007 ソフト・リサーチ・センター「ソフトウェアの少子高齢化が急加速 ～開発中心パラダイ

開発」という言葉を使い，改良はあくまで開発の一種とし，保守

ムに未来はあるか？～」増井和也 2016 ソフトウェア技術者

作業を隠すか小さく見せている。また，一括に「運用保守フェー

協会 SS2016 Future Presentation

200

SEA

  

1 ) (.

-‐‑‒

.

  

a0

  

1

BB) (.
()1

G

( 1

f(

O

( 1

G

(
c

( 1(

c
G

(

G

)

G

<

S<
c

c

c

( 1)

r

k

( 1+

97D

3F5

(+1+

c

4R

c

RPWVNR IP

KWTIP

c
v

r

r

r

NL

r

l

KV RTOlc

BRLV ITK 6 RPWVNR

225

l

BC2

BC 2
c

B4B c

c

  

e

r

E5

(+1)

BA2c

C9Bc

r

(+1(

-‐‑‒ .

k

c

( 1

c

BA2c

(+1+
(+1
(+1

BB

9RC

( 1)

RPNVK KUU

c

( 1)

:I I

( 1

c

v

c

>

7

  

(/1

(/

a

G

fg

]

G

(

012

(.1

)

c

G

(-‐‑‒1)

f
fi
f

v

n“
c

(-‐‑‒1)

r
c

BB

C7E9B

( 1

l

2 B

l

( 7

w
CBgce

] . -‐‑‒+)0 )+
ul s
(/1(
v](/1
[v w
]/1
v w
o
p
v l w
F8
F8 t
w
F8

(

l
l

]

v
ul

l

201

vn
S
t
ul

cf)
”

o

e
l

S+

t

ul

ul

SEA

DD
J

g K

J

>
d

i

d

i

/

6

/

6OWOUNOUMO 3U S

C MO 6O OM RVU 4
i

g K
F

J

K

J

K

<

i

g

g

d

i

i

i

i

iDC3

g

g

d

i
i

ON VU

R

g

8[ [XO AXO OU

RVU

te

/(

QX T 68

/

g

i

g

c

g

g

G6>

nd

i

g

i
i:43

/
/

/

g
g

/(

/(

g

g

g
i

g

/

GR [ Sutgi

VNO C76

J

g K

P

/

  

RVU

iDC3

iD5D

<2

-‐‑‒

8[ [XO AXO OU

i

g

i

v
c

i

g

s

l

d

/(

i

A

/(
)/
<
8[ [XO AXO OU
0H9 1

J

   )/)
EA

g

RVU

K m)

g

g

a

/

7IE
i

0H9 1

  

/

3DE7C

/
v

i

te

c

0H9 1 8[ [XO AXO OURVU   

/

/(

s

g

i

H9   3< /
)/
-‐‑‒/

f

H9   EA /EA

H9(   8> /H9)   3

v

py

7IE

y

/

3

r

te

H9   76 / 3
H9   67 /H9   7E /up

H9-‐‑‒   D7 / DVP ] XO 7 VS[ RVU

o

y

c

f

H9   C6 /H9  BF /

H9

  DE /

H9

  8C /

wDE3>A

H9 (   D6 /ED   5> /
m

s
/

a

H9 ED

202

o

a

SEA

77(

-‐‑‒

s
“
/0

a

0

S

0

PF

0)

/
  

r

S

0)

w

0)

r

3

4

0

6 K A K 7P C AKG   7 A A 2

a

0)

1

5K A 9 E A E S[

r
[

0

rpef

r

s

uw

[

M

3
:4

:4)
:4/

:4.

o
bsln

o
bsln
:4

a

:4(

:4

S

:4-‐‑‒
a

:4 )
:4

:4 (

:4

:4

203

87

SEA

rp

t

u   

ml
k

F

l .0 jd.0) jT
UdneW
” k
y vpb
ahc W
p
dne

oj

iahc

W

fk
idmlD
77( -‐‑‒ k
0 A

(

l
-‐‑‒

A

“ :A

tj

gdneW

tk

]pb

ahc

W

13

204

SEA

http://sea.jp／叫017/
6月に宮崎で「聞かれたソフトウエア聞発」について話しませんが
ソフトウエア ・ シンポジウム2017

r,冨；；；；；i買】

CSS2017 in宮崎）

l理士会＼［

第37回目を迎える
2017年のソフトウェ
ア ・ シンポラウムでは ，
この数年間で試みてきた新しい取り組み（チュ ー トりアル
やFuture Presentationなど）をさらに発展さぜたちのにしたいと考えています。 このほか， 552016に引き続き ，
論文発表や事例報告と ， ワ ー キンググルー プで議論を行います 。

争日程20口年＆Jl 78 （水｝～108 （土｝
6月7日（水｝～雪日 ｛金｝本 会議
設イベン卜日 ｛日 ｝
ラ ：併
月 民プ
ザ
場｛所本併 会議 富 崎 1市0〈．〉場｛所設イベ ン ト ） 来 定.......宵

i:6552017プログラム委員長
片山徹郎（宮崎大学）・票田太郎（ソニ ー ）ss これまでの開催地

ソフトウェヌグラフィティ
高富宮・::::.1:.::..

ソフトウエア妓術者協会（SEA, 「シ ー J ）は， ソフトウエアハ
ウス， コンビュ ー タメ ー カ， 計算センタ， エンドユ ー ザ， 大学，
研究所など， それぞれ異なった環境に置か九ているソフトウエア
妓術者あるいは研究者が， そうした社会組織の壁を越えて，各自の経験や妓術を自由に交流しあうための「場」として， 1985年
12月に設立しました．

4与

玄箆這重量
金益金丞動
環2葺分科会（5IGENV)
教育分科会（5IGEDU)
ソフトウェアプロセス分科会 （5PIN)
フォ ー マルメソッド分科会｛SICFM)
ソフトウエア品質保証分科会 （5ig5QA)
システムオブシステムズ分科会（5IG5o5)
ソフトウェア信頼性分科会（5IGForce)

名古屋支部
関西支都
九州支im
.t.J毎支im
I黄浜支im
東北支SP
北陸支節
広島支節
盛岡支百日
オtJ観重支部｛予）
205

SEA

ソフトウェア・シンポジウム 2017
論文集© ソフトウェア技術者協会----------------------------------------------------

2017 年 6 月 15 日 初版発行
編者

小笠原秀人
三輪東

発行者

伊藤昌夫

発行・発売 ソフトウェア技術者協会〒157-0073 東京都世田谷区砧二丁目 17 番 7 号
株式会社ニルソフトウェア内
ソフトウェア技術者協会 事務局
TEL: 03-6805-8931
http://sea.jp/----------------------------------------------------

ISBN978-4-916227-23-2