事例3.建前だけの効率化・標準化
不動産管理会社の保守切れによる基幹システム更新の案件です。これは私がPM（プロジェクトマネージャー）でした。
当初は基幹システムを刷新し業務の効率化、標準化を目標にプロジェクトを進めましたが、実際にはあまり効率化できないことが分かりました。というのも、会社の売上規模は数百億円ですが、従業員数は数百人なのです。不動産管理会社という特性上、業務を効率化しても人件費率が少ないので、それほど効果は出せないという構造がありました。お金をかけてまで基幹システムを更新するのか？ と立ち戻ることになり、プロジェクトが迷走し始めてしまいました。
しかし、システムは保守切れなので更新は必要です。「どうしよう」というタイミングでプロジェクトに入りました。そこで「効率化、標準化は本当にやりたかったのですか？」と聞きました。すると、実は本当の意味で効率化、標準化したいと思っている人はあまりおらず、どちらかと言うと、やはり保守切れで変える以上、何か大義名文が欲しく、分かりやすい目標に乗ったという人が大半でした。
では、本当にやりたいことは何か「きちんとみんなで話しましょう」と、管理職全体を巻き込んだワークショップを企画しました。
その結果、出てきたアイデアは、このようなものです。会社がやらなければならないことは「建物情報の次世代への継承」だと。新宿や丸ノ内には高層ビルがたくさん建っていますが、ビル群は100年もつわけです。新宿ではすでに50年ぐらい経っている高層ビルもありますが、大規模なリノベーションして、まだ数十年使い続けます。
人間の寿命よりビルの寿命の方が長いわけです。担当者は入れ替わっていきますが、建物の健全性は一貫して維持しなければならず、建物情報を世代が変わっても引き継いでいくことが、これから特に重要になっていきます。その観点から見てみると、実はシステムの保守切れ以前の問題として、業務に様々な問題があることが分かりました。
まず紙の情報が多いこと。電子情報だったとしても各部門や担当者が個別に持っていて、建物という単位で整理・管理されていないということです。
それを元にBPR、業務を全面的に見直しました。その過程では、どうしても発生してしまう紙の資料をスキャンして建物情報として整理をすることも必要です。建物番号を入れると自動的に建物情報として整理されるようにするため、プリンターの総入れ替えもやりました。
当初、プロジェクトが迷走したのは、目指す方針が不明確の中、分かりやすい建前つまり効率化、標準化に飛びついたことが原因です。ワークショップに時間をかけ、みんなで議論をして、本来なすべきことはなにか、かなり奥深くまで考えました。プロジェクトの目標・目的を考えるとき、最初から綺麗な目標を立てることに、そもそも無理があったと思います。きちんとした現場の理解と、関係者を巻き込んだ議論、その上で自社のパーパスを再確認するところまで深掘ったのが、上手くいった理由と思っています
取り組みによっては当初、何が全体最適か誰も分かってないことがあります。建前に飛びつくのではなく、時間を取ってでも自分たちは何を大切にしなければいけないのか、考えることはすごく大事だと思います。
事例4.BtoB製造業の出荷プロセスのシステム化
4つ目の事例は、BtoB製造業の出荷プロセスのシステム化の事例です。こちらも私が主担当として入った案件です。ユーザー部門が1年以上の時間をかけてシステム企画を進めましたが、開発範囲を確定させることができていませんでした。
ユーザー部門とプロジェクトマネジメント部門、出荷書類を作る人たちが中心でやっていましたが、出荷依頼をもらって送り状や船積み書類といった書類を作る作業が、いわゆるエクセルの山になって繁雑になっていました。何とかしたいと考えたのですが、この部分のシステム化だけならコストはかけられない、しかし、このままエクセル作業を続けていくのもよろしくないとスタックしたわけです。
そこで、出荷情報が、全体としてどう動いているか、視野を広げて確認しました。
そもそも出荷情報は受注情報を元に、基幹システムから取得され、さらに終わりの部分では経理に連携されて売上計上されている。出荷の情報は当然、物流部門にもいっています。大事なポイントは、輸出の場合は輸出管理の手続きが必要になることです。出荷情報は出荷の部分だけでなく、様々なところで共有されていて、全体をデータベース化するのであれば、システム化する大義名分、費用対効果も成り立つという提案をしました。その時の実際のスコープ図がこちらです。
かなり広い範囲になりました。部門最適では極めて狭い範囲の業務改善、狭い範囲のプロセスの自動化でしたが、全体最適は、出荷という情報を扱っているプロセス全体を把握して、その中で業務をどう設計するかまで視野を広げた見方になっています。問題の原因は、やはりアーキテクチャの構造、特に情報のライフサイクルを把握できていなかったことです。普段、業務のオペレーションを担当している方は、そういう考え方で自分の業務を見ていないでしょうから、それを現場部門に企画しろという経営側、ITの企画のやり方自体に問題があったと思います。つまり、必要なリテラシーのない現場部門がスコープ設定を行っていたので、ずっと迷走していたのです。
そこで我々のような専門家が入って、ビジネスプロセスの可視化とシステム企画を一からやり直しました。気づきとして、やはりシステムの企画フェーズでは、アーキテクチャ、特にデータの流れをきちんと理解をしなければ、適切なスコープは見出せないということになります。
ライター
新聞記者、月刊誌編集者を経て2024年1月にLTS入社。北海道大学科学技術コミュニケーター養成ユニットを修了し、同大でサイエンス・ライティング講師を経験。著書、共著、編著に「頭脳対決！ 棋士vs.コンピュータ」（新潮文庫）など。SF好き。お勧めは「星を継ぐもの」「宇宙の戦士」「ハーモニー」など。（2024年1月時点）
