BA BLOG

コストを徹底的に削減する:④中期的な視点(部門改革(開発業務、運用業務、人材))

コスト削減は、だいたいは短期で終わってしまう。
戦略ファームは一気にワーっとやってしまうが、やりすぎるとリバウンドする。それはなぜかというと、組織と人が変わっていないから。
次に考えるべきは、組織と人を変えること、すなわち、情報部門の業務改革をすること。
何をしなければならないかというと、開発業務を効率化すること、運用業務を効率化すること、人の生産性を上げること、これに尽きる。

開発業務を効率化することとは、そもそも、開発が効率的になるようなインフラストラクチャーにする。あるいは、プラットフォームを入れることだと思ってしまうが、それは次。
最初にフォーカスすべきは開発プロセスを運用できるようにすること。
みんなが要件定義と言っているところのアウトプットを定義し、基本設計、プログラミングを定義、標準化していくことは外せない。
ただし、ワンパターンでは対応できないケースがあるため、少なくとも3パターンは準備する必要がある。
カスタマイズで作るパターン、パッケージを用いるパターン、基盤更改で行うパターンを持っておく。
プロセスを作ったとすると、あとはできるだけ技術標準を作っておく。要するに、余計なことは考えないようにする。

最近のプログラミングはどちらかというと、使えるユーティリティがたくさんあるので、一つ一つデータの定義をしなくても、データを指定すればあとは勝手にやってくれるような構成にする。
使えるユーティリティとかは考えずに決めておく。例えば、Unixはアウト、LinuxはOKとしておけば、検討する手間がなくなる。
なので、決めても問題ないものはルールとして決めておいて、考えなくていいものを増やしておく。すると、考えなくていいので、人も手間も不要になる。
それを技術標準という名前で作っておく。
逆に、品質サイドからこれをやらないとダメなどのルールもあるが、効率化のためにも活用する。
運用業務も一緒で、なければ文書化して、運用ってこういう風にやろうね、と言ってやる。
だいたいの場合、職人芸みたいな人がたくさん出てきて、「いやー、あの人がやるのにいくらかかるんです」とかいうから、おかしくなってしまう。
基本的には、運用は誰でもできるようにしていかないといけない。
なので、まずはマニュアル化し、手順化し、いろいろなものを誰でもできる状態をきちんと作っていく。これが一つ。

二つ目は自動化。
工場のプラントもそうだし、最近のITもそうだが、自動でやろうと思うと結構なところまで自動でできる。当然ユーザのOKをもらわないといけないため、どうしても手でやらないといけないところはあるが、なるべく運用ツール・監視ツールなどの〇〇ツールを仕組みとして入れていき、自動化をかけていく。
そうすることで、手順と言っているところも、人に依存しない形になっていく。
まだまだ出来ていないところは多いので、それをいくつかのパターンで自動的に徹底的にやっていく。

開発業務を変え、運用業務を変え、あとは人。
よく「パフォーマンスだ」「育成だ」というが、どうすることなのか。スキルを上げることかというと、ちょっと違う。
一番は、一番単価の高い人をいかに外すかを考える。
運用の中で高値になっている、この人がいないと回らない、みたいな人をいかに外すか。ということを考える、そうすると安くなる。
「スキルが」ということも大事だが、単価が高い人を残して、中間層をガバっと変える。それをベンダーに対していかに提供していくか。
いっぺんにやると危険なので、計画的に来年「誰々」はいないということにしよう、ということをやり、若い人に変えていく。
実はこれが育成。環境に置かないと、なかなかやらない。

開発標準・プロセスができ、運用の自動化も進んだ。あとは安い人に変える。なるべく安い人に育成という名のもとで変えていく。これを計画的にやる。
それをやる際に、スキルと呼んでいるものが何になるかというと、経験でこれあれだ、というものもあるにはあるが、インシデントの~書があったりして、なんとかなったりする。
あとは、本当に詳しい人に電話に出てもらえばいい。経験の部分は補う方法はある。
補えない部分はコミュニケーション。
同じことを言っても、ある人が言っても駄目だけど、別の人が言ったら「まぁ、わかったよ」ってことはある。これは経験に裏打ちされているところもあるが、コミュニケーションの頻度・やり方があるので、コミュニケーションをちゃんとする。
メールの書き方といったマナーの話に始まり、~会議の資料の組み立てというところはこうしましょう、要件定義書をまとめてサマリの書き方はこうしましょう、といったところであったり。
IT部門は、ユーザ・ベンダー・経営といったところにコミュニケーションをとらなければいけないが、95%は定型化できるので、なるべく定型化したコミュニケーションをとる。
残りの5%は企画提案のみ。ITを使ったビジネス創造といったものは、ストーリーやポエムが必要になるので、こればっかりは定型化してはダメ。だが、それ以外の定常的に動かす開発業務とか運用の定期報告の大半は定型化できる。
ユーザとの調整も大抵定型化できる。コミュニケーションといっているところを定型化し、誰々でないとダメ、と言っているところを極力なくしていく。これをやることで、業務改革が達成される。

まとめると、開発の業務をちゃんとする、運用の業務をちゃんとする、人を若い人にする。
こういう3つの組み立てを実行していくと、部門というものは若くて活性化されるので、効率もよくなっていく。

閑話休題。
使えないミドルはたくさんいる。どうするかというと、なるべく専門職に回していく。
予算管理だったり、調達やセキュリティなどの専門的な仕事は最近のITには増えているので、そういう若くなくて、使えないわけじゃないが、どうしようと悩んじゃう人には、~マネージャといった専門ポストを与え、管理系で頑張ってもらう。


プロフィール

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

年別アーカイブ