誰も完成形をイメージできない
本来が売上を増やすためのアリバイのようなプロジェクトだったり、逆に収益には直接貢献しない社内のシステム開発などの場合、何を作るのかはっきりしないまま「きっと将来このぐらい売上に貢献するはずだ」「このぐらいコストカットに役立つはずだ」という漠然とした雰囲気でプロジェクトスタートしてしまうことも多く、結果として執行役員などの経営幹部は数字だけ“管理”して中身を部下に丸投げしてしまいます。部下は部下で、明日会議だからと前日徹夜残業して適当に会議用資料をまとめただけの掘り下げで説明することになりますので、誰も完成形をイメージできないままプロジェクトが立ち上がってしまうのです。
本来であれば、会社全体の方針にそって「こういうシステムが必要だ」という目的がなければなりません。でも実際には「同業他社がオンラインでのサービスを拡充しているから、うちもやらなければならない」というクソどうでもいい理由でプロジェクトが立ち上がり、しばらく経ってから執行役員などから「おいこれオンラインにしたはいいけどどうやって儲けるんだ？」という素朴な質問が飛び交う修羅に陥ります。突然の質問に呆然とする現場。「やれ」ってお前が言ったんだよ。
つい先日も、グループ会社全体で複数のサービスが並行して走っていては非効率極まりないので、せめてお客さまのIDとパスワードぐらいは統合しようという謎のプロジェクトが炎上したというので呼ばれて行ってみたら、統合後のIDとパスワードと各々のIDとパスワードを最低2つ以上お客さまに入力させなければログインできないとかいうピラミッドの秘密の扉みたいな仕組みが堂々と稼働していて鼻水が出ました。馬鹿なのかな。これ、見て誰も「おかしい」とか言わなかったんでしょうか。
数字だけではなく、仕事の流れを良くすること
また、店舗系でもすでに走っている取引先の台帳サービスと全く同じ台帳サービスを自前で始めようとして、まったく同じ機能の台帳サービスに同じ予約情報を複数入力しなくてはならなくなるという苦行のような仕組みを投入していて現場が大火災を起こしていました。どっちかやめるとかしろよ。それもこれも、自前で始めれば台帳サービスの利用料を総取りできて売上が増えるに違いないと馬鹿なことを考えた経営幹部が現場に相談せずに決めた案件なのだろうと思うわけであります。
つまり、プロジェクトというのは単に数字を目指すのではなく、現場の仕事の流れを良くし、稼ぐための仕組みがどれだけしっかり効率的に回せるようになるかを考えて進める必要がある以上、現場のことが分からずに数字や人員だけ管理していることで仕事をしているフリをしている経営幹部は一番大事なところを丸投げしてしまっていることになるわけです。
