先日、自動車学校が情報テクノロジーを活用するために今注視すべきは「業務の完全ペーパーレス化」であり教習原簿のデジタル化はその第1ステップに過ぎない、という趣旨の記事をアップしました。（詳しくは下記）

この記事では、その教習原簿のデジタル化を進めるにあたって、「完全ペーパレス化」に繋げるために意識すべきことを述べていきたいと思います。

本題に入る前に、少しだけ企業における情報システム導入の歴史を少しだけふり返ってみます。

90年代、オープンシステムによるダウンサイジングが進んでいたころ、ERP（Enterprise Resources Planning）と言われるシステムが大きな脚光を浴びるようになりました。ERPとは受注・調達・生産管理・在庫管理・販売管理・財務会計などの基幹業務を網羅的に同じアーキテクチャで構築したシステムのことで、1970年代にドイツのSAP社が開発した「R/1」が世界最初のERPといわれています。このERPは欧米で徐々に広がっていき、90年代に入ると日本でもSAPのERPパッケージが販売されるようになり、その後、多くの企業がERPを導入するようになりました。

ERPの導入は、多くのプロジェクトの場合、私の古巣の会社のようなコンサルティングファームがプロジェクトに深く入り込みました。ERPを導入して効果を最大限に発揮するためには「システムを業務に合わせる」のではなく「業務をシステムに合わせる」という作業が必要となるためです。ERPパッケージの思想にはベストプラクティスに基いて機能設計をするという考え方があります。その様な考えで設計しなければ多くの企業に導入することは難しくなりますし、その様な考え方で構築されたからこそ、業務をシステムに合わせることが業務の改善に繋がると考えられていました。ンサルティングファームがプロジェクトに参画するのは、ERPを導入するためにベストプラクティスに合わせたBPR（Business Process Reengineering、業務プロセスの再構築）が求められるというのが１つの理由でした。

90年代以降、ERPだけでなく、SCM・CRM・SFA・HRMなど様々な分野で業務パッケージの導入が行されるようになりました。しかし、日本企業での導入は失敗事例が多いと言われています。よくある失敗のパターンは次のようなものです。

業務パッケージがカバーする業務に関して、現場からは強い不満の声が上がったので次々にアドオン開発を要件に取り入れた。アドオン開発が増えたため導入コストが予算オーバーとなった上に開発の工期が伸びてしまった。アドオン開発が増えた結果、業務パッケージのバージョンアップがやりにくくなり運用は柔軟性に欠け、アドオンが原因の障害も多く発生した。更に画面や帳票が使いにくいと現場の不満は高まる。そういった対応に追われて情報システム部門や開発ベンダーは休まるときがない。そうやって苦労して開発し運用を始めたものの、結果的に業務はパッケージ導入前と殆ど変化していなかった。

上記のような失敗事例が起こる原因は、日本企業の情報システムマネジメントのあり方にあるということはよく言われることです。導入の目的が曖昧だったり、導入効果の評価指標が曖昧だったり、そういったことが要因で、現場の声に押されてアドオン開発が増えるということは、パッケージ導入の現場では起こりがちなことです。こういった問題を支援するのもコンサルタントのお仕事だったりします。

ここまでの失敗の話で、教習原簿のデジタル化を進めるうえで自動車学校の経営者が意識しなければならないことが少し理解できると思います。まずトップは「なぜ教習原簿をデジタル化するか」という問いに明確に答えられなければなりませんし、導入成果の指標も明確にしておかなければなりません。弊社の導入目的は明快で「紙の教習原簿を完全に廃止してICT化の基盤を構築すること」それ以上でもそれ以下でもありません。評価指標は「導入から9カ月以内、なるべく早いタイミングで紙の教習原簿を廃止すること」、「定量的な評価で情報セキュリティが紙ベースの運用より向上すること」、「サービスインの予定日を厳守すること」の３つと考えました。実は、業務効率化は教習原簿のデジタル化においてそれ程重視しませんでした。効率化の効果も試算はしたものの、原簿の電子化だけではそれ程大きな改善は期待できず、あくまでも効率化の効果はその後のシステム改善やデジタル化の領域の拡大で狙っていくと考えたためです。「基盤の構築」ということが重要なので、完全に紙をなくすことが重要なことに加え、不要な機能を作り込まないという意識を持つようにしました。サービスインの予定日を厳守することを評価指標と考えたのはそのためです。余計な機能の構築をしていては、スケジュール通りの導入ができなくなってしまいます。

