ソフトウェア・シンポジウム 2019 にご投稿いただいた論文／報告／Future Presentation に対して，プログラム委員会で審査を行い，下記を採択いたしました．
皆さま，ご執筆，ご投稿いただき，ありがとうございました．
| 時間 | ホール（6・7階） | 大広間A（5階） | 大広間B（5階） | 第一会議室（4階） |
| 6/5(水)14:30-16:45 | 未来に開く教育改革 |
要求抽出・形式仕様記述応用 |
ソースコード解析の応用 |
|
| 6/6(木)9:10-11:20 | ふりかえり・問題解決 |
IoT関連技術と応用 |
予測・テスト設計 |
Future Presentation |
未来に開く教育改革
[事例報告] 小中学生を対象としたロボット・プログラミング教育とコンテストの実施 前原 栄輔(NPO 法人HITO プロジェクト), 菅原智裕(熊本県立技術短期大学校), 久我守弘(熊本大学) 要旨： 2020 年度より小学校で必修化されることとなる「プログラミング教育」を，それに先立つ 2007 年度より地域貢献の一環として熊本県内で実施してきた．また，生徒の成果発表の場として国際ロボットコンテストの熊本地区大会を開催してきた．本稿では，これまでの取り組みについて報告する．[事例報告] 社会人リカレント教育enPiT-everi における熊本大学の取り組み 久我 守弘, 末吉 敏則(熊本大学), 中武 繁寿(北九州市立大学) 要旨： 本稿では，Society5.0 に対応した高度技術人材育成事業として実施する社会人リカレント教育 emPit-everi の概要，および，連携大学として参加する本学の取り組みについて報告する．
[経験論文] ソフトウェアプロセスの自己改善は自学自習でも可能なのか？ 梅田 政信, 片峯 恵一, 荒木 俊輔, 橋本 正明(九州工業大学), 日下部 茂(長崎県立大学) 要旨： パーソナルソフトウェアプロセス (PSP) は，ソフトウェア技術者のための自己改善プロセスである．PSP for Engineers コースは，SEI が提供する PSP トレーニングコースの一つであり，受講者は，講義と演習とを通じて，高品質ソフトウェアの開発に必要なスキルを習得できる．同コースの講義資料等は，2018 年 10 月よりCreative Commons ライセンスに基づき入手可能となり， PSP を自学自習する環境は整ってきた．しかし，改善提案の根拠となるプロセスデータの正確性と精密性とを自己で判断することは必ずしも容易ではなく，自学自習によるソフトウェアプロセスの自己改善の有効性は明らかになっていない．本論文では，九州工業大学におけるPSP for Engineers コースの 2013 年～2018 年の実施結果に基づいて，PSP インストラクタが果たしている役割を定量的に分析し，自学自習によるソフトウェアプロセスの自己改善の課題を明らかにする．
[経験論文] 勉強会を活用した組織成長モデル ～参加型勉強会の適用事例～ 伊藤 修司(SCSK 株式会社) 要旨： 本論文は，「参加型勉強会」を活用して，新しい組織成長モデル構築を試みた事例を紹介する．「参加型勉強会[1] [2]」とは，組織全体で，3 年間に渡り実践した，グループワーク主体の勉強会である． この勉強会を立ち上げた目的とねらい，業務と並行で長期にわたり継続するための工夫や，実際に組織にどんな影響を及ぼし，どんな課題が明らかになったのかについて，評価と考察を述べる． 一定の成果を出して，さらなる成長を目指す組織，タックマンモデル[3]に例えると，機能期（遂行期）の段階に入った組織が，さらに成長していくために適用した事例である．類似の課題に直面している組織が，解決に向けたアプローチの一例として，参考にしていただくことを期待する．
要求抽出・形式仕様記述応用
[研究論文] 要件定義計画を強化するアセスメント項目の提案 越前谷 達朗(株式会社日立ソリューションズ・クリエイト), 久保 光寛(日本システム技術株式会社), 渋谷 公寛(東京海上日動システムズ株式会社), 新田 史弥(株式会社東光高岳), 吉竹 宏幸(TIS 株式会社), 石川 冬樹(国立情報学研究所), 栗田 太郎(ソニー株式会社) 要旨： 我々は要件定義計画の不備に起因する要件定義の失敗を回避するために，要件定義開始前に具体化するべき計画事項と計画内容に対するアセスメント項目を創出し，過去の開発プロジェクト 53 件に対して調査を行った．結果，要件定義計画の不備を抱えた開発プロジェクトが多く存在すること，それらの要件定義で発生した問題の予防にアセスメント項目が有効であることを確認した．[研究論文] 新規製品開発時の発想支援ツールの提案 辻脇 優一 中谷 多哉子(国立情報学研究所放送大学) 要旨： 新規製品開発時には，既存製品に新しい価値をつけることが必要である．ここで製品の価値とは，製品のステ ークホルダのゴールを満たすものである．そのような新しい価値を新製品に組み込む際に，現状では開発者の閃きや思いつきに大きく依存している．そのようなアイディアを開発者がコンスタントに生み出せるようにするためには，工学的な手法が必要である．その際の発想支援として，著者のチームでは経験的な知見に基づいて作られた独自の発想支援ツールを考案し，用いてきた．この手法では，重要性として二項目，さらに三種類のステークホルダを抽出し，誰にとってどのような機能が目的を達成するために必須なのか，あるいは，付加価値を与えるものなのかを定義する．したがって，手法の入力は，目的，機能，その機能の重要性，その機能のステークホルダである．この手法の課題は第一に，目的とそれを達成するための機能が一段階しか定義できない．第二に，より多様なステークホルダを定義することが困難である．第一の課題を解決するために，我々はこの手法と KAOS 法とを統合した．また第二の課題を解決するために，人が担うロールによってステークホルダを分類した．これによって各ロールのユーザエクスペリエンスを分析し，課題を抽出するとともに，課題を階層的に分析することが可能となる．最終的に本稿で提案する手法では，ロール毎の課題と課題を解決するための手段を明らかにし，その手段から新製品を開発するための機能を要求として定義することが可能となる．また，この要求は別のステークホルダ，マーケティング担当者によって新製品の新しい機能による価値が評価される．本稿では，本手法を検証するために，目的と手段の関係を明確にできるか，顧客のニーズに答えることができる機能を創出することができるかを，実際の新製品開発において，新たに追加された機能を用いて検証した．
[研究論文] 日本語非機能要件の自動分類における教師あり学習アルゴリズムの評価 大東 誠弥, 福井 克法, 宮崎 智己, 大平 雅雄(和歌山大学) 要旨： 要件定義の際に作成される要件定義書に機能要件と非機能要件がある．中でも非機能要件は，明確な定義が存在せず文献によって定義が異なることがある [1]，といった理由により見落とされやすいことが知られている．また，要件定義書はシステムの規模が大きくなるにつれ要件も多くなる．大量の要件を目視で確認し，非機能要件の見落としを防ぐことは困難である． 非機能要件の見落としを未然に防ぐために非機能要件分類手法が提案されている．先行研究 [2] では，k-近傍アルゴリズム，SMO アルゴリズム，Na¨ıve Bayes アルゴリズムを用いた場合の分類精度を比較し，SMO アルゴリズムが最も分類精度が高いことを示している．しかしながら，先行研究が分類の対象としている非機能要件はすべて英語で記述された非機能要件であり，英語と文構造が異なる日本語非機能要件の分類においても先行研究の手法が最も適しているとは限らない． 本研究では，日本語非機能要件の分類に適した教師あり学習アルゴリズムの評価を行う．また，品詞を限定した場合についての分類精度を比較するとともに，類似する単語を統一する単語の正規化処理を行った場合の分類精度についても調査する．評価実験を行った結果，日本語非機能要件の分類においても先行研究と同様に SMOアルゴリズムを用いた場合が最も精度が高いことが確認された．また，SMO アルゴリズムを用いる場合，分類に用いる単語を名詞のみ，類似単語を統一することで，精度が向上することが確認された．
最優秀論文賞
[研究論文] 軽量形式手法VDMによるバーチャルマシンの開発 小田 朋宏(株式会社SRA), 荒木 啓二郎(熊本高等専門学校) 要旨： バーチャルマシン (VM) はソフトウェアで実装された仮想コンピュータシステムであり，プログラミング言語の実行系アーキテクチャとして広く採用されている．VMはユーザプログラムを実行するための基盤であり，高い信頼性と処理速度の両立が求められることから，その開発には高度に専門化された高い技能が要求されるとともに，安定した実装が得られるまで数年から 10 年以上の長い期間を要することが多い．本稿では，VM の仕様記述に実行可能な形式仕様記述言語 VDM-SL を適用した事例として，現在進行している ViennaVM の開発を紹介し，VM 開発における軽量形式手法の効果を議論する．
ソースコード解析の応用
荒木富松特別奨励賞[研究論文] コードクローンへの欠陥混入防止に向けた欠陥混入クローンの特徴分析 野口 耕二朗, 大平 雅雄(和歌山大学) 要旨： 大規模ソフトウェアの品質および保守効率の改善を目的として，欠陥が混入したコードクローンを検出する手法や欠陥混入クローンの特徴分析などの研究が行われている．しかしながら，コードクローンに欠陥が混入する原因を明らかにした研究は存在しておらず，クローンに対して欠陥が混入するのを未然に防ぐ方法については十分な検討がなされていない．本論文では，RxJava プロジェクトを対象としてコードクローンに欠陥が混入する原因を分析した結果について報告する．欠陥混入クローンのソースコードメトリクスの特徴を分析した結果，欠陥が混入していないコードクローンと比較して，(1) コードクローンに対する入力の数が大きい，(2) 規模に関するメトリクスの値が全体的に小さい，という結果が得られた．また，欠陥混入クローンの欠陥を分析した結果，コードクローンを持たない部分に混入した欠陥と比較して，(1) コードの不整備による欠陥が多く，(2) 欠陥の修正範囲が大きい，という結果が得られた．
荒木富松特別奨励賞
[研究論文] 組み込みソフトウェアにおけるコードクローン出現に関する考察 若林 奎人, 水野 修(京都工芸繊維大学) 要旨： 近年組み込みソフトウェアにおいて，個人でハードウェア部品を安価に入手できることや部品の多様化に伴い，ソフトウェア中にはコードクローンが発生することがある． 組み込み開発プラットフォームの１つである Arduinoは，特にハードウェア部品が安価であり，また，ハードウェア，ソフトウェア共にオープンソースであるため，派生品や互換機も数多く存在し，環境下には多くのコードクローンが発生していると考えられる．コードクローンはソフトウェアの保守を困難にしている要因の１つであると指摘されている． そこで，GitHub から watch 数の多い Arduino のプロジェクトを 170 個取得し，コードクローン検出ツールである CCFinder に入力することで，コードクローンの位置を把握し，他のプロジェクトにおけるコードクローンの数と比較することで Arduino プロジェクトにおけるコードクローンの発生率について考察する．さらに組み込みソフトウェア特有のコードクローンについて考察することで，組み込みソフトウェアにおけるコードクローンに関する知見を得る． CCFinder を用いた結果，Arduino プロジェクトには他のプロジェクトよりもコードクローンが多く発生していることがわかった．また，発生率の高いコードクローンの種類や，組み込みソフトウェア特有と思われるコードクローンを発見した．
[研究論文] CNN-BIシステムによるプログラムの不具合発見の検証 小川 一彦, 中谷 多哉子(放送大学) 要旨： ソフトウェアの品質を向上させるため，これまで多くの研究が行われてきた．従来の方法には，ソフトウェアメトリクスを用いてソフトウェアシステムの品質を評価する方法がある．本稿では，プログラムの不具合を有無を推論するために、深層学習技術の 1 つである CNN （Convolutional Neural Network）を適用する．不具合を起こすプログラムの記述には共通点があるのではないかと考えた．プログラムの記述を目視すると，関数やサブ ルーチンの集合体でインデントにより模様に見える．記述に共通点があるのであれば，見た目の模様にも共通点があると考えられる．プログラムの構文の文法に従い，文字に色付けすることでより特徴付けられる．プログラムの記述の特徴を，深層学習を用いて，ソースコードの構文の形から不具合を推論することを試みた．これには，ソースコードを画像化し，深層学習により不具合の推論を行った．推論結果を検証するために，不具合のある画像を推論した結果と，推論用プログラムの中で実際に発見された不具合の内容を比較した．この比較実験では，画像化したプログラムを使用して学習用データ及び推論用データを作成した．作成したデータを用いて，学習と検証および推論することで実験を行った．
[研究論文] LSTMを用いたソースコード内の演算子推定手法 舟山 優, 水野 修(京都工芸繊維大学) 要旨： 統合開発環境（IDE）には関数名や変数名の候補を表示するなどの補完機能が備わっているものが多い．このような機能は，素早くソースコードを記述したり，不具合の混入を抑制したりするなど，ソフトウェア開発の生産性を向上させている．このような生産性に関連する研究は数多く行われている． 本研究ではソースコード中の演算子に関する有用な情報をユーザに提示することを目的とする．有用な情報の例としては，演算子の補完機能や，ソースコード中の不適切な演算子の検出が考えられる．ソースコード中の不適切な演算子とは，例えば ”if(a > 5)” とするべきところを ”if(a >= 5)” としてしまった場合などである．目的達成のための第一歩として，本研究ではソースコード中のある箇所の演算子の種類が不明な場合に，その箇所に最も当てはまる演算子を推定する手法を提案した． Java で記述されたソースコードをトークンの並びに変換し，それをもとに欠落した演算子を推定する LSTMを用いた機械学習モデルを作成した．LSTM を用いたモデルを 3 つ作成し，それらのモデルを用いた手法と欠落した演算子をランダムに推定する手法で実験し，考察を行った．実験の結果，最大で約 72%の正解率を得られた．この結果から，ソースコードには欠落した演算子の特定に有用な特徴が含まれており，LSTM を用いることでそれらの特徴を学習できると考えられる．
ふりかえり・問題解決
[事例報告] ソフトウェアエンジニアリングにおけるコミュニケーション技術の活用 艸薙 匠, 田村 朱麗, 藤原 聡子(株式会社東芝) 要旨： ソフトウェアは未だ人が作るため、コミュニケーションが重要であると言われている。以前から様々なソフトウェアプロセスの中でコミュニケーションについて経験知がまとめられてきた(例：ピアレビュー等)。一方人文科学系ではコミュニケーションについて様々な取り組みが定式化しつつあるが、その成果を整理して、ソフトウェアエンジニアリングの中で十分活かせているとは言い難い。 そこで本発表では、技術者向けのコミュニケーション技術として、特に近年注目されている、ファシリテート(フ ァシリテーション)、ティーチング、コーチング、カウンセリングの 4 つの方法に着目し整理する。その上でソフトウェアエンジニアリングに活用している社内事例を紹介する。なおそれぞれのソフトウェアエンジニアリング技術は、コミ ュニケーション以外の側面の方が大きいと思われるが、本報告ではコミュニケーションという切り口で取り扱う。また、「技術」という言葉を本報告では、「物事をたくみに行うわざ(広辞苑)」という定義で用いる。最優秀発表賞
[事例報告] コンセプト＆ゴール指向のふりかえりの提案 小楠 聡美(株式会社 HBA) 要旨： 筆者は，過去に経験した開発現場でのふりかえりについて，「ふりかえりの効果が実感できない．」「ふりかえりをやる意味があるのか？」と思っていた．そして，その原因として，複数の要因があると考えた． そこで筆者は，上記の要因を解消して，より効果を実感できるふりかえりを実施できるような手段はないかと考え，実際のものづくりにおけるふりかえり手段として活用した ． 本事例では，「ふりかえりの効果が実感できない」要因を解決できるようなふりかえりの手段と，実際のものづくりにおける改善実践例，およびその効果を報告する．
[事例報告] ＜違い＞を捉えよう ～違いの分析から始める問題解決～ 常盤 香央里(WACATE 実行委員会) 要旨： 組織で発生する様々な“人に起因する問題”を分析すると，その背景にある人の考え方やコンテキストなどの＜違い＞に収束した．この＜違い＞を意識的に捉えることにより，“人に起因する問題”の抑制や対処が可能であると考えられる． そこで＜違い＞を捉えることを意識的かつ段階的に体験し試行してもらう場として，新たなワークショップを考案し実施した．以下の 2 回のワークショップ実践事例を元に具体的な内容と効果を述べる． ・初回：WACATE 本会（ソフトウェアテストの 1 泊 2 日合宿形式勉強会）での 1 セッションとしての実施 ・2 回目：プチ WACATE（WACATE 主催の個別勉強会）での本セッションのみの再演
[経験論文] なぜなぜ分析とシステム理論に基づくSTAMP/CAST の事例による比較 ～ソフトウェアメンテナンスプロジェクトでの問題の分析事例に基づく比較～ 日下部 茂(長崎県立大学), 三輪 東(SCSK株式会社) 要旨： 筆者らは，ソフトウェアメンテナンスプロジェクトで問題が発生した事例で，システム理論に基づく事故の説明モデル STAMP をベースとした分析手法 CAST を用いることで失いかけた心理的安全を回復できた．この組織では通常は問題分析においてなぜなぜ分析をベースとした分析を行っており，該当事例でも当初なぜなぜ分析をベ ースとした分析を行ったが，分析に限界があった．本稿では，システム理論に基づく STAMP/CAST となぜなぜ分析の比較について，分析結果に違いが出た上記事例をベースに比較と考察を行う．
IoT関連技術と応用
[事例報告] IoT システム開発におけるエッジデバイスソフトウェア開発の難しさ 阪井 誠(株式会社SRA) 要旨： IoT システムのエッジデバイスとして Rashberry pi を用いたIoT システムの開発者にヒアリングを行い，12の具体的な難しさを確認した． エッジデバイスソフトウェア開発はその構造の複雑さから，一般のアプリケーションの難しさとは異なるものであった．本報告のような知見の蓄積が，IoT システムの開発をより安全で安定したものにしてくれると考えられる．論文奨励賞
[研究論文] テンソル分解プログラミングの理解支援のための立体パズルの利用 山本 直樹, 村上 純, 石田 明男(熊本高等専門学校) 要旨： テンソル分解の一手法として高次特異値分解（HOSVD）があるが，これは行列の特異値分解（SVD）を高階テンソルの分解に拡張したものである．そのため，HOSVD は SVD と比べアルゴリズムが複雑となる．そこで，我々は，立体パズルを教材に用いた HOSVD アルゴリズムの理解支援の取り組みを行っている．本論文では，立体パズルとしてルービックキューブおよびインスタント・インサニティの 2 つを取り上げ，これらを高階テンソルで表現し，HOSVD アルゴリズムの n-モード行列展開を利用して展開図にする原理について述べる．さらに，その展開図のテンソル分解やそのプログラミング教育への応用として，本校学生によるルービックキューブの展開図作成の事例と，主に小中学生を対象として，インスタント・インサニティの展開図の理解度について調査した事例についても言及する．
[研究論文] マイクロサービス開発へのSOA 開発プロセスの拡張可能性の検討 宗平 順己(Kyoto ビジネスデザインラボ) 要旨： デジタルトランスフォーメーションの進展に伴い，SoE (Systems of Engagement)と呼ばれるタイプのアプリケーシ ョン開発の重要性が急激に高まってきており，先行する欧米では，マイクロサービスの利用がデファクト化してきている． このマイクロサービス開発にあたっては，サービス設計の難しさが課題として共通認識されている． このサービス粒度問題については，SOA 開発と同じ課題であることから，筆者らが開発した SOA 開発プロセスをマイクロサービス開発へと拡張できるのではないかと考えた． 本論では，SOA 開発プロセスが BPM からスタートすることから，マイクロサービス開発についても上流プロセスからの定義を行い，マイクロサービスの持つ特徴に留意して，どのように SOA 開発プロセスを拡張すればよいのかを検討する．
[研究論文] データベース・アプリケーションへの実行時モデル検査導入手法の提案 宮永 照二(株式会社テクノネット) 要旨： 情報システムの急速なかつ広範囲な普及に伴って，情報システムの製品の品質とプロセスの品質の両方において，新たな適用方法が提案されている [2][3]． 情報システムは開発・運用プロセスにおいてライフサクルを持つが，このライフサイクル内の各工程間でシステムに関する知識が共有されていないために様々な問題を引き起こしている [2]．特にシステムの重要な性質についてテストすら完全にできない状態が存在することも報告されている [2]． このような状況でシステムの重要な性質を検証する技術として，実行時モデル検査 (On-the-Fly Model Check-ing) がある [7] [9] [10]． 本稿では，情報システムとくにデータベースアプリケーションについて，実行時モデル検査を効果的に適用する方法について提案する．
予測・テスト設計
論文奨励賞[研究論文] 開発者に着目したFault-Prediction 技術 高井 康勢, 加藤 正恭, 三部 良太(株式会社日立製作所), 林 晋平, 小林 隆志(東京工業大学) 要旨： ソフトウェア開発では，開発の早い段階でフォールト（バグ）を見つけて修正することが重要となる．そのため，潜在的なフォールトの場所を予測する Fault-Prediction技術に注目が集まっている． Fault-Prediction 技術では，ファイルやモジュールごとに，潜在的なフォールトの存在確率を表す「潜在フォールト率」を算出する．算出した潜在フォールト率が高いファイルやモジュールを重点的にテストやレビューすることで，開発の早い段階でのフォールト発見が可能となる． 近年利用が進んでいる Fault-Prediction 技術では，静的解析ツールで検出できるコーディング規約違反や既知のフォールトの情報を基に，潜在フォールト率を算出する．しかしながら，開発の立ち上げ直後は，潜在フォールト率の算出に利用するコーディング規約違反やフォールトの情報が少ないため，従来技術では潜在フォールト率を算出できない． そこで本研究では，「開発者」が過去に携わったプロジェクトで作り込んだ指摘やフォールトなどの情報を基に，ファイルごとの潜在フォールト率を算出する Fault-Prediction 技術を提案・評価した．本技術では，開発の立ち上げ直後でも潜在フォールト率を算出できる． 企業内のある 1 プロジェクトで提案手法を評価したところ，本手法で算出した潜在フォールト率が高い上位25% のファイルに，全フォールトの約 6 割が含まれることが分かった．提案手法により，潜在フォールト率が高いファイルから順にテストやレビューを実施することで，開発の早い段階でのフォールトの発見・修正が可能となる．
[研究論文] 質問に対する回答者推薦手法に用いられるデータの期間についての一検討 眞鍋 雄貴, 西原 弘樹(熊本大学) 要旨： ユーザ間で質問回答を行うプラットフォームとして質問回答コミュニティ（CQA）がある．CQA では日々多くの質問に対して，回答が行われる．一方で，回答が行われない質問も多くある．この問題を解決するため，回答者推薦手法が提案されている．特に，複数の手法を組み合わせた回答者推薦手法が多く提案され，特に，トピック分析とネットワーク分析を組み合わせた手法が多くを占める．しかしながら，これらの手法の評価では，推薦に用いるデータの期間が考慮されていないこと，また，新たな質問をテストデータにしていないものがある．これらは，回答者推薦手法がユーザにとって有用であるかを評価するには必要な観点である．そこで，本研究では，このような観点から回答者推薦手法を評価する第一歩として，プログラマ向け CQA である Stack Overflow において，質問や回答を抽出する期間を基準となる日の直前3 ヶ月，6 ヶ月，9 ヶ月，12 ヶ月として得られたデータセットを用い，トピック分析とネットワーク分析を組み合わせた回答者推薦手法の結果がどのように変わるのかを調査した．その結果，3 ヶ月の場合にのみ正しく推薦を行えた質問があった．また，この質問に対して回答者として推薦されたユーザのうち 3 名は基準日直前 2 ヶ月間は活動を行っていなかったことが示された．
論文励賞
[経験論文] Web サービス・モバイルアプリケーション開発におけるテスト設計を支援するための標準テスト観点の整備 河野 哲也, 柏倉 直樹, 前川 健二, 菊武 祐輔(株式会社ディー・エヌ・エー) 要旨： Webサービス・モバイルアプリケーション開発におけるテスト設計においてテスト観点を抜け落ちなく網羅的に抽出するために，標準テスト観点を整備し，それをテスト設計で活用する研究を報告する．まず，実際のテスト業務に基づきテストエンジニアの特性を整理し，問題を明らかにする．次に，テスト分析・テスト設計の流れを解析し，標準テスト観点の枠組みとして必要な要件を整理し，その要件に従い枠組みを定める．そして，過去に作成したテストスイートを分析することで様々なテスト観点を導出し，枠組みに従いそれらのテスト観点を整理することで標準テスト観点の実装を行う．最後に，実際のWebサービス・モバイルアプリを対象として標準テスト観点の適用を行い，一定の有効性が確認できた．
Future Presentation
[Future Presentation] システムオブシステムズの現状と課題 落水 浩一郎(UIT，Myanmar), 小笠原 秀人(千葉工業大学), 日下部 茂(長崎県立大学), 艸薙 匠(株式会社), 熊谷 章(金沢諏訪堂の会), 栗田 太郎(ソニー株式会社), 塩谷 和範(ISO/IEC SC7 エキスパート), 新谷 勝利(新谷IT コンサルティング), 鈴木 正人(北陸先端科学技術大学院大学), 瀬尾 明志（日本ユニシス株式会社）,富松 篤典(株式会社電盛社), 奈良 隆正(コンサル21世紀),羽田 裕(日本電気通信システム株式会社), 方 学芬(株式会社), Huyen Phan Thi Thanh(株式会社日立製作所), 堀 雅和(株式会社インテック), 矢嶋 健一(株式会社JTB) 要旨： 連携する情報システム群（システムオブシステムズ）を対象として，その定義，問題点, 対処策に対する研究・技術開発の課題を検討する．[Future Presentation] プログラミング言語横断類似コード断片検出ツールの試作 神谷 年洋(島根大学) 要旨： 複数のプログラミング言語で記述されたプログラム，あるいは，異なるプログラミング言語へ書き換えている途中のプログラムに適用することを目的とした，類似コード断片を検出する動的解析手法を提案する．また，その実装により，Java により記述された 300 行程度のプログラムとそれを Python に変換したものの間で類似コード断片を検出した適用例を紹介する．
[Future Presentation] 日本版エンジニアの心理的安全性 ～トリセツ活動その2 実践編～ 増田 礼子(フェリカネットワークス株式会社),松尾谷 徹(有限会社デバッグ工学研究所) 要旨： 前々回のソフトウェア・シンポジウム (SS) 2017 では，マイクロマネジメント (過介入) など，エンジニアにとって危険な職場が実在することを取り上げました． SS2017 のワーキンググループ (WG) では，善良なマネジャーが無意識のうちに，部下に圧力をかける行動に陥る体験を聞き，この問題の根の深さを感じました．その後，Google のチームに対する実証研究が公開され，「心理的安全性」がチームの成果や生産性を支配する一番重要な共通因子であることが証明されました． Google の研究は，データに基づく実証研究であることから，同様に日本におけるこの種の研究をまとめ，さらに，対策として成果がでているケースを調べました．トリセツ第 2 弾は，日本版エンジニアの心理的安全性とその対策について提唱します．内容は，1. 原因：根深い組織文化，2. 症状を測る：客観的な把握，3. 対策分類：なにが実績として成功しているのか，4. トレンド：自立したチーム活動，などです．
