ソフトウェア・シンポジウム 2017
ワーキンググループ・チュートリアル

ソフトウェア・シンポジウム 2017 で 12 年目を迎えるワーキンググループでの活動は,ソフトウェア技術にまつわるさまざまなテーマや課題に関する発表,議論を行うことで,参加者やグループがそれぞれの方向性を見いだしていくための場です.昨年から継続して,参加者のさまざまな要望に応えるために,ワーキンググループ (Working Group : WG) の他に,チュートリアル (Tutorial Session : TS) も用意しました.

また,昨年と同様,今回もワーキンググループに参加しないという選択肢はありません.特定のテーマが決まらない方は,WG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」を選択してください.このワーキングでは,特定のテーマを決めず,参加者からの発表をベースにしたディスカッションを行います.

WG名前
1 (AJ) アジャイルの振り返りを、自分達の強みで進化させよう!
2 (TP) テストプロセス改善モデルを理解する-TPI NEXT(R)を例に-
3 (FM) 仕様で書きたいことと形式仕様で書けること - 道具としての形式手法 -
4 (AI) 人工知能技術のソフトウェア開発プロセスへの応用 ~AIはソフトウェア開発を変えるか?~
5 (ED) AI時代のソフトウェア技術者教育
6 (DE) ソフトウェア欠陥エンジニアリング
7 (ET) エンジニアのトリセツ ~やりがいのある職場と育成~
8 (SE) Software Evolution,保守こそもっと自由に・柔軟に!
9 (RD) 要件開発を開発する
10 (QU) ソフトウェア品質保証の温故創新
11 (ST) システム理論に基づくSTAMPでのモデリング
12 (FR) 機能共鳴分析法 (the Functional Resonance Analysis Method, FRAM) とシステムズオブシステム (Sytems of System, SoS)
13 (SD) ソフトウェア開発の現状と今後の発展に向けたディスカッション
TS名前
1 (CM) 開発における情報伝達を見直す

(順序不同,英字二文字は略称)

WG1: アジャイルの振り返りを自分達の強みで進化させよう!

リーダ: 日山 敦生 (緑ビジネスコーチ研究所)

概要:

最近,感じることは,日本のビジネス,元気がない.イノベーションは,弱点克服のビジネス文化からではなく,強みを活かすビジネス文化から生まれると思っています.イノベーションとマネジメントで有名なドラッカーも著書で「組織の目的は,人の強みを生産に結びつけ,人の弱みを中和することにある.」(出典:マネジメント[エッセンシャル版])と述べています.

そこで,アジャイルの振り返りに焦点をあて,強みを活かしたポジティブな振り返りをご紹介します.

振り返りのフレームワークであるKPT(Keep,Problem,Try)は,アジャイルを初めとするソフト開発でよく使われています.そこで,強みに活かすポジティブ心理学(解決志向アプローチ)を応用して,KPTの進化系として,ROTT(Recycle,Organizational problem,Technical problem,Try)をご紹介します.特徴は,失敗の責任追及ではなく,成功の責任追及を用いた「自分達が既に出来ていることの再利用(Recycle)による強化」と「問題を,人や組織の問題(Organizational problem)と技術の問題(Technical problem)に分けて,人や組織の問題は,原因を後から考える問題解決法」を使います.

具体的には,成功要因として,「顧客と信頼関係が築けた」であれば,自分達のどのような行動が,顧客と信頼関係を築くことに有効であったかを分析し,次のイテレーションに,再利用する方法です.問題解決では,A部署が非協力的で困るという問題であれば,問題に焦点をあてるのではなく,希に起こるA部署が協力してくれた時に焦点をあて,どのような条件が揃うと協力してもらえるのかを,明確にする方法です.

出来ないことを,出来るようにするためには,時間が掛かります.ところが,他人ではなく自分が既に出来ていることは,すぐに使えるということです.

ROTTによる振り返りは,問題の再発防止を目的とする問題のなぜなぜ分析に対して,成功の再発促進を目的とする成功のなぜなぜ分析だと思っています.

アジャイルに限らず,プロジェクトの振り返りに,関心をお持ちの皆様の参加をお待ちしています.

参加の条件:

運営方法・備考:

自分達の強みを活かすための理論・技法をご紹介し,自分達の強みを活かすための技法を,ワークショップ形式で,習得を図ります.

ワークを通じて,参加者全員で,対話による学びを行います.

メーリングリストのアドレス: ss2017-aj @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG2: テストプロセス改善モデルを理解する-TPI NEXT(R)を例に-

