システムリプレイスの担当者になったら大失敗した話。と組織論について。

こんにちは。ユウキです。

私は日系の大手金融機関のサラリーマンでした。システムの最上流担当として改善&保守、そして事務のイレギュラー裁きをやっていました。

今日は、システムリプレイスの担当者になったら大失敗した話をします。

そして、どうすれば大失敗を避けられたのか検証します。


(元所属先に迷惑がかからないよう、フェイク入れたり、特定できないよう配慮します。ちょっと分かりづらいところあるかも。)

最初に、組織の歴史的経路を整理します。プロジェクトの成否を検討するポイントとして、この組織がどういった組織なのか、は超重要です(MBAで学びました)


【1990年ごろ】

・会社機能をざっくり分けると、『商品を企画し、契約保全する本社機能』と『自社商品のみを売る販売機能』の2つ(※ざっくりしすぎ!笑)

金融商品は差別化が難しい。(金融庁の監督があり、商品は認可が必要。よって、商品スペックは横並びになりがち。)

・商品の差別化が難しいと、会社の競争力は営業部隊に依存しがち。資源投下を営業組織にする…つまり、エース社員を営業部隊に配置。営業=出世コースの文化がつくられる。

・商品は約款で価格が定められている。提案するには、価格表と電卓で手計算。(IT活用なんて夢の時代

・現代と比べると、消費者保護の観点はないに等しい。(騙してでも)販売できる人が偉い。

【2000年ごろ】

一人1台のPCが配布され、煩雑な繰り返しの計算から解放されつつある時代。

業界全体の売上は高止まりし、コスト削減が経営課題に。

コスト削減に効くのは、システム化。煩雑な繰り返しの計算をシステムに担わせ、スタッフ部門の人件費抑制と、販売部門の活動効率向上を指向。

・一方で、消費者保護の法制度施工や、金融庁の指導により、チェック機能が多数追加される。オペレーションは複雑化

システム部門が別会社化。IT専門部隊としてノウハウが集積される一方で、サイロ化が進み、『本社にITが分かる人材がいない問題』が徐々に進行

出世ルートは相変わらず営業畑であるものの、経営課題としてシステムの重要性が高まっている状況

・そこで、人材配置を本社機能優先に。しかし、営業畑から異動してきた部長・課長級人材はシステムがわからず、『部下に丸投げ』が常態化。

【2010年ごろ】

・システムのレガシー化とスパゲッティ化が更に進行。ノウハウは別会社に蓄積され、本社社員は表層機能だけ把握している状態

・システム改修案件を本社主導でやりたいものの、金融庁の指摘や法制度対応に翻弄され、大規模案件と小規模案件とが繰り返し、波が起こる

・IT専門の別会社は波に対応するため、オフショア開発やその他金融機関からの案件を受注するようになる。本社と一蓮托生ではなくなったため、採算管理が厳しくなり、人事評価として導入される

・本社案件の採算管理も同様で、別会社社員は見積もりを高くして利ザヤを稼ぎたい動機が生まれる。本社は相見積もり先がなく、表層機能の理解しかないため、交渉力が弱い

・そんなころ、金融庁が”自由化”に舵を切り、代理店による販売が開始。(これまでは本社に雇用された社員しか売ることができなかった)

・代理店は新たな顧客にアプローチでき、また、顧客は複数の会社から商品を選べるとして、代理店チャネルは躍進。成長部門へ

代理店特有のオペレーションがあり、黎明期は人で対応していたものの、取扱い契約数の成長に伴い、システム化が検討され始める


そして、私は代理店特有のオペレーションをシステム化する担当者として指名されたということです。この歴史を長々と書いてきましたが、読者さんのなかには、何の意味があるんだと読み飛ばしてる人がいるかもしれません(読み飛ばすならまだ良くて、普通は離脱する量の長文ですね笑)。

ですが、もしあなたがリプレイス等の担当者なら、『歴史的経路』を甘くみてはいけません。私が失敗した原因の一つは『歴史的経路が見えていなかったこと』だからです。

もう少し踏み込んで言うと、『あるべきオペレーション(≒人もシステムも全て包含された業務の全体)を描けたとしても、組織の力学を理解して人を動かすことができなければ、机上の空論』です。この悲しき現実は、単なるシステム担当者としてシステムのことしか考えてこなかった私を打ちのめしました。私はドン・キホーテのように風車に立ち向かったのです。

さて、改めて状況整理した後に、どんなリプレイスをすべきか考えます。

状況整理

第一の経営課題は、売上成長に伴うバックオフィス部門のコスト増加抑制。つまり、システム開発保守費で固定費化して利益率を高めること。

第二の経営課題は代理店に学習負担・利用負担をかけないUI・UXの実現。代理店は販売手数料と使うコストを見比べながら、どの会社の商品を取り扱うべきか判断する。つまり、登録代理店数の拡大&売上増。

・現行システムはレガシー化&スパゲッティ化が進行。保守コストが肥大化。そして、その現状を真に理解しているのはIT専門の別会社のみ

・部門売上成長率とバックオフィスコスト増加率を見れば、リプレイスによる売上増及びコスト削減効果は見込めそうな気がする。ただし、要件定義の精緻化でも30人月ほどコストがかかり、想定外の開発費用の増大リスクは大きい。

システム開発費の回収期間は本社全体で3年と定められている。(成長が鈍化している販売部門の基準に引きずられる形で、本社一律3年となっている)

さて、どんなリプレイス策があるでしょうか。

リプレイス方針

現在的(2021年的)な考えでいうと、SaaS化がコスト最善案でしょう。金融庁が監督指導している業界なので、販売・管理のオペレーションのうち、7割ぐらいは共通で、残り3割が個社機能になってくるかと思います。その7割をSaaSにして運用保守をまるごと委託。各社は残り3割と”繋ぎ”をやるような分担です。

業界全体でコストダウンを図れる夢のようなプランですが、夢物語でしかありません。金融業界は新規参入が難しく、新陳代謝が少ない業界です。そして、本社機能はIT化による規模の経済が強くききます。商品の差別化は困難なため、販売の強さ=会社の強さです。もっとはっきり言うと、販売力がある代理店の手数料を高くできる会社=競争力がある会社です。SaaS化によって、〜小さい会社も、大きい会社も一律に〜本社機能のコストダウンができてしまえば、大きい会社の競争力が失われることに繋がりかねません。SaaSとは、小さい会社がオペレーションを共通化することによって、仮想的な規模の経済を手に入れる戦略、と言えるのです。新規参入が少ないこの業界でこの戦略(SaaS導入)は、よほどの進化圧がかからない限り、稟議は通らないでしょう。

やはり、個社案件としてリプレイスを企画すべきなのです。

リプレイスといっても、どこまでをスコープとすべきでしょうか。業務フローをゼロベースで見直してスクラッチ開発をするのか、小さな改修とUI統一で済ませるのか。代理店の利便性を優先すべきか、本社のコストダウンを優先すべきか。

判断軸は様々あり、正解がわからない、まさに経営判断です。こういったコンセンサス形成が難しい案件は、役員・部長クラスがリスクをとって判断するしかありませんイチ担当者が自分の論理的正しさを主張しても、反対者が上位役職者であれば潰されます。

私は要件定義を書く技術は持っていたので、このリプレイス案件がきたときにも要件定義を書こうとしました。しかし、上述の通り、経営の方向性が決まらなければ、どんなに精緻な要件定義を書こうが無意味です。最初にあるべきは経営判断です。

さて、役員・部長クラスの”虎の威”が必要な場面ですが、虎に会いにいくのは難しそうです。

・本社の部課長クラスはシステムを理解しておらず、部下任せ。生え抜きでシステムに携わってきた部課長人材もいるが、出世ルートは販売部門のため人数に限りがあり、代理店部門には配置されていない

・システム開発費の回収期間は全社一律3年で、これは成長率が鈍化している販売部門に引きずられた基準。成長著しい代理店部門では、よりリスクをとったファイナンス判断ができそうだが、”そもそも論”で交渉できる知識と発言権をもつ課長はいない。

つまり、自分の人事ラインを使っても、虎までたどり着きません。これには本当に困りました。課長クラスで議論しても、1歩も進まないのです。それでも、私には自分の人事ラインを使う道しか見えていませんでした。その結果、プロジェクトは頓挫したのです。

本当にやるべきだったのは、直属上司を超えて役員クラスの人に相談することでした。そして、部門外の実力者を協力者においてもらうことでした。頭を下げ、これが経営課題であるが、自分に進める実力はなく、上司でも進められずにスタックしている、と。社内に人脈があり、経験があるあの人の協力を得られれば進められるかもしれない、と支援を依頼すべきでした。

直属上司を超えて役員に相談することは、ヒエラルキー組織にとってタブーです。直属上司の顔を潰し、組織の命令系統ルールを逸脱する行為です。ですから、役員は相談されていないフリをしながら、裏で支援をしなければいけない。それだけの信頼関係を役員と築けていなければ、危険なチャレンジになるでしょう。

そもそも、これまでの歴史的経路で当部門にシステムリプレイスできる能力が備わっていなかったということであり、HRMで負けが確定している…つまり、人事戦略というか経営戦略で負けているということかもしれません。イチ担当者としては、『人事戦略で負けてるのにやらせんじゃねーよ』と言いたいところではありますが、しかし、今振り返ってみると、そこから成功させられるルートもあったんだろうなと感じています。

この話は私個人の経験談ではありますが、実は”大企業あるある”が多数含まれています。そこで、最後にプロジェクトの成否を握るチェックポイントを書きます。この長文を読む方が、私の屍を拾って成功されることを願って。

□経営課題は特定できているか。人を動かせるだけの危機感がある課題か

□プロジェクトメンバーは成功させるだけの実力があるか。メンバーに必要なスキル・人脈・権限は特定できているか

□プロジェクトが進まないとき、解決に動いてくれる人と繋がれているか

□難しい仕事を成功させるために、自分自身の成長に投資しているか

では。

この記事が気に入ったらサポートをしてみませんか?