解説 ITで儲けるための仕組みづくり：売り上げ増に直結するIT部門の作り方（2/3 ページ）

儲かるITを実現するためには、「仕組み」やそれを使う「人」に目を向けなくてはならない。シンプルで高品質のデータ活用の仕組みが現場の収益活動に貢献する。

[岡政次（ウイングアーク テクノロジーズ），ITmedia]

仕組みに必要な機能とは

　では、どのような仕組みが必要なのだろうか。まずは動き回る課題を追いかけられる仕組みである。課題分析ツールを選択するときに考慮すべきことは、課題は移動するということである。課題は解決すると必ず違うところに移動する。販売でも生産でもすべての工程が同じ能力を持っているわけではなく、どこかにボトルネックがある。当初想定していた能力を基準に生産を行えば、必ずボトルネックとなる工程で在庫の山を築いてしまう。そのボトルネックの能力を改善すると次に能力の低い工程がボトルネックになる。課題解決とは対策を講じるたびに、移動する課題を追いかけ続けるということである。このことから、仕組みには移動する課題を追随し続ける柔軟性がなければならない。

　課題解決は、点でとらえるのではなく、線や面でとらえることであり、移動する課題を容易に追いかけられる仕組みが必要である。移動する課題を追いかけ、必要とされるデータを提供することにより、PDCAサイクルがスムーズに回ると、収益性向上に貢献する活動ができる。

　しかし、現状の情報システムでは、移動する課題を追い、随時必要なデータを提供することは難しい。変化が激しく、スピードを求められる業務現場のニーズに対応するためには、以下の課題を解決できる仕組みが必要である。

1．ユーザー部門のシステム改善依頼に迅速に応えられない

2．ユーザー部門のデータ提供要求に即座に応えられない

3．ユーザー部門のデータ活用スキルが低い

ウォーターフォール型の弊害

　具体的に見ていこう。1「ユーザー部門のシステム改善依頼に迅速に応えられない」はビジネススピードについていけないシステム改修手順に原因がある。企業のビジネス環境の変化は5年前、10年前と比べると何倍にも速くなっている。以前は1年に1度、半年に1度で済んだアプリケーションシステムの改修が、今では3カ月に1度あるいは毎月と、どんどん短いサイクルに変わってきた。しかしIT部門のシステム改修手順は20年前とほとんど変わっていない。

　ユーザー部門からの改修要件を受け、ウォーターフォール型で進め、長く、重い手順をへてシステム改修が完了する。この手順を踏んでいる限り改善要望は溜まっていく一方で、納期回答はできないのが現実である。

　2「ユーザー部門のデータ提供要求に即座に応えられない」について、1の影響でIT部門は徐々にユーザー部門の信頼を失い、IT部門に依頼しても時間がかかるので、データだけ提供してくれれば後は自分たちでやるという「データ提供依頼型」にユーザー要求がシフトしてきた。しかし、データ提供依頼の発生頻度はほぼ毎日といっていいほどで、データ提供が一度で完了せず、五月雨式に追加データの提供を求められる。1の代替手段として2でユーザーを満足させようとしたが、これでも対応が追いつかなくなった。これも1と同様に、ウォーターフォール型による弊害である。

　3についてもIT部門に原因がある。ユーザー部門はデータ活用に慣れていないが、業務についてはプロであり、業務で扱う数字の意味を一番理解している。必要なデータがそろっていれば、自分の思考の展開通りにレポートが作成できるので、どんどんデータ活用スキルは向上する。しかし、提供されるデータは断片的で必要なタイミングにすぐ出てこない環境ではスキルの向上は鈍化する。また、ユーザー部門のモチベーションも上がらない。データ活用で一番重要なことは、必要なタイミングにデータが入手できる環境であるが、これを阻害するITシステム環境である限り、ユーザー部門のデータ活用スキルは向上しない。

　しかし、上記の原因は表面的なもので真因ではない。では、この根っこにある真因は何なのか。次の3つだと考える。

• レガシーシステムは、手作りで開発されたものがくもの巣状のインタフェースで連携されている。そのため、改修が非常に難しい。過去から修正を重ねてきており、そのたびに複雑化が進むという悪循環を招いている。このため、改修には多くの時間を要している。放置すると悪くなる一方で、法律改正への対応も難しくなってしまう。ウォーターフォール型での作業は、レガシーシステムの構造そのものが真因といえる
• オープン化によってパッケージソフトの活用が進み、手作り部分は以前に比べ減少したが、システム構造は従来と変わらず業務ごとに個別最適なシステムである。ユーザー部門が必要なデータを切り出すためには、複数の業務システムから整合性が取れたタイミングと粒度のデータを抜き出さなければならない。これにも調査や切り出し作業工数が掛かり、依頼を受けてすぐに提供するというわけにはいかない。本番データを取り扱うリスクを回避するための確認、承認、テストなど踏まなければならない手続きがあり、作業効率は上がらない。どれだけ効率化を図ってもエンドユーザーのスピードには応えられない
• データ提供を受けても、思うように集計ができない理由がある。それは、業務システム間のマスターデータの不整合である。ユーザー部門から見れば理解できない事象であるが、ほとんどの企業で、1つの取引先に複数のコードが振られていたり、1つの製品に複数のコードが設定されていたりする。このため、取引先別に取引実績を把握しようとしても簡単にはできず、集計するためのノウハウが必要になる。故にノウハウのない人はデータ集計、分析ができずデータ活用が進まないということになる。これらは既存システムのシステム構造と開発手法に起因するもので、簡単に解決できる課題ではない。IT部門の人たちもこの課題と原因については十分承知していることだが、これを解決する適切な手段が見つからないというのが現実である。

　西暦2000年問題の対策時に一気に業務システムをERP（統合業務パッケージ）システムに移行して、業務システムの全体最適化を狙ったが、業務要件を満たすにはあまりにも機能不足で、断念したいきさつがある。現在進めているのが地道にレガシーシステムを個別にERPシステムに移管してシステム改修を容易にしていることだ。しかし、これでも2と3の対策にはならない。さらに踏み込んだ課題解決策を講じるべきである。