自動テスト文化を根付かせる王道と、邪道を教えよう。和田卓人氏による「組織に自動テストを根付かせる戦略」（その4）。ソフトウェア品質シンポジウム2022

9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。

講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。

本記事は、2時間におよぶこの講演をダイジェストとしてまとめたものです。以下の4本から構成されています。

• 答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
• 開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022
• フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
• [自動テスト文化を根付かせる王道と、邪道を教えよう。和田卓人氏による「組織に自動テストを根付かせる戦略」（その4）。ソフトウェア品質シンポジウム2022

いまお読みの記事は、その（4）です。

文化を根付かせる王道は新人教育

ここからは、文化を根付かせる、という話をしていきます。

文化を根付かせるというのは、一筋縄ではいきません。自動テストを書く文化がどのくらいで根付いたかなという話を仲間と話すと、「2年かかったかな」「いやいや5年ぐらいかかるよね」と言われましたし、もっとかかるところがあります。

文化を根付かせるには時間がかかる。これは事実として受け入れて、腹をくくってやっていく必要がある。当たり前ですけど一大事業です。

文化を根付かせるには、まず王道があります。

王道とは何か、王道とは教育です。王道としての教育にはいくつかパターンがあります。王道中の王道が新人教育です。

配属前の、あまり部署の現場の色がついていない状態の若者たちに、モダンなソフトウェアエンジニアリングの教育を施す。つまり、テストは当たり前のように書く、バージョン管理、テスト自動化、継続的インテグレーション、継続的デリバリー、プログレッシブデリバリーなど、モダンなエンジニアリング文化を体現した教育メニューを作り、新人全員に等しくその教育メニューを適用する。

そしてそういう教育を受けた新人エンジニアが年々、組織に増えていくことによって、どんどん組織の文化というのが強靱になっていくし、どんどんモダンになっていく。

これが王道中の王道です。これができるところはとにかくこれを実行する。

文化が根付くには年単位の時間がかかりますが、新人教育でこれを続けて3年か4年もたてば、組織の中でモダンなソフトウェア文化を持つ従業員の比率がだいぶ変わるんです。

それを実際にやったのはGoogleです。日本国内でもいろんな企業がやっていますが、早いうちに取り組んだのがドワンゴです。

ドワンゴは、ニコニコ動画を作った会社で、どちらかといえば伝説的な凄腕プログラマーが3日でニコニコ動画を作りました、みたいな、そういうイメージを持たれがちだと思います。

ですがドワンゴは2010年代の早いうちから新人研修をゼロベースで設計し、望ましいエンジニアリング教育を新人に施すことをずっと続けました。

その結果、今のドワンゴはものすごくモダンな開発をする企業になっていると聞きます。

例えるなら、南米の個人技中心のサッカーチームがいつのまにか、組織力中心のヨーロッパのチームになっていた。そんな感じで大きな変化を新人教育によって成し遂げました。

Cygamesも、新人だけではなく社員のかなりの割合の方に対して社内ワークショップを行いました。Cygamesも、もともとはあまりテストを書かない文化でした。ですが、テストを書かないプロダクトを長続きさせていくには非常にコストがかかることも分かっていたんですね。

では、テストコードのない既存のプロダクトに対して、どうやってテストコードがある状態にもっていくべきなのか、ワークショップを私もお手伝いしてやったわけです。

そのワークショップでは、研修用の架空のコードではなく、Cygamesの実際のゲームタイトルの本物のプロダクトコードに対して従業員がチームを組んでテストコードを書いていくという実施研修を行いました。

王道の最後は人事評価です。自動テストを書くことが人事評価につながらないと、お給料に繋がらないと、意識の高い人しか動きません。みんな動いてはくれません。

自動テストを書くとか、リファクタリングを行うということが、きちんと待遇に反映される評価されることが大事です。

ですけど、自動テストを書くとか、リファクタリングを行うことを、エンジニアじゃない人が評価できるかというと、それはできないです。

こういうことを評価できない事業責任者が評価すると、速くコードを書いてテストは書かず、セキュリティも甘いけれど、リリースは早い、こういう人の給料が上がる。

こうなるとみんなテストを書かずに早くリリースする。私がいろんな会社で、なぜテストを書く文化やリファクタリングする文化が根付かないのか調べると、リファクタリングしても給料は上がらないからだ、という身も蓋もない調査結果が出てきたりするんです。

ですから、テストを書くことを人事評価に組み込む。当たり前の話ではあります。この点ではCARTA HOLDINGS（旧VOYAGE GROUP）の人事評価制度「技術力評価会」が参考になると思います。

ビジネス面だけではなく能力面も、短期的な生産性だけではなく中長期的な保守性に対しても、エンジニアにきちんとした人事評価を与えるということ。それができる評価者および評価制度を作ることが大事になってきます。

文化を根付かせる邪道。他社事例で意思決定層を押す

王道があれば邪道もあります。文化を根付かせるためには、いろいろなやり方があるわけですよね。

例えばこんなジョーク集があります。日本人には「みんなやっていますよ」という言葉が効く、これが日本人を動かすと。

これを説得ロジックに合わせると、事例で押す、ということになります。意思決定層に対して他社事例を並べて危機感を持たせて説得する。

もう一つ、説明の向きを逆にする。これは河野大臣が行革相だったときに、ハンコ使用撤廃の話がありました。そのときに、「ハンコの使用は原則廃止、廃止できない場合は廃止できない理由を今月中に示せ」と説明の方向を変えたんですね。

説明責任の向きを反転させた。変える理由を説明するんじゃなくて、変えない理由を説明する、という方向にした。

テストを書かないから時間がなくなるのだ

すると、例えば「テストを書く時間はない」みたいな話が出てくる。

これに対してはもう皆さんもうご存知かもしれませんが、テストを書く時間がないんじゃなくて、テストを書かないから時間がなくなっていく、という話ですよね。

自動化というものは、時間を生み出すために行うものです。

私はテスト自動化のためのコンサルティング依頼をいただくことが多いのですが、実はテスト自動化より前に、別の自動化、例えばビルドの自動化とか、デプロイの自動化とか、そういったものを先に着手しましょうと提案することがよくあります。

なぜかというと、テストの自動化はエンジニア一人一人がテスト自動化を理解して、テストコードを書いて、それによってだんだんコストも時間もセーブされるのですが、そもそもテスト自動化への理解や学習の時間を作らなきゃいけない。

それよりも改善の入り口としては、レバレッジが効く自動化、誰かが頑張れば全体の時間を削減できる、例えばビルドの自動化とかチケット管理の自動化とか、何なら勤怠管理の自動化とか、そちらに投資します。

そうすることで全員の時間がセーブされ、その時間でテストの自動化を学んで、より効率的な開発に進んでいけば良い。自動テストを書くようになるとさらに余裕が生まれ、改善のための時間ができていく、という話になります。

動くコードに触れないでいると、動かなくなる

もう一つ。動くコードには触れるなという呪いの言葉もありますね。

ですが、動くコードに触れなければ安定して動き続けるかというと、もうそういう時代ではないんです。

動くコードに触れないでいると、動かなくなります。

なぜならいろんなものが変わっていくからです。クライアントもOSもカーネルもライブラリも言語も全部が変わっていきます。自分のコードを塩漬けにしていればそれだけ安定して動くかというと、周りが勝手に変わっていくので、動かなくなります。

だから「何もしてないのに壊れた」ではなくて「何もしてないと壊れる」んですよね。

だから常にコードに手を入れられるようにならないと、動かなくなっちゃうんですよ。

ツールから文化を変えることもできる

まだあります。自動化を行う文化とか、常に改善を行う文化とか、そういった文化的な基盤があるから自動テストを書ける、継続的デリバリーまで進めるんだ、というイメージを持たれる方が多いんじゃないかなと思います。

実は先ほどのDevOpsレポートで分かってきたことの中でもう一つ、すごく興味深いことがありました。

それは、文化が技術に影響を与えるだけじゃなくて、技術が文化に影響を与えるということです。

DevOpsレポートではこんな形で図式化されています。働く環境の文化、ここに入ってくる矢印がいくつかあります。

そこには「リーンプロダクト開発」「継続的デリバリ」「リーンマネジメント」など、いくつかあります。文化に入っていく矢印がある。ということが分かってきました。

これをデブサミで講演された島田さんの資料をお借りして説明していきます。

文化や風土およびパフォーマンスに影響を与えることが認められた要素というのがいくつかあります。真ん中にあるのが「文化・風土」。この文化・風土に入ってくる矢印にはいろんなものがあります。

「リーンマネージメント」「変革的リーダーシップ」から影響を受けた「リーン製品開発」と「継続的デリバリーとそれを支える技術的プラクティス」とか「文化的な能力」とか、そういったものが文化・風土に影響を与え、文化・風土がソフトウェアデリバリと運用のパフォーマンスに影響を与えて、ひいては組織全体のパフォーマンスに影響を与える。

こういう関係になっています。

だから、文化がパフォーマンスに影響を与えるだけじゃなくて、技術から文化に影響を与えるパスが存在するんですね。特に影響が大きいものが、「継続的デリバリーとそれを支える技術的プラクティス」です。

これは望みのある話だと思います。ツールやプラクティスから文化を変えることができる、ということに繋がってくるわけです。

では、文化への影響が大きい「継続的デリバリーとそれを支える技術的プラクティス」の中身はどんなものかっていうと、こういうものがあります。

これは個別の技術の話になるので、いろんな書籍などから内容をぜひ拾っていただければと思います。

テストコードの問題に正対する

最後になります。「自動テスト文化」とは何なのか、自分なりに最後にまとめたいと思います。

以下は「Googleのソフトウェアエンジニアリング」を引用しています。

自動テストのアンチパターンに「コスト削減を主目的にする」がありましたが、これは保守性（メンテナビリティ）に問題を抱えたテストコードの山に失望することが原因で、その失望からテストコードが残骸になっちゃうんですよね。

例えば、このスライドの上は理想で、下が現状です。現状は悪い意味の現実。

私が日本でテスト自動化の啓蒙などを始めた2000年代の序盤から中盤においては、「目の前には学習コストと自動テスト実装コストの山脈がありますが、その山脈を越えた先には約束の地が待ってるんです。そこでは、自動テストを書いていてよかった。不具合は未然に防ぐことができたし、常に一定のスピードで開発することができて、リファクタリングもできる。本当に良かった」という世界が待っていると、そう思われていました。

しかし今、現場を見回してみると「前々任者と前任者が書いたテストコードがどうも内容は重複していそうだし同時に失敗するんだけども、2人とももういないし、そのテストコードを消す度胸もないから歯を食いしばってメンテナンスしていくしかない」といったような、保守性や可読性、理解容易性や変更容易性などに問題を抱えたテストコードがたくさん現場を苦しめています。

私はこの問題を直視し、正対することが自動テスト文化であると思っています。

つまり、テストにメンテナンスコストがかかることの解決方法は、テストのメンテナンスコストを下げられるようなスキルを身につけることです。

オブジェクト指向設計実践ガイドの著者のサンディ・メッツさんは「テストにコストがかかることの解決方法は、テストをやめることではありません。上手くなることです」と言っています。

暴論にも聞こえますが、これは自動テスト文化とは何かをはっきりと体現した言葉であると、私は考えています。ぜひこのページもスクリーンショットを撮って、ツイートしていただければと思います。

まとめ：自動テスト文化とは

ということで、自動テスト文化とは、をリフレーズしてみると、テスト自動化に夢を見ないことです。

テスト自動化に夢を見ると、早めに夢から覚めて失望してしまうんですね。そうじゃなくてテスト自動化は現実です。

目の前にある現実で、やらないと話にならない。その上でテストコードは書いて終わりじゃなくて、書いてそのままだと残骸になっていきます。

テストコードはメンテナンス対象であり、メンテナンスには上手い下手がある。テストコードの書き方には上手い下手がある、ということを理解し、腹落ちすることです。

学習し、メンテナンスコストを下げる努力を怠らないこと、これが自動テスト文化であると私は考えています。

ここまでの話は、継続的デリバリーの5つの基本原則のうち少なくとも4つに該当してるんですね。品質の概念を最初から組み込むとか、反復はコンピュータに任せ、人間問題解決に当たる。徹底した改善努力を継続的に行う。全員が責任を担う。

それが望むゴールへと繋がっていく。正しい価値を早く提供し、無駄をなくし、高い質のソフトウェアを早いフィードバックをもとに回していく、ということに繋がると考えています。

ということで、私の講演はこれで終わりにしたいと思います。ご清聴ありがとうございました。

公開されたスライド：組織に自動テストを書く文化を根付かせる戦略（2022秋版） - Speaker Deck

関連記事

• 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
• 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020