アジャイル開発でスピーディーなソフトウェア開発を

IT時代を生き抜く中で自社ソフトウェアの保持は業務効率化、経費削減の上ではとても重要になっています。そして、その需要に応えるべくソフトウェア開発会社は、あらゆる開発手法を考え、試してきました。

高品質なものを短期間で納品することがベストだとすると、その挑戦に終わりはありません。このような状況下、比較的新しい開発手法であり、多くの現場で採用されている開発手法がアジャイル開発です。
アジャイル開発は、現在のソフトウェア開発の主流と言って良いほどです。

• アジャイル開発とは
• アジャイルソフトウェア開発宣言
• アジャイル開発の種類
• アジャイル開発以外の手法
• アジャイル開発実現のために
• アジャイル開発がベストチョイスではない

アジャイル開発とは

アジャイル開発とはソフトウェアをスピーディーに、かつフレキシブルに開発する手法の総称をいいます。短いプロセスを何度も繰り返して、ソフトウェアの質を高めていく方法です。
そのため、最初からソフトウェアの精度は求めず、何度もすべてのプロセスを繰り返して、ソフトウェアの質を上げて、最終的に高品質のソフトウェアを構築します。
「アジャイル」（agile）とは俊敏な、や素早いという意味を持ちますが、その英単語通りの開発手法です。

アジャイル開発では、まず最低限の大枠の機能を実装します。画面項目の配置やその項目をアクションしたら、どの画面に遷移するかなどです。
その時点では全くリリースできるレベルではありませんが、まずはそれで問題ありません。

次にその大枠機能をもとにして、クライアントと議論をし、細かい機能を実装していきます。
このように設計、製造、テストといったプロセスを繰り返して質を上げていきます。

スピーディーだと何が良いか

アジャイル開発の特徴の１つであるスピーディーな開発は、初期段階の設計漏れが気付きやすくなります。 ソフトウェア開発未経験のクライアントが相手だと、イメージしていたソフトウェアと出来上がったソフトウェアが往々にして異なっている場合があります。

事前に設計した機能が実際には実現できない機能だったり、そもそも仕様上、矛盾した設計だったりなどの設計漏れは、実物で確認できてこそ、気付けたりします。
これが開発中盤で分かるともはや修正は難しくなりますが、初期段階で分かるので修正対応が可能となります。

フレキシブルだと何が良いか

スピーディーな開発設計漏れが分かれば、それに付随してプログラム改修をかける必要があります。開発初期で気づけたので、プログラム改修をする時間はたっぷりあります。
しかし、これが開発中期あたりで発覚すると、そのあとはプログラム改修に多大な時間をかけることになります。
なにより、間違った設計書をもとに製造してきた時間がムダとなってしまいます。

あえてしっかり作りこみすぎないことで、仕様変更によるプログラム改修の時間を確保し、クライアントの要望（機能面、スケジュール面）に合った完成度の高いソフトウェアが出来上がります。

アジャイルソフトウェア開発宣言

アジャイル開発に関する包括的な考えは、アジャイルソフトウェア開発宣言にまとめられています。 アジャイルソフトウェア開発宣言は、アジャイル開発手法を採用して開発した人たちが持つべき考えをまとめた内容になります。

以下、アジャイルソフトウェア開発宣言（日本語版）より抜粋です。

「プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客（クライアント）との協調を、
計画に従うことよりも変化への対応を、
価値とする。」

これがアジャイルソフトウェア開発の考え方です。

引用：https://agilemanifesto.org/iso/ja/manifesto.html

プロセスやツールよりも個人と対話を

従来のソフトウェア開発では、使用実績のある進捗管理やツールを優先的に活用していました。
たしかに過去に成功した実績ある方法を踏襲するのは、信頼性の観点から大事にすべきですが、時代が変化するにつれて、クライアントの要望も変わり、仕事の進め方、最適なツールも変化します。
それにもかかわらず、実績のある方法だからと言って、このプロセスを経ないといけない、このツールを使わないといけないでは、方法論ありきの開発になってしまいます。
時代にそぐわない方法で開発を進めることになり、結果的にはプロジェクトの進捗遅延など、開発に悪影響が出てしまいます。

包括的なドキュメントよりも動くソフトウェアを

ソフトウェア開発では、クライアントと受託者は分厚いドキュメントで契約を交わし、納品物はドキュメントで納めるのが一般的です。もちろん、BtoBのやり取りなので、書面契約は不可避ですが、ソフトウェア開発で最も価値があるのはソフトウェア自体です。

