2000年頃のシステム導入の現場
こんにちは。当ブログをご覧いただきありがとうございます。
この記事では過去の業務経験から学んだことについてご紹介させていただきます。
大学を卒業する西暦2000年は、ITバブルがはじけてすぐで就職氷河期の1年目にあたる年だったと記憶しています。前の年の売り手市場と打って変わって厳しい就職活動で、先輩たちをうらやましく思ったものですが、こうして振り返ると私より後の数年やサブプライムローンショックの後の方が厳しかったのではないかと思います。
そんな就職氷河期1年目でも、大量に人を必要としている業界がありました。システムの導入を手掛けているIT業界です。当時は「システムを導入すれば業務が劇的に効率化される！システムを入れなければ他社に遅れを取ってしまう！」と大企業がこぞって思い込んでいた時代でシステム導入に関係している業界に多額のお金が流れ込んでいました。
システムやプログラミングは全く分かりませんでしたが、コンサルティング会社に興味があった私は、総合研究所、戦略系コンサルティングファーム、会計事務所系コンサルティングファームを中心に就職活動を行っていましたが、その周辺領域ともいえるシステムエンジニアの会社も回っていました。
最終的に希望通りの会計事務所系コンサルティングファームに入ることになりましたが、数十社回って、「入社を確約してくれたら内定を出す！」と言ってくれた会社は就職した会社以外に2社だけで、どちらもシステムエンジニアの会社でした。
会計事務所系コンサルティングファームで会計のコンサルティングをやっていたのかというと全くそんなことは無く、そこで配属されたのは やはりシステム導入のコンサルティングの部署でした。当時、ドイツのSAP社が開発するR/3という基幹業務全般をカバーするシステムを日本の大企業はどこもかしこも入れようとしており、私もそのシステムのコンサルタントとしてキャリアを積み始めました。
先ほども書きましたが、私は当時システムの素養が全くありませんでした。私のような人間は日本中に腐るほどいたと思います。入社してすぐの頃、研修室に行くとプログラミングの本が置いてあり、会社貸与のPCを使って、「こういう機能を持ったプログラムを作ってください」とだけ言われて本を見ながらなんとか作るという研修もありました。こんな感じで素養ゼロからITスキルを詰め込み現場に送り出すということがどこのコンサルティング会社でも行われていたと思います。どうにも向いていない人もいる中、私はたまたま適性があったのかIT寄りのプロジェクトに配属されるようになりました。
今でもあるのかもしれませんが、当時は大企業が多額の投資を行いシステム導入を行うため、いきなり大規模に数百人単位のプロジェクトチームが組まれ、数年単位で導入計画が策定されるプロジェクトばかりでした。当時のR/3自体が非常に高価なシステムで、そういったやり方しかできなかったというのもあると思います。
しかし、このやり方は非常にリスキーで、失敗する可能性も高いものでした。まず、規模が大きすぎてコミュニケーションや情報共有に多大な労力がかかります。その結果、工程全体のクリティカルパス（プロジェクト納期を決定する最重要工程）が見えにくく、なんだかみんな忙しそうだけど遅々として進まないという状況があちらこちらで生まれます。責任の所在もわかりにくく、遅延していることを「俺はちゃんとやっている。他は何をやっているんだ」とみんなが人ごとのように感じるようになります。
結果的に、効率化云々を度外視してとにかくなんとかシステムを導入しようということにいっぱいいっぱいで、システムは入ったけどものすごく使いにくいとか、全然効率化されなかったとか、そういった可能性が高くなります。
今も昔も共通して言えるのは、「システムをカスタマイズできると考えてはいけない」ということです。カスタマイズが可能な場合はありますが、それでも運用の方を合わせないといけません。それには様々な理由があり、別記事にするレベルなので詳しくは書きませんが、私が当時参加した中で成功したプロジェクトはこの原則を曲げないプロジェクトでした。中には全世界から人が集まる大規模中の大規模プロジェクトもありましたが、この原則を守ったおかげで無事に導入できていました。欧米の人の方がこの原則に非常にこだわっていて、当時は「日本人とは違う、日本のやり方に合わない」という話がよく上がっていましたが、今になって断言できますが、そういう問題ではありません。改善要望をシステム開発業者に出すのは問題ありませんが、「うちは特別にこういうことをやっているから、特別にこういう風に変えてくれ、こういう機能を追加してくれ」というのは絶対にやってはいけません。
最近のシステム開発現場で感じたこと
よく、「大きな課題をクリアするためには課題を細分化しろ」と言われますが、最近のシステム開発現場を垣間見る機会があり、小規模・短納期でとりあえず入れて、後から修正していくというやり方が浸透してきていると感じました。
それでもやはり運用と合わないという問題はありますが、カスタマイズも原則できず、ソフトウェアもサブスクリプション契約と言って月額いくらという方式で使い続ける間払い続けるという方式のものが主流になっているようです。これは、ソフトウェアを売るのではなく、ソフトウェアから提供できるサービスを売っているという考え方で、ソフトウエア使用料を取るという考え方です。
運用と合わないというのはシステムの宿命的な部分でもあります。システム開発を行っている人間は当該業務を普段からやっていないため勘所がわからないという問題があります。そして、運用そのものが実は刻一刻と変化しており、システム開発開始時の運用とシステム開発完了時の運用は変わってしまっていたという可能性もあります。いずれにせよ、運用にシステムの方をフィットさせようとするのは無理があります。
システムに必要なことは、必要な情報を必要な時に必要なだけ示してくれることで、まずはその情報が何なのかを明らかにすること、次にデモ環境でそれが可能かどうかを検証するということが（それができるのであれば）最優先される事項になります。
当事務所では、システム導入のお手伝いもさせていただいております。ご興味がある方はお問い合わせフォームからご相談ください。初回のご相談は無料です。
