テスト戦略を語る夕べ(第3回)の内容をまとめてみようとした #STS1031

告知ページ

connpass.com

テストの在り方を変える軸

  • テスト戦略を考える上で、テストの在り方を変える軸というのが様々存在しているっぽい
  • それらを勉強会の中で話した結果、5個ぐらいはありそう。
    • 実際にはもっとありそう
  • 勉強会の中で軸までを考えたのは以下の5つ
    • 垂れ流し
    • 警察
    • 大富豪
    • コーチ
    • まつお(仮)
  • これら以外にも、「がんじがらめ」「執事」といったワードも出てきてた
  • 今回話した内容についてまとめてみます。

ケース1「垂れ流し」

  • 軸…コストとクオリティ
  • クオリティを維持してコストを減らすために、安いコストの人へ依頼する傾向にある。
  • これを行うと、一見目的が達成されているように見えるが、長期的に見るとコストがあまり変わらずクオリティが下がる結果となる。

f:id:nihonbuson:20171101214029p:plain

ケース2「警察」

  • 軸…規律(自律か他律か)とムダの許容度
  • ルールを作り、クオリティゲートによって監視するやり方。
  • 監視が強くなればなるほど、他律の組織になり、物事のムダが多くなる。
    • レビューでくだらない指摘をする必要とかも出てくる。
  • 監視が強い(他律&ムダが多い)状態をPMOはする傾向にある。
  • 逆方向(自律&ムダが少ない)状態になれば幸せなように見えるが、人月商売で成り立っているSI系がこの傾向に移るのは稀。

f:id:nihonbuson:20171101214804p:plain

ケース3「大富豪」

  • 軸…技術的先進性と定着度
  • 金にモノを言わせて解決するやり方。
  • そのまま放置すると技術的先進性は勝手になくなっていく。
    • 常にアップデートが必要。
  • 上手くいくと、技術的先進性を一定以上キープしつつ定着度が上がっていく。
  • ただし、ツールの導入に関わっていた人などがいなくなり、上手く伝承されないと、ツールが陳腐化し、定着度も高まらなくなる。
  • もしくは陳腐化したツールを意図も分からず使い続けて埋もれる。

f:id:nihonbuson:20171101234638p:plain

ケース4「コーチ」

  • 軸…学ぶ機会と納得感
  • 共に汗をかくタイプ。ちょっと離れてサポートする執事型はこれの亜流。
  • 学ぶ機会が増えることで、徐々に納得感が出てくるはず。
  • 学ぶ機会が増える方法の一つに、リリース間隔を狭める考えがある。

f:id:nihonbuson:20171101235154p:plain

ケース5「まつお(仮)」

  • 軸…信頼感(距離感の逆数)とサーバントシップ
  • 最初は縦割りで信頼感も無い状態
  • 信頼がお互いにできるようになると、さらにお互いを支え合うような仕事の仕方になる。
  • そこから組織が変わる(人が増えたりする)と、信頼感が減りC&Cになりがちだが、その時の経過からまたサーバントシップに向かえるようになるのが理想。

f:id:nihonbuson:20171102000026p:plain

感想

  • 今回は5つのケースを話しましたが、他にもまだまだありそうな予感です。
  • 自分の会社・組織ではどのケースに当てはまるのかorまた別のケースに当てはまるのか考えてみるのも面白いかも

勉強会中にホワイトボードに書いたメモ

明日はJaSST Kyushu

JaSSTソフトウェアテストシンポジウム-JaSST'17 Kyushu

  • そういえば、明日はJaSST Kyushuです。
  • 基調講演では、中野さんがQAの組織としての取り組み事例を話して頂けるようなので、今回の勉強会とも照らし合わせてみるのも良いかもしれません。*1

*1:気になった方へ。当日券もあるみたいですよ!

Veriserve - WebQA FunNight!! #01 #WQFN01

告知ページ

veriserve.connpass.com

はじめに

  • このイベントでは、テスト管理クラウドサービス QualityForward のアジャイル開発において、どんな取り組みを行ってきたか、「守」「破」「離」の3点に分けて紹介していました。
  • なお、最初の話と、最後の話は諸事情により記録できていません。*1ご了承ください。

登壇者紹介

  • 開発:遠藤大介さん(ソニックガーデン)
  • テスト:大竹未紗さん(ベリサーブ)
  • PO:松木晋祐さん(ベリサーブ)

  • 以下の3点を行った。
    • 仕様を徹底的に議論する
    • 環境を最新に保つ
      • RailsのVersionをガンガン上げるとか
    • テストをちゃんと書く

