アジャイルしてますか？

マイナンバーや全銀ネットなど、いわゆるITゼネコンの関わる巨大プロジェクトにおいて、システム障害や不具合発生が相次いでいる。

その原因を、多重下請け構造やSIerにおけるPMやSEの人材の劣化、あるいはウォーターフォール開発という方法論そのものに求める人もいる。

本記事では、どちらかと言えば発注側として実際にシステム開発系プロジェクトに関わるビジネスパーソンに向けて、システム開発系プロジェクトの現状と、プロジェクトが頓挫するリスクを削減するためのアイデアについて取り扱う。

ウォーターフォール開発の過去と現在

ウォーターフォール開発は、もともとIT黎明期において、建設業のプロセスを参考に組み上げられたアプローチである。

建設物を作るにあたっては、事前の調査→設計→製造といったように、基本的に後工程に進んだプロセスが前の工程に戻ることはない。当然である。（基礎を打ったあとで、やっぱり高さを二倍にしたいなどと言われてもどうしようもない。）

このようなプロセスをソフトウェア開発にも流用し、設計→実装→各種テスト→納品といったステップを、基本的に前工程に戻ることなく一直線で行う、というのがウォーターフォール開発である。

ウォーターフォール開発は、今ほどインターネットが発達していなかった時代、オンプレミスのサーバーを利用していた時代は非常に都合がよかった。

（一度フロッピーやCD／DVDといったメディアの形式で出荷してしまえば、なにかしら不具合が発生した場合には修正パッチの開発から出荷といったベンダー側の対応コストは当然として、その後ユーザー側としてインストール済の端末すべてに対してアップデートを手動で実行していく必要があるなど、対応コストは膨大になる。）

一方で現在では、もはやインフラにクラウドを利用していない企業は存在しないと言って良いほどにクラウドが浸透している。

ソフトウェアはインストール方式であってもアップデートがインターネット経由で配布されることが当然となっており、そもそもユーザー側でのインストールやアップデートの作業が不要になるSaaS形態での提供も一般的になっている。

そのような状況では、万が一の不具合発生時も、ベンダー側／ユーザー側ともに対応のコストは極めて小さい。

また、かつてのようにオールインワンの重厚長大なシステムを利用するのではなく、モジュールごとに最適な製品を組み合わせ、一気通貫のワークフローは維持しつつも、各業務においてはそれぞれ最適なツールを利用することでより一層の業務効率化を図る、という考え方も一般的になりつつある。

アジャイル開発とは

そのような背景から、かつてオンプレミス前提・重厚長大かつ、手戻りが許されないソフトウェアの開発において一定の理があったウォーターフォール開発も、アメリカやヨーロッパ等の先進国だけでなく、アジア等の途上国（とはいえITにおいてはむしろ先進国と言えるが）においても、もはや方法論自体が時代遅れとみなされ、ほぼすべての開発はアジャイルで行われているそうである。

むしろ、世界でも日本だけが、ほぼ唯一と言っていいほどに頑なにウォーターフォール開発を行っている、というのが現状とも言える。

プロジェクトマネージメントの教科書とも言えるPMBOKにおいて、最新の第7版ではついにアジャイル開発を前提とした内容に全面刷新された、と界隈がざわついたのも記憶に新しい。

簡単に言ってしまえば、ウォーターフォール開発の思想が「起こりうる出来事を事前にすべて想定し、すべての想定しうる事態に対応できるよう、転ばぬ先の杖をひたすらに積み重ねる」であるとするならば、アジャイル開発は「今必要なものだけを作り、何か問題があれば直せばよい、必要なものが増えたらまた作れば良い」という思想である。

VUCAの時代とも言われ、市場の変化が著しくスピードアップした現在、歴史ある企業であっても時代の変化に追従することが不可欠であり、また国としてスタートアップ投資に本腰を入れようとしている現在、高速に仮説検証を繰り返し、筋がよいアイデアが見つかればそこに全力投球するという、いわゆるリーンスタートアップ的な方法論ともアジャイル開発は非常に相性がよい。

また、レガシーシステムのリプレイスにおいても、「どのような操作に対し、どのような結果が得られるべきなのか」というシステム要件さえはっきりしていれば、要件に優先順位をつけ、内部処理の完全互換にはこだわらず、あくまで結果の互換性のみを担保する前提であれば、アジャイル開発は非常に有用である。

このような背景から、アンテナの高いビジネスパーソンが、ウォーターフォール開発を時代遅れのものとみなし、アジャイル開発を持ち上げることも当然であると言え、いまだウォーターフォール開発を行っているような組織は実力がない、と切って捨てるのも理解できる。

アジャイル開発は銀の弾丸なのか

では果たして、ウォーターフォール開発を駆逐し、あらゆる開発をアジャイルで行うことで、システム構築系のプロジェクトの遅延や頓挫を減らすことはできるのだろうか。

残念ながら、筆者はそうは思ってはいない。

すでに記憶が薄れつつある人も多いかとは思うが、マイナンバーや全銀ネットのシステム障害より以前、大きな話題となった政府系システム開発プロジェクトの障害を覚えているだろうか。

