11/8 に渋谷ヒカリエの31F株式会社medibaで行われたソフトウェア品質勉強会「開発とテストが一体となったソフトウェア開発」 に参加してきました。

内容は、JaSST 2016 Hokkaido の基調講演の再演＋会場の参加者との多めの質疑応答でした。
主催者の方が、せっかくなので、講演だけでなく質疑応答を多めにできるようにした。という作戦がはまって、活発に質疑がかわされて良い会でした。

感じたこと

• 組織としてのお墨付き
• 適切というか大胆な権限委譲
• 適切な評価システム
  このあたりが整っているとチームは自律的になるんだなと感じました

セッションの内容はスライドが公開されているので、そちらを参照していただくのがいいと思います。

以下メモ

テストエンジニアのチームとの関わり方

• Agile Testingのスライドに書いてある部分を読めばわかる

  • テストエンジニアならよりよく分かる→著者がテストエンジニアだから

• テストエンジニアはプロジェクト初期から関わる

  • なぜか？

• Yahoo!も道半ばなので、完成形ではない。

• パターン1

  • プロジェクト初期からバリバリ関わっているわけではない

  • 自動化したほうが楽なものはプログラマが自動化

    • → テストエンジニアがプログラマに提案する感じ？
  • プログラマとテストエンジニアがみつにコミュニケーションを取っている

• パターン2

  • テストエンジニアは業務委託さんへお願いするところを決める＋質問とかのカウンター
  • パターン1より処理できるテストケース数はスケールする
    • 大きな案件に向く
  • プログラマと業務委託のプロキシがいるのでスムーズに行くことが多い

• パターン3

  • 典型的なパターン
  • 細かいテストはプログラマがやる

  • テストエンジニアはサービス全体を見据えたテスト設計＋実施（リリース前）

    • 自分の現場に一番近い形

  • 小さいリリース

    • 軽微な変更（誤植とか）

  • もともとWFだったところがやっているプロセス

    • WFでやっている案件だとこういうパターンになるかもね → あー、そうだね～。うちの現場。

  • Q:それぞれのチームの規模感は

    • A:1チーム10人いかないくらい
      • 大きくなったら分割して、多チーム構成にします
  • Q:Sprintのきかんとか、リリースの単位とかは
    • A:早いところだと2日くらい→緊急リリース的な
      • Agile開発しているところは1w,2wが多い
      • サーバーサイドはできたらすぐ出す
      • アプリは審査があるのでちょっとサイクルが長めになる傾向
  • Q:テストは一斉にしますか？　順次しますか？
    • A:プロダクトによる、アプリとかはまとまってやる
      • できれば切りたいので、細かくする方向に持っていきたい
  • Q: チームは解体とか結構しますか
    • A:人の入れ替えは半期、一年とか
      • チームのライフサイクルはプロダクトに依存する
    • Q: 解散してしまうとノウハウが消えてしまうんじゃないか
      • A: そこは社内でも問題、だがずっと一緒のチームにいると学びが落ちて行く人もいるので
  • Q: パターン3でのコミュニケーションのスキームは
    • A:変更点とかをビジネスの人と、テストを変更しなければいけないところ
      • 基本的にはテストエンジニアとプログラマが近くにいるので、適宜コミュニケーションをすればいいと思ってる
  • Q:テストの範囲→テストエンジニアはQAですか？
    • A:QAって？　→第三者検査をする人
      • みんな当事者なので、第三者的な感じではなくプロダクトを一緒に作っていく人
      • 外部部門というスタンスではなく、ちかしい感じ
  • Q:ドキュメントは
    • A:情報共有できる雑な最低限のものをConfluenceやExcelとかに残っている
      • 粒度はまちまち
  • Q: ドキュメントがない状態のばあい、ミドルウェアのバージョンアップのときとかにフルにリグレッションテストとかをしないといけないと思うけど、困りませんか
    • A:全く前回と同じテストしないといけない理由が無い
      • お客様が使えないといけないというところが担保できていればいいので（そこは担保されているということ？　自動化されているとか？　いつもやってるテストケースがあるとか？）

組織の話

• 部門が分かれていると、部門ごとに責任分界点が生まれる　→　ビジネスにフォーカスできないよね！

  • なので組織を変えていく
    • （ここに関しては今の現場はできている、ところもある）

• 参考書籍：JAICAのPDFがいい感じ、安い、生々しい

• なぜ、あじゃいる

  • なんかアジャイルだと解決できるらしいぜ！　→　やってみっぺ！　→　うまく行った！　→　テンション上がった！　→　普及した！