リーダ: 河野 哲也 (日立製作所/ASTER テストプロセス改善研究),高野 愛美(日立製作所/ASTERテストプロセス改善研究会),浦山 さつき(ウェブレッジ/ASTER テストプロセス改善研究会)

概要:

本WGは,ASTER テストプロセス改善研究会の企画で運営します.

テストプロセス改善モデルの一つである,TPI NEXTを取り上げて,テストプロセス成熟度評価のためのチェックポイントについて議論します.具体的には,TPI NEXT のいくつかのキーエリアを取り上げてそれらのチェック項目に対してDFDやPFDでプロセスを表現するグループワークを実施します,

導入で簡単な説明を行いますが,後はひたすらグループワークを進めます.プロセスで表現することで以下につながると考えています.

参加の条件:

主にテストプロセスについて議論するためテストやQAの業務に携わっている方を対象とします.もちろん,上記を勉強したい方も歓迎します.当日,簡単な自己紹介してもらいますが,ポジションペーパの提出は必要ありません.

運営方法・備考:

(進め方):

メーリングリストのアドレス: ss2017-tp @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG3: 仕様で書きたいことと形式仕様で書けること - 道具としての形式手法 -

リーダ: 張 漢明 (南山大学), 酒匂 寛 (デザイナーズデン)

概要:

ソフトウェア開発における形式手法の有用性は認知されつつあるが,形式手法の意義,特に形式仕様の意義について正しく認識されているとは限らない.これは「形式」という言葉が含意する「数学的で難しい」という認識によるものと考えられる.

本ワーキンググループでは,実際のソフトウェア開発現場で抱えている仕様記述の問題について,「形式仕様」の観点からできることとできないことを明らかにする.実際のソフトウェア開発現場の具体的な問題を題材として,「仕様記述」と「形式的なアプローチ」の観点から議論することにより,形式仕様の意義について参加者の間で互いに理解を深め,形式仕様の実用化の課題を提示することを目指す.

参加の条件:

以下のいずれかに該当する方を参加者の条件とし,事前にアンケートを実施して当日の議論の材料を提供してもらう.

運営方法・備考:

事前 当日

メーリングリストのアドレス: ss2017-fm @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG4: 人工知能技術のソフトウェア開発プロセスへの応用 ~AIはソフトウェア開発を変えるか?~

リーダ: 植月 啓次 (パナソニック),松尾谷 徹 (デバッグ工学研究所)

概要:

近年のAI(人工知能)技術の発達にともない,世の中にはさまざまなビジネスアプリケーションが誕生しています.特に推論や機械学習を活用したアプリケーションは,私たちの身近な存在となってきました.

では,ソフトウェア(システム)開発プロセスの分野では,AI技術の活用はできるのでしょうか.例えば,UIのテストでは,推論による画像認識技術を使ったテストスクリプトの自動生成といったアプリケーションが現れています.

このWGでは,AI技術をソフトウェア開発プロセスに適用するための方法論について,関連するツールや応用事例の紹介を通じて議論します.なお,ここでのAI技術のスコープは,情報検索や画像・音声認識などの応用分野から,機械学習や推論といった基礎的な分野まで幅広く考えたいと思います.

参加の条件:

ポジションペーパーの提出(スライド 1~2枚)

運営方法・備考:

メーリングリストのアドレス: ss2017-ai @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG5: AI時代のソフトウェア技術者教育

リーダ: 米島 博司 (パフォーマンス・インプルーブメント・アソシエイツ),辻 達諭 (L&Cトレーニング株式会社)

概要:

近年とみに話題になってきた人工知能はコンピューターの持つ圧倒的な情報蓄積量と情報処理速度により,将棋などのゲームだけでなくソフトウェア開発の領域まで応用され,プログラマーにとって脅威となるなどと言った議論まで交わされるようになってきました.

そうした議論はさておき,コンピューターの持つその情報量や処理速度が高度な技術力要する業や、その学習を支援するという意味で近い将来かなり大きな役割を果たすことになることは間違いないでしょう.

こうした背景の中,人工知能を開発業務の支援ツール、また技術力育成リソースの一つとして捉え,その機能を最大限活用する必要性が生じてきています.今回のフォーラムではソフトウェア開発における人工知能の持つ可能性を探りながら,未来のソフトウェア開発や、そこで果たす人間技術者の役割はどんな姿になるだろうかを描き,その有効性を議論・検証します.

参加の条件:

ポジションペーパー (スライド 1 ~ 2 枚程度) の提出を必須とする.基本的に参加者はスライド一枚程度のポジションペーパーを 5 月末までに提出する.

