業務フロー

たまには、システムよりな話を書こうと思う。
プログラミングの話は、もっと詳しい人が居るので、そちらに任せるとして、違う側面から開発者の性を書いていこうと思う。

何度も書いているが、私は「プログラマ」なのです、システムエンジニアでは有りません。
世間一般ではどう思われようが、私は「プログラマ」なのです。プログラムを行うのに必要なので、話を聞いたり、効いた話をまとめて考えを客に伝えたりしていますが、本質はプログラムを書くのが仕事なのです。

その人間が不思議に思うセリフを吐く人が多い。
自分でシステムエンジニアと名乗っているのに、「客に言われませんでした」や「指示が無かった」と平気で言うのです。それは違うだろうと思ってしまう。
客に言われなかった事でも、一般通念的に対応しているべき事は対応しているべきなのだと思うし、システムエンジニアなら客の周辺事情も解っていてしかるべきだと思う。 プログラマの私でさえ、客の事情や客の商売を勉強してから、プログラムを作るようにしている。
一般的な●●管理システムと言われる物でも、オーダーメイドしようとしている事から、客が何らかの不都合を感じているのだと所から開始しないといけないと思っている。
話を聞いていけば、その業務に精通してくるので、精通してからプログラムを開始しても十分いい商品を作れると思う。
逆に、ツール的な物を作る時には、業務フローの邪魔にならない用に作り込みを行って、作業を円滑に進める用にしなければならないと思う。

そこで大切な物が業務フローになってくるのですが、業務フローは簡単に言えば人の動きを見る必要があるので、一般的な窓口の人との接触だけではなくて現場を見なくてはならない。
契約の問題で現場を見る事が出来ない時でも、現場の担当者から話を聞く事が出来るので、私は業務フローの確認の為に、早い段階で現場の人との接触をお願いする。
オーダーメイドのシステムになればなるほど現場での接触は必要になってくるので、業務フローの把握と言う意味の他にも、業務に精通すると言う事から必要な事だと思っている。
プログラマの私でさえそう思うので、システムエンジニアを名乗る人達は当然やっている物と思って話を聞いてみても、今まで数社のシステムを担当している会社のシステムエンジニアに話を聞いても、そんな事までしなくてはならないの？って驚きの返事が返ってきた。
その結果がどういう事態を引き起こしたのかを考えて欲しいですね。