##はじめに　
2019年10月25日長崎県長崎市CO-DEJIMAにて開催された
「4th 長崎QDG」のイベントレポートを書きました！

レポート内容は、本イベント各セクション内容のポイントを主観でまとめたものです。
また各セクションの講演資料のリンクも掲載しましたので、ぜひご参照ください('◇')ゞ

(補足)
今回のイベントが私の人生初ITコミュニティ参加であり、
また、ブログ・SNS投稿等も不慣れなため、ご指摘・ご意見・ご感想あればぜひ連絡くださいませ。

###イベント紹介　「4th 長崎QDG」
※QDG：Software Quality and Development Gathering

公演テーマは↓の通り

派生開発
ソフトウェアテスト
開発技術
プロセス改善など

(補足)
イベント人生初参加＆ソフトウェア経験少ない私でも、
参加しやすい、アットホームな雰囲気のイベントでした(^^)/
また、CO-DEJIMAは、長崎市街からのアクセスも良く
頭が活性化するカラフルで素敵なデザインのワークスペースでした！
　← 今回の会場：CO-DEJIMA

4th 長崎QDG : https://nagasaki-it-engineers.connpass.com/event/122763/
スタートアップ交流拠点CO-DEJIMA : https://co-dejima.jp/

###主催コミュニティ紹介　「NaITE（長崎IT技術者会）」
長崎に縁のある技術者による技術コミュニティです。
長崎QDGやAgile japan 長崎サテライトを開催，その他長崎内外で勉強会やSIG活動に取り組んでいる。

(補足)
長崎とは無縁の私でも参加できました！
長崎＆都内等でも、精力的に勉強会等を開催しているようです！

###参加目的
日頃、ソフト開発に関する学習方法は、ネットor本なので、社外情報を得る機会がなかった。
そのため、社外のソフトウェア開発の動向、ソフトウェアテスト技術を学ぶために参加した。

#セッション

##「派生開発でDXの時代を生き残る　～「2025年の崖」への処方箋～」
【資料】https://www.slideshare.net/NaITE_Official/dx2025
###ポイント
IT化の浸透加速により分断されたサービスが繋がる！
しかし、ベースとなる従来の基幹システム（レガシーコード）からの派生開発時、課題あり！

【課題】ベースとなる従来の基幹システム（レガシーコード）の複雑化＆ブラックボックス化
【対策】派生開発技術の導入により、既存システムの可視化＆再構築
【派生開発技術の3本柱】
- XDDP(eXtreme Derivative Development Process) : (新規開発じゃない、派生開発やるんだから、派生開発に特化したアプローチで開発しよう)
- USDM(Universal Specification Describing Manner) : (要求と仕様の階層表現により、変更要求を具体的な変更仕様に漏れなく表現する)
- PFD(Process Flow Diagram)：(標準プロセスにこだわり過ぎてプロジェクトが遅延。そうならない為に、プロジェクトベースで必要な成果物と作業を定義し、その成果物と作業の関係を表して開発しましょう)

【参考資料】：
AFFORDD派生開発推進協議会　
http://affordd.jp/index.html
AFFORDカンファレンス2014 (PFDについて)　
http://affordd.jp/conference2014/affordd_conference2014_tutorial.pdf
AFFORDカンファレンス2015(USDMについて)　
http://affordd.jp/conference2015/affordd_conference2015_tutorial.pdf

##「UML Testing Profile紹介とテストアーキテクチャ開発のための拡張手法」
【資料】SlideShare : https://www.slideshare.net/secret/cWmHUhVndUzBFv
###ポイント

UML Testing Profile(以下UTP)を用いることで、UMLでテストに関する情報を記述可能。
UTPは、仕様、テスト目的、テスト要件、テストケースを表現可能。
しかし、UTP2.0では、テスト設計に必要なテスト観点の記述力がないという課題あり。

【課題】UTP2.0では、テスト設計で必要な"テスト観点"が表せない
【対策】テスト観点の一部「エンジニアの気がかり(Test Aspect)」に限定した記述方法を考案
【効果】Test Aspect明示の効果
- テスト要求やテストケースを導出可能
- 開発モデルの補完が可能
- 思考の可視化により、ステークホルダと知の共有ができる

