BA BLOG

コストを徹底的に削減する:③短期的な視点(ITにかかるお金を適正にしていく)

最近、ネットニュースを見ていると、お金に関するアドバイスや助言を目にすることが多い。もっとも、筆者の興味があるから仕組み的にそうしたニュースが選ばれているのだが、興味を差し引いても、従前に比べれば、お金の使い方や節約の方法、投資に関する情報はより親しみやすくなっていることは間違いない。
そうした記事の中の一つに、ファイナンシャルプランナーによる家計診断がある。支出の傾向を科目ごとに整理し、使いすぎと思われる費用を減らしたりする。情報システムについても、最初にやるべきことはいわばこの家計診断である。情報システムの家計が水膨れしていれば、無駄をなくす。相応以上に贅沢していれば、相応のものに変える。コスト削減の短期的な施策の目的は、平たく言うと適正化にある。ちゃんとやること、とでも言おうか。繰り返しとなるが、「無駄をやめ、節約する」ことに尽きてくる。

まずは、「無駄な持ち物を持っている」状態を解消する。もっとも、中小規模企業なのにグローバルスタンダードの会計システムを入れたというような無駄もあるが、そうした無駄は一気に解決できないので、構造改革の問題と考えて欲しい。
ここで言及したいのは、今すぐ辞めることが出来るようなものを洗い出すことにある。無駄は、多くの場合、PCやライセンスなどの購入物にあることが多い。社員の数よりもパソコンの数の方が多い、ライセンスの数が必要以上に多い、ソフトの切り替え時に余裕を持って在庫をもっていたが切替後に在庫の整理を忘れていたなど。無駄があれば、資産を適正な規模に圧縮する。最近の言葉で言えば断捨離だ。
因みに、この施策で実際にコストが減ることは、ほとんどない。当たり前なのだが、流石にそこまで無駄をしている企業は少ないからだ。皆さんの企業もそうだろう。どんなに探しても、無駄と言えるものはなかなか出てこないだろう。むしろ、すぐに出てくるようならば、ちょっとコスト削減的には重症だと考えたほうがいいだろう。
また、利用していないサーバがある、利用していないアプリケーションプログラムがある、などのケースも今まで経験したことがあるが、こうしたものはすぐに捨てられることはなかなかないので、短期的には期待しない方がいいだろう。

では、次に検討する短期策は何か。それは、コストが上がる意識を変えることだ。
情報システムのコストの適正化を阻む理由の一つは、現場はお金が欲しがる習性があるからだ。情報システムを担当している人ならば誰だって分かると思うが、情報システムの成功と失敗の最後の境目は、お金にある。問題が起きたときに、最後に自分を救ってくれるのは、お金である。現場の担当者、特に長く従事する担当者は、こういうことを、骨の髄まで知っていている。だから、予算の時にあの手この手を使って考えて、いろいろと水増しする。
こうした予算は、返ってくることはない。なぜなら、費消されないと来年以降は二度ともらえることはないからだ。担当者にしてみると、来年以降のことを考え、また周囲の仲間のことを考え、幸運にも使わなかった時、余ることがないように使いきるのだ。

因みに、「すごいIT部門」ではこうした水増しは許さないこととしている。徹底的に許さない。一円でも許さない。できる企業とできない企業の境目は、余裕を許さない案件調査・審査体制と実際にトラブルが起きたときの余裕費の持ち方の問題である。言うなれば、予算段階でどうやって水増しをいかに無くしていくか、ここにかかってくる。
一番簡単な方法は、見破れる人を配置し、あらゆる案件をそこに通すことだ。もしかすると、見破れる人がいないとおっしゃるかもしれない。ただ、それはその通りなのだが、要は相対の問題である。貴社が配置出来る中で、もっとも全体に目を配ることができる人をこうした調査・審査体制に配置すればいい。
良くある対策に、財務・経理の専門家を配置することがある。財務・経理部門は、日本においては強力な部門なので、確かに威圧することは可能となるのだが、如何せんITに関する知識はない。どんなに下げろとすごんでも、IT部門は聞く耳を持たないこともある。要は、IT部門が言うこと聞かなければならない人を配置する、そこに成功要因がある。

最後に考えるべきことは、無駄な案件をやらないことだ。
IT部門の案件の中には、「なんでこんな無駄なものやったの?」という案件が結構ある。中でも相当多いのは、経営トップが「これをやろう」と言ってくるものだ。「俺がこれをやりたいからやれ!」と言われて、上から突き通されたりすることもある。しかし、結局全然使っていなかったり、作る順番が無茶苦茶になっているので、似たようなシステムで同じ機能をあちこちに作っていることがある。

こうした3つの無駄をいかにして無くしていくか?が短期策の目標であり、目的となる。以降では、これらを無くしていくための具体策について説明をしていこう。

まずは資産を必要最小限にしていく。そう、上述した、ライセンスやPCだ。
何をするかというと、簡単である。全部を棚卸しするのだ。棚卸しして、いらないものを削っていく。

