ソフトウェア・シンポジウム 2019 で 14 年目を迎えるワーキンググループでの活動は，ソフトウェア技術にまつわるさまざまなテーマや課題に関する発表，議論を行うことで，参加者やグループがそれぞれの方向性を見いだしていくための場です．昨年から継続して，参加者のさまざまな要望に応えるために，ワーキンググループ (Working Group : WG) の他に，チュートリアル (Tutorial Session : TS) も用意しました．
昨年と同様，今回もワーキンググループに参加しないという選択肢はありません．フルに参加できない場合でもかまいませんので（その時は，ワーキンググループのリーダにあらかじめ予定を伝えてください），できるだけ議論したいテーマを決めて，ワーキンググループに参加することをお薦めします．どうしても特定のテーマが決まらない方は，WG12「ソフトウェア開発の現状と今後の発展に向けたディスカッション」を選択してください．このワーキンググループでは，特定のテーマを決めず，参加者からの発表をベースにしたディス カッションを行います．
また，昨年から引き続き，ワーキンググループでの活動終了後，各ワーキンググループからの報告会（約1時間）を実施します．参加申込み時に，議論に参加するワーキンググループと聴講するワーキンググループの報告会を選択して下さい．各ワーキングリーダの皆様には，最後の時間帯にまとめをお願いすることになり，お手間をかけて申し訳ありませんが企画の主旨をご理解の上，ご協力いただければ幸いです．
以下はタイムテーブル(案)です．
- 6/6(木) 14:00-18:00 ワーキング／チュートリアルでの議論や講義
- 6/7(金) 9:00-12:00 ワーキング／チュートリアルでの議論や講義
- 6/7(金) 13:30-14:30 報告会（各ワーキンググループを開催した部屋で実施）
| WG | 名前 |
|---|---|
| 1 (OS) | OSSこれからの20年を想像する |
| 2 (PI) | 働き方改革 ～プロセスを改善して業務効率アップ！ |
| 3 (LE) | レガシーソフトウェアのブラックボックス化をどう防ぎ，どう解消する？ |
| 4 (OP) | 組織パターンの活用 複数拠点開発を円滑に |
| 5 (QA) | 新しい品質保証のかたちを目指して |
| 6 (FM) | 仕様について考えよう - SPARK/Ada を用いたプログラム検証を題材にして - |
| 7 (PL) | 本当は難しくないソフトウェアプロダクトライン |
| 8 (PT) | プロセス自己改善手法のビックバン到来？ － PSP/TSPのCreative Commons化を契機に － |
| 9 (ET) | エンジニアのターニングポイント：異動，転職，リタイヤ ～ 新たなチャレンジとストレス克服 ～ |
| 10 (RE) | 様々なふりかえり手法の効果的なシチュエーションを考えてみよう！ |
| 11 (ED) | 未来を切り開くソフトウェア教育の可能性を探る |
| 12 (XS) | ソフトウェア開発の現状と今後の発展に向けたディスカッション |
| TS | 名前 |
| 1 (QU) | エンジニアのための『質問力』（引き出す力）を伸ばすワークショップ |
(順序不同，英字二文字は略称)
WG1: OSS これからの20年を想像する
◆リーダ: 古木良子 (オープンソースソフトウェア協会，株式会社ウィズ.アール)
◆概要:
オープンソース誕生から20年過ぎ，ソフトウェアそのものも，またそれを取り巻くビジネス自体大きく変革してきました．そこで，今，この現状を踏まえ，これから20年後のオープンソースソフトウェア，それを取り巻く環境，ビジネスなど多方面からソフトウェアを想像する．
◆想定参加人数:
10名◆参加の条件:
特になし．◆運営方法・備考:
それぞれの想像した考えを述べいただき，議論する．◆メーリングリストのアドレス: ss2019-os @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG2: 働き方改革～プロセスを改善して業務効率アップ！
◆リーダ: 田中 康 (奈良先端科学技術大学院大学，(有)ケイプラス・ソリューションズ)，八木 将計 ((株)日立製作所)
◆概要:
近年，働き方改革が注目される中，労働基準法が改正され，ソフトウェア開発現場も含めて，残業時間の削減が必須となっています．
しかしながら，作業量そのものが減るわけではないため，残業禁止などによる単純な労働時間の削減というわけにはいかず，お困りの方は多いのではないでしょうか？
業務効率を向上し，生産性を上げるためには，現状の働き方の問題を見直し，改善していくことが必要です．
本WGでは業務プロセスモデリング手法であるPRePモデルを用いて，プロセス改善・業務改善について議論します．
進め方は，グループワークにて，身近な具体例を用いて，業務の問題点の整理，改善の方向性について議論することを想定しています．自業務へどうのように適用していくかディスカッションしていきたいと思います．
◆想定参加人数:
10名程度◆参加の条件:
＜想定参加者＞ ・自身の業務の効率を上げたいと思っている方 ・開発プロセス改善を支援している方
◆運営方法・備考:
＜想定アジェンダ＞ 1.参加者の自己紹介(0.5～1時間) 2.概要とワークの進め方(1.5時間) 3.As-Is業務モデル作成(3時間) 4.To-Be業務モデル作成(2時間) 5.ディスカッション(2時間)
◆メーリングリストのアドレス: ss2019-pi @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG3: レガシーソフトウェアのブラックボックス化をどう防ぎ，どう解消する？
◆リーダ: 増井 和也 (ソフトウェア・メインテナンス研究会)
◆概要:
レガシーソフトウェアのブラックボックス化が進み，保守対応のリスクやコストが増大，さらにその「技術的負債」などにより，多くのシステムで保守・運用の対応破たんが間近に迫っている（2025年の崖）との報告があります．
その対策としてシステムの刷新（デジタルトランスフォーメーション(DX)）の事例もIT雑誌に掲載されてきています．
大規模かつミッションクリティカルなシステムでの刷新期間は数年またはそれ以上を要する場合も珍しくなく，この間も複雑に絡まった稼働中レガシーソフトウェア保守対応の並行継続が不可避であることが容易に想像できます．
また，DX推進ガイドライン等では，現行システムの詳細仕様の正しい認識が刷新プロジェクトの失敗防止に必須との警告注記があります．刷新時には現行ソフトウェアの再ホワイトボックス化により，新旧システム全体を俯瞰できる多くのソフトウェア技術者が必要と考えられます．
なお，刷新期間が数年になる場合では，刷新で新規に開発されたソフトウェア（アジャイル開発などで比較的早い時期に稼働するソフトウェア）への保守対応も必要となり，刷新後の保守体制不備から，刷新後ソフトウェアのブラックボックス化が急速に進む恐れもあります．
本WGは本テーマについて下記「運営方法」で進めます．
◆想定参加人数:
10名◆参加の条件:
ソフトウェアに関する経験（開発・保守・運用に関する現場・提案・管理・研究・技術教育の履修などのいずれか）があればどなたでも構いません．
コミュニケーションを円滑にする目的で，ポジションペーパーの提出をお願いします．簡単なもので構いません．
◆運営方法・備考:
参加者のみなさまのお考えや経験知の共有を最初に行い，ブラックボックス化の現状・原因・防止対策，属人性を排除した再ホワイトボックス化の方法・課題などを具体的に集めます．その中から共通的な知見を集約・整理し，どうすることでこの課題克服の道筋を描けるのか，議論してみたいと思います．
◆その他:
DXの事前予習などは特に不要ですが，上記「概要」の前提となる参考文献を次に示します．
<参考文献> 1) 経済産業省『DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～』2018.9 2)日経BP社 日経コンピュータ 特集「さあ，デジタル変革の旅に出よう」2019.2.7号 3)日経BP社 日経コンピュータ 特集「富士フイルム DX戦略の青写真 AIで挑む，2度目の業態転換」2019.1.24号 4)経済産業省 『デジタルトランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン）Ver. 1.0』 2018.12 5)IPA社会基盤センター 片岡晃「デジタルトランスフォーメーション時代に組込み/IoT分野で求められること」2018.12
◆メーリングリストのアドレス: ss2019-le @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG4: 組織パターンの活用 複数拠点開発を円滑に
◆リーダ: 本多 慶匡 (SEA北海道，東京エレクトロン)
◆概要:
「組織パターン」ではコンウェイの法則をはじめとしていろいろと複数拠点開発について記録しています．本ワーキンググループでは，ひとつのプロダクトを複数の拠点に分かれて開発を進めているみなさんと一緒に，
・「組織パターン」を活用して複数拠点開発についての振り返り ・複数拠点開発を円滑に進めるためのノウハウの共有 ・そして新たな取り組み
について話し合いをしたいと思います．
◆想定参加人数:
10名以下◆参加の条件:
複数拠点開発に関心のある方，組織パターンに関心のある方なら経験を問わずどなたでも歓迎します．
◆運営方法・備考:
概要に記載
◆メーリングリストのアドレス: ss2019-op @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG5: 新しい品質保証のかたちを目指して
◆リーダ: 西 康晴 (電気通信大学)，三輪 東 (SCSK)，宮田 一平 (SHIFT)，大野 泰代 (オープンストリーム)
◆概要:
SigSQAでは2018年4月期のキックオフ以降（https://sea.jp/p/2433#more-2433），伝統的なSQA（ソフトウェア品質保証）の利点や問題点をふりかえりながら，新しいSQAをどう実践していくべきかの議論を重ねてきました．経営を強固にし，会社やプロジェクトから必要とされるSQAのかたちはどういったものかを考えています．2月に「イマドキのソフトウェア品質保証に重要な8つの原則」を抽出するところまできました．以後，この原則は増えたり減ったり表現が変わったりするかもしれませんが，6月WGまでに整理される見込みです．
本ワーキングでは，ここでまとめた「イマドキのソフトウェア品質保証に重要な原則」を用いて，新しい品質保証のかたちを議論します．新しい品質保証を一緒に創りたい方，参加をお待ちしております．
◆想定参加人数:
10名◆参加の条件:
SQAに興味を持たれている方々であれば，条件は問いません．
SQAがよく分からないという方，SQA は不要という方，SQA に関して一家言のある方，自分たちのSQAは素晴らしいという方，SQAで悩んでいるという方，すべてWelcomeです！開催前に作成いただく自己紹介シートを，WG参加者全員で共有させていただきます．
◆運営方法・備考:
「イマドキのソフトウェア品質保証に重要な原則」を，テーマごとに時間を区切り，ディスカッションしていきます．
◆メーリングリストのアドレス: ss2019-qa @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG6: 仕様について考えよう - SPARK/Ada を用いたプログラム検証を題材にして -
◆リーダ: 張 漢明 (南山大学)
◆概要:
ソフトウェア開発において「仕様」が重要な役割を果たすことは誰もが認識しています．しかしながら，仕様として「何」を「どのように」書けば良いかは，誰もが悩ましいと感じていると思われます．要求と仕様の違いは何か？形式仕様とプログラムの違いは何か？本ワーキンググループでは，SPARK/Ada 言語を題材にして，「仕様とは何か」について議論します．SPARK 言語は，事後条件，事前条件，不変条件などの仕様を記述することができる実行可能な Ada のサブセットで，静的解析やプログラムの自動検証を支援する環境が整備されています．SPARK 言語の紹介と，参加者による仕様に対する問題を議論して，仕様記述の課題と解決策を探ります．
◆想定参加人数:
10名◆参加の条件:
ソフトウェア開発における仕様記述およびプログラム検証に関心がある方．参加者には仕様に関する発表をお願いしますが，議論のみの参加も募集します．
◆運営方法・備考:
プログラム検証の概略および SPARK/Ada の言語と検証機能の紹介と，参加者による仕様に関する発表を行い，仕様に関する議論を行います．
◆メーリングリストのアドレス: ss2019-fm @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG7: 本当は難しくないソフトウェアプロダクトライン
◆リーダ: 中西 恒夫 (福岡大学)
◆アドバイザ: Lee, Kwanwoo（韓国 漢城大学校）
◆概要:
日本の産業現場ではニーズはありながらも，導入障壁が高いと敬遠されがちなソフトウェアプロダクトライン（SPL） --- しかしながら過去10年の間に国内での導入，さらには継続の事例も少なからず報告されている．本ワーキンググループでは，ソフトウェアプロダクトラインの導入を検討している，導入に成功した，さらには継続している現場の当事者が集い，現場の文化を踏まえた導入／継続の戦術と課題，定量的／定性的な効果，SPLの肯定的側面と否定的側面，SPLの次にすべきことについて議論する．
◆想定参加人数:
10～20名◆参加の条件:
形式は問わないが，ワーキンググループでの何かしらの発表を求める．内容はSPLの導入／継続に関わることであればなんでもよい．たとえば，「SPLに期待していること」，「なぜSPLに取り組みたいのか」，「SPLの導入にあたって課題，障壁と認識していること」，「SPLの導入の結果」，「SPLの継続の結果」，「SPLで期待外れだったこと」，「SPLの現状に対する批判」，「SPLの成功／失敗事例」，「SPL実践のためのプロセス／テクニック／ツール」など．発表内容に学術性，新規性は問わず，既発表のものや社内での発表や他の学会の再利用でも全く構わない．発表は会場での議論のネタとして使う．発表は他の参加者との共同発表でも構わない．
◆運営方法・備考:
参加者個々／グループで発表し，それをもとに議論を行う．（参加できる期間などの制約がない限り）フレキシブルなスケジュールでリラックスして議論を行う．途中での割込み質問も可能とする．本WGは，個々の参加者がSPLの導入／継続に係る「納得解」を得ること，パラダイムに過ぎないSPLについて自分なりの定義を見出すこと，自社へのSPL普及活動に本WGを利用できるようにすること，ならびに我が国におけるSPLコミュニティの拡大を目指す．
◆メーリングリストのアドレス: ss2019-pl @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG8: プロセス自己改善手法のビックバン到来？ － PSP/TSPのCreative Commons化を契機に －
◆リーダ: 日下部 茂 (長崎県立大学)，梅田 政信 (九州工業大学)
◆概要:
個人・チームレベルのソフトウェア開発プロセスのテンプレート・トレーニングコースである，PSP/TSPは，これまではカーネギーメロン大学のソフトウェア工学研究所の知的財産として管理されていましたが，2018年10月よりCreative Commons化（オープンソース的ライセンス）され，企業や教育機関などにとってPSP/TSPの利活用が以前より柔軟にできるようになりました．その一方で，集中的な管理者がいなくなることにより，質の保証などの課題も生じています．そこでこのワーキンググループでは，参加者のそれぞれの立場や状況から，PSP/TSPの実務導入・展開への期待と課題，今後のコミュニティをテーマに議論を行いたいと思います．
◆想定参加人数:
数名◆参加の条件:
ポジションペーパA4１ページ程度
◆メーリングリストのアドレス: ss2019-pt @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG9: エンジニアのターニングポイント：異動，転職，リタイヤ ～ 新たなチャレンジとストレス克服
◆リーダ: 増田 礼子 (フェリカネットワークス)，古畑 慶次 (デンソー)，辻 達諭 (L＆Cトレーニング)，松尾谷 徹 (デバッグ工学研究所)
◆概要:
IT 分野の技術進歩は速まる一方，企業における中堅エンジニアの市場に対するエンジニア力が急速に陳腐化しています．
この WG では，この現状認識のもと，企業人の立場とは別に，エンジニア個人として成長するために，ターニングポイントとして何が大切なのかについて議論します．
成長していない原因の一つには，職場経験からしか学ばない／学べない環境にあります．職場における技術をエンジニアが選択する自由度が無く，階層的な管理システム下で技術がプロセスに組み込まれ上意下達化すると，エンジニアの成長は停滞するようです．しかし，この環境を企業の視点から改善するのを待ってはいられません．待っていても，異動時や転職時にエンジニアとしての時価価値が得られません．
今回のテーマは，このような現状の中で，異動や転職の経験者から，エンジニア個人の成長をどのようにして進めてきたかについて本音の部分を語ってもらい， 議論を進めます．
◆想定参加人数:
中堅エンジニア 10名程度◆参加の条件:
本音トークに関する守秘義務を固く守れる方 本音トークで発表したい方 (内容については事前相談あり） 中堅エンジニアで社会人経験 2 年以上が望ましい．
◆運営方法・備考:
エンジニアにとって劣悪な職場環境，転職，意図しない異動，リタイヤ転職などの経験者による「ここだけの経験談」を基に，本音の議論をします．
経験談の予定：
- 転職のケース；メーカから新興企業へ，メーカから大学へ
- 異動のケース：開発部門からスタッフ部門へなど専門性の変化
経験談は一部をWG以外の方に依頼しています．
◆その他:
この WG はエンジニアの成長がテーマです．転職を推進する意図はありません．
◆メーリングリストのアドレス: ss2019-et @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG10: 様々なふりかえり手法の効果的なシチュエーションを考えてみよう！
◆リーダ: 根本 紀之 (東京エレクトロン)
◆概要:
アジャイル開発のプラクティスとして，有名なものはふりかえりが挙げられます．アジャイル開発の一つであるスクラムでもレトロスペクティブとして定義されています．ふりかえりの手法としてはKPTが有名ですが，それ以外にもYWTやタイムライン，最近有名になっているFun Done Learnがあります．
今回は最初に代表的なふりかえりの手法を紹介します．その後，あるアクティビティを実践し，複数のふりかえりを実施します．最後に様々なふりかえりがどのようなシチュエーションで効果的なのかを参加者みんなでディスカッションしていきます．
◆想定参加人数:
10名前後◆参加の条件:
事前アンケートで今まで実施したことのあるふりかえり手法を聞きたいです．
◆運営方法:
最初にふりかえりの説明を行います． あるアクティビティを実施して代表的なふりかえりを実施します．
◆メーリングリストのアドレス: ss2019-re @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG11: 未来を切り開くソフトウェア教育の可能性を探る
◆リーダ: 米島 博司 (パフォーマンス・インプルーブメント・アソシエイツ)
◆概要:
ソフトウェアの教育においてぶつかる様々な課題について，参加者のテーマに関し全員で解決策を検討します．
また，創造的なソフトウェアエンジニアを育てるためには，幼少期からの創造性の育成が不可欠であることを前提にして，個人や関係する組織として何ができるかを議論します．
日本を変える，世界を変えるぐらいの意気込みで熱い議論を交わしたいと思います．
◆想定参加人数:
8名程度◆参加の条件:
ポジションペーパーの提出：5月31日（金） 以下の項目も含めてください． ・取り組んでいる教育実践・改革での課題（参加者で議論するため） ・個人/所属団体/SEAとして，幼児期，小中高生向けに未来のソフトウェア技術者を育てるために何ができるか．
◆運営方法・備考:
参加者が自分の課題を持ち込んで全員で検討するワークショップ形式．
◆メーリングリストのアドレス: ss2019-ed @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
WG12: 「ソフトウェア開発の現状と今後の発展に向けたディスカッション」
◆リーダ: 小笠原 秀人 (千葉工業大学)
◆概要:
今年も，ワーキンググループに参加しないという選択肢を用意していません．ソフトウェア開発に関するさまざまな発表をとおして，幅広く議論をしたいという方は，このワーキングを選択してください．途中での退席や途中からの参加もありとします．全参加者の発表が終わった時点で終了とします．
※ お願い：できるだけ議論したいテーマを決めて，他のワーキンググループに参加することをお薦めします．どうしても特定のテーマが決まらない場合は本ワーキングを選択してください．
◆参加の条件:
当日，20～30分の発表をお願いします．発表資料は当日までに準備してください．
◆運営方法・備考:
当日，自己紹介をしていただいた後，発表する順番を決めます．
◆メーリングリストのアドレス: ss2019-xs @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
TS1: エンジニアのための『質問力』（引き出す力）を伸ばすワークショップ
◆講師: 森 薫子 (株式会社 B)，玉城 理恵子 (富士通クラウドテクノロジーズ株式会社)，鈴木 史恵 (ことのは国語教室)
◆概要:
「開発遅延／障害報告がギリギリまで上がってこない」，「要件定義がいつまでも終わらない」などの課題に，皆さんはどう取り組まれていますか？
相手の持っている情報を『引き出す』質問力を身につけることで，必要な情報をより早いタイミングで得る工夫ができると考え，今回は『質問力』にフォーカスして体験型で学ぶ場を用意しました．相手の意見を引き出すコミュニケーションについて興味のある方のご参加をお待ちしております．質問の作り方に興味のある学生さんの参加も大歓迎です！
◆参加の条件:
ご参加の前提条件はありません．
◆運営方法・備考:
・質問の作り方講座（基礎～応用編まで） ・ツールを使った質問によるコミュニケーション体験
◆メーリングリストのアドレス: ss2019-qu @ sea.jp (ログを取得する方法については，こちらをご参照ください．)
メーリングリストのログを取得する方法
メーリングリストのアドレスの名前の末尾に "-ctl" を付加してこれを宛先として，メールの本文の先頭を get 1-last としたメールを送ると，ログを取得することができます．
例えば，“WG1 OSSこれからの20年を想像する”の場合，メーリングリストのアドレスが ss2019-os @ sea.jp ですから，宛先は ss2019-os-ctl @ sea.jp，本文は get 1-last となります．
このときに，メーリングリストに登録されたメールアドレスからしか取得できませんので，ご注意ください．
get の代わりに help を送ると，メーリングリストの使い方が返送されます．
