システム開発の外注の失敗を防ぎ成功に導くコツ４つ

システム開発の外注の失敗を防ぎ成功に導くコツ４つ

他社にシステムを発注するとき、こんなお悩みはありませんか？

• 期待しているシステムをちゃんと作ってくれるだろうか？
• 品質は大丈夫だろうか？
• 費用が高額にならないだろうか？

自社のビジネスを支える大事なシステムを発注する以上、慎重になるのは当然だと思います。 この記事では、システムを発注する際に気をつけるポイントや、システム開発プロジェクトを成功させるために どういったことが必要なのかをご紹介したいと思います。

システム開発の4割は失敗している

企業IT動向調査報告書 2020によると、 システム開発プロジェクトにおいて、たとえば工期の遅延は500人月以上の大規模プロジェクトで「予定より遅延」との回答数は45.8%にも登ります。 また、同様に予算超過は500人月以上の大規模プロジェクトにおいても「予定より超過」が45.8%の回答を締めています。

このような状況において、システム開発の品質への満足度も「不満」が21.2%、「ある程度は満足」54.2%となっており、少なくない割合のユーザー企業が システム開発プロジェクトに対して、なんらかの不満を抱えていると言えます。

なぜこのような状況が発生するのでしょうか。 原因と対策を考えて行きたいと思います。

受注者側の問題と解決策

まずはシステム会社側の問題点をみていきましょう。 システム開発プロジェクトが失敗する原因として、よく挙げられる受注側の問題点として以下があげられます。

• 見積もりの曖昧さ
• 技術力不足
• コミュニケーション不足

１つ目の「見積もりの曖昧さ」ですが、これには様々な原因があります。

どのようなお客様であっても、「業界標準的な業務」と「自社独自の業務」があります。 「業界標準的な業務」については、見積もり担当者の業務知識、経験も必要ですが、「自社独自の業務」はそうはいきません。 これを見積もりに落とし込めないと、開発プロジェクト中に要件が拡大し、見積もりとの乖離がおきてしまします。 要はヒアリング不足、コミュニケーション不足といえます。

また、そもそもシステム開発プロジェクトでは見積もり時点で仕様がすべて決定していることはありません。 そのため、どうしても見積もり前提から派生する類推による見積もりや、リスクヘッジというものが発生します。 ですが、これは安全にシステム開発プロジェクトを遂行する上で必要なものです。 システム開発プロジェクトに対するリスクをどのように考慮して、見積もりに含めているか、 受注側は発注側に説明できる必要があります。

次に。「技術力不足」です。 これにも様々な状況が考えられます。 例えば最先端の技術を使ったシステムの構想をしている場合。 この場合は、最先端技術を習得している技術者というのは非常に稀有な人材です。 こういった場合、プロジェクトメンバーが10人いて、10人ともがその技術を習得している。ということはまず無いでしょう。 一人でもメンターとなれる技術者をアサインできるか、または調査工数を費用や納期に含められるか。といったことをお客様とよく会話する必要があるでしょう。

また、この場合にどの程度調査に工数をかけるか、その結果によってプロジェクト進行に影響が発生するリスクがないか。 といった点も予め明確にしておく必要があります。 結果を受けてリスク見積もり分をどのように使っていけば、納期までにプロジェクトを完遂できるかアイディアを出せる プロジェクトマネージャーの能力も必要になります。

最後に「コミュニケーション不足」です。 開発チームにとって、コミュニケーションは最重要です。 発注側、受注側双方向のコミュニケーション、発注側内部のコミュニケーション、受注側内部のコミュニケーション。 どれがかけてもプロジェクトはうまく行きません。 定例の会議を設けることは最低限必要ですが、日常的なコミュニケーションを簡易に取れるツールを用意することも有効です。 容易にコミュニケーションを取れる体制と信頼関係はプロジェクトを成功させるために最も重要であると言っても良いと思います。

発注者側の問題と解決策

つぎは発注側の問題点をみていきましょう。 このブログの筆者はシステム開発を生業とするプログラマですので、開発者の視線が入ってしまうことはお許しください。 システム開発プロジェクトが失敗する原因として、よく見られる発注側の問題点として以下があげられます。

• 期待する仕様が明確になっていない
• 仕様の変更が頻発する
• 過剰なドキュメントを要求する

これも一つずつ確認していきます。