仕様を徹底的に議論する

  • PO(松木さん)がまずやりたいことを持ってくる
    • ビジネス的に何を実現したいのかについて、松木さん流に話す
  • 中にはソフトウェア的に作るのが難しいことも
    • 開発者(遠藤さん)が「後々ガンになるよ」と伝えるようにしている
  • 要求に対して色んな実現方法がある
    • ソフトウェアにとって優しい、優しくない
    • ユーザーにとって優しい、優しくない
    • これらの調整がエンジニアの腕の見せどころ
  • 僕のオススメはこれ、と提案する
  • どちらかが折れるのではなく、対等に議論する
  • 週に2時間超のMTGをしているが、殆どがその議論

  • 松木

    • 変な仕様ってある?
  • 遠藤
    • いっぱいあるんですけど(笑)
    • テストスイートにタグを付けたい
      • →何のために付けるの?
      • →目的のテストスイートを見つけるためにタグを付けたい
      • →タグの管理が破綻するよ
      • タグのシステムは簡単なのですぐに作れるが、ユーザーは使いこなせないと思った。
  • 作るのもメンテも大変ではないやり方を選び続けて1年半経った

環境を最新に保つ

  • 技術は日進月歩
  • セキュリティ的に固くしようと考えると、フレームワークも最新にすることになる
  • 古いVersionだとセキュリティパッチも当てられない、使いたいライブラリが使えない
  • しょっちゅう、ライブラリを最新版に上げろと言ってる
  • 毎週リリースしているとリファクタするのを後回しにすると絶対にやらなくなる
    • →毎週リファクタをする
      • Redmine連携をした後に、JIRAなどにも対応できるようという要求があり、連携部分を抽象化した
  • ベリサーブ社内用のツールとして開発していたためシングルテナントで作っていたが、他の会社でも使いたいと言われた
    • →2週間でマルチテナント化した
  • 松木「ペースが落ちたことはない」

自動テストをちゃんと書く

  • カバレッジを100%を目指すのは辛い、C1を85〜90%でキープしてる
  • ライブラリのVersionを上げると挙動が変わるが、それを恐れてたらVerUpできない

    • 大事なのはすぐに気付けること
  • 今回開発したサービスだと権限毎のふるまいが違うので、その関係性を整理した上で自動テストを描いたりした。

  • 自分でできるところが守る、ただそれでも気付けないところはベリサーブさんに助けてもらってる

  • 松木「日付をまたぐテストの書き方についてなどは勉強になった。」

  • UIテストはどうやってる?

    • ブラウザで触った時の挙動については、Railsなのでcapybaraでやってる
  • ヘッドレスか実ブラウザでやるか?

    • 殆どがヘッドレス。たまに実ブラウザでテストする。
  • システムテストの成長系+αをプログラマに守ってもらってる

質問

Q 結構リッチなUIを使っていると思っているが、フロントエンド側は?
  • A フロントエンド側は書きづらい。例えば、スプレッドシートの自動化は流石にコストがかかるので、効率的な部分を優先にやっている。
Q リファクタリングの(時間的な)割合は?
  • A 空気を吸うようにやってる。ソニックガーデンの場合は、コードレビューを必ずやっているが、そこでも指摘があったりするので、リリース直前でもやってる
Q コーディングとテストコードの比率は?
  • A テストコードが1.5倍ぐらいある。テストコードの方が圧倒的に多い
Q マニュアルでテストすることはあるか?
  • A TDDに向いていないものもある。
    • 完成形が見えていないものとか。
    • そういうものは触りながらやる。
    • 逆に権限周りでガチガチに決まっている場合はテストコードを先に書く
Q テストコードとプロダクトコードは別リポジトリ
  • A 同じです。
Q CIってどこでで回ってる?master側?develop branch側?
  • A 手元では開発側で回してるし、masterでもstagingでも回してる
Q 環境を最新に保つとあったが、最新Versionの環境ではライブラリが使えないような場合はどうするのか?
  • A いくつかパターンが分かれる。
    • デグレって使えない
      • プルリクを投げて対応
    • 思想から外れるのでコードから外された。
      • 乗り換え先を検討する。(別ライブラリを探す)