「余計な機能を作らない」という意味で意識しなければならない点で、「標準」と「例外」の区別、「標準」と「差別化要因」の区別です。多くの場合、現場の声というのはこれらの区別がなされません。結果として、不要な機能を多く作ることに陥りがちです。

弊社の導入の過程でもあったのですが、例えば、スマートフォンを前程とした業務設計を考えていると、「持ってない人がそれでは対応できないからスマートフォン前程で考えるのはやめよう」なんて意見がでます。ただ、現在9割以上のお客様がスマートフォンを持っている状況なので「標準業務はスマートフォン前程で設計し、持っていない人は例外業務で対応できる設計にする」という考え方をするのが「標準」と「例外」の区別です。この区別ができなければ例外に引っ張られて有効な機能が活用できなかったり、不要な開発要件が発生したりします。

業務パッケージ導入の教科書でよく言われるのが「標準」と「差別化要因」の区別です。「標準」とは同じ業種・業務であればどこの会社でも同じでよいようなものです。こういった標準的な業務はパッケージの仕様に業務を合わせるのが業務パッケージのメリットを生かせます。「差別化要因」とは、自社独自のノウハウを詰め込んで明らかに強みとなる部分です。業務パッケージ導入のアドオン開発はこの「差別化要因」に関して行うというのが、基本的な導入方法論の考え方です。そして、教習原簿の電子化とは、「標準」の枠から外れることはまずありえまいので、業務パッケージ側がベストプラクティスを詰め込んで、各自動車学校がパッケージに業務を合わせるという考え方をする方ことで、同じパッケージを使っている企業の業務品質は上がっていくものと考えられます。

自動車学校の経営者の皆様には、デジタル教習原簿のプロジェクトを進めるにあたって、目的の明確化、効果の評価方法、標準・例外・差別化要因の区別を意識して頂きたいと思っております。とくに区別の話は、これからデジタル教習原簿をサポートする教習システムが合理的に発展していくうえでとても重要だと考えています。

さて、とはいえ、まだまだデジタル教習原簿は黎明期であり、パッケージ側の機能が必ずしもベストプラクティスと言えない場合は多くあると思います。そのためにパッケージの機能改善の進め方は「サービスリクエスト」といわれるリクエストベースで進むということを業界の皆様には理解して頂きたいと思います。現場で起きた機能変更の要望はゴリ押しするのではなく「サービスリクエスト」という形で依頼を投げて、パッケージ全体の様々なバランスを考え、対応するか否かはベンダー側で考えるという進め方で行うことで、変更が行われる都度、ベストプラクティスが改善されるわけです。ベンダーが対応しなから自分の会社だけ独自の機能追加を行う、という考えは差別化要因となる機能であれば合理的な判断ですが、デジタル教習原簿は差別化要因にはなりにくいので、避けた方が将来的に良い形になると考えます。ベンダー側も、バージョンアップする際は、サービスリクエストの対応はベストプラクティスの改善という意識を持っていただき、対応した業務に打ち手は、事前通知を行ったうえで、ユーザー企業が活用していけるようなコミュニケーションをとって頂ければ、デジタル教習原簿はよりよい形へと発展していくと考えています。各都道府県の免許課の皆様にも同様の意識を持っていただけるとよいのですが、そうするためには、自動車学校の経営者側がシステム導入に対する高い知見を持ち、おこがましいかも知れませんが免許課を育てていくという意識を持った方が良いかもしれません。

ということで、今回はややこしい話となってしまいましたが、デジタル教習原簿をご検討の経営者の皆様には、情報システムの導入ということについて、学んでいただき、強くて適切なリーダーシップを発揮して頂ければ幸いでございます。