WACATE2019冬 参加報告会 - WACATEに参加した前後で何が変わるか？
概要
12/14・15日のQAの合宿型の勉強会の参加報告としてこちらのイベントでLTしました。 https://d-cube.connpass.com/event/159920/
資料はWACATEに参加した前後で何が変わるか？にフォーカスした内容にしました。
全体の講演内容の所感なども書いていただいています。shiro (id:yuki_shiro)さん,「テストの宿泊型ワークショップWACATE2019冬参加報告」で参加報告してきました
発表前・ネタ
面白い題材ないかなあと思ってマインドマップで思考を発散させつつ寝かせていましたが、ちょうど発表一週間前に転職透明らぼさんのイベントで人事兼エンジニアの方がポテンシャル採用をする際の見る箇所とWACATEの加速体験が近かったので急遽そちらの話題に変えました。
発表前の思考の発散させたものと、今回の構成をまとめた残骸はこちら
発表後
wacateの楽しみ方についてtwitterでFBくれた方がいて嬉しかった。
あとは盛り上げてくれる方の存在はありがたかった。
アンケートのフィードバックはこんな感じでした。
意外とWACATEの良さを的確に表現する方向にシフトしていたけど、それよりも自分の言葉でといった意見があって難しいと感じた次第。
感想一覧
・内容が入ってこなかった
・モデリングとか全く知らない私でも参加したら少し分かるようになれたかもしれない…
・実行委員からみて、こちらの意図、それ以上のことを言語化してくれてました。ありがとうございました。
・他の方に比べるとご自身の言葉というよりキレイな言葉にされていたので、もっとご自身の本音みたいなものが聴いてみたかったです。
・テスト計画に対する自分の過去のイメージをアンラーニングしていく過程が良かったです！ポテンシャルが上がってく様子が伝わってきました！
・途中退室したため聴講していません。
・言語化できないものはアクションにつながりにくい、というワードが刺さりました。私もまずは言語化することからスタートを切るように心がけようと思います。ポテンシャルの話で「技術を知り、付加価値の出し方に気づいているかどうか」という内容も考えさせられました。私も、自分の付加価値の出し方は？と聞かれると、これもまた言語化できていないので、考え直そうと思えました。
・他の発表者と違い、自分ではない人の言葉を紹介していることが多く、ご本人なりの解釈での言葉や感情になっていなかったのが残念でした。
・途中退室してしまったので聞けておりません...
勉強するための勉強会参加の意義・位置づけ（アイデアだし）
2019/12月追記 3分スピーチ用にマインドマップに全て纏めたので更新します。
ここから展開
背景
思考の整理の過程を出してみると面白いかなあと思って、まずは書きだしてみる。
最初は口頭で、sixpadで筋トレ中にやった考えをテキスト化する。
音声書き出しなので、所々何いっているかわからないところもある。
このあと、以下を考えて
- 構造化モデリングしてみる
- wacateでやってた発表の仕方みたいなものを取り入れてみる
- オーディエンスだとか、アウトカムだとか、発表内容の反復開発っぽいのとか
- 目的と合致しているか、論理構成のレビューと、勉強会のメリットデメリットの内容のバランスを考える
- いくつかの勉強会について、具体的にどんな価値あったっけ？ってなってるので再度深堀する(任意)
目的
プロジェクトで 難しいものぶつかったりするけれど そういった時の立ち回り方 なんかの参考になればいいなと思って勉強会の話をします
勉強会の種類と、得るものについて
まず勉強会の種類について 勉強会の種類を話す目的は それぞれの勉強会の特性によって 得られるものが変わってくるのでその話につなげていきたいと思います
まず勉強会の種類から
- 1年がかりでも 未だに何を言ってるのかわからないスライドもあれば
物も考え方に踏み込んだ勉強会もあるし
自分の知らないロール の人と絡むようなきっかけをあえて持つ
知らない要素技術の勉強会に参加してみて そこでホットなワードを 調べてみたりだとか 自分がどの程度その技術に対して知見があるのかテストしてみたり
実際に聞いてみて簡単すぎなものでも 自分がどうやって後輩に対してそれを噛み砕いて説明するかということを考えるきっかけにしたり
一泊二日のワークショップ形式の勉強会
- 大きなシンポジウムのようなイベント
- 酒場やティーパーティーなんかの気軽に交流するような
までいろいろなものがあります
例えば酒場なんかでは 第三者検証会社 のそれなりにキャリアを積まれるてる方と良いお付き合いの仕方を聞いてみたりだとか
過去の先人の失敗事例 なんかを聞いて転ばぬ先の杖にしたりだとか
本で読むには敷居が高いけれど 何かしらの勉強会をきっかけに 勉強会を目標にしてテスト駆動開発を勉強してみたりだとか
中にはQAとしての密度が 一年の成長速度が数倍になるようなセット勉強会もあります
そのような勉強会の特徴はいくつかあるんですけど
- 自分の考えの空をあえて破ろうとしてくれる人,守破離の家 火を取るような話をしてくれる人
- テスト計画のような なんか馴染みのないようなとりあえず形式的にやっておけばいいんでしょ的なものに対して 明確な目的と 使って幸せになるような動機付けをしてくれるものだとか
- いくつもの勉強会に出ていると なんとなく抽象化されて本質が見えてくるようになります
- 新たなものの見方を提示してくれるような 例えばQAで言うとコミュニケーションスキルが一番重要視されていて、コミュニケーションと言ってもロジカルなものから 相手の悩みを推測して言語化していくような・その地図を書き換えていくような そういった価値があります
- また 自分は朝勉強して夜は だらだらするタイプなので 夜の勉強会はダラダラするものよりは具合がいいと言った そういったライフスタイルに合ってるといった理由もあるかもしれません
最終的に得られたもの
最終的にこれらの勉強会を通して 概念や物事を整理するスキルや、 柔軟にアプローチしていいんだって言う 守破離のりの部分に着目できるところ
たくさんの選択肢戦う道具が身についたこと
先人たちの失敗や 今ある悩みについて 最も適切な人に対して相談できるようなチャネルができたこと
その辺りが勉強会に参加した価値だなあと思います
とはいえ勉強会に参加して 「何もは成果も得られませんでした！」 といった事も多々あるので 最終的には書籍だとか そういったものに頼る必要はあるんですけれど
とりあえず知らないドメインの勉強会に参加しておけば その勉強会で熱いテーマのいくつかピックアップできてそれを足がかりにできるし そういったものはえてして社内で取り組まれていないので 割とやってみると面白い発見があるんじゃないかなと思います
他のロールの勉強会に参加するのは 実際にそこにそのロールで活動されて どういったことを考えて いるんだろうっていうのを知りたいっていうモチベーションなんですけど
例えば開発の人が テスト境界値分析をしてくれて いたりとかすると Qa としては嬉しかったりもして その逆も言えるのでこちら側からお互いのロールに理解を示して歩み寄るっていう姿勢は大事なんじゃないかなと思います
なかには大学の教授とマンツーマンで話す機会もあったりだとか そこで人生の相談してみたり
第一任者の方と直接話す機会もあったりして そういった界隈の情報が入ってくるような状態になるのは結果的に良かったなぁと思います
第一任者の方だと、そのドメインのキャリアに対しての知見は深く 何かしら面白いやりがいっていうのを提示してくれて、興味を持つ良いきっかけを与えてくれる
実際に参加した勉強会リストを見直してみて
スマート SE 関連だと第一任者の人と話していた かつアジャイルの最先端モデルに触れられた そういった話が聞ける
新しいドメインの要素技術を聞いておくと頭の中に全体像ができるので その後の勉強が進みやすくなるっていうのもあると思う
DeNA QA Night の中途 鉄コンテナモデリングと他の企業の実際の取り組みが見えるので ツムレベルが高いので すぐさま役に立つ 役に立ったのか？ 何かしら考えの規定になったモデリングもありだとか 9月4日は読み直しておく
やっぱスマートエスイーのやついいのアジャイルケーパビリティ
楽天だとか 既存の知識をしっかり考えて高いレベルでやってるところもある よくある姓を適切に捉える力
はたまた国際基準的な話もあったりだとか
NAITEのテストレベル定義に考えるも良かったな 言葉の定義を考えると そこで何を決めたらいいのかがはっきりしてくれ テスコン要求分析チュートリアルもよかった 誰のために提出するのか考えるきっかけになった
クックパッドtec conf 何が良かったんだ なんかいろんなアプローチの仕方があるんだなと思った リーン開発でまずは価値検証をやるスタイルだとか 実際にユーザーヒアリングの話 UX 話だとか その辺りは良かった
cI CD と内容ナイトは難しかったなやっぱりこの辺りわかってないんだろうなーと思った
ホロレンズだとかスマートスピーカーを遊びたおす会とかたものは別に何か役に立ってないけど単純に見ても白かった
自動テストカンファレンスあたり去年の部分についてはだいぶ加速できた 今年のはあまり加速できなかったんだよなんでだろ
後はreproとか 不動産テックアプリ特集見たのは確か面白かった気がする Alexa 照明をつけて 広島 2020年3月4日12時から DeNA テックカンファレンスと予定入れて
ここに文字を隠す
11/1 Scrum Masters Night!参加レポート
概要
Scrum Masters Night!に参加してきました。 smn.connpass.com
感想
QAやっててスクラムマスターis 何？って状態だったけど、参加してよかった。スラムマスターの興味・hotなワード、実際に話してみてひととなりや悩み事なんかを一気に知る事ができる（来週はCTOmeetupに突撃するけど流石にこっちはついていけないと思う） #smn2019
— 信頼貯金 (@sinraityokin) November 2, 2019
なぜ？や目的を大事にしてコミュニケーションをとっていたり、チームメンバーの働きやすさを考えて上と斥候できる人など、QA界隈よりアクティブな雰囲気を醸し出す人が多かった。
メモ
■アジャイルを始めたとき
・メンバーを自律させていくように動かす。
3人チームで自立しない人は、自立しない。
メンバーのスクラムへの熱量が大事。熱量が足りないと淘汰される
スクラム始めたが１年で、100人中数十人がスクラムやめた。
・メンバーの数にも、reserch的なものを取り入れている方もいるそう。
・トップダウンでやらないと時間かかる。
マイクロソフトでは３年かかった。ボトムアップはもっと時間かかる。
■知識移転周り
・人数が多いと、スクラムで班（ユニット）に分かれているところがある。
・モブプロは仕様を知った方がいい共通コンポーネントとかをやる。ペアプロは一日の半分まで。それ以上は集中力は持たない。
・ペアプロはユニット（班でやる）、モブプロはユニット間で調整する必要があるからセッティングが大変。
教育と、レビューの目的がある。最大生産性を意識して動くチームなのでやるタイミングはチームの裁量。
■評価周り
・メトリクスは時間あたりのポイント数で測ったりするが、あまりモチベーションはあがらない。
チームの評価、人事評価をどうするか。
スプリントが良かったか。その人が成長できたか。星取表の更新をする。
・プロダクトへの貢献とメンバーの成長は別軸の場合がある。
知識の移転はありだけど、成長を求めるとぶつかる。
プロダクトの価値の世界観が大事。これはリーダーシップがなければなしえない。
成長を求めたりプロダクトへの貢献とのすり合わせが難しいなら、ならグーグルの20%ルールのようにPOの目標とはまた別の時間を設ける。
■その他
・障害リストは自分用とメンバー公開用に分けていたりする。
率直に伝えるのが難しいこともあるそう 。
・スケジュールについて
火：リファインメント
水：振り返り・レビュー
木：プラニング
スケジュールにも意図がある。月金は祝日が多い。
水リリースなので、プランニングは木がいい。
他にも色々な理由があった。
時間はスクラムガイドの時間をベースにしている。
■以下懇談会でのQA
Q.スクラムマスターって、別のチームに移ったらまた１から始まりですが同じことの繰り返しになるとつらくないですか？
A.チームによって性質ややることは違うので、そんなことはない
Q.スクラムマスターの指向性って、カウンセリングや開発方法論的な方向はあると思うのですが、どういった方向を見ていますか？
A.ビジネス・開発寄りのどちらのスクラムマスターがいてもいい。それぞれのドメインを元に価値を出せばいいし、ビジネスよりなら、テックリードと仲良くするとか弱みは補完できる。
Q.1on1やったことないんですけど、ある程度繰り返して重度の課題がなくなるとなあなあになりませんか？
A.1on1の目的は、チームから問題をいいづらい場合もあるので、問題を聞く場 を設けることが大事にしている。
課題がないなら早く終わらせればいいだけ。
ググってたリスト
■OKR
https://bizhint.jp/keyword/39402
https://seleck.cc/okr
■スクラムガイド
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
■スキル移転周り
https://qiita.com/bringer1092/items/a459cc9e9e2bc2b25deb
https://www.ryuzee.com/contents/blog/7065
トラックナンバー
http://bonotake.hatenablog.com/entry/2018/01/12/232223
■チームの人数周り
多数の心理（たぶん、人数が増えた場合の個人の責任感の希薄化のこと）
キーワード駆動システムテスト チュートリアル（素振り）のコンテンツフィードバック
※勉強会に参加された方へのコンテンツのFB用の記事であって、考察などはあまり含まない（かつ参加者しかわからない粒度でしか記載しない）ので、このブログから何かしら得られるものはないと思います。 興味のある方は概要記載の資料を見たほうが有用かと思います。
■勉強会・記事概要
- 日程:19/10/26 14:00-17:30
- URL:https://kokucheese.com/event/index/582210
- 資料は後日小井土さんが公開にアナウンスされるとのことなので省略します。おそらく以下にアップされるかと思います。
- 参加者は小井土さんの知り合いと自由参加枠があり、自由参加枠で参加させてもらいました。計６名でした。
■記載者のドメイン知識
FBをするうえで、記載者のドメイン知識は前提として伝えておくべきなので、記載する
- 自動化のコードはあまり書かず、アーキテクチャの設計は未経験。ブラックボックステストメインのQA５年目
- キーワード駆動は軽く触ったことはある
- 資料側（キーワード駆動自動テスト）は独力で一通り読んで理解できた。チュートリアル側は、前半はおそらく大丈夫で、後半のキーワード駆動で脱落しかけた。
■得たこと（自分用）
- 何に活用できそうか？
- 自動テスト、キーワード駆動設計時のレビュー時の有用な観点を知る事ができた
- 自身で設計するのは、まだ掘り下げが必要
- 新しく得た発想は何か？
■よかったこと（FB用）
- 自動化する際の要求として、資料側に指針となること、チュートリアル側に具体化されたことの両面が書いてあって、今後見返して活用できること。先人の通った道筋が参考にできるようになったこと
- 特にードの品質として複数人で継続的に自動テストに関わるうえでの思想・ルール（とどう記述すべきか）など取組の意識の高さが凄い
- 普段考えるきっかけのなかった視点・発想に触れられた
- その他
・例題・電卓演習
- 各step毎に要求の具体例があるため、アークテクチャ設計や自動テストを進めるうえでの実際の勘所に触れられたこと。また、それらの要求の思想（という普段表に出てこないもの）を考える事ができた
・キーワード駆動チュートリアル
■難しかったこと（FB用）
そもそも、今回のチュートリアルにはそれなりの前提知識や経験が必要だが、そこに至れていなかったことが全ての敗因。 併せてアーキテクチャ設計など高度に知的なお話を他人に認識の祖語なく伝えるのは難しいのでどうしたら多少は緩和するんだろう？って思った。
・例題・電卓演習
- step2以降の質問で「追加したようが良い要求」とあるが、各stepの範囲がタイトル・具体例から汲み取りきれなかった。step2で答えた内容が実はstep3で述べられていたりと、各ステップを行ったり来たりしつつ考える必要があったこと。他にはテスト計画やJSTQB(Advanced Level Test Automation Engineer Syllabusのこと？)のフレームワークに併せると良いのではといった話もあった。
・キーワード駆動チュートリアル
- キーワード駆動の基本を理解しつつ、並行してチュートリアルの意図や、達成したいこと・制約など、さらうことが難しかった。(考えるきっかけになってよかったことでもある)。
- キーワード駆動の知識：
- キーワード、値、対象の定義（説明はあったけど、理解がおいついていなかった）
- キーワードの定義と、実行スクリプトのイメージの両方が必要だったが、後者の観点が抜けていたので
- チュートリアルの意図:システムアーキテクチャへの要求事項を考え設計に落とし込む
- 達成したいこと・制約
- 一つのキーワードテストスクリプトで、二つの出力の異なる電卓をサポートする必要がある？（ように最初は聞こえたが、そのあと違うことが分かった。このあたり、全くついていけなかった）
- キーワード駆動を取り入れることにより達成したいことと、そのすり合わせができなかった
- 電卓の計算機能
- ボタンの押す順番による状態
- e.g.異常系（有効桁数を超えて数値の入力・＋ボタンを２回押すなど意図しない操作も対応できる）ことを見越すのかよう。また電卓液晶部の表示系の確認も含むのか
- キーワード駆動の知識：
■感想
以下の自動テストチュートリアルを紹介いただいたので、まずはキーワード駆動テストチュートリアルハンズアウト.03.06から出直す。 チュートリアルをする前に、キーワード駆動についてどういった思想で作られているかがわかったうえで、取り組めるのはとても有難い。
チュートリアル化する際には、また参加したい。数日かけてじっくりだと嬉しい。とても高度なチュートリアルなので、時間として適切か、認識の祖語なくチームで進められるか、対象者は適切か、などの敷居を埋めるにはある程度の日数が必要そう。
チュートリアル参加者５名と少人数、かつ集中する必要のあるチュートリアルだったので、シェア用のお菓子をもっていって正解だった
JaSST2019 参加レポート
概要
JaSST'19 Tokyoに参加してきました！
講演資料は上記リンクに後日公開されるはず。
まずは、去年と要領が違ったので、来年のためにメモ
- 早割り券は発売から一週間足らずで売り切れ。一日券は開催日一週間前には売り切れていたので早めに動すること
- 各講義に参加するためには事前に予約しておく必要があった。前日でも間に合ったので受講票に登録して印刷すること
- なのでオープニングセッションは早めに会場に到着する必要はなかった。
参加レポート
1. AI-Driven Testing:A New Era of Test Automation
github: https://github.com/UltimateSoftware
tariq kingの論文:https://scholar.google.com/citations?hl=en&user=7_WXT5sAAAAJ&view_op=list_works&sortby=pubdate
ソフトウェア業界は長らく止まっており、改めてテスト自動化について考える時期が来ている。
テスト自動化は、テスト対象の選定・機能の妥当性の定義、テスト設計、テスト実装（期待値も含む）・テストスクリプト実装・実行結果の確認、人手の介する作業が多い。これではスケーラビリティに欠ける。
また、テストは人手を介する以上リニアにしか増えず、指数関数的に増加するテストに対して物足りなさはある。
AIを利用したアプローチによって、色々と解決できるよというお話。
- AIとは
- ４つのプロセス（探索する、モデル化するランダムにアクションする、学ぶ）で構成される
- 人間と一緒
- 命令されて動かない。自身で判断して動く
- 経験して学ぶ。人のやっているプロセスを真似する
- そのものの概念を知る必要はない。特徴量をベースにクラスタリングする
- AItestのアーキテクチャ
- coordinatorとworkerで構成する。Cordinatorは...
- リンクをひたすらクリックすると、テスト対象とは無関係な外部のサイトに飛んでしまうのでスコープを決める必要はある
- 大量のログ・エラーに対してはグルーピングして、人の目で見れるようにする
- AItestの現状と方向性
- 複雑性の低めのアプリに対しては行われている。今後デスクトップアプリへの適用するには複雑性が跳ねあがる
- AIテストのメリット
- AI普及のために考えるべきこと
- AIを特性を理解してテストに適用すること
- ミッションクリティカルシステムではテスト支援として利用する。
- この話は、「AIプロダクトに対する品質保証の基本的考え方」で語られているはず
- AIのテストの準備
- ホワイトボックステストをAI用に再定義する必要がある。（ホワイトボックス同値分割は使えない）
- AIのロジック(HIDDENLAYER)が何をしているのかわからないので人に受け入れられるようにする
- 説明可能なAI
- Self Healing 。AIそのものをテストできるようにする
- 量が多いので、信頼度の定量化する
- ドメインを選ぶ。ミッションクリティカルなものは、あくまで支援（サポート）とする
- データをコミュニティで共有できるよう、何かしらのインセンティブとフレームワークが必要である。
- AIを特性を理解してテストに適用すること
※文字列の推論の話をいれる
感想
E2E自動テストを作るときの悩み所を解決してくれる画期的なアイデアだが、
AIテスト導入時には、テストの目的をAIの特徴を理解したうえで適用する必要がある。
その際にはテスト設計技法な大きく考え方を変えて再構築する必要があること、AIへの諸々の理解が追い付いていないと場当たり的なテストしかできない事を肝に銘じておく。
将来、AIテストが発達したころにはテスターはAIトレーナーになるのかもしれない。 現状の私の能力とAIに対しては隔たりは大きくが、まずは今進めている機械学習を含め理解している要素技術を広げていくことで準備する必要はある。
2. TPI NEXTを活用したチームメンバーの問題意識から始めるテストプロセス改善
改善には、分析的アプローチとモデルベースアプローチの２種類がある。
それぞれメリットデメリットはあり使い分けが肝要だが、ここではハイブリットな利用をしている。
具体的にはモデルの学習コストの高さを補うべく分析的なアプローチから始めて、部分的にモデルであるTPINEXTを利用し局所的最適解に陥らせずベストプラクティスにつなげる。
- TPINEXTとは
- 分析的アプローチとモデルベースアプローチ
- P110参照
- 分析的アプローチ
- モデルベースアプローチ
- 改善事例を寄せ集めたベストプラクティス
- モデルは色々な事を端折っている。端折られていることやチームの背景に合致しているか確認せずに適用すると苦労する
1
第2回enPiT-Proスマートエスイーセミナー: アジャイル品質保証と組織変革
プログラム
日時：2018年9月7日（金） 18〜20時 キーワード：アジャイル品質保証の知識体系、パターン、形式工学、組織変革ほか プログラム： - 18:00-18:10 アジャイル品質保証の知識体系 SQuBOK 2020 予定より - 18:10-18:40 基調講演: アジャイル品質保証パターン: Quality Assurance から Agile Quality へ - 18:40-19:05 招待講演: OODAと品質保証 - 19:05-19:30 招待講演: 高生産性と信頼性におけるアジャイル形式工学手法 - 19:30-19:50 招待講演: ソフトウェア工学の観点から見たアジャイル - 19:50-20:00 招待講演: “アジャイル組織への変革”と“アジャイル開発の成功・定着”のポイント
各公演の資料は以下を参照ください。qiita中の画像は全て講演資料の引用になります。 https://smartse.jp/information/2018/0705201707/
アジャイルって何？って方は以下を参照ください。 アジャイルソフトウェア開発宣言 … http://agilemanifesto.org/iso/ja/manifesto.html
アジャイル品質保証の知識体系 SQuBOK 2020 予定より
SQuBOK2020へアジャイルを追加すること、アジャイル開発のパターンランゲージをさらっと説明。後段の講演でそれぞれ深堀する。
- SQuBOK2020にアジャイルの品質体系を追加予定
- 品質の概念…バリュー・チーム全体・バグ即修正・改善活動
- マネジメント…アジャイル品質保証パターンQA2AQ、アジャイルスキル体系SFIA
- 品質技法 …アジャイルメトリクス、品質ダッシュボード
- アジャイル品質保証パターンQA2AQ(Quality Assurance to Agile Quality)とは
- 従来の品質保証（ウォーターフォール）からアジャイルな形にするための方法を集めたもの。下にあるように色々な要素から成り立っている。
※補足：そもそもWFとアジャイルの品質保証の違いについてはこちらを参照ください。
所感：障壁の解体・品質の組み入れ・品質の可視化いずれも実施できていない箇所だった。そもそもだが、アジャイル品質保証とWF品質保証で、メトリクス的な役割とゲート的な役割の違いは大きいと思った。ゲートを定めていない分アジャイルは特に可視化が重要なのかなと。
アジャイル品質保証パターン: Quality Assurance から Agile Quality へ
アジャイル品質保証パターンQA2AQの紹介。 QA to AQ: Quality Assurance から Agile Quality への紹介と重複する部分は割愛。以下の説明がしっくりきた。
核心は「組織の壁を壊すこと」と、品質をプロセスの最後に「分離」せずに全体の中に「組入れる」こと。そして、そのために、品質面での習慣化(1)を支援するパターン、品質を特定し(2)、そして、それを可視化する(3)パターンという構成です。とてもわかりやすいですね。
- 品質でアジャイルになる。行為ではなく習慣である
- 同じチームとして価値のある情報を提供すること
- チーム全体が品質に取り組む
- プロダクト、マネジメント、品質保証、アーキテクトの相互作用
- システムの品質(最後の四つが開発スピードに影響)
- パフォーマンス
- セキュリティ
- スケーラビリティ
- 可用性
- 信頼戦
- 保守性
- 進化性
- テスト容易性
- デプロイ容易性
- バリューがプラクティスを駆動する（？）
- 責任時点を計画する
- さまざま判断は最大限遅らせたうえで選択する
- 視認性が重要
- 計画・ラジエーターなど諸々の可視化
- CI(継続的インスペクション)でコードの匂いを検出。メトリクスを自動で計測する
- バックログに品質を積んで定期的に実行
- 改善には余分な時間が必要。計画に組み込んで時間の確保すべき
所感：先の講演とつながる部分は多かった。新しく出たもので開発スピードも考慮すると、テスト自動化や最悪ソフトウェア動きについて仕様は整理しておいた方がよさそう。また、バックログに品質に関するタスクを積んで実施する（余分な時間を設ける）ことも明示されなければ後回しそうだ。
OODAと品質保証
OODAループを品質（テスト）に取り込む
- OODAとは…観察 (Observe)、情勢判断 (Orient)、意思決定 (Decide)、行動（Act））の略
- 近いものでPDCAが思い浮かぶか、より機敏に実施し学びが蓄積されやすい
- OODAをテストに適用する
- 動くところからシステムテストをしてしまう
- 早期のフィードバックで、後段で起こりうる類似のバグをつぶせる！
ソフトウェアパターン界の「パターンプリンセス」からQAとしてアジャイル開発へのかかわり方へのアドバイス
- stealthでいること
- 回りから見えない存在・透明人間
邪魔にならない存在
早いうちから巻き込め
- 設計者とともに、システムやフィーチャを学ぶ
- 要求仕様や設計ドキュメントのレビューに参加する
- テスト計画のレビューに設計者を招待する
- まずは見守る。
- リスクセンサー…朝会の観察
- メトリクス…まずは開発の負担にならないよう出来る範囲ですすめる
結論：OODAにより品質の情報を“早く“フィードバックし、品質の埋め込みできるアジャイルが好きだ
所感：開発者と協調することは引き続き意識する。バグを観察し観点を早期にフィードバックし改善することによるバグの収束もアジャイルのメリットなので、活用していきたい。
JSTQB 行動規範
同僚 - ソフトウェアテスト担当者は、同僚に対し公正かつ協力的でなければならず、ソフトウェア開発者と協調しなければならない。
高生産性と信頼性におけるアジャイル形式工学手法
- Agileを取り入れるにはプロジェクトが小さい（プロジェクト期間が5ヵ月・5000LOC）又はクリティカルでないものがよい
- Agile manifesto
- プロセスやツールよりも個人と対話
- 包括的なドキュメントよりも動くソフトウェア
- 契約交渉よりも顧客との協調
- 計画に従うことよりも変化への対応
- Agile SOFL(Agile Formal Engineering Method) を利用することでアジャイルの欠点を克服できるのか？できる
- 要件やシステムの潜在的な動きを理解する3段階のアプローチ
- Informal Specification
- Gui design And animation (e.g. PowerPoint)
- Hybrid Specification
所感：アジャイルと対極にある形式手法からといって敬遠せず、スケールしていく開発の中で破綻しないようカッチりドキュメントを書いてたり自動化するなど、ソフトウェア工学的な観点も取り入れていくことも大事。
ソフトウェア工学の観点から見たアジャイル
所感：設計・プロセスを重視するソフトウェア工学と、（ドキュメントではなく）動くソフトウェア・（プロセスより）個人との対話を重視するアジャイル開発を比較し、手段ではなく目的によって方法を選ぶことが大事。
“アジャイル組織への変革”と“アジャイル開発の成功・定着”のポイント
"アジャイル組織への変革”に役立つ書籍（一冊）
アジャイルエンタープライズ 出版社: 翔泳社 (2018/3/19) XP祭り2018の協賛本の一つ
“アジャイル組織への変革”と“アジャイル開発の成功・定着”に共通する重要なポイント（一つ）
AgileCxO(組織) と APH(改善モデル）の紹介
APH:Agile Performance Holarchy(アジャイルパフォーマンスホラキー)とは、200を超えるアジャイルプロジェクトの分析結果をもとに作られた、アジャイルをスケーラブル（拡張可能）でかつ持続可能にするための行動指針を提供する“改善モデル”
CMMIは組織成熟度モデルを5段階で定義しているのに対し、APHでは3段階（’Adopting・Transforming・Masteringのいわゆる守破離）で定義されている。観察を重要視する。
APH無料サンプル本ダウンロードはこちら：https://agilecxo.org/wp-content/uploads/2018/05/APH_model_teaser_v3.pdf
所感：これまでの講演だけでなく、組織からの支援が要素に入っている点は見落としがちだと感じた。