• 経営陣刷新　→　爆速

  • COOのトップメッセージとしてスモールチームでやりなさい
    • 作ったら出していいよへのシフト
      • QAへ責任転嫁できない　→　開発チームの責任感が大きく　→　テストしないとヤヴァイ！　→　チームへテストエンジニアが参画！

  • QA担当のパラダイムシフト

    • 受ける人から、自分で取りに行かないといけないように

  • Q: もともとQA担当の人ってどれくらいいました

    • A: 40人位、業務委託の人も使っていた
      • テスト範囲も広くない＆リードタイムが長かった
      • Q: テスト支援部門は
        • A: 15人位
        • Q: 15人ですべてのチームの手伝いを？
          • A: 各チームのテストエンジニアのサポートと、テストしたいビジネスの人にコンサル的なことをする
  • Q ：もともとテストエンジニアじゃなかった人はジョブチェンジしましたか？
    • A: テストオペレーター的な人は、テストエンジニアになったり、テストしつつデータ解析したり、ビジネス系にいったりとか
  • Q: のこった2個の承認プロセスってなんですか
    • A: ビジネスをやるかやらないか、セキュリティやコーポレート・ガバナンス的なところの2つくらい
  • Q:似たようなアプリができたりしませんか
    • A: ある。けどカンパニーを分けているのでサービス的にはかち合うことがすくない
  • Q:セキュリティ以外の非機能要件はチームに任されている？
    • A:任されている、そこも含めてビジネスをすることを任されている
  • Q:ゲートを外したらヤバイと思った、思った人はサービスの人ですか？
    • A:いい方　→　サービスをちゃんとしないといけないというモチベーション
      良くない方　→　仕事が増えたので、テストエンジニアの人を取り込んでやってもらおう
  • Q:ゲートが外れた途端に品質がさがりましたか（バンバンリリースできるので、なんでもいいからバンバン出そうぜ！　みたいになって、品質が後回しにならないですか？）
    • A:下がりました、今は戻ってきているとき
  • Q:品質についてショック療法的になっていますが、コレは狙いましたか？
    • A:狙っていません
      • そんなにインパクトがあったわけではなく、じわっとヤバイとなった感じ
  • Q: テストスキルを上げるための取り組み
    • A:もともとレベルが低いので、ほんに書いてあることをティーチングできればOK　＋　サービスに合わせて行ければやっていけた
  • Q:課金系は権限委譲していますか
    • A：権限委譲はしています
      • 法的な部分とかそういったところは組織でチェックしていく
      • 会社としてはサービス組織に以上している
  • Q: 品質あげようとするとコストとか時間がかかるが、そのあたりにビジネス層からの圧力や軋轢とかはありますか
    • A:現実的にはある
      • Q: どうやって解消していますか？
        • カイゼンも含めてサービスの向上なので、ビジネス、カイゼン含めて優先順位を決めていく
          • 短期的視点と中長期的な視点で考える
  • Q: アーキテクチャとか、プロセスとかを標準化したい人がいるものの、そこはチームごとに最適解を目指していきたいけどどうやってその辺標準化厨を抑えてますか？
    • A:まとめたいひとと、まとめないほうがいいと思う人が話し合い
      • ライセンスとか、全社的に考え無いといけないときはそこで話し合う
      • 部分最適の人は勝手にやる
      • コメント：標準化とすると最適にしないといけないけど、平準化として、ベースラインを決めると進めたほうがやりやすいって聞いたことがある
  • Q: コンテンツなどがカニバることってありますか？
    • A: コンテンツがカニバるときはある。
      • カニバらないようにするのは、チームの自助努力に任されている
      • メディア・コンテンツの上の方の人たちは見てる＋分野がわかれているので
  • Q:サービス毎の機能連携
    • A：基本的にはチーム間での話し合い
      • 戦略的にやるときは、コンダクトする人が出てくる（サービスの責任者級のひとたちで、カンパニー長は出てこない）
    • Q: システムIF　が変わってデグレしたりしませんか
      • A:します、けどスピード重視
      • Q:そのへんは原因分析して、再発防止とかしますか
        • A:事故の規模、深刻度による
  • Q:チームの知見とか、グッドプラクティスは支援部門として広めるのですか？
    • A:支援部門がキャッチデキるところについてはそうしてる
      • でも、全部が把握できないので、そういったものはノウハウを持っている人が他チームにいったタイミングで拡散する
  • Q:コンフルエンス検索ダメじゃないですか？
    • A:検索やさんなので、頑張って改善しています
      • Googleの検索エンジンをバックエンドに使っているものの、そのまま使っているわけではなく、カスタマイズしていてまだまだ検索やさんがいます
  • Q:もともとQA部門があったからテストエンジニアができたとおもうけど、テストエンジニアになろうとする人のモチベーションを上げるには
    • 理想的なチームにするためにはどうしたらいいですか
    • A:テストするスキルは必要だが、テストエンジニアが必ずしも必要とはかぎらない。みんなでやればいい
      • テストスキルがその人に依存しているという状態はよろしくない
    • Q:テストできる人と、できない人のスキルレベルが違う　→　そこは揃えたい
      • A:プログラマと一緒で、シニアなエンジニアがジュニアなエンジニアを教育するのが理想じゃないか
        • コーディング規約みたいにテスト規約とかもあってもいいかもね
  • Q:テストコードを書ける人と、テスト設計デキる人って違う人だと思うのですが、そこの住み分けは
    • A:得意分野の差であり、違う職責としてはいない
  • Q: スキルを上げていく必要があるということにたいして、チームではなくて、会社、カンパニーとかで取り組んでますか
    • A:オフィシャルにはない、勉強会とか、支援部門としてセミナーをやったりしている
      • だいたい本を読めばわかることがおおい、それ以上は個別にコンテキストに応じたアドバイスをしないといけないので、使い分けている
  • Q: テスト勉強してこなかったプログラマにおすすめの本は？
    • A: みんなが読んだ本で良いんじゃないか
  • Q: テストを含めてどれくらい自動化してますか？
    • A: サービスがおおいので、均一な自動化はしていない
      • テスティングのプラットフォームを整備している
        • 環境、CI、CDを用意する
        • 支援部門が教えに行く

感想

Yahoo!のいろいろな立場の方に過去話を聞いたことがあったが、
その人の立場とかやっていることによって話す内容や、話から受ける印象が違うのが楽しく、ためになるなぁと感じた。

山口さん、呼べばどこでも講演してくれるそうなので、話を聞きたかったら呼んでしまいましょう。