前提
- 筆者はSIer・社内SEを10年ほど経験しており、体験などを根拠に記述する
- 「業務システム」は企業の業務で利用されるシステムを指す
対義語は「コンシューマサービス」
BtoB/BtoC問わず市場向けのパッケージシステムを指す - 「システム開発」はプログラミングを伴うシステム構築の手段を指す
いわゆるスクラッチ/ハーフスクラッチ開発や個別開発
業務システムを取り巻く状況
- DXの追い風もありシステムの導入市場は活性化している
- 23年度時点でシステム受注(SIer,SESなど)の国内市場は約6兆5000億円。前年度比で6%増(参考：日経コンパス)
- ERPパッケージの市場規模も23年度時点で2494億円。前年度比で14%増(参考デロイトトーマツミック研究所)
システム構築手法の整理
| 開発手法 | 概要 |
|---|---|
| スクラッチ開発 | ゼロからシステム開発する手法。仕様や機能の自由度が高いが管理コストも大きい |
| ハーフスクラッチ開発 | パッケージの標準機能を利用しつつ業務に合わせるため開発ふる手法。日本ではこれが主流 |
| パッケージ導入 | 必要機能をまとめたパッケージソフトウェアを購入し導入する方法。自由度は低いが業界のベストプラクティスを適用できる |
この記事で言いたいこと
むやみやたらにシステム開発を行うべきではない
システム開発は実施すべき理由を認識した上で行うべき
システム開発が必要な理由
基本的な考え方として、システム開発よりも市販のパッケージの方がシステムとして高品質、多機能となることがほとんどである。
システム開発は多くとも一企業の一部署の人間で構成されるが、パッケージ製品は専門の業者が企業としてサービスを構築するため、シンプルに投入している時間、人などのコストが違う。
それではパッケージが存在する業務領域においては、パッケージ導入を選択するだけでいいのでは？と思うが、システム開発を選択する理由もいくつかある。
1.業務やシステムにパッケージがマッチしない
最もよくあるパターン。パッケージに業務がマッチせず、業務に合わせてシステム化を進める為にシステム開発を行う。
関連し、企業内では様々な業務システムを取り扱っているが、他の業務システムと連携する際にパッケージが連携の仕組みを担保できないケースがあるためシステム開発を行う。
2.システム化すべきか判断したい
システム導入初期では、そもそも対象業務をシステム化すべきか否かの判断が必要になる。
このような場合、業務側とシステム側で必要機能をすり合わせて見極めていくことになるが、自由度の高いシステム開発の方が効果検証を進めやすい。
3.パッケージが多機能すぎる
パッケージは複数企業に販売することを前提とするため、1企業にとっては多機能すぎてしまうことがある。
多機能なこと自体は良いことだが、多機能であればパッケージ自体のコストが上がるため、結果として割高になる。
システム開発により必要な機能に絞って開発することができる。
業務システムでのシステム開発は必要か？
自身の実体験を交えてシステム開発すべき理由をいくつかあげてみた。
おそらくだが、多くの業務システムでシステム開発を選択する際に当てはまる理由だと思う。
しかし、これは本当にシステム開発を選択する理由になりえるのだろうか？
2.3.はともかく、1.業務やシステムにパッケージがマッチしないという点について考えてみる。
パッケージは単一企業の業務を観察して作成されるわけではなく、業界のベストプラクティスとされる業務を基に開発されるケースがほとんどである。
少なくともパッケージを提供する企業はベストプラクティスを想定して構築する。
そうなると「パッケージが業務にマッチしない」というより「パッケージが想定する複数企業で実現できる業務が自社の業務に適用できない」という方が正確である。
また、想定する業務の中で連携が必要な場合は対象パッケージでは関連するメジャーなパッケージとのコネクタなども用意されている可能性が高い。
結果的に業務が適用できればシステムも追従できる可能性が高いということだ。
しかし、システムだけでなく業務もビジネス環境に合わせて最適化され改善され変化していく。
仮に現在パッケージが想定する業務にならないとしても、最終的には世の中全体でより良い方向に進んでいき、最終的にはベストプラクティスとされていることに落ち着いていく可能性が高い。
要はパッケージで想定される業務に集約されていく可能性が高いということだ。
このようになった場合、業務の改善に合わせてシステム開発を進めていくメリットはなんだろうか？
将来的にパッケージを採用することを見越し、今業務に適合するためシステム開発を行うという判断がなされることは良いと思うが、機能拡張すればするほどパッケージの優位性が増してくる。
このことから、システム開発を選択する際はつくりこみすぎず、業務が適用できるまでの一時的な策として採用すべきだと考えられる。
結論
上述した内容から、パッケージがある業務領域でのシステム開発は以下の条件で選択されるべきである。
- 小規模である
- 検証目的である
- 一時的なものである
業務では、小規模や検証用で開発したシステムをなし崩し的に使い続けたり、ユーザーの要求を受け続け複雑怪奇にしたシステムをお守りし続けるようなケースによく遭遇する。
このような業務システムを担当するシステム部門は「開発人員を大量に抱えてコストがかかってる割に対応が遅いうえ、低品質で、低機能なシステムだ」と各所から言われるようになり、企業内のプレゼンスが低下していく。
最終的にシステム開発を選択した場合や、今すでに継続的にシステム開発が行われている場合でも、パッケージに置き換えるべきではないのか、どこまで開発すべきかという点については常に意識すべきである。
そうしなければ企業として効果に見合った投資ができているとは言えないのではないだろうか。
最後に
本記事を書いた理由を2つ。
1.自身の考えを自分なりに整理し発信することで、フィードバックをもらいたい
2.これからITエンジニアを目指す人達に、システムの受託開発の実態を認識したうえでキャリアを描いてほしい
特に2.について、ITエンジニアとしてシステム開発をしっかり行いたいならば(自分は経験がないが)パッケージを提供する側の自社開発の方が望ましいと思う。
少なくとも私が見てきたSIerや社内SEで業務システムではこのようなケースがほとんどであった。
結果として、正しく判断した結果小規模な開発を行うか、負の遺産と化した複雑怪奇な大規模システムを担当するかの2択になりがちである。
検証目的で開発しているようなチームであれば最新技術に触れながら前向きに開発を行っていけるが、このようなケースは稀である。
それであればシステム開発が手段として選択される業務システムの開発ではなく、価値を生むモノづくりそのものである自社開発を仕事にした方がITエンジニアとしての経験としては良いと思う。
一方、業務システムを構築する役割の人たちは自分たちのビジネスと照らし合わせて適切に判断する能力が求められる。
自分たちにとってより良い選択をする為に準備し、計画し実行する力はITエンジニアからは少し遠くなるかもしれないが、ビジネスマンにとってはかなりポータブルで強力なスキルなのではないかと思う。
また、文章中ではフォローできてなかったがパッケージが想定する業務を自社で実現できない理由については別記事でまとめたい。これにはまた根深い問題が存在している。