在庫・受発注管理 自社開発のすすめ
受発注、入出荷、在庫、支払請求の
管理を システム化する場合、
パッケージ（市販）ソフトを使用する
のか？
自社開発（他社依頼を含む）で
対応するのか？ の２点となります。
コストパフォーマンス（CP）が
一番良いのは、カスタマイズ無し
（個別修正無し）で、
自社業務に最適なパッケージが
見つかるのがベストです。
しかし、
・一部の業務は自社開発、
一部の業務はパッケージ
・一部の業務はパッケージ、
一部の業務は他社パッケージ
等の状況で業務を行っている場合、
業務変更が生じた場合の
データ連携が難しくなります。
パッケージシステムのデータ連携
同一会社の異なる業務システムならば、
そのパッケージ内のデータ連携は、
可能です。
=> この連携で、余分な経費が掛かるの
ならば、 自社開発、他社パッケージ
を検討したほうが 良いでしょう。
パッケージ製品のデータ連携は、
「同一パッケージ会社間の連携」を
除き、連携されるデータは、
CSVデータと なります。
※CSVデータ：Comma Separated
Values カンマで各項目が分割された
データで各種システムで、参照、
変更が可能
管理データが異なる場合に、
データ連携が行い易いデータ
レイアウト
しかし、「連携」という手順を
踏まずに、リアルタイムに他のシステム
にデータ反映を行うには、
データの送り側、データの受け側の
システムの修正が必要になります
自社開発か？ パッケージシステムか？
開発者は、自社要員または
パッケージシステムの
システム担当員になります
① 先ず、自社の業務を完全に
把握すること
・基本的な業務は問題ないが、
特殊な対応を 開発者に伝えること
・特殊な対応がシステム化できない
場合、 業務運用変更を想定
していること
→システムで対応できない場合、
現場業務の変更を想定
すること
※ 中小企業では、業務の流れが
疎かになっている 場合が非常
に多いです。
② 開発者に自社業務・要望を漏れなく
伝えられること
・自社要件を文書化（要求定義）し、
開発者に伝えること
（相互認証が必要）
・開発者がシステム化可能な範囲、
システム化不可（運用対応）を
明確に（要件定義）し、
両者確認すること
（相互認証が必要）
③ システム導入後の不具合
・上記の「要件定義」、「要求定義」
を踏まえて 明確な契約を結んで
いれば、問題ないですが、
ユーザー側では、不具合の判断
が明確には 分かりません
・ユーザー側の設定・入力ミス
→通常は、開発者より
手順指導がある
・開発者側のバグ
（システム仕様不具合）
→要件定義、契約条件を
踏まえて、 瑕疵対応に
なるのか？を判断し、
開発者へ対応依頼
※１：最低限MS Office環境
（Accessが使用可能な製品）が
あれば、１つの環境でデータ
ベース、処理記述、 画面、帳票の
開発が可能で、 開発生産性の高い
のが特徴です。
また、Office製品のためExcelとの
連携親和性もあります。
使用ユーザが増えた場合は、
データベースをaccdbより
MS SqlServerに 拡張すれば
多ユーザーでの使用が可能です。
※２：※１に比べて安定性は高いですが、
開発環境作成は、※１よりも
手順が複雑（別途、統合開発環境が
必要）になります。
※３：Webでの使用（インターネット
間で外部より作業可能）が 必要
ならば、選択肢はこれ一つです。
※１、※２に比べて環境構築に
多少の手間がかかり、 生産効率、
技術習得も※１、※２に比べて
低くなります。
また、外部からのアクセスが発生
するためセキュリティが 必要に
なります。
自社開発の要員をどうするか？
① 自社内で調達する
自社に業務内容をしっかりと把握し、
システム開発経験がある社員がいる
場合は、その方を中心に開発
グループを作り進めていくのが
ベストです。
② 自社要員＋他社要員
自社にてシステム開発力に不安がある
場合は、他社への依頼
（システム会社、人材派遣依頼）
することとなります。
どちらにしても、自社の要求を正確に
伝えて依頼することが重要です。
③ 他社要員のみでシステム開発
既に述べていますが、システム
開発者に 「丸投げしないこと」が
重要です。
実際の開発要員（SE、PG）は
他社の要員で あっても、担当のSE
との下記状況の 打合せは必須に
なります。
・要求定義、要件定義
・スケジュール、進捗管理
上記①～③にて自社開発するとしても
以下のドキュメントを作成、修正する
ことが重要です。
========== 開発前 ==========
・契約書（他社へ全面依頼する場合）
・要求定義
・要件定義
・外部設計書（処理と画面、帳票、
データとの関連仕様）
・画面、帳票、ファイルレイアウト
・内部設計書（処理の具体的記述）
・取扱説明書（システムの使用方法）
========== 稼働後 ==========
・不具合発生対応書類
（通常使用で不具合が発生した
状況記述と対応記述）
・システム変更仕様
（業務変更、法的対応等による
仕様変更）
<例> 2000年問題、消費税対応、
インボイス対応 等
また、他社要員を導入しても、
自社システム要員の技術スキルアップは
必要になります。
まとめ
M：メリット D：デメリット
① パッケージシステムの導入
M → 新規開発よりも安く導入できる
D → 「自社業務に一致するか？」
までの 判断に時間が掛かる
D → 自社業務に合わない場合、
自社仕様に 合わせるために費用と
時間が掛かる
D → 自社業務変更の場合、システム
改修に費用と時間が掛かる
D → 複数他社で複数システムを稼働
させると 業務間連携に費用と
時間が掛かる
② 自社開発
M → 社内作業のため、業務と
システムの連携 が取り易い
M → 仕様変更が発生する場合、
現場担当者と システム担当者の
連携が取り易い
D → 自社要員が確保できるか？
D → システム開発の作業がない場合、
システム要員の作業空きが
発生する
③ 他社依頼
M → システム作業が必要な場合のみ
費用と時間が掛かる
D → 自社要員より費用が掛かり、
システム仕様の説明に時間が
掛かる
<システム会社依頼の場合>
D → 自社業務変更の場合、
迅速に対応できない
D → 過去に依頼した会社に
再度依頼が 可能か？
（存在するのか？、作業依頼を
受けてもらえるのか？）
<派遣要員依頼の場合>
M → 比較的要員確保はし易い
D → 必要な業務、システムの
スキルが あるのか？