2020
11/06
現在何周目?
「スクラッチかパッケージか悩んでいる」
ある企業の取締役の方からご相談を受けました。
その企業は、独自性が高く、多用なサービスを展開していました。そのサービスがこれまでの競争優位に繋がってきたと自己評価しています。
それらを支える現行システムはスクラッチで開発しており、多様なサービスに個別で対応してきました。
一方でそのシステムは肥大化し、プログラムがスパゲティ化しました。ほんの少しの変更を加えるだけでも「無影響テスト」で膨大な工数がかかります。
改修スピードが悪くなり、保守費用もかなりの高額になっていました。新規のサービスを投入したくても、見積もり金額を見ただけで戦意喪失してしまいます。
そこで「システム刷新」プロジェクトが立ち上がったのですが、どの方向でいくか、なかなか意見がまとまりません。
・この複雑すぎる現行システムを「パッケージ」に変更した場合、途方もないカスタマイズになり、原形をとどめないのではないか。
・それなら「スクラッチ」の方が柔軟に対応できるのではないか。でもそれだと今と変わらないのではないか。
・じゃあ、このまま「現行システム」を使い倒すのか。でもそれだとジリ貧になる。やはり「パッケージ」が良いのではないか…。
と堂々巡りです。もう何周目か分かりません(苦笑)。
「システム刷新」で必ず出てくる議論ですが、どのように考えていけばよいのでしょうか?
透明性のあるプロセスで進める
企業の経営層からは、必ず次のような言葉が出てきます。
「パッケージで業務を標準化したい」
そして現場に聞くと、必ず次の言葉を聞きます。
「ウチにパッケージは絶対無理。業務が独自だから」
経営層はパッケージを入れたがり、現場は拒絶し、我々のようなコンサルがわざわざ板挟みに合う、という構図です(笑)。
両者の言い分は立場上、ごもっともです。
経営層は、無駄を排除し、業務とコストの合理化を図りたい。
現場も好んで業務を複雑にしているわけではありません。顧客の要望にとても苦労しながら対応した結果、処理パターンが増えているだけです。
現場には「個別の頑張りを褒められることはあっても、責められる覚えはない」という心理的な背景も見えてきます。
このような状況で、どのように進めていけばよいのでしょうか?
弊社の答えはシンプルです。
「消去法でパッケージがなければスクラッチ」
きちんと選択肢を洗い出して、透明性を持って評価していくだけです。
ただし、全ての選択肢を入念に検証していると、いくら時間があっても足りません。アタリを付けた上で、効率的かつ合理的に進めていく必要があります。
経験的に、バックオフィス系(勤怠・人事・給与・会計など)はほとんどパッケージになります。社内の標準化、工数削減が目的になることが多いからです。
一方で、フロントエンド系(ECサイト・クライアントアプリなど)はスクラッチ開発がほとんどです。独自サービスを展開し、内製化でスピードアップも図りたいからです。
問題は、販売管理システムです。フロントエンド系(受注・契約・商品管理など)とバックオフィス系(請求・入金管理・会計連携など)が同居するからです。さらに、バックオフィスなのに請求・入金も顧客都合で「独自進化」を遂げていたりするので、ややこしくなります。
これらシステムの性質や位置づけを加味し、アタリをつけた上で、目ぼしいベンダーに「RFI(Request For Information)」を出していきます。その回答を見ながら、パッケージで行けそうか見極めます。
見極めが難しい場合は、そのパッケージの「トライアル」を行い、追加調査します。仮にそのトライアルが「有料」であっても、やる価値があると判断すれば、お金を払ってでもトライアルを行います。
それら情報収集を経て「市場の標準機能」と「自社の独自要求」のギャップを認識し、パッケージかスクラッチかの方向性を決めます。
その上で、ベンダーを絞り込み、「RFP(Request for Proposal)」を作成していく流れになります。
一次選考、二次選考、最終選考と透明性のあるステップを踏んで、徐々に選択肢を絞っていくという「消去法」を愚直にやるだけです。
現場が別人に変わった
「意外にパッケージが使えて、これなら行けそうと思った」
猛反対していた現場メンバーのコメントです。
冒頭の案件は、RFIで3つのパッケージが浮上しました。そこで現場メンバーを交えて、本格的に3つのパッケージでトライアルを実施しました。
本番データと本番シナリオを準備して、トライアルをしたところ、細かい部分で課題はあるものの、大枠で業務が回せる手ごたえを掴みます。
現場が一転して「パッケージ推進派」になると、話は一気にまとまりました。
現場にパッケージの説明に行くたび、皆さまの顔が「阿修羅面 怒」に変わり、机を叩かれ、罵声を浴び、胃液で口の中が酸っぱくなる生活ともついにオサラバです!(苦笑)
貴社の情報システム部門/IT部門は、「スクラッチ or パッケージ?」を合理的に選定していますでしょうか?
コラム更新情報をメールでお知らせします。ぜひこちらからご登録ください。
情シスコンサルタント
田村 昇平
情シス(IT部門、情報システム部門)を支援するコンサルタント。
支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。
多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。
また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。
「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。
著書の詳細は、こちらをご覧ください。