というシステムのお話をいただくとお客様からは
「普通、こんな作り方しないよね」
という声を多く聞ききます。
「開発者側の理解力が足りていないから」
という結論は少々乱暴なようですが、
自戒の意味も込めて、弊社ではそのように考えています。
それほどに、
開発者が業務をどれだけ理解できるかで、結果が大きく変わります。
これがけっこう大変なことでして、実は、
業務のやり方も、使っている言葉も、
会社ごとにバラバラだったりします。
たとえば、オーソドックスな所で紹介しますと、
Aという会社では、納品をもって売上とします。
Bという会社では、請求をもって売上とします。
Cという会社では、請求や納品とは別に、売上を計上するという作業をします。
Dという会社では、請求、納品、売上はすべて一致しています。
Eという会社では、入金をもって売上とします。
さらに、
納品していないのに請求をする
納品しているのに請求しない
入金されてから納品する
などなどの条件が絡んできます。
上記のような例ですと、売上という言葉が意味するところも
そのやり方も違ってきます。
言葉は悪いですが、会社ごとに方言があると思っていただくと
わかりやすいかもしれません。
方言ということでいうと、同じ会社内でも営業と経理でも
それぞれ方言があったりします。
営業がいう売上は営業成績のことで、経理がいうのは経理上の売上。
計上日も違うし、消費税が入ったり入らなかったり、
少々脱線しますが、消費税でいうと、
大きな金額を分割請求した場合の消費税の計上方法もバラバラです。
本体価格を分割して、都度消費税を計算する会社もあれば、
最終金の時に全額分の消費税を計上する会社もあります。
さて、
他にもいくつもパターンが存在するかと思いますが、
ご自身の会社のパターンはありますか？
たいていの場合、転職でもしたことなければ、
ご自身の会社のやり方が「常識」ですよね。
他の会社の例には違和感や疑問を覚えるはずです。
開発者はあくまで会社の外の人間ですから、
みなさんの会社内の「常識」を知りません。
このあたりの摺合せと理解がなされていないと、
出来上がったシステムは、
・余計な工程があって手間がかかる
・あまりに自動処理すぎてできない処理がある
・数字が狂うパターンがある
ということが発生します。
さらに、この後につながる処理にも不具合がでてきます。
と、わかりやすい例から入りましたが、
それほどにバラバラで理解するのは大変ですし、
かといって理解していないで作るとえらいことになります。
たいてい、お客様の前にいる人間は、
「営業」「コンサルタント」「コーディネータ」などなど
それに類する肩書きで、実際に制作するわけではないので、
伝聞がもう一度行われます。
理解していない人間が伝聞したらどうなるかは想像に難くないですよね
開発者が御社の業務を理解することは、
システム開発成功の第一歩なのです。
その上で、
業務の問題点、
なぜシステムの導入が必要なのか？
ユーザーから上がっている要望の理由はなんなのか？
ということを、開発者が本当の意味で理解すると、
設計思想というか、システムの目的みたいなものが明確になります。
そうすると軸が一本通るので、
話は早くなり、よいシステムが出来上がってきます。
また、
ユーザーの要望をそのまま実装しなくなります。
なぜなら、ユーザーの要望の原因まで理解できていれば、
そもそも問題が起きないような設計にしたり、
システム導入の目的に反する要望や規制の抜け道になる要望を断り、
「システムではなく業務を改善すべき」
という判断をできるようになるからです。
過去に実際にあった例ですが、
納品前に請求書を発行してことで発生するトラブルを防ぎたい
という経営者の要望が存在する設計中のシステムに対して、
納品処理していなくても請求書を発行できるようにしてほしいという
要望が現場から上がったことがあります。
さて、こんな相反する要望があがってきたらどうしましょうか
ちょっと長くなってきたので、
それはまた次の機会にでもお話しします。