この一言に尽きる。
ちょっと肩透かしを食らっているかもしれないが、多くの企業においては、この棚卸という作業に工数が割けていない。結果的に、自分たちが今何を持っているのか、わかっていないことが結構あるのだ。最近でこそ、システム台帳が当たり前のように作られるようになっており、多くの会社が分かるようになってきてはいる。しかし、ではPCが何台で、ライセンスが何個で、NW回線の契約は何本でといったことまでは、実はまだまだわかっていないことが多い。
正確な言い方をすると、わかっている人が分散しているのだ。当然、管理担当者はわかっている。しかし、コストを下げなければと思っている人にはダイレクトに届かないことが多い。
こうした分散によって本当にいるのかいらないのか、下げなきゃいけないのか、ということがよく分からなくなる。だから、人を割き、情報を一カ所にまとめ、全部台帳にしてまとめ、「いる」・「いらない」をつける。
無駄があることが顕著な企業の場合には、こういう基礎的なことをするだけで、結構ぐっと下がる。ちゃんとわかる人をまとめ、台帳をきちんと作り、「いる」・「いらない」をきちんとする、という当たり前のことをする。そう、コスト削減を業務として運営していくのだ。

次は、水増しを減らすことを考える。これは予算段階のやり取りの見直しが必須だ。
上述の通り、みんな水増し、水増しでやっている。筆者が知っている日本でも有数の銀行の多くは水増しを認めている。なお、「すごいIT部門」の銀行では、水増しを一切認めてない。これだけでは当然ないのだが、相当のITコストのレベルの違いが出てきている。
この水増しの防止は、結局のところ審査体制の整備がいるということは前述した。ただ、それだけだと中々効果がしれているので、結局合わせ技が必要となる。
予算には管理側と申請側がいる。管理側の方が「ちゃんとした案件、すなわち水増しがない案件以外を認めないこと」を強く徹底することがまず第一である。
徹底とは、申請側に徹底することである。この時、例外を設けてはいけない。良くあるのは、経営が認める戦略プロジェクトなどでは、素通りするということだ。そうしたことはあってはならない。こうした例外を排除すると、申請側も水増しが認められないと理解し、徐々に水増し自体を悪いことと捉え、やらないようになってくる。
こうした体制とマインドが染み渡るよう、きちんとルール化しなければならない。

ではどういうルールを作っていくといいのか。最初は、予算にシーリングをつけることからだ。特に、経営企画サイドや財務経理の担当に多いのだが、投資としていくらかかるかをみて決めていきたいという人が多い。これは、ダメだ。なぜなら、IT部門は「いる」と思っている。そしてIT部門の裏には、お金が欲しいベンダーがいる。よって、どうしても水増し傾向は収まらない。ITの予算は、原理原則トップダウンで決めるべきだし、そうした勇気がない人は経営企画や財務経理といった部門にいるべきではない。
当然、これは大体いくらぐらいだろう、というのを順守できるケースもあれば、順守できないケースもある。しかし、人間とは面白いもので、低めの予算で「大体これぐらいの予算でやってね」というところから入ると、一応それに合わせて色んなことをやるようになる。工夫を始めるようになるのだ。
低予算の映画が思わぬ名画になることがあるが、それと同じ作用が起こる。無駄な要件は入ってこないようにもなるし、その段階で水増しをやろうとすると難しくなってくる。こうした枠を作れば、自ずとそこに寄って来るのだ。
こうした枠を作るのは、当然ベテランで勘のいい人がやるのがいいのだが、我々のような外部の信頼できるコンサルタントに助言を求めることも大切だろう。逆にそうした助言をもらえるような関係を常日頃からもっていないような人は、枠を決めるような立場に置かないようにしなければならない。

ルールの2つ目は、要員のマックスを決めることだ。IT部門の最大の要員は、実は外部にいることが多い。開発パートナーであったり、運用パートナーであったり。こうした人数は、案件が増えると増やし、減ると減らす。本来はそういう体制であるべきである。
しかしながら、こうした要員を変動にすることは、必ずしも得策ではない時が出てくる。そう、生産性が低いのだ。だから、何か一つのことをやろうとしたときに、え?そんなにかかるの?といったことが出てくる。
多くの企業で、IT子会社を持っているが、それはこの考え方に則るべきである。IT子会社は昔はいわゆるプログラマを安く安定的に供給するために作られた集団だ。時を経て紆余曲折しているが、その原点の発想は今でも有効だ。もっとも、現代社会においてIT子会社を持つことの難易度や意義は随分と変わっているのは注意したい。これはこれで非常に大きな問題なので、別の機会で議論したい。
話をもとに戻すと、「うちは500人月しか使えないから、年間500人月以上でやるな」ということを先に言っておくのだ。そうした中で、生産性目標をベンダーやIT機能会社と握る。そういう努力目標自体、ベンダーやIT機能会社は受注が安定するし、人も育てやすくなる。もっとも、絶対にやってはいけないのは、なれ合いだ。緊張関係は必須である。頼む側と受ける側が楽をしようとするのは危険だ。
この「総工数一定ルール」は別の問題への処方箋となる。それは、「どうでもいいユーザニーズを切ることが出来る」ということだ。多くの場合、ユーザがやりたいことはどうでもいいものが多い。薄っぺらい問題意識によって「これじゃだめだ」と思う、自分の得点稼ぎのために「何かやらねば」と思う、そもそも無理筋のニーズを押し付ける、などなど。ユーザニーズを絶対視する風潮があるが、所詮そういうユーザだって数年も経てばいなくなる。そんな不安定なニーズを聞いているより、むしろ心の中で「良い物を作っていく」と割り切ったほうが良い。そういう勇気を持ちたい。

