BANKEYの開発の考え方 ~品質の積み上げ編~
こんにちは。BANKEYの高橋です。
BANKEYのプロダクト開発の考え方について書く連載の第二回です。
第一回では、そもそもソフトウェアの品質とはなにかということを切り口にBANKEYの開発工程について紹介しました。
BANKEYはFintechなので特にソフトウェアの品質が高いに越したことはないのですが、その高い品質はどのように作り上げればよいでしょうか。
第二回は、その高い品質をどのように作り上げていくかを考えます。
品質は「積み上げるもの」
一般的に「品質を積み上げる」という表現はあまり耳にしないかもしれません。しかし、私は品質を「積み上げるもの」として捉えています。
この「積み上げる」というのは、プロダクト開発における各工程で少しずつ品質を積み重ねることで初めてプロダクト全体として高い品質が生まれるということから来た考え方です。

第一回の記事でも示した通り、BANKEYの開発はV字モデルをベースにしています。それぞれの工程では、それぞれの実装スコープがあり、そのすべてが積み重なって一つのプロダクトを作ります。
品質も同様にそれぞれの実装スコープで証明すべき品質スコープがあり、工程単体では考慮できない品質の観点がたくさんあります。しかし、すべての工程で様々な観点を取り入れることにより、工程全体で見て考慮漏れのない状態とすることができます。それが積み上げた高い品質だと考えています。
各工程で積み上げる品質
上述したように、V字モデルの各工程で証明すべき品質スコープは異なっています。それらの具体的な例を紹介します。
1. 単体テスト
コードレベルでの動作を確認する工程
C1(分岐網羅)で、各コードが期待通りに動作するか確認する
2. 結合テスト
コードだけでなく、インフラや他サーバとの協調動作を確認する工程
自動APIテストとAPIコールを含めたフロントエンドの動作確認を通して、フロントやバック含めて認証スコープ制御やデータベース接続、非同期通信などが期待通りに動作するか確認する
3. 総合テスト
システム全体としての性能や信頼性、資源の効率性を確認する工程
ラッシュテストや脆弱性診断によって、リリース後に使用される実際の状況と同様の状況でも期待通りに動作するかを確認する
4. 受け入れテスト
実際のユーザーが問題なく利用できるか検証する工程
主にユーザーが満足して目的を達成できるかを確認する
ここで示す内容はウォーターフォールモデルなどでも言われているので知ってるという方も多かったのではないかと思います。
しかし改めて見てみるとすべての工程で確認する観点が全く異なることがわかると思います。だからこそ品質に妥協しないということは、どの工程も省略はできないのです。
そうして、これらすべての異なる観点を積み重ねることは全体で見て穴のない検証となるということであり、品質が高いと言えると思います。
Goのコードレベルで見る品質の積み上げ
ここまで開発工程としての品質の積み上げを見てきました。しかし、コードレベルでも品質の積み上げを考えることはできます。
それは、よくご存知のレイヤードアーキテクチャの考え方によるものです。クリーンアーキテクチャやMVCなど様々なソフトウェアアーキテクチャがありますが、それらは開発工程と同様に各レイヤーにおける責務を明確化し、その中での品質を十分に保証することによって、全体として高い品質が保証されるという考え方です。
BANKEYのGoのコードは、MVCSモデルを採用しています。以下では簡単にそれぞれのレイヤーが持つ役割を簡単に説明します。
View:入力データのバリデーションや、出力データの整形など、ユーザーとの接点としてのデータの扱いを明示する
Controller:ビジネスロジックとしての処理順や条件分岐を明示する
Service:ビジネスロジックを適切な大きさで意味のある処理のかたまりに分割し、理解しやすく修正しやすいロジックとして明示する
Model:DBとのやり取りを正しく行い、データの整合性が保たれることを保証する
各レイヤーではこれらの役割に応じて、それぞれのレイヤーに対して必要なテストを実行し品質を積み上げていくことで、Goアプリケーションの世界における高い品質を実現しています。
インフラレベルでの品質の積み上げ
品質を積み上げるのはコードレベルだけではありません。インフラストラクチャにおいても、各コンポーネントがそれぞれの役割を果たし、品質を担保しています。
ここでは、詳しく説明しませんが、API Gatewayや各種サーバ設定、ロードバランサのルーティング設定、ファイアーウォールの設定など、それらの正しさも検証すべきものであり、これらに穴がないことが非常に重要です。
HTTPパケットを理解すれば、インフラがもっと理解できる
すごく雑に言えば、インフラの各コンポーネントはパケットの中身を解釈し、その設定に応じた処理を行っています。
パケットは通信の最小単位であり、実は文字列の集合体です。パケットの中身をデコードすると、宛先や送信元のIPアドレス、MACアドレス、HTTPヘッダーやボディなど、通信の詳細を実際の文字列として見ることができます。

引用:https://atmarkit.itmedia.co.jp/fnetwork/rensai/tcp20/04.html
普段あまり意識することはなく、詳細にパケットの中身を覚える必要も全くありませんが、一度くらいはパケットの中身を見てみてほしいと思います。そうしてインフラ上を流れるデータの実態を理解することが、インフラレベルでの品質を積み上げることを意識するには非常に重要なことだと考えています。
HTTPパケットの理解には、OSI参照モデルを活用する
通信データの構造は、OSI参照モデルに基づいています。基本情報を学んだ人なら誰しも一度は聞いたことあると思いますが、実業務で触れることはあまりないのではないでしょうか。私は一度も聞いたことが無い気がします…。
しかし、このモデルをHTTPパケットの実像と合わせて理解することで、各レイヤーで何が行われているのかを把握しやすくなります。基本的な内容ではありますが、品質を考える上で重要な知識だと感じています。
まとめ
今回は品質は、「積み上げるもの」であり、工程管理だけでなくコードレベルからインフラレベルまで、あらゆるレイヤーにおける品質保証の積み重ねが、高品質なソフトウェアを生み出すことを紹介しました。
私自身、この考え方を常に念頭に置き、日々の開発に取り組んでいます。品質の観点にヌケモレがなくそれらをすべて検証できることが、最終的にユーザーの満足度や信頼性につながると信じています。
しかし、そのような品質保証をスピード感のある開発でやり続けるのは非常に困難です。それらを具体的にどう運用しているかというのはまた他の記事で紹介したいと思います。
BANKEYでは、エンタープライズに負けない安心安全なプロダクトをスタートアップのスピード感で開発することに日々挑戦しています!
金融の未来を一緒に作ってくれる仲間を募集しています。この記事を読んで少しでもBANKEYの開発に興味を持たれた方はぜひ ↓ から採用ページを見てみてください。
筆者プロフィール
高橋 宏圭(Takahashi Hiroyoshi) - BANKEY CTO
2012年4月に野村総合研究所に入社。2022年7月に同社を退職し、SalestechのスタートアップでVP of Engineeringとして開発組織を牽引。2024年1月にCTOとしてBANKEYに参画しプロダクト開発全般を統括。