##「スタートアップ企業が実践するクラウドネイティブアプリケーションの開発手法（仮）」
【資料】SlideShare : https://www.slideshare.net/YutaMatsumura/ss-186513850
###ポイント
DevOpsの活用事例紹介！
「スピード感をもってビジネスを進めるための技術を使う」というモチベーションでプロダクト開発を行っている。
運用・保守コストを抑える＆開発者が開発に注力するための開発効率化の事例。

【課題】複数の製品を少人数・高品質・低コスト・短納期で開発する必要がある
【対策と効果】
- Development :「.NET Core」
  - クロスプラットフォームで開発する
    - Windows,macOS,Linuxいづれの環境でも同じソースコードで実行可能
    - 複数の製品に対し同じソースコードをそのまま流用可能
- Operation :「Microsoft Azure」
  - クラウドを活用するメリット
    - ハード不要
    - 初期コスト軽減
    - アプリケーションの素早い展開
    - etc.
  - クラウドの種類　(オンプレミス, IaaS, PaaS, SaaS)とあり、フルマネージドサービスを推奨
    - プラットフォームのアップデートが自動で実施される
    - 開発者の保守対象外となる（メンテフリー)
    - 結果、本来の開発に注力可能
- DevOps : 「Azure DevOps」
  - コードとテストを実装すれば、自動的にクラウド上でデプロイ可能
  - 開発者は、開発に注力可能

##「テスト観点をうまく議論し使い回すためにできることを考える」
【資料】https://speakerdeck.com/omn/nagasakiqdg4th-test-viewpoints
###ポイント
「テスト観点」の定義はあいまい＆人によりイメージが異なる
テスト資産を組織で使いまわすためには、
テスト観点のイメージばらつきの排除とテスト観点の蓄積方法について考える必要がある。

テスト観点の曖昧さ
- 対象 : なにを表すのか
- 抽象度 : 具体値or抽象値
- 表現方法 : 自然言語orモデル
- スコープ : テストケースのことorテストケースより上流概念
- etc.
【課題1】テスト観点のイメージばらつき
【対策1】組織中でテスト観点の定義が必要
- 抽象度を上げた内容とする（ステークホルダーに説明可能な内容であることを意識）
- テスト観点導出の思考過程を記録する
- 以下、テスト観点の定義と考え方の参考
  - テスト観点は、「観点がそのまま、あるいは、具体化するとテストケースの構成要素となるもの」と定義。
  - 蓄積したテスト観点を「思考のヒント」とらえる
    - テスト観点を過剰な意識による思考停止を防ぎ、かつテストケースを作るうえでの有効なヒントとなる
【課題2】テスト観点を使いまわすために
【対策2】テスト観点の蓄積方法のポイント
- ツリー構造（例：マインドマップ）が効果的
  - テスト観点同士の関係性の特徴は、目的-手段、全体-部分、汎化などであるのでツリー構造表現が整理しやすい
- 蓄積するテスト観点が膨大化しないために、テスト技法（同値分割・境界値分析）で導出されるものは、"あえて"テスト観点には載せない

##「プロセス改善活動の光と影～CMMI レベル5 は何をもたらし、何をもたらさなかったのか～」
【資料】https://www.slideshare.net/NaITE_Official/stampstapfram

###ポイント
CMMIレベル5適応の事例紹介です!（CMMI : Capability Maturity Model Integration）
私にはやや難しい内容でしたので、理解できた範囲でまとめます。

【課題】
- 組織としてはCMMIレベル向上を目指し、CMMIレベル5を達成（CMMIレベル4「(定量的に)管理された」状態からレベル5「最適化された」状態を指す）
- 一方で、現場のソフトウェア開発者からはあまり「喜ばれなかった」
  - 【要因】
    - メトリクス分析（レビュー密度/レビュー速度等）により定量的FBでプロセス改善を促進していたが、設計・実装の質は上がらないため。
    - 開発者が求めたのは、設計・実装のプロセス改善
  - 【対策】
    - 設計プロセスの可視化
    - 開発者のスキルマップとスキルに応じた責任範囲の明確化