運営方法・備考:

基本的に参加者自身の事例や研究を持ち寄って発表し,参加者全員で意見交換,議論によって相互研鑽を行う.

メーリングリストのアドレス: ss2017-ed @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG6: ソフトウェア欠陥エンジニアリング

リーダ: 細川 宣啓 (日本アイビーエム株式会社 東京基礎研究所)

概要:

各種ソフトウェアエンジニアリング技術のうち,本ワーキンググループでは,研究が十分とは言い難いソフトウェア欠陥そのものに焦点を当て,

などを行って参ります.「基礎知識」は体系化されたものが少なく,広く頒布すべき教材と考えます.またソフトウェア欠陥に関するcommunityも募集します.是非ご参加ください.

参加の条件:

ネットワーキングを目的としたオープンなディスカッションの場です.特に条件はありません.

運営方法・備考:

講義形式+ディスカッション形式

メーリングリストのアドレス: ss2017-de @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG7: エンジニアのトリセツ ~やりがいのある職場と育成~

リーダ: 森本 千佳子(東京工業大学),増田 礼子(フェリカネットワークス),東村 高良(関西大学), 松尾谷 徹(デバッグ工学研究所)

概要:

多くの職場や教育の現場において,悲痛な叫びを聞くことが増えている.叫びの多くは,日々の仕事として,その活動の意味が見いだせない無駄な作業に忙殺されていることから生じている.この現象は現代の若者に我慢が不足していると切り捨てる管理職も存在するが決してそうではない.

製品開発やサービス開発において,付加価値を生み出すのはクリエイティブな人的資源と彼らを活性化する自由な職場環境が必要なことは,成功している企業を観れば明白である.彼らには「やりがい」など内的報酬がないと力を発揮することができない.

しかし,多くの現場レベルのマネジメントは規範的な側面が詳細に強化され,厖大な手続き的な作業を押し付けるマイクロマネジメントが蔓延している.

結果的に,付加価値を生まない活動にクリエイティブ人材を投入することになり,当然,付加価値が生まれないばかりか,人材を疲弊させ組織自身をも衰退させている.

この現状を明らかにし,この流れを断ち切るための提案として「エンジニアのトリセツ」とその背景や実践について議論する必要がある.

議論する内容は,エンジニアの勝手な権利主張では無く,社会や経営側に対する「この度はこんな私を選んでくれてどうもありがとう」 に対応するエンジニアの義務と貢献を前提にする.トリセツの中身は,職場の現状により色々バリエーションがあるが,基本はエンジニアの仕事満足調査から得られた内的報酬と呼ばれる仕事意欲の素である.

以上について,エンジニアの立場(ボトムアップ的)から,業界や学界の合意形成をすすめるための枠組みを議論します.

参加の条件:

特になし

運営方法・備考:

Future Presentation での提案を受けて,「エンジニアのトリセツ」に関して意見交換と展開のアイデアを練る.

メーリングリストのアドレス: ss2017-et @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG8: Software Evolution,保守こそもっと自由に・柔軟に!

リーダ: 三輪 東 (SCSK, SERC, SEA)

概要:

Software Evolution の現場では,Agileやスクラム,漸進型ライフサイクル,チケット駆動の利用,devopsの導入など,便利なものを取り入れながら進化を遂げています.

「えっ、そんな使い方してるの?意外だけど確かにありだね」これこそ Software Evolution の面白いところです.

新たな手法を保守に取り入れたいが悩んでいるみなさま,保守について悩みを抱えていたり意見をお持ちの方,ざっくばらんに情報交換してみませんか.意外なヒントが見つかるかもしれません!

明日のMaintenance,Software Evolution について一緒に考え,それぞれの現場のNEXT STEPを皆で考えてみる,そんなワークにしましょう.

参加の条件:

ソフトウェア保守,ソフトウェア保守開発,Software Evolutionにご意見・ご興味のある方.

ポジションペーパの提出をお願いします.簡単で良いので,自己紹介,日ごろの悩み,議論したい内容や興味のある分野を事前に提出していただきます.

運営方法・備考:

参加者のみなさまのSoftware Evolution の共有からはいり,現場で実践したい手法や解決したい悩みを集めます.その中からテーマを設け,参加者のヒントをもらいながら,導入までのストーリーを作っていきます.

皆様の理解をサポートするワークショップやアンケートを活用し,具体的な作業を支援する運営を予定しています.

メーリングリストのアドレス: ss2017-se @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG9: 要件開発を開発する

