アプリ開発やサイト制作のスマホ端末実機検証・テスト-Remote TestKit

継続的インテグレーション入門

ソフトウェア開発におけるQCDを高い次元で満足させるための手法の一つである、継続的インテグレーション(Continuous Integration)について学習します。

システム開発における課題

最近のシステム開発において、最も求められていることはなんでしょうか?

以前から、QCD(品質、コスト、納期)といわれていますが、この三つを同時に満足することが困難であることは、ご存知かと思います。

QCD

品質を上げるためにはテストを十分に行う必要がありますが、そうすると、テスト工数が膨らみ、コストと納期が遅れる可能性があります。

納期を短縮するためには開発者の人数を増やす場合もありますが、「人月の神話」に代表されるように、人員を増やしてもある程度以上は生産性は向上しません。結果的に、コストが上がる場合も考えられます。また、納期を短縮するためにテスト工数を減らす、という対応をすることで、システムの品質が下がる場合もあるでしょう。

コストを削減するには、開発者の人数を減らすことが多いかと思われますが、開発する成果物が同じであれば、人を減らした分だけ納期が遅れます。あるいは、テスト工数を削減して、品質が下がる場合もあるでしょう。

現在の多くのシステム開発では、以前より「複雑化」「短納期化」「低コスト化」する要求が強くなっており、かつ、開発途中でも、お客様の要求が変化し続けるという特徴があるのではないでしょうか? もちろん、「品質」を落としても良いといわれるお客様がいらっしゃるわけはありませんよね。

このようなお客様の要求にこたえる一つの手法として、アジャイル開発があります。

では、アジャイル開発と、オーソドックスなウォータフォール型開発手法の違いは何でしょうか? この二つの違いの中でも、注目すべき点は以下の点です。

  • 短いサイクルで、お客様にとって価値を生む機能から順々に実現し続ける。
  • サイクル毎に、お客様の要求が変化することを前提としている。

よく間違えられるのですが、アジャイル手法だと開発コストが下がると思われている方がいらっしゃいます。しかし、同じ技術を使って、同じ機能を実装するためのコストが、開発手法を変えただけで劇的に下がるはずがありません。

とはいえ、ちゃんとしたアジャイル手法の開発現場では、QCDを求めるための仕組みを構築したうえで開発を行います。その結果、QCDという相反する要求を、ある程度満たすことが可能となっています(当然、ある種のトレードオフは発生します)。

課題解決のための仕組み

QCDを求めるための仕組みとして「継続的インテグレーション(Continuous Integration)」と呼ばれるものがあります。その仕組みを実現するためにCIツールと呼ばれるツールを導入し、開発を行います。

では、「継続的インテグレーション」とは、なんでしょうか?
名称から「インテグレーション(結合、統合)」を「継続的に実行する」という仕組みであることは、想像ができるのではないでしょうか?

この「継続的インテグレーション」の効果は、主に、不具合をできるだけ早期に発見することと、システム開発におけるさまざまな情報を可視化することです。

従来のウォーターフォール型開発手法では、フェーズ間で手戻りが発生しないように、レビューを徹底することが挙げられます。残念ながら、実際には、手戻りが発生しないというような理想的な開発の現場はほとんどあり得ないと思っています。そして、手戻りが発生する場合には、問題の発生時点から、発見までの時間が長ければ長いほど、対応工数が大きくなり、手戻りコストが増大するのは、ご存知のことだと思います。
したがって、不具合の発生をできるだけ早期に発見することができれば、対応工数も少なく、手戻りコストを最小化することができるのです。

また、情報の可視化によって、現在のシステムの開発状況を把握することができ、今までならわからなかった潜在的な問題を可視化することも可能となります。「継続的インテグレーション」を導入することによって、このような効果を得ることができるのです。

上手く使いこなせば他にもさまざまなメリットを受けることができますが、現在のプロジェクトや組織の成熟度に合わせた形での「継続的インテグレーション」を導入しなければ、逆に振り回される可能性もあります。

さらには、CIツールに代表されるツールの導入が必要になりますし、それらを稼働させるためのコンピュータリソースも必要となります。基本的に、必要となるコンピュータリソースは以下のようなものが挙げられます。

  • 構成管理サーバー
  • CIサーバー
  • ビルドサーバー
  • 各開発者の開発環境
CI構成要素の関係

これらのコンピュータリソースを適切に配置することで、「継続的インテグレーション」を実行できる環境を整えます。

