情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

システム再構築はスクラッチ開発か?パッケージ導入か?

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の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。