PAGE TOP

採用情報ヘッダ画像

販売管理システムへの挑戦

冒頭

DVDやCDを販売する某ショップ「F」(仮称)全国展開するこのショップの1日の来客数はのべ数万人。しかし「F」の販売管理システムは、10年以上前の旧世代のものであった。
処理スピードの遅さ、商品数の増加、業界内容の変化・・・各店舗から悲鳴が上がっていた。

その頃MSCは、ある大規模システムの開発を終え、新たなシステム開発案件を模索していた。

冒頭イメージ画像

ユーザーとの折衝

何を作るべきかの話し合いにおいて、ユーザーの要望すべてを通すのは間違いである。
「あったら便利だ」をすべてシステムとして構築すると、コストや開発期間がかかるのはもちろん、システムの融通までが利かなくなってしまうからだ。

本当に必要なものは何か?

ユーザーと要件確定の打ち合わせが続いていく・・・

ユーザーとの折衝イメージ画像

システム分析

現在のシステムはどう使われているのか?
どう運用されているのか?
調査と解析をし、問題点を洗い出していく。

現行システムでの販売や在庫の管理は、限界を越えていることがよく分かる。

また別の問題も分かってくる。各店がバラバラなシステムの使い方をしていて、標準化されていない。

システム分析イメージ画像

システム分析イメージ画像

扱う商品数の増加に伴い仕入れ業務が多様化している。
誰もがスピーディに正確に在庫状況を把握できる在庫管理ができない。

POS(販売時点管理)システムの導入が必至であった。

費用対効果を充分に考慮し、開発コストを見積る。

開発チーム結成

「F」へのプレゼンが受け入れられ開発チームが結成された。
チームでの開発において重要なことは、最初のスケジューリングとその後の管理である。
メンバーひとり一人がバラバラに動いては、良いシステムは生まれてこない。

納期を厳守するために、万が一のトラブルも考え綿密なスケジュールが立てられていく。

開発チーム結成イメージ画像

基本設計

ユーザーの要件に応えながら、使い勝手を最大限にするにはどうすればよいのか。目先の便利さだけでなく業務が変化してもそれに対応できるようにするにはどうすればよいのか。

様々な業務のケースをイメージしながらシステム全体の構成を考えていく。

納得いくまで終わることはない。

基本設計イメージ画像

詳細設計

システム全体の絵は描けた。

次は実際のプログラムを作るための設計書だ。

プログラマーの誰に渡しても理解できるよう、
詳細な設計図を作成していく。

詳細設計イメージ画像

プログラミング

難しい技法を使い、複雑なプログラムを組めることが
偉いと思っている人がまれにいる。

実際はそんなプログラムはまったく役に立たない。

何故ならばそのプログラムを他人が理解できず、
修正も容易ではないから。

プログラミングイメージ画像1

プログラミングイメージ画像2

本当にすばらしいプログラムとは
他人が見てもすぐ理解できるシンプルなものだ。

そして、シンプルにすることは
複雑にすることより、実は難しい。

とことんまで無駄をなくし簡潔にするにはどうすべきか。

プログラマーの技量が試される。

単体テスト

プログラム完成。

果たして正常に動作するかテストする。
しかし、思った通りに動かない。

原因はなにか、
追及しプログラムを修正していく。

単体テストイメージ画像

結合テスト

各人のプログラムを結合させる。

単体のプログラムでは正常に動作しても
連結すると問題が発生してくる。

納品後のシステムトラブルは許されない。

あらゆるケースを想定して様々なテストが繰り返される。

結合テストイメージ画像

仕様変更への対応

ここに来て問題が発生した!

ユーザーとの仕様認識の違いが発覚したのだ。

再確認の上、仕様書を変更し、
至急プログラム修正とスケジュール調整を行う。

仕様変更への対応イメージ画像

運用テスト

やっと本番さながらの運用テストが実施できる。

実務レベルで耐えられるか。
ユーザーとともに稼働検証の最終チェックを行っていく。

運用テストイメージ画像

システム完成

無事に本番稼働した。

チーム全員の安堵、達成感・・・。
各々に満足顔。

このシステムで多くの貢献が実感できる。
お客様も満足してくださっている。
今までの苦労が報われる瞬間だ。

システム完成イメージ画像