Q 松木さんが「ペースが速い」と言っていたが、ペースの速い、遅いの判断はどうやって?
  • A 完全に松木さんの主観。
    • 今まで関わってきたプロジェクトと比較すると圧倒的に速い。
    • 速い場合、時間が経つと落ちてくるが、全然落ちない。
    • 最初からトップスピードで、その速度をキープしている感じ。
    • 逆にどんどん加速していくことも無い。
      • これ以上速くなるとPOが保たない
Q VerUpで不具合が見つかるタイミングは、自動テスト以外にあるか?
  • A ある。その時は、テストケースを足したりQAが観点として足したりする。
Q ドメイン知識が無い人がコードレビューをしていても回るか?
  • A いかに読みやすいコードを書くかを会社全体の流れとしている。
    • ビジネス的なものをコードレビューで見るのはそもそも難しい。
    • 「セキュリティ的に大丈夫かどうか」「読みやすいコードかどうか」を中心にレビューしている。
  • 権限周りのコードレビューだと松木さんに相談したり。
  • 松木「複雑な要求なのにコードが綺麗すぎるので、逆になんかあるのでは?と思ったりした。」

  • エンジニアが守っていた後に流す。テストエンジニアが破る。

バグランク

  • バグランクを予め決めている。
    • S セキュリティ、データ消失/破壊、システムの価値を致命的に損なう
    • A システムクラッシュ、復帰不能例外、システムの本質的な価値を毀損する
    • B 機能不具合、例外、ほか頻繁に利用されるケース
    • C 目立つ表示崩れ、軽微なユーザ期待との相違

テストサイズ

  • 変更内容によって、テストのサイズも決めている
Sテスト
  • 以下のような変更はSテストで対応
    • 軽微な変更
    • データの書き込みを伴わない変更
    • 表示される情報がユーザーにとってクリティカルでない変更
  • →製品知識が豊富なテスターのアドホックテストで対応
Mテスト
  • 以下のような変更はMテストで対応
    • 主要機能の追加や変更
    • データの書き込みを伴う機能
  • →テスト分析、設計、設計レビュー、実行、レポートのプロセスを通すようにして対応
Lテスト
  • 以下のような変更はLテストで対応
    • セキュリティ
    • データ毀損のリスクを伴う機能
    • ユーザーにとってクリティカルな情報を扱う機能の変更
  • →仕様、影響を網羅するためのモデルから作る

出来上がった最小の製品に対してリスクベースドでテストスイートを作る

  • 最初から1ヶ月ぐらい経ったときにまずは作った
  • 「ユーザーがどれ位ショックか」と「この機能はどれぐらい複雑か」の積でスコアを算出し、優先度を決めた

変更部分について影響範囲分析に基づくテスト設計と実行

  • 機能が加わったり、変更があったら、どれぐらい影響が表すかを図にしてまとめた
    • この機能を動かしたらどこに影響があるかについては矢印で表現した
      • 矢印の1本1本がテスト条件になっている
    • 例えば、ケースを作成した時に、「出力ができる」ものがあればエクスポートの機能に影響を与えるとか

Lテストの場合はPOと一緒に仕様のモデルを整理する

  • 「なぜこんな仕様になっているのか?」「どういう思想なのか?」を徹底的に共有
  • Lテストを実施する時は救援のQAも呼んで実施
  • ユーザー権限は非常にクリティカルなので、Lテストを実施した
    • 横の権限、縦の権限というモデルを一緒に作った
    • この仕様とモデルにおいては、画面、ユーザーメニュー、機能実行×権限の昇格&降格の組み合わせで網羅できることを発明した
  • 納得できる網羅を毎回発明している
  • このモデルを作ってテスト&修正を行った結果、その後、テストエンジニアのエースが1週間やってもバグを1件も見つけられなかった
Q Sテスト、Mテスト、Lテストの比率は?
  • A 5:3:2ぐらい

  • 製品に対しての問い合わせの対応は、QA側で行っている。
  • 開発側にはフィルタリングした情報のみ来る
  • 開発が集中にしてくれる環境になってる。
    • 遠藤「POからすると『作らないなー』と思ってそう。」
    • 松木「最初の3,4ヶ月は本当にそう感じた。今では慣れた」
      • 今回のサービス(テスト管理クラウドサービス)の提案を最初にソニックガーデンに伝えた時に「エクセルでいいじゃん」と言われた。
      • プログラマがガンガン言うことで内容が洗練されていく

おわりに

  • 最初にも書きましたが、これ以降は諸事情により記録が出来ていません。
  • ただし、ここに書いた内容以外にも様々な質問が飛び出して、大変面白い&タメになるイベントでした!

