基幹システムの電子記録債権への対応 Part12 支払系の解析

■　解析

システムの保守を担当してから8年。色々な開発案件や障害対応（こっちの比重が大きい）を行った結果、ほぼ全容は見えたのですが、商流買掛に属する部分については知見が不足しています。

全体のデータの流れは見えているのですが、細かい部分が全く見えないので、事前に解析する必要があります。という事で、一週間をかけて支払系の調査を行いました。

■　業務フロー

調査の取っ掛かりとしたのが、業務フローです。外部委託して開発したシステムなので、この辺りの資料が整っているのが幸いでした。業務フローを使えば、（実際の業務はともかくとして）システムの大きな流れが見えてきます。

後は、業務フローに記述されている機能を一つずつ確認して、データがどのように作られているのかを確認していきます。全体の流れが見えれば、どこに機能を追加（ないし修正）すれば良いかが見えてくるので、業務フローに記述を追加していきます。

まぁ、この時点では現場ヒアリングをしていないので、目安にしかならないです。良く分からない部分については、課題管理表を作成して書き溜めておきます。

■　工数見積り

依頼時に聞いていた要件は「現行の支払手形と同じような方法」だけで、細かい部分は全く聞いていません。これが、外注や詳細工数の算出が必要だったならば拙いのですが、社内での内製であれば、こっちの方が良いと思います。

開発中の画面や帳票などを随時レビューしていけば、考え方が間違っていたとしても修正が容易ですし、結果として使いやすい良いシステムになってくれます（と思う）。

さて、今度は業務フローの変更箇所と、システム機能一覧を付け合せて、開発対象機能の洗出しと新規機能の追加を行い、それぞれに対して重みづけを行います。

重みづけの判定基準は勘と経験！

・・・いや、実現したい機能数とか、アクセスするテーブル数とかも考慮するのですが、細かく分析しても誰も幸せにならないので、この程度で十分です。そもそも、最初から期限が決められていて、それに合わせないといけない時点で工数見積りの意味が薄いんですよね。

やっぱり、これが外注だったらそうもいかないでしょうけど。

■　開発プラン

修正した業務フロー、機能一覧、課題管理表、概算工数を持って、開発プラン（スケジュールとか）を打合せします。かなり納期がシビアだったので、リリースを数回に分ける分散開発とか、色々と考えていたのですが、結局は全て破綻しました。

なんでも、まったくの別件で大きなシステム開発が必要になりそうで、そっちを優先して取り組んで欲しいそうです。依頼者も、そっちの方に注力するそうなので、細かい打合せに参加する余裕もなさそうな気配なので、開発自体が無理そうです。

とりあえず、その別件とやらが目に見える形になるまで、暫く時間がありそうなので、要件の確認が不要、またはどうとでもなる管理系の機能の実装を進めることにしました。

重要なキーとなる個所については、別件が片付いてからって事ですね。

■　後書き

実の所、その別件については予想できていました。上司にも、それとなく言われていた案件でして。今回、最初から外注を諦めたのは、その辺りの理由が大きいです。

設計から実装まで、一括して外注できれば良いのですが、実際に設計を外注に頼むと、完全に外付けのシステムにしようとするので、運用も維持管理が大変になるんです。

既存機能と上手く組み合わせようとすると、工数が増大するし、開発失敗のリスクが高くなるので避けたいのは理解できるんですけど、納品されたシステムを維持管理する立場としては認められないです。


前回：基幹システムの電子記録債権への対応　Part11　本稼働、そして・・・
次回：基幹システムの電子記録債権への対応　Part13　絶望のPG修正

投稿記事の一覧：http://harikofu.web.fc2.com/

--- blog end ---