Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テストの自動化とテスト駆動開発

yattom
March 29, 2021

 テストの自動化とテスト駆動開発

組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。

ねらい:
・主に顧客向けの業務システム(B2B)を開発している、
・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、
・マネージャーのかたに向け、
・テスト自動化が自分たちのメリットになると納得してもらい、
・その道筋として2つのアプローチを紹介して、
- テスト駆動開発
- ペアプログラミング
・組織的・長期的に取り組む価値を感じてもらう

アジェンダ:
1.自動化したい理由
2.必要な人材を考える
3.テスト自動化の端緒 ~テスト駆動開発について~
4.深めつつ広げる鍵 ~ペアプログラミングについて~
5.見る夢について

yattom

March 29, 2021
Tweet

More Decks by yattom

Other Decks in Programming

Transcript

  1. テストの自動化と テスト駆動開発 Test Driven Development for Automating Tests やっとむ こと

    安井力 合同会社やっとむ屋 アジャイルコーチ ©2021 やっとむ、合同会社やっとむ屋
  2. 2001年ごろアジャイルと出会い、開発者、チームリーダー、ト レーナー、導入支援と多様な立場で関わってきた。(株)永和シス テムマネジメントにて2010年頃からアジャイルコーチを主軸とし て活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ

    (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 著書・訳書 [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)
  3. アジャイルなソフトウェア開発とは アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

    価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 アジャイル宣言の背後にある原則 私たちは以下の原則に従う: • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客 様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるま で彼らを信頼します。 • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 • 動くソフトウェアこそが進捗の最も重要な尺度です。 • アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよ うにしなければなりません。 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 • シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちの やり方を最適に調整します。 アジャイルソフトウェア開発宣言(2001年) http://agilemanifesto.org/iso/ja/
  4. ソフトウェアの品質はいつ決まるのか?〜「Point of Sales」から「Point of Use」へソニックガーデン代表倉貫義人のブログ https://kuranuki.sonicgarden.jp/2011/09/post-46.html いいもの 作るぞ! できた! 終わったー!

    ここちょっと 使いにくいな 業務と 合わないなー 作り直す しか。。。 こんなアイデア どうかな? これは 便利! ここ変えたら もっと良くなる 手直し続けて 馴染んだな~
  5. 新規/再開発と開発規模による テスト工数割合の傾向 0% 5% 10% 15% 20% 25% 30% 35%

    < 10人月 10~50人月 50~100人月 100~500人 月 >500人月 < 10人月 10~50人月 50~100人月 100~500人 月 >500人月 テスト工数(%) ユーザー総合テスト工数(%) 新規開発 再開発 ソフトウェアメトリックス調査2020 システム開発・保守調査 一般社団法人 日本情報システム・ユーザー協会(JUAS) 図表6-3-2 投入工数別フェーズ別新規改修区分別工数(p.21) より
  6. 再開発はテスト負担が重い • 変更内容のテスト + 変えてない部分の再確認テスト • 再テストが発生 • 「1箇所でも変えたら全部テストやり直し」 •

    影響範囲の見極めは大変 • システムとソフトウェアの構成、設計はどんどん複雑化 • 見落としが起きやすい • 綿密に影響範囲を見極める → コスト増加 • 影響範囲を安全寄りに判断 → コスト増加
  7. アジャイルの場合 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

    価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 アジャイル宣言の背後にある原則 私たちは以下の原則に従う: • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客 様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるま で彼らを信頼します。 • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 • 動くソフトウェアこそが進捗の最も重要な尺度です。 • アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよ うにしなければなりません。 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 • シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちの やり方を最適に調整します。 アジャイルソフトウェア開発宣言(2001年) http://agilemanifesto.org/iso/ja/
  8. 解決策 = 回帰テストの自動化 • 「意図せず影響」する範囲をテストする • 範囲を限定しにくい • 範囲を特定するだけでも工数がかかる •

    「前回と同じ」テストを「すべて実行」すればよい • 自動化してあれば、流すだけ • 人間が「同じこと」を繰り返すのは非効率 • 結論: 短納期や変更頻度が高いなら回帰テストを自動化すべき 注意: 「回帰テスト」というテストはない。 前回と同じテストを再実行して差異がないか確認する。
  9. テストの種類: テストレベル • コンポーネントテスト • 独立したテスト対象のテスト • ユニット、モジュール、クラス、画面など • 統合テスト

    • コンポーネント間のインターフェースのテスト • OS、ハードウェアなどとの相互処理のテスト • システムテスト • システム全体のテスト • 受け入れテスト • ニーズを満たしているか、稼働できるかのテスト
  10. チェッキングとテスティング • チェッキング • 製品の特定の観測に対してアルゴリズムによる 機械的ルールを適用して評価するプロセス • テスティング • 製品を経験し、探索し、実験することで製品に

    ついて学ぶことを通じて、評価するプロセス。問 いを立てる、研究、モデル化、観測、推論などの 活動を含む “Testing and Checking Refined”より引用、和訳はやっとむ責 https://www.satisfice.com/blog/archives/856 http://testerchan.hatenadiary.com/entry/2020/03/09/080000
  11. テスト自動化エンジニア(SET) • Software Engineer in Test • テストの自動化は専門スキル • 言語やツールの多様性

    • アーキテクチャの多様性(Web、API、バッチ、クラウド、etc.) • テストの多様性(ユニット、結合、システム、運用、etc.) • 自動化の実行環境、インフラも自力で構築 • チームやプロジェクトに導入する エヴァンジェリスト役、コンサルタント役
  12. テスト自動化エンジニア(SET) • Software Engineer in Test • テストの自動化は専門スキル (以下は一例) エリア

    内容 例 言語やツール 開発言語、テスティングフレー ムワーク、自動化ツール、負荷 ツール、など Java, PHP, JUnit, pytest, jest, Selenium, Cypressなど アーキテクチャの多様性 Web、API、クラウド、バッチ、 GUI、OS、など REST, JSON, AWS, Azure, Lambda, Functions, .NET Core, Linuxなど テストの総合知識 テストフェーズ、テスト技法、テ スト戦略、など ユニットテスト、システムテスト、同値分割、ペアワ イズ法、探索テスト、レコード&プレイ 自動化の仕組み 環境構築、インフラ設計、実行 システム、など AWS、CircleCI、GitHub Actions、自動デプロイ、 テストデータ構築 コミュニケーション コンサルティング、エバンジェ リズム、メンタリング、など チームへの導入、相談役、自動化リーダー、先生 役、組織の推進
  13. テスト担当者 • テストの目的、効果、プロセスを熟知した専門家 • テスト担当者の仕事 • テスト対象を分析する • テスト計画を立てる •

    テストを設計する • テストを実施する • 開発者とコミュニケーションする • 状況を見える化する • プロセスを改善する
  14. なぜテスト担当者に能力が必要なのか そもそもテストとは… • すべてを網羅できない • 「全部テストせよ」は不可能 • 「バグがないこと」は証明できない • 有限のテスト工数で問題を効果的に見つける創造的作業

    • バグは遍在する • 問題を見つけるのに効果的な技法がある → 修得 • 人間がおかす間違いには傾向がある → 分析 • 1匹見たら30匹 → 想像力 • 包括的理解、緻密な分析、創造的探索
  15. https://www.servantworks.co.jp/resources/scrum_overview_figures/ 設計 仕様 ユーザー ヒアリング 実装 フィード バック 相談 画面

    デザイン データ ベース 1ヶ月以内の スプリント 修正 設計改善 デバッグ 改善 テスト 自動化 テスト
  16. スクラムで成長するメンバー • 1チーム(10人以内) • すべての行程、作業、管理業務をおこなう • 各自の能力を生かし かつ 協力し学び合って プロダクトを作る

    • マネージャーも、固定したリーダーもいない 役割分担もない • 全員にすべての作業のチャンス • 繰り返し練習して習熟 • 学びと成長の可能性を最大化
  17. 学習リソース (コミュニティ) • テストコミュニティは人材育成に積極的 • WACATE https://wacate.jp/ • 合宿形式でハンズオン •

    智美塾 http://aster.or.jp/business/satomijuku.html • テスト設計コンテスト http://aster.or.jp/business/contest.html • テスト設計コンテストU30チュートリアル https://youtu.be/DrgfzXzv7MU • YouTube ASTERソフトウェアテストチャンネル https://www.youtube.com/channel/UCKNO4SmQ7KRs4i2v_fLmCfA • ASTERセミナー標準テキスト http://aster.or.jp/business/seminar_text.html
  18. 学習リソース (書籍) • 「これからソフトウェアテストを学ぼうと 考えている人に読んでほしい10冊」 https://swquality.jp/?p=1180 • まずはソフトウェアテストの世界を覗こう • テストの基本的な考え方を体系的に抑えよう

    • テスト技法を身につけよう • テストツールの基本的な考え方を抑えておこう • ソフトウェア品質保証についての知識 池田暁さん http://www.jasst.jp/symposium/jasst19hokkaido/report.html#S1 https://twitter.com/nihonbuson/status/1373104318790864899
  19. 学習リソース (イベント) • JaSST日本ソフトウェアテストシンポジウム http://jasst.jp/ • 通年、全国各地でイベント開催(いまはオンラインで) • 日科技連 ソフトウェア品質研究会

    SQiP https://www.juse.or.jp/sqip/ • 毎年、ソフトウェア品質シンポジウム を開催 • DevOpsDays Tokyo https://www.devopsdaystokyo.org/ • 開発、インフラ、運用をトータルで考える、品質の話題も。毎年開催
  20. TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5.

    2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングを おこなう(Refactor) 7. 1〜6を繰り返す
  21. メリット • 自動化したテストが書ける • 低レベルのエラーが減り、品質が良くなる • コンパイルが通らない • 動かない •

    システムテストフェーズなのに単体レベルのバグが出る • 引き継ぎがし易くなる • 常にメンテナンス性高いコードベースを維持できる • リファクタリングの効果
  22. 注意: すべてのテストをTDDだけで書けない • 品質を担保する観点では、テストが不足する • テスト駆動開発=「開発」手法 • 品質を担保する作業は別に必要 • 開発者だけでは、テストを充足できない

    • テスト設計の観点が必要 • 開発者もテスト設計を学ぶ • テスト設計が上手い人とペアプロをする • TDDには向かないテストもある • 非機能テスト • 画面の見た目や使いやすさ • システムテスト
  23. テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数

    9 6 5-7 7 コード量(KLOC) 41.0 6.0 26.0 155.2 開発規模(人月) 119 24 46 20 欠陥数 (TDD未使用に対 する) 61% 38% 24% 9% 開発時間の増加 (管理者の見積) 15~20% 25~35% 15% 20~25% Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through test driven development: results and experiences of four industrial teams” 2008 http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
  24. スキルが必要では? • その通り • 時間をかけて修得する • テスト駆動開発は小規模に、個人レベルでも始められる • スキルを伸ばしながらできることを増やせる •

    スキルの高い人を生かす • メンバーの書いたコードのレビューと修正ばっかり。。。 • テストをレビューする • ペアプログラミングで一緒にやりながら指導する • テスト駆動開発は「開発」技法 • テスト設計も学ぶ • 必要に応じて学ぶ・学んだことをすぐ実践する
  25. TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical

    Studies" Simo Makinen and Jurgen Munch 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究の結論を整理した TDDは欠陥の作り込み(introduced defects)を減らし、 メンテナンスしやすいコードを産む TDDで実装されたコードは、部分的に、 サイズが小さく、複雑度が低い場合がある メンテナンスがしやすくなるものの、 初期開発では時間がかかる
  26. 体験の機会 • TDDBC テスト駆動開発ブートキャンプ http://devtesting.jp/tddbc/ https://tddbc.connpass.com/ • テスト駆動開発の講演と体験 • 全国(いまはオンライン)で開催、参加無料

    • TDDワイワイ会 https://tddyyx.connpass.com/ • テスト駆動開発の体験 • 小規模で気軽、参加無料、不定期開催 • TDD飲み会 (Test Driven Drinking) https://tddrinking.connpass.com/ • お酒などを飲みながら楽しくテスト駆動開発とモブプログラミング体験 • 2ヶ月に1回程度開催、いまはオンライン
  27. 巷間の感想 初TDDの感想 •レッド、グリーン、リファクタリングの黄金の回転は非常に心地がよく、着実に前にすすんでいることを実 感できました。 •ふと気づくと動作確認をしていないことに驚きました。 作成した関数の戻り値をprint文で出力したり、デバッガを立ち上げて変数の状況を確認してみたり。 •リファクタリングを行って大きくコードを変えても、テストコードが通っている=仕様を満たせている、と いう安心感がありました。 初ペアプロの感想 •コーディング中の選択ひとつひとつをペアの方と議論して進められるため、自然と質が上がると思いま

    す。 •トラブル対応などで一刻も早く対応せねばならず、冷や汗を書きながら震える手でコーディングせね ばならない状況においてもペアプロは有効ではないでしょうか。 •他人のコーディングをライブで見ることは気づきの宝庫です。 •メリットも多いけど、業務で毎日ペアプロやるのはしんどそう。週1でペアプロデーを設けるくらいがちょ うどいいかも。 TDDBC Tokyo 1.7 for PHP お題1実践記 https://www.karakaram.com/tddbc-tokyo-17/#feedback-tdd 「テストをしながら設計出来る」「テストコードがドキュメントになる」そんな 魔法のような売り文句のTDDが魔法でないことを教えてくれる、まさに魔 法のようなセミナーでした!! CodeZine Academy テスト駆動開発実践講座 参加者アンケートより 「TDDは分析技法であり、設計技法であり、実際には開発の すべてのアクティビティを構造化する技法なのだ。(本書より 引用)」ということが良くわかった。 オンライン記事などで聞き かじってきたテスト駆動開発は、テストファーストの説明がほ とんどであった。対して本書ではテストコードを書くことで設 計、実装を深めていく様子を再現し、その有効性を示してい る。良書を読むことができてよかった。 テスト駆動の大きなメリットは、 ・実装がシンプルになる。 ・ 過去に書いたコードの質か担保される→精神的に安定する、 自信が持てる。 ただ、あくまでプログラムを書く方法の1つで あって、全てのテストを書けるわけではないことに注意。 テ スト駆動の実践は個人でできるものなので、まずは一人で やってみたい。 因みに本書でも、「テスト駆動をチームメン バー強要すればするほど、広まらない。」と書かれているw (略)テスト駆動開発の真似事をしてみた感想として は、ーーーこの本にも書かれているがーーー着実な前進感 が得られて、心の平静が保たれるところが非常に強力なポ イントのように思う。 書籍『テスト駆動開発』への感想 (2021.3.26参照) https://bookmeter.com/books/12375096
  28. 機能追加や障害対応のプロセス 自動テストがない場合 自動テストがある場合 テスト駆動開発の場合 変更箇所と影響範囲を特定する 全体を把握していないと難しい 自動テストを新仕様に合わせて直す 障害の場合は再現テストを書く テストと仕様を把握していないと難しい コードを変更して完成する

    つぎはぎの対応になりやすい コードを変更して完成する テストして動作確認する 意図しない影響の確認には 限界がある 手動でテストして動作確認する 自動テストをすべて実行して、 意図しない影響が出ていたら、直す テストの自動化が不十分だと漏れが起きる 自動テストを新仕様に合わせて 直す リファクタリングして コード、設計、テストをきれいにする 自動テストをすべて実行して、 意図しない影響が出たら直す テストの自動化が不十分だと 漏れが起きる 手動でテストして動作確認する 自動テストを過信して省略しがち ユーザー受け入れテストをする 変更を依頼した箇所しかテストしない ユーザー受け入れテストをする ユーザー受け入れテストをする
  29. リファクタリングが大事 • メンテナンス性の高いコードを維持する • テスト駆動開発の本当のねらい • テストもリファクタリングの対象 • 「きれいを保つ」 •

    メンテナンス性が高いと • 変更の手間が少ない • 把握にかかる時間が短い • 想定しない副作用が起きにくい • 未発見の不具合があまりない • Point of Salesでは不要 → Point of Useでは大事 • できるようにならないといけない
  30. ソフトウェアは経年劣化する 時間 内部 品質 高品質 低品質 追加変更が容易で 意図しない問題も 起きにくい 楽な領域

    追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力 急ぎの対応 予期しない仕様変更 OSバージョンアップ 詳しい人が退職 新システムと連携
  31. リファクタリングでいいポジションをキープ 時間 高品質 低品質 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力

    相応の 手間・コストは 必要 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 重力に 打ち克つ 内部 品質
  32. 品質は最高が安上がり • 整った環境での仕事は速くて安全 • 安全に変更できる=最高速度を出せる • プロジェクトを炎上させるのは、テストではなくデバッグと再テスト • 変更しやすい状況を維持するためのリファクタリング •

    よりよいプロダクトに変更できるという顧客価値 • 「後で直す」より「いますぐ直す」ほうがだいたい 常に低コスト • リファクタリングを後回しにする=負債を背負い込む
  33. 本当は常にリファクタリング 時間 高品質 低品質 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力

    日々の仕事に 組み込む =テスト駆動開発 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 内部 品質
  34. 実装は設計 “These kinds of questions led Jack Reeves to suggest

    that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.” “The New Methodology” Martin Fowler https://www.martinfowler.com/articles/newMethodology.html “A program listing is a document that represents a software design. Compilers and linkers actually build software designs.” “What is Software Design?” Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
  35. 自動テストとドキュメント • 自動テスト自体をドキュメントとして機能させる • 実行結果からテストケース一覧や内容がわかるように • 仕様に対する網羅 • コードに対する網羅 •

    エビデンスとしての実行履歴 • 不具合対応も自動テストとして残す • 不具合を再現するテストを書いてから直す • レポートとして残す • (とっても)簡易な説明スライド https://docs.google.com/presentation/d/1MaeT4OVk74j7BO6DFzjsjhV9RSXhqrZ7n49jz8obsZg/edit?usp=sharing
  36. なぜテストを書きたいのか ― 個人の理由 • 不安がある=リスクがある • 工数が見通せない • 影響範囲を見切れない •

    最善の対応かどうかわからない • 命綱、安全ネットとしての自動テスト • 自分の身を守るために書く • 将来が今より安全になるよう書く • チームや組織を守るために書く
  37. フレームワークはテスト自動化前提 • .NET • xUnit.net, NUnitなど • Django (Python) •

    unittest, pytest • Spring Boot • JUnit 5, Spring Test, AssertJ, Hamcrest, Mockito など • Ruby on Rails • RSpec • React • Jest
  38. ペアプログラミングとは "Write all production programs with two people sitting at

    one machine. ... Pair programming is a dialog between two people simultaneously programming (and designing and testing) and to program better." (Extreme Programming Explained 2nd) 「プロダクションコードはすべて、2人で1台のマシンに向かって書くこと。 …ペアプログラミングとは、プログラミングしながら2人で会話するこ とだ(設計もテストも同時にする)。会話するのは、もっと上手にプログ ラムするためである。」
  39. ペアプログラミングとは • 2人が密に連携し、支援し合いながら仕事をする • 2人で1台のコンピュータ、1組のキーボード+マウスを使う • キーボードをにぎるのがドライバー、見ているのがナビゲーター • 設計、実装、テストをする •

    2つの脳、4つの眼球で共同作業 • 2人分の知恵を出し合い、2人分以上の成果を出す • お互いをカバーし合う • 知識、経験、ノウハウを交換する • 該当箇所を知っている人が最低2人できる
  40. 重要な仕事は2人組で臨む • 捜査する刑事 • 人命救助 • 学術研究 • ペアプログラミング →

    ペアワーク https://anagileway.com/2017/02/17/digital-innovation-leadership-with-jeff-nonaka-and-takeuchi/ https://hominis.media/category/actor/post3925/ https://sandanoumesan.com/archives/9803
  41. よくない例 次は登録処理をやろう わかりました(カタカタ) できました うん、よさそうだね この条件、だいじょうぶ? 考えてみたんけど、ダメです? このメソッド使うといいよ わかりました(カタカタ) できたね。じゃあ次は…

    黙って 手を動かしている 対話せず 報告している レビューアーの態度 共同作業ではない 頭の中を さらけ出していない アイデアではなく 指示 淡々とこなしている 達成感がない 考えずに 従っている 頻繁な 交代がない
  42. ペアプログラミングのプロセス • にぎやかにしゃべる • ドライバーとナビゲーターが対話しながら作業する • 黙ってはダメ、しゃべりながら手を動かす • ペアの役割を入れ替える •

    ドライバーとナビゲーターは頻繁に、数分~数十分で交代 • ペアを組み替える • 別のペアと組み替える • 他チームの人とペアを組む • プログラマとデザイナ • プログラマとQA • 仕様ホルダとプログラマ • 仕様ホルダとQA
  43. 例 • 毎週新しいペア • 週40時間みっちり • プロジェクトを越えることも • 1タスク1ペア、だいたい1日ごと •

    1タスクを担当するペアとなる • チーム内であれこれする • 毎時新しいペア • タスクに付く人と、あちこちする人 • 必要なスキルで呼ばれたり • いろいろ工夫する!
  44. 「チームの心理的安全とは、対人のリスクを取っても 安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams”

    Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「対人関係のリスクを取っても安全 だと信じられる職場環境であること。 それが心理的安全性だと、私は考 えている。」 https://www.amazon.co.jp/dp/4862762883
  45. 組織としてペアプロを取り入れる • 重要な仕事は2人組んで臨む • プログラミングに限らない(ペアワーク) • トラックナンバーを大きくしレジリエンスを高める • 知識、経験、スキルを組織内に環流させる トラックナンバー

    チームから何人欠けたら、仕事が継続できなくなるか? 「X人が交通事故に遭って仕事を急に休んだら」という意味 Xが大きい方が、情報共有ができていて、耐性がある 縁起が悪いので、ハネムーンナンバーと呼ぶこともある
  46. ペアプロと信頼関係 • 「同じ釜の飯を食った仲間」 • 同じキーボードを叩いた仲間 • 同じコードを書いた仲間 • 同じ障害に悩んだ仲間 •

    同じ解決に喜んだ仲間 • お互いを知るところから生まれる信頼 • 好き嫌いとは別 • 嫌いな人でも信頼できる • 相性問題は気を付ける
  47. ペアプロと生産性 • ペアプロの生産性が高いと示すデータは少ない • 低いというデータもない • やり方次第、ペアの組み方次第 • 目の前の生産性 vs.

    長期的な成長 • どっちも大事 • 目の前に捕らわれると未来がなくなる • ペアプロに向く作業、向かない作業 • 単純作業、定型業務、学びや発見のない作業には向かない • やってみてから判断するとよい
  48. ペアプログラミングの効果-ユタ大学の研究 “The Costs and Benefits of Pair Programming” Alistair Cockburn,

    Laurie Williams, 2000 https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming プログラミング 工数は増えるが、 15%しか増えない (2倍にはならない) ペアプロだと 品質が高い (不具合が少ない) ペアプロの ほうが楽しい ペアプロだと 同じ機能を 少ない行数で 実現する (洗練された 設計)
  49. ペアプログラミングの効果-ユタ大学の研究 • 作業中に間違いを見つけて直せるので、後工程に残らない(常時コー ドレビュー) • 不具合が減る(常時コードレビュー) • 設計がより良くなり、コード行数が減る(常時ブレインストーミングとペ アリレー※) ※常に相談し、意見交換し、一緒に考えることで問題解決が早くなる様子が観察された

    • 問題解決が早い(ペアリレー) • 学習効果が高い。対象システムについてもソフトウェア開発の技法に ついても(“教師の目が届く”効果) • 終了時、各自の理解している範囲が広くなる • 協力して働き会話も増えるため、情報の流れとチームのダイナミズ ムが生まれる • 仕事がもっと楽しくなる“The Costs and Benefits of Pair Programming” Alistair Cockburn, Laurie Williams, 2000 https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming
  50. 最初の一歩 • 誰がやる? • 情熱のある人 • 人を巻き込める人 • どこでやる? •

    リスクの小さなプロジェクト • 新規開発から(可能であれば) • どういうステップで上手になる? • テスト駆動開発を身につける • テスト自動化を身につける • 効果、メリット、ROIを確認して広げる
  51. 組織の取り組みとして位置づける • 個人の情熱だけでは燃え尽きる • 要員や工数への影響も • 権限者の後押しが必要 • 最初から組織全体でやると失敗する •

    自分たちの環境で上手くいくやり方を探索する • 最初は失敗するので、小規模に、安全に • 上手くいったら、少しずつ広げる • 100%にならなくてよい • 周囲が理解できるよう広報する • 広く伝えるための活動レポート • 顔を見て話せる成果発表会 • 仲間を増やす勉強会
  52. 効果があるところを見つける • ユーザーの環境がダイナミックに変わる領域 • 成長中のビジネス • ITの貢献度が高いビジネス • 業務や使い方に変化が多いシステム •

    人員の拡大、入れ替えがある現場 • 変化が少ない、安定性重視のところでは効果が小さい • 既存コードベースが大きいと効果が出るまでに時間がかかる
  53. プラスの効果をねらう • やる気が出る指標 • 顧客満足度に着目 • 「もっと何とかならないの?」と文句ばかりの人を驚かせる秘策として • 「あなたのおかげで自分の仕事によい影響が出た」と言われたい •

    効果が出るようにねらう • ユーザーの業務やビジネスを理解 • 仕様変更要望より踏み込んで提案 • 変わりそうな部分にテストで網を張る
  54. 書籍『レガシーコード改善ガイド』 • https://www.amazon.co.jp/dp/4798116831 • 目次から抜粋 • 第2章 フィードバックを得ながらの作業 • 第6章

    時間がないのに変更しなければなりません • 第7章 いつまで経っても変更作業が終わりません • 第9章 このクラスをテストハーネスに入れることができません • 第13章 変更する必要がありますが、 どんなテストを書けば良いのかわかりません • 第16章 変更できるほど十分に私はコードを理解していません • 第18章 自分のテストコードが邪魔になっています • 第21章 同じコードをいたるところで変更しています • 第24章 もうウンザリです、何も改善できません
  55. 基本戦略 • テスト自動化の経験者をアサインする • 初めてテストを書くような人が立ち向かうのは無理 • 熟練者、外部のコンサルなどがいるとベスト • エンドツーエンドテスト(システムテスト)を書いて全体をカバーする •

    動かなくなるような事態を検出できる • システム全体のテスト環境が稼働する • 自動テストでカバーすべき箇所を見つける • 過去の変更依頼や障害箇所を分析 • いつも変更するモジュール、苦労するモジュール • 適用できる自動テストのバリエーションを持っているとよい • 慎重に依存関係を除去する • シーム(接合部、縫い目)を見つける • 『レガシーコード改善ガイド』のパターンを用いる • テストを書き、リファクタリングする • 繰り返す
  56. ただし時間はかかる • 既存コードベースの規模に応じて • 年単位かかる場合もある • 自動化だけをやり続けるのは厳しい • 通常業務を回しながら •

    一定の割合で作業時間を確保する • 心が折れないように • 対投資効果のある箇所に限定する • 苦労に対して実入りがあるように • 実入りが薄いところは諦める
  57. 機能追加や障害対応のプロセス 自動テストがない場合 自動テストがある場合 テスト駆動開発の場合 変更箇所と影響範囲を特定する 全体を把握していないと難しい 自動テストを新仕様に合わせて直す 障害の場合は再現テストを書く テストと仕様を把握していないと難しい コードを変更して完成する

    つぎはぎの対応になりやすい コードを変更して完成する テストして動作確認する 意図しない影響の確認には 限界がある 手動でテストして動作確認する 自動テストをすべて実行して、 意図しない影響が出ていたら、直す テストの自動化が不十分だと漏れが起きる 自動テストを新仕様に合わせて 直す リファクタリングして コード、設計、テストをきれいにする 自動テストをすべて実行して、 意図しない影響が出たら直す テストの自動化が不十分だと 漏れが起きる 手動でテストして動作確認する 自動テストを過信して省略しがち ユーザー受け入れテストをする 変更を依頼した箇所しかテストしない ユーザー受け入れテストをする ユーザー受け入れテストをする もっとも安全で低コスト テストが十分あれば
  58. それでも改修は大変 • 直すべきテストが見つからない • テストが整理されていない • そもそもテストが足らない • テストで捉えられない影響が出る •

    テストをメンテナンスできていない • そもそもテストが足らない • テストを書けない • スキル不足 • そもそもテストが足らない • 関係するテストが多すぎて大変 • テストが整理されていない
  59. ただし時間はかかる • 運用保守に引き渡す前に時間をかける • テストを書く • テストを整理する • テスト環境を引き渡す •

    初期開発の責任が大きくなる • 安全に運用保守できる準備をする • 「完成する」から「変えられるように作る」へ • 運用保守の工数を担保する • 開発と保守運用が一緒に活動する