*1:最初は電車遅延で会場に間に合わなかったのと、最後はピザを食べながらだったのでPCを起動して記録していなかったためです

継続的E2Eテスト #Seleniumjp

スライド

www.slideshare.net

はじめに

  • 自動テストを継続的に行うのって難しいですよね?
  • 自動テストはキャズムを超えた
  • やり始めるのは簡単だが、継続していくというのは大変
  • 技術的な話というよりも、運用で気をつけてきた点を話す

継続のポイント

  • メンテナンスコストがかかる

メンテナンスコストがかかる

  • テストが動かなくなった
  • NGが多発する
    • テストの分析が走るはず
    • 分析そのものが時間がかかる
      • テストを諦めてしまう
    • SUT updateをする
      • これも時間がかかる
      • リリースサイクルが早いと、メンテナンスコストが追いつかない
    • テスト環境が変わる
      • これを意識しないと大変なことになる
      • 対応してSeleniumそのものバージョンを上げたりする
  • メンテナンスするものはたくさんある

メンテナンスを効率よくするために行っていること

  • 毎日動かす
    • リリースが毎月1回とかでも動かす
    • 動かしていないと大変
    • 変化に敏感になる
  • 不安定を排除する
    • 特にテスト環境
    • WindowsのOSを再起動する
      • 溜まっていくメモリを開放するため
  • 常に調査する
    • OSSのバグなどを敏感に知っておく
    • ナレッジ化して社内の人が知っておくようにする
  • 対応の速さ
    • テストが落ちた時に、次の実行までに解決するようにする
  • メンテナンスしやすい仕組みにする
    • OSSSeleniumでページファクトリーでメンテナンスしやすくするのもそう
    • Updateした時に動作確認をする場所が常にある

テストの価値が低下する と感じる要因

  • デグレが見つけられない
    • テスト設計・実装の見直しを積極的に行う
    • 実行頻度を開発プロセスと同期する
      • 開発者が意識していくと、「テストが○時に動くので、それまでにMRを通そう」となったりする
  • NGが多すぎる

    • 環境起因でのNG
    • メールの表題が毎回同じだと、鈍感になったりする
  • 自由にテスト実行ができない

    • テスト実行環境を複数用意する
    • 自分で直した時に確認できるようにする

テストが継続しない最大の要因 = 担当者がいなくなる

  • 「部署は残っているのですが、担当者がいなくなったので一から作り直しています」とかある
  • 自動テストは属人化する
  • 一つの案件に対して複数人をアサインするようにしている

Let's step into the OSS community #Seleniumjp

スライド

www.slideshare.net

クックパッドについて

  • 日本だけでなく世界でもサービスを提供している
  • Rubyを使っている

OSS活動について

  • 今はOSSに貢献している
  • 入社前は全然コミットしていなかった
    • 利用していただけ
  • 最近はどんどんOSSのコミットをしている
  • Appiumのコミットを盛んにしている

Appiumのコミュニティについて

  • 様々な人が存在している
  • コミッター
    • Rubyのコミッターの一人として松尾さんがいる
    • あくまでもコミュニティの一つのユーザー
  • 質問に回答している人もいる
    • Githubのissue
    • Appiumのdiscussionのサイト
    • Appiumに関するチャット
      • コミッター同士ではSlackで行っている

OSSの貢献について

  • 松尾さんの最初のPRはiOS8の不具合修正(2014 Oct 14)
  • タイポ、スペルミスなどのプルリクも貢献のカタチの一つ
    • 例えば、Elixerでは、コロンが抜けていたのでPRを送った経験もある
    • OSSをメンテしているのも人なので、間違いはある
  • 慣れていくと、もう少し大きな修正をしたりする
    • Google/earlGreyでは、大きな不具合修正をした
    • リリースノートに自分の名前が載った!
  • 質問に回答したりケアするのもOSSの貢献の一つ

  • OSSの貢献では英語が主体にはなる

    • このSeleniumコミュニティのように地域ごとにあるコミュニティもある
      • 英語が苦手なら、こういうコミュニティに入ってケアするのも貢献の一つ

E2E自動テストの長期運用に耐えるための5つの手法 #Seleniumjp

スライド

www.slideshare.net

モバゲーのプラットフォームについて

  • 数千万人の会員がいる
  • 3rdパーティーの開発のためのサービスを提供している

