ＩＴに巨額投資はもう必要ない―600億円の基幹システムを60億円で構築したＪメソッド導入法
ジェイ デュイベディ (著), 新生銀行Ｊメソッドチーム (著), 司馬 正次 (監修)
1998年に経営破綻した日本長期信用銀行が新生銀行として再生してから、基幹システムを刷新した際の手法の話。ベンダー見積もりでは3-4年の歳月と600億円のコストが掛かるシステムをわずか1年、たった60億円で構築し、サービスも24時間ATM利用手数料無料、キャッシュカード即日発行、インターネットバンキングを365日24時間稼働など実現しているシステムの秘密を解説した本。
新生銀行のシステムについての記事はhttp://www.ciojp.com/casefile/t/4/%E5%9B%BD%E5%86%85%E4%BA%8B%E4%BE%8B/153/%E6%96%B0%E7%94%9F%E9%8A%80%E8%A1%8Cが詳しいかな。 http://globe.asahi.com/feature/090216/side/09.html もあるが、こちらはアウトソース視点。
イマドキのシステム開発どうなっているんだろうというミーハーな気分で読んでみたので簡単に概要と、疑問点をまとめてみる。
Jメソッドとは新生銀行CIOのジェイ デュイベディの生み出した手法らしい*1
基本的な考え方は、ユーザ指向と、流通品を使った分散処理。Jメソッドは、一連の手法と実行体制をまとめたもののことで簡単には真似できない、ということ。また、視察に来る企業は多いが、うまく実現できたところはないのでこの本を書いたとも。
そのJメソッドの流れは次のよう。
■フェイズ1 ランドマップを作成する
変革の道筋と業務領域を設定するためにランドマップを作成する。ランドマップは商品ごとの売上や利益、それに関わる社員の数や顧客数、システムの状況などの数値を獲得し整理したもので、次の目的を持っている。
- 企業全体の姿を理解・共有する
- 企業内でコストを削減できそうなところを列挙する
- 自己のビジネスと規模を確認できること。
■フェイズ2 ペーパーモデルを作成する
現状の分析を業務フローチャート分析のように机上でやるのではなく、大会議室などを用いて、実際に使う書類や、必要な人員を可視化するように模型、ワークフローを作成する。場所を確保し続けなければならないが目に見える分、作成しやすく理解しやすい。このペーパーモデルをもとに分析し設計していく。各要素を変革するためのプロジェクトチームをつくり、検討させる。
また領域ごとにチャレンジ目標を設定し、そこでのコスト削減がIT投資を上回るときにIT投資を実施する。
■フェイズ3 モジュラー型モデルの作成
１．ペーパーモデルの各要素をインプット/アウトプットのつながりで捉える
２．同じインプット/アウトプットを出す既存のモジュールを市場やライブラリから探して置き換える
３．ない場合はインプット/アウトプットをさらに分解
４．分解してもソフトウェアがない場合は作成する
５．すべての要素をリンクし、モジュラー型モデルとする
※ここは一番曖昧な箇所。実際にどうするかは新生銀行の事例だが、http://www.ciojp.com/casefile/t/4/%E5%9B%BD%E5%86%85%E4%BA%8B%E4%BE%8B/153/%E6%96%B0%E7%94%9F%E9%8A%80%E8%A1%8Cが詳しい。安価なIAサーバでコンパクトなパッケージを動かし、可用性を高めるために分散をすすめるイメージかな。
■フェイズ4 モジュラー型モデルの導入とチェック
・順次住み替え・・一気に置き換えるのではなく、プロセスのモジュールごとに切り替える
・パラレルラン・・新旧同時に運用することで問題を調べる
・愚直な努力の継続・・違いを探して修正することを続ける
■フェイズ5 変革の達成度チェック
新システムと目標を比較。PDCAを回す。
基本的には顧客志向で丁寧にビジネスプロセスを分析し、細かいモジュールに分解、再構築して設計し、オブジェクト指向的にソフトやハードを組み合わせ製造、現場ではパラレルに導入・調整するという流れを強力なリーダーシップでもって実現するという手法らしい。
社内ユーザ志向アプローチとIT部門主導アプローチの両者の良い悪いを言及した上で、そのどちらの良いとこどりをした手法、と言っている点とか、全く新しいとか、革新的なという形容詞を多用していてちょと胡散臭いけど内容は、ユーザ指向に徹し、愚直。
直接はメソッドとして現れていないけれど特に大事だと思うのは、従業員をどう巻き込むかというところ。
・トップの継続的な説明と関与により納得させることで
・顧客に良いサービスを提供するにはどうしたらよいかを自分たちで考えさせる
・移行も、押し付けるのではなくシステムを並行して運用させテストしつつ徐々に馴れさせていく
これがなかなかできないと思う。
システムのユーザである従業員を巻き込んでいくという点でアジャイルな側面もあるのかな。
そして製造業のカイゼン的、BPMなイメージが強い。要素を分解して、複雑なものを単純にする。わりと古典的な考えだけど、これまではITシステムは複雑なもので分解することは難しいからしないという先入観を持っていたことが恥ずかしい・・・。
プロセス中の説明にも疑問と書いた、設計・製造プロセスについては、経営側向けに書かれた本という性質上、掘り下げていないのか、あるいはあえてぼかしたのかはわからないが、曖昧。ただ経営側の視点を意識して書かれた本であり、システム開発・システム投資についてあまり知らない自分が読むと、これまで意識しなかった見方も学べてわりと有益だったと思う。
実際に使えるかどうかは判断できない。そもそも使える条件が限られていて、おそらく一般の受託開発では使えない。強力なリーダーシップをもったユーザ企業主導のプロジェクトでのみ可能だろう。そういう意味ではベンダーに出る幕はないが、そういったプロジェクトにぜひ参加してみたいな。Jメソッドの要素々々は使えうる、かもしれない。特に金融の基幹系もPCサーバで構築できうるというのはもっと調べてみたい。そして、コストをかけずに利益をあげたいシステム会社と、いかに少ないコストでよいシステムをつかいたいというユーザ企業のせめぎ合いを認識できた。
いいシステムをつくるためには、かなり顧客企業にコミットしないといけないが、それは現場からの反発や技術的な複雑性、つまり高コストにもつながり、メリットがなくなる。そこで無難なシステムを、無難な手法で構築せざるを得ない。ユーザ企業も技術的な部分がわからず投資効果も不鮮明だし、現場は慣れ親しんだ手法を捨てたくないし、システムの導入によって仕事を喪うことにもなりかねないことから十分な協力を得られないこともある。
システムは複雑すぎて、作ってみるまで効果も定量的に測れないのに、コストや納期も不安定。IT投資はほんと難しい。コンサルとかSIerとかベンダーとかはどーすればいいんだろ、経営者、特にCIOはどう判断すればいいんだろとか考えさせられる。
あ、あとこの本欲しい人いれば東京付近ならあげますよー。連絡ください。