CIツールは、無償で提供されている物を選択することもできますが、コンピュータリソースは無償では用意できません。とはいえ、コンピュータリソースにかかるコストより、「継続的インテグレーション」を導入したことによって受けるメリットの方がはるかに大きくなります。これは、プロジェクトの規模が大きくなればなるほど、より効果的になります。

導入シナリオ

では、代表的な「継続的インテグレーション」の導入シナリオについて、以下で説明いたします。

必須の導入項目

「継続的インテグレーション」を導入するにあたって、必須事項として、「自動ビルド」と「自動テスト」が挙げられます。これをなくして、「継続的インテグレーション」とは言えないと筆者は考えています。

ここでいう「自動ビルド」は、基本的に、開発しているシステム全体のビルドを表します。常にシステム全体をビルドできることを確認し続けることで、確実にテスト可能な実行ファイルが生成されることを保証します。

そして、テスト可能な実行ファイルが生成できたならば、それを「自動テスト」にてテストを行い続けます。当然ですが、テストがエラーとなれば、それは何らかの不具合が現在開発中のシステムに混入しているということを示すので、対処する必要があります。そして、不具合の混入から発見までの時間が短ければ短いほど、対応にかかる工数も少なくなります。

なお、導入したCIツールと構成管理ツールの選択によっては、「自動ビルド」と「自動テスト」の頻度や実行タイミングの制御にある種の制限が出る可能性もあります。同時に、プロジェクトや組織によっても、不具合の混入から発見し対応するまでの許容時間は異なると考えられます。

定期的に「自動ビルド」を実行することはほとんどのツールで可能です。また、構成管理ツールへの格納時に「自動ビルド」「自動テスト」を行って、不具合が検出された場合には、構成管理ツールへ格納できないようにさせるツールの組み合わせも存在します。これらによって、常にシステムが動作することを保証された状態を保ち続けることで、全体的な生産性の向上を見込むことができます。同時に、お客様の要求が変化した場合でも、開発者が機能を追加、変更する時に十分な「自動テスト」が用意されているならば、デグレードの発生をその場で検出でき、素早い対応が可能となります。

つまり、変化に強いシステム開発が可能になるのです。

開発状況の可視化

「継続的インテグレーション」を導入するメリットの一つに、開発状況の可視化が挙げられます。

一般的なCIツールでは、それぞれのビルド結果の履歴を持っており、それを時系列に並べて可視化する仕組みがあります。この機能を使うことで、先に記述したビルドエラーの発生状況を確認することもできますし、「自動テスト」の状況(テストケース数やテスト結果)も確認することができます。

ソースコードのメトリクス測定

CIツールによる「自動ビルド」と同時に、ソースコードのメトリクス測定ツールを実行することで、現在開発中のソースコードのメトリクスを表示することが可能となります。

測定ツールによって測定可能な項目や値に差異はありますが、同一ツールを常に使用することで、開発中のソースコードのメトリクスデータの変化を参照することが可能となります。

同時に、メトリクスデータを見ることで、潜在的な問題を含んでいる可能性の高いソースコードを識別することができます。これにより、ソースコードレビューや、リファクタリングなどを行うための指標を得ることができます。

ソースコードの静的解析

CIツールによる「自動ビルド」と同時に、コーディングルールのチェックツールや、潜在バグのチェックツールを実行することで、現在開発中のソースコードの問題点を可視化することができます。

直接の不具合としては顕在化していませんが、将来不具合につながる、もしくは、保守性を下げるような状況の発生をここでチェックすることも可能です。

他にもCIツールの導入シーンにはさまざまなものがあり、うまく活用することで多くの改善ができる可能性があります。

導入にあたっての注意点

しかしながら、「継続的インテグレーション」を導入したからといって開発者自身のマインドセットが変わらないと、開発の現場は何も変わりません。

また、「自動テスト」の設計と実装という新しいスキルも必要となります。同時に「自動テスト」の品質(カバレッジなど)が悪いと、結局、手動テストで不具合を見つけて、手戻りが発生するということもあり得ます。さらには、マネージメント層に理解がない場合には、無駄なことをしているようにとられる場合もあります。

「継続的インテグレーション」を導入して効果を出すためには、何を目的として導入するかを明確にして、プロジェクト全員がその理由を理解してから導入する必要があります。

執筆者プロフィール  吉村 好廣

外資系コンピュータメーカーに入社し、ハードウエアからソフトウエアまで幅広く開発の経験を積む。その中で様々なレベルのテストを経験する。独立後、テストをキーワードにプロジェクトを渡り歩くフリーランスのエンジニア。Androidテスト部、自動化テスト研究会等の活動の中でさらに切磋琢磨し腕を磨き続ける。