【教訓】
- プロセス改善は重要であるが、プロセス改善自体を目的にしてはいけない。
- 開発現場の意見・実態も取り入れながらプロセス改善を進める必要がある。

##「ソフトウェアテストでのSTAMP/STAPやFRAMの活用　～システムズエンジニアリングのモデリング手法の活用～」
【資料】掲載なし
###ポイント

私にはやや難しい内容でしたので、理解できた範囲でまとめます。
FTA/FMEAでは、システムのアクシデント・ハザードの識別が不足していたが、
STAMP/STPAやFRAMを用いることで、システムのアクシデント・ハザードを識別可能となる。

【従来】ソフトウェアテストでのFTA/FMEA
- FTA　: SWコンポーネント異常に対し、その要因を探る
- FMEA : SWコンポーネントの故障モードに対し、上位で発生する可能性のある影響を解析
【課題】
- FTA/FMEA は、要因(SWコンポーネント)に対し、アクシデント・ハザードをボトムアップ的にしか特定できない
  - システムレベルでは、不十分
【対策】
- STAMP/STPAやFRAM：SWコンポーネントの相互作用に着目して、アクシデント・ハザードを解析

SW : Software
STAMP : Systems-Theoretic Accident Model & Process ←システム論理に基づくアクシデントモデル
STPA : STAMP based Process Analysis ←STAMPを用いた安全解析手法
FRAM : Functional Resonance Analysis Method ← 機能共鳴分析手法（起源：レジリエンス・エンジニアリング）
FTA : Fault Tree Analysis
FMEA : Failure Mode & Effects Analysis
参考URL : https://www.ipa.go.jp/files/000065199.pdf

##「レビューの歩き方」
【資料】掲載なし

###ポイント
「レビュー」を実施する際に直観的に行ってしまうことよくあると思いますが、
このセクションでは、レビューの目的と効果的なレビュー（←非公開情報）についてお話がありました。
※講演者様のご都合で、情報公開は一部となります。

【レビューの誤解】
- 「レビューをしても品質は向上しない」（「悪さ加減がわかる」）ことを再確認
  - 指摘を受けた当事者のアクションにより品質は向上する
【レビューの目的】
- 開発工程のフェーズ移行判断（設計成果物の良し悪し判断）の関所だけが目的ではない
- 開発者の状況把握、問題点・ベテラン知見の共有などもレビュー目的となる

##「IoT機器のセキュリティの評価方法」
【資料】OneDrive : https://onedrive.live.com/?authkey=%21ABDUsaaFTp1gn4Q&cid=86B5B215F14AA34B&id=86B5B215F14AA34B%2198974&parId=86B5B215F14AA34B%2198968&o=OneUp

###ポイント
近年、IoT化が進み、サイバーセキュリティリスクや脅威が増している。
しかし、開発者の多くが、その知識と対処の経験が不足している。
そこで、JPCERT/CC「IoTセキュリティチェックリスト」を用いることにより、
最低限のセキュリティ機能実装項目とテスト項目を確認できるとのこと。
この講演では実際のIoTモデルを用いた演習があり、システムのどこに脆弱性があるのかを議論。

【セキュリティテスト】
- 「（一般的な）ソフトウェアテスト」と「セキュリティテスト」は性質が異なる
  - ソフトウェアテストは、「正常系テスト」＋「異常系テスト」
  - セキュリティテストは、「異常系テスト」（ペネトレーションテスト）のみ
- ペネトレーションテスト
  - IoT機器のセキュリティ脆弱性に対する侵入テスト
- 脆弱性との向き合い方
  - 既知の脆弱性への対策
    - 直接対策＆他の脆弱性を発想
  - 未知の脆弱性への対策は
    - 未然対策が不可能（既知の脆弱性の組み合わせは、無限大にあるため）。
    - 常に、最新の脆弱性事例にアンテナを張る。
