JaSST'18 Tokyo 第２日
以下、参加セッション順に、個人的な所感を登稿します。
《C5-1）AI搭載システムの品質保証》
当初から聴講してみたいと思っていたセッションの1つ。会場もいっぱいに入った上に、立ち見の人も結構いたので、JaSST参加者の感心度の高さがうかがえました。
セッションの流れは、以下の順で説明されました。
・AI搭載システムに対する品質保証の必要性
・品質保証のゴール
「品質保証のゴール」：
社会が許容可能なリスク上限 ≧ システム全体のリスク
「従来から許容しているリスク」 「従来のシステムのリスク」
「AI活用の追加利益により 「AI活用により新たに発生するリスク」※１
新たに許容可能なリスク」※２
（上記は発表資料から引用）
・品質保証ゴールへのアプローチ
・テスト技法：DNNカバレッジテスト手法（※１）
・品質アセスメント技法（※２）
・社会が許容できるリスクの合意形成（※２）
自分たちで品質保証のゴールを定義している点に感心しました。技術的な検証実績を積んでないと、中々できないことだと思います。また、本セッションを通して研究成果を公開するところは、日立さんの懐の深さを感じました。もちろん、社会的な合意形成が必要である点を強く認識されてのことだと思いますが。また、機能性を１００％実現できない特性上、統計学的な確率を用いてアセスメントせざるを得ないのは、同じ意見です。
【AIを評価する軸】
・精度（対人間）
・スピード
・誤差の許容度（追加コスト、セーフティ）
→ 上記の総合値と対象とするドメイン特性を元に、妥当性を検証
《C5-2）TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善》
TPI Nextを始めとした改善プロセスモデルは、組織に適用する初期段階で挫折してしまいそうですが、「メンバーの感情を突破口にする」やり方は、なるほどと思いました。感情は個人個人の主観ですが、決裁者を納得させる客観的事実として、上手に使っていると感心しました。また発表内容と共に、困っている人の心に寄り添う様なその喋り口など、自己顕示欲を全く感じないその講演者の方が、私の目には徳の高いお坊様のように映りました。私が日頃従事しているフィールドへの支援活動は、成果を評価できる基準がほぼ無いため、何が正しいのか迷うことがしばしばあるのですが、「大丈夫だよ、あなたのやっていることは、きっと役にたっているよ」と諭されている気になりました。仕事の中で直接的に感謝されることは滅多に無いので、気が付かないうちに承認欲求が募っていた私にとっては、心の琴線に触れられた様な感じになり、溢れる涙をこらえるのに苦労しました。
尚、本セッションが参加者投票で決まる今年のベストスピーカー賞に選ばれました。おめでとうございます！やっぱり皆同じ気持ちで聞いていたのかな。
《D6）QAからDevOpsへの挑戦 〜QCDはトレードオフじゃない》
アンケートにも書かせてもらいましたが、自分の知らないDevOpsならではのエピソードを聞けると思っていたのですが、よくあるプロセス改善の苦労話のように聞こえてしまい、私にとっては少し期待外れでした。でも、「スイッチングコスト」と言うフレーズを聞けたことは収穫かも。パラレルで色々と勉強している私にとって、学習の効率性を評価するのに必要なメトリクスと、概念化が出来ていなかった現実という、２点を気付く良いきっかけになったと思います。
《A7）招待講演：私が経験したソフトウェアテストの変遷》
「もはや、CIを実践していることは強みにはならない。CIを実践していないことが弱みになる。」というお話が、とてつもなく印象的でした。以前内の会社でも、テスト自動化の話は確かにありましたが、今はだれも活用していません（私が知る限り）。何故その様な結末になったのか、私なりに考えてみました（下記）。成功する方法があるとするなら、デザイン思考によって設計されたマネジメントシステムを組織に導入するべきではないか、そんな風に思うのです。
①組織風土により目先の損得を重視する傾向が強く、現状変更への反発する力が働いた
②1本のろうそくの火の様な矮小な推進力のため、組織内の風で簡単に消えてしまった
③AsIsとToBeの両方のイメージは認識していたが、改善のアプローチとして、
現在の延長線上にゴールを見出そうとしていたため、袋小路に入ってしまった
以下は、現時点でのCIに対する私の理解です。上の事柄を下の事柄が可能にする、いわばイネーブラー・フレームワークです。
【時代の要請】
価格競争、スピーディなサービスデリバリ
（当然ながら、品質担保は上記との両立）
↑
【開発技術の進化】
開発プロセスの自動化：サブミッション時の自動的なビルド／統合テスト
（前提：迅速な対処を可能とするエラー検出）
↑
【開発プロセスを支えるツールの普及】※使いこなせる人材も必要
①テスト自動化ツール
②ブランチからのコミットを管理するバージョン管理ツール
③仕様、ソースコード、テストコードのトレーサビリティを管理する構成管理ツール
④①～③を統合するＣＩツール
↑
【テスト実装】※テストコードを書ける人材も必要
テスト自動化ツールで動作させるテストコード、テストデータ
↑
【テスト設計】※テスト設計ができる人材も必要
仕様、プロダクトリスクを元にテスト仕様を設計
↑
【ソフトウェア開発の計画】※開発プロセスをプロジェクトに最適化する人材も必要
テストファーストを前提とした開発プロセスの計画
参考文献：
・ジョイ・インク 役職も部署もない全員主役のマネジメント
・ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
《A8）クロ一ジングパネル：アジャイル・自動化時代のテストの現場のリアル》
本パネルディスカッションでは、パネリストが属する各社の状況を語る程度で、一定のコンセンサスの形成には至りませんでした。収穫としては、サイボウズさんの取り組み（当初、ウォーターフォールでの開発プロセスを、2週間サイクルのスクラムへ移行）を聞けたこと。ソフトランディングをねらった段階的に移行は、うちの会社で改善をする際、参考になるかも知れません。
《A9）クロージングセッション》
ベストスピーカー賞に「TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善」が選ばれ、再び男泣きしたのでありました。
《C5-1）AI搭載システムの品質保証》
当初から聴講してみたいと思っていたセッションの1つ。会場もいっぱいに入った上に、立ち見の人も結構いたので、JaSST参加者の感心度の高さがうかがえました。
セッションの流れは、以下の順で説明されました。
・AI搭載システムに対する品質保証の必要性
・品質保証のゴール
「品質保証のゴール」：
社会が許容可能なリスク上限 ≧ システム全体のリスク
「従来から許容しているリスク」 「従来のシステムのリスク」
「AI活用の追加利益により 「AI活用により新たに発生するリスク」※１
新たに許容可能なリスク」※２
（上記は発表資料から引用）
・品質保証ゴールへのアプローチ
・テスト技法：DNNカバレッジテスト手法（※１）
・品質アセスメント技法（※２）
・社会が許容できるリスクの合意形成（※２）
自分たちで品質保証のゴールを定義している点に感心しました。技術的な検証実績を積んでないと、中々できないことだと思います。また、本セッションを通して研究成果を公開するところは、日立さんの懐の深さを感じました。もちろん、社会的な合意形成が必要である点を強く認識されてのことだと思いますが。また、機能性を１００％実現できない特性上、統計学的な確率を用いてアセスメントせざるを得ないのは、同じ意見です。
【AIを評価する軸】
・精度（対人間）
・スピード
・誤差の許容度（追加コスト、セーフティ）
→ 上記の総合値と対象とするドメイン特性を元に、妥当性を検証
《C5-2）TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善》
TPI Nextを始めとした改善プロセスモデルは、組織に適用する初期段階で挫折してしまいそうですが、「メンバーの感情を突破口にする」やり方は、なるほどと思いました。感情は個人個人の主観ですが、決裁者を納得させる客観的事実として、上手に使っていると感心しました。また発表内容と共に、困っている人の心に寄り添う様なその喋り口など、自己顕示欲を全く感じないその講演者の方が、私の目には徳の高いお坊様のように映りました。私が日頃従事しているフィールドへの支援活動は、成果を評価できる基準がほぼ無いため、何が正しいのか迷うことがしばしばあるのですが、「大丈夫だよ、あなたのやっていることは、きっと役にたっているよ」と諭されている気になりました。仕事の中で直接的に感謝されることは滅多に無いので、気が付かないうちに承認欲求が募っていた私にとっては、心の琴線に触れられた様な感じになり、溢れる涙をこらえるのに苦労しました。
尚、本セッションが参加者投票で決まる今年のベストスピーカー賞に選ばれました。おめでとうございます！やっぱり皆同じ気持ちで聞いていたのかな。
《D6）QAからDevOpsへの挑戦 〜QCDはトレードオフじゃない》
アンケートにも書かせてもらいましたが、自分の知らないDevOpsならではのエピソードを聞けると思っていたのですが、よくあるプロセス改善の苦労話のように聞こえてしまい、私にとっては少し期待外れでした。でも、「スイッチングコスト」と言うフレーズを聞けたことは収穫かも。パラレルで色々と勉強している私にとって、学習の効率性を評価するのに必要なメトリクスと、概念化が出来ていなかった現実という、２点を気付く良いきっかけになったと思います。
《A7）招待講演：私が経験したソフトウェアテストの変遷》
「もはや、CIを実践していることは強みにはならない。CIを実践していないことが弱みになる。」というお話が、とてつもなく印象的でした。以前内の会社でも、テスト自動化の話は確かにありましたが、今はだれも活用していません（私が知る限り）。何故その様な結末になったのか、私なりに考えてみました（下記）。成功する方法があるとするなら、デザイン思考によって設計されたマネジメントシステムを組織に導入するべきではないか、そんな風に思うのです。
②1本のろうそくの火の様な矮小な推進力のため、組織内の風で簡単に消えてしまった
③AsIsとToBeの両方のイメージは認識していたが、改善のアプローチとして、
現在の延長線上にゴールを見出そうとしていたため、袋小路に入ってしまった
以下は、現時点でのCIに対する私の理解です。上の事柄を下の事柄が可能にする、いわばイネーブラー・フレームワークです。
【時代の要請】
価格競争、スピーディなサービスデリバリ
（当然ながら、品質担保は上記との両立）
↑
【開発技術の進化】
開発プロセスの自動化：サブミッション時の自動的なビルド／統合テスト
（前提：迅速な対処を可能とするエラー検出）
↑
【開発プロセスを支えるツールの普及】※使いこなせる人材も必要
①テスト自動化ツール
②ブランチからのコミットを管理するバージョン管理ツール
③仕様、ソースコード、テストコードのトレーサビリティを管理する構成管理ツール
④①～③を統合するＣＩツール
↑
【テスト実装】※テストコードを書ける人材も必要
テスト自動化ツールで動作させるテストコード、テストデータ
↑
【テスト設計】※テスト設計ができる人材も必要
仕様、プロダクトリスクを元にテスト仕様を設計
↑
【ソフトウェア開発の計画】※開発プロセスをプロジェクトに最適化する人材も必要
テストファーストを前提とした開発プロセスの計画
参考文献：
・ジョイ・インク 役職も部署もない全員主役のマネジメント
・ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
本パネルディスカッションでは、パネリストが属する各社の状況を語る程度で、一定のコンセンサスの形成には至りませんでした。収穫としては、サイボウズさんの取り組み（当初、ウォーターフォールでの開発プロセスを、2週間サイクルのスクラムへ移行）を聞けたこと。ソフトランディングをねらった段階的に移行は、うちの会社で改善をする際、参考になるかも知れません。
《A9）クロージングセッション》
ベストスピーカー賞に「TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善」が選ばれ、再び男泣きしたのでありました。
コメント