何をおいてもまず最初に、アジャイル開発の持つ圧倒的な成功事例をご紹介したいと思います。
こちらはアメリカFBIでの成功事例です。
このプロジェクトは当初5年間、日本円にして約500億円を費やしても完遂できませんでした。つまりプロジェクトは失敗し、ソフトウェアはリリースされることがないまま中止に追い込まれてしまった悲劇のプロジェクトでした。
そしてこの時に採用された開発手法は、今の日本でも多くのプロジェクトで採用されている「ウォーターフォール」とよばれる開発手法でした。
しかし、一度は中止されたこのプロジェクトを、アジャイル開発手法に切り替えたことによって見事に完遂。悲劇のプロジェクトは奇跡のプロジェクトとして語り継がれるようになりました。
さらに、完遂に費やした時間はたったの１年。費用は当初の10分の1以下の約30億円でした。
※このページの最後に、私達が担当し、そして大成功を収めた
アジャイル開発プロジェクトの実践事例の解説動画無料プレゼントをご案内しています。
ぜひ、お見逃しなく！
目次
1.ウォーターフォール型の開発手法が招いた悲劇のプロジェクト
この悲劇のプロジェクトは、2006年3月にFBIによって開始されました。プロジェクト名は「Sentinel（センティネル）」。３万人以上のFBI捜査官・アナリスト・管理職が利用する超巨大システムです。
このプロジェクトの当初の開発見積もりは約540億円。完成予定は、３年後の2009年12月でした。
しかし、システムの完成予定を大幅に超えた2010年7月。このプロジェクトは中止に追い込まれました。
なぜなら、プロジェクトが中止された段階で、当初予定していた機能の半分しか完成していなかったのです。
しかもその時点で、既に予算の90%、約490億円が費やされていました。
そして、このままプロジェクトを進めた場合、さらに420億円の追加予算と、プラス６年の開発期間が必要という結果が試算されました。
FBIのシステムといえば、その原資は当然アメリカ国民の「税金」です。約500億円の税金が、システム開発の失敗によって水の泡と消えてしまいました。
そして、この時に採用されたシステム開発手法が、今日本でも多く用いられている「ウォーターフォール手法」でした。
2.悲劇のプロジェクトから奇跡のプロジェクトへ
この悲劇の失敗を受けて、FBIは、ウォーターフォール型の開発手法からアジャイル開発手法への切り替えを決断しました。
そして新たに、アジャイル開発プロジェクトを用いた開発のマネジメント経験のある新たなCIOとCTOを採用しました。
さらにFBIは、それまでプロジェクトに携わっていた人員を400人から、なんと約10分の１の45人に削減しました。
10分の１の規模で仕切り直しされて再始動した悲劇のプロジェクト…
しかしそのプロジェクトは「悲劇のプロジェクト」から「奇跡のプロジェクト」に生まれかわりました。
なんと仕切り直しから12ヶ月後の2011年11月までにすべての開発を完了してしまったのです。
アジャイル開発手法に切り替えてから費やされたのは、当初予算の10%以下の36億円。そして開発期間はたったの12ヶ月です。
2006年3月から約５年の時間と490億円という巨額の費用をかけても完成できなかった巨大システム。
それを、アジャイル開発手法に切り替えたことで、当初予算の10%以下で完遂できのです。
3.アジャイル開発があなたのプロジェクトにもたらすもの。
今現在、困難なプロジェクトに身をおいている開発者や発注担当者、もしくは大きな情報システム投資をしている経営者が読んだら、ちょっと心臓に悪い事例だったかもしれません。なぜなら、先に書いた悲劇はあなたのプロジェクトにも起きる可能性が大いにあるからです。
ソフトウェアの成功率は概ね３割程度だと言われています。
しかしこの成功率は、あまりに低すぎるのではないでしょうか…
ご承知のとおり、今日ではソフトウェア無しではビジネスそのものが成り立ちません。
ということは、今この瞬間でも大小含めて何千・何万ものソフトウェア開発プロジェクトが推進されているはずです。
にも関わらず、これらのプロジェクトで理想のゴールに辿り着けるのはたったの３割…
この現実は、ソフトウェア開発プロジェクトに携わる開発者・利用者、そしてプロジェクトオーナーたる経営者といった全ての利害関係者に不幸をもたらしています。
しかし、この不幸な現実に一筋の光明を照らすのがアジャイル開発手法なのです。
センティネルのプロジェクトに見られるように、アジャイル開発手法を適用することで、悲劇のプロジェクトが奇跡のプロジェクトに生まれ変わる可能性が劇的に上がります。
もしあなたがプログラマであれば、自分の仕事に誇りを持つことができるでしょう。お客様は、満面の笑みであたなの手を握り、感謝と喜びの言葉をかけてその労をねぎらってくれると思います。ソフトウェアの開発者としてこんなに素晴らしい瞬間は他にありません。私達もソフトウェアの開発者なのでその喜びは、よく理解できます。
もしあなたがシステム利用者であれば、毎日の業務がスムーズにはかどり、より短時間でより多くの成果をアウトプットすることができるでしょう。コンピュータにできることはコンピュータに任せる。あなたはあなたにしかできないクリエイティブで付加価値の高い仕事に集中することができるようになるでしょう。
もしあなたが経営者であれば、極めてリターンの大きいIT投資を実現することができるでしょう。そして、あなたのビジネスはより拡大し、より加速し、そしてより多くの人に価値を届けられるでしょう。さらにあなたはプロジェクトオーナーとして、プロジェクト関係者の全てから尊敬される存在になるでしょう。
まさにサンポウ（三方良し）のソフトウェア開発手法。
それがアジャイル開発手法なのです。
4.数字で実証されているアジャイル開発手法の成功率の高さ
アジャイル開発がウォーターフォール型の開発と比較して３倍もの成功率をほこることは数字で実証されています。
ここで紹介させていただく【CHAOS REPORT 2011】は、残念ながら日本の調査結果ではなくアメリカでの調査結果です。しかし海外のサイトでは、この数字がかなり多く引用されています。そして私達の経験則からも非常に信頼のおける数字であると言えます。
実際にレポートの内容を確認されたい方は、Google検索で【chaos report 2011 agile】とご検索ください。相当数の学術記事やブログ等がヒットすると思います。
こちらには、数ある解説サイトの中でも非常に要領よくまとめられているこちらのサイトをご紹介したいと思います。
上記の円グラフにおいて、Successfulは「成功」、Challengedは「改善の余地あり/問題あり」、最後のFailedは「失敗」と理解して良いと思います。まずこのグラフで目につくのは、ウォーターフォール型の失敗率です。恐らくこの失敗は「プロジェクトの中止」を伴う致命的な失敗と思われます。つまり、ソフトウェアは何もリリースされることがなく、プロジェクトが中止されてしまった割合となります。その致命的な失敗は全体の30%を占めています。
それと比較して、アジャイル開発についてはわずか9%です。
額面通り受け取るならば、ウォーターフォール型の開発は、アジャイル開発と比較して３倍も失敗する確率が高いということになります。
また、成功プロジェクトの割合にも注目していただきたいと思います。
ウォーターフォール型の開発において、成功と評価されたプロジェクトは全体の14%なのに対して、アジャイル開発では42%と、こちらはアジャイル開発のほうが３倍高い成功率を示しています。
ウォーターフォール手法と比較して、圧倒的に高い成功率をほこるアジャイル開発手法ですが、残念ながら現在の日本のプロジェクトでは、まだまだウォーターフォール型が主流です。
もしあなたの会社がソフトウェア開発をアウトソーシングした場合、このウォーターフォール型で対応される可能性が極めて高いと言えます。そして過去にアウトソーシングで苦い思いをしてきたユーザ企業も、このウォーターフォール型の開発手法に苦しめられてきました。（そして現在でも苦しんでいるプロジェクトは数多くあります…）
しかしこれは日本の「ガラパゴス化」の産物なのでしょうか。
いえ、そんなことは無いようです。海外の文献や有識者のブログをつぶさに見ていくと、アメリカの企業も、最初からアジャイル開発手法を使って開発をしていたわけでは無いようです。
海外の企業も、今の日本と同じく、ウォーターフォール型のプロジェクトによる数多くの失敗を経験しています。
その失敗を教訓として、様々な研究と試行錯誤がなされ、アジャイル開発手法が生まれました。
そして約20年の歳月をかけて、アジャイル開発手法はついに主流の開発手法になったのです。
アメリカでは、スクラムをはじめとしたアジャイル開発手法の導入企業が全体の９割に達しているというレポートもあります。
この普及率もアジャイル開発手法が、いかに有用であるかを物語る重要な指標であると言えます。
5.なぜアジャイル開発手法は、従来のソフトウェア開発手法に比べて３倍の成功率をほこるのか？
アジャイル開発の成功率の高さを説明するには、ウォーターフォール型の開発手法との違いをご理解いただくのが最も解りやすいと思います。
アジャイル開発手法とウォーターフォール開発手法の違い、それは「変化に対する考え方」の違いです。
端的に表現するとウォーターフォール・メソッドは変化を受け入れません。
一方アジャイル・メソッドは変化を積極的に受け入れます。
この変化に対する考え方の違いが、アジャイルとウォーターフォールの最も大きな違いです。
ではなぜ、変化を受け入れるアジャイル開発手法の成功率が優れているのでしょうか。
ダーウィンは、進化論の中で「最も変化に対応できる種が生き残る」と解きました。そしてソフトウェア開発においても、その理論はあてはまるようです。
ソフトウェア開発プロジェクトが「変化を受け入れる」べきであることは、たったひとつの理由です。
それは我々人間が、これからはじめて世に送り出すソフトウェアに搭載すべき機能と、その機能を開発するために必要な時間とコストを、予め全て正確に定義することは絶対に不可能であるという現実です。
6.計画主義のウォーターフォール、行動・経験主義のアジャイル
ウォーターフォール手法では、このソフトウェアに搭載すべきすべての機能と、その機能の開発に必要な費用・時間を予め定義する作業を「要件定義」と呼びます。そして、ウォーターフォールが失敗する原因の８割は「要件定義が十分に行われなかった・要件の漏れ」に起因します。この現実を受けて、近年のソフトウェア開発プロジェクトでは「如何に要件定義を漏れ無く遂行できるか」にフォーカスが当てられてきました。
その結果、要件定義フェーズのフィーは高騰。
ITコンサルタントと呼ばれる職種の専門家が、高額なフィーを受け取って要件定義を行うようになりました。その要件定義フェーズで作成されるのは、システム利用者が読んでもプログラマが読んでも意味の分からない大量のドキュメントです。
こんなドキュメントのために、ユーザ企業は数千万のお金を支払わなければならなりません。
しかし、現実的な話として、これからはじめてこの世に生み出されるソフトウェアの全ての機能を漏れ無く定義することは可能でしょうか。また逆に、実際は必要のない機能を必要だと定義してしまう可能性はないのでしょうか。
私達は20年以上、大小様々なプロジェクトを経験してきましたが、事前にすべての要件を過不足無く定義することは絶対に不可能だと思います。
そもそも私達はこの「ITコンサルティング」の分野で起業しました。そして数多くのプロジェクトの「要件定義」を支援してきました。その経験からも、ビジネス的に価値のあるソフトウェアの機能を予め過不足なく完璧に定義することは絶対にできないと言えます。
もちろん、よほどの小規模なソフトウェアであればそれは可能かもしれません。しかしそれが何百・何千にも及ぶ機能をもった大規模なソフトウェア開発であれば、予め過不足なく定義することはそれこそ奇跡です。
しかし、ウォーターフォールは、その「奇跡」が起こることを前提とした開発手法なのです。
それと比較して、アジャイル開発では、プロジェクトの初期にすべての機能を漏れ無く定義するような非合理的なことはしません。
アジャイル開発のプロジェクトは、初期の開発に必要な情報が集まれば、直ぐに開発を開始します。
そして、最長でも30日後、最短だと１週間後には実際に動くソフトウェアを完成させます。
システム利用者、もしくはプロジェクトオーナーは、この「実際に動くソフトウェア」を、具体的に操作しながら、その機能がビジネス的に有用なものなのかを評価します。システム利用者やプロジェクトオーナーでも、実際に使ってみるまではその機能の必要性、もしくは「真に必要とされる機能」はわからないのです。
そしてプログラマは、リリースしたソフトウェアに対して具体的なフィードバックを得ることができます。
この具体的なフィードバックの中には、当然初期には予測していなかった機能の追加も出てくるでしょう。また反対に、当初予定していた機能が必要なくなるといったことも出てくるでしょう。こういった変化を、アジャイル開発手法では肯定的に、むしろ積極的に受け入れます。
これがウォーターフォールだとそうはいきません。全ては「仕様変更」という不穏なレッテルを貼られ、そして手戻りによる追加費用の温床となります。
さらにソフトウェア開発プロジェクトの期間中、プロジェクトを取り巻く環境はどんどん変わっていきます。
新しい業務が追加される、今までの業務が廃止される、社内の組織変更によって仕事の流れが変わる、ライバル企業の出現、新技術の誕生、プロジェクトのキーパーソンの退職、OSやデータベースのバージョンアップ…
このようにプロジェクトに影響のある変化はを挙げ始めれば枚挙にいとまがありません。ビジネスのスピードそのものが非常に早くなった今日、このような変化は日常的に発生します。
この変化にうまく対応しながら、その時々で最善の舵取りを行うのがアジャイル開発手法の真髄なのです。
アジャイル開発プロジェクトでは、このような激しい変化を積極的に受け入れながら、１〜４週間という短期間で実際に利用可能なソフトウェアを次々にリリースします。
そして次々にリリースする実際に利用可能なソフトウェアから得られる具体的なフィードバックもとに、常に発生する変化に対応しながら開発を進めていきます。
この変化に対する対応の違いがウォーターフォール手法よりもアジャイル開発手法の成功率が３倍も優れている最も大きな要因なのです。
7.私達が支援したプロジェクトの成功例
ここからは弊社におけるアジャイル開発手法を用いたプロジェクトの成功事例をご紹介させていただこうと思います。
こちらは、FileMakerジャパンの公式パンフレットにも掲載いただいている株式会社アクア・グラツィエ様の成功事例です。
このプロジェクトではアジャイル開発プロジェクトらしく段階的なシステム化によって、在庫回転率を数倍に、また大幅な残業時間の削減に成功しました。
その結果は決算書レベルでも如実に現れるほどのインパクトだったと伺っています。
最初に全てを決めない。小さく始めて大きく育てる。
このプロジェクトのとりかかりはまず、手書きで書かれた書類の電子ファイリングツールを開発・導入するところから始まりました。
２週間程度の開発期間を終えて、実際の業務で使用いただいたところ、思ったほどの効果が出ませんでした。また、現場の実業務も、担当者や店舗によってバラつきがあり、この方法では期待した程の効果が上がらないことがわかりました。
やはり簡易的な電子ファイリングの機能で小手先の効率化を追うよりも、もっと根本的な問題に対応したい。しかし、数年前にソフトウェア開発をアウトソーシングした時には、当初の予算を大幅にオーバーし、さらにやりたかったことの半分も実現できなかった…
お客様はそんな苦い経験をお持ちでした。なので、本格的なシステム開発を立ち上げるには、心理的な障壁がかなり大きかったのではないかと思います。
そういった経緯の中で、私達は開発プロジェクトを担当させていただきました。
私達はアジャイル開発の方法論を用いて、顧客管理・販売管理・在庫管理・購買管理等のシステムを段階的に開発・リリースしていきました。
それぞれの機能を実際に業務で使用しながら、機能の過不足やユーザインタフェースを修正。そしてシステムがカバーする業務範囲を徐々に広げていき、最終的に仕入から売上まで一気通貫のシステムを構築することができました。
私達は20年以上もシステム開発の現場にいますが、恐らくこの規模のシステムをウォーターフォールで開発していたら、まず完成まで辿りつけなかったのではないかと思います。
もし完成まで辿りつけたとしても、何倍もの費用と時間、そして使い勝手の悪いシステムが出来上がっていたに違いありません。
なぜなら、このプロジェクトの最中にもプロジェクトにインパクトを与える様々な「変化」がいくつもあったからです。
それは業務ルールの変更、社内の組織体制の変化、パートナー企業との関係性、関連システムの仕様変更、RDBMSのバージョンアップ…
数え上げればきりがないほどの変化が発生しました。
しかし、「変化を受け入れる」アジャイル開発手法を適用することで、この難しい状況に対応することができました。
しかもプログラマとしては最大でもたったの３名、平均すれば1.5名以下でこのシステムを完成させることができたのです。
このプロジェクトの成功要因は、上場企業の連結会社の基幹システムであるにもかかわらず、「最初に全てを決めない」「重要な機能から徐々に開発していく」「実際に現場で使いながら改善していく」「有益な変化を積極的に受け入れる」という指針を、ブレずに実践したことにあります。
その結果、このシステムは決算書レベルでその成果が確認できるほど、大きな成果を得ることができました。
ちなみに、このプロジェクトを利用者サイドで取りまとめいただいた物流部門のマネージャ様は、この功績が認められて社長賞を受賞されたということです。
これは我々開発者としても自分事のように非常に嬉しいニュースでした。
8.アジャイル開発とFileMakerが内製化に最適な理由
弊社お客様の成功事例、そして海外における成功事例をご紹介しながら、なぜアジャイル開発が、ウォーターフォール型の開発手法よりも高い成功率をほこるのかについてご説明させていただきました。
そして我々は、FileMakerプラットホームとアジャイル開発手法は、システムの内製化に極めて有用な組合せであると考えています。
ソフトウェアを内製化する最も大きな目的な何でしょうか…
それは、「開発生産性の向上」と「経済的な合理性」の両方を追求しながら、システムを素早く展開し、それを継続的に拡張・改善していきながら120%利活用することで、自社の競争優位性を継続的に向上させるため…というのが私達の考えです。
ここで重要なのが、「開発生産性の向上」と「経済的な合理性」いうキーワードです。そして、この２つのキーワードに共通する概念は「スピード」です。ソフトウェア内製化で最も重要な事は「スピード」であると私達は確信しています。
このスピード開発を徹底的に追求しなければ、ソフトウェア開発を内製化する意味はないに等しいと思います。
そして私たちは、そのスピードの追求に最も適した組合せがアジャイル開発とFileMakerプラットフォームの組合せだと評価しています。
FileMakerプラットフォームが持つ、技術獲得コストの低さや圧倒的なコーディング量の少なさ、そして拡張性と柔軟性に富んだこのプラットフォームは、一般的に普及している開発プラットフォームよりも、より少ない時間、より少ないコストでソフトウェアを開発・運用することができます。
さらに、アジャイル開発手法を用いることで、FileMakerプラットフォームが持つスピードを何倍にも加速することができます。FileMakerプラットホームがエンジンなら、アジャイル開発手法はターボチャージャーと例えることもできるでしょう。
FileMakerプラットフォームを選択しても、ウォーターフォール型で開発するのであれば、その潜在能力を十分に発揮することはできません。逆にアジャイル開発を選択したとしても、技術獲得コストが高く、コーディング量が膨大な、一般的な開発プラットフォームを選択してしまえば、やはり同じく「スピード」を失うことになってしまいます。
開発プラットフォームとしてのFileMaker、開発フレームワークとしてのアジャイル開発。
この２つが揃うことで、はじめて内製化に求められる「圧倒的なスピード」を得ることができると私達は考えます。
無料動画プレゼント
FileMakerプラットフォームとアジャイルソフトウェア開発手法で大成功を収めたプロジェクトの解説動画をプレゼントいたします。
この動画では、アジャイルソフトウェア開発手法だけではなく、事例としてあまり聞くことの少ないFileMakerプラットフォームでのチーム開発についても、多くを学べる動画になっております。
今回ご紹介させていただくプロジェクトのお客様は、東証１部上場企業のサービス業です。
こちらのお客様が、新たに新規顧客獲得の増加、そして成約率の向上を目的としたコールセンターを立ち上げるということで、そちらのコールセンターで使用する顧客管理システムの構築事例となります。
プロジェクト立ち上げ当初は、具体的なコールセンターの業務フロー、メンバーも決まっていないという状況から、納品期日の３週間前にはすべての開発を終えて納品させていただくという、絵に描いたような成功プロジェクトとなりました。
また、この時にプロジェクトに参画したプログラマのプロジェクト中の残業時間はゼロ時間。
今すぐ、以下のコンタクトフォームから動画URLをご請求してください。
