はじめに
へ行ってきました。
参加したのは2月15日（木）だけ。
聴講しながら書き込んだメモとか感想を無加工で放流。
ソフトウェアセキュリティ
チャットによるUIがイノベーションになった
たしかに、IFとしてチャットというか自然言語を使えるのは大きいと思う。
RAG
LLMへの問い合わせにProxy的に情報を付加するみたいな感じかな？ （あとで調べる）
プロンプトインジェクション的な攻撃
「これまで言ったことを忘れて」
LLMのセキュリティリスクTOP10
これを見ると何が攻撃対象になるのかというのがわかるので目を通すと良い
自動化による過度の信頼
「なぜ、それをしたのか」というところが分からないことをしてしまうことがありえる。。 勝手な商品購入とか、メインルータを止めてしまうとか 「いや、そこまでやったらだめ」ということは、AIとは別のところできちんとブロックする必要はありそう。
全部をAIだけではなくて、セーフティーネットはハード側の設定で変更不可なところで止めるみたいなことをあわせ技でできる仕組みをきちんと設ける必要性
Human In the Loop
チェック、改善の中に「人」を入れることを忘れないように、ということ
リスクベースアプローチ
考える必要あり
WebシステムやモバイルアプリにおけるUIからの自動テスト事例３選
自動テストの山は２つ
「はじめる」「継続する」
初期構築がすぐにできない
テストをリファクタリングできない（テストのメンテンスで疲弊）
環境の変化
テストはバグを見つけるものではなくフィードバックを得る手段
技術の変遷
大きいのはテストの実行環境
実機からWorkspaces、Dockerへ
テストケース管理はエクセルが結局王道（？）
何を自動テストする？
リグレッションテストの充足
基本的な機能を確認する
落ちると致命的なもの（重要度が高いもの）
手動テストでコストが高いところ
テストピラミッド
Unit:Service:UI = 7:2:1
この「1」を満たすことを目標にする
最初のテストケースが回るようになるまで3Week
慣れている専業でも対象の選定から実行までそのくらい時間かかるというのは１つの目安になりそう。
UIのテストを増やすのではなく、Integrationテストを増やすように
UIを増やす方向にすると破綻しやすい
（UIとIntegrationテストの違いを学ぶ必要もありそう？）
テストケースは適切に分割
基準は「時間」
10分を超えるテストは分割すること
テストツールで拾える情報を実装に組み込む
Appiumで認識できるIDを入れる
いれないと、場所の特定で失敗してしまってテストが安定しない
自動テストは属人化がキモ
担当者をちゃんと決めないと「誰もやらない」になって継続ができない
不安定なテストは能動的に捨てる
自動化が安定しないものを延々とメンテナンスするのでは、結局「手動」のほうがハンドリングしやすいということ
ケースを最適化をする
「ただ追加していく」ではなく、適切な規模をキープするように精査（減らす）というメンテナンスも大事
サービスの危機に立ち向かうリーダーシップ
PagerDuty
インシデント全体を分析と改善する
インシデントコマンダー
SREと同じくらいの位置づけになると思っている
言葉の整理
インシデントは「状態」not = 「障害」
参照
事業価値とエンジニアリング・リソース効率性とフロー効率性
（リクルートの公開資料）
インシデントコマンダーはボトルネックになる
これはなるべくしてなる
PageDutyで可視化して、俯瞰力をツールで補完する
PagerDutyでWar Roomを作って情報を集める
コミュニケーションは、ブロードキャスト型にする
インシデントコマンダーはCEO/CIO（すーてくホルダー）に対するメンバーの壁役
対応者の手を止めないのが大事
RUNDECK
自動実行スクリプトエンジン
ポストモーテム
きちんとまとめて組織としての成長につながるものまでやるのが大事
インシデントコマンダーになれる人
（後で資料で） イメージとしてはSMに近い印象をもった
教育・育成についてもPagerDutyで公開しているので参考にすると良い
AIの利用
データが集約されているので、そこからLLMで「文章化」してレポートを読めるという仕組み
要約を作るのはLLMの得意分野だと思うので有効活用できるところだと思う
知識ゼロから学ぶAIのテスト（信頼できないソフトウェアとそのテストのために）
書籍「ソフトウェアテスト」で扱えなかったAIテストについて
30年でテストの費用は減っていない
工数内の46%がテスト費用
おそらくAIで更に増えるかも？
Copilot活用
生産性は上がる、コードの凝縮度も上がるけど、コードレベルは良くないかも
テストの生産性は上がるわけではない
AI自体をテストするのは困難
シフトレフト
（初耳だった・・・）
原因工程で不具合を見つけると、後工程で見つけるよりも費用は低くなるよ
だから「シフトレフトしよう」という話
シフトライトせざるを得ない背景
AIは事後教育の結果でテスト結果が変わってしまうので「初期の想定」と 違う結果が起きるのは自然な話ではある
シフトライトは以前からある話
パフォーマンステストとか、出来上がらないとできないテストは以前からある
AIのテストの難しさ
サンプリングデータによるバイアスが発生しがち
＝白人データに偏りがち
さて、、これを「バグ」というべき？みたいな。 かとって、人口比率にあわせても、たぶん「求めているもの」とは違うかも。
非常にウェットなものなので、理系学問というよりも文系学問に近しい分野
ADAS
自動運転による危機回避はトロッコ問題的なものもAIのテストの難しさ
AIのテストは自動化が難しい
IOが安定しない（期待値が安定しない）
AIによるバイアス問題は、機能テストでも非機能テストでもない
AIテスト手法
ニューロンカバレッジ
役に立たないわけではないが、気休めよりもちょっとマシくらいのいうところ
メタモリフィックテスト
これが現時点でもまともなテスト手法
データポイソニング
モデルデータに対する攻撃
起こり得ることとしては、道路標識にノイズを入れて「通行止め」を「通行可」にしてしまうことができてしまう。
テストの自動化が成功する確率はそもそも低い（by Rex Black）
プラスのROIを達成していないというのが実態とのこと
AIのテストはリリースしたところが「始まり」
あくまで初期設定に近くて、その結果を分析・改修を繰り返すことになるから
AIを活用した誰でもテストが自動化できるプラットフォームの実現に向けて
モバイルのテストは画像に依存する
これはAMのセクションでも言っていた。
このあたりはテストをE2Eで実行するときに覚えておいたほうが良いかも
LLMの登場で抽象度の高い作業ができるようになった
これまでできていたのは「操作」に対してのテスト
これからは要件分析やテスト計画といったところをテスト出来るようになってきた！
LLMの問題
ハルシネーション（嘘を付く）などなど。
結局のところ最終的には「人」によるレビューは必須
あくまで作成は自動化はできるけど、それをチェックするのは必要
そして、それには高いスキルが必要というジレンマ
LLMの活用：テストすべきことの提案
これであれば「何をテストすべき？」を考えることをLLMで補完するアプローチ
これならLLM問題よりも安全な使い方
これまでテスト経験知でカバーしていたところをAIに補完してもらうアプローチ
LLMの活用：テストのシナリオの要約
テストケースはどうしても人間には読みにくい
LLMによる要約によって「人間に読みやすい文章化」をしてもらう
これはインシデントコマンダーのところでもあったところ
この「要約する」というのはLLMの強みと考えて良さそう
LLMとこれまでの機械学習の差
LLMは抽象度の高い問題解決（文系的なもの？）
機械学習は特化型の問題解決（理系的なもの？）
という強みの違いがある
レガシーモダナイゼーション
モダナイゼーションの提案はほぼジオゲッサー
よくわからないところに落とされて、ヒントを探して推測してゴールに到達する
推測が間違っていると…
現在地が違うと課題もずれる
課題がずれると解決できない
戦略的ドメイン駆動
アーキテクチャとかVOは戦術的DDD
コンテキスト分割とかドメイン分析が戦略的な方
戦略的DDDは地図に例えるとわかりやすい
逆に言うと全体の課題（システムとか関係なく）を把握しないと、解決したい課題に正しくたどり着けない
「線引の外」が結局線引の中の問題解決に繋がらずデスゲーム
地図に山や川に名前をつけるように、名前をつけることで初めて「地図」になる
名前がないと「経度緯度」
これでは誰もわからない
戦略的DDDで得られること
全体像を全員で把握
適切な名前付け
適切な属人性の把握（＝ステークホルダー）
アプリケーションシンプリファイ
ルール駆動開発
これ、製品がなくなったのでこの表現はつかえなくなったみたい（？）
死にロジックを捨てるためのアプローチともいえる
なので、既存のソースコードを見ない
７年間１０００件の生涯事例から分かった障害対応の改善ポイント
まずできる改善ポイント
大事なこと
サービス視点（システム視点ではない）
アクション（事象ではない）
情報の質（量ではない）
サービス視点
使う側にとって、何が必要？に対して適切なアンサーをすることが大事
アクション
事象はシステム毎に多岐にわたるけれど、すべきアクションはパターン化されていることが多い
情報の質
有象無象の情報ではなく、処理できる量に収めないと解決ができない
30分以内 or 以上 になるの？みたいなのが判断できる情報に整理
小さな対処をトレーニングとして大きな障害に対応できるようにする
運用設計は後回しとかやっていないとかアルアル
まず「大規模なシステム障害」の定義とパターンに応じた関連組織を決める
週２〜３時間をつかってやれる活動
判断基準をまず作る
基準がない一人ひとりが判断もできない（情報の質）
そして、誰に伝えればいいのかわからないと広報もできない（サービス視点、Action）
担当者自身にとっても安心につながる
改善を進ませるための工夫（もしくは進まない原因）
アラート多すぎ
まず扱えるように減らすことから
障害対応にユーザー企業と協力体制を作る
アイディアとしては「サービスの質の維持」をキーワードにすれば、ユーザーにとっても「自分事」になるのでユーザーを巻き込める文脈になるかな？
GenAI in Production
弁護士ドットコムはIBMワトソンから使っていた
LLMの前から使っていた
課題としては「正しい質問立て」
それを解消できたのが「ChatGPT（自然言語による質問立てができる）」
RAGをつかって質問の精度を上げている
質問に対して、そのキーワードになる情報から関連書籍などをベクター検索して、その情報を質問に加えてChatGPTに投げて回答の精度を上げるている
「RAG」という言葉はAMの登壇で知った言葉
さっそくその理解が活きているのはデブサミならではという感じで良い
RAGに関するTIPS的なもの
Llamaindex Blog
専門性があるからこそ
フレームワークによる抽象化のブラックボックス化が逆に扱いにくい
このあたりはLLMの結果を精査する主体ならではだと思う
何を持って改善という？
LLMならではの不確実性
品質基準の難しさ
このあたりは「知識ゼロから…」で扱っていたところの課題で言っていたところ
結局、それを解消するのは弁護士による検証しかない
学習データによる学び直しを継続していく必要がある
データの品質大事
Data is the new oil
ビッグデータが流行ったときの言葉
ブランク・キャンバス症候群
「なんでもできる」だと、逆に「何をしたらいいのかわからない」になる
適切な問いかけや枠組みがあると、より質の良いデータを集めることが出来る
人間の役割はチェックだけで良い？
レビュー・修正するためには、実装経験のような育成がないと行き詰まってしまうよね？
AIの限界は、結局 人側の成長分に依存するよね？という話
伝統工芸の技術の継承の話みたい
むしろ、そのあたりをかなり意識的にやっていかないと緩やかにAIによって人は退化（？）するかも？とか思ったりもした
実際は「課題を解決する」ということになるんだろうけど
コードを書くこと自体がロストテクノロジーになるのは、まぁそう遠くないのかもしれないとは思ったりもする
世界標準のソフトウェア工学知識系SWEBOKGuide最新第４版を通じた開発アップデート
エンジニアリングに対する知識の体系がSWEBOK Guide
エンジニアリングは科学に裏打ちされたもの
体系的、規律的、定量的なアプローチ
顧客満足、開発者満足も「定量化」の範囲だと考えている、とのこと
正当なエンジニアリング（の定義）
コミュニティ（独りよがりではない）
科学的基盤に則っている（実証性がないのはNG）
実質的な価値を形成する（趣味じゃない）
体系とは、点と点を線で結んだもの
プラクティスとパターンは、体系を作り込む実践
SQuBOK（品質体系）
ソフトウェアエンジニアリングに対する共有理解のための手引（＝SWEBOK）
枯れた技術を体系立てて基盤として整理したものがSWEBOK
ぎゃくにいうと、SWEBOKで扱っているものは「エンジニアリングというのであれば、やっているのが当たり前」という扱いでもあるとも言える
V3までに意外にもなかったんだと思うところ
アーキテクチャ
システムは複雑で、基盤も多岐にわたる
運用
そもそも入っていなかったの？とも思える
セキュリティ
悪意への想定も重要な品質
アジャイルが入らなかった理由
これは、体系の１つというよりも、横断的なものであり、マインドになるものという扱いにした
AIが入らなかった理由
まだ新しすぎて、知識領域としてまとめるには成熟していない
セキュリティは「ドメインに特化したもの」まで扱う
ドメイン（Cloud、IoT、ML）
正しい用語の定義がSWEBOKの意義
AIについては「言及」まで
LLMのムーブメントがちょうど起きてしまったので入れた
「機械学習デザインパターン」
SWEBOKの開発への役立て方
ポータル
エンジニアリングの地図
辞書
ソフトエンジニアリングほど言葉がブレる業界はない…
ちゃんと用語を合わせよう
