1日目の記事から間が空いてしまいましたが2日目のまとめです。
E6 「価値あるソフトウェア」の価値ってなぁに？
安達 賢二さん（ＨＢＡ）、永田 敦さん（サイボウズ）、吉澤 智美さん（日本電気）
内容メモ
ワークショップ形式で価値とは何かを考えていくセッション。スピーカーの御三方の価値についての考え方も聞けた。
どの価値のことを言っているのか？
システムで実現しようとしている価値は何か？
デビッド、アーカーによる分類
- 自己実現価値
- ITシステムを使った先にある結果
- 情緒的価値
- ITシステムでどういう体験が得られたか
- 機能的価値
- ITシステムでどう便利になったか
事例紹介
https://jasst.jp/symposium/jasst23hokkaido/pdf/S4-1.pdf
- 価値分析モデル
- 我々はどんな価値を提供するのかを分析
- AsーIs課題分析表
- その組織の能力の中でできる一番インパクトのあること
- 仮説をたてる際に検証する方法はたてているのか→これについてはまだまだ
- 一つの事例としてはアンケート
- toーbe 価値連鎖モデル作成時に、相関の関連とか指標を決めておく
- お客さんが自分たちに見えてなかった価値を見出してくれて売れることもある
https://www.jasst.jp/symposium/jasstreview21/pdf/S1.pdf
- 計画は変わるために立てる
- エピックとユーザーストーリーの関係性
- QAは価値をどう認識しているか
- 他のロールが実施しているから自らのロールの対象外にしてないか？
感想
個人的な思い出ですが、関わったシステムがどう成長してるか分かりずらいのが転職の大きな理由でした。受託がメインでテストフェーズに入ったとこ転々としてたので。同じ社内なので聞けるといえば聞けるんだけど、自分のリソースは別のプロジェクト。掛け持ちすればするほど気にかけられる余裕はなくなるわけで、ということを何となく思い出しながら聞いてました。
今はその時よりは価値について考える機会は増えてると思います。メンバーのテストケースレビューの時に、システムの目的に合うかどうかみたいなことを聞いてみるところからチームで価値を意識するのを始めてみようと思います。
A8 テスト管理ツールの向かう先
朱峰 錦司さん（株式会社ベリサーブ）、石井 優さん（株式会社SHIFT）、会田 圭司さん（テクマトリックス株式会社）、鈴木 一裕さん
内容メモ
- テスト管理ツールのメリット
- 集計作業の軽減
- テスト資産活用による品質分析の高度化
- プロダクトチーム内の情報流通の加速
- トーク対象のツール
- TestRail（テクマトリックスさんが代理店）
- CAT（SHIFTさん）
- QualityForward（ベリサーブさん）
- テスト管理ツールが得意、苦手とする分野
- テスト管理ツールは1000件超えたらツールの導入を検討する
- 証跡を残さなきゃいけない業界では便利
- PassかFailedかだけじゃない 敢えて今回は飛ばすというステータスもある
- テスト管理ケースの普及の足かせ
- 表計算のいいことは表現の幅が広い
- マトリクスが表現できない
- テスト設計ツールとの連携は？
- S社さんツールだとできる
- GIHOZ頑張って！
- 国によってテスト管理ツールの要望が異なる？
- BDDとか探索的テスト向け テストの現場が楽になるような要望が海外は多い
- 集計レポートの要望が日本では多い
- 表計算ツールではグラフ、集計が自由にできるが？
- 日本ではもっと細かくみたいとか、切り口を細かくしたいという要望は多い
- V社はあいつのローデータの提供とかでなんとかしてる
- テスト管理ツールは今後どう進化していくべき？
- テスト資産のハブとして使えないか フレーキーテストの推測
- 操作ログとかコミットログとか障害表が整理されてないのを整理されてるようにする
- 仕様管理とつながるとかAIの活用とか
感想
表計算ツールはやはり強いんですよね…。マトリクスとかの扱いができないのが個人的には大きい気がします。テスト設計とか、E2E自動テストのサービスとかともっと連携できるようになれば管理ツールのアドバンテージが出てきそうだなと思いながら、私は現状はあまりうまく扱えてません。気になる分野ではあるので今後も期待！
自動車のソフトウェア品質に関する現場の試行錯誤
長尾 洋平さん（トヨタ自動車）
内容メモ
- BEV（バッテリーEV）
- SDV（software defined vihcle）とは何か車をソフトウェアで定義していく
- 従来は車のハードを設計してからそれに乗るソフトウェア
- ソフトウェアの構造を決めてハードを作るよう転換
- メリット；ソフト部分のテストが先にできる、早く提供できるようになる点
- なぜSDVが必要なのか
- コスト最適と開発スピード
- 車全体のシステムの複雑化によるソフトウェア開発の複雑さ コード一億行
- 時間がない
- なぜ今なのか 各タイミングでコードの量がガンガン増える
- ECU（Electronic Control Unit：システムを電子回路を用いて制御する装置）制御の拡大
- コネクティッドカー
- 自動運転、社会インフラとの連携
- ECUに依存せずに進化できなければならない
- 各種法規を満たさなければならない ハザードひとつ取っても国によって法規が違う（様々な法規を満たすよう作るし、それをテストしなければならない）
- 論理構造 APPIで繋げればいい
- 物理構造 規格にそう。後から調整でする
- ソフトウェア実装の支援
- CICDパイプラインは注意深くデプロイする必要がある
- 法規対応も守った上でリリースする必要がある
- sdvコンセプトをテスト観点で具体化:品質は小さい部品からの積み上げ
- テスト設計品質
- テストに関わる人が多くテスト設計の品質が不明確
- テスト設計ガイドラインを作成
- テスト実装品質
- テスト実行スピード
- ガワを取り去ってECUとワイヤーとソノサキを残したのもの 1台ー数台しかない
- 一億行のテストをこの環境でやり切るのは大変
- 計画と運用
- ステークホルダーからテストの全体像が見えないという相談が多い
- テスト計画をより洗練させ、社外知見者からのレビューを受ける
- テストのアプローチ方法改善の施行
- V字からW字にされてる感じ
- ドキュメントがこないからテスト設計できないの壁を取っ払う
- テストのために設計ガワも変えていこうと思っている
- テストなどドキュメントで全て残す
- 説明責任を担保しなければならない
- 必要最小限、ただし安全を担保するため十分なテスト
質疑
感想
自動車関連のテストを実はやったことがないので、規模の大きさや関連部署との調整の難しさに圧倒されながら聞いてました。特にハードウェアの部門の方との調整が大変そう。愚直にきちんと必要なことを積み上げていってるのが講演の中だけでも見て取れてすごかったです（小並感）
全体の感想
久々にオフライン開催もあるJaSST Tokyoで、色々な方に会えて嬉しかったです。Xのアイコンの方とお会いできる嬉しさよ…！
今回は基調講演から招待講演まで、価値の話がよく出てきました。チームでもどういう価値を提供できるかを話すきっかけにできたらと思います。
