開発者の自分がテストを好きになったきっかけと、同じようにテストに興味を持ってもらうために頭を悩ませてる話
先日Scrum Fest Mikawa 2023に「テストを活用して効率よく認識を揃えよう -開発者がテストを学ぶメリット-」というプロポーザルを出しました。
採択されれば前後半の2パートに分けてそれぞれ
認識を効率よく揃える方法がテストを学ぶと手に入る
開発者がテストに興味を持つにはどうしたらいいのか
という話をしようと思っていますが、後半の開発者がテストに興味を持った例として僕自身のことも話す予定です。
JSTQB FL合格記でも軽く予告していましたが、この僕自身がテストに興味を持つに至った経緯、自己紹介的な話を先にブログで書こうと思います（本当はブログが先、プロポーザルが後のはずだったんですけどね、しょうがない）。
機械系時代の経験
元々大学入学から新卒入社まで全て機械系として過ごしてきました。
研究室は流体力学＆バイオミメティクスが専門で、イルカの研究をしたり、ゴリゴリFortranのプログラムを書いてシミュレーションで研究したり。
特に何も機械系としての人生に疑いを持つことなく新卒で製造業の会社（前職）に入ったわけですが、そこでは日本の古き良き製造業と言われるであろう働き方がありました。
タスクを小さく分解し見積もり、評価可能な状態に仕上げるまでの計画を立て、週次でチームで進捗を確認し計画を引き直したり、やることを共有するだけの短い朝会をしたり。
こんなことを付箋とボードを使ってやっていました。
ソフトウェア開発の現場じゃなくて、機械系の話です。
なぜなぜ分析もありました。
問題が発生した時には「なぜ」を繰り返し、上位概念へと抽象化します。
抽出した上位概念を、今度は逆に発生した問題とは異なる具体化し、他の問題を未然に防ぎます。
抽出された上位概念はナレッジデータベースで共有されており、とても優秀なチェックリストとして存在しているようでした。
当時はこの働き方が当たり前だと思ってましたが、そうでもないことに徐々に気づいていきます…
ソフトウェアエンジニアへの転向
色々あって、社内でソフトウェアエンジニアにジョブチェンジしました。
社内キャリアマッチ制度を活用した形で、3ヶ月間情報系新卒と同じ内容らしい研修を受けて次の職場へ。
幸運にも希望通りモバイルアプリ開発の部署に異動でき
新しい上司「AndroidとiOS、どっちをやりたい？」
僕「iOSをやりたいです、持ってるのもiPhoneなので」
新しい上司「わかった、じゃあAndroidをやってくれるかな」
という悲しいやり取りから、モバイルアプリエンジニアとしてのキャリアが始まりました。
元上司の名誉のために触れておくと、当時Androidチームの人数が減ったのでそこに入って欲しいという異動だったようで、多分最初Androidチームなのは決まってました。ただこの話を覚えていてその3年後にiOSチームに移る機会をくれたので、完全に無駄なやり取りというわけではなかったようです。
そんなこんなで、研修を受けたとはいえぶっつけ本番感満載の開発から始まっていったわけですが、まあ障害が多い。それに伴って残業も多い。
そもそもの仕事量が多すぎるのもあって、結構タフな残業度合いが毎年3ヶ月くらいは続く職場でした。
当時は開発はウォーターフォールで、組織としては開発部門と品質保証部門が完全にわかれているし、なんなら事業所さえ違うので物理的な距離さえ離れていました。
品質保証部門との関係は悪いということは決してなく、とはいえ離れているため、どうしても最低限のやり取りになっていたとも思います。
そんな環境で、評価期間中あれやこれやとたくさんの障害票が飛んでくると心の声は大体こんな感じ。
「うわー考慮漏れてた…これどう直そう…」（4割）
「なんでそんな操作するのおおおお！？」（3割）
「スレッド周りの挙動何がどうなってこの結果なのか全然わからん…」（1割）
「いや、それは仕様です（これ以上仕事増えるの勘弁して…）」（1割）
「何これよく見つけたね、ウケる」（1割）
品質保証部門との関係性は悪くなくても、仕事量が影響して対立に近い構造が出来上がることがありました。
特に「いや、それは仕様です」なんてやり取りはその象徴だったと思います。ユーザーの方を全然見ていなかったと自戒。
障害ふりかえり
最初の年はとにかく目の前の仕事をなんとかするのに必死でしたが、異動してから2年くらい経つと障害減らしたいなーなんてことを考え始めます（最終的にある程度カイゼンはできたのですが、どうやら品質保証部門に障害票の目標件数があるらしく、仕様書との小さな差異をひたすら指摘されるという悲しい展開が待っていたのはまた別のお話…）。
どんな障害が起きているのか、対策を打つにしてもまずは傾向を把握しようということで、記憶に残っていたなぜなぜ分析を直近1年分の障害票に対して実施しました。
結果的にわかったのは、大半の障害は割と些細なミスが原因だということ。仕様の認識違いや考慮漏れなどなど。
当時の開発の流れはざっくりと
チームリーダークラスの人が他部門と協力して要件決めてくる
各開発者に要件が割り振られる
各開発者が要件の完全に決まりきってない部分を詰める
設計・実装・コードレビュー
各開発者が手動用のテストケース（テスト手順）を作成
テストケースを使って開発内で実装確認後、品質保証部門に渡して評価開始
という感じです。
大半の障害が仕様の認識違いや考慮漏れが原因で発生しており、なおかつコードレビューで発見することもできていない。それなら最後の確認で使うテストケースを実装前に作成し、そのレビューをしてもらえばいいのでは？というのが当時出した結論でした。
アジャイルのアの字も、テストのテの字も知らないにしては、なかなかいい結論に辿り着いたんじゃないかと今でも思います。
機械系の頃工場実習で習った段取り八分って考え方も影響してたのかなと思います。
ただ当時はまだテストケースの上手な作り方、ハイレベルテストケースも記す作り方などを知らず、テストケースのレビューはあまりうまくいきませんでした。
とはいえ最初にどんなテストをするのか考えてから作り始めることの効果は実感できていました。
アジャイルとの出会い
そんなこんなで自己流のカイゼンを続けていると、アジャイル開発をしようという話がとあるチームメンバーから出てきました。
アジャイル開発といっても基本情報受けた時になんか出てきたなー程度の知識しかなかったので、事前に勉強しとくかーと人から借りた『アジャイルサムライ』を読むと…
第一印象は「機械系の頃の働き方ってこれじゃん！」でした。
チームメンバーがお互い何をしているかわかっていて、必要に応じて助け合いが自然発生する
締切に対して自分たちの仕事の進捗度合いがどの程度か、誰もが把握している
という「チーム」としての働き方を新卒の最初から経験していて、一方でモバイルアプリ開発の部署に異動してからはそうでもなく…
果たしてあの働き方はなんだったのかともやもやしていた状況に、名前のついた答えが飛び込んでくる衝撃的な経験でした。
（ちなみに社内では機械系の働き方にはちゃんと名前がついていて、やり方やポイントがドキュメントとしてまとまってることをその後知りました）
アジャイルと出会ってのめり込んでからはあれこれあったわけですが、テストに興味を持つに至る 一番の転機は（確か）t_wadaさんのTDDBC 基調講演/ライブコーディング動画です。
社内研修を受けるもやり方ばかりがフォーカスされていてあまり腹落ちしていなかったTDDを、意図や効果がスパッと明快に説明されていて一瞬でコロリといきました。
TDDの良さの1つに「一歩一歩着実に作り積み上げる」という面があると思います。
社内でソフトウェアエンジニアにジョブチェンジする時の研修で、CASLという基本情報試験で出てくるアセンブリ言語のアセンブラとシミュレーターを実装した時には、処理の流れを数行実装しては即実行して意図通りの結果かprintfデバッグしていました。
けれどモバイルアプリ開発の部署に行くとなかなか細かい動作確認ができず、そりゃ障害も出るよなあと感じていましたが、Unit Testを使えばそれが可能になるし、より具体的かつ効果的な手順がTDDなんだと、その効率面にとても惹かれました（そう、なんとも恥ずかしいことに自動テストはほぼ0の職場だったんです…）。
t_wadaさんの動画を見た後は、もっとTDDを学びたいと『テスト駆動開発』を写経しながら読み、なんともちょうどいいタイミングで開催されたTDDBC Sendai Xに参加し。
TDDからBDD、そしてアジャイルテスティングへ繋がり。
さらにTDDBC Sendai XにTAとして参加されていたブロッコリーさんに影響を受けて、WACATE 2021夏と冬に参加し。
恥ずかしながらこの辺でQAエンジニアという職種を知り、テストの世界の奥深さが徐々に見えてきていました。
同時にアジャイルテストを効率的にリスクを潰せそうだと、とても好きになりあれこれ実践もし始めました。
他の開発者をどう巻き込むか
僕自身はこんな感じで障害をなんとか減らせないか、些細なミスで残業が増えるのはきついという経験から、より効率的に、より着実にという視点でテストを好きになりました。
けれど同じ経験をすれば誰でも同じ結果になるなんてことはないわけで。
アジャイル開発をしようという流れでチームが文字通りチーム開発をするようになりましたが、なかなかテスト、ひいては品質に対する考え方の違いに最初はとても苦労しました。
どうやって他の開発者にもテストに興味を持ってもらえばいいのか、品質に対する考え方を揃えるにはどうしたらいいのか。
いまだに手を替え品を替え悩み続け、答えはありません。「ちゃんとやってくれ」というような、今思えば不毛な意見のぶつけ方をしていたこともあります。
そんな中で効果を感じられたのが、テストを活用した効果を体感してもらうことです。
具体的にはプロポーザルにも少し書いた
実例による仕様・受け入れテストを用いたPOとの認識合わせ
テスト技法を活用したドキュメント作成
テストプロセスに沿ったテストによりチームに生まれた自信
といったことでした。
特に前職での「実例による仕様・受け入れテストを用いたPOとの認識合わせ」は完全にチームに定着しました。
最初意図を共有しないまま、いわゆるQuestion AskerとしてのQAな振る舞いを始めていたので、下手をすれば重箱の隅を突っつき続けるめんどくさいやつと思われかねないとちょっと反省してるのですが、やっていると着実に効果が出ているのが周囲に伝わったようです。突っつかれていた側のPOは質問に対して「確かにそれ考えないと、大事だね」という反応になったり、他の開発者も真似をするようになったり。
最近はTDDが定着する鍵は何なのかがテーマです。
TDDの作法はわかるけれど、実際のコードベースにどう適応していったらいいのかと手が止まるようです。もしやある程度設計の知識がないと、TDDを始める際にテストを書いていくオブジェクトやそのインターフェースのイメージがわかなかったり、リファクタ時にどの方向に向かってリファクタするかが難しいのかな？という仮説を持っています。
なんてことを去年くらいから考えているタイミングで、先日Certified Scrum Developerの研修を受けました。研修ではTDDやリファクタリングは取り上げず、技術面ではデザインパターンの話が中心（TDDやリファクタリングはACSDで扱うそうです）。
もしやDavidも同じ意図があってこの研修のデザインなのでは？やはりまずは設計なのでは？説が自分の中で話題になっていたりするのですが、そんなCSD研修を受けたあれこれはまた次の機会に。
2023/09/08追記
CSD研修を受けた話はこちらのブログに記載しました。
この記事が気に入ったらサポートをしてみませんか？