WEBマガジン

「業務改善プロジェクトの進め方」

2016.01.21 株式会社オージス総研　　宇野泰三

我々ITベンダーは、ITを調達したい企業（以降、施主と呼ぶ）からシステム開発の引き合いやRFPの提示を受け、それに応える提案を行い、晴れて発注先に選定されたのちにシステム開発を請け負う。システム開発の手法にはウォーターフォールやアジャイル開発などがあり、その進め方に違いこそあるが、いわゆるＶモデルに示される、要件定義からテストという一連の開発フェーズを担当する。ITベンダーにとってはシステム開発プロジェクトかもしれないが、施主にすればシステム導入は課題解決の手段にすぎず、何らかの課題を解決するための業務改善プロジェクトの一環でシステムを導入する。
本稿では、施主とITベンダーが一体となって進めていくべきプロジェクトを、広く業務改善プロジェクトとして捉え、その進め方を見ていく。尚、改善と改革という言葉は異なる意味であるが、本稿では両者の違いに触れず、一括りに「業務改善」と呼ぶ。

・業務改善のステップ

業務改善を語るうえで避けて通れない研究成果がある。「コッターの変革の8ステップ」と言われるものである。コッターによると、業務改善に取り組む数多くの企業を調査したところ、成功している企業はほぼ漏れなく、以下の8段階のステップを踏んでいるということである。

危機意識を高める（Establishing a sense of urgency）
変革推進チームをつくる（Forming a powerful guiding coalition）
適切なビジョンをつくる（Creating a vision）
変革のビジョンを周知徹底する（Communicating the vision）
従業員の自発的な行動を促す（Empowering others to act on the vision）
短期的な成果を生む（Planning for and creating short-term wins）
さらに変革を進める（Consolidating improvements and producing still more change）
変革を根付かせる（Institutionalizing new approaches）

ここでは、特に1と6に注目したい。業務改善を進めていくためには、強力なリーダーシップが必要であることは言うまでもないが、これは協力的なフォロワーをどれだけ巻き込めるかということと同義である。誰しも変化に対して否定的に捉えがちだが、実は変化しないことが一番危ないことだという、「このままではヤバい」という感覚をはっきりと皆で共有しましょう、ということを1は示している。この緊迫感が、業務改善の正のスパイラルの原動力となる。
また、業務改善は一朝一夕に実現できるものではなく、どうしても長丁場になりがちだ。小さな成功体験は、現場のモチベーション維持のためだけでなく経営層の理解を得て業務改善活動を継続し続けるためにも必要になってくる。成果を短期的に出していくためには、改善テーマを適切なサイズにスライスし、優先順の高いものから取り組んでいく。すなわち、業務改善プロジェクトのWBSは、タスクではなく成果ベースで作成しなければならないことを意味する。

・業務改善のプロセス

次に、業務改善プロジェクトをどのように進めていけばよいのかを見ていこう。IT導入を伴う業務改善プロジェクトの標準的なモデルとしては、ITコーディネータ協会が発行する「ITCプロセスガイドライン」に記載されているIT経営プロセスモデルが参考になる。

図１. IT経営プロセスモデル「ITCプロセスガイドラインVer2.0」より引用

少々聞きなれない単語が並んでいて取っ付きにくい感があるが、「経営目標を達成するために経営戦略と整合した改善テーマを選定し、課題を解決する手段として必要とあらばITを導入する」ということを言っている。
ITCのプロセスは、企業の状況に応じてカスタマイズして利用することが前提となっている。また、抽象度が高いので実践経験の無い人からすれば多少分かり難いところがあるかもしれない。今回は、プロセスの詳細には触れず、要するに「何をしなければならないのか」のイメージを伝えたい。

若干話が逸れてしまうのだが、プロセスとは料理でいうところのレシピに相当する。出来上がる料理を知らされていなければプロセスを順に追うしかないが、出来上がりの料理のイメージが湧いていれば、そのプロセスでおおよそどういったことをしなければならないのか見当がつく。

IT導入を伴う業務改善プロジェクトの（中間）成果物のひとつにRFPがある。上記のITCプロセスで言うと「IT資源調達」フェーズで作成され、ベンダー選定の後に「IT導入」フェーズにてシステム開発を行う。RFPの構成を見ることによって、「IT資源調達」フェーズまでのプロセスで何を検討しなければならないのか、おおよその見当がつく。

・RFPの構成

RFPについての説明は割愛するが、RFPがどのようなものかご存じでない方は、ITコーディネータ協会が発行しているRFPの見本が参考になる。ぜひ参照いただきたい。
ここでは、その見本を活用させていただき、RFPの全体像を俯瞰する。ざっくりいうと、RFPは３つのパートから構成されていることが分かる。

図２. ITコーディネータ協会発行　「開発委託用RFP見本」より作成引用

: このパートの主題は、「なぜ業務改善を行い、解決の手段としてシステムを導入するのか？」ということになる。そもそもシステム導入の目的が経営戦略と整合し、尚且つ、経営目標の達成に寄与するものでなければ経営層の承認を得ることができない。また、システムのオーナーたる利用部門が主体的に参画するように仕向けるために、動機づけのメッセージも不可欠となる。
: このパートでは、「何を実現しようとし、そのためにどのようなシステムを必要としているのか？」を記述する。RFPに付きまとう疑問として、「何をどこまで書けば良いのか？」というものがある。詳細に書けば要件定義書のレベルになるし、粗く書けばベンダーに要件が伝わらず、精度の高い見積はもとより、より良い提案を引き出すことができない。一概には言えないが、施主の要求として伝えなければならないことと、ベンダーの裁量に委ねることを勘案して「適切なレベルで」記述することになる。
: 「どのようにシステムを実現するのか？」に関しては、主にベンダーから提案を受ける部分であり、施主として提案に含めてほしい内容を検討し記述する。ベンダーからより良い提案を受けられるように、前提条件や要望等を整理する。

RFPを作成する目的は、一言でいえば、「より良い調達のため」だ。表向きには、ベンダーからより良い提案を引きだすために作成するものであるが、実は、経営目標の達成に寄与する業務改善テーマを設定し、業務のあるべき姿を明らかにするという活動のひとつの通過点がRFPという形で整理されている。

・まとめ

本稿では、RFPの構成を見ることで、業務改善のプロセスでどういったことを検討しなければならないのかのイメージを掴むことを試みた。また、コッターの変革の8ステップを紹介し、危機意識を共有することや小さな成功体験の積み重ねが業務改善を継続していくために不可欠となることを示した。その一方で、小さな成功体験を積み重ねることと、RFPを作成してITを導入するという重厚長大なプロセスとが整合しないのではないかという疑問を持たれた方もおられるかもしれない。今回説明できなかったが、別の機会に紹介できればと思う。

・参考文献

[1]	「ジョン・コッターの企業変革ノート」ジョン・P・コッター他、2003年
[2]	「ITコーディネータプロセスガイドラインVer2.0」ITコーディネータ協会、2011年
[3]	「開発委託用RFP見本」ITコーディネータ協会、2003-2004年 http://www.itc.or.jp/foritc/useful/rfpsla/dlfiles/kaihaturfp_v10e.pdf

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

お問い合わせ