前回の記事の続きです。2日目のレポートです。
当日のスケジュール
WACATE2022 冬プログラム - WACATE
モーニングセッション(テストエンジニアのギアナ高地「システムアーキテクチャって何?」をつまむ) <30分>
- 感想
- アーキテクチャは最近まさに関心を持っているところで、お話を聞くことができて良かった。本当に高い品質を求めた時、避けて通ることができないものがアーキテクチャだと思う。ソフトウェアの動くという結果はアーキテクチャによってもたらされている。上手く動かない時、原因はアーキテクチャにあり、そこに何かしらアプローチができるようになれたら QA はもっとプロダクトの品質を高めるために重要な動きが出来るようになると思う。ハードルは高いが、やっぱり関心はある。アーキテクチャの話とは関係ないが、IPAで推進されているセキュリティ要件はクライアントからの仕様書に明記されていなくても実装するべき、というお話がチラッと出たが、その通りだなと思った。業界標準というか、クライアントに要望としてされていなくても、業界が推奨しているようなものはマストで押さえているような開発ができると良いなと思った。実装しないにしても、しないことが当然ではないという感覚は身に付けれると良いなと思った。
- memo
セッション3(仕事に感情を持ち込んじゃおう!~弱さに寄りそえるQAエンジニアになるためのヒント)<90分>
- 感想
- 仕事は誰もが感情ではなく事業の目標や事実を重視して意思決定やコミュニケーションが行えることが理想という気持ちがあったので、感情を持ち込んで働くことを推奨するようなテーマに少し懐疑的なところはあった。しかしこのセクションで伝えられた最終的なメッセージは、感情をアクションに変える力を付けようというもので、これはすごく重要な力だと思った。上記で書いたような理想を自分は持ちつつも、やはり感情は無くしきれないので、感情が起こった時、それをどう建設的に処理できるか、改めて考えたいと思った。セクション中、内省する時間があったが、日ごろから内省している自分はそんなに新しい発見はないだろうと思ったが、新しい発見があった。内省を行う環境が変わると気づく内容も変化するのかもしれない。
- memo
- UEQ
- EQPC
セッション4(品質とは何か?)<90分>
- 感想
- 場所移動に間に合わず、前半のお話をしっかり聞くことができず残念だった...。品質特性の使い方のお話が聞けて良かった。開発チームや PO と品質についての話をするとき、品質が指すものが多く、どうしても空中戦というか、とりとめのない話になりがちな印象なので、品質特性を地図のように扱い、議論できると良いかもと思った。品質の定義が時代によって変わっていくのは何でだろうと思った。ふと、ソフトウェア開発はビジネスだから。という理由を思いついた。品質の定義が変わるというのは、世の中のニーズが変わったことを意味しているのではないか。品質とニーズが切り離せないのは少し違和感がある。品質と聞くと、安心安全(ユーザのためにこちらが用意するもの)、みたいなものを連想する。だからニーズ(ユーザが求めているもの)と紐づいていることに違和感があるのか。ユーザのためにこちらが用意するもの、ユーザが求めているもの、どちらも品質の中で用意しようと思えば、品質エンジニアの業務はあまりに広い気がするが、そういうものなのだろうか。もしそうであれば、品質エンジニアはどのようなステップアップが存在するのだろう。QCD の話を聞いて思ったが、品質はかけたリソースに対して向上するという前提はあっているのか?
- memo
- 品質特性は地図みたいなもの。特性を識別できるようになることが重要。品質特性すべてを満たすのは目的ではない。
- QCD
- チームメンバーから聞いたお話「品質を良くせよ、と指令が出てまず行ったのはリグレッションテストの充実。デグレが頻出していたため」
- 品質管理といった時、品質管理、品質マネージメント、どちらを指しているか、人によって異なる
- 品質活動の歴史
- 不良品を世の中に出さない
- 不良品を作らない
- 不良品を設計しない(イマココ)
- プロセス品質
- プロセスを尊守して安定した能力を発揮しているか
- プロダクト品質
- 成果物の要求事項・決められた基準を満たしているか
- テストレベルに適したテストの実施が必要
- 品質が十分である時、どうやって品質に着目するか→今よりコストをかけずに品質を十分にするにはどうするか考える
招待講演(スピードがなければ、生きていけない。品質が低ければ、生きていく資格がない。)<90分>
- 感想
- 以前聴講した"水銀中毒はAI羊の夢を見るか"に続いて、エキサイティングな例えが用いられた素敵な講演だった。エキサイティングなだけでなく、重厚な歴史とそれに紐づいた品質についての話が、分断なく上下左右に展開されて、色々な知識が自分の中で繋がっていき、面白い体験だった。これだけ品質について語ることができて、ようやく品質についての改善案を持ち出せるんじゃなかろうか、という感覚があった。今の自分は、現場で品質改善の案を提案し、全員に取り組んでもらうには、まだまだ品質についての理解が足らないように思えた。もっと勉強しないといけない。僕の勉強不足もあるが、品質というテーマがそもそもかなり深いもののように思える。
- memo
- 品質と民族は関係ない
- 統計と品質管理は切っても切り離せない
- 経営工学
- 小難しい数学を使って企業で良いことをするのは QC だけじゃない
- オペレーションリサーチ
- 生産工学
- トヨタ式生産
- 信頼性工学
- ...など、すべて統計を使う
- 何をやろうとも、理想の現場をイメージできていなければうまくいかない
- 品質管理はこれをやれば十分というものはない。だから「賞」はあるが、認証制度はない
- SQC→(魔改造)→TQC
- 品質の「品」は品物ではなくて品格を意味している(加納さんいわく)
- 日本的品質管理は「品質とは」という深遠な問いに答えるために様々な進化をしてきた
- 源流管理
- 信頼性工学との融合
- 設計品質・企画品質(品質は一品ものだから統計使えない)
- 規格の適合度・顧客の要求に対する合致度・顧客満足度
- ...
- 価値が変わると品質保証手段も変わる
- 「品質」は技術そのもの
- 層別は層を分かりやすくして分析すること
- 品質で重要なのは、物事を正確にとらえること
- ロジックキューブを大きくして、原理原則を見つける
- POや開発者がわからない点に気づける
- コントロール
- 予め決めた基準に合致させること
- マネジメント
- 目的を達成するためにあらゆることを上手に行うこと
- MBOやOKRは上下が円滑に行き来できて納得感ができるのが大事
- 落とし込みの上手さは重要ではない
- カイゼンは変化する筋肉をつける
- カイゼンサイクル(PDCA)は回すことが重要
- AIはQAの技術が追い付いていない
- 納得感を作るのが大事
- (質疑応答)具体化抽象化がうまくなるには
- 具体化抽象化能力の高い人のインプットとそこからのアウトプットを知り、自分との処理の差を知ってみる
- 「なぜ」をたくさん考えると伸びる
- (質疑応答)レベルの高い品質エンジニアがほかの企業より多いと感じる企業はあるか。また多い理由はどこになるのか
- (製造業であれば)他の企業より多いと感じる企業はある
- なぜなぜ分析が得意
- なぜ得意なのかと言えば入社してから何度もする機会があるから
- ねばちっこい。スマートな愚直。
- ダメな企業はやれといったことがやれない
- 現代品質管理総論(大事なことが全部書いてある本)
思ったことを感想に、講義内容で気になった箇所は memo に書いていきました。思い出し用のレポートとしては十分機能しそうです。より、詳細に内容を思い出したい時は、共有していただいた資料を見返したいと思います。楽しい2日間でした。運営の皆様、仲良くしてくださった皆様、ありがとうございました。