BANKEYの開発の考え方 ~デグレは怖い編~
こんにちは。BANKEYの高橋です。
BANKEYのプロダクト開発の考え方について書く連載の第三回です。
前回の第二回では、「品質の積み上げ」と題してBANKEYのソフトウェア品質がどのように作り上げられているかについて紹介しました。
その紹介した方法をしていても品質がガクッと悪くなるときというのがあります。その主な原因が「デグレ」です。品質を着実に積み上げていくには、以下にこのデグレを予防または早期発見するかが非常に重要です。
第三回では、品質の積み上げに欠かせないデグレの原因と対策について考えていきます。
デグレとは、意図せず品質が劣化すること
そもそもデグレとはなんでしょうか。
SHIFTさんのコラムには以下の様に紹介されていました。
デグレとは、機能の追加や変更のために稼働中のシステムを修正した際に、それまで動作したものが動かなくなってしまうことによって発生するトラブルのことです。英語の「degrade」（低下する、下がる）の略語であり、日本のIT業界では「デグレ」という呼び方でなじみがあります。
英語圏ではデグレードという言葉はRAIDの不整合を表す時に用いられることが多く、私たちが日ごろ日本で使っている「デグレ」、すなわち「変更により引き起こされた、コンポーネントやシステムの品質の悪化」を表す言葉としては「リグレッション（regression）」という言葉を用います。
つまり、良かれと思って修正したのに動かなくなることがある、という現象をデグレと呼んでいます。デグレ怖い。
デグレ発生は防げないから、検知したい
そもそもなぜデグレが起きるのかというのはSHIFTさんのコラムでも言及されていましたが、様々な要因があります。
それらを見るに、私は究極的には「デグレ発生は仕方ないな」と思っています。実装者は人間なのでミスはもちろんしますし、仕様書の理解が毎回誰もが完全なんてことも現実的には不可能です。
だったら、「デグレは起きる」と割り切ったうえで、「デグレを開発段階で検知する」と考えるほうが現実的です。
そこで、デグレを検知するために考えることは「影響調査を十分すること」なのではないかと考えています。
影響調査とは、その修正によって起こり得る変化を調査することを指しています。そのやり方には同件調査と類似調査の２つがあると思っています。
同件調査
修正内容と同一のコードや変数名で検索して同様の修正が必要と思われる箇所を洗い出す調査
その人の経験によらず、機械的に実行可能
類似調査
修正内容から推察される類似のロジックや変数が存在する箇所を発見し、同様の修正が必要と思われる箇所を洗い出す調査
経験に依存する面はあるが、手法を知れば十分実行可能
これらの調査を十分行うことによって、修正箇所の影響を確認しリリースの前に影響のあった箇所を修正してデグレを防ぐ事ができると思います。
ただ、類似調査には上記に書いた通り経験に依存する面があります。しかし以下のようにいくつかの観点はあるので、それらを駆使すれば経験のない型でもある程度は洗い出すことができます。
同一の要件
→ 同じビジネスロジックを使う箇所ってほかにもあるよね？類似のロジックやアーキテクチャ
→ そもそも同じようなロジックの組み方を別のところでやってない？類似の変数名
→ 同じロジックでは同じ変数名が使われるよね？同一の実装者
→ 実装者の思考の癖やコードの書き方の癖が起因してそうなら？実装時期
→ その仕様が作成され、実装された時期が近ければ？
でも、これを修正するたびに毎回やるのは正直大変です。だからこそもっと別の方法でデグレの発生を検知したい。
そこで、リグレッションテストの出番です。
リグレッションテストでデグレを機械的にチェック
またSHIFTさんの記事を引用しますと、以下のように紹介されています。
リグレッションテストは新機能のリリースや、不具合の改修をするときに実施するテストであり、「回帰テスト」や「退行テスト」と同義語に捉えられることもあります。
また記事を読み進めるとデグレードテストとの違いも紹介されています。しかし、この記事で言うデグレは「修正によって別の箇所の機能が正常動作しなくなる」ことであり、性能低下に限定していません。
つまり、ここでいうデグレを発見するためのテストとは、リグレッションテストであると定義しています。
このリグレッションテストをデグレに対して使うときに重要なポイントは、「入力に対する出力が変わらない」ことをチェックすることにあります。
逆に言えば、意図しない既存機能への影響がない（=デグレしてない）というのは「入力に対する出力が変わらない」という意味だからです。
そのため、単体テストやAPIテストで入出力のペアを定義し、それらを自動実行して合否を見ることでデグレを検知できると考えます。（もちろんログの出方などの内部的な挙動まで見るのが厳密ですがここではスコープに入れません）
Tavernで自動APIテストを導入推進！
ここからはリグレッションテストの具体的な実装方法を簡単に紹介します。
BANKEYでは、結合テストレベルで自動テストをするのが最もコスト効率の高いリグレッションテストと考え、自動APIテストを導入推進しています。
自動APIテストとは、APIのリクエストとレスポンスのペアをテストケースとして作成し、ソースがマージされるたびにそのケースのとおりに自動でAPIをコールしてテストする工程を指します。
そのために使用しているツールは、Tavernです。
Tavern自体はPytestベースで作られていますが、テストケースはすべてyamlで書くことができますので、簡単にケース作成できるなど良い面が多いです。具体的にはTavernを採用しているのは以下のポイントからです。
yamlでケースを作成できる = リポジトリでケース管理できる
CLIで実行できる = CIで使える
あるAPIのレスポンスを次のAPIリクエストに使える = 複数のAPIを実行するケースを実装できる
Pythonコードでテストに必要な処理を追加できる
これらによって、APIテストを充実させて日々のデグレチェックに役立てています。まだ開発し始めて１年経過していませんが、テストケース数は600件を超えてきています。まだまだ増やして漏れのないチェック体制を作っていきたいと思います。
まとめ
今回はデグレという修正影響で品質低下や障害が発生する現象について、その対処法も含めてご紹介しました。
良かれと思って修正したのに、プロダクトを壊す結果になるなんてエンジニアとしても非常に悲しいことです。これを機械的に気づいて障害を未然に防ぎ、エンジニアもユーザも安心できるプロダクトにしたいところです。
そしてエンジニアが安心して開発を進めるには、このように開発の初期からデグレを意識してテストケースを整備することが必要であり、これによってスタートアップのスピードを維持しながら品質を確実に積み上げていくことができるのだと信じています。
BANKEYでは、エンタープライズに負けない安心安全なプロダクトをスタートアップのスピード感で開発することに日々挑戦しています！
金融の未来を一緒に作ってくれる仲間を募集しています。この記事を読んで少しでもBANKEYの開発に興味を持たれた方はぜひ ↓ から採用ページを見てみてください。
筆者プロフィール
高橋 宏圭（Takahashi Hiroyoshi） - BANKEY CTO
2012年4月に野村総合研究所に入社。2022年7月に同社を退職し、SalestechのスタートアップでVP of Engineeringとして開発組織を牽引。2024年1月にCTOとしてBANKEYに参画しプロダクト開発全般を統括。