【セキュリティテストの進め方】
- まずは、最低限のチェックリストを用意してテスト
  - JPCERT/CC公開する「IoTセキュリティチェックリスト」 : https://www.jpcert.or.jp/research/IoT-SecurityCheckList.html
- さらなる、テストを行う場合は
  - システムの構成から、「自分が悪意のある人物ならどう突破するか」という視点で考える
  - 特に、データの流れ、データの中枢を中心に突破口を考える

キーワード
派生開発、テスト観点、UTP、CMMI5、テスト観点、可視化（思考、やること）、セキュリティ
ツールを使う（開発に専念）、安全性、レビュー

##まとめと所感

ソフトウェア開発の動向：派生開発が主流!

これからのサービス開発は、新規開発(無からのソフトウェア開発)は主流ではなく、派生開発(基幹システム（レガシーコード）をベースに追加・変更する開発)が主流である。
　
派生開発の難しいところは、基幹システムのソフトウェア仕様を、
担当メンバがすべて把握するのが困難であること。(最悪、不可能。)
部分理解で追加・変更をしていては、どこかしらで欠陥を作り込んでしまう可能性が高い。
つまり、基幹システムの全体理解はマスト！
基幹システムの関連成果物が最悪の場合、ソースコードのみの可能性も考えると、
ソースコードから仕様の情報を得られるツールの活用はとても重要と思う。(ソースコードは必ずあるので。)

###　ソフトウェアテスト技術の動向：ソフトウェアテストの基本的な概念と用語は、とても重要！
ソフトウェアテスト初学者の私ですが、今回のカンファレンスで
今まで「テストをやる」と一言で語っていたものが、一言では語れないものであることを強く実感しました。
　
例えば、「テストをやる」という行為も「テスト計画」「テスト分析」「テスト設計」「テスト実装」「テスト実行」「テスト完了」のように、テストプロセスに分解し、各プロセスで実施することを把握して、段階的に実施する必要があります。
　
また、それに関連して、各テストプロセスで入力・出力となる情報には、専門的な用語が用意されていて、テストエンジニアとして、今後、専門的な用語を理解できていないと議論にすらならないということを痛感しました。
ということで、まずは、JSTQBFLの取得目指します！

社外イベント初参加の感想 :

###その① : 「課題」、「関心事」が広がり、次学習へのモチベーションアップ！
今までは、社内業務を通じて見つけた「自分の課題」、「関心事」に対して、本やインターネットで勉強をする社会人生活でした。しかし、社内業務も慣れてくると、「自分の課題」、「関心事」への気づきが減ってきました。

そんな中、今回、4th長崎QDGに参加し、講演者の方の発表を聴いたことがとても良い刺激となり、「自分の課題」、「関心事」が広がりました。
今回得られた「自分の課題」、「関心事」をもとに次の学習に繋がると確信しています！

###その② : イベント参加、ぜんぜん怖くない！　初学者もバンバン参加すべき！
私は、ITイベントは自分とは遠い世界だと思っていました。
抱いていた印象は、「知らない人たち、怖い。。。」、「なんか難しそう」、「初学者にはしんどそう」などなど。

しかし、参加してみると、印象とは違い
友好的な人ばかりで、技術的な内容なので難しくはありますが、
初学者にとっても「自分の課題」、「関心事」を見つけるのに最適な場所だと感じました。
そう思わせてくださった　NaITE（長崎IT技術者会）の皆様、本当に感謝です(ToT)/~~~

情報交換会

イベントに加えて情報交換会＋αがあり、参加者の皆さんとはとても勉強になる&楽しい時間を過ごさせて頂きました!(^^)!

イベント前夜祭
情報交換会（イベント打ち上げ）
エクスカージョンツアー(長崎観光)

　← 長崎中華街　江山楼

　
↑ 左：長崎ちゃんぽん / 右：皿うどん（太麺）

　
　↑ 眼鏡橋　with 秋の心地よい風　　　　　　　　　↑出島を観光

　← 巨大パフェ120cm vs NaITE 9名→ NaITEの勝利(^^)/