その要望はできても、そのあとどうするの?
お客さんの要望で実現可能だとしても、その後お客さんが扱えるのかも考えるのも仕事です。
photo credit: South Texas Border Patrol Agent Monitors Border Activity with RVS via photopin (license)
カラムの桁数を拡張?
ある日のこと、部下から既存のデータベースのテーブルのカラムの桁数を動的に変更して問題はないのか質問されました。PostgreSQLの場合、該当のカラムがビューで使われていなければ変更できるので、変更できるけれどなぜそのカラムを拡張するのか目的を聞いてみました。
その結果、既に稼働中のシステムで必要な入力項目が不足していることが判明したため、システムを改造しないで既存の項目に必要な項目を入れてもらってデータを集めようとお客さんが考えているということがわかりました。
データは集められても扱えないでしょう
確かにデータは既存の項目に入れれば、データは集まられるかもしれません。しかし、お客さんの考えている通りにしてしまうと、データを集めた後のデータの扱いが困難です。
どうやって元々の既存の入力項目として入力したデータと、既存の入力項目とは関係のないけれど入力したデータを切り分けるのかわかりませんでした。
入力のルールを設けても正しく入力できないと考えて、そのために入力された内容をシステムでチェックを入れていて、正しく入力されるようにしています。
それを働かせることができません。
部下に、どうやって集めたデータを扱うのか僕にはわからない、お客さんが扱えるというのなら対応するのは構わないが、扱えなくて後からこちらになんとかして欲しいと言われても対応はできないので、お客さんに確認するように伝えました。
お客さんの要望をかなえるのも仕事、無駄なことをさせないのも仕事
部下からお客さんに確認したところ、お客さんはデータを集めることだけど考えていて、集めたデータの切り分けまでは考えていませんでした。結局は要望を受け入れず、現状のまま他の手段をお客さん側で考えることになりました。
お客さんの要望をかなえるのは当然の仕事です。
無駄なことをさせないのも当然の仕事です。
必要な情報を正しく扱えるように集めるという目的を考えてシステムは検討しないといけないです。