大規模ソフトウェア開発のために発注者側が押さえておきたい７つのコツ【2024年最新版】

ソフトウェア開発は、納品物が上がってくるまでなかなか途中のイメージがつかみにくく、信頼できる発注先業者と良好なパートナーシップが確立できていたとしてもどこかで不安を感じてしまうものです。
ましてや、工期が数ヵ月単位、規模が数百万以上のプロジェクトともなれば、発注から納品までのプロジェクト全期間にわたって不安を感じるのももっともだと言えるでしょう。

この記事では、最初に大規模ソフトウェア開発の失敗例を参照して発注側、開発側がソフトウェア開発の経験を積んでいたとしても、プロジェクトマネジメントに失敗すればプロジェクトが崩壊するという実例を特許庁の失敗例を事例に考察します。

そして、特許庁の事例を教訓として、プロジェクトマネージャーおよびプロジェクトマネージャーを組織的に支えるPMO（プロジェクトマネジメント・オフィス）の役割の大切さを確認します。

さらに大規模ソフトウェア開発を成功させるための注意点を、プロジェクトマネジメントの標準的書籍と言われる「PMBOK」を参照しながら整理していきます。

「PMBOK」では、プロジェクトを「総合管理」「スコープ」「時間」「コスト」「品質」「人的資源」「コミュニケーション」「リスク」「調達」「ステークホルダー」の項目に分けて整理しています。
この９つのプロジェクトマネジメントの共通概念・用語を整理して理解することによって、見えてくる大規模ソフトウェア開発の実際の成功ポイントを具体的に解説します。

大規模ソフトウェア開発は予算的にも工期的にも失敗の許されないプロジェクトです。
大規模開発の怖さ、PMOおよびPMOの役割、世界標準の教科書の概要、成功のポイントなどを知り、大規模ソフトウェア開発プロジェクトに自信を持って着手できるようにしましょう。

それでは、まず大規模ソフトウェアを発注する時の注意点から見てみましょう。

大規模なソフトウェア開発とは下記の４つの特徴を持っています。

大規模ソフトウェア開発は、短期の開発と違ってこのような特徴を持ちますので、場合によっては思うようにプロジェクトが進まずに頓挫してしまうこともあります。
こうしたプロジェクトの失敗は、発注側にもソフトウェア開発の外注を何度も経験した経験を持つ担当者がいたり、開発側も大手企業であったりした場合でも生じる場合があります。

例えば、特許庁が2004年に特許審査や原本保管といった業務を支援する基幹系システムの全面刷新を計画して結局プロジェクトが空中分解してしまった例があります。
システムアーキテクチャーに詳しい情報システム部門の職員が発注を担当し、開発企業はIBMというケースでした。

発注側も開発側も問題がなさそうに見えてもプロジェクトが頓挫する、というのは意外な感じもすると思いますので、最初にその例を見て、大規模プロジェクトの難しさについて確認しておきましょう。

特許庁のソフトウェア開発はなぜ失敗したのかですが、あとから振り返ってみると致命的ないくつかの失敗要因が浮かび上がってきます。

■ 設計会社と開発会社が別だった
この大規模開発の失敗の原因としてまず目につくのはプロジェクトがねじれているということです。
このプロジェクトの基本設計から詳細設計までを行ったのはIBMでした。
しかし基本設計から詳細設計までのコーディングを落札したのは東芝ソリューションだったのです。

■ キーマンである特許庁担当者が突然の異動
開発を引き継いだ東芝がスケジュール通りに開発を進められないなどの問題が明らかになっていく中、発注側担当者が責任を取らされて異動となってしまいます。

■ 開発が始まってからの仕様書の変更
東芝の開発がうまくいかないので、IBM仕様書を破棄して途中から現在稼働しているシステムベースに設計をやり直しました。
東芝では急遽人員の大幅増などで対応しようとしたがうまくいかずに現場が大混乱に陥りました。
強力なリーダーシップを持ったプロジェクトマネージャーの不在、プロジェクトマネジメント・オフィスの機能不全などが指摘されます。

■ ほどなくプロジェクト頓挫
このプロジェクトでは、発注側の担当者が異動になったり、プロジェクトの仕様がプロジェクトスタート後に変更になったりと首尾一貫しないプロジェクト体制が問題として指摘されました。


決して大企業に発注したから大丈夫というわけではなく、プロジェクトマネジメントに失敗すれば、経験を積んだ開発会社であってもこうした取り返しのつかない事態を引き起こしてしまうということを肝に銘じておきましょう。

