いざ基幹系刷新 みずほ、東京ガス、JALに続け


そもそも基幹系システムって何?

基幹系システムは、事業を支える、日々の業務の中で主として利用されるシステムを示し、BtoB、BtoCに限らず顧客との取引に関する情報が記録されます。いつ・だれと・どのような取引をしたか、もしくは企業内でどのような業務が行われたか、モノ・カネ・ヒトの流れを情報として蓄積し、決算報告の元として使用したり、管理会計の基礎データとして使用したり、会社の業務状況を把握するためなどに活用されます。製造業における生産管理システムや、卸業における販売管理システム、銀行における勘定システムなどが、基幹系システムと捉えられます。業界によって適用される法令が異なったり、業界独自の商習慣があったり、企業独自の商習慣があるなどの理由から、企業によって基幹系システムに求められる業務要件は異なります。基幹系システムの別の呼び方としてERP(EnterpriseResourcePlanning)という言葉も定着しておりますが、明確な違いはなく、現在では基幹系システム=ERPという理解で問題ありません。
日常業務の中で最も触れる機会の多いシステムのため、利用者からは、操作性やシステムによる業務サポート(業務ルールに従わない操作を禁止したり、警告メッセージを出したり)といった細かな要件が、経営者からは業務実態に即した、高い精度の情報の管理が求められます。

 

なぜシステムは古くなるのか?

システム自体はプログラムの集合体なので、経年劣化することはありませんが、事業を継続する中で、外部環境(法令変更や顧客からの要望の変化)・内部環境(企業合併や事業構造)の変化が発生します。システムもそういった変化への対応を求められます。例えば、新しいオンラインシステムとの連携であったり、顧客に関する管理項目の追加などです。変化に対応するためにはプログラムの変更が必要となりますが、プログラムを作ったときの技術者が退職してしまったり、作っていたソフトウェア会社が倒産してしまったり、システムの変更が仕様書やマニュアルに正確に反映されていないなどの理由で、システムの中の動きを正確に把握することが次第に難しくなっていきます。様々な要素が絡み合って、環境の変化にシステムを対応させることが難しくなった状況が、「システムが古くなった」状態であるといいます。
また他のパターンとしては、システムが動いているサーバーやOS・ミドルウェアの保守期限が切れて、今使っているシステムの引っ越し先が無くなってしまうということもあります。
古くなったシステムは、現行の業務に合わせてシステム自体を作り直すか、別のシステムを調達して業務をシステムに合わせ見直すかの判断が求められます。

 

大手企業がなぜ基幹系システム刷新に苦労しているのか?

大手企業は様々なシステムを連携させて使用しているため、基幹系システムを刷新しようとすると、それらの連携するシステムとの連携を整理するのが非常に困難になります。また、企業買収や経営統合などによって、同じような機能を持つシステムが複数動いているケースも多く、業務手順の統合も大きな課題となります。紙面で紹介されているみずほ銀行の例では、検討開始から稼働まで約6年、金額にして4000億円(スカイツリー7基分に相当)の一大プロジェクトとなっているそうです。また、基幹系パッケージ導入の際に必ず掲げられる「業務をシステムに合わせて見直す」といったお題目も、現場レベルの細やかな要望に合わせてカスタマイズしてきたシステムを廃棄するという現実を現場がなかなか受け入れられず、プロジェクトが遅延・頓挫する事例も数多くあります。特に海外製パッケージの場合は、グローバル展開しやすいというメリットはありますが、日本の商習慣にそぐわない部分が多く、導入のハードルが高くなります。

 

システム刷新で苦労しないためには?

日経コンピュータ誌が創刊となった1981年当時から、KISS(Keep It Short and Simple:単純かつ簡潔に保つ)が原則だと言われており、私自身もその原則は今も変わっていないと思います。将来を予測してシステムを構築することは不可能であり、今のやり方であったり、今後変わる「かもしれない」やり方を元にシステムは設計されます。重要なのは、誌面にもありますが、企業全体のシステム像を俯瞰すること、加えて私の考えですが、現場からの個々の要望に場当たり的に対応せず、システムを俯瞰しやすい状態を維持する姿勢で臨む事です。システムの利用者が変更要望を出す場合は、変更する一部分に限った話をしますので、そのまま要望をシステムに取り込んだ場合、他の部分と違う動きをすることになります。また、変更が影響する帳票など、アウトプット部分に変更が見落とされがちで、結果全体としてちぐはぐな動きをし始めます。全体の視点でシステムをとらえ、要求を今動いているシステムの設計と整合性をもって反映させる努力を続けない限り、あっという間にシステムは古くなり、ブラックボックス化して刷新が難しくなります。全体の視点でシステムを捉える立場の人、いわゆる情シス担当者には、整合性を維持することの重要性を伝えるためにも、パソコンやネットワークに関する知識だけではなく、業務を遂行する部門と対等に意見を交わせる交渉力が必要です。

 

パッケージ VS スクラッチ開発。結局どっちがいいの?

システム開発の鉄則として「銀の弾丸などない」という言葉がよく使われます。これは、どんな問題も解決する万能なシステムは存在しないという意味です。パッケージVSスクラッチの論争もこれに当てはまります。身も蓋もな言い方をすれば、導入する企業の進め方次第であり、正解はありません。最重要なのは、導入を進めるのはシステムを利用する企業自身であって、システムを提供するシステムインテグレータもしくはパッケージベンダでは無いという事です。ただし、導入する難しさの中身がパッケージとスクラッチでは異なります。パッケージの場合は業務をシステムに合わせることが前提になりますので、業務再構築を進めるに当たっての業務設計が難しさの中心となり、スクラッチの場合は業務要件をシステムに取り込みながら全体としての整合性を保つ、システム設計部分が難しさの中心となります。
パッケージであってもスクラッチであっても、必ずやるべきこととして、システム刷新を検討する際には、現状がどうなっていて、どのように変えていきたいのかを、利用者自身が文書として作成することです。IT業界ではそういった文書を要求仕様書と呼んだりします。要求仕様書を元に、スクラッチであればシステムインテグレータの選定を進め、パッケージであればRFP(提案依頼書)の形に書き直して、候補となるパッケージベンダに提案を依頼します。要求仕様書を作ることが難しい場合は、システムの発注先とは別の企業に、要求仕様書の作成を依頼しましょう。発注先に依頼すると、企業の実態に即さない、偏りのある要求仕様書になってしまうので、注意してください。