高品質なソフトウェアこそ最大の価値があるのに、ドキュメント作成に精を出しすぎてしまうプロジェクトが往々にしてあります。しかしアジャイルソフトウェア開発宣言ではドキュメントよりもソフトウェアに価値を置いています。 綿密なドキュメントを作るなら、それに費やす時間をソフトウェア開発に充てるべきという考え方です。

契約交渉よりもクライアントとの協調を

クライアントと受託者の間で結ばれた契約書は、通常は細部まできっちり内容が決まっています。そのため、例えば、クライアントが途中で仕様を変更したくなった場合は、大ごとです。
受託者は、クライアントが望む仕様が実現できるかを調査し、さらにその仕様変更にかかる追加費用に関して、クライアントと契約交渉を行います。クライアントがその交渉を受け入れて、仕様変更に対応した改修が始まります。

ただし、この従来の契約交渉プロセスは顧客満足の観点からは、遠くかけ離れています。
契約交渉で長々と時間を費やすぐらいなら、クライアントの立場に寄り添ってすぐにでも追加対応してあげましょうということです。

計画に従うことよりも変化への対応を

アジャイル開発であっても従来の開発であってもまずは計画（スケジュール）を立てますが、初期段階の計画はあくまで初期段階の計画です。
不確かな事柄を前提で立てる計画なので、開発している最中に幾度となく前提は変わります。にもかかわらず、不確かな状態で作った初期の計画通り、プロジェクトを進行することは無意味なのに、あらゆるプロジェクトでは、その計画を変えずに進める方法を模索してしまいがちです。

でも、それは全く無意味なのでさっさと計画を変えて対応したほうが良いというのがアジャイル開発の考え方です。

アジャイル開発の種類

アジャイル開発はスピーディーかつフレキシブルな開発手法ですが、アジャイル開発の中でもさらに手法を分類することができます。

スクラム

スクラムとは、ラグビーのスクラムからきているといわれ、「みんなで協力し合って全体で大きなゴールを目指す」という考え方の手法です。 取り組むべき事柄をバックログと呼ばれるリストに記載して、優先順位順に機能を作ります。
プロジェクトメンバーは、基本的に毎日話し合い、進捗状況を確認し合います。フレキシブルな開発には認識の共有化は欠かせません。
開発するうえで、メンバー間で認識のずれが生じることが多々ありますが、毎日話し合うことで認識のずれをなくしていきます。スクラム開発でよい点は、プロジェクトチームが強くなるということです。

メンバー全員の協力がベースにあるため、一体感が出て、メンバー間の精神的結びつきが強くなります。バグや改修は毎日の話し合いで共有するので、デグレーションなども発生しづらくなります。
アジャイル開発の中で、一番ポピュラーな開発手法です。

エクストリームプログラミング（XP）

エクストリームプログラミングは、アジャイル開発の概念が誕生して、最初に広がった手法です。エクストリームプログラミングの特徴は、テスト駆動開発です。 テストを主体にして、プログラミングをしていくという考えで最初にシナリオテストのチェックリストを作成します。このシナリオテストを通すために製造をするので、ムダなコーディングを避けることができます。

フレキシブルなコーディングが求められるアジャイル開発では、ムダなコードはソフトウェアの質を悪化させてしてしまいますが、エクストリームプログラミングでは、そのようなリスクを避けることができます。

FDD（ユーザー機能駆動開発）

FDDは、ユーザーにとって重要な機能をリスト化し、重要視する機能から実装します。多くのプロジェクトで採用される手法ではないですが、クライアントが望む機能から作りこむという性質上、クライアントには喜ばれる開発手法です。

アジャイル開発以外の手法

アジャイル開発が主流となりつつありますが、アジャイル以外にも開発手法は存在します。非アジャイル開発として代表的な手法がウォーターフォール、プロトタイプ、スパイラルです。

ウォーターフォール

ソフトウェア開発が始まった当初に主流だった開発手法がウォーターフォールです。最も古典的な開発モデルと言っても良いでしょう。
ウォーターフォールでは、要件定義、外部設計、内部設計、製造、試験、本番稼働（納品）、運用といった各工程を順次行います。一つ前の工程が終われば、その成果物をベースに次の工程に進める、という方法で開発を行います。
1つずつの工程を完璧に終わらせてから次に進めるので、基本的に後戻りはしません。
そのため、仕様変更や設計ミスが発生したらすべての工程がやり直しになります。

プロトタイプ

プロトタイプ開発では、早い段階でソフトウェアのプロトタイプ（試作品）を作成します。そして、その試作品をクライアントに確認してもらい、ソフトウェアの仕様を決めます。
プロトタイプを見てもらうことでクライアントに完成形をイメージしてもらい、要件の漏れを防ぎます。

