DXに失敗した話
【初心者優先枠】corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2 Advent Calendar 2020 18日目
お前誰よ
クリタと申します。働きたくないでござるが10年以上続いていますがいつのまにか情シスとして働いております。主にSalesforceをいじいじするのが得意な感じですが、スキルで食うというよりはべき論ぶちあげて、現場とキャッキャウフフするのが好きな多感なお年頃です。こういう場にアウトプットするのは初心者ですが、がんばって書いたので読んでください。つい最近、LTで喋ったネタはこういうふざけたやつです。
さて自分では成功と呼べるような成功もしていませんが、大失敗と呼べるPJにも関わってきましたのでそこをしっかりみっちりネトネトと語って参ります。
イントロ
過去に在籍した企業で、大規模なシステムリプレースに失敗しました。サービスインも行い3年ほどシステムも稼働はしましたが、最終的にシステム自体を棄却しました。
コンセプトとしては次期経営計画の中心となり、オフコンからPaaSに切り替え、最終的には、顧客と協力社双方に開放し使ってもらおうという野心的なものでした。
DXという言葉はまだ流行りではありませんでしたが、コンセプトとしてはレガシーシステムをモダナイズし、ブラックボックスとなっている部分を解体し、業務の変更、拡大に対応すると謳われておりましたので、DXのはしりともいえるでしょう。
システムの概要と、私がそのプロジェクトにどうジョインしシステムの終焉を見届けたか時系列を追ってはじめたいと思います。
システムの概要
・B2B企業向け修理受付コールセンターの受付/進捗管理システム
・依頼を受け付けるだけではなく、修理を行う協力社への手配もしている
・移行前のシステムはオフコン（AS/400）で稼働している
・受付件数は1日200件以上（完了するまでに数日～数週間かかる）
ビジネス上の特性
・1件あたりの単価は安く、とにかく数多く、短期間でこなすことが求められる
・依頼する企業によって受付ルールや依頼する協力社が異なっていたりと細かい決まりごとが多い
・修理の内容は専門資格が必要な内容もあり、適切な協力社を選ぶ必要がある
（水道の修理に電気系の修理が得意な協力社を当てられない）
・その協力社を選ぶ方法はオペレーターの長年の経験で選んでいる
どうでしょう十分やりがいがある仕事ではないでしょうか？
私が某社に中途で入社した際には、すでにこのシステムは稼働した状態で、サービスインしてから数ヶ月といったところでした。プロジェクト開始は入社の2年も前のことでした。
私の当時の立場としては、経営企画部門（の下っ端）でシステムの改善要望を取りまとめをしたり、利活用を提案したり、社員に対して利用方法をレクチャーするなどPMO的な働きをしていました。そこから紆余曲折を経て情シスへと異動となり終焉を見届けることになります。
失敗の原因
失敗の原因を端的に表すと下記になるでしょう。
1. 業務設計の変更ができなかった
2. システムのプラットフォームをのせかえただけという安易な移行
3. ベンダーロックからの脱却を標榜したが別のベンダーロックが発生した
4. 情シスへの不信
5. 揃わない足踏みと思惑 など
文章で表すとこう。
現状のままではいかんと危機感だけは先行してあった。その結果、大号令のもとプロジェクトは開始したが、現場には危機感もなく、今あることをなぜ変えなければいけないのか？という疑念があった。現場の「現業が忙しい」の言葉は、そのまま今できることを新システムでも実装すること、という業務を棚卸ししないままの要件定義となり、ここで手段が目的になる邪悪なプロジェクトが誕生する。情シスは情シスで受け身な感じでなんもしなかった（ここまで入社前）。危機感どこいった。
できあがったシステムはこう。
SalesforceとAS/400がWindows Server 2008で稼働するETLサーバーを介して連携しあう（CSVファイルを投げ合うだけともいう）お化けシステム（書いているだけで背筋が凍る）。Salesforceは哀れApexとVFで開発されつくした容易に改修できないシステムとなり、フロントとしての柔軟性もないシステムが出来上がった。しかもオンプレでやってたことをそのまんまクラウドでやるのでいろいろな制限に引っかかりまくりというお寒い感じになりました（しかもETLがこけると全部こけるし、SFがこけても全部こけるし、AS/400なんて当時いた人員だれもわからんし、業務はなんもかわらんし、で誰が幸せになるんだこのシステムでした）。
やってることはSalesforceから出力した帳票を印刷して、それに手書きで指示書いたり、別の印刷物をホチキスで止めてクリアファイルで別部署に回す、柔軟に対応できる紙ワークフローです（すてきー）。あと、それをFAXで協力社に送っていました（これは花王さんも苦労しているように、中小企業のほとんどが脱FAXできていないというのが理由です）。一部の懇意にしている協力社（というか一人親方）にはiPadを支給しておりましたが、何をしていたかと思います？業務にはあまり使わずXvideosとかいう素敵サイトを見ていたんですね。
失敗原因の深堀り
これは情シスの若林くんばりの鉄壁の守りです。これは途中で部署異動して入ってからわかったことですが、もう10年じゃきかないレベルで守りしかしてなかったんですね。やる範囲を決めてそれ以外ははねのける。情シスには何聞いても無駄って雰囲気が社内に浸透していました。そんな部署が音頭とったところで何が得られますかね。部下からの信頼厚いエルヴィンさんですら壁外探査の成果は何も得られなかったのに、これは無理ゲーですよね。
した悪あがき
まず私が年齢に逆らって髪を伸ばし（たつもりになって）若島津くんのように攻めの姿勢に転じました。といっても、システムの右も左もわからないパソコン=チョット=ワカルができるのは、社内をフラフラして開いてる席に座り、「なんか困ってることないっすか？」と隣に聞くことでした。
面白いでしょうが10年単位で言われたことだけしかしない情シスが話を聞きにいくだけですごくびっくりされるんですよね。そして聞いた内容をちょっとでもいいから反映していきます。そうなると「情シスなんか変わったぞ」、と社員に伝わるんですね。最初はおそるおそる、次第にタイガーシュートのような勢いで依頼、相談が来るようになりました。これはシステム的には失敗だったかもしれませんが、組織として得た大きな成果だと思うんですよね。
とはいえ一度作ってしまったシステムは小手先だけの改修でとどまり、現場レベルのカイゼンもなぜか上長が阻むといったよくわからない政治的な動きが発生して頓挫しました。
やってくる転機
みなさん御存知の通りSalesforceのライセンスは高いです、そして、ETLサーバーなどあることによりそれらのライセンス保守費用なども発生しておりました。費用はですね・・・会社の利益が吹っ飛ぶくらいに・・・。利益を出すためのシステムが足かせとなってはいけません。その状態で大きな転機が訪れます。会社が買収されました。今までの非効率を徹底的に精査され膿として出されます。システムは真っ先のやり玉でした。これは経営観点から見れば真っ当な観点ですし、当然の帰結だと私も思いました。
どうなったか
今までのシステムを廃止し、新しく親会社となった会社のシステムを導入しました。紆余曲折はたくさんありましたが、廃止となったシステムの導入時とは違い、信頼される情シスに組織が変わっていたことが要因で、現場のフルコミットメントも得られいいプロジェクトとできました。私も、パソコン＝チョット＝ワカルから、ジョーシス＝フンイキ＝ワカルになっていたかと思います。
まとめ
危機感ドリブンというような言葉も最近耳にしますが、危機感など曖昧な言葉のままプロジェクトが走ると思いも寄らない結果になることがあります。社内のいろいろな危機感などふわっとした感じのことを「言語化し、課題として捉え、解決策を練る」というところが情シスの楽しいところではないでしょうか。DXという言葉もふわっとして曖昧な言葉です。自社にとってのDXってなんですかね？正直、その答えは会社によって千差万別じゃないかなと勝手に思っています。自社にとってのDXってなんだろう？それを言葉にしてあるべき姿に向けて実行していく。素敵じゃないですか。それこそが情シスのやりがいです。やりましょう。Excelにマクロ組むだけでもDXでいいんです。FAXやめるだけでDXでもいいんです。ウォーターサーバーというオンプレをやめて水道という水 as ServiceにするのもDXなんです（暴論）。ただそれを遂行していくうえでいろいろな利害関係者の理解を得たり、戦ったりしていくことも重要だなとテクノクラートではない私は思います。失敗を糧にして思い思いの未来をDXという言葉に拘らずよい未来をみんなで楽しく描きましょう。
ちなみにこの会社では、雨漏りする箇所にサーバールームを移転した話や、隣にはいったテナントの工事で光回線を物理切断されたとか、近隣の変電設備の故障で自社のまわりだけ停電した、面白い話もありますが、それはまた別の機会に。それではまた。
この記事が気に入ったらサポートをしてみませんか？