モバゲーのプラットフォームの経緯

  • ブラウザのゲームからスマホゲームに移行している
  • まだまだ沢山のユーザーがモバゲーのプラットフォーム上で遊んでいる
  • 課題として、高いアベイラビリティ後方互換性を少ないメンテナンスコストで行っている

規模感

  • 5年経過
  • 22個のテストスイートが分かれている
    • 機能毎に分かれている。
      • 会員登録とか
  • 700個のテストケース
    • 決済とかログインとかはしかkりテストしている
  • 60000個のAPIのテストケース
  • 開発者はサーバーサイドのリリースはQA無しでリリースできる

運用について

  • テストスイートがどういう経過を辿るか分かってきた
  • QAの一部として作り始める。
  • リグレッションテストとして回り続ける
  • 1年ぐらい経つとテストが壊れ始める
  • 自動テストが完全に壊れるテストスイートが出てくる
  • 出来る限りちゃんと動く期間を長くするようにする

どうすれば長期運用に耐えられるようになるのか

  • とにかくテストを流し続けましょう
  • 1日1回は最低限回すようにしている
    • 定期的に実行しているぐらい安定していないといけない
    • なかなか通らないテストは安定化しましょう
    • 開発環境が変わったなどをいち早く検知するため
      • 壊れた瞬間が一番直しやすい
  • どうしようも無いテストは諦める
  • 既存のリグレッションテストの100%グリーンを拘らない
  • 環境に依存するようなFlakyなテストとか
  • 直す工数が大きいが得られるメリットが小さいものとか

できるだけ早くテストをデバッグしたい

  • 出来る限りテストのデバッグが出来る人を増やす
    • 一番長く使われるテストは、開発のプログラミングテストと同じ言語にすることだった
  • テストのインフラはしっkり確保しよう
    • 1回回すのに1時間かかるものとかは無しで
    • 失敗したテストケースのみ流せるようにする
    • 失敗時のログを出す
  • Selenium Gridが活躍している

Debuggability

  • Zalenium
  • 実行のデバッグが見やすいようになっている

テストの実装とテスト対象システムの実装を疎結合にしたい(これからやりたいこと)

  • WebAPIはメンテしやすい
    • APIサーバーに依存しにくいから
  • Seleniumでテストを書こうとすると、テストコードの中で表現しないといけない
  • 取り組み
    • イトクローラを用いて、本番プロダクションのデータを持ってきて、それを正解データとする
      • 正解データはGithubに入れる
      • 別のブランチでプルリクする
        • GitHubが勝手に差分をしてくれる
    • 自然言語処理を使ってフォームを解析する
      • ICST2017で得たネタを使っている

re:反復開発

勉強会告知ページ

connpass.com

スライド

speakerdeck.com

自己紹介

  • @m_seki
  • XPプログラミングを16年ぐらいやっている

クックパッド

  • 2015年にイベントをやってた
  • 秋山さんが論文を書いてた
    • 開発チームの中にテストエンジニアを配し…テストの現場の理想型の一つと思う
    • 開発者もテストエンジニアも不具合を減らし、
    • このようなチームを@m_sekiさんが持っている

Agenda

  • 反復開発の基本
  • 上手くやることのヒント

本当はなにに困っていますか?

歴史

  • 2004年には会社の理解が無かった
  • 2008年
    • 川口さんが上手くやり始めた
  • 2016年のJaSST
    • 「Scrumは上手く行っているがプロジェクトは上手く行っていない」
    • →反復開発が上手く行っていないみたい

障害を想定したい

  • 今日の会場は「変わりたくない層」ではないと思うことにした

反復開発ができてないのでは?

  • まず、反復開発を説明するべきかもしれない
  • Scrumとか色々な名前の手順書が出てきたのに、それを使いこなせてない

プロジェクトが終わったとき

  • どんなことを感じますか?
    • こうすれば良かった…とか
  • もう一度やったらうまくいくような気がしませんか?

ウォーターモデル

  • 図だけ引用されることが多い。
  • 実は「戻りはnステップですよ」と書いてある
    • 工程は1ステップずつ進むけど戻りはnステップ
  • 同じ工程は何度も起こる
  • むしろ2度作りましょう
    • 1回やって分かったことを使って本番の開発をしましょう
      • 2度作ることで色々活かせることがある

期間を半分にしてみる

  • 期間と内容を半分にして、2回に分けて開発したら?
    • なんだかうまくいきそう!