ここまでは無駄を排除するルールを見てきた。その次に考えたいのは、そもそも無駄がないようにすることだ。それは、計画的にシステムを作り、運用するということである。
システムは、ニーズがあって作り始めることが多い。逆に言えば、ニーズがないと作らない。「あと1年待ってくれれば一緒にやって統合できたのに」「今やると全体的にキレイなシステムが出来るのに」ってことが多かったりする。
だから「なにを」「いつ」変えていくか、あらかじめ決めておいて「これとこれは一緒にやる」というのを宣言しておく。結局、中長期的なプランを立てるということだ。別の言い方をすれば、IT部門がちゃんとニーズを喚起するということだし、ニーズをコントロールするということだ。予算段階であまり突発的なことをやらせない。そういう具合にやることにしたい。
こうしたプランを明示して計画的にシステムを整備していくことで、サーバの乱立を許さない、ソフトウェアの乱立を許さない、データベースの乱立を許さない。そういう効率的な仕組みを作ることができる。これは、予算段階からやっておかないと、中々できるものではない。
近年の情報システムは、様々なもので作り上げる。これでもかというくらい新商品やサービスが出てくる。そもそも、混沌を招くようになっている。だから、必要となるのは都市計画である。東京の都市が、十年前とはガラリと変わって機能的で美しい街並みが増えているが、断捨離のように明日からできるというものではない。機能的で効率的なものにしようとすると、計画に則って粛々とやることが必要であり、そこにユーザを巻き込む、ユーザにシステム部門の意図をマーケティングすることがその成否を分ける。
多くの場合、そこそこはやっていることだと思うが、ちゃんとやり切っているかどうか、ユーザにマーケティングをきちんとしているかどうか、そうなると心もとないケースが多いのではないか。
多くの場合、鉛筆を舐めて決めていくが、「本当はいついるのか?」「効果はいつ出るのか?」「効率的に作れるのか?」ということをやっていくと、余計なユーザニーズが、シューって消えていくし、作る側も計画的に準備もできる。上手く共有が出来れば、偉い役員から「おらぁ、言う通りに作れ」と言われることも防げる。こうした元を作っていくことがコスト削減にも効くのだ。

ここまででもいくつかのコツを見てみているが、どちらかと言えば、予算段階で絞るということに重点をおいている。次に見ていくのは、執行段階だ。

執行段階でのコスト削減は、案件統制がちゃんとできていることが一丁目一番地になる。
以前ブログでも書いたが、一番は「要件定義をちゃんとしましょう」ということ。
いらないものを作ることも要件定義で決めているし、失敗というコストが一番上がる原因も要件定義のところで起きているので、きちんと期間を引いてやる。
二つ目は、最近ほとんどのところでやっている「調達のプロセス解析」という選定プロセスをきちんとやること。
頼むときに、ここをこういう感じで、と適当にやってしまうと、適当にお金がかかったりするため、面倒だがちゃんとRFPを書き、誰に渡すべきかをきちんと評価し、決定していく。
そうすると、ベンダーさんがちゃんと競争してくれるようになる。
単価の問題もあるため、寄りすぎたなと思うと違うベンダーさんに振ってあげる。こっちがそうしてあげないとビジネスできなくなってしまうため、逆に分散しすぎないようにいく。
そんな感じのことを、ちゃんと「調達」行為をかますことで、できるようになる。

もう一つできるといいことは、コスト情報を色んな所からちゃんと収集してくること。
情報システムの人は、どちらかというと内にこもってユーザとベンダーとの間で手いっぱいになることがあるので、ちゃんと外交をすること。
他の人たちはどうやっているのか、だいたい日本は行間というものがあり、公の会議では言ってくれないが、飲み会に行ったりすると「うちいくらでやってるよ」と言ってくれたりする。そういうインフォーマルな場では、「実際どうなの?」みたいなことを交換できる。
そういう関係性を作って情報交換をし、自分たちの相場感ってやつを磨くようにする。
その上で、これをやる時に「いくらぐらいなんだよな」ということをやる。

あとは、たまにベンチマークをやるのは本当によい。
何がいくらかかっている、高い低いと言っているものを、ちゃんと人間ドッグに入って検査をする。
お金に余裕があるんだったらやった方が良い。
そうやって、きちんと情報をもって、ベンダーなり何なりをコントロールできるように、調達をかましていく。それが、執行段階の適正化である。


プロフィール

宮本 認 Mitomu Miyamoto
BA参画前は、某外資系ファームで統括を務める。17業種のNo1/No2企業を経験した異色のIT戦略コンサルタント。

年別アーカイブ