目 次

システムの品質が悪くなる根本原因

「ウチはシステム障害が非常に多い。どうしたら品質を高められますか？」

当社にご相談いただいたIT部門の部長のお言葉です。そのシステムは「B to C（企業-消費者）」のシステムのため、エラー発生やレスポンスの遅さで、利用者からクレームが多発していました。

現状分析を開始し、プロジェクトのドキュメントを全てチェックします。すると、すぐに品質の悪い理由がわかりました。

性能要求、セキュリティ要求、テスト計画書、エビデンス、障害管理表、リリース判定表など「品質に関わるドキュメント」がほとんど存在しなかったのです。

一方で、ビジネス計画書や要求定義書はしっかり書かれていました。ITベンダーが納品したドキュメントもそれなりにしっかりしています。全体的にドキュメントが不足しているわけではなく、「ユーザー側から見たIT寄りのドキュメント」だけが不足している状態でした。

思い当たる節があり、プロジェクト計画書の体制図を確認してみると…やはりそうでした。

プロジェクトオーナーとプロジェクトマネージャーが「ビジネス部門」のメンバーで、「IT部門」は入っていませんでした。IT部門はシステムリリース後に移管され、運用・保守フェーズから担当しているとのことでした。

自部門の強みと弱みを意識する

ビジネス部門・業務部門が中心となるプロジェクトの場合、以下のような傾向があります（ちなみにIT部門・情シスはこの逆です）。

＜良い傾向＞

  • ビジネス要件、業務要件に強い
  • スピード重視
  • 部門間の調整、根回しは得意
  • 現場重視

＜悪い傾向＞

  • 品質、セキュリティを軽視
  • スケジュールの遅れをテスト省略でカバー
  • システム間連携に弱い
  • 自部門中心の部分最適化い
  • ドキュメントが断片的（パワポ多し）
  • ITベンダーを野放し

ビジネス部門・業務部門が中心の場合、良くも悪くも推進力があります。いったん決めたスケジュールは「他を犠牲にしてでも守る」という執念すら感じます。

大枠の方針はそれで問題ないのですが「何を犠牲にするか？」という点に偏りが出ます。全社的な観点で優先順位をつければ良いのですが、ビジネス・業務主導だと、自部門優先になりがちです。

ここで必要とされるのは「客観的・中立的な立場であるIT部門」です。

品質、セキュリティ、テスト、システム間連携、全社最適、ドキュメントの網羅、ベンダーコントロール・・・など上記の　＜悪い傾向＞　を補える唯一の部署です。

つまり、このプロジェクトは「体制図にIT部門を組み込まなかった」時点で品質が悪くなる傾向にあったのです。

逆をいえば、IT部門・情報システム部はビジネス・業務部門に気後れすることなく、自分たちの「強み」を理解し、その分野を積極的にリードすべきです。「強み」となるスキルを日々意識して、磨いていくことが重要となります。その積み重ねが、体制図に反映されていきます。

IT部門・情シスを適正に配置する

「ビジネス・業務部門とIT部門のどちらがオーナーとなるべきか？」

これはケースバイケースです。プロジェクトの特性に合わせて、重要な判断ができる部門がオーナーになるべきです。大切なのは、それぞれのオーナー部門の傾向を理解して「弱い部分を他部門が補完するように体制を組む」ということです。

最近は、ビジネス・業務部門がオーナーとなるITプロジェクトが多いと感じます。それは「ITなくしてビジネスの展開ができない時代になってきた」と言えます。そのようなプロジェクトこそ、「IT部門の適正な配置」が成功の鍵を握るのではないでしょうか。

御社のプロジェクト体制図は、バランス良くIT部門・情報システム部が配置されていますでしょうか？