工程別の不具合の調査結果

  • Royceの図はテストは1つ
  • この資料ではV時モデル風
  • 原因工程と発見工程の違い
    • 原因は上流工程が60%強
    • 下流工程で75%発見
      • 企画・仕様・設計の問題をその時に見つけるのは難しい
      • テストは問題を見つける能力が高い
  • 試して分かることは試す
  • 試さずに調べるのは高コスト
  • 中間成果物(ドキュメント)をあてにするのは危険
  • 試してみたほうが安いので、上流工程で頑張るのはコストがかかる

利用する

  • 工程と時期を分けて考えてみよう
  • システムテスト・運用テストをより早く
  • 結合された状態でのテストを早く、頻繁に行うために反復型の開発を行う

期間を半分にしてみる

  • 1/2、1/4、1/8としていって、どんどん小さくしてみる
  • V字を行うにあたって、どこまで短くできるか考えてみる
  • 時期ざっと並べて開発するのと同じ

やり方視点

  • V字モデルの全行程をやるのが1反復
  • 小さな動くシステムから始める
  • 強のシステムを次の反復で改造する
  • じわじわ開発するのとは違う
    • V字の下部分しかやってない
    • @t_wadaが言っていることを信じちゃうやつ
  • V字の一番底だけを繰り返すもの
  • うまくいってそうに見えるのがやっかい
  • 例えば、「ブランチで作業することで、結合時の問題を避けている」という状態になったり

システムを改造する単位

  • 確認ができ、数日で終わる仕様を作る
  • ストーリー毎に全行程を行う
    • 部品、フレームワークを先に揃えるのは✕
    • ストーリー単位に必要なものを用意するのが○
  • 住みながら増築していく感じ
  • アプリケーションとフレームワークが同時に進む

製品を反復毎に確かめる

  • 不具合を確認するだけではない
  • 製品を前にして様々なことを発見できる
    • 製品の意味とか
    • この製品はどういうものだったのかとか
  • 顧客の欲しいものは顧客もよくわからない
  • 実装の問題もよくわかってない
  • 最初から分かるはずがない

プロセス=チーム

  • 出来上がって製品によって、要求が変わったりチームが変わったりする
  • チームが変わったことでどんな効果があったかを製品を見ることによって分かる
  • 要求を変えたりチームを変えたりするには、製品を作る必要がある
  • 全部が成果!
    • 製品はもちろん成果だが、その作り方とか、その途中で分かってきた要求仕様とかも成果物になる
      • 2008年では膨大なテストスイートも成果物だった
      • 自動テストではなく、手動テストだった

製造業であれば…

  • おそらく自社製品
  • 3つの成果を活かしやすい
    • 良い仕様の開発は非常に難しい
      • 何が使いやすいのか
    • 製品寿命が長い
    • 開発期間が長い
      • チームが長生きする
  • 数ヶ月でAgileとかは難しいと思う

チームの変化

  • 反復毎に何かが変わる
  • メンバーのちょっとしたふるまいの変化とか
  • わざとらしい変化以外もあったりする

やろうとすると難しい

  • よく知られている話だけど実践するのが難しい
  • なので、m_sekiならではのヒント

反復開発ならではの問題

  • プロジェクトの初めから終わりまでに起こる問題が5日間の中で発生する
    • ごまかせない。目をそらす時間がない

壁?

  • 世界のエリートは大事にしないが、普通の人にはそこそこ役立つビジネス書

おすすめ→無理をしない

  • 無理そうなことは無理そう
  • 3つの例を示す
    • サブシステム間のペースの違い
    • 工程別のチーム
    • ストーリーの分割

ペースの違い

  • 大きなシステムでは全員同じペースではないかもしれない
  • ペースの違いから揉めがち
  • 実はペースを混ぜても大丈夫
    • 結合された状態で確認するという原則を守っていればね
  • まだ結合されてない部分はリスクとして持っておけば良い
    • あるチームだけ確認した内容は信じない
  • 反復が綺麗に揃うことはあまり重要でない
    • そんなところでは揉めない
  • 隣のチームのペースを無理に変えない
    • スムーズに行っている自分達が合わせる
  • となりのチームもサボっていないのでイライラしない
    • となりのチームは遅いのではなく、実はタイミングが合わないことへの不満が多い
    • 質問しても返事が来ないとか
      • 相手の都合を聞いてみよう
  • どこまでがチームなのか、チームの切れ目に意味があるのか?
  • となりのチームの人達も同じチーうの人達のように考えましょう
  • チームの境界を曖昧にするのが吉

