限りなく自動化したテストとデプロイ（本番環境にプログラムを配布すること）により、作ったコードを極力早くユーザーに使ってもらう。これを繰り返すことで効率よく品質の高いシステムを提供し続けていく。こうした「継続的開発」は今、最もホットなテーマの一つと言っていいだろう。
「継続的デリバリー（CD）」と呼んだり、ビルドとテストの自動化を主眼として「継続的インテグレーション（CI）」と呼んだりする。継続的開発はそれらの方法論やツール、コンセプトを総称したものである。
ご存じの方も多いと思うが、継続的開発はアジャイル開発に端を発している。アジャイル開発とは一気に全部の要求をシステム化するのではなく、継続的に少しずつ要求に合ったものを開発し続けていくスタイルである。作成したシステムをユーザー部門に使ってもらい、フィードバックを受け、素早く改善していくこともできる。
メリットは多いものの、多くのユーザーにとって開発側からのアジャイル提案は「何だか怪しいもの」に聞こえるらしい。内容がよく分からないからか、「作り手にとって都合のいい方法」と捉えられてしまうのだ。
また、ユーザーがアジャイル開発を短絡的に理解してしまうと、「いつまでも仕様を変更できる」「すぐ何でも作ってもらえる」と思われてしまう。中には「成果物責任を負えないなら駄目だ」と主張する人もいる。
こうしたアジャイル開発を取り巻く環境が、継続的開発に注目が集まることで変化してきている。継続的開発はユーザーへの価値をより具体的に説明できる。CIツールなど目に見える道具もそろってきている。継続的開発への理解をきっかけに、アジャイル開発はユーザーに受け入れられやすくなるだろう。だからどんどん提案すべきだと思うが、ここで改めて注意しておきたいのが、従来のSIモデルではアジャイル開発のメリットをうまく引き出せないことだ。
アジャイル開発が最も効果的なのは、ソフトウエアを内製化する場合である。欧米は内製化のスタイルがほとんどなのでアジャイル開発の効果を出しやすいが、日本では多重請負構造が多い。多重請負構造のままでアジャイル開発の良さを引き出そうとしても無理がある。
「多重」もやっかいな問題だが、本質的には「言われた通りに作ります」という請負姿勢でいる限り、アジャイル開発のメリットは引き出せないと思ったほうがいい。ユーザー部門に出向いてビジネスのキーパーソンと話をし、一緒にシステムを作る立場を確立する。そうすればアジャイル開発のメリットを享受できる。
個人的にそうしたくても組織の上層部が理解してくれない。そう思う読者もいるだろう。このコラムは一人のエンジニアとして書いているが、筆者はIT会社の経営者でもあるのでその立場で言えば、今、多くのSI会社は転換期にあると考えている。従来の事業モデルを再構築しようとしており、いうならば会社としての“進むべき道”を模索しているのだ。そこでのキーワードの一つに「継続的開発」があると見ていい。
エンジニアとしては、“進むべき道”の見本となるくらいの気概を持ってアジャイル開発に取り組みたい。
