判断の出発点
業務のどこに独自の価値があるかから考えます。一般的な仕事は既製品を調べ、運用を変えると顧客への価値が失われる部分は独自開発を検討します。購入費と開発費だけでなく、運用全体を比較してください。
具体例で考える
架空の修理店で予約、部品管理、顧客承認、データ出力を「必須・有用・任意」に分けます。必須条件を満たさない案は除外し、請求への異議を含む修理一件を架空データで試します。
採用できない条件を比較に入れる
通常の作業、難しい例外、データ出力、権限、導入の手間、継続責任を表にします。不明は動くと推測せず不明と記します。間違いを直す人も含め、自社の例を実演してもらいます。必須ルールを設定できなければ、正式な拡張で対応できるか、その依存先を確認します。柔軟性という曖昧な評価を観察可能にします。
組織を変える費用も考える
既製品に合わせた変更が無駄を減らすのか、大切な約束を損なうのかを考えます。試用で二重入力、別管理の表、メッセージ承認を記録してください。それも運用費です。一方、習慣を残したいだけで独自開発を選ばないことです。許せる変更、教育の担当、移行中の過去記録へのアクセスを決めます。
退出経路を最初に試す
出力ファイルを実際に読み、ID、添付、関係が残るか確かめます。独自製品は別の許可された開発者がビルドとテスト復元を行えるか確認します。併用では記録ごとの責任元を定め、一部の置換で全履歴の再構成が必要にならないようにします。不明点を解く試用や調査を次の一歩にし、選択が適さなくなる条件も記してください。 一部を置き換えるときに、事業の履歴全体を最初から組み直さずに済む境界を確認します。
選択肢とその負担
- 既製品では保守の一部を任せられますが、変更は提供元に依存します。独自開発では自由度と保守責任が増えます。会計は既存製品に残し、承認だけを作る方法もありますが、連携の運用が必要です。
見落としやすい点
小さな便利機能を足し合わせて、実現できない権限制御を見逃さないでください。解約、データ出力、アクセシビリティ、障害時対応、移行、教育も比較します。
依頼前に確認すること
本当に差別化する業務は何か。最も難しい例外を実演できるか。誰が保守するか。個別開発の相談では、既製品で十分という結論も根拠とともに検討します。