「第19回：アジャイル開発の実践例：ANAシステムズ株式会社 その2」はこちら＞
「第20回：アジャイル開発の実践例：アジャイルのはじめ方 その1」はこちら＞
「第21回：アジャイル開発の実践例：アジャイルのはじめ方 その2」はこちら＞
従来のシステム開発の２つの問題
本日はまず、なぜアジャイル開発がDXというトレンドの中で脚光を浴びているのかをお話ししたいと思います。
例えば新しいサービスをゼロから作るためには、市場調査やユーザーヒアリングをしてこういうサービスならお客さまに喜んでいただけそうだ、というアイデアを企画書にまとめます。サービスの骨格が固まった段階で、今度は開発を担当する部署やベンダーに時間とコストを見積もってもらいます。そして話がまとまれば開発がスタートし、1年とか1年半といった長い時間をかけてでき上がったサービスを市場に投入する。これが従来のビジネスのやり方でした。
しかしこのやり方には、大きな問題点が２つあります。１つは「時間」です。今の時代、１年前に決めた仕様をめざしてものを作っても、市場は日々動いています。その間にユーザーが一度も触っていないものが、ユーザーに喜ばれるものになるはずがありません。もしかするとそれ以前に、他社がもっと良いものを出してしまっていることだってあるわけです。
もう１つは、「ビジネスと開発」の分断です。ビジネスのアイデアを形にするには、開発のための仕様書を作らざるを得ませんが、これによって開発側は仕様書を形にすることがものづくりの目的になってしまいます。つまり仕様書に向かって仕事をすることになるわけです。本来はビジネスも開発も、ユーザーに向かってものを作らないと本当に支持されるサービスや製品なんて作れるはずがないのに、仕様書と契約によって「ビジネスと開発の分断」が起き、ユーザー不在のものづくりが進行してしまう。これでは、クラウドやAIなど新しいテクノロジーを効果的に取り入れるといったこともできなくなってしまいます。
SI業界の多くの方は経験されていると思いますが、この分断は開発の後半になると、必ず費用やスケジュールでもめることになるのです。それは「あの機能が入っていると思っていたけど入ってない」とか、「この機能がないのはあの時こう言われたからで、それは理解していただいたはずです」といったビジネスサイドと開発サイドの不毛な争いが起きて、みんなの「やる気」と「工数」が果てしなく「調整」に使われる。こういう事態は珍しいことではありません。
ではアジャイルの場合どう考えるのかというと、開発はビジネスの中のものであり、ビジネスの中にたまたま開発やITがある。めざすべきは、ビジネスが成功するかどうか、ビジネスが顧客を喜ばせられるかどうかであり、そのためにビジネスと開発は一体になって取り組むということを前提にします。ただし、ビジネスが答えを持っているわけではありません。答えを持っているのはユーザーだけです。仕様書は答えではない。だからできるだけ早い段階でユーザーに使ってもらえるものを作り、そのフィードバックを次に生かしながらその時点で一番イケてる仕様で開発を進めるのがアジャイルです。
DXとアジャイルの親和性
例えばウォーターフォールという従来型のやり方では、仕様書に365個のやるべきことがあれば、その365個を１年間かけて作ります。最初に全体を分析し、設計して、実装してテストになるわけですが、大体テストの時にうまくいかないということになります。それは実物が見えない中で計画だけを頼りに開発を進めていて、肝心のユーザーが不在だからです。
アジャイルでは、この365個を全部作るかどうかはわかりませんと最初に宣言してしまいます。その上で、365個に１番から365番まで番号を付けるのです。そして１番大事、２番目に大事、３番目に大事という順番をつけて、優先度の高い7個を1週間で動くものにしてテストをします。そこでまた優先度の高い7個を決めて、動くものを作ってテストをする。これを繰り返してある程度のものができたら、ユーザーやそれに近い外部の人に実際に使ってもらいます。そこで生のフィードバックをもらい、それをベースにまた残りの358個の優先順位を決めて、動くものを作ってテストというサイクルを繰り返していきます。
ウォーターフォールのプロジェクトだと、もうガチガチに決められた仕様書で進めていきますから、あとから入ってくる情報は有効活用できません。プロジェクトが進行し、情報が増えるのは後半で、あとから入ってくる情報というのは重要な場合が多いのですが、それを聞き入れることができません。変更に保守的なウォーターフォールは、価値ある新しい情報を怖いものとして扱ってしまうのです。
一方アジャイルでは、アップデートされた一番新しいリストを元に1週間で動くモノを作ってテストというサイクルを繰り返しますから、ユーザーのフィードバックなど新しい情報はすぐに開発に反映されます。このやり方であれば、「時間」という問題も「ビジネスと開発の分断」という問題も、自然に解決されることがおわかりいただけると思います。
アジャイル開発や「スクラム」では、そのために毎日「朝会」を開いてチーム全員の状況を確認し、1週間の成果を「ふりかえり」でみんなが議論してあれこれと意見を出し合いながら、プロセス改善を行っていきます。これが重要で、言われたことをただやるのではなくて、アジャイルという開発手法に自分たちの意見やアイデアをどんどん取り入れていくことで、チームとしての成長とエンジニアとしての成長を同時に実現することが可能になる。それもアジャイル開発の特徴です。
今、DXというトレンドでアジャイルが再び注目されている理由、それはビジネスとITを一体化しなければDXは絶対に実現しないからです。時間をかけて仕様書を作るよりも、課題を解決するために作るべきものに優先度をつけて、動くものでユーザーのフィードバックをもらい、それを土台に答えを組み上げていく方が、正解やお手本のないDXには近道だということが共通認識になったからだと思います。何より、実際にそうなんですから。
平鍋 健児（ひらなべ けんじ）
株式会社 永和システムマネジメント 代表取締役社長、株式会社チェンジビジョン 代表取締役CTO、Scrum Inc.Japan 取締役。1989年東京大学工学部卒業後、UMLエディタastah*の開発などを経て、現在は、アジャイル開発の場、Agile Studio にて顧客と共創の環境づくりを実践する経営者。 初代アジャイルジャパン実行委員長、著書『アジャイル開発とスクラム 第2版』（野中郁次郎、及部敬雄と共著） 他に翻訳書多数。
『アジャイル開発とスクラム 第2版』
著：平鍋健児 野中郁次郎 及部敬雄
発行：翔泳社（2021年）
PDF形式のファイルをご覧になるには、Adobe Systems Incorporated （アドビシステムズ社）のAdobe Acrobat Readerが必要です。
