2023.03.27
本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。
湯本氏のnote「テストマネジメント虎の巻」はこちら
第1回：いまどきのソフトウェア開発に求められるもの 第2回：新しい開発スタイルの概要 第3回：新しい開発スタイルに合わせたテストの概要 第4回：開発チームとテストチームの関係～成功のための大事な役割～ 第5回：品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い 第6回：テストレベル間のテスト量の関係は？テストピラミッドとの関係も 第7回：QA（Quality Assurance）の定義と考え方とは？ 前回は、ビジネスの成功に貢献するソフトウェアを作るためには、トライアルアンドエラーを行うことと、チームの垣根を超えて開発を行うことの２つが大事であることを説明しました。
本連載は、ソフトウェアテストを取り扱うものですが、ソフトウェアテストはソフトウェア開発の一部であるため、まずは、ビジネスに貢献するソフトウェアをどのように開発していくかを知る必要があります。
昨今、上記したトライアルアンドエラーとチームの垣根を超えた開発の２つを実現するため、さまざまな開発手法やツール、仕組みを取り入れた新しい開発スタイルが提唱され、実用化されています。ソフトウェアテストの話に入る前に、今回は、それらの開発スタイルがどのようにビジネスに貢献するのかと、その開発スタイルを採用する際の注意点を説明していきます。
- もくじ
1．今回取り上げる代表的な開発スタイル
昨今、さまざまな開発手法やツール、仕組みが提唱され、実践されています。
今回は、本連載の主旨である「ビジネスに貢献するソフトウェア開発のために大事な２つのこと」の実現に貢献していると考えられる、以下の４つを代表的な開発スタイルとして取り上げて説明したいと思います。
- オープンソースを活用した開発
- アジャイル開発
- クラウドを活用した開発
- マイクロサービスアーキテクチャーを活用した開発
オープンソースを活用した開発
オープンソースという用語は、フリーソフトウェアに代わる用語として、1998年に提唱されました。
当初、オープンソースソフトウェアは、ビジネスで十分に利用できると言えるものは少なかったのですが、現在では、開発言語、OS、アプリケーションサーバー、データベースなどにオープンソースソフトウェアを使い、ソフトウェア開発をすることが一般的になってきています。
この開発スタイルの特徴
オープンソースのメリットは、ソフトウェアベンダーに依存せず、開発者が自分たちでコントロール可能な状態になることです。
ソフトウェアベンダーが提供するブラックボックスなソフトウェアを開発の中心においてしまうと、全てがベンダー依存になってしまい、開発者は、ベンダーへお金を払って技術を習得したり、ベンダーのソフトウェアを改善したいとしてもベンダーの都合に合わせたりする必要があります。このようなことに時間やコストがかかってしまうと、ビジネス要求をスピーディにサービスとして提供する際の障壁になってしまいます。
また、オープンソースから必要となるプラットフォームやライブラリなどを入手して、全てを自分たちで開発しなくても済むようになると、開発のスピードを上げることができます。
また、これは後述するクラウドの活用になりますが、自身が開発したソフトウェアとSaaS（ソフトウェア・アズ・ア・サービス） に代表される他のクラウドサービスの活用／連結によって、ビジネス要求をスピーディに満たしたサービスを提供していくことができます。
この開発スタイルを利用する際のポイント
オープンソースを活用するためには、開発者に技術的投資の裁量を移管することが重要になります。開発者自身で状況に適したオープンソースソフトウェアを発見し、使ってみたうえで、適用可能かを判断します。開発者がそのオープンソースソフトウェアをとても良いと思えば、その評価をオープンソースコミュニティにフィードバックします。また、開発者自身が自分たちの作業効率を良くするために作ったライブラリやツールをオープンソースコミュニティで公開するといったこともあるでしょう。
これらの一連の相互作用が現在のオープンソースの発展に寄与しています。これまでは、ソフトウェアベンダーから購入する際の決定権が予算権限を持った上位管理職や経営陣にあり、選定のための承認を得るといった活動が必要でしたが、開発者自身が選定することで、開発に本当に有用であるものを活用できるまでのスピードが上がります。
アジャイル開発
アジャイル開発は、2001年の「アジャイルソフトウェア開発宣言」が提唱されたことで有名になりましたが、その考え方はXP（エクストリームプログラミング）が発展した1990年代に遡ります。
現在では、手法や心構えについて解説する書籍も多く出版され、日本でも実践している組織が増えています。欧米でエンジニアと話をすると、アジャイル開発はもはや当然のやり方だという風潮になっていますので、日本でもこれからさらに主流になっていくと思われます。
この開発スタイルの特徴
アジャイル開発の特徴としては、ビジネス側の人と開発側の人でお互いの垣根を超えた数名からなるチームを形成し、そのチームが主体となって開発をしていくことが挙げられます。そして１週間や２週間という短い単位で開発を進めます。そのために開発範囲もその短い単位に収まるように設定します。開発状況や、出来たものの確認を通して得た教訓を次の１週間（もしくは２週間）へフィードバックし、微調整を繰り返しながら開発を進めていきます。この繰り返しによりトライアルアンドエラーを実現していきます。
これらを実現するために、アジャイルでは「デイリーミーティング」「プランニングポーカー」といったさまざまなプラクティス（実践事例）が紹介されていて、各組織では、自分たちに合うプラクティスを適用していきます。
この開発スタイルを利用する際のポイント
注意が必要なこととしては、アジャイル開発が単一の手法だけを指すものではなく、「価値」「原則」「役割」「プラクティス」「ツール」からなる、考え方や事例まで含めたものの集合体だということです。ひとつひとつを細かく見ていくと、昔からある考え方の場合もあれば、新しい考え方だと思われることもあります。また、それぞれはどんな時にでも上手くいく銀の弾丸ではないため、チーム自身が自分たちにとって何が必要なのかを考えながら適用していくことが重要です。チーム運営もトライアルアンドエラーを繰り返すことでアジャイル開発の良さが発揮できます。
クラウドを活用した開発
クラウドは、Amazon AWSやMicrosoft Azureが登場した2000年代後半から、ビジネスで使われるようになりましたが、今では説明が不要なほど一般的なものになってきました。ただし、クラウド上に載せるソフトウェアの提供する基本的な価値（例えば、営業支援システムであれば、案件状況の可視化や可視化のための労力の削減といった価値）については、ソフトウェアがどんな場所で動作しようと変わらないはずであり、そういう意味ではクラウドである必要はないかもしれません。
この開発スタイルの特徴
クラウドの活用は、いくつかの点でビジネスに貢献しうると考えられます。1つは、インフラ基盤を自在に伸縮させてサービスに対するインフラ基盤に対する過剰投資を防ぐことです。またもう1つは、環境構築やデプロイのスピードを上げることで、ビジネスのアイデアから、ソフトウェア開発、そしてサービスとして提供するまでのサイクルを短くすることです。
クラウド活用に適したソフトウェア開発の特徴は、クラウド上で全て完結できるところです。つまり、本番で使われているプログラムやデータが全て同じクラウド上にあります。本番で使われているプログラム、データ、そしてインフラ基盤が論理的にすぐに増やすことが可能になります。そのため、本番と同等の環境をクラウド上にすぐに作り、そこで新しいサービスを開発し、テストをすることが可能です。
そして本番にリリースすることも同様にすぐにできるようになります。本番リリースまでを効率化する一連の仕組みをCD（継続的デリバリー）と呼びます。この特徴をうまく生かすためには、開発と運用といった垣根が障壁になります。この障壁を取り除くことができればできるほど、クラウドを活用する効果を得ることができます。
この開発スタイルを利用する際のポイント
ソフトウェアの設計によっては、クラウド活用の効果が最大限に得られない場合があります。例えば、オンプレミスのシステム上で動作させていた既存のソフトウェアを、その設計を変えずにクラウド上に移行させるとしましょう。この場合、他のハードウェアにあるソフトウェアの呼び出しやネットワーク・インフラなどが「個別に最適化された環境」での利用を想定して設計されている可能性があります。
仮に、そのようなソフトウェアに対して、クラウドとオンプレミスの間や、他の外部サービスとの間を横断させようとすると、かえって複雑な設計になってしまい、開発の期間が従来よりも長くなってしまう恐れが強まります。そうなれば、「サービス提供サイクルを短縮化」というクラウド活用の効果が全て帳消しになってしまいます。
マイクロサービスアーキテクチャーを活用した開発
オープンソース、アジャイル、クラウドを活用した開発スタイルは、価値を素早く届けるために、ソフトウェアを少しずつ開発していく方法として考えられたといっても過言ではないでしょう。マイクロサービスアーキテクチャーは、少しずつ開発し、そこから得られるフィードバックによって絶え間なく変化していくことを可能にするために考えられたアーキテクチャーであり、2014年に提唱されました。
この開発スタイルの特徴
従来のアーキテクチャーはモノリス（一枚岩）アーキテクチャーと呼ばれます。データベース、ビジネスロジック、プレゼンテーションという階層で構造化することが多く、それぞれの階層に特化した技術者でチームを構成して開発を進めます。この場合、１つの簡単な機能追加を行ってリリースする際にもシステム全体への影響が懸念され、念入りに影響範囲をテストしたり、デプロイ時に全体的にサービスを止めたりといったことが必要になる場合があります。
マイクロサービスアーキテクチャーの場合、ビジネスドメインと呼ばれる、サービスを利用する観点でシステムを分割し、構造化します。ビジネスドメインで分割したマイクロサービス毎に開発チームを構成します。ビジネスドメインの単位で頻繁にリリースをしても他に影響がでないようにすることで、1日に数十回、数百回といった本番リリースが可能になります。
また、新機能を一部のユーザーだけが利用できるように本番リリースを行い、新機能に関してユーザーからのフィードバックも受けた上で段階的に全体に展開していくことができるようになります。これをカナリアリリースと呼びます。カナリアリリースによってより迅速なトライアルアンドエラーができるようになります。
アーキテクチャーの特徴としては、ビジネスドメインの単位で頻繁なリリースをしても他に影響を与えないようにするため、マイクロサービス間の結合をなるべく少なくすることがあげられます。例えばデータベーススキーマはサービス全体で１つではなく、マイクロサービス毎に分割し、複数のマイクロサービスが同じデータにアクセスとするといったことがないようにします。そのため、マイクロサービス毎に同じデータ（例えば、営業支援システムであれば、顧客IDや取引IDといったデータ）を重複して持つことを許可しています。
この開発スタイルを利用する際のポイント
しかし、ビジネスドメイン毎に分離したサービス間の整合性をどう確保するかという問題もあり、認証、ロギング、モニタリングといったサービス全体で共通となる機構で整合性を確保させるといった仕掛けが必須です。また、モノリスの設計思想のままマイクロサービスへ移行しようとすると、かえって複雑な設計になってしまい、開発の期間が従来よりも長くなってしまったり、品質が確保できなくなったりする可能性もあります。
2．開発スタイルの変化に対するソフトウェアテストの適合のために
今回は、ビジネスの成功に貢献するソフトウェアを作るための新しい開発スタイルとして、代表的なものを取り上げて概要を説明しました。
本連載は、これらの開発スタイルの中で行うソフトウェアテストがメインのテーマになっていきます。今回の内容は、そのための前提知識として理解してもらえればと思います。
各開発スタイルの概要で言及した通り、どの新しい開発スタイルにも注意すべきことがあります。ソフトウェアテストは、これらの注意点を意識して新しい開発に適合させていくことになります。
適合させるといっても、ソフトウェアテストの何もかもがこれまでと変わってしまうわけではありません。ソフトウェアテストの目的、基本的な考え方は新しい開発スタイルにも十分に有効です。
ただし、細かいやり方ひとつひとつで見ていけば、新しい開発スタイルに合わせて見直しをする必要があることも出てきます。見直しをする際に大事なことは、ビジネスの成功に貢献することが目的であることを念頭におくことです。
次回からは、新しい開発スタイルに合わせたソフトウェアテストとはどのようなものになるのかを説明していきたいと思います。
