本記事は、リンクアンドモチベーション Advent Calendar 2025 の5日目になります。

野良的な活動

先日、Sentry エラーの一次調査用カスタムスラッシュコマンドを作ったという記事を書きました。

これ作ったのですが、プロンプトおよび仕組み改善中ということもあり、実態としては、まだ試しに使っているという段階だったりします。Sentry 対応チームは別で存在していますが、それとは別に（時間があればですが）調査して、レポートを貼ったりしています。
もちろんゆくゆくはチーム内外に共有し、チームとして使える道具の一つになれればと考えていますが、現状は、野良的にやっているという段階です。

そんなことをやっていると、2年ちょっと前に忍者式テストについて知ったときのことを思い出しました。この時も誰に頼まれたわけでもなく、なんとなくやった方がいいだろう、そしてやるのは楽しいんじゃなかろうか、という気持ち駆動で取り組んでいたのでした。

過去に当時の様子を社内ブログとして執筆したのですが、一部リライトした上で公開します。実際に忍者式テストに取り組んだ記事は、そこまで多くないと思うため、何かの参考になればいいなと思います。
ただし、先に断っていくと、この記事は、忍者式テストを取り組んだ、ではなく、忍者式テストを知って取り組んだこと、になります（つまり、忍者式テストに inspire された行動の話で、厳密には、忍者式テストをやったわけではない）。

今Qはじめ、同僚と話している中で、忍者式テストというものを教わり、陰でコソコソやっていました。どういうものなのか、どういう効果があったかについて、整理します。

どういうものか

初出は、2004年の JaSST と XP 祭りで、関将俊さんにより紹介されました。名前から変化球っぽく見なされますが、XP の有効なプラクティスの一つと理解しています。

自動にせよ手動にせよ、「テスト駆動」で開発することを重視すると、忍者式テストは、TDDの受け入れテスト版と捉えることができます。

「テストからはじめよ」〜忍者式テスト20年の実践から〜（発表スライド）

これを知って、よし、何か自分たちも似たようなことをしよう！と思い立ち、その週から、毎日ちょっとずつ手動テストをし始めました。これだけ聞くと、なんとも退屈そうと思われるかもしれませんが、やってみると、エンジニアリング / ユーザ / 品質の視点から、メリットがあると感じました。

日々の仕事をしていると、目の前の開発している機能については、多少詳しくなれど、それ以外のプロダクトの違和感は、感じにくくなりがちかなと思います。フラットに機能を触る時間を作ることで、そういった感覚を思い出しやすくなります。

どう進めたか

当時は、ウォーターフォールに近い形で数カ月開発を進めており、その開発工程中でした。まず初めに取り組んだことは、数週間後から始まる予定のシナリオテストを（勝手に）試験し始めるというものです。試験仕様書は、暫定版として存在していたので、その試験をしつつ、不足していると感じたテストケースを追加したり、わかりづらいテスト手順を修正していきました。

それが一区切りし、シナリオテストの工程が開始してからは、同時に同じことをするのもどうかと思ったので、別のストーリーをやり始めました。具体的には、新卒や中途でジョインした方がオンボーディングで使用するシナリオテストの仕様書があったので、その中で、別のストーリーを探して、勝手に消化し始めました。

毎朝、プロジェクトの朝会が30分あるのですが、30分以内に終わることも多いので、残った時間を、忍者式テストを進める時間としました。最初は1-2人から初め、途中からは3-4人で一緒に消化しつつ、疑問点があればそこで議論が始めることもありました。

小さな工夫として、週に3回、以下のリマインドを設定していました。

※ 「こちら」は、作業メモや改善メモなどのリンク

成果

朝会の余った時間（1〜15分）という短い時間ではありましたが、数週間試してみて、いくつかの成果と気づきがありました：

試験仕様書の改善
- テストデータのパターンの記載をわかりやすくした
- テストで使うユーザの情報を記載するなど、テスタビリティを向上させた
- テストファイルの管理がおざなりになっていたので直した
環境
- テスト工程に備えて環境を整備した
- オンボーディング用環境を整備した
UI/UX
- イケてないボタンの位置を見つけた
- イケてない自動処理を見つけた
- ここにこんなボタンあったんだという複数の気付きを得た

思ったこと

テストをする、ドメイン知識を深める、環境を整備する、といったことは、ともすればそれだけだと、退屈だと思われるかもしれませんが、忍者式テスト（とXP）という切り口から立ち向かうことで、その退屈さは、幾分か薄まったように感じました（なにより、勝手にやるというのがいい）。

余談

関将俊さんの書かれたプログラマが知るべき97のことのエッセイは、なかなか面白いです。

上記が当時、社内に公開した記事（に若干の加筆修正をしたもの）です。今思うと、このプラクティスは、プロダクトの動作の修練に繋がると思いました。AI によって加速されたプログラミングに対して、その他の工程がボトルネックになることを防ぎやすくするかもしれません。

最後に、上記リンクの中で、私が好きなスライドを載せて終わります：

参考