ITエンジニアが経験を通して感じた
アジャイル開発成功のポイント

lead

政府が推進するデジタルトランスフォーメーション（DX）という概念に対する企業の取り組みが定着してきています。そしてITシステム開発においても、従来の「ウォーターフォール開発」から「アジャイル開発」へプロセス改革が行われようとしています。
私は幸運なことに両者の開発手法を使ったITシステム開発を行い、成功体験を得ることができました。今回はその経験を振り返り、これからアジャイル開発を始めようとされている方に少しでもお役に立てるよう次のような目次で書いてみました。最後までお付き合い頂けますと幸いです。

１．アジャイル開発とは？

ITシステムの開発は、長い間、「ウォーターフォールモデル」という開発手法で進められてきました。
これは、ITシステムの開発に必要な要件の定義から始まり、システムの設計、製造、検査と、まさに水が滝を流れるようにプロセスを順に行う開発手法になります。
「ウォーターフォールモデル」では、ITシステムに求める要件を最初にしっかりと固め、要件に沿って設計を行い、設計に基づいてプログラムを開発、正しくプログラムが動作するかの検査を行います。工程ごとにチェックポイントがあるので、進捗率を把握しながら確実にITシステムを開発することができます。
反面、「ウォーターフォールモデル」は要件の確定からサービスリリースまでに長期間を要することが大きな欠点となります。このため昨今の変化の早い市場環境やITシステムに求められる要件の多様化についていけないという問題点も抱えています。
そこで近年、使われ始めたのが「アジャイル開発」です。2001年頃に提唱された『アジャイルソフトウェア開発宣言』を踏まえ、ビジネス環境やITシステムに対するニーズの変化にスピーディに追い付くために、より早く、より効果的にITシステムを開発する手法として「アジャイル開発」が生まれました。

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

私たちは、ソフトウェア開発の実践、あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイル開発では、ITシステムに必要とされる機能や処理を"スプリント"という短い期間に区切り、"スプリント"の中でITシステムの開発に必要なプロセスを進めていきます。
開発するITシステムの一部を少しづつ完成させ、最後に全体を結合してITシステム全体を作り上げます。
このため、ITシステムの主要な機能や処理、画面を早い段階でユーザー（顧客）が確認することができ、ニーズに沿ったITシステムを開発することができます。
また、スプリントを複数、並行で動かすことで、ウォーターフォールモデルと比較すると短い期間でITシステムを完成させることもできます。

２．アジャイル開発が活用されない理由

世の中の情勢や経済活動の動きが早くなっている中、ITシステムが企業活動に欠かせない存在になっていることを考えると、アジャイル開発が従来のウォーターフォールモデルに置き換わってもおかしくありません。
しかし、2020年に一般社団法人 日本情報システムユーザー協会が行ったアンケートを見ると、新たなITシステム開発の80%が従来のウォーターフォールモデルによる開発になっています。アジャイル開発はまだまだ活用が進んでいないことがわかります。
この理由を、アジャイル開発はITシステムの本質的な価値を導くために、ユーザー（顧客）とITベンダーが一体となって取り組まないと実現できない開発手法だからだと私は考えます。

逆に言うと、ユーザー（顧客）とITベンダーが一体となって取り組めば、ITシステムの価値を最大限にすることができるとも言えます。
ITシステムの価値を最大限に引き出すための取り組みはユーザー（顧客）にとってはもちろん、ITベンダーにとっても喜ばしいことだと思いますが、なぜアジャイル開発が活用されていないのでしょうか？
ウォーターフォールモデルとアジャイル開発の両方の開発手法を経験した立場から考えてみたいと思います。

■アジャイル開発に必要な独自知識、経験の必要性

アジャイル開発とひと口に言っても、さまざまな手法があります。代表的なものとして「スクラム」や「エクストリーム・プログラミング（XP）」、「ユーザー機能駆動開発（FDD）」などですが、これらの手法を使うためには基本的な知識や、やり方を理解しておく必要があります。
中でも有名なものは「スクラム」で、その手法は書籍やWebサイトで多数紹介されていますが、知識だけで取り組むのと、実際のプロジェクトで取り組むのでは雲泥の差があります。
「AであればBをおこなう」のようなロジカルなものではなく、日々、もしくは一瞬一瞬で変化していくものに道筋を立てて進める必要があります。決められた通りに進めるのがプロジェクトマネージャーの役割ですが、アジャイル開発では困難な状況に対し、あらゆる道筋を作り、またその道で壁が発生してもまた新たな道筋を作る強い牽引力も必要になります。
また、ITシステムの開発を"発注"する側であるユーザー（顧客）もITベンダーと一体となって開発に取り組むため、専任体制が必要になったり、ユーザーにおいても成果物に責任を持つ覚悟が必要になることもアジャイル開発が活用されない原因のひとつではないかと考えます。

■ITシステムの品質確保

