業務システム開発の舞台裏！部門間で要求が二転三転し、予算と機能のバランスが試される物語。経理部長のアイデアが奇跡の解決策を導く！
目次
旧ACCESSのリプレイス計画始動
A社（架空の会社）は、会員向けのオンラインサービスを展開しており、年間売上は85億円、会員数は3万名を誇ります。同社のサービスは、「りんご事業（年50億円）」「みかん事業（年20億円）」「パイナップル事業（年15億円）」の3つで構成されています。
決済方法は重要なポイントです。りんご事業とみかん事業は月額課金方式で、パイナップル事業は年払い方式となっています。
また、現行の請求管理はマイクロソフトOfficeのACCESS（データベース）を用いていますが、会員数の急増に伴い、新たな販売管理システムと債権管理システムの導入が必要になってきました。
各部門の業務要求を見ていくと、以下のような意見が出ています。
- 社長 「特に機能の要望はないが、次期システムの予算は5,000万円。開発費用をその金額内に抑えてほしい」
- 会員管理部 「ACCESS管理はとても使いやすかった。次期システムも同じようなシンプルな仕様にしてほしい」
- 経理部 「現在、売上・入金仕訳は会計システムに手入力。システム間をつないで自動仕訳をつくってほしい」
システム担当者はこれらの業務要求をまとめ、ベンダーに提案を依頼しました。結果、以下の2つの案が提示されました。
「提案A」は予算重視の案で、見積金額は5,000万円以内に収まっています。ただし、年払い機能には対応していません。
「提案B」は機能重視の案で、月額課金と年払いに対応していますが、見積金額が8,000万円と予算を大幅に超えています。
システム担当者 「希望は提案Bですが、見積金額をなんとかできませんか？」
ベンダー 「では、パイナップル事業の年払い決済をりんご事業とみかん事業と同じ月額課金に揃えるのはどうでしょうか？ 月額課金だけであれば『請求データ＝売上データ』となり、システムがシンプルになります。」
年払いを毎月売上計上する場合、請求と売上が異なり、システムが複雑化します。例えば、会費が月1,000円の場合、年払いだと請求額は12,000円です。初月の売上は1,000円だけで、残りの11,000円は前受金として処理し、サービス期間が進むにつれ毎月1,000円ずつ売上に振り替えます。
提案Bでは、請求データと売上データを別々に作成し、それを12等分して管理する機能が必要になるため、予算が3,000万円も超過してしまったようです。
システム担当者 「確かに、年払い機能があるとシステムが複雑になるのは理解できます。しかし、決済方法の変更はビジネスに影響を与えるため、会員管理部とよく相談する必要があります。」
すぐに会員管理部長に年払い機能の追加によってシステム予算が超過する話を伝えると、
会員管理部長 「なるほどね。りんご事業とみかん事業が我々の主力だけど、パイナップル事業のために高額なシステムコストを負担するのは避けたい。決済方法を変更しても売上に大きな影響はないだろうし、パイナップル事業も月額課金にすることで、会員管理部の業務が一元化できて効率化が図れるわね。」
このように、会員管理部長から月額課金への一本化の同意を得たシステム担当者は、提案Aを役員会で提案することにします。
社長から大目玉を受ける
しかし、役員会で提案書を見た経営者からシステム担当者へ緊急の呼び出しがかかります。
社長 「何を考えているんだ！ パイナップル事業の決済方法を年払いから月額課金に変更するなんて、その影響がどのようなものか理解しているのか？」
システム担当者は困惑しています。そこで同席していた経理部長が説明を行います。
経理部長 「この表を見てください。現在のパイナップル事業の年間売上は15億円です。会費が月1,000円とすると、年払いでは1月に入会した人から1月に12,000円を受け取ります。2月に入会した人からは2月から翌年1月までの12ヶ月分を2月に受け取ります。3月以降も同様です。」
システム担当者 「はい。」
経理部長 「年払いを月額課金に変更すると、資金繰りが6.6億円悪化することになります。」
つまり、パイナップル事業の売上が今後も同じであれば、常に6.6億円の資金不足が発生します。資金繰りに余裕があれば問題ないですが、厳しい経営状況では、6～7億円の追加借入が必要となり、最悪の場合は倒産のリスクもあります。
実際、情報システム部門やベンダーは会社の利益には注意を払っていますが、キャッシュフローまで考慮することは稀です。資金繰りの影響は見落としがちなポイントです。
システム担当者 「すみません、その点を考慮していませんでした…」
社長 「今回の件から学んでくれ。パイナップル事業の決済方法を月額課金に変更する選択肢はない。提案Bの年払い機能を含むシステムにしなければならない。ただし、見積もり金額の8,000万円は高すぎる。ベンダーと交渉して、どうしても5,000万円に近づけるよう努めてくれ！」
システム担当者は、社長の意見を受け入れ、改めて提案Bに対してベンダーと交渉を進めることにします。
無理やりの値下げ交渉
システム担当者は落ち込んで席に戻り、ベンダーに電話をかけます。
システム担当者 「もしもし、A社の○○です。販売管理システムについてなんですが、提案Bで進めることになりました。ただ、提案Bを5,000万円近くまで値下げすることは可能でしょうか？」
ベンダー 「8,000万円から5,000万円に？それは無理です。私の仕事が危うくなりますよ！」
システム担当者 「大変申し訳ないのですが、社長から5,000万円まで下げるよう指示されてしまって…。例えば、テストやデータ移行をこちらで全部やりますし、システム稼働直後のサポートも必要ないです。また、設計書や要件定義書などのドキュメントも削ることで、値下げをしてもらえませんか？」
ベンダー 「分かりました。そこまでおっしゃるのなら、社内で再検討します。ただし、テストなどの工数を削っても、値引きは最大でも1,500万円くらいだと思います。」
価格交渉はビジネスにおいて重要ですが、無理な要求をするとどうなるでしょうか？
テストが十分でなければ、システムのバグが解消されません。データ移行がおざなりになると、稼働後に混乱が生じます。さらに、システム稼働当日のベンダーサポートも断ってしまったため、問題が起こると現場は大混乱になります。
さらに、設計書や要件定義書などのドキュメントを削除してしまいました。これがないと、将来システムの改修が非常に困難になります。これはシステム開発の属人化やブラックボックス化を引き起こす原因となります。
将来の問題を抱える形で5,000万円に近づけたとしても、長期的には値引き以上の損失が発生することは明らかです。しかし、現実では目先の金額が優先され、こうした問題が頻繁に起こってしまいます。
経理部長がくれた解決のヒント
システム担当者は5,000万円に近づけないことで悩んでいると、経理部長が現れました。
経理部長 「調子はどうだい？5,000万円に収まりそうか？」
システム担当者 「正直、難しいです。もともと8,000万円だったので、6,500万円まで頑張りましたが、それでも予算が1,500万円オーバーしそうです。」
経理部長 「1,500万円か…。まあ、社長が許してくれれば何とかなるだろう。ところで、提案Aはどうして却下されたんだっけ？」
システム担当者 「それは年払いに対応できないからです。」
経理部長は、目を閉じて少し考えてから、答えました。
経理部長 「確かに年払いだと請求金額が違うけど、引き落とし依頼を出して入金管理する機能は同じだろう。」
システム担当者 「確かに、債権管理の機能は同じです。ただ、月額課金では「請求データ＝売上データ」ですが、年払いだと違うため、別の売上管理システムが必要になります。」
経理部長 「それなら、年払いの売上を経理部でExcel管理すればいいんじゃないか？」
システム担当者 「確かにそれも一つの方法ですが、経理課長からは自動仕訳を作ってほしいと言われています。」
経理部長 「もちろん、自動仕訳があったほうがいいけど、1,500万円も予算オーバーするなら、一部手作業が残ることも仕方ないだろう。課長ともう一度相談してみてくれ。」
業務要求を修正したベスト案
早速、システム担当者は経理課長に相談しました。すでに経理部長から話が通っていたらしく、経理部長のアイデアを元に、自動仕訳と手入力を組み合わせた修正A案を二人で考え出しました。
修正A案の基本コンセプトは「請求データ＝売上データ」で、年払いのパイナップル事業も一度12,000円の年会費で自動仕訳を行います。ただし、11,000円分は前受金であり、月末に振替伝票で手作業で処理します。
このため、前受金の根拠資料として「入会月別明細CSV」を出力する機能を追加することになりました。これが修正A案の内容です。
システム担当者は気付いていませんでしたが、明細があれば仕訳はサマリー形式で問題なく、経理の手間もそれほどかからないことが判明しました。
経理部は完全な自動仕訳を諦め、年払いの売上をExcelで管理することになりましたが、売上仕訳を95％超自動化できて大満足です。
そして、システム担当者は修正A案を、再度役員会に持ち込みます。
社長 「見積金額は5,300万円か。でも、当初8,000万円からよく頑張ったな。」
システム担当者 「ありがとうございます。経理部長のお陰です。」
経理部長 「いやいや、自分は大したことはしていないよ。」
社長 「それでは、次期システム開発を正式に承認しよう。引き続き頑張ってくれ。」
まとめ
ストーリーを振り返りましょう。システム担当者はまず、社長、会員管理部、経理部の意見を聞き、それを次期システムの業務要件としてベンダーに提案依頼を行いました。
提案は2つ。提案Aは予算の5,000万円以内でしたが、年払い機能がありませんでした。提案Bは年払いに対応していましたが、8,000万円で予算を大幅に超過していました。
パイナップル事業の決済方法を年払いから月額課金に変更することで、会員管理部と合意できたため、システム担当者は最初に提案Aを採用しようとしました。通常の企業であれば、このまま発注されることもあるでしょう。
しかし、決済方法を年払いから月額課金に変更すると、資金が6.6億円悪化することが判明し、提案Aは没となります。
選択肢は、年払い機能のある提案Bだけとなり、あとは8,000万円の見積もりをどれだけ5,000万円近くまで削るかという話になりました。システム障害リスクを承知の上で、システム担当者はベンダーに無理な値引きを依頼します。
提案Bで発注する寸前、経理部長から思わぬヒントをもらいます。経理部が一部の自動仕訳を諦め、前受金をExcelで管理することで、提案Aを基にした「修正A案」が生まれました。最終的にこれで正式発注ができました。
業務要求が変わっていく過程が伝わったでしょうか？ もし発注後にこれらが大きく変わると、開発が大幅に遅れたり、完成しても使えないシステムができてしまうことがあります。
システム開発に取り掛かる前に、システム企画の段階で十分議論を重ね、経営・会計・業務・システムの4つの視点で、システム構想を洗練させていくことが大切です。
