（本記事はBizauthが提供する「BA BLOG」からの転載です）
今回紹介するのは流通業のIT部門である。仮にC社と呼ぼう。現在は非常に業績が好調で、海外展開も順調に推移している。C社のIT部門は、ITが経営に貢献するとは何たるかを正しく理解しているのだ。
A社の例では、徹底したコスト管理が経営に大きく貢献すると述べた。しかし、ITは経営になくてはならない要素の一つであることに違いはない。C社の場合は、これを本当に必要な範囲内で、かつ低コストでやり切っているのである。
あまり背景を言ってしまうと社名が特定されてしまうので割愛するが、C社は多くの流通企業と同様に、業績の厳しい時期があった。従来の成功モデルが通じなくなるタイミングがやってくる中、そこで新しい成功モデルを創造できるかどうかで企業の存続が決まる。この危機を乗り切るのに大きく貢献し、その後の成長を大きく支えるIT部門へと脱皮したのがC社である。
経営からの要求は過酷だった。ITコストを半分に削減にするという命令がくだったが、当時のIT部門長にこれを断るすべはない。やらないと会社がつぶれてしまうのだ。それほど深刻な状態だったそうだ。C社はここで構造改革に乗り出した。
ITコストとは結局のところ、人件費（自社内、ベンダーを含む）や設備費（ハードウェア、設置費用、電気代など）に収れんされる。これらを半分に減らそうとすると、ベンダーに支払う人件費や設備費を削減しなければならない。問題はどのように実現するかだ。
まずはベンダーの人件費だが、システムの追加開発や保守運用などをやめてしまえばいいのだ。インフラの種類を統一してしまえば、ベンダーに支払う人件費を抑えられる。もう一つは、ベンダーに頼んでいる仕事を自社でやるようにすればいい。どんなに安いベンダーでもその会社の販管費と利益が上乗せされる。だから、そこを削減するために自前でやるのだ。
ハードウェアについても、メインフレームからUNIXサーバ、IAサーバなど、さまざまなアーキテクチャが存在する。最近はIAサーバも性能や信頼性、可用性が高まっている。IAサーバにまとめてしまえば、インフラにかかるコストを大きく下げられる。
理屈で言うのは簡単だ。しかし、実際はさまざまな問題や課題が噴出し、「そうなんだけどね」とやり過ごされてしまう。C社の場合は、これをやり切ってしまったのである。
C社はまず、システムを大きく二つに分けた。一つは基幹系。POSシステムや発注端末、ストアコンピュータ、配送管理システムがひも付いている。C社はこれを変えないと決めた。変えようと思えば変えられるが、今回は変化させずにただ「運用するシステム」と決めたのだ。そうすれば、ベンダーに支払う人件費を最も低く収められる。
そして、C社は情報系を「変化するシステム」と決めた。C社においては、情報系システムとは店舗の運営をサポートするシステムで、在庫を把握して当日の売れ行き・売り上げを管理し、今後の発注や要員のシフトを決めていく、まさに店舗経営を支援するのためのシステムである。ここは店長や店員、顧客からさまざまなニーズを吸い上げて、機能の追加や変更が起きる。これをベンダーに委託するのをやめ、内製化したのである。
システムの内製化というのは、言うは易く行うは難しである。まずは内製要員の確保だ。システム開発の未経験者にやらせたのである。日本はコンピュータサイエンスで遅れを取っている。そのため、優秀な人材が少なく、社内教育を行わなければならない。だから、どうしてもベンダーに頼ってしまう。そこでC社は、「プログラム」と「開発手法・開発管理」を簡単にすることを考えた。誰にでもできるようにし、教育を不要にしたのだ。
まずプログラムについては、誰でも簡単に書くことができる「シェル」で全てを作ることにした。C言語などの専門知識が必要な環境は眼中になく、Javaのような言語でさえ「難しい」と判断して、シェルでプログラミングまでやることにした。一切の例外を認めず、とにかく全てをシェルで作ることに徹底した。
開発手法も徹底している。要件定義は「画面」イメージを作るだけだ。要はプロトタイピングをして、「ここにこれを作ればいいのですね」ということをユーザーと話して決めるだけにしてしまった。誤解もなく、早く進む。ドキュメント類は一切作らず、全てプログラミングの中にコメントするようにした。ドキュメントが直っていなくて、最新の仕様が分からないということがよくあるが、そういう無駄や手戻りが一切なくなり、最小の労力で最新かつ正確な仕様を管理できる。まさに一挙両得である。
ここまでシンプルにすると、ハードウェアなどに過度な負担がかかるときがあるのではないかと思ってしまう。情報系といえども、経営に欠かせない非常に重要なシステムだから、インフラのパフォーマンス管理はやはり専門的な人材が必要なのではないか。ここでもC社の解決方法は思い切っている。「しょせんはIAサーバだから、インフラ面で問題が出たらすぐに買い足せばいい。悩んでいる暇があれば、その方が効率的だ」というわけだ。C社は流通企業の1社に過ぎないが、まるでGoogleのような発想をすることに驚いてしまった。
こうしたITおよびIT部門の構造改革は、やり切ることも難しいが、維持することも難しい。維持の局面で特に問題になってくるのは、人材の継続的な獲得と育成である。ここで威力を発揮したのが、簡単なプログラム構造や開発手法だ。情報系のシステム一覧を見せられて、「これがC社の情報資産です」と紹介される。最初は「はぁ？」と思ってしまうのだが、話を聞いていると深く納得する。初めてやってくる人は、これさえ見せればいい。しかも中に書いているものは、最新であることが保障されている。後は、シェルのプログラミング方法を教えるだけで、誰でもすぐに実力を発揮できる。
そして、C社が特に気を使っていたのが、人の行き来だ。ユーザー部門、ビジネス部門にとって、業務を横串で見られて課題を発見できるIT部門に要員を派遣することは、潜在的にニーズが高い。しかしながら、いったん送り出してしまうとなかなか戻ってこない。だから、C社は人を戻すことに注力する。それが可能なのも構造改革があってこそだ。なぜなら、新たな人が入ってきても、すぐに実力を発揮できる環境を整備してあるからだ。ローテーションさえきちんとしていればいいのである。
C社がここで取った施策は、実は「Pace Layering」「Technology Standard」「Sourcing Optimization」といった、さまざまな効率化手法を駆使している。筆者のようなコンサルタントにとって斬新さはないのだが、ここまで徹底してやれるということ自体に驚きを感じてしまったし、画期的で尊敬さえしている。正直、われわれコンサルタントの出る幕はない。
もっとすごいのは、こうしたことをコンサルタントの手助けなしにやってしまったことだ。自分たちの状況や持っている資源（人材や予算）などの限界を突き詰めて考えることで、対策を編み出したのだ。グローバルでも通用する施策、すなわちグローバルスタンダードになっているともいえるだろう。
大切なのは、スタンダードありきではないということだ。自分たちが何をすべきか、どうなるべきか、そこから入って改革をやり遂げ、あるべき姿を見つけ出していることである。ここを考え抜いてやり切ること、やはりそうした手間がIT部門を良くするいい事例だと思っている。