アジャイル開発では、品質指標を定義するのが難しいと言われています。
ウォーターフォールモデルでは、最初に機能要件や設計をすべて行うため、開発者が作成すべきもののボリュームが明示されます。それをもとに開発するので、機能漏れ、設計ミス、プログラム不具合などを上流プロセスで発見することが可能です。
一方、アジャイル開発では、機能を部品化し、徐々に機能を作り上げていきます。極論になりますが、最終的にITシステム全体でどんな機能に仕上がるかはやってみないとわかりません。大枠では機能要件をイメージしておきますが、その通りにならないことも許容しなくてはなりません。そのため、責任の所在がどこにあるのかがわかりづらい状態になることも起こり得てしまいます。 もっと具体的に言うと、進めていく中でユーザー（プロダクトオーナー）と機能や品質を握りながら進めるのがアジャイル開発です。そのため、基本的に品質責任はユーザー側に発生することが想定されます。ユーザーの立場で考えると、問題や課題はITベンダーが負うべきと考えるのが普通ですので、品質指標が明確で、ユーザーとITベンダーの役割と責任が明確なウォーターフォールモデルが多く採用されているのだと思います。

■アジャイル開発の基本は準委任契約

アジャイル開発では、ITベンダーが品質責任を負うことが難しいとされています。そのため、アジャイル開発を行う場合、多くの場合は事前に成果物を特定せず、ITベンダーが有する知見やノウハウをユーザーに提供する"準委任契約"で取り組むのが一般的です。これが日本の企業文化に合わないのではないかと思っています。
これまでのITシステム開発においては、ユーザー（顧客）とITベンダーの役割と責任が明確な"請負契約"が主流でしたが、準委任契約になることでユーザー（顧客）で多くの責任を持つことになります。

どんな企業でも、ITシステムを開発するためには社内で予算を調達し、経営幹部の承認が得られなければ進めることはできません。先にも触れましたが、アジャイル開発ではコストやスケジュール、ゴールの姿を定義するのは難しいことに加え、「先が読めない」「コストがどのくらいかかるか見えない」ようでは承認を取り付けることは難しいと思います。
このようなことから、アジャイル開発はユーザー（顧客）での承認を得られず、ウォーターフォールモデルでITシステムを開発することが多くなっていると考えます。

３．アジャイル開発に向いているITシステム開発、向いていないITシステム開発

ITシステムの価値を最大化できる可能性を秘めるアジャイル開発ですが、「２．アジャイル開発が活用されない理由」 で述べたように活用するにはユーザー（顧客）、ITベンダーともに壁があるのが実態だと思います。 この"壁"を乗り越えたとして、もうひとつ考えなければならないことがあると私は考えています。 それは、アジャイル開発が向いているITシステム開発と向いていないITシステム開発があることです。 アジャイル開発には、どのようなITシステム開発が向いているのか、向いていないのか、一般的に言われていることに加え、私が実際にアジャイル開発に携わった経験から考えてみたいと思います。

■アジャイル開発が"向いている"ITシステム開発

アジャイル開発の最大の特徴は、ユーザー（顧客）とITベンダーが一体となってITシステム開発に取り組むことと、スプリントと呼ばれる"区切り"で開発プロセスを並行で進めることです（スクラム開発の場合）。
この特徴を活かせるITシステム開発は

• 要件が曖昧だったり、ニーズの変更が多いITシステム
• 短期間で稼働させなければならないITシステム

の２つだと考えます。
１点目の「求める要件が曖昧、ニーズ変更が多い」は、例えば、ITシステムの利用者が複数部門にまたがっていたり、優劣を付け難い複数のシステム要求がある場合などが該当すると思います。
２点目の「短期間で稼働させなければならない」は、ビジネス環境やビジネスニーズの激しい変化に、ITシステムも追随していく必要があるケースが該当します。

私は、数年前にある企業の財務管理システムをWeb化するリニューアルのプロジェクトに携わりました。 このプロジェクトは、100もの画面を新規に開発する必要がありましたが、期間は5ヶ月しかないといった非常に難しいものでした。おまけに、プロジェクト開始段階では画面の仕様が決まっておらず、開発しながら要件を決めていかねばならない状況でした。
当時はアジャイル開発の経験がなかったため、ウォーターフォールモデルでスケジュールを立てましたが、画面の仕様確定を待ってから開発しようとすると、すべての作業（要件定義、設計、開発、テスト）を五月雨式に、かつ多くの作業を並列に進めなければならない無謀な計画しか立てることができませんでした。
そこで、当時は未経験だったアジャイル開発を採用してみました。結果、ITシステムに求められる要件やニーズを満たした上で、期間内でITシステムの稼働まで漕ぎ着けることができました。しかし、もしウォーターフォールモデルで開発していたら、「機能を定義したのにITシステムに求める要件が変わってしまった」、「プログラムの開発が終わっているのに機能が追加になった」などで開発プロセスをやり直す"手戻り"が多く発生していたと思います。その結果、コストは増加、ITシステムは期間内に稼働できないといった事態に陥っていたと容易に想像できます。