リーダ: 田中 康 (有限会社ケイプラス・ソリューションズ,奈良先端科学技術大学院大学,大阪芸術大学,東京工業大学)

概要:

注文通りに家を建てるだけではなく,どのような家にするかを住む人と一緒に考えることも(ことこそ)建築家の重要な仕事である.2000年にリリースされたCMMIでは,エンジニアリングプロセス領域として「要件開発プロセス」が追加された.要件を獲得して分析して定義するという視点から「開発する」という視点へ,要件自体をデザインすることもエンジニアリングの仕事であるということである.

昨今では,新事業開発が企業の重要課題となる中,産業の基盤を担っているIT技術者に対しても,新サービス開発などの価値創造の活動が期待されている.一方で,CMMIのレベル3以上を取得していても,実際的な要件開発のプロセスを実装できている組織は少ないのが現実ではないか.

要件開発プロセスは学際的な技術領域であり,情報工学のみならず,デザインや社会学,認知科学といった様々な分野からの議論が必要だと考えている.

本ワーキングでは,要件開発プロセスに係る技術に関して,情報領域のみならず,他分野の実践者にも声がけをして,学際的な視点も取り入れた継続的な議論の場にしていきたいと考えている.

また,参加者の同意が得られれば,継続的な議論を進めていきたい.

参加の条件:

WG当日,要件開発プロセスへの取り組み,期待,疑問等,ご自身の興味や関わりなどに関して,一人10分程度でポジションを発表していただく.

運営方法・備考:

SS2017でのゴール:
・本WGとして継続的に議論すべきテーマを選定する

予定アジェンダ:
1. 参加者ポジション報告
2. 要件開発プロセスの背景,論点などに関して(WGリーダー)
3. 要件開発ワークショップ体験(システムのプロセスモデル視点からの要件開発方法(PReP model)によるワークショップ;予定テーマ「タクシー配車」)
4. ワークショップ実践通して,議論すべきテーマに関する議論とまとめ

メーリングリストのアドレス: ss2017-rd @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG10: ソフトウェア品質保証の温故創新

リーダ: 奈良 隆正 (NARAコンサルティング),宮田 一平 (SHIFT)

概要:

ソフトウェア開発の現場においては,様々な技術を用いて,ソフトウェアの品質向上に努めている.品質の高いソフトウェア開発のため,過去様々な品質保証のための手法が生み出されてきた.

代表的なものは以下の通りである.

ただし,様々な手法が存在するにもかかわらず,思うような品質が出ずに苦しんでいる現場も多いことも,また事実である.

このワーキンググループでは,ソフトウェア品質の向上につながるアイデアや事例を共有し,議論する.参加者がこうしたアイデアを現場に持ち帰り,実践することができることを目的とする.

参加の条件:

ソフトウェア品質向上のためのアイデアや事例を,事前にポジションペーパーとして提出いただきます.参加条件は特にありません.(若手歓迎)

運営方法・備考:

まず,参加者の認識を合わせるため,ソフトウェア品質保証に関する歴史・概論を共有します.その上で,参加者の皆さんにポジションペーパーを発表していただき,内容に関する議論を進めていきます.

メーリングリストのアドレス: ss2017-qu @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG11: システム理論に基づくSTAMPでのモデリング

リーダ: 日下部 茂 (長崎県立大学)

概要:

従来の解析的還元論や信頼性理論ではなくシステム理論に基づく事故モデルとしてSTAMP(System Theoretic Accident Model and Process)が提唱され,代表的な分析法STPA(System-Theoretic Process Analysis)と合わせて,その有効性が着目されています.STAMPは安全工学の知見を広く適用できるように意図されており,いわゆる組込みシステムのようなものだけでなく人や組織も含めたかなり広い問題にも適用可能とされています.しかしながら,汎用性の高さから逆に具体的な適用に関してはある種の難しさもあるとの声もあります.本WGではこのような背景を踏まえて,STAMPでのモデリングに,取組み済み,取組み中,取組み予定の参加者の間で,STAMPのモデリングについてディスカッションし,知見を共有しようとするものです.(予備知識全くゼロからのチュートリアルなどは想定していません)

参加の条件:

取組み済み,取組み中,取組み予定のSTAMPでのモデリングについてA4一枚程度のポジションペーパを提出(得られた、もしくは求めている適用の知見が言語化できるようであればそれが書かれているとより助かります)

運営方法・備考:

詳細未定

メーリングリストのアドレス: ss2017-st @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG12: 機能共鳴分析法 (the Functional Resonance Analysis Method, FRAM) とシステムズオブシステム (Sytems of System, SoS)