またクライアントと受託者でプロトタイプを見ながら議論することでお互いの認識のずれも防ぎます。プロトタイプ開発はとても効率的な気がしますが、ある程度完成度の高いプロトタイプを作る必要があるので、意外にコストがかかってしまい、特に大規模な開発では採算が合わなくなる可能性があります。

AIやIoT分野ではPoCフェーズも視野に

さらに、昨今、注目を浴びているAIやIoT分野では、プロトタイプよりもさらに前段階にPoCフェーズが必要となる場合があります。PoCとは、実証実験的な小規模開発を言います。AIやIoTなどの新しい分野では、まだ実績が乏しいので、前例のないシステム開発となるケースが多くあります。
このような場合はいきなりプロトタイプを作るのではなく、まず、そのシステム開発が導入可能かを検証するためにPoCフェーズからはじまります。とうぜん、PoCフェーズが加わる分だけコストはさらに増えてしまいます。

スパイラル

スパイラル開発もプロトタイプを作成するソフトウェア開発の手法ですが、プロトタイプ開発と異なるのは、スパイラル開発は設計とプロトタイプ作成を何度も繰り返し行う点です。クライアントの要望に応えるまで繰り返します。

アジャイル開発にも共通する反復開発型ですが、アジャイル開発はすべての工程を繰り返すのに対して、スパイラルは設計とプロトタイプのみです。スパイラル開発もやはり思った以上にプロトタイプ作成でコストが発生するので採算リスクの高い開発手法になります。

アジャイル開発実現のために

アジャイル開発は、スピーディーかつフレキシブルな開発なので、プロジェクトチームは基本的に少数精鋭です。
大人数だと心強いですが、スピーディーでフレキシブルな開発には向いていません。そのためアジャイル開発を実現するためには、優秀な精鋭エンジニアが必要となるのです。
アジャイル開発を採用すれば、アジャイル開発ができる、という単純な話ではないのです。アジャイル開発のプロジェクトメンバーにはエンジニア力と人間力が求められます。

すべての工程を繰り返せるエンジニア力

すべての工程を繰り返しできるエンジニア力とは、深く堀り下げると、すべての工程を経験していて、自力ですべての工程を繰り返しできる能力のことです。 ２、３年目のエンジニアには到底難しく、５年～１０年の開発経験は必要です。俯瞰した目でプロジェクト全体を見渡せて、仕様変更にも柔軟に対応できる特筆した能力です。

優れた人間力

クライアントと繰り返しやり取りをして、クライアントの要求を正確に受け止めて、その要求をプロジェクトメンバーに正確に伝達できる優れたコミュニケーション力も求められます。 そして、繰り返しの仕様変更にもモチベーションを保てる安定した精神力を持っている人財が必要です。

アジャイル開発がベストチョイスではない

アジャイル開発は、クライアント側に立ち、「お客様は神様です」的な観点から考えると、たしかに理想的な開発手法です。
しかし、受託者側に立った時にどうなるでしょうか。アジャイル開発を行うためには、優秀な人材を確保しなければなりません。とうぜん、人件費つまりソフトウェア開発における原価は高くなります。（そして、エンジニア不足のこのご時世にそんな優秀なエンジニアはなかなか空いていません）

そして、「クライアントのために」が行き過ぎてしまうと、それは受託者であるソフトウェア開発会社の立場を危うくします。考え方次第ではすべてのクライアント要望を受け入れてしまうことになりかねず、クライアントの気まぐれな要望でソフトウェアを作り替えたり、さらに作り戻したりなどのムダな工程が発生してしまいます。時間がいくらあっても足りません。
本来、ビジネスはお互いが対等な立場なはずなのに、クライアントの立場が圧倒的に高くなるリスクがあります。デスマーチの危険性をはらんでいます。

たしかに、アジャイル開発は、画期的で優れて、クライアントのためになる開発手法なのは疑う余地がありません。
しかし、すべてのソフトウェア開発はアジャイル開発がベストチョイスだと考えるのは早計です。どんな手法にもメリットがあればデメリットもあります。 アジャイル開発は受託者にとってデメリットになる場合もあるのです。

そのため、受託者は案件やクライアントの状況を考えたうえで、アジャイル開発を採用すべきか、もしくは他の手法を採用すべきかをしっかりと吟味して、開発を始めた方が良いでしょう。
それでこそ、クライアント、受託者双方にとって最適なソフトウェア開発が可能となります。

PR：ECサイト構築パッケージ「EC-ORANGE」