■アジャイル開発が"向いていない"ITシステム開発

私は、アジャイル開発の経験が多いこともあり、「アジャイル開発に向いていないシステム開発は無い」のではないかと考えていますので、「アジャイル開発でなくても良い」という視点で考えたいと思います。
この考えに立つと、「アジャイル開発に向いているITシステム開発」の逆が「アジャイル開発に向いていないＩＴシステム開発」だと考えます。
つまり、

• ITシステムに求める要件がしっかりと固まっていて、ニーズの変更は無いITシステム
• 期間を気にしないで開発できるITシステム開発

と言うことになります。少し皮肉めいた表現になってしまいましたが、アジャイル開発に向いていない≒アジャイル開発で無くても良いと考えると、上記の条件を満たすITシステム開発ということになります。
いまはVUCAの時代といわれ、世界情勢やビジネス環境は変化の速度を増しサービスのライフサイクルの短期化が進んでいます。さらに新型コロナウイルスにより、先行きも不透明さを増しています。厳しいビジネス環境に対応するためのひとつの解決先としてITシステムを活用することが企業にとって必要不可欠になっていることを考えると、「ITシステムに求める要件やニーズがしっかり固まっている」、「時間を掛けてITシステムを開発する」ことは、もはや非現実的になりつつあるのではないかと私は感じています。

４．アジャイル開発でITシステム開発を成功させるポイント

ITシステムの開発においては、アジャイル開発を活用しなければならない時代に突入していると私は考えていますが、アジャイル開発で失敗してしまうケースも多く耳にすることも事実です。
そこで、私が経験したアジャイル開発のITシステム開発プロジェクトを振り返り、プロジェクトの成功に寄与したと考える要因を成功ポイントとして話したいと思います。

■全体スケジュールを把握しておく

アジャイル開発においては、直近のタスクを短期間で完了させていくので、全体スケジュールというのはあまり必要ないのではと思う方が多いようです。しかし、アジャイル開発においても全体像の把握はとても重要で、細かいスケジュールでなくても、中工程レベルのタスクを時系列で把握しておくことは必要だと考えます。

■5つのスクラムイベント※はどんなときも必ず実施する

スプリントプランニング、デイリースクラムなど、何度も実施していくと慣れてしまい、時間がないときなどではどうしても優先度を落としてしまうことが起こります。 忙しい時には、「今日は忙しいからデイリーはやめよう」と考えてしまいがちですが、どんなに忙しくても、5分でもよいので、ミーティングを開催するというルールを徹底することが重要です。忙しいからと一度でも手を抜いてしまうと、なし崩し的にイベントを減らしてしまうことに陥ることが多く、プロジェクトが失敗する要因になってしまいます。

※５つのスクラムイベント
1. スプリント 2. スプリントプランニング 3. デイリースクラム 4. スプリントレビュー 5. スプリントレトロスペクティブ

■振り返り（レトロスペクティブ）は"KPTG"で

スクラムでは、次のスプリントに行く前に必ず今回の振り返りを実施します。
振り返りでは、プロジェクトメンバー全員に「今回のスプリントはどうだったか？」、「課題は？」などについてスクラムマスターが主導して進めることが多いかと思います。しかし、どうしても１つの課題で時間を取られたりして、長時間になりがちです。
そこで、"Keep（続けたいこと）"、"Problem（問題点）"、"Try（次やってみたいこと）"、"Good（よかったこと）"の4つを"KPTG"として一人ずつコメントして貰うことでスムーズに、漏れなく振り返りを行えるようになります。
"KPTG"の中でも特に重要なのは、「Good」だと思います。今回のスプリントで、「これよかったね！」、「●●の考えたこの資料とても分かりやすかった！」とチーム内で良かったことをたくさん出すことです。問題点はすぐに出るものですが、よかったことは意識しないと出てきません。また、恥ずかしくて言えないこともあります。チームメンバーを称賛するクセをつけることで、目標達成にもつながります。

■プライベートの時間を共有できるとチーム力は向上

プロジェクトはチームでやるものだというのは、アジャイルに限らず誰もが感じていると思います。 しかし、常に仕事のことばかりを共有していても、チームは一つにはなりません。重要なのはプライベートの時間の共有です。例えば、「今日どうしても友人と会いたいから早く上がりたい」「今日はパートナーの誕生日だから、午後からお休みがほしい」というプライベートな時間をチーム力で補うというところです。これは本当に効果が出ます。「前回自分が休ませてもらったから、今回は彼の時間を何とかしてあげよう」という気持ちが芽生えます。つまり、仕事のサポートだけでなく、プライベートの時間もサポートすることで、チーム力は強固なものになります。