ソフトウェア開発ではどんな規模であれ開発側の窓口担当者、プロジェクトマネージャー（PM）の役割が非常に大きくなってきます。
特許庁の失敗例を見て分かるように、とりわけ大規模なプロジェクトを成功させるためには、プロジェクトマネージャーに高い能力や経験、スキルが求められます。

窓口担当者やプロジェクトマネージャーの資質が重要なだけでなく、プロジェクトマネージャーをサポートする要員や体制（PMO－Project Management Office、プロジェクトマネジメント・オフィス）が必要となります。

プロジェクトマネージャーはプロジェクトの進捗管理を果たす要の存在ですが、大規模プロジェクトにおいてはたった１人のプロジェクトマネージャーにすべての権限や進行管理の責任が集中してしまうことは危険です。

PMOは、プロジェクトマネジメント方式の標準化を図り、優秀なプロジェクトマネージャーただ１人に負担がかからないようにプロジェクトを組織的に円滑に回していくための施策を実施します。

プロジェクトマネージャーの業務が属人化してしまうと、万が一プロジェクトマネージャーが途中で何らかの理由により業務を継続できなくなった場合にプロジェクトが空中分解してしまう危険性もあります。
こうした属人化を防ぐために、PMOはプロジェクトネージャーに求められている業務について組織で対応します。

発注側にとってプロジェクトマネージャーとの十分なコミュニケーションや、プロジェクトマネジメント・オフィスとの情報共有は、大規模ソフトウェア開発プロジェクトを成功させるために欠かせないものです。
プロジェクトマネジメントを開発会社に丸投げすることをせずに、積極的にプロジェクトの進捗管理の情報共有を進めていきましょう。

「PMBOK」とは「A Guide to the Project Management Body of Knowledge」の頭文字を取った言葉です。
内容はアメリカの非営利団体PMI（Project Management Institute）がまとめたプロジェクトマネジメントのガイドラインです。
世界中で参照されており、事実上プロジェクトマネジメントの標準となっています。
4年に一度オリンピックが開催される年に改訂版が発行され、常に最新の問題に対処できるようにアップデートされています。

「PMBOK」の内容概略は下記のようになっています。多くのプロジェクトマネジメントで使用される言葉や、暗黙の前提となっていますので、プロジェクトマネジメントを成功させるには押さえておきたい基礎知識です。
特に大規模プロジェクトを考えているときには、必ず一読しておくことをおすすめします。

「PMBOK」という言葉そのものが出なくても、PMやPMOメンバーは「PMBOK」の内容を把握した上でプロジェクトの運営を行っています。
標準的なプロジェクトマネジメントのドキュメントを参照しておくことで、より開発側とのコミュニケーションが円滑になることが期待できます。

大規模ソフトウェア開発を実施する際には、過去に似たような事例がないかをできる限り調査することが大切です。
見積もりの規模を測るために行うのではなく、失敗例を探して自社が行おうとするプロジェクトの反面教師とするためです。

もちろん発注候補の開発会社に「失敗例を教えてください」と質問しても自社の失敗例をオープンに語る担当者はいません。
この場合、失敗例はウェブサイト上で公開されているもので構いません。
ただし、ただ漠然と失敗例の情報を斜め読みするのではなく、下記の点についてメモを取るなどしてその内容を自社内で共有しておきましょう。

冒頭に挙げた特許庁の例で分析すると下記のようになるでしょう。

大規模システムの開発プロジェクトでは、発注側、開発側を含め、プロジェクトに関わっている人員、部署の間で意思疎通、コミュニケーションが十分に取られていることが大切です。

もちろん、プロジェクトマネジメントにおけるコミュニケーションとは、にこやかに雑談をするといったレベルのことではありません。
共通の問題意識を持ち、共通の問題を確認し、共通の課題確認の方向を向いているということが大切です。

この共通の問題意識を持ち、共通の問題を確認し、共通の課題確認の方向を向くために必要な重要基盤がソフトウェア開発のプロジェクトマネジメントにおける「標準化」です。

発注側のキーマン、開発側のプロジェクトマネージャー、開発現場でリーダー的存在のスキルの高いエンジニアなど、個人の能力が高いに越したことはありません。
しかし、大規模なプロジェクト開発を成功させるには、そうした属人的な能力に依存しない、標準化されたマネジメントの導入が必要です。

これは、開発側に限ったことではありません。
開発側は大規模ソフトウェア開発の経験豊富なプロジェクトマネージャーを抜擢するだけでなく、プロジェクトマネジメント・オフィスを導入すべきですし、発注側も１人の担当者がすべての外注管理を行うのではなく、プロジェクトチームを作ってチームとしてソフトウェア外注プロジェクトをマネジメントすべきです。

こうした体制を組むことで、属人化を脱してプロジェクトが「標準化」されていきます。

発注側、開発側双方が共通の問題意識を持ち、共通の問題を確認し、共通の課題確認の方向を向くために必要な「標準化」については「PMBOK」を参照することをおすすめします。

大規模システムの開発プロジェクトは半年から数年がかりで完成するといったスパンで行います。
当然、当初想定していた以外のリスクが浮かび上がってきたり、工期が遅れたりといった事態も生じてきます。

現場レベルでは、想定していなかったリスクには対処できませんので、新たなリスクは表立って議論されないままであることが多いです。
また工期の遅れも「なんとか次のフェーズで挽回する」といった対症療法でしか解決できません。

こうした現場レベルの無理が積み重なると、最終的にプロジェクトそのものが足元から崩壊します。

また、現場だけに任せておくと、現場はもうこれ以上持ちこたえられない、という最悪の事態を迎えたときになってようやく「無理です」という報告をしてくる傾向にあります。

こうならないためには、計画の変更見直しを含めて意思決定ができる「プロジェクトコントロール・チーム」を設置することが大切です。

プロジェクトの意思決定者である発注側の責任者、発注側企業の管理職、開発側のPM、PMO責任者らが定期的な会議を開き、プロジェクトの実態を踏まえて問題の早期発見と是正策を実施していくなど、適切にプロジェクトをコントロールしていくことが大切です。

スコープとは、ここからここまでの「範囲」という意味です。
範囲を限定しないことには、プロジェクトのスタートも終わりもありません。例えば、「営業マンが便利だと思うシステム」というあいまいな範囲の区切り方では、開発側も何を作ってよいのか分かりません。
「営業マンが手作業で行っている、社内のCRMから優良顧客を選別して、リスト化するシステム」のように、明確に開発の「範囲」を区切ることで、プロジェクトのスコープははっきりしてきます。

このように、スコープはプロジェクトマネジメントにおけるそのプロジェクトが最終的に生み出す「成果物」＝「納品物」を指します。
また、最終的な納品物だけでなく、途中段階の「仕様書」「設計書」「計画書」や開発各段階の「中間的な完成品」もスコープとなります。

つまり、スコープとは各段階の「完成品」であり、その完成品を作るためにどんな人材が関わり、誰が責任を持ち、どのようなリソースを投入すればよいかという、部品化されたプロジェクトだと言えます。

大規模ソフトウェア開発プロジェクトでは、こうした部品化された完成品は多岐にわたります。
そして、部品化された完成品が相互に複雑に影響し合いますので、１つの部品＝スコープの完成が達成できないとやがてプロジェクト全体に深刻な影響が出てきます。

例えば、先程の「営業マンが手作業で行っている、社内のCRMから優良顧客を選別して、リスト化するシステム」というスコープであれば、部分スコープである「データベースから優良顧客を選別する」が完成しないと、最終的に営業マンに渡す「リスト化」はできません。

冒頭に検討した特許庁の大規模システム開発の失敗例では、こうした部分的なスコープがうまく機能せず結局プロジェクト途中で仕様書全体を書き換えるという、信じられないような場当たり的な対応が取られてプロジェクトそのものが立ち行かなくなりました。

プロジェクト全体のスコープを見直すという、プロジェクト失敗の一歩手前に至る前に、プロジェクトの部分的なスコープを見直すことが重要です。

大規模システムの開発プロジェクトでは部分的なスコープが複雑に絡み合ってきます。
例えば、２つの小規模なスコープの間で、その部分的なシステムを結びつけるインタフェースが必要であるとプロジェクトの中で認識されたとします。

こうした場合に、現場でありがちなのは、２つの小規模なスコープをなんとか改良しようとして無駄な努力をしてしまうことです。

ここで本当に必要なのは、２つの小規模なスコープを連結するという「中工程計画」の実施です。
小工程の内部で問題を無理やり解決しようとして、その小工程が完成しないために、もっと大きなスコープを見直さざるをえない（プロジェクトの頓挫）ケースに陥ることが一番問題です。

そうなる前に、中規模のスコープを上手に見直してプロジェクト全体の調整を早めに行いましょう。

大規模システム開発プロジェクトでは、ソフトウェアの開発部分だけでなく、クライアントコンピュータやサーバー、ネットワーク機器などのシステム資源（リソース）が膨大な数に上ってきます。

また、広い意味で開発会社の外注先から上がってくる小さな範囲のスコープの納品物もリソースの一部となります。

ハードウェアや、外注されたソフトウェアなどのリソースが、どのタイミングでどのくらい必要であり、そのリソースがそろわないことによって、プロジェクトの進行にどれくらいの影響が出てくるのかなど、システムリソースの管理は大規模ソフトウェア開発プロジェクトの成功の必須要因です。

これまでの成功のポイント１から成功のポイント６までは、いわば「大規模プロジェクトを大規模プロジェクトとして成功させる」手法でした。

番外編の７として、大規模プロジェクトを細かいプロジェクトに分割して小さく完成形をリリースさせていく方法を見てみます。
これは、大規模プロジェクトをやめてプロジェクトの規模を小さくせよ、と言っているわけではありません。

そうではなくて、全体のプロジェクトを多数の納品可能なプロジェクトに分割し、１回の開発期間を短く設定した上で、その１回の完成型を発注者とともに検証し、次回に必要な要件の優先順位を組み替えて、次のプロセスに移るという「アジャイル開発」の検討のすすめです。

「大規模プロジェクトを大規模プロジェクトとして成功させる」手法においても、スコープを小さく分割し、スコープの見直しを進めたり、中規模スコープを上手に活用したりすることによってプロジェクト全体の調整を上手に行っていこうとするテクニックをご紹介しました。

この場合、個々の小さなスコープに着目しますが、小さなスコープや中規模スコープを調整することによって、最終的なスコープである１つの大きな「納品物」を予定通り納品するということには変わりありません。

アジャイル開発では、この「最終的な納品物」という考え方そのものをなくします。

「営業マンが手作業で行っている、社内のCRMから優良顧客を選別して、リスト化するシステム」という例を再び取り上げて考えてみましょう。

「大規模プロジェクトを大規模プロジェクトとして成功させる」手法では、顧客の選別段階でシステムがうまく組めないと、リスト化ができないのでプロジェクトが頓挫するという考え方をしました。
最終的な納品物として1つしか考えていないからです。

アジャイル開発では「社内のCRMから優良顧客を選別するシステム」を完成形として納品します。
当然このシステムに関する請求と支払い処理も実行されます。それと同時に、次のプロジェクトを考えます。
その際に「選別した顧客をリスト化するシステム」を次のゴールとしてもよいですし、先に「社内のCRMから優良顧客を選別するシステム」をさらに精緻化したシステムを次のゴールとしてもよいのです。

「社内のCRMから優良顧客を選別するシステム」も、当初の予定していた形ではまだ営業マンの希望を満たしていないことが使ってみて判明した。
しかし、選別システムがまったくなかったときよりは営業マンの手作業は少なくなったので、営業現場はかなり効率化された。
こうした改善された状況を享受しつつ、次の新しい課題として、「選別した顧客をリスト化するシステム」ではなく「社内のCRMから優良顧客をさらに高度に選別するシステム」を課題とするという柔軟なプロジェクトの決定ができるのです。

製品を投入しようとしている市場の変化が激しかったり、プロジェクトの成果物が次々の進化していきそうだったりする場合には、アジャイル手法で大規模ソフトウェア開発を小さく分割してリリースしていくという方法も有効ですので、ぜひ開発方法検討の中に加えてみましょう。

いかがでしたでしょうか。
ソフトウェア開発では、プロジェクトを進めていくうちに当初の計画通りいかない部分が出てきます。
特に大規模システム開発プロジェクトの場合には、計画通りいきそうもないという兆候に気がついたとしても、現場レベルではそれを途中で修正、改善していくことが困難な場合があります。

そうした事態を避けるために、属人化を脱した組織的で標準化されたプロジェクトマネジメントノウハウが必要となってきます。
大規模ソフトウェア開発では経験・ノウハウの豊富な業者を選ぶことはもちろんですが、プロジェクトが進行したあとでも、柔軟にプロジェクトを調整し最終的なゴールまで導くノウハウを蓄積した業者を選ぶことがポイントです。
そうした業者選びは公式サイトなどの情報だけでは難しいので、ぜひ「アイミツ」にご相談ください。
業界での評判などを含めて、大規模ソフトウェア開発に柔軟に対処し、最終的なゴールに至るまで安心して任せることのできる開発会社をピックアップいたします。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。