※この連載は「なぜ、システム開発は必ずモメるのか?」(細川義洋著)のCHAPTER1を、著者と出版社の許可の下、一部修正して転載するものです。
クライアントの大手スーパーを訪れた塔子は、社長の長男であり、かつて1度だけデートをしたことがある越後章介に再会。オンラインショップシステム開発を任されたと喜ぶ章介に、塔子はパッケージソフトを使った開発の危険について忠告します。
塔子、塔子じゃないか! ほら僕だよ、元カレの章介。
元カレじゃないし。ってかアンタ、現場に修行に出されてたんじゃなかったの?
修行? したよ。四国の丸亀店でね。レジとかバックヤードとか。そうしたら店長が「もう、坊ちゃんに教えることは何もございません」って。
あまりに使えなくて邪魔なだけだから帰ってくれってことね。で? 今度はどこの部署に迷惑掛けてるの?
システム企画室だよ。今度、ウチでもオンラインショップを立ち上げることになってさ。その責任者ってわけ。
大丈夫? オンラインショップは大量データを一気に処理する速度と、1円の間違いも許されない正確性が必要だし、パソコンやスマホが使えないお客さんもたくさんいるから、構築が難しいシステムなのよ?
大丈夫、大丈夫。知り合いの開発ベンダーがね、パッケージソフトっていうの? オンラインショップ用に出来上がってるソフトを持ってきて、ウチ向けに改造すればすぐできますって言うんだ。
大丈夫かしら。パッケージソフト導入の失敗って、年中聞く話よ。
そうなの?
ついこの間もあったわ。学生数が何万人もいる大学で、学生の履修届けをWebで受け付けるシステムをパッケージソフトで導入しようとして、学校の規模にソフトが対応できずに失敗したって話※1。
どういうこと?
1人の学生が履修登録をしている間、その科目を他の学生が同時に登録できないようにする仕組みがなかったの。専門用語では、排他制御って言うんだけどね。
同時に登録してもらえばいいじゃない。
そんなことしたら、定員50人の講義に100人が登録できちゃうでしょ。人数の少ない大学ならともかく、何万人もいる大学の人気講義だったら、履修登録期間にアクセスが集中して、同時登録しちゃう危険が十分にある。
だったら、ソフトを修正してもらえば?
そこが問題。パッケージソフトっていうのは、1つ作ってたくさん売るから安く提供できるっていうビジネスモデルだから、個別の対応は極力行わないの。データの排他制御なんてやればできるけど、いちいち対応してたら開発会社も身がもたないから、なかなかやってくれないのよ。
でも、結局は個別にいろいろ対応しなきゃダメでしょ?
だから、パッケージソフトは大抵、プログラムを直さなくても設定で出力項目を変えられたり、ソフトにない機能を後から付け加えられたりするのよ。ある程度はね。
ふーん。頭いいんだね。
アンタにくらべりゃ霊長類はみんな天才よ。別に詳しく理解する必要はないわ。パッケージソフトは業務に合わせて、ある程度変更できるようになっているって分かればいい。
じゃあ、問題ないじゃない。
“ある程度”なの。限界があるのよ。
※1 東京地方裁判所 平成22年1月22日判決を基にしたフィクション。ある学校法人のシステム開発で、学校の規模を考慮した要件をユーザーが指示しなかったために不具合が多発した。裁判所は、「新システムは、複数学部の多数の関係者が同時にアクセスする(中略)という理念のシステムである。そこから、仮に被告が具体的に指示をしていなくても、フィットギャップ分析および詳細設計作業を請け負っていた原告が、同機能アドオン又はカスタマイズなどによって対応することが必要であったものといえる」としてベンダーに一定の責任があるとした判決。
Copyright © ITmedia, Inc. All Rights Reserved.