WACATE2021冬
1日目
WACATEとは
過去
14年前にテスト業界には「若手が積極的に活躍できる場がなかった」→若手が発言しやすい場を作っていこう
夏は1つのテーマを、冬は広くいろんなテーマをやる
現在
名前の通り加速装置である
参加者も運営もみな若手・手を動かす・成長する
参加してる若手それぞれで成長していく（いい話だなあ）
参加者：積極的に参加していきましょう
講師：発信経験
実行委員：PJ運営経験
未来
加速していこう（具体的には？）
自分が加速することで会社を変えていくとか。
加速の定義は人それぞれなので、短期的な目標でも長期的な目標でも何らか成長し貢献できると良い
では若手の二日間で何を持って帰る？書いてみよう
自分はソフトウェアテストコミュニティにいなかったので、同じぐらいの世代の人たちがどんな活動をしているのかが気になっているので、そのあたりを聞いてみたい
テストケースの書き方、ふわっとしてるのを多少固めたい
ポジションペーパーセッション
噂に聞いてたやつだ！
ポジペをもとに交流するやつ
一人3分 x 2ラウンド
BPPセッション
前回のWACATEでBPP取った方のセッション
組み込み開発のエンジニアがソフトウェアテストの勉強をして変わったこと
ある日突然第三者検証チームを立ち上げろと言われ…←つらそう
(感想)大変気になる
働き始めてから最近までソフトウェアテストについて全く勉強していなかった。
初期は詳細設計と実装、それに伴うユニットテストやコードレビュー
ValidationではなくVerification
転職し、基本設計以下をカバーするようになった
ValidationではなくVerification
ある日突然「第三者検証チームをやっから、移動な」
開発チームから独立したチームが新たなテストプロセスに従ってテストをしていく
次世代の機種も対象になった
そもそもなぜチームが立ち上がったのか
開発チームがやることのメリット
作業効率がいい
デメリット
毎度観点が同じになってしまい、検証の漏れがあった→第三者検証で品質を上げたい
では0から立ち上げるに何やった？
まずは社外の第三者検証の会社に入ってもらい、ベースとなるテストプロセスを構築した
自分たちの新たな開発プロセスに合わせてテストの戦略やプロセスの定義をした
(感想)自分たちの開発プロセスに合わせるってのが大事よね
(感想)決まったやり方というのはないので、組織や開発体制によって変える必要がある
ソフトウェアテストの勉強をして変わったこと
ソフトウェアテストに対する考え方
テストに正解はない
(感想)わかる～
テスト7原則の原則1：血管があることは示せるけど欠陥がないことは示せない
(感想)これをやれば完璧って感じなのか？ってのは自分も思っていた。最近はいかにリスクを減らすかをうまくやる方法がテスト技法的なところだと思っていて、コストと品質を天秤にかけてうまくやるしかないんだよなと思っている。
テストも開発も同じ
(感想)Jasst'19 Hokkaidoの資料っぽい？気になるので後で見るか
テストにもちゃんとプロセスがある。これって開発と同じじゃん？
レビューもテスト
(感想)レビューはレビュー、テストはテストって思っちゃうのわかる
(感想)今は勉強してレビューも静的テストということは理解している
テストよりも前のフェーズで気づけてたほうが手戻りも少ないよね
テストが貢献できるのは下流工程だけではない
シフトレフトしてテスト設計を前倒ししておくことのメリット
別に下流だけじゃなく上流からやっていくことで、最終的な成果物の品質をあげられる
ソフトウェア品質保証に対する考え方
テストだけで品質が上がるわけではないんですよ
SQuBOKってのがあってね
ソフトウェアエンジニアの役割に対する考え方
そもそもテストエンジニアってやつが社内で認知されてない
テスト対象が複雑化している。上流にもどんどん働きかけていかないと品質が上がって行かないのでは？と思う
まとめ
ソフトウェアテストの勉強がエンジニアとしての裾野を広げてくれた
:iihanashi:
テストエンジニアに「開発の知識/経験」が求められるという話があるが、逆に開発エンジニアにも「テスト知識/経験」が求められるのでは
(感想)今回の話とはずれるかもしれないが、QAという話を聞くたびに「正直現場で全部これできたらいいんだよな」みたいなのを思うことがあり、それぞれにQA専がいなくてもなんとかなる未来のほうが良いのかもしれない、などと考えたことはある
(感想)初期段階として横軸でQAチームが全部見るもいいかもしれないが、そこでやったこととかが各チームに浸透していけるといいね
デシジョンテーブルで振る舞いを整理しよう
デシジョンテーブルについての理解を深めていきましょう
その前提となる技法についても理解を深める
デシジョンテーブルとは
決定表とも呼ばれる
そのままだね
入力と出力の論理関係を整理するときに使う手法
最近普通にMRとかにデシジョンテーブル書いて振る舞いを説明したりしてる
デシジョンテーブルテストとは
デシジョンテーブルを作成し、そのとおりにソフトウェアが実装されているかを確認する
色んな本があるやん
SWEBOK
SQuBOK
JSTQB
今度受けるやつ
ソフトウェア技法ドリル
めちゃくちゃお世話になったやつだ
いい本なのでやってみておくれ
モデリング（モデル化）
問題解決の対象を抽象化表現する
抽象化：ある事象から必要な情報のみを抜き出して表現する
自然言語での記述は矛盾点にに気づいたり、本質的ではない情報の取捨選択が難しいため抽象化が有効
デシジョンテーブルの作成（モデリング）すると何がよい？
自然言語のみではどういう条件で何が起こるのかを即時に理解するのが難しい
パターン数がどれくらいある？を即座に理解できる
組み合わせの種類
有則
入力と出力の論理関係が定義されているもの（入力に対して振る舞いが確実に定まっている）
無則
どうなるかが定義されていないが組み合わせる事自体が可能なもの
組み合わせても影響がないと思われるもの
組み合わせても影響がないやろ！ｗって思っているものだと思えばいい
(感想)そういったものを組み合わせた結果やばい挙動をしないかを見るのでな
禁則
組み合わせることが禁止されているもの
デシジョンテーブルのテスト範囲
デシジョンテーブルテストは有則なものをテストする
因子と水準
因子
要因の変数（普段はカテゴリぐらいに思っている）
水準
因子がとり得る値
因子を具体化したものが水準だし、水準を抽象化したものが因子という関係だね
例えば言語が因子で日本語が水準、みたいな
前GIHOZでみたやつ、因子と水準を意識した書き方みたいだったな
因子・水準は同値分割の関係
例えば20歳かどうかで分岐するとき、19歳以下と20歳以上で分けるよね。これは同値分割っぽ～い
同値分割法
同じように処理される値のセット（同値クラスとか）として分割するやつ
わかりやすいのは数値の値域で挙動が変わるものを同値クラスにすることが多い気がする
同値分割法は数値に限ったものではないという点には注意。例えば地域とか
その中から代表値と呼ばれる値をピックしてテストに使うよね
有効な同値クラスは有効同値クラス、無効な同値クラスは無効同値クラス
分け方というのはテスト対象によって異なる
MECE、研修以来にきいた
重なりもなく漏れもないっていうあれだ
ズームイン・ズームアウト
これ初めて聞いた
抽象的に全体を把握することをズームアウト、より具体化して詳細に把握することをズームイン
因子がズームアウト、水準がズームインみたいなイメージ
同値分割法ワーク
最初デシジョンテーブルか？！とミスリードしてたがよくよく見ると同値分割法でしたね
議論する時間が一瞬で終わってしまって焦る
本題のデシジョンテーブルテストへ
表の上部に原因、下部にアクションを書く
これ書き方いろいろありますよね～、JISだとY/NだったりJSTQBだとT/Fだったりする。統一されてればどっちでも良さそう
禁則であるものを消す、無則な水準を消して簡単化していく
禁則はグレーアウトしておくと便利
グレーアウトもできる、そうgihozならね
圧縮したテーブルはCollapsed Decision Table, 圧縮していないものをFull Decision Tableって名前ついてるんだ
limited-entry decision tableですべての条件が網羅されてるものを comple-limited decision table(であってる？)
ふりかえりをふりかえる
SaPID is 何
SigSQA is 何
これまでのセッションに関する振り返り、どうだった？
振り返りそのものがどうだったかとか考えたことがないかもしれん
ここまでのセッションで最も印象に残った出来事は？
これまで書いた振り返りに「最も印象に残った出来事」に関する付箋があるか見る
なければ追加する
その出来事ってポジティブ？ネガティブ？
その出来事に紐づく感情が書かれた付箋がありますか
なければ追加してどうぞ
どうしてその出来事が印象に残った・インパクトがあったのか
理由が書かれた付箋がありますか
なければ追加を
このあとどう活かせそう？
実務で活かせそうなこと、WACATE2日目で活かせそうなこと
活かせそうなことをやっている自分をイメージできる？
イメージできないなら追加してみましょうね
Most Helpful Reflection
出来事・感情・理由→活かせそうなことを出した
この矢印の間には「教訓・学び」というステップが入る
教訓・学びってやつは出来事や感情などから何を言えるのか意味づけ・意義付けしていると考えることができる
これがうまくできるかどうかで成長できるか
適切な行動に繋げられるか
ちゃんとその事象が起こった理由を認識し、そこから未来へ生かしていけるかどうか
出来事：事実を捉えること
これは難しいこともある
いきなり活かせそうなことにいきなり行く場合もある
頭の中で処理をしている
なんでそれが起こったか？を考えることが重要
振り返りフレームワークは色々ある
KPT / KPTA / YWT / Good&More / FDL etc..
フレームが有るから出せる付箋もある。逆にフレームがあるから出せない付箋もある
フレームワークごとにそれぞれなので、活用するのであればどの場面でどれを使うかを意識するともっと効率的だよ
2日目
継続的テストモデルにおける具体的な施策を学ぶ
Testing in DevOpsの中に書いてある内容が中心になるよ
継続的テストモデルという考え方
一般的にテストというと、開発が終わったあとにテストをしてリリースしていこうみたいなイメージ
それ以外にもテストするところはあるよ！
例えばコード書くときであればTDDとか
設計レビューとか
今回は、Ops側のテストの話
継続的テストモデルを支える技術
リリース戦略とトグル
リリース戦略
デプロイ先が目的などで異なる
リリース戦略とテスト戦略に関係があるよ
作成できる環境やリリースの戦略によってテストも制限を受ける
リリース戦略の例
開発環境でバグ修正や機能を開発して本番環境へデプロイ
開発環境・本番環境
開発環境で開発し、検証環境で検証し、一連のものが終わったら本番環境へ
開発環境・検証環境・本番環境
トグル
何らかの条件でスイッチして見え方を変える
フィーチャートグルだね
継続的テストモデルでの具体的な施策
ダークローンチ
本番環境のデプロイ内容に開発途中のコードを混ぜる
ユーザーには既存機能しか見えない。しかし、コード自体は混じっている
例えば開発環境で作ったものを本番環境に入れるときに、フィーチャートグルをONにした状態で混ぜることにより、一般ユーザーには見えないがコード自体は混じっているとなる
(感想)弊社はこれ
ダークローンチが存在しないと一生マージができず、ビックバンリリースが発生する
テストもその段階で大量のものを検証する必要があり辛い
(感想)過去に1回ビックバンリリースして死ぬほど辛かったときあったな
利点は差分が少なく毎度レビューがしやすい、一方でフィーチャートグルちゃんと設定しないと誤爆します
A/Bテスト
既存の機能と新規機能を一定割合でユーザーに出して、統計的に有用であるか判断する
(感想)A/Bテストとは全然違うんだけど、A/Bテストみたいノリで一定割合のユーザーに段階的にリリースしていくことで、バグを出す範囲を限定的にしながらリリースできるというメリットもある気がする
本格的な実装前に有用化判断できるという利点がある一方、本当にランダムでピックされており、使用結果に有意差があるかどうかをしっかり判断しないといけない。
あとA/Bテスト自体はバグ検出が目的ではないので、バグってる物を出すと普通に障害になるから気をつけよう
一般的に行うテストのあとに実施できる施策
バグバッシュ
短時間にみんなでテスト作業を行い、新しいバグを見つける
開発者とかQAとかビジネス側も関係なく参加していただく
検証環境である程度変更差分ができたタイミングでバグバッシュをしてバグを潰す
開発者がテスター任せにしない（みんなで向き合う）という利点
製品が安定していないと（バグが少なくないと）できない点に注意
バグバッシュだとどうしても工数が生まれるので、スピード感が大事（つまり1日でリリースしたい）とかには不向き？
ドッグフーディング
社内リリース環境みたいなのを用意しておいてそこにデプロイする。バグバッシュよりも長い期間で試してもらい、バグが見つかったら社内リリース環境側を更新していく
利点：問題が一般ユーザーに流出するリスクがない
一般ユーザーと専門的な知識に差がある場合はバグが見つからない
ドメイン知識（例えば法律とか会計とか）が必要な場合も同様に
新機能の利用者を徐々に広げる施策
ベータテスト
新しい機能を特定のユーザーにリリースして試してもらうやつ
利点：特定のユーザーならではの多様な視点でみてもらえる、早めに出すことで他社との差別化
注意点：βテストに参加する層を理解しておく、バグの一部が「バグなのか新機能なのかわからない」状況になり見過ごされてしまうリスクもある
カナリアリリース
ユーザーの一部にリリースして状況を見て全体に広げるか判断する
特定バージョンで振り分けたり、アクセス先サーバの所在地とか
Androidとはstaged rolloutって機能があったり
トラブルが発生したらもとに戻す
利点：想定外の自体になった場合に全体へのリリースを取りやめ可能
ただし、ロールバックの仕組みを準備しておく必要がある。A/Bテストとの併用が難しい（統計的にランダムである保証がなくなる）
おわりに
リリース戦略とテスト戦略は密接な関係があって、リリースの戦略によってできるテストも変わってくる
QAだけ・開発者だけではなく、インフラとかも巻き込んでやっていくのが大事
全体の戦略とかリリース戦略まで踏まえたテストができるとGOOD
探索的テストをやってみよう
探索的テストをやってことある？
（感想）ない
大体探索的テストと言う名のモンキーテストになる
探索的テストってよく聞くが、テスト対象がないと練習できないんですね
探索的テストとは
James Bach(Exploratory Testing Explained)曰く「学習・テスト設計・テスト実行を並列でやるテストのこと」
基本的にテストケースを作らずにその場で全部やる
Elisabeth Henrickson(Explore it!の人)
↑のに加え、気づきを次のテストに活かす
アドホックテストとは何が違うんや
どちらも特に準備をせずにやる
探索的テストは「動作させて動きを把握しながら、あたかも探索するようにやっていく」
要はなんだ
学習・テスト設計・テスト実行を並列でやるテストのこと。テスト対象を動かしながら観察しテストをする。その結果を次のテストに活かしながらやっていく
これがこうなったから、こっちはこうなるだろ？みたいなのを考えつつやっていくんかね
テスト担当者が自由意志でやる。
スクリプトテストとの違い
スクリプトテストは予めテストケースや手順を決める。そのため、仕様の確認に向いているが、テスト実行するまでに時間がかかるというデメリットが有る
一方、探索的テストはテスト手順を予め用意しない。仕様が綿密に固まっていないバグを見つけるのに向いているが、属人性が強く再現しにくいというデメリット。また、品質の評価には向いていない。
あと結局再現手順が残らなくて何がどうやばいのか追うのが大変そう
いつやるん？
どのテストレベル・テストタイプでも基本可能
例：システムテストは探索的テストだけ
基本はアンチパターンである点に注意。アプリが壊滅してるみたいなものに気づけるように
例：画面は探索的テスト、APIはスクリプトテスト
ロジックは全部APIに寄せているので、APIでそれに応じた動きだけ見る
場合によっては良いと思う
探索的テストの方法
フリースタイル探索テスト
目的とか時間も決めずに行うスタイル
スコープが広範囲になったり、いつまでたっても終わらないとかに陥りがち
テストチャーターを用いた探索的テスト
ある指針に基づいて探索的テストをするやつ
チャーター
Target(テスト対象)
Resource(使う資源)
XSSインジェクションが可能な文字列
キーボードのみ使って入力
Information(見つけたい情報やテスト観点)
脆弱性
意図しないUI
チャーター以外での不具合は一旦メモってその間にはやらないようにする
時間を決める
セッションベースドテスト
時間を区切る
厳密なレポートが必要
テストチャーターについて
チャーターを作る
どこに対して探索的テストをするか決める
内容を考える
何が起こると一番まずい？
仕様の曖昧さを見つけ出す？
過去の経験上バグりやすいところ？
探索的テストのやり方 - 観察編
カウントできるものに注目する
ゼロとか境界値とか
CRUD
データのライフサイクルを狙う
状態遷移
その他細かいこと
画面のチラツキ
URLのクエリパラメータ
探索的テストのやり方 - 記録
探索してるときにやった内容はメモを取ろう
何やって何が起こったか記録残らないがち
チャーターに関係ない不具合も起こりうるのでメモをね
うまくなるには
手を動かすしかねえ～！
最後に
Exploratory Testing 3.0 曰く「探索的テストはテストそのものだわ。そもそも全てのテストに探索の要素って必要じゃん？その中でスクリプトちゃんと書くかどうかの問題であって、そもそも探索的テストって言葉いらねんだわ by James Bach」
昼の分科会
どういうテストを自動化するか
具体的なツールと言うよりは、どういったものを自動化すると良いよという話をしたい
テスト実行の自動化が多く出てきている
実はそれだけではなくて、テスト設計や実装の自動化もある。実行以外もあるよというのは頭に入れておいたほうが良さそう
あ～PICTとかそうかなるほど（実行を自動化してるわけではない）
言われてみれば使ってんじゃん、となった
UI, Service, Unit（テストピラミッド）
UIはコストが高く時間がかかる
Unitはコストが低くパッと実行できる
実際の例
例えばどこやりたい？
ここ落ちてたらやばい！みたいなところを重点的に
例えば金額とか
計算ロジックがどこにあるかでUIでやるのかUnitでやるのかという階層もね
ブラウザやデバイスの違いとかをみたい
Androidの端末でカメラと表示がかぶる（セーフゾーンの設定とか）
古いiPhoneとか
実際にそれで何を見たいのか、というのが重要
ペルソナを決めて「こういう人はこうやって使うやろ」に基づく
境界値とか最大値とかそういったものを入れてみる、選択に合わせて項目が変わったりもある
境界値の部分もUIでやるん？
計算自体は単体テストかな～
例えばUIテストで「本来検証したい部分ではないところの変更でそのテストがコケる」みたいなことがあるとつらい。計算ロジックの検証をするのであれば、別にUIレベルでやる必要はないのでは？という意見もある
UIレベルでやる→体験を担保したい？
新規登録ができるのか、ログインができるのか、退会ができるのか…
ど正常系
UIが変更される可能性も考えて、あえて作らないという方法もあるかと
みんなどんな書式でテストケース書いているの？
コンテキストの異なる人とテストケースの書式を共有して改善の機会にしましょう
本等を読んでも現場レベルで実用的なフォーマットって違うと思っていて、そういったものを組織を超えて共有する機会ってないよね～わかる～
参考情報：ISO/IEC/IEEE29119
Agile Corporation
確認するストーリーを箇条書する
Traditional Ltd
目的とか参照資料とか
カバレッジ
テストケース…
参考情報：よろしくない例
何が何でも一覧形式にする
表形式でずらずらと…
つらい…
絶対大分類・中分類・小分類にして、条件に自然言語は本当につらい
組み合わせのない2d matrix
どういうことなの…
参考情報：どこでバランスを取る？
自由記述がよい？フォーマットを固定する？
具体的？抽象的？
この辺は様々な要因でかわってくる
複数人でテストをする
スキルの差
スキルが高い人が多い場合に置いては自由記述でもなんとかなるが、経験が浅い人がいる場合定型のほうがよかったり
ドキュメンテーションコスト
抽象のほうがコストが低いかもしれないけどそれで本当に大丈夫？
現象の再現ができるかどうか
そのテストケースの書き方で再現できる？
発表
書き方って状況次第だよな
例えばテストを実施してくれている人がエンジニアなのか？それともプロダクトへの理解度が低い方なのか？
テストケースの管理が何にせよ辛い
スプレッドシートを使うのやめたいんだよな
思っていたより「再現手順」を自然言語でしっかり書いているところが多かった。個人的にこれは辛いんじゃない？って思うんだけど、検証する側との知識差みたいなのあるしな～難しいねになった
レビューが教えてくれたこと
あだち部長
なぜレビューなのか
レビューはテストの一つやぞ
JSTQB-FLのシラバスにも書いてあったね
レビューっていろいろあるよね
コードとかそういうのだけじゃなくて、稟議だってレビューだよな
大量の指摘が繰り返される
レビューで大量の問題箇所が見つかり、その記録に工数がかかった。それに対する戻しに対しても指摘が重なり…というループを4回繰り返した。で、「なんで最初から全部言わないん？」と文句
これみたことあるな～（白目）
レビュアーからすると「丁寧にやって時間もかけたのになんで文句言われないといけないのや」となる
ただ現実的なところ
一度に全部は無理
時間と品質が比例すると思ったらそんなことはないと思う（それはそう）
そもそも前提の設計や考慮漏れがあったらどうにもならんよね
ここからなにがわかるか
質の悪い仕事はすべてを不幸にする
正しいことが常によいわけではない
どうするとよいのか
そもそもそれ変更がでかすぎない？小分けにするといいかも
人間、よくも悪くも感情で動く。いくら正しいことを言ったとしても、感情ってやつには勝てない
めちゃくちゃわかる
受け取りての気持ちに配慮して、できるだけ円滑にコミュニケーション取れるようにコメントするとか気をつけよう
セルフレビューの習慣をつけよう（セルフチェックなしでレビュワーにレビュー依頼するのはやめよう）
(感想)セルフチェックも大事だし、Linterをかけてエラーになったら機械的に知らせるとかも大事かも
代表者が斜め読みして差し戻すなどしようね
対象の質がレビューに与える影響
構造化した文章 vs すべて1paragraphで書いたものを比較すると、構造化された文章のほうがレビューの精度が良い
つまりレビューにおいても成果物の質が大きく変わる。レビューのフェーズに入れるドキュメントは質を高くしておくことが最適化への近道
そもそもドキュメントの段階で質が低いと、本来みたい技術的な側面のレビューに時間を割けなくなる
3段階レビュー
すり合わせって本当に大事だよね
最後のフェーズで不具合出て手戻り、死って感じだ
作業者には確証バイアスってやつがある
そうだな！
不具合の指摘はあくまでコードに対してであるが、自分が否定されていると取る人もいるのでこわいね
受け取りやすい指摘の伝達
主語を”あなた”ではなく”私"にする
例：自分にはこう認識してるんだけどそれであってます？
断定的な物言いをしない
もしかすると～～かもしれないので確認してもらっても良い？
大体手段の話が揉め事になりやすい。手段よりも事実や目的にフォーカスしよう
コミュニケーションスタイル
相対するタイプの人と話が噛み合わずに辛くなる
チェックリストの形式適用
チェックリストを運用し、レビューでの見逃しが多い問題を解決しようとした
ある程度防げたが、深いレベルの指摘が以前より検出されない傾向が強まった
チェックリストに書いてあることさえやればいいんでしょ？=現状維持みたいな形になってしまった
思考停止
ルールや基準ってやつも定期的に見直して（思考して）作り変える必要がある
ルールを破った人が「なんでそうせなあかんのや？」→「ルールだからや」というのも、なんでそのルールが有るのかも考えずに返答してしまうと辛い未来が待ってそう
ルールや定められた手順を守ると良いことがある業務
だいたい手続き系やな…
ルールがないとか変えなきゃいけないルールってやつ、考えて変えてみよう
不備・不整合指摘が多い
レビュー実施日を大幅に遅延した成果物のレビューをしたところ、不整合があって。その原因が度重なる要求変更だった
要は相手の言うことをそのまま鵜呑みにして変えていたパターン、それ大丈夫？
人間は「目的や問題」ではなく「手段」を要求しがち
要求を何でも入れるのは本当に良いのか？
これ、達成したい目的とかがブレるとなりがちじゃないですか
なんでもかんでも実装というのは
何でも要求を受けるのは悪である。ビジネスなので、フェアにやっていかないと
不備や不整合がおこっている裏には変更要求を過剰に対応があるかも
なんでそれをやるのか、ってのは重要ですね
コストと納品日の関係
ラピッドデベロップメント
効率の良いスケジュールを実現するために必要なコストは、可能な最短スケジュールを実現するためのコストに比べ大幅に少ない
期間を8%減らした結果、工数が38％増えた
関係が線形ではない…やばいな
目的の確認、本当に大事。コンテキストや目的を共有した上で、適切に優先度をつけてやっていく必要がある
マジで大事。何でもかんでもできるわけではない（工数に限りがある）ので、やるやらないの判断をするためにも適切な情報提供は大事
例えばお問い合わせ対応をエンジニアがする場合、背景がすっぽ抜けてたり温度感がぬけてたりすると「それ今やらなきゃまずいのか？」っていう話にもなってくる。このあたりはテンプレートがあるとよいのかもね
普段の立場で見てしまう
要件定義レビューにおいて、レビュワーのポジション絡みたものばかりになっていたのだが、このやり方で大丈夫？
レビューの監修として実施してしまい、自分の立ち位置からの視点でしか確認をしなくなる
どんな立ち位置の人が集まったかによって、レビューの観点が固定化されてしまう懸念
人間は習慣の動物であり、なれてくると思考停止しがち
レビューの目的や、観点を明確化してレビューしよう
関係者それぞれで観点が違う問題
例えば事業を統括する人って現場のシステムのことって見えづらいよね
自分で見えてるもので判断しがちなので、立ち位置によって見え方が変わる
立ち位置の違いってやつを認め、認識をそれぞれで合わせるためにレビューってやつがいる
ステークホルダーとその関心事を頭に入れておく
レビュー観点図ってやつをプロダクトごとに持っておくといいのかも
レビューのシフトレフト
作業の成果物にたいしてレビューするのではなく、作業をする前にもレビュー（進め方とか）を挟むことで手戻りを減らしながらできるぞ
後出しジャンケン感を減らそう（それ最初から言ってくれよをなくす）
信頼がない上長からの依頼
パワハラ上司が「君らの思ってることを素直に教えてくれ」って言われました。さてどうする？
言うわけがないんだよな
実装しているか、経験した上での話があるかで説得力が変わってくる
傾聴テク
その場しのぎでは効果ないよね
信頼ってやつは長い期間を経て積み上げられる
し、崩れるのは一瞬だよなって思う
論理的に考えて、それを情に乗せて提供しよう
相手は多分こう動くから…というのを考えるのも大事かも
へえ
結局人間間コミュニケーションに落ち着くんだよなあ、ってなっている
誠実と能力、両方あることが大事
どちらかが欠けてしまってはいけない
心理的安全性な
わからないことを言える環境、マジで大事
その上でちゃんと教えてくれる（教えてあげる）のも大事
周囲が賛同しない取り組み
品質向上施策をやることになった。周りは特に参道もなく評価も微妙だったが、ある執行委員だけは見ていてくれ評価してくれた
意味があることであれば周りの目線などによらずしっかり実践していくこと
これ結局周りを変えよう！などと息巻いて頑張りすぎず、与えられたことをできる範囲で着実にやっていくのが大事
自信を持つ方法
自分で自分に貸した約束を守る
守れない約束はしない
これマジで大事だと思う。うっかりなんでも受けがちなので気をつけたい
成功体験が大事
できなかったことができるようになった体験
過信は気をつけよう
自分の価値観を持つことが大切
最初は尊敬する誰かの真似でもいい
色々と吸収し、どんどん自分の言葉で言えるようになろう
こういうのはもう経験とかによるところもあるから、上で書いたように成功体験積み重ねるしかないな
初論文構築・発表
JaSST'06北海道をやることにしたが、コンテンツが不足していた。そのため自分で論文を書いて投稿するなどした。で、様々な結果（オブラート）があったわけだけど、コレがトレーニングとなって毎年展開されることになった。
やっぱりアウトプットしないと
成長になる
他の人が見ている可能性がある
ストレッチ目標って大事
論文投稿とかってかなりハードルが高いので、JaSST nanoってやつからいくといいのかもね
ラーニングピラミッド
学習定着率、やはりアウトプットがないと
ストレッチ目標大事
手が届かないってのはあれ
背伸びしたら届くかも？ってやつが大事
ひとりビジネスのふりかえり
これまでのビジネス、成功だけでなくたくさんの失敗や挫折を味わってきた
ほぼ一人って書いてあるとおり、自分だけでなく様々な人の協力の上で成り立っている事に気づいた
利己的な行動は短期的には良いかもしれないが、長くは続かない。関係者もみな幸せになるように倒したほうがよい
実務に学習サイクルを入れ込むことが効果的
正しいと思うことに関しても、半分ぐらいは「本当にそれでよいのか？」という疑問を持つようにすること
専門家バイアス
異なる味方や意見から学ぶ
振り返りが大事
KPT / YWT / ORID
4行日記
三方良しを見つける
自分も会社も利用者も嬉しい
マフィアオファー型プロセス改善
自分自身への気づきを高める方法
スーパーエンジニアへの道 技術リーダーシップの人間学
人間のものごとの取り込み
Virginia Satirの交流モデル
成長サイクル
まずアンテナをはらないと機会がないのでな
挑戦してふりかえろう
そして成長へ…