こちらのイベントに参加してきたので、会の様子を書いていこうと思います。
オンライン区長のお言葉＆設営
1時間のはずが体感5分くらいしか喋っていませんでした笑
今年の締めを区長らしい安定した品質で行っていました。
Ackyさんのkeynote
基本的にすべて口外NGという内容だったのですが、世間の書籍やブログで書かれている〇〇と実際の〇〇の差が大きすぎるということで、本物の〇〇に関して説明してもらいました。
前半の煽りに答えるような形で、実際にAckyさんがやっている〇〇を見せてもらったり、世間とのGapを説明したりしてくれました。
全然準備をしていないという話を前日までしていて、話せることはなにもない、誰かに枠を譲りたい、と布石をかなり言っていたのですが、Ackyさんのこれまでの発表を聞いていた身からすると話の濃厚さと突っ込み具合がぜんぜん違くて、その後のkeynoteのハードルを大きくあげていたため、これは策士だなと思いました笑
Ryoさんのkeynote
組織をApp*1/OS*2/Device*3という3つのレイヤーで捉えているという話がありました。
こう考えたときに、異なるLayerの問題を異なるLayerのソリューションで解決しようとしてしまうのが問題だということで、例えば雑にいう「ふりかえりですべてを良くする」はこの考え方に当てはまるということでした。
そのうえで、OS Layerにアプローチするワークショップの説明がありました。
ワークショップ自体は、
- 文脈設定(なんで我々はそれをやる必要があるのか？)
- 手順
- エクササイズ
- まとめ
のステップを作ることが大切だということですが、OS Layerでは特に重要なことがあるというお話でした。
具体的に何が重要なのかという話に関しては、コンフィデンシャルなためブログに書くことはできないのですが、コミュニケーションを取る時に(?)よく言われがちな概念に関して、NVCとインプロとマイズナーとシステムコーチングと仏教を合わせて捉えることで大切なことが見えてくるという話で、実際にそれぞれどういう文脈でどう捉えているのか？という話をしてくれました。
やましたさんのkeynote
まず、今回はテストの専門家orテストが好きな人、くらいで今回の発表は作っているということでした。また、あくまでもやましたさんがもがいてきた結果の理解を整理した話だということです。
品質という言葉を考えるとかなり広い定義になってしまいますが、品質をどういう風に扱いたいと思っているのか？という文脈で考えるのがよいとやましたさんは思っているそうです。
例えば品質保証と品質管理はTQSとISOで微妙に話が違ったり*4しているということでした。
品質保証をソフトウェアテストの文脈で考えてみると、量産工程がなかったり最終成果物に物的な実体がなかったり自然法則を受けなかったりするという制約があるということで、「製品設計」の文脈が「生産」よりも重視されるということです。
品質保証の原則としては、目的と手段と組織の運営という3カテゴリーでかなりの原則があるということで、例えば
- マーケットイン(不具合数ではなく顧客満足を目的にする)
- 後工程はお客様(例えばトイレのスリッパを揃えておく)
- 品質第一(売上向上より顧客のニーズにあった製品を出すことを重視する)
- プロセス重視(結果を生み出すプロセスを管理して向上)
- 標準化(効率化や認知負荷を下げるとともに標準化自体も改善するものでたたき台である)
- 源流管理(仕事の流れの源流にしたがって品質管理)
- PDCAサイクル(プロセスを設定してその結果を見ながら逐次的に修正する。改善と管理でアプローチを分ける。なお、失敗が少なくなってきていることはサイクルを回し直す手がかりになる)
- 再発防止(プロセスに遡って問題分析する必要がある)
- 未然防止(トラブルが発生する前にトラブルを防ぐ)
- 潜在トラブルの顕在化(報告されていないトラブルも探す)
- QCDにもとづく管理(プロセスの評価はプロセスだけではなく結果を見る)
- 重点思考(結果に大きな影響を与えている問題から取り組む)
- 事実に基づく管理(妄想や仮定で話をしない)
- リーダーシップ(経営者や管理者が率先して顧客やステークホルダーのニーズを考慮すべき)
- 全員参加(全社全部門が参加する必要がある)
- 人間性尊重(マズローの欲求の自己実現を人間の能力をフル活用してやる)
- 教育・訓練の重視(企業の発展を支えるためには一人一人の能力を計画的に上げることが大切)
この話とQAエンジニアの語源*5を踏まえるとQAエンジニア=テスターだと思っているそうですが、品質保証≠テストだと言えることと日本ではQAエンジニアに特別な意味を持つようになってきていることから、品質保証に関わっている人は全員QAくらいにやましたさんは思っているそうです。
また、「QAエンジニア」と名乗るのであればそれはすなわちフルスタックエンジニアだと思っているそうで、品質だけではなく開発やビジネスを一緒にやることを忘れないようにしてほしいということでした。(一方でQAエンジニアと名乗るのは人間が人間と名乗っているようなものなのでテスターと名乗ったほうがいいんじゃないか？と思っている)
そのため、品質富士山はまさにQAの概念を言語化しているものだと感じるそうです。
ここまで話してきた内容でも出てきたように品質の定義は色々ありますが、こうした「品質とはなにか？」を考える前にそもそも顧客満足とはなにか？を考えたほうが重要だと思っているそうです。
おおひらさんのkeynote
おおひらさんはテストをすることで不確実性や知らないことを減らしたいと思っているそうで、具体的にどんなプロセスでテストをしているのかや実施しているプラクティスの説明がありました。
こちらの詳細に関しては以下の資料が詳しいということです。
なお、おおひらさんとしてはこういった取り組みを話を聞いた人が真似するのはおすすめしないそうで、まずは自分がやって結果を出すことが重要だということでした。(おおひらさんが見ている感じだと、自分が手を動かす前に全員でやりましょうみたいな話をするQAエンジニアが多い印象がある)
実際、おおひらさんのチームでやっているリリースノートやマニュアル作成といったことも、おおひらさんの趣味のようなところから始めたということでした。現在も、実装しながらPdMに探索的テストをしてもらうということをやり始めているそうです。(完成を待たずにテストをすることがすごく良いこと)
次に、チームにテスターは必要か？という話がありました。おおひらさんも答えはわからないそうですが、おおひらさん個人としてはチームにテスターは必要だと思っているということで、その理由としては
- 抽象と具体の逆張りができる(エンジニアがコードを通して抽象化をしていく際に、テスターはテスト分析などを通してどんどん具体化していく)
- 異なる時間軸で話すことができる(エンジニアが特定のスコープを見ている時に別の時間軸で話ができる)
- プロセスを常に作れる(リリースまでどういったタスクを積み上げていくのか、何が必要なのかを決めれる)
があるということでした。また、有効なコラボレーションの仕方として、
- 他職種のサポートとしてテストをする
- テストの新たな活動を発見をする
- ScMとテスターのポジション取りを変える(チームの障害を除くのがScMで品質向上の面からテスターはアプローチする)
があるということでした。
