システム化する範囲を考える

極論をいうとなんでもシステム化できます

　相談に来られたらよく言っています。実際、お金と時間と環境が許せば、できないことなどほとんどないはず。

　ただ、「できる」と「やるべきか」はまったく別問題だと思います。システム化って純粋な手段でしかないので、目的を考えると、「これはシステム以外で解決策を考えた方がいいんじゃないか？」と思うものは多いです。それを指摘して、適切な方向にもっていけるようにアドバイスするのもコーポレートSEとして大事なスキルだと思っています。

システムよりも、
サービスや業務フローを見直したら？

　業務システムって、業務の効率化（＝自分の仕事を楽にしたい）ということが起点の案件って多いんですよね。でもそこで、目的や、かけられるコストや、負荷がかかっている要因を聞いていくと、上長の方が「うーん、これ、私たち内でもう少しもんだ方がいいですね」と持って帰られるケースも少なくありません。

　たとえば、先日あった相談だと、

１）受注管理をシステム化したい
２）短い時間で大量に顧客を入力しないといけない
３）商品の提供が大変なので一斉提供したい
４）顧客ごとにちょっとずつ商品が違うので、極論をいうと、顧客分提供パターンがあって、全部作り分けているので大変

この場合、改善すべきはどちらかというと２）と４）の「システムやサービスのありかた」です。ここの原因をしっかりとらえて、その原因を解消する方法を考えることが必要。たとえば、立派なWeb入力の画面を作っても、実際に使う人が２名とかで、確認を一覧で見て処理をしたいのなら、スプレッドシートに最初から入力してしまったほうが早いんですよね。入力チェックとかだってスプレッドシートとかである程度できちゃいます。

エンジニアだからミスしない？

　さらに、弊社のように運用までアウトソーシングしていると、自分たちの労務的な手間を減らすために、本来であれば関数やピボットテーブルでできるような集計作業とかを外注しようとするケースもあったりします。話を聞くと、

・エンジニアの人たちは絶対にミスしないと思っている
・段階を踏んでやらないといけない作業もプログラムを使えば一瞬でできると思っている

みたいに思っているケースが少なくありませんが、結局人ですからね。

　先日、とあるデータ抽出で「高い！」という話になって見積を見たら、顧客リストを作成する際に、年齢層別にシートを分ける、というものがありました。で、これをSE作業でやると、手順書を作って２人がかりでチェックして、となるので高くなるわけです。
　「うちでやったら一瞬なのになぜこんなに高いの？」と相手の上長の方に絶叫されましたが、「手作業をエンジニアにさせるのは高いんですよ。このプロセスをそちらでおやりになったら？」という話になり、作業範囲を見直すことになりました。

　なかなかこういったところまで口を出すのが難しいですが、システム化して価値のあるものだけを提案できるような情シスでありたいと思っています。