システム屋の仕事としては、システムを新しく構築するだけでなく、以下のような仕事もよくあります（むしろこっちのほうが多いかも）
・ミドルウェアのバージョンアップに伴い既存システムに影響がないかテストする
・既存システムに機能追加を加える
このような仕事では既存システムがどうなっているかを把握しておく必要があります。しかし実際のプロジェクトでは既存システムの把握が非常に困難なケースがよくあります。
ケース１：設計書が無い/古い
既存システムを把握するために開発当時の設計書について開示を求めるのですが、お客様から「設計書？ 無いよ」とか軽く言われることもよくあります。また、設計書が更新されておらず実際のコードと矛盾していることもよくあります。
まぁ、この場合はコードさえあれば設計書を作成したり、修正することが可能なので手間は掛かりますが現行把握は可能です。
ケース２：実装機能に矛盾がある
実装されている機能の中でどうしても辻褄が合わない部分（たとえばデータの入力画面はあるけど、入力されてデータを表示する画面は無いなど）がある場合があり、このようなケースについては利用しているユーザーに確認を取ってもらう必要があります。（ユーザーに聞いてみると「あっ、それは今は使ってません」と言われたりして・・・）
このような場合におススメの方法は「ユーザーマニュアルを利用する」ことです。
なぜなら最終的に実装機能にOKを出すのはエンドユーザーであり、エンドユーザーが内容を確認できるドキュメントは「設計書」ではなく「ユーザーマニュアル」だからです。
ユーザーマニュアルが存在すればそれをベースに「提供すべき機能」を確認する(現状不要な機能も把握する)ことで、既存システムの把握ができます。また、ユーザーマニュアルが存在しなければ新規で作成することも検討すべきです。少なくともコードから設計書を起こすことに工数を割くのであれば、ユーザーマニュアルを作成した方がプロジェクト全体として作業効率が上がります。
ドキュメントが乏しく現行システム把握に工数が必要なシステムに対する前記したようなプロジェクトの場合、是非「ユーザーマニュアルの作成」を検討してみてください。
コメント