工程別チーム

  • ロール別にチームを作ったり…
    • 開発者とテスターとか
  • なんとなく仲違い
  • 遠慮とか不信感が…
  • 担当する工程がうまくいっているかどうか製品で確認する
    • 自分達の工程だけ上手く行っている状況はあり得ない
  • 前後の工程のチームがうまくいくように気を使おう

開発に関わる活動

  • 以下の5つ全部!
    • 欲しいものを実現する
    • 仕様を具体的にする
    • 実装を考える
    • プログラムを書く・直す
    • テストする
  • 5日間の中に全ての工程がある
  • ソフトウェア開発の加圧動画そのままロールになった
  • こうなるのが自然
    • 5日間でやるとなると自分でやらざるを得ない
  • ほかのロールは?
  • やらないことが違う
    • テスターの場合、「プログラムを書く・直す」だけがない
  • テスターは劣化プログラマか?
    • テスターならではの価値がある
    • 開発者に比べ…
      • 領域が広い・深い
      • テスターの方がより長い時間製品を触れる
      • 製品全体を触れる
      • 手触りの一貫性をイメージしやすくなる

ストーリー

  • 要求の分割のテクニック
    • 練習しないと難しい
    • パターンは存在する
  • ルール
    • 結合したシステムで確かめられること
      • 部品だけのストーリーを作らない
    • 何かしらの価値が増えていること
  • 作戦
    • 起動、主処理、終了までの最も単純なフローを見つける
      • まずはこれを作る
      • 最初は起動と終了だけ作る
        • 設定ファイルは…とか面倒なものが多い
      • その後、徐々に増築し、単純なフローを完成させる
        • 起動の面倒なものが多いので、それが終われば主処理のコードに集中できる
        • なるべく早い時期に心配な処理が試せるように工夫する
        • 枝葉を気にせず幹(中心となるもの)を作る
    • 基本フローから徐々に枝葉を増やす
      • 幹無しで枝が生えないように、いきなりリンゴを作らない
  • 階層のあるチケットはオススメしない
    • 入れ子になりがち
    • なんとなくかっこいい!
      • しかし確かめられない…!
        • 進捗が分かっても確かめられない
    • 個人の進捗は確かめられるが、製品の出来は確かめられない
  • いつも結合テストを可能にする
    • 手に触って完成した様子が分かるようにする
    • 新しいものが載っていることを確かめたい
      • 個人の進捗はどうでも良い
      • 「進んでいる」と言う割には分からない
      • 「どうやって確かめるの?」と聞いてみると良い
        • 「実は確かめられないです」「ダメだね」となったりする
  • ボタン一つは価値があるの?
    • システムが壊れていないことは分かる
  • できるだけ早く喜ばれるものにしたくなる
  • 向かい合うことは大事!

質問

チケットの粒度について。チケット1つが価値を届けるものになっているのか?それともストーリー?

  • ユーザーが確かめられるものが一単位
  • チケットはストーリー、バグ、タスクの3種類。そのうち、ストーリー、バグは確かめられないことが書いてある。
    • タスクは確かめられないもの。ほとんど書いていない

イテレーションの最初は考えるものが多いと思うが、最初はユーザーに届ける価値が無いのでは?

  • ボタンを押して起動して、終了できること
  • 少なくともWindowが出てくること

受託開発をやる場合は、お客様が出した要件通りにやらないといけない。3ヶ月でとかだと難しいのでは?

  • 難しいと思う。
  • 3ヶ月経って作ったもの見せて「ああ、ダメだね」となったり。
  • 「早く気付くために期間を半分にしてみよう」と提案するとか

ストーリーと価値の話について。「ボタンを押して起動して動くものを提供する」というものは、ストーリーを繋げて話すと思うが、お客様としては繋がらないと意味ないじゃんと言われるのでは?

  • 「価値」というと難しくなるので、「変化が分かる」と言ったほうが良いかも
  • ユーザーのゴールは一番細い線ができること

今のやり方に組織が変わるきっかけはあったのか?

  • 全員がやっているわけではない
    • 最初にやっていたのは、V字のテスト部分のみをやっていた、それによって開発が変わったりする

じわじわ開発について。非機能の部分とかも反復の中でやっているのか?

  • 非機能の多くは分けていない。
  • パフォーマンスはもはや非機能ではない。パフォーマンスはほぼ毎日触る。
  • ただ、できないのもある気がする。
  • できないものは「できないなぁ」と思っているようにする。

