これは、多くの企業において「無駄な機能の開発に多額のコストを支払っている」ということを意味しています。また、コスト面だけではなく、システムの規模が大きくなるほど稼働後の機能改修に時間が掛かるようになり、ビジネスの変化に身軽に対応することが難しくなってしまいます。
しかし、どうすれば無駄をなくすことができるのか・・・そこが難しいところですよね。
皆さんこんにちは、アイ・ティ・イノベーションの弘中 伸典です。
約20年、コンサルタントとしてIT戦略/企画やプロジェクトマネジメントなどの専門領域でお客様の支援をしてきました。
今回より「システム企画」をテーマに、普段のコンサルティングや研修の講師を担当する際に「良く訊かれる質問」を一つずつ採り上げ、Q&A形式でご紹介していきます。
いまだに成果が出ない(または途中で失敗してしまう)プロジェクトは数多くありますが、これまでの経験上、「ITのことは専門の開発会社に任せておけばなんとかしてくれる」との安易な発想により、開発前の企画段階が軽視されていることが大きな原因であると感じています。
このシリーズでは、企業価値向上につながるシステムを低コストで実現するという観点から、システム企画のキーポイントとなるような内容を中心にお伝えしていこうと思いますので、皆様の業務のヒントとしてお役立ていただければ幸いです。
(※1The Standish Group “Chaos” report 2002)
それでは今回のお題です。
大きく二つの要因があります。
・システム化という手段が目的化している
・ユーザーの課題をそのままシステムへの要求としている
例えばシステムのサポート切れが近づいた時。
システム企画で「サポート切れに対処するためシステムを再構築する」ことを目的に掲げ、おもむろに「ユーザーアンケートによる現状課題の調査」などしていませんか?
これでは、「リアルタイムの在庫を画面に表示して欲しい」「問い合わせ履歴を全文検索できるようにして欲しい」「1クリックで帳票を出せるようにしたい」といった現場のありとあらゆるニーズが数多く寄せられ、それらを全部システムへの要求として扱うとどうしても規模が膨らんでしまいますよね。
ユーザー全員がビジネスの全体像や組織の戦略を把握できている訳ではありませんから、このような課題を一つずつシステムで解決しても、ビジネスの成果に寄与しない機能が多く出来てしまうことになります。(そのような機能は、使用頻度が低かったり、特定のユーザーしか使わなかったりで、後から見るとコストの無駄だったということになりがちです)。
システム企画においては、まず組織としてのビジネス上のゴールを決めておくことが重要です。いったん手段は置いておいて、ビジネス戦略にもとづき、「注文件数〇%アップ」などといった「実現したい状態」を目的として定義します。
そのうえで、「注文件数〇%アップに必要な状態が何か」を、ユーザーの意見を交えながらブレイクダウンしていき、「欠品率が〇%低下する」「リアルタイムに正確な在庫を把握できる」「翌日発送分が当日17:00まで補充指示できる」といった要求の体系を完成させます。
このように、現場のユーザーによるボトムアップ観点の要求をビジネスから見たトップダウン観点の要求に繋ぎ合わせることで、ビジネス上のゴールに寄与しない要求が入り込むことを避け、また手段を分離することで「システム以外による実現方法」を考えやすくなります(例えば、「リアルタイムに正確な在庫を把握できる」という状態は、やり方を工夫すれば手作業でも満たすことが可能ですよね)。
サポート切れへの対応なども、例えば「ビジネス中断による機会損失のリスクを抑制する」を目的とすれば、想定されるリスク発生率・損失額に見合わない再構築は行うべきではなく、延命措置などコストを抑えた手段を選択できるようになります。
手間はかかりますが、目的→要求体系(状態)→手段というステップをきっちりと踏んで企画しておくことで、その後の要件定義工程などで追加要件が出てきても、目的や要求体系と照らし合わせて不要な要件、オーバースペックとなる要件を絞り込むための軸として使うことができます。
最後に。稼働後に本当にビジネス上の目的が達成できたか、そして開発した機能がどれだけ利用されているかしっかりモニタリングし、機能改修や次の再構築に活かすことも忘れないようにしましょう。
今回の答え。
Aシステム企画で「ビジネス」として実現したい「状態」を定義できていないから。
システムは、あくまで「あるべきビジネスの姿を実現するための手段」ですから、ITプロジェクト=ビジネスプロジェクトであることをしっかり認識しておくことが重要です。
それでは次回もお楽しみに!