システム開発の方法について
１．システム障害の多発
ここのところ大きなシステム障害のニュースが続発しています。みずほ銀行では2021年2月末からシステム障害が続発し、2週間の間に4回のシステム障害を起こす事態となりました。みずほ銀行は2002年と2011年にも大規模なシステム障害を起こしており、ご記憶の方は「またか」と思われたかもしれません。また、新型コロナウィルスの接触確認アプリ「COCOA」ではAndroid版に不具合があり、2020年9月から接触の通知が行われない状態となっていたことが分かりました。
多くの方にとってシステムは「正しく動いて当たり前」なのに対し、情報システム部門に在籍する方や、業務としてシステム開発や運用に関わっている方は、正しく動かすことの難しさを痛感していると思います。ある程度のファジーさが容認される人間と比べ機械はちょっとしたプログラムミスでも全ての動きを止めてしまいます。こうしたシステム開発の難しさに対応するため、システムの開発にあたっては方法論が発達してきました。
２．ウォーターフォールとアジャイル
一番有名で古くから使われてきた方法論はウォーターフォールモデルと呼ばれる方法です。
【ウォーターフォール】
システムに求める要件を定義し、概要を設計し、詳細を設計し、プログラムを開発して、テストを行っていくというステップを踏むもの。それぞれの段階ごとにチェックと承認を設けることで間違いのないシステム開発を行う方法。あらかじめ全行程の計画を立てて実行する方法と言え、水が各ステップを流れ落ちるように進んでいくことからウォーターフォールと名づけられた。
ウォーターフォールモデルは長きにわたって多くのシステム開発を支えました。この方法には、ステップごとに確実にチェックポイントを設けられるので社内手続が取りやすい、全体像から詳細へ流れていくので手戻りが少ない、といった長所があります。一方で短所としては、最初に決めたことを後で変えるのが大変という点が挙げられます。変化の少ない環境で使われるシステムであれば良いのですが、変化が激しい環境にさらされるシステムだと、開発期間中に条件が変わってしまうことはざらにあります。そこで編み出されたのがアジャイルという方法論です。
【アジャイル】
大きな単位でシステムを開発するのではなく、小さな単位で設計・開発・テスト・実装を繰り返してシステムを作っていく方法。より素早い開発、柔軟性の必要とされる開発に向いている。
アジャイルの定義は少し分かりにくいのですが、例えば翻訳アプリを例にとると、最初は英語と日本語だけの翻訳機能でアプリを公開、その後に中国語やフランス語を追加し、音声認識を追加するという具合に、最初の設計には無かった機能を随時追加したり、あるいはAndroidやiOSといったOSの更新に合わせて随時アプリのアップデートを行うといった用途に向いている方法です。ウォーターフォールで開発する場合には最初から多言語で設計する必要があり、リリースまでに長い期間がかかりますが、アジャイルだと短い期間・最小限の機能で一旦リリースし、あとで機能追加していくことも可能です。こうした柔軟性とリリースの速さはアジャイルの大きな長所と言えます。
３．アジャイルの誤解
柔軟で速いと聞くとアジャイル万歳と思ってしまいますが、残念ながらアジャイルについて多くの誤解も存在しますし、アジャイルは適用方法を誤ると危険な方法でもあります。
誤解１ アジャイルだと要件定義や設計がいらない
アジャイルでも要件定義や設計は必要です。ウォーターフォールのように段階的に確定させていくわけではなく、一度作った要件定義や設計を柔軟に見直すことができるだけです。
誤解２ アジャイルだとドキュメンテーションがいらない
これも大きな誤解です。段階的リリースのような複雑な工程になるからこそドキュメントはしっかり作らないといけません。ドキュメントをないがしろにすると、設計や作業の共有が不十分になり、アジャイル開発はあっという間に混乱します。むしろドキュメンテーションが随時更新されていくのがアジャイルです。
誤解３ アジャイルだと開発が速い
表現が難しいところですが、アジャイルを採用すると開発が速くなるとは一概には言えません。同じ能力の人が開発すれば同じだけ時間がかかります。ただしアジャイルの場合はリリースできる部分からリリースしていけるので、最終形に達するまでにはウォーターフォールと大して変わらない時間がかかるとしても、最小限の機能のリリースは速くなるとは言えます。
内部事情は分かりませんが、接触確認アプリ「COCOA」の障害などは、こうしたアジャイルの誤解に由来するのではと感じます。コロナ対策で急ぎでリリースし、随時更新していく点ではアジャイル開発がぴったりなシステムですが、アジャイル
であれば頻繁にテストが行われるはずです。アジャイルが正しく適用されていれば何か月も基本機能が使えていなかったというのは考えにくく、アジャイルだからステップを省略できるという誤った理解があったように感じています。
４．より良いシステム開発のために
アジャイル開発の肝はコミュニケーションの質と量です。「考えてから走る」ウォーターフォールでは考えた結果を決められたポイントで確実に開発メンバーに伝えればそれで済みますが、「考えながら走る」アジャイルでは、刻々と変わっていく要件や設計を常時メンバーと共有しなければなりません。そのためにはドキュメンテーションをしっかり行い、頻繁に会議を設定する必要があります。情報に取り残された開発メンバーがプログラムを作ると、そこでシステムが停止しかねません。こうした複雑な情報共有を分かりやすくするためには、タスクや情報を管理できるツールも必要です。そうした管理があってこそ、アジャイルは柔軟性という強みを出せます。ウォーターフォールより楽という誤った理由だけでアジャイルを採用すると、システム障害への道をまっしぐらといっても過言ではありません。
また、アジャイルが良くてウォーターフォールがダメということは決してありません。安定的な環境でのシステム開発には工程管理がアジャイルよりシンプルなウォーターフォールのほうが向いていることも多いです。優劣ではなく適材適所の問題と言えます。
一方で、ウォーターフォールでの開発の難しさに、結果が最後まで分からない点があります。実際に、最終的にシステムがうまく動かなかったり、求めていた機能と違っていたりといった経験のある方も少なくないと思います。大きなプロジェクトほど開発途中でのネガティブ情報は隠されがちです。私も、開発の遅れや予算超過懸念、バグ情報などを現場では認識しているものの、プロジェクトリーダーへの報告では大本営発表になってしまうケースを幾度も見てきました。こうしたネガティブ情報は、たいてい最終局面でシステム障害として表に出てきます。
従って、ウォーターフォールで大規模なシステム開発を行う場合、正しい情報がしっかり報告されているかを監視するべきです。日本ではあまり事例を見ませんが、具体的にはプロジェクト監査でそこを見ることができます。ネガティブ情報の把握や報告状況、プロジェクト目的と実情がズレていないかといった点を監査・報告し、いわばプロジェクトリーダーや社長にとって第3の目となります。プロジェクト監査自体がシステム開発を早めるわけではないものの、膨大な費用が掛かるシステム開発においては十分に正当化されうる必要コストと言えます。（作成日：2021年3月25日）
■執筆者：株式会社ビズサプリ 代表取締役 三木 孝則