「期待する仕様が明確になっていない」ということは、受注者側の問題でも書いたとおり、 仕様自体がプロジェクト開始時にすべて決まっているということはまずありえないので、受注側もあるていどは許容しています。 ですが、前述のとおりどの会社でも「自社独自の業務」というものがあります。 これは発注側から提示しない限り、受注側では推察も難しい性質のものになりますので、 発注側は何が「自社独自の業務」なのかを理解し、プロセスを説明する必要があります。 また、システムリプレース案件などでありがちですが「既存仕様を踏襲」というフレーズで短縮してしまうと、 受注側からは「既存仕様」が数行のプログラムなのか、数ファイルに渡る規模のプログラムなのか判断が難しい場合があります。 なるべくこういった表現はせず、可能な限り仕様を明示することが大切です。 とはいえ「XX業務です」である程度察してくれる場合もありますので、開発側担当者と内容に齟齬がないかよく確認する必要があります。

「仕様の変更が頻発する」というのは、非常に悩ましい問題です。 というのも、仕様変更が社内の業務プロセスの変更やステークホルダーの考えから発生する場合もあれば、システム開発会社の設計不良が原因である場合もあるからです。 後者の場合はシステム開発会社に設計の修正を求めることになると思います。 前者については発注側社内で新システムの目的や業務プロセスの変更を伴うかといった情報がステークホルダー間で適切に共有されていることで、一定の抑制は可能です。 だれがステークホルダーなのか、キーパーソンとなるのは誰か、どういったコミュニケーションが必要か。といったステークホルダー・マネジメントを事前に検討することでプロジェクト中における仕様変更の頻度は抑制することができます・

「過剰なドキュメントを要求する」というのは、システム開発プロジェクトにおいて発生しうる問題です。 ざっとシステム開発プロジェクトに付帯するドキュメントの例を上げると以下のようなものが考えられます。

• 要求仕様書
• 要件定義書

• 基本設計書

  • システム概要仕様書
  • 機能一覧
  • 業務フロー設計書
  • ネットワーク構成図
  • 画面設計書
  • 帳票仕様書
  • ER図
  • インターフェース仕様書

• 詳細仕様書

  • DB定義書
  • プログラム仕様書
  • クラス設計書
  • 状態遷移図

• テスト仕様書

  • 単体テスト仕様書
  • 結合テスト仕様書
  • システムテスト仕様書

こういったドキュメントの作成は、当然ながら見積もりに反映されることになります。 トラブルが発生した場合の証跡として有効ではありますが、開発者が仕様認識を揃えるために必要な範囲はもっと少なくてよく、 「発注側にとって必要なドキュメントか」という視点での精査は必要です。

システム開発を発注する前に考えるべきチェックポイント

前述のような問題を回避または解消しながら、システム開発プロジェクトを推進していくために、どのようなことに注意したらよいでしょうか？ これにはいくつかケース別にポイントが考えられます。

• 社内のプロジェクトキックオフにおいて
• ベンダー選定において
• 見積もりのチェックにおいて
• プロジェクト中において

社内のプロジェクトキックオフにおいては、ステークホルダーコントロールを意識することが重要です。 関係者をリストアップし、だれが（どの部署が）何を決めて、どんなアウトプットをするのか。 プロジェクト初期における適切な権限移譲が行われていれば、多くのステークホルダーが迷わず担当のミッションに注力できます。 このとき、インセプションデッキを作成すると、プロジェクトの目的と優先事項が明確になるのでおすすめです。

ベンダー選定においては、まずその会社が同様のシステムを開発した実績を持っているか。 会社としての実績がない場合は、プロジェクトメンバーのなかに同様の経験をもつメンバーが存在するか、 または（少なくとも開発期間の）見積もりとして、調工数を計上しているか確認すべきです。

開発会社から見積もりを受け取ったら、その見積もりの内容をヒアリングします。 会社によって、見積書に掲載する粒度はことなりますが、おおまかにでも、見積もり上想定している機能数と、 どの程度リスクを見込んでいるかは確認するようにします。 また、会議体などのコミュニケーションコストもどの程度見込んでいるか確認すると良いと思います。

開発会社がきまり、無事システム開発プロジェクトが進行しはじめたら、コミュニケーションを重視します。 仕様などの情報は、適切な時期に適切な粒度で伝わると一番間違いが少なくなります。 予めすべて伝えてある。と断言できる状況だとしたら、それはプロジェクト初期に発注側で非常に努力した結果で素晴らしいことですが、 開発期間が長期になればなるほど、人の記憶は曖昧になり、抜け漏れや認識の食い違いに繋がります。 そうならないために、常に「今進行しているタスク」と「直近で進行するタスク」に対して、 必要な情報を受注側、発注側双方で整理していけることが理想的です。

まとめ

いかがでしたでしょうか。 今回は説明的な内容が多くなってしまいましたが、システム開発プロジェクトに起こりがちな問題点と、プロジェクト始める際に考えるべきことをお伝えしました。 アーバでは社内キックオフの段階からコンサルティングも行っております。 システム開発を考えているが、わからないことが多くて不安。という場合は、お気軽に弊社お問い合わせフォームよりご相談ください。