リーダ: 羽田 裕 (日本電気通信システム),落水 浩一郎 (University of information Technology, Myanmar)

概要:

ホルナゲルが提案した,機能共鳴手法(FRAM)は,社会技術システムの事故解析,リスク評価を実施するための系統的な手段である.レジリアンス・エンジニアリングを実現する代表的な手法であり,情報システムの安全性解析に有用である.本ワーキングでは,システムズオブシステム(SoS)の定義と問題点を紹介し,FRAM手法の考え方と手法を紹介したのち,いくつかの典型的な問題の解決を試みる演習を通じて,FRAM手法を習得しつつその有効性を確認する.

参加の条件:

  1. PC (Win7/8, Ubuntu, Mac) 持参.
  2. 上記1のPCにツールFMV(FRAM Model Visualiser)をインストール済.
    当日インストール媒体を用意しますが,できるだけ事前にインストール願います.別途,参加者にインストール方法をご連絡します.

運営方法・備考:

メーリングリストのアドレス: ss2017-fr @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

WG13: 「ソフトウェア開発の現状と今後の発展に向けたディスカッション」

リーダ: 小笠原 秀人 (東芝)

概要:

昨年から継続して,今年も,ワーキンググループに参加しないという選択肢を用意していません.ソフトウェア開発に関するさまざまな発表をとおして,幅広く議論をしたいという方は,このワーキングを選択してください.途中での退席や途中からの参加もありとします.

なお,参加者が集まらずに開催できないワーキングがあった場合には,本ワーキングに吸収します.

参加の条件:

A4で4ページ以内にご意見(ご自身が関わっている,あるいは興味を持っている内容に関する悩み,アイデア,成果,計画,疑問など何でも)をポジションペーパとしてまとめ,投稿してください.また,当日は,投稿されたポジションペーパをベースにした発表をお願いします.

運営方法・備考:

初日は,投稿されたポジションペーパから事前にプログラムを決めて,発表と質疑応答を繰り返します.2日目は,初日に発表&議論した内容からいくつかの話題に絞り,議論を中心として進めていきます.

メーリングリストのアドレス: ss2017-sd @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

TS1: 開発における情報伝達を見直す

講師: 玉城 理恵子 (富士通クラウドテクノロジーズ株式会社),鈴木 史恵 (専修大学松戸高等学校,ことのは国語教室),森 薫子 (株式会社 B)

概要:

「ちょっと茶色い犬の家を壊してるからそちら次第で答えられるかな.」

この文から,読者であるあなたは何を思うでしょうか.

「ちょっとだけ茶色い犬」「の」「家」「を」「壊している (壊す仕事を行う予定だ)」から,「(家の取り壊しが終わる時間次第で) 答えられる」でしょうか.

あるいは,「今はちょっと」「茶色い」「犬の家」「を」「壊している (最中だ)」から,「(仕事が終わり次第) 答えられるかもしれない」でしょうか.

または,「ちょっとだけ茶色い」「犬の家」「を」「壊している (人がいる)」から「(その人の仕事の予定次第) で」「答えることができるかもしれない」という解釈も可能かもしれません.

日々の開発の仕事において,情報伝達は,前提や立場が異なる様々な関係者間で無数に行われ,伝達の齟齬が,開発の成否や期間に影響を及ぼします.

その伝達をできるだけ正確に行うために,どう表現を整理し,そして,問いかけを行っていくと効果的なのでしょうか.

このチュートリアルでは,正しく伝える,正しく伝わる,正しく受け取る工夫について,参加者の皆さんと一緒に考えていきたいと思います.

参加の条件:

ご参加の前提条件はありません.

情報の伝達に関する技術や心のあり方に悩んでいる方,工夫している方,日々,日本語で仕事に携わっている方のご参加をお待ちしております.

メーリングリストのアドレス: ss2017-cm @ sea.jp (ログを取得する方法については,こちらをご参照ください.)

メーリングリストのログを取得する方法

メーリングリストのアドレスの名前の末尾に "-ctl" を付加してこれを宛先として,メールの本文の先頭を get 1-last としたメールを送ると,ログを取得することができます.

例えば,“WG1 アジャイルの振り返りを、自分達の強みで進化させよう!”の場合,メーリングリストのアドレスが ss2017-aj @ sea.jp ですから,宛先は ss2017-aj-ctl @ sea.jp,本文は get 1-last となります.

このときに,メーリングリストに登録されたメールアドレスからしか取得できませんので,ご注意ください.

get の代わりに help を送ると,メーリングリストの使い方が返送されます.