アジャイル開発の誤解とは（前編）
クラウドネイティブNow
廣石 真也
富士通株式会社
ソフトウェアプロダクト事業本部 アプリケーションマネジメント事業部
マネージャー
はじめに
私は1998年に現在の会社に入社してから、ソフトウェア製品の開発に長年携わってきました。最近ではアジャイル開発に取り組むプロジェクトに関わることも多くなりましたが、アジャイル開発はその特徴から多くの誤解があり、アジャイル開発に失敗するプロジェクトも多く見てきました。
本特集では、まずはアジャイル開発が登場する背景として従来のソフトウェア開発の実態を説明し、アジャイル開発で陥りやすい誤解について解説します。前編では、アジャイル開発の誕生に至る経緯からアジャイルソフトウェア開発宣言に記された4つの中核となる価値について解説し、後編ではアジャイルソフトウェア開発宣言の背後にある「12の原則」とアジャイル開発の本質およびアジャイル開発と技術について解説します。
従来のソフトウェア開発
我々、ソフトウェア開発者は、常に限られた予算（工数）と厳しい納期の中で開発が求められ、なるべく高機能で高品質な機能を開発するために、新たなツールの活用などで開発作業の効率化に日々取り組んできました。
しかし、ソフトウェア開発者の方はご存じのとおり、一言で開発作業と言っても外部設計・内部設計・開発（コーディング）・単体テスト・結合テスト・統合テストに加え、回帰テスト・性能検証・セキュリティー検証・特許侵害調査などの各種検証作業、それらの検証が正しく実施されていることを実施履歴（エビデンスと呼ぶ）や帳票を基にした開発責任者への説明など、組織で定めた開発ガイドラインに則りながら、チェックリストで作業漏れが無いか確認して各種作業を実施します。これにより、ソフトウェア開発は開始してから開発したものを実際にリリースするまで、開発量が少なくても数ヶ月かかることは珍しくありません。
また、これまでのICT活用は人間が手作業で実施していた作業をICTに任せて効率化するような活用がほとんどで、ICT化された後の状態は比較的に想像しやすいものでした。しかし、モバイルやクラウドによってICTが身近なものになったことでICTに求める顧客ニーズは多様化し、ICTを活用した新たな業態が既存の業態を脅かす（注1）など、ICT活用により実現した最終的な状態を想像するのはとても難しくなっています。
このような状況に対し、ソフトウェア開発者は今まで以上に難しい開発が求められ、依頼元から「期待したものと違う」として賠償問題となるようなリスクが高まりました。
ICTベンダー企業（SIer）が顧客企業から開発を受注する場合、ICTベンダー企業は開発を受注する際に契約書で受注する条件を明確化することに今まで以上に時間をかけ、受注側が責任を持つ範囲を明確にして開発開始後の依頼元の期待との乖離が無いように対策します。特に日本は、ICTベンダー企業（SIer）が顧客企業から開発を受注する場合が多いため、企業間の賠償問題・信頼問題となるリスクが高いため、尚更に契約交渉に時間をかけることになりますが、企業内のシステム開発においても、ビジネスオーナーに予算を交渉する企画書の執筆に時間をかけることになります。
一方で、開発したシステムや製品を利用してビジネスするビジネス側の人は、数ヶ月たってリリースされたものに満足できず、開発部門に改善要望を出しても、改善されたものがリリースされるのが更に数ヶ月かかることに対し、開発部門に不満を持つ現場も少なくないのではないでしょうか？
このような背景からICTに対する期待の高まりに反して、契約に時間をかけたり、厳格な規律に従うような従来のソフトウェア開発は重量ソフトウェア開発と呼ばれるようになりました。
-
注1ウェブブラウザーの先駆けであるNCSA MosaicやNetscape Navigatorを開発したアメリカ合衆国のソフトウェア開発者であるマーク・アンドリーセン（Marc Andreessen）氏が「ソフトウェアが世界を飲み込む（Why Software Is Eating The World）」と表現しています。
アジャイル開発（agile software development）の誕生
1990年代の後半に重量ソフトウェア開発に対するアンチテーゼとして、軽量なプロセスで開発を進める軽量ソフトウェア開発を提唱・実践する人が登場し、ScrumやXPなどが登場します。
そして、2001年に17名の軽量ソフトウェア開発の専門家達が集まり、それぞれがもつ開発方法やさまざまなソフトウェア開発へのアプローチについて議論する会議を開きました。そこで、共通点や相違点についてどこまで合意できるか確認しあった結果、お互いが同意した方向性に「アジャイル」という言葉を選択したのがアジャイルの始まりと言われています。
会議に参加した1人であるアリスター・コーバーン（Alistair Cockburn）氏の書籍「アジャイルソフトウェア開発」によると、会議で同意したことは以下の4つだと記されています。
-
変化に対応する必然性
-
4つの中核となる価値
-
12のより詳細化された原則
-
同意の不在
アジャイル開発を語る上で、1つ目から3つ目についてはよく取り上げられます。しかし、あまり取り上げられない4つ目の「同意の不在」がアジャイル開発の本質を語る上で重要である反面で、アジャイル開発がどういったものかを捉えるのを難しくしています。顧客のニーズが多様化して最終形が想像し難くなった状況になったのと同時に、ソフトウェアを開発するやり方についてもそれぞれの現場で異なっているのが当たり前です。このため、開発のやり方は同意のしようがなく、むしろ同意できないことを同意したのが「同意の不在」です。詳細なやり方まで同意しようとすると、やり方を統一しようという動きになり、更に良い取り組みがあっても、それに取り組むことを拒むことになってしまい、進化を止めてしまうことになりかねないと考えたのです。
誤解① アジャイル開発には決まった形がある
アジャイル開発には決まった形がありません。そもそもアジャイル開発は、上述のようにScrumやXPなどの開発方法が先にあり、それらの開発方法の共通の価値と原則をまとめたものなので、アジャイル開発には決まった形がありません。ツールやプロセスもアジャイル開発を採用する組織により選定することになります。
アジャイル開発を採用しようとした場合、まずは作ろうとしようしているもの、それを開発しようとする組織によって、どのようなアジャイル開発が適しているかを考えることからはじめる必要があります。
アジャイル開発は「Don't just Do Agile, Be Agile」と表現されるように、アジャイルは特定のプロセスを実施するのではなく、アジャイルのマインドセットを持つ状態になることだと言われます。
ちなみにDigital.ai社が公開する「15th Annual State Of Agile Report（Digital.ai社のウェブサイトへ）」では、アジャイル開発を実践する人の66%がScrum開発を採用していると報告されています。アジャイル開発を実践する際には、まずはScrum開発を参考にするのが良いと思います。
4つの価値（4 values）
2001年に軽量ソフトウェア開発の専門家達が合意した『4つの中核となる価値』は「アジャイルソフトウェア開発宣言（Manifesto for Agile Software Developmentのウェブサイトへ）」に以下のように記載されています。
1）プロセスやツールよりも個人と対話を／Individuals and interactions over processes and tools
日本語訳では個人との対話が重要であるように読み取れますが、英語原文を見ると分かるように重要なのは「個人」であり「対話」であるということです。
組織で決められたプロセスやツールに従うより、関係者個人の意志・感情・スキルを重要視し、関係者間での密な対話によるコミュニケーションを重要視しましょうということです。
決められたプロセスやツールを使うことに縛られ過ぎてしまうと、変化へのチームの対応力が低下し、顧客のニーズを満たすことができなくなります。
誤解② 無駄と思うプロセスを省いて良い
特に開発経験の浅いソフトウェア開発者は、従来から必要性が分からないプロセスを組織として強いられ、非生産的な作業に嫌気が差している人も少なくありません。このようなソフトウェア開発者が「このプロセスやツールよりも個人と対話を」を無駄と思うプロセスは省いて良いと拡大解釈してしまいがちですが、あくまでも「プロセスやツール」も重要であるが、それよりも「個人と対話」の方が重要だと述べているだけなので、プロセスやツールを疎かにしてはなりません。
組織で実施が求められているプロセスやツールには、過去の色々な経緯から経験豊富な先輩方が利用を決めたプロセスやツールなのです。それを自分だけの判断で無駄だと決めつけるのはアジャイルの考え方に反します。
組織で定めたプロセスやツールを無駄だと現場の開発者（個人）が感じることは非常に重要な感情のため放置せず、既存のプロセスやツールの利用を決めた先輩達と対話し、本当に自分が現在担当する開発で必要なのか、別のプロセスやツールでもっと効率的に実施できないかを議論するのがアジャイル開発として正しい姿勢です。
2）包括的なドキュメントよりも動くソフトウェアを／Working software over comprehensive documentation
ソフトウェア開発者は事前に開発することすべてを網羅的にドキュメントに書いて合意を得ることを重視するのではなく、実際に動くソフトウェアを作って顧客が求めているものかを確認することを重視しようというものです。
ジョナサン・ラスムッソン（Jonathan Rasmusson）氏の書籍『アジャイルサムライ －－ 達人開発者への道』では、「さて、君が信頼に足ると判断するのは次のどちらのチームだろうか？実施計画書や大量の製品文章、作業報告書を納品してくれるチーム？それとも、一番大事だと君が思う機能を実装して、テスト済みのソフトウェアとして毎週必ず届けてくれるチーム？」と読者に問いかけています。
顧客ニーズが多様化する現在においては、詳細で緻密な計画書を示しても、計画どおりに実装したものが期待したものと異なることはよくあります。詳細な動作を記した包括的なドキュメントを作っても、変化する顧客ニーズに対応するためにはすぐに実装を作り直す可能性があり、ドキュメントをすぐに書き直す必要が発生してしまいます。
一度実装したものは最終的に別のソフトウェア開発者が障害修正などの保守作業を行うことはよくあるため、保守のためにドキュメントが必要と考える人もいるでしょう。しかし、ソースを見れば分かるようなことを構成設計書に詳細に記載しても、過去に作られた構成設計書は更新されずに信頼できない資料として放置されている状況をソフトウェア開発者の皆さんであればよく経験しているのではないでしょうか？これは、障害があった際に本来は構成設計書とソースを合わせて修正すれば良いですが、障害修正は早期対処が求められるため構成設計書の更新よりも早く修正を作ることが求められるためです。
また、UMLなど誰でも伝わる書式で設計書が書かれていれば良いですが、他人の作った設計書は作成者それぞれが好みのフォーマットで作成してしまうことも少なくありません。前任者の好みで作られた設計書を、その好みを後任者が理解して資料を更新するのは大変であるため、どうしても設計書の更新は疎かになるのです。このように構成設計書が更新されずにソース修正が繰り返されると、構成設計書には過去の情報が記載された信頼できない資料となってしまいます。
このため、全体的に網羅的なドキュメントを作るよりも、一番大事な機能の品質を確保して短サイクルで提供し、ビジネス側の人からのフィードバックを得ることが重要だと言うのです。
誤解③ ドキュメントは作らなくても良い
開発経験の浅いソフトウェア開発者ほど、動くものを早く実装したいと考えます。経験不足のため、実装後のイメージが想像できず、設計書を書いてもレビューで多くの指摘を受けて設計に時間がかかるため、「包括的なドキュメントよりも動くソフトウェアを」という価値を拡大解釈し、ドキュメントを作らず実装をしようとします。
しかし、一度実装したものを作り替えるのは時間がかかります。作り替えが多いほどスケジュールが遅延します。開発経験の浅いソフトウェア開発者ほど問題が多い実装を作るリスクは高く、作り替えが発生する可能性が高まります。この時に有効なのがドキュメントです。不確かな実装イメージをドキュメントで示し、実装前にチーム内でレビューしてフィードバックをもらうことにより、実装後の作り替えリスクを減らすのです。作成するドキュメントは全体的に網羅的に作るよりも、過不足無く最小限のものを作るのが効果的です。
3）契約交渉よりも顧客との協調を／Customer collaboration over contract negotiation
「従来のソフトウェア開発」で述べたように顧客ニーズが多様化する現状では、依頼元から「期待したものと違う」として賠償問題となるようなリスクを伴いますが、これに対して契約交渉で作るものを最初に合意するというリスク回避手段を取ってしまうと、顧客ニーズの変化への対応力を低下して本来の顧客が求めるものが提供できなくなります。
自分の立場を契約で守るのではなく、事前に顧客と最終形をイメージすることが難しい開発となることを理解していただき、一緒に難しい課題に取り組むことが重要であるということです。
4）計画に従うことよりも変化への対応を／Responding to change over following a plan
顧客ニーズが多様化する現状では最初に計画したことが必ずしも正しいとは限りません。このため、最初に立てた計画に従うよりも顧客と協調して顧客ニーズの変化に柔軟に対応することが本当に顧客に価値あるソフトウェア開発につながるということです。
誤解④ 計画は守らなくても良い
顧客ニーズが多様化して最終的な完成形がイメージし難いため、「計画に従うことよりも変化への対応を」を計画どおりに進まなくても難しい開発をしているから仕方が無いと考えがちです。
しかし、後編で説明する12の原則にある「動くソフトウェアを、2週間～3週間から2ヶ月～3ヶ月というできるだけ短い時間間隔でリリースします。」のように、動くソフトウェアを短い間隔で提供して顧客からフィードバックを得るためには、2週間～3週間で何もかもを終わらせることは難しいため、大きな課題を小さくシンプルな課題に分解して優先順位が高いものから提供します。
2週間～3週間でリリースしたものが顧客の求めるものと異なれば、次の2週間～3週間で実装するものは当初想定していたものから変えるべきですが、短い間隔でリリースが必要となるということは短い間隔で顧客との約束を守る計画が必要となります。このため、アジャイル開発を実施するソフトウェア開発者には、2週間～3週間で動くソフトウェアを提供するという厳しいスケジュール管理が求められます。
前編では、アジャイル開発の誕生に至る経緯からアジャイルソフトウェア開発宣言に記された4つの中核となる価値について解説しました。後編ではアジャイルソフトウェア開発宣言の背後にある「12の原則」とアジャイル開発の本質およびアジャイル開発と技術について解説します。
関連製品・サービス
当社が提供するデジタルトランスフォーメーションを支えるアプリケーションサーバー「FUJITSU Software Enterprise Application Platform」の詳細は下記ページをご覧ください。
当社が提供するDX実現の課題にお応えするハイブリットITサービスの詳細は下記ページをご覧ください。
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ
Webでのお問い合わせ
当社はセキュリティ保護の観点からSSL技術を使用しております。
