開発要件の仮確定
前回(
基幹システムの電子記録債権への対応 Part2 基幹システム)いろいろと考えた訳ですが、いくつか計画を立ててコストを算出することにしました。
本当は、要件定義をしてからでないとコストの算出は無理なんですけど、そこは社内開発を前提としているので適当に見積もります。
そもそも、でんさいネットがまだ未稼働という状況では、要件定義といっても限界があるはずです。
そういう状況を踏まえて、あえてユーザーの意見は聞かずに、「法律で謳っている機能」=「開発要件」という事にしました。
現状で話を聞くと、必ず細かい話になってしまって混乱するだけですからね。
最も、これが社外に開発を依頼するのであれば、かなり細かく聞き取りをしないとマズいですけどね。
開発フェイズ
計画立案にあたって、まずは開発フェイズを分ける事にしました。
やはり、でんさいネットが未稼働で実際の業務が(想像でしか)見えないなかで、開発を進めるのは手戻りのリスクが高すぎます。
どうせ、当初はスモールスタートになるでしょうから、全機能をいきなり実現する必要は無いはずです。
最初に必要なのは「
電子記録債権を受け取る事が出来る機能」なので、それを中心に開発して、それ以外の機能に付いては、後回しにする事にしました。
分割、譲渡の実装、不渡も無い物として後回しです。
経理システムはパッケージを使っているので、発生した場合は手入力で仕訳を直してもらいます。
他には、でんさいネットから出力されるデータを取り込めるようにして欲しいと言われましたが、これも後回しです。
外部データ(テキストファイル)の取り込みって、書式チェック、二重取込みの防止策とか、不整合時のアンマッチリストの作成など、ユーザーが考えるよりもずっと面倒なんですよね。
何よりも、レイアウトだけで実データが無い状態では、事前開発に限界があります。
開発作業員に余裕があればともかく、ほとんど人がいない現状では対応できません。
ただし、基盤部分の設計レベルでは、ここまでにあげた全機能に対応できるように、考えておきますけどね。
計画立案
基本ベースは現行の“手形”を基本に考えます。
電子記録債権は、手形が持っている機能の大部分を引き継いでいるようなので、基本はこれで良いはずです。
後は、いくつか計画を考えます。
まずは、
電子記録債権のもつ全ての機能に対応する計画を一つ。
これは、完全に手形と分けた形で考えます。
もう一つ、いくつか制限をつけた上での計画を考えます。
分割に対応しないとすれば、既存の手形システムへの機能追加でも対応は可能と思います(後々祟りそうですが)。
この二つをメインにして、他には
電子記録債権を手形として考える方針もありますね。
電子記録債権の発生を、約束手形の受取として、データ上にはそれが電子的なものであるか判断するフラグを用意しときます。
そして、経理仕訳の作成処理で上手く仕訳を分けてやれば、そこそこ動きそうです。
何にせよ、開発計画の観点は、電子記録債権の独特の機能である“分割”をどう捉えるのかと、作成される仕訳の考え方が手形と違うという事になるでしょうか?
しかし、分割が無制限にできるっていうのは、システム開発上の難点ですよね。
いや、それ単体ならどうとでもなるのですが、経理仕訳や債権債務への未決済残高への連動、過去の時点の状態が分かるようにするといった条件が付くと、なかなか考える事があります。
ここは、データベース設計の腕の見せ所ですね。
コストの試算
コストの試算方法に、いろいろな手法があるのは知っているのですが、残念ながらずっと社内SEとしてやってきた私は、その辺りの技術には疎いんですよね。勉強しても良かったんですけど、時間がないので今回はパスして、別の方法を考えます。
幸い、基幹システムの機能一覧というのがあって、ここでいう機能の1件が1つの画面、帳票にあたります。
そこで、各計画別に対応する機能にチェックを付けて、それぞれに定型化した難易度を設定します。
そして難易度毎に、想定工数(日数)と金額を設定しました。
この辺りは、数年前に、とある機能を外注した時の実測値があったので、それを使いました。
んで、コストを出したんですけど、やっぱり凄い事になりました。
複数の計画の平均が、日数で300日超(一人工)で、金額が数千万円。
依頼した人たちは、単純に現行の手形に区分を追加する程度に考えていたようですが、各サブシステムとの連動を考えて行くと、結構な量になるんですよね。
世間様の状況は?
しかし、基幹システムへの電子記録債権の対応って、よその会社ではどうしているんだろうか?
ツテを使って、いくつかの会社の状況を聞いてみました。
それによると、手形の管理を基幹システムで行っていない(Excelベースで管理)ので、対応する事が無い。というのと、どの程度発生するのか分からないので、基幹システムの対応は様子を見てからにして、その間は経理システムに仕訳を手入力するという2パターンに分かれました。
まぁ、そうですよね。
現状で対応しても、手戻りが発生するのが目に見えてますからね。
プレゼンの結果
それぞれの計画案を説明して、判断は参加者にお任せしたのですが、結局は「電子記録債権管理システム」というサブシステムを立てる事で合意しました。
まぁ、そうなるように誘導したんですけどね。
何にせよ、これで下準備は完了です。
後回しにしていた要件定義でも始めましょうかね。
前回:
基幹システムの電子記録債権への対応 Part2 基幹システム次回:
基幹システムの電子記録債権への対応 Part4 要件定義投稿記事の一覧:
目次--- blog end ---
スポンサードリンク