参加した時にメモっていた内容になります。自分向けに投稿。
URL：https://offers.connpass.com/event/290685/
みーんなSREとかQAをチームにしとる チームにしていないのお前だけ - toriさん
開発チームがシステムを運用するオーナーシップ
→ SRE, QAを安易にチーム化しない
→ なぜ？
チーム化の理想は？
専門領域の深掘りを集中的にできる
→ 果ては他チーム・組織全体にまで波及させる
→ 希少な人的ソースを基盤化
但し問題がある
・責務分割からの責任の放棄（あっちのチームがいい感じにやってくれるでしょ
・権限問題（あっちの領分だし
→ 外部からの口出しがしにくくなる
→ （外部から見て）よくわからんがこうなってる
！！学びの機会の損失！！
組織の形によっては「こっちで良しなにやりました、あとはよろしく！」となるのが良いのか悪いのかという論争はある
カミナシでは開発チームではなくサービスチームという立て付けでやっている
→ サービスを提供して初めてユーザーに価値が届く
→ 開発を求めているのではなく、サービス提供を求めているというお気持ち
チーム化による必要なケイパビリティを備える機会を奪うことを避けたい
セキュリティチームはさすがに人いなさすぎてチーム化
→ サービスチームにenablingしていくこと、文化を作っていくことを目標としている
オーナーシップをどこに集結させるのか？というお話だった。
QA；CSとかはチーム化した方がいい？
サービスチームにどこまでオーナーシップを持つのか？による。ビジネス含めて丸っと全部持てたら最強だが、現実的にはそうなっていない。
パネルディスカッション
t-wadaさん -> W
toriさん -> T
テーマ：チームでQAを捉える場合、具体的にどう進めていく？
W；チームにどれくらいQAを理解している人がいるか？にもよる。別チームにQAがいる場合には、時間借りのような形で関わってもらう。
自分ごととしてどこまでチームが範囲を広げられるか？経験者がいない場合には読書会や外部経験者からの助言でまかなっていく。学ぶ姿勢が大事。
機能開発にリソースを全振りするのはダメ。時間があったらやりますは結局やらない。
T：QAうまくいってるかというとそうではない。トライしている最中。QAは外部ベンダーから派遣されていたが、手動テストを減らすなどでエンジニアリングの力で減らしていき、QAは上流工程からどうしていくのか？を助言する立場。
スクラムでやっていると全リソースを機能開発に注ぎがち。そうなると自然に得意分野のタスクしか取らなくなる。業務外で学べ、は違うよね。
チーム全体のスループットが下がっても業務内で学んでいく。
QA：チームを分けない場合での理想状態は、各サービスチームが自律的にやるのか、それともある程度ナレッジシェアリングなどを行いつつ進めたいと考えるとチーム横断のワーキンググループみたいな形でやるのが良いのか、どうお考えでしょうか？
W：横串の知見共有グループを作るのがよい。知識をサイロ化させない、ナレッジシェアリングの場を作ろう。横串チームではなく、横串コミュニティを作る。
T：カミナシは小さい会社なのでまだサイロ化は起こっていない。AWSは↑のコミュニティがあった。横串コミュニティがなぜやっているのか疑問化されないためのカルチャーづくりも大事。
QA：SRE/QAを内包することで、何かチームライフサイクルが変わることがある？
T：例として開発段階でそれぞれのレビュー目線で指摘することができる人が増えること。
テーマ：SREやQAがチームをあえて別チームにすることが効果的な場合はある？
T：評価が難しくなってきたとき。専門領域が多岐に渡ると評価者が判断しかねることがある。サービスチームにはいるが、評価者としては横串チームでやってもらう、みたいな感じも一つ。
QA：SRE/QA/セキュリティなどの専門知識をenablingしていくメンバをチームに配置するとチームの規模が大きくなり過ぎて困ることはないですか。もしくはenablingするメンバを1人配置するほどの規模ではない場合にはどうしていますか。
T：チームサイズの理想は１桁人。2pizzaチームと言いながら前職で30人いるとかはあった。前職ではチーム規模を保つために、オーナーシップを上手く切っていくことをやっていた。
W：逆コンウェイのようなことですよね。つらいところはどこでした？
T：AWSの規模だと急なトラフィック増があるが、スケールするようなチームの切り方をしていた。ボトルネックがチーム間で共有されるような場合には２チームが結局依存する形になったりしていて、そこの解決が難しかった。
QA：QAチームを分けることで一定の品質を担保できるメリットがあると思っています. 開発チーム内で品質を管理しようとすると, どうしても開発優先となり品質の優先度が低くなってしまいがちになってしまうと思いますが, それを防止する方法等がありますでしょうか?
W：品質を下げて開発スピードが上がるという考え方が間違い。品質を担保できていないのは開発が終わっていないと同義。手順を分けると「あとはお願いします脳」になっちゃうので、そうなっている。チームを分ける怖さはここにある。完了の定義を見直そう。
T：スタートアップなどだとスプリント回したあとに、次のスプリントは負債を回収するために動くといった動きもあるっちゃある。
テーマ：ソフトウェアエンジニア一人一人がQAにどう関わっていくことが求められているのか？
T：使いたいものを作ろう！という意識が大事なんじゃないか。降ってきた要件をこなすだけはやめよう。価値提供することをもっとエンジニアの意識の中心に置こう。
W：同意見。自分事として関わることが大事。あとはユーザーとの距離が遠すぎると意識が希薄になっていくので、近づけることも大事。アクセスログを体感するとか、ユーザーの意見を受け取るなど。
QA：品質保証への意識を高める、学ぶためにどのように学んでもらうのが良いでしょうか？ また、それは目標設計に含まれる場合、どういう目標設計にするのが良いのでしょうか。
T：仕事の中で学ぶのがオススメ。カミナシではジョブレベル・等級要件の定義に品質についての文言を含んでいたりする。
W：目標設計は事業貢献一辺倒・技術貢献一辺倒でもダメ。どちらの側面からも評価してあげるように設計するのが良い。
質疑応答
QA：QAってすごく多彩な領域があると思います（組織の品質ポリシー、チームのポリシー、チームが目指す（外部）品質モデル、テストのレベル、サイズの定義、テスト分析、設計、自動化、CI、メトリクス、内部品質の選択と担保etcetc... ）チームにQAをEnableしていく、ときにどこからはじめると進みやすい、入りやすい、など感触ありますでしょうか？
T：テスト設計を一緒にやっていくことで、こういった観点があるのか！など感動があった。そういったスキルを持った人による新しい観点の導入が感触としてはよかった。
W：仕事を減らす入り方が良い。過剰なテストを減らすようなところから入ってもらうといい。エンジニアはとにかくありったけのテストを詰め込むので、そこを調整してもらうのが最初にやってくれると刺さる。
T：専門知識を持っている人は最高の状態を目指そうとする、ただヨチヨチ歩きの状態からは圧が強すぎるのでここまでにここに行きたいというロードマップを引いてもらえるとよさそう。
QA：定期アップデートの話？（質問見つけれなかった）
T：定期アップデートは当たり前にやることとして、価値観に入れている。（とはいえカミナシのAuroraアップデートはまだやれてない・・・
締めの一言
T：カミナシは仮説を元に実験的に色々やっている。今日話したことが実際に成功したかは今後のカミナシを見ていってくれ！
W：良い会でした