そう、「新型コロナウイルス接触確認アプリ（COCOA）」である。

COCOAはもともと、オープンソースソフトウェアの開発等に関わっていた有志により開発され、その後GoogleやAppleの方針（COVID-19に関する接触検知アプリ等は、1カ国につき1つのみ公式に認める）によって政府のプロジェクトに転換された背景がある。

そのCOCOAであるが、実際には接触検知の機能そのものが長期間動いていなかったなど、不具合が発生して問題となった。

もともとがオープンソースの開発者たち有志のプロジェクトであるから、開発体制は当然アジャイルだが、それでもマイナンバーや全銀ネットのように失敗したわけである。

もちろん、たった一つの反例をもって「アジャイル開発に意味はない」などと言うつもりはない。

ただ筆者の経験上、「スピーディに必要な機能をリリースするため、アジャイル開発を採用」と触れ込んでスタートしたプロジェクトが、ウォーターフォールに比べ成功率が明確に高い、とは到底感じられていないというのは事実である。

プロジェクトを円滑に進めるために

アジャイル開発は銀の弾丸ではない。

それでは、プロジェクトを円滑に進めるためにはどうすればよいのか？

そのためには、方法論としてのアジャイルを表面的に取り入れるのではなく、組織にアジャイルの精神を根付かせることが必要である。

なんだか禅問答のようだが、そもそも、ウォーターフォール開発には正しいプロセスが存在するが、「アジャイル開発」に定形のフォーマットは存在しない。

もともとアジャイル開発は、2001年に、ソフトウェア開発のエキスパート達が提言した「アジャイルソフトウェア開発宣言」の精神をもとに、そのコンセプトを実現するため作られたスクラム開発やエクストリームプログラミングといった方法論による開発の総称である。

アジャイルソフトウェア開発宣言を一部引用する。

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

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

契約交渉よりも顧客との協調を、

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

価値とする。

すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

つまり、アジャイル開発を行うためには、契約したベンダーだけがスクラム開発等の方法論で開発を進めるだけでは不十分で、発注側のクライアントも、同じ目的でもってプロジェクトに向き合う必要がある。

ベンダー側が個人と対話／動くソフトウェア／顧客との協調／変化への対応を重視していたとしても、（特に、プロジェクトにおける決定権を持つ）クライアント側がプロセスやツール／包括的なドキュメント／契約交渉／計画の遵守を重視しているのであれば、それはアジャイル開発ではなく、単に計画性なく闇雲に開発を進めるだけのプロジェクトにしかならないのである。

組織をアジャイルにするには

言い換えれば、アジャイル開発がその真価を発揮するためには、組織そのものがアジャイルである必要があるということである。

では、組織をアジャイルにするためには何をすればよいのか？

そのために、アジャイルソフトウェア開発宣言にあるように「個人と対話／動くソフトウェア／顧客との協調／変化への対応」を重視するようにすれば組織はアジャイルになるのだろうか？

筆者個人の見解ではあるが、アジャイルソフトウェア開発宣言は、もとが欧米のエンジニアによる提言であることもあり、極めて重要な前提が記載されていないように感じている。

それはすなわち、目的意識と優先順位である。

欧米のビジネスにおいてはジョブディスクリプションが極めて明確であるため、自明の理として略されているのかもしれないが、日本においてはその前提を明確に強調しておかなければ、ミスリードが発生するように感じる。（個人との対話や顧客との協調など、日本のビジネスパーソンが最も重視していることであろう。）

つまり、例えば営業マンであれば、自身のミッションは「利益の拡大」である。

「担当する顧客との良好な関係性」は「利益の拡大」を実現するための手段である。

この目的意識がブレなければ、ソフトウェア開発における優先順位を議論する際にも「ユーザーには運用変更の手間を強いることになるが、たとえそれが原因でユーザーが離れてしまったとしても、それを上回るコスト削減効果がある」として建設的な議論が可能になる。

逆にこの目的意識が曖昧だと、「自身が担当しているユーザー（売上額としてはさして大きくない）がこの機能がないと業務が回らないと言っているから機能として必須」のような判断が入り込み、結果的にイレギュラーな運用に至るまですべてシステムで代替する、といった非現実的な要求が発生し、調整は難航する。

基本的にプロジェクトの期間は動かせないことが大半であるから、要件の調整に時間を食えば実装やテストにかけられる時間は減り、結果的にシステムの品質が下がることになる。

まとめ

アジャイル開発は、少なくともウォーターフォール開発に比べれば、時流に乗った開発スタイルであると言える。

しかし、その真価を発揮するためには、参加メンバー全員が同じ方向を向いていることが必要である。

そのためにはまず、開発ベンダーとの関係性以前に、自社のプロジェクトメンバー内で、プロジェクトの目的と、優先順位についての認識をすり合わせておくことをおすすめしたい。

また、社内メンバーだけでは喧々諤々の議論はしづらく、結果的にあまり目的や優先順位の認識が合わないままプロジェクトを開始してしまっている、などのお悩みがあれば、弊社での支援も可能なため、お問い合わせ頂きたい。