エンタープライズアジャイル勉強会のきっかけは?反復開発できていないと気付いたのはどこで?

  • テストのイベントでテストエンジニアが開発と話をしていないことがわかった
    • 永田さんから「これが普通なんだよ」と言われた
  • プログラマの話は、プログラムの話はあってもプロダクトに興味を持たない

ストーリーを扱うのは1本だけか?

  • 最初は少なくしていたが、どんどん増える

徐々にテスト工程が増えてくるのでは?

  • やるべきテストスイートを集めてきて優先順位を付けるツールを作った

テスト工程を全なめするわけではない?

  • 全体をカバーしているが、全なめするわけではない

疎にしていると思うが、そのアルゴリズムはどういう風にしているか?

  • 最近触ったものは暫くしなくてよいとか
    • だいたい通っているものは下がっていく
    • rateを決めていて、rateが高いものは頻度を高くするとか

ストーリーの分割が難しい。「DBにアクセスしないといけない」とか、「インタフェースを切り替えたい」といったようなものは、どういうタイミングに行うべきか

  • 増築していくと辛いから整理したいときとかで。

その結果、何が良くなるのか?

  • 次の増築がやりやすくなる

リファクタリングしたい」という要望が出る場合は?ストーリーなどが書けないと思うが…。

  • それで何ができるの?
  • 言ってくる自体怪しいよね

増築するとぐしゃっとなるのでは?

  • 数日で終わる経験が多い。それだけ大ジャンプしてないのかも。
  • 限定的にするように話をすり替えているのかも

大企業だけど新規ビジネス開発をモブプログラミングでやってみた #xpjug

スライド

speakerdeck.com

カンファレンス

  • カンファレンスは発表者に直接聞けるのが売り

現地

  • 真ん中の写真は従業員ボード
    • 自分ができること、出来ないことを書いている
    • 付箋には、他者からのコメントが書いている
  • 右側の写真は技術について、TDDとかBDDとかカンバン、リファクタリングとか

Hunter社のモブプログラミング

  • 社内に6つぐらいモブが存在する
    • 川口さんが現地に行った時には8つぐらいになってた
  • 1つのモブに付き3〜5人
  • 隣のモブは全く別の技術領域
    • CDの話
    • UIの話
    • サーバーサイド
    • 製品の制御系
    • Android
  • 常にモブプログラミングをしている
    • この時間はモブプログラミング、というような働き方ではない

環境

  • 大きいモニタ2枚と、長机
  • 楽天では、ディスプレイ2枚とPC
  • エンジニアは1日中タイピングしていることが無くて、だいたい調べているはず

作業内容

  • 分担を決めてやると、他作業者の同期の時間がかかる
  • モブの場合、常に同期をしている状態
  • お客様のところへ行くと、人事の人がほしいと行っているものに、発注者と利用者が違うので、欲しいというものに違いがある
  • モブプログラミングでは作る量に限りがあるので。
  • 業務担当者から要望が出ない
    • 業務担当者はソフトウェア開発をしているわけではないので、時間がない
  • バグ=思いもよらない挙動なので、予想できない
  • コードの量に比例してバグの量が増える
    • 一番良いのは作らないこと
  • やり方を直すようにしている
  • 打ち合わせの後に、伝言ゲームを使ってクレームが来た
    • クレームがくるのは良い。伝言ゲームを辞めろ

10年ぐらい出てから気付いたこと

  • お客様は成果物の想像が出来ない
  • 引き継ぎは問題の強調解決しないとできない
    • 2週間や1ヶ月では、業務手順は引き継げるがスキルは引き継げない
    • 問題が出てきた時点で、どうやって解決するか話し合う必要がある
  • 人は忘れやすい生き物なので、備忘録は必要
    • 手順を書くだけでなく、どうしてその手順が必要なのか書く
  • 情報ラジエータとして壁に貼る
  • モブプログラミングはコード・情報・情報ラジエータ・ヒトが必要

取り組んでいること

  • 全員で客先に行く
  • 「来週は何がほしいですか?」と聞く

質問

  • 誰もいなくなっちゃう場合には怒らないのか?
  • モブプログラミングは評価と紐付いている。誰もいないところに参加するだけで、評価が上がる
  • リーダーはいるか?
  • それっぽいヒトはいたが、明確に決めているかどうかは分からない