システム開発会社を
お探しですか? PRONIアイミツを使って手間なく最良の会社と出会いましょう

システム開発発注は初めてですか?

PRONIアイミツは最適な出会える
ビジネスマッチングサービス
です

システム開発
無料で一括見積もり
0120-917-819 平日10:00-19:00

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

更新日:2024.01.24

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

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

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

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

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

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

大規模なソフトウェア開発を発注するときの注意点

地球とキーボード

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

大規模プロジェクトの特徴

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

大規模ソフトウェア開発の特徴
  • 1年以上の長い開発期間
  • 数千万円以上の大きな費用
  • 発注側、開発側ともに多くの関係者が関与すること
  • プロジェクトが複雑なこと

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

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

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

大規模ソフトウェア開発失敗の原因

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

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

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

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

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


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

大規模プロジェクトを失敗しないためのPMとPMOの役割

PMに求められる高いスキルと経験

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

プロジェクト全体の意思決定のサポートをする役割
  • 発注側とヒアリングを重ね、規模・予算・人員・スケジュールなどを決定させる
  • 発注側の要件を明確化して設計に落とし込む
  • 途中で顧客の要望が変更になった場合などにはスケジュールや対応能力を見極めて迅速に対応する
プロジェクトを円滑に進行・管理する役割
  • 顧客の要望や決定事項をプロジェクトチーム全体に伝える
  • チーム単位や工程単位ごとに進捗管理を徹底する
  • スケジュールの作成・更新・管理をスムーズに実行する
クライアントとのコミュニケーションを推進する役割
  • プロジェクトの進行状況を分かりやすく顧客に伝える
  • 顧客と常にコミュニケーションを取りヒアリングを重ねる
  • 必要に応じて開発部門との会議をセッティングする

PMOに求められるプロジェクトマネジメントの組織的対応

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

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

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

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

PMOの役割
  • プロジェクト運営の事務局としての機能
    全体会議、運営委員会(ステアリングコミッティ)、進捗会議などの管理運営
  • プロジェクトの基準、標準の策定
    開発プロセスの整備、ドキュメントの策定、コミュニケーションの促進
  • 各種指標の基準値作成、収集、評価とクライアントとの共有
    進捗率、品質指標、各工程での指標のサマリーや整理、状況の把握と評価をしてクライアントと共有します

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

プロジェクトマネジメントの標準「PMBOK」を知っておく

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

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

「PMBOK」の内容概略
  • 「プロジェクト総合マネジメント」
    プロジェクトマネジメント各種プロセスの関連性を見極め、調整や意思決定を行うための指針が解説されています。
  • 「プロジェクトスコープ・マネジメント」
    プロジェクトを成功のうちに完了するために必要な作業を抽出するための指針が解説されています。
  • 「プロジェクトタイム・マネジメント」
    スケジュールのコントロールを行うための指針が解説されています。
  • 「プロジェクトコスト・マネジメント」
    見積策定、予算化、予算実績対比など予算管理をするための指針が解説されています。
  • 「プロジェクト品質マネジメント」
    品質計画、品質保証、品質管理の3つのプロセスを実行することで、一定以上の品質を保つための指針が解説されています。
  • 「プロジェクト人的資源マネジメント」
    プロジェクトメンバー間の交流の促進、役割の見直し、またモチベーション向上のための施策を行う指針が解説されています。
  • 「プロジェクトコミュニケーション・マネジメント」
    プロジェクトメンバーが効率的かつ効果的なコミュニケーションが図れるよう支援するための指針が解説されています。
  • 「プロジェクトリスク・マネジメント」
    時間、コスト、スコープ、品質などのプロジェクト目標に影響を与える不確実な事象、リスクに対応するための指針が解説されています。
  • 「プロジェクト調達マネジメント」
    作業に実行に必要なプロダクト、サービス、所産を調達するための指針が解説されています。
  • 「ステークホルダーマネジメント」
    プロジェクト全体の利害関係者とのコミュニケーションや、意思疎通の円滑化、利害関係の調整などを行うための指針が解説されています。

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

大規模ソフトウェア開発を成功させるためのポイント

キーボードとペン

成功のポイント1 ~事例調査でリスクを事前把握する

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

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

開発プロジェクト失敗例の分析視点
  • プロジェクト全体に無理は見られなかったか
  • 想定していなかったリスクとしてプロジェクトスタート後に何が浮かび上がってきたか
  • プロジェクトスタート後に発覚したリスクに対して適切に対処できたか
  • 失敗事例で明らかになったリスクに対して自社で対応することは可能か

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

失敗例の分析例
  • プロジェクト全体に無理は見られなかったか
    ⇒ 設計した会社(IBM)と開発に取り掛かった会社(東芝)が違っている。
  • 想定していなかったリスクとしてプロジェクトスタート後に何が浮かび上がってきたか
    ⇒ IBMの設計した仕様書を東芝が開発できないことが分かった。
  • プロジェクトスタート後に発覚したリスクに対して適切に対処できたか
    ⇒ 設計通りにできないことが分かり、設計自体を破棄してしまった(適切に対処できたとは言えない)。
  • 失敗事例で明らかになったリスクに対して自社で対応することは可能か
    ⇒ プロジェクトの開始前、開始後などさまざまな段階についてシミュレーションを行い話し合ってみましょう。

成功ポイント2 ~現場の計画に標準化を導入

電卓とペン

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

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

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

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

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

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

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

成功のポイント3 ~プロジェクトコントロール・チームを機能させる

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

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

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

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

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

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

成功のポイント4 ~プロジェクトのスコープ(範囲)を見直す

会議中の風景

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

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

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

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

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

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

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

成功のポイント5 ~「中工程計画」でプロジェクトを調整する

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

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

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

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

成功のポイント6 ~システムリソースを管理する

グラフを使ったビジネス資料

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

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

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

【番外編】成功のポイント7 ~アジャイルソフトウェア開発手法を検討する

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

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

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

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

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

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

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

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

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

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

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

大規模ソフトウェア開発を成功のカギを握るプロジェクトマネジメントの質の向上

握手をするビジネスマン

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

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

システム開発の費用相場

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

システム開発の平均相場
平均相場 233万円~
システム開発の種類別平均相場
システム開発の種類 費用相場
簡易顧客システム 20万円~
Webシステム 130万円~
業務システム 200万円~

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

システム開発会社探しで、こんなお悩みありませんか?

  • 一括見積もりサイトだと多数の会社から電話が・・・

    一括見積もりサイトだと
    多数の会社から電話が・・・

  • 相場がわからないから見積もりを取っても不安・・・

    相場がわからないから
    見積もりを取っても不安・・・

  • どの企業が優れているのか判断できない・・・

    どの企業が優れているのか
    判断できない・・・

PRONIアイミツなら

発注先決定まで最短翌日

発注先決定まで
最短翌日

  1. 専門コンシェルジュが
    あなたの要件をヒアリング!
  2. 10万件の利用実績から
    業界・相場情報をご提供!
  3. あなたの要件にマッチした
    優良企業のみご紹介!
マッチング実績30万件!

一括見積もりをする

(無料)

この記事に関連するシステム開発会社一覧

大規模システムに強いに条件を追加して企業を探す