なぜ企業は大規模開発を選択してしまうのか #プロジェクト管理

「『アジャイル vs ウォーターフォール』からプロジェクト管理を考える」という記事にてウォーターフォールであっても分割すれば問題は解決するかもしれないという話を書きました。しかし、プロジェクトの分割は現実にはなかなか難しいのも事実です。分割すればプロジェクトの成功率が上がるのことは明らかに見える（そしてアジャイル開発を導入するよりも変化に対応するコストをかけなくてよいという利点がある）にも関わらず、なぜ企業は大規模開発を選択してしまうのでしょうか。

今回もちょうどよい論文がないか探してみたのですが……探し方が悪いのかぜんぜん見つかりません。¹ そこで、この記事では私の業務システム開発の過去の経験から「なぜプロジェクトの分割が難しいのか」という理由を列挙したうえで、解決策を考えてみたいと思います。

なぜ、プロジェクトの分割は難しいのか

システム間連携が多すぎる

特に業務系基幹システムにはその傾向がありますが、システムの連携機能が数十どころか数百あることも珍しくありません。プロジェクト対象のシステムをリプレースする場合には、そこに繋がっているシステム全体に影響がないように移行する必要があります。

単に連携先の切り替えだけの話であれば、分割しての移行も可能ですが、支払や在庫のようにトランザクションの状態が重要な場合には、旧システムと新システムを並行稼動させることは困難になります。実際には連携方法の変更（例：FTP から SFTP）であったり、項目の変更も同時に行われることになりますので、新システムから新旧ふたつのレイアウトでファイルを出力するようなことも必要になるかもしれません。

予算枠の調整が難しい

企業が情報システムを作るということは投資をすることに他なりません。投資に対する効果を元に予算枠を決め、その中で実施する必要があります。プロジェクトを分割するということは、後回しにする部分については予算枠が決められないということになります。

最終的に分割前のプロジェクトで計画された内容すべてを実現しないと効果が出ない（例えば、旧システムの維持に大きなコストがかかっており、新システムに完全に切り替わらないとメリットがでない）場合には、最終的な着地点が見えないと予算枠の申請ができなくなってしまいます。

また、予算枠が先に決める必要があるなら、金額、期間を達成する責任を開発ベンダーに負わせる一括請負契約を選択する以外の選択肢は難しくなります。

リリース日の調整が難しい

特に業務システムでは、会計年度や繁忙期との兼ね合いで、ユーザー側がテストできる期間やリリースできる日程に制限があることがよくあります。ハードウェアやミドルウェアの保守期限のため、現行システムを維持できる期間にも限りがあるかもしれません。このような状況では、プロジェクトを分割したところでリリース日は変わりません。これでは、プロジェクトを分割する意味は薄れてしまいます。

プロジェクト期間がベームの法則（工数の立方根で決まる）に従って決まるとされています。この場合、工数を半分にしたところで期間は20%程度しか短縮できません。例えば 100人月、標準工期 11ヶ月のプロジェクトを分割し50人月、工期5.5ヶ月の2プロジェクトとしたいところですが、標準工期はそれぞれ9ヶ月までしか縮まりません。この場合、開始が2ヶ月ずれた9ヶ月間のスケジュールが並走するだけということになります。これでは、むしろプロジェクトを分割したことによる影響（2回移行やリリースが必要など）の方が心配になってきます。2ヶ月しかずらせないのなら、リリース日をまとめてしまおうと考えるのは自然なことです。

利用者、利用部署への周知・教育が難しい

あまり重要でない機能を分割してリリースするのであればともかく、主となる機能が徐々に新システムに切り替わっていくというのでは、利用者側もどちらのシステムを使えばいいのかわからなくなってしまいます。

新システムの導入を推進する情報システム部的な立場であれば、一度の通知、教育で済ましてしまいたいと思うのは当然でしょう。

どうやったら分割できるのか

業務の違いで分割する

業務の種類が異なればデータの接点も少なくなることが期待できます。業務の違いでサブシステム化し、サブシステムごとに独立性を持たせることで、プロジェクトを分割するという考え方ができます。

とはいえ、これも言うは易し行うは難しです。すでに現行システムが大規模でモノリシックな作り方になっている場合は、サブシステムを独立させても徐々にリリースさせるということが難しいため、次のシステム更改ではプロジェクトを分割できても、今のプロジェクトを分割することは難しいでしょう。

開発という側面でも難しさがあります。まったく必要がないにもかかわらず、データベースを分割したり、マイクロサービス化したり、など、システムを複雑化させてしましまうかもしれません。疎結合になるというメリットが得られても、マスタ情報の配信・同期が必要になったり、分散トランザクション制御が必要になるのでは、プロジェクトの難易度が跳ね上がってしまいます。

機能性の違いで分割する

分析系と登録系の機能で分割するのもひとつの考え方です。登録系のシステムでは、データ反映のリアルタイム性が重要な役割を果たしますが、分析系のシステムではそこまでセンシティブではありません。登録系機能の設計・開発を優先し、分析系機能の設計・開発とは切り離すことは可能です。

最近では、Google BigQuery や Amazon Redshift、Snowflake といった BI 用データベースが簡単に構築できるようになり、PowerBI、Tableau、QuickSight のようなツールで簡単に集計・加工できるようになりました。分析系はいったんそれらのツールにお任せすることにすれば、登録系機能の開発に注力できます。

しかしこの考え方にも難点はあります。一般に業務設計ではアウトプットの分析こそが重要です。分析系機能の設計なしに登録系機能を設計することができるのか悩ましいところです。

工程で分割する

要件定義～基本設計で全体の設計を行いプロジェクトの分解点を明らかにした上で、詳細設計以降、プロジェクトを分割し実行するという考え方もあります。

開発側としては合理的ではありますが、要件定義～基本設計というフェイズを分割して契約することが前提となります。それでも、すべてを準委任の元でアジャイル開発するよりは現実的な解決策となるかもしれません。

もし知っていたら教えていただけると幸いです。 ↩