オペレーションツール（フロントサイドシステム）を先に優先的に作り業務効率を上げたいと思う方が多くいらっしゃいますが、最終的に効率より品質が優先されないといけません。つまり、サービスが一番優先であり、サービスが疎かになった受注を上げたところで、二度と使ってもらえないユーザー様をたくさん作ってしまう結果になり、一時的な売上は上がっても長期のロイヤルユーザー様には育ちません。極端な表現かもしれませんが、親切につかっていただいているお客様を、殴らないでよいのに毎日殴っている ような状態が続くとなると１年以内にそのショップは、リピーターがなくなりつぶれてしまいます。
つまり、サービスの品質こそがショップ一番優先されるべきところになり、それを維持するためには、監査・監視ツールを優先して作るべきであります。まずは、作ったシステムがちゃんと稼働しているかどうか、相手がいれば、相手のデータは本当に大丈夫なデータか、私も、これを疎かにした結果、さんざんな目に遭った経験を持っています。具体的にどのようなことがあったかを簡単に例をあげると、
相手から提供されている商品情報データがでたらめで、人力でのチェックが疎かになり、また、取込み部分の不具合はみとめられなかったため、問題なしの結果が続いた。結局、相手のデータがカスタム時にデタラメなものになっており、２年以上も気づかずに、大損害を被った。数字で言えば、売上規模は、数億、利益ベースでいっても、４，５千万円規模の損害を被った。
カスタム時に、2次被害にて、販売価格が原価で出品された。消費税抜きで販売された。
各モールへのエラーチェックがなく、更新がされていなかった。など、数千万円単位で損害を被った。
これらは、すべて監査ツールが優先されていなくて、目先の効率や売上に走った結果、数億単位の損害を出すことになりました。責任は、誰も取ってくれませんというより、取れません。現場が、SEが作るシステムを過信する と損害は膨らむばかりです。導入されるシステムは、でたらめで、SEは、試作品を送ってきているくらいの気持ちで現場には伝えて、テスト結果をSEにフィードバックする仕組みを作っておくべきであります。それよりも何よりも、何か不具合があれば、すぐに判明するツールを先に作り、フロントサイドを取り掛かるという方が、結局なところ得する部分が多く、欲におぼれてしまうという結果になりかねません。ここはとにかく過信することなく、注意をして進めてください。
人事評価のためのログ取得
ログは、セキュリティや不正の制御のためにあるというイメージですが、ログは、誰が何をいつやったかの履歴であり、人事評価の目安にできます。つまり、作業ボリュームを出すことが可能です。人は、ゴールがなければ、各々ゴールを設けて努力をします。まじめにするもの、不正をするもの、さぼるもの、楽しむもの・・・それぞれのゴールがあるから、バラバラになります。ここで、仕組みで、作業ボリュームが正当に出て、正当に評価されるとなれば、みんなのゴールは、まじめにがんばろうとなるわけです。私語はなくなり、だらだらと残業するものもなくなり、不正も社内営業しかしないものも、成果に対して努力をするようになります。スタッフは、理不尽だから、がんばらないのです。誰もが納得する理にかなったものであれば、スタッフはみんな明日から優秀なスタッフになるのです。
システム開発についての心得
業務システム開発を設備投資として、早１５年が経ちました。
その設備投資のおかげで、このコロナ禍でもなんとか生き長らえてきたと自負しておりますが、どちらかというとたくさんの失敗を経験しました。失敗と一言で申しますが、設備投資でいう失敗は、損失です。つまり、お金を損した ということにつながります。
私はこの失敗のせいで、たくさんの損失を出しました。その例をいくつか紹介します。
頭でっかち尻つぼみによる失敗
システム開発で一番失敗しがちなのが、設計です。設計は一番重要な作業ですが、一番重要な社長が行う方がよい場合が多いです。それを、多くの場合で、誰かに丸投げをしたりして疎かにしてしまいます。それは、よく勘違いをすることが多いのですが、システム設計は専門家でないとできないと思っている人が多くおられます。一方、システム技術者の方の多くも、設計は自分たちでないとできないと思っている人が多く見受けられます。会社の大事なシステム開発は、会社の代表が行う方が一番良い場合が多くございます。そこを見誤って開発を始めてしまうことがすべての原因になります。
見当違い、使いずらい、重くて使えないシステム
多くの技術者は、設計図を見ずに憶測で作ります。全く見ないわけではなく、ある分だけしか見ないということになります。たとえば、家を建てるのに、設計図を作って大工さんに立ててもらいたいと思えば、平面図と簡単なスケッチがあれば、家は建ちます。その代わり、壁だらけの圧迫感のある空間になり、窓は小さく暗くなり、収納は少なく、スイッチやコンセントは使いづらく、動線も長くとても使いづらい家になることは間違いないです。設計は、ユーザービリティです。使う人の満足を目的にあります。つまり、その満足は、何をすれば満足するかは、本人しかわからないわけです。つまり、自分たちが希望しなければ、何も出てこないと思っていた方がよいです。彼らが万能だと思っているのは大きな間違いです。いずれ、必ずこのメンバーで 日本を代表するようなシステム を作ろうと思っていたこと自体が大きな間違いだったということに気づくときが必ず来ます。
約１０００万円くらいかけて作ったシステムが表示に３分くらいかかり、まったく使わずに廃止したシステムもありました。現時点でも、開発した半分は、そのような状態にあります。ほとんどは、相手がいる場合の仕様の変化による廃止もございますが、ほとんどの場合が設計時点で十分に時間をかけていなかったことが原因でありました。
現場を楽にするのではなく、現場に便利なツールを！
親心としては、いつも大変な現場に楽をさせてやりたいと思うわけでございます。設備投資はそれでは間違ったシステムができることが多くございます。なぜなら、過剰なシステムが完成し、何から何まで自動運転により、オペレーションができないといったシステムが完成・運用してしまうことがございます。一見するとそれの何がわるいのと思うかもしれませんが、運用ができないものが何をしているのかを把握しているものが誰もいないということになり、システムが誤作動や停止をしていても誰も何も気づかないし、是正ができないということになりかねません。私共のシステムも一時は、自動バッチ（システムが自動に開始されるようにタイマーを設定すること）だけでも、１００以上あり、とにかく自動でという時期がございましたが、同時に監視ツールを作らなかったため、誤作動や停止などの不具合があれば気づかずに、被害を大きくしてしまったり、エラーが出ているにも関わらず誰も監査をしていないため、そのエラーによる被害が延々に継続していたり、ティータイムは増えましたが、最後の方は、エラーや不具合が続出し、すべての自動バッチを廃止するというところまでいきました。システムは、正確に動きます。ミスも正確です。不具合があれば、延々と正確にミスが続きます。人間は、状況判断をし、修復ができます。そのためにも、システムは、できるだけオペレーターによる操作にして、不具合をチェックし、不具合があれば、手作業による操作もでき、手待ちのスタッフもなくなります。現場がシステムの不具合により営業ができない時は、ほんと居たたまれないです。また、監査を役員が行うことができるようにし、不正なき現場を作り、現場のベクトルをおおいに成果にすることが可能になります。
社長自ら経験し実践してから育てる現場だからできる業務ツール
現場は、日々の自分のプライベートを守るために精一杯です。新しい設備投資をして効率を上げ利益率を上げることなんか一切考えていません。特に、中小零細企業に関しては、皆無だと考えてまず間違いないでしょう。
現場がどう戦うかどんな武器をもって戦うかは、社長の仕事です。それが、ビジネスモデルやコンプライアンスの作成ということになろうかと思います。社長は、自ら実践し、現場の課題解決や現場の要望の洗い出しをし、設備投資に反映させなければいけません。それができなければ、私共と同じように、失敗をたくさん繰り返してしまいます。現場は、プライベートをまずは維持するために生きています。向上するためには生きていません。その現場に対し、新しいツールやマニュアルの変更は、大きな反発や混乱を招き、せっかくの設備投資が台無しになることも多くございます。まずは、現場が２割増しくらいにプライベートをよくするためのプロジェクトということを明確に示して、協力を仰がなければいけません。そのためにも、ツールは、段階的かつ単発的なものの方が、現場はとても理解し、設備投資が成功する場合が多いことを忘れてはいけません。
ベストな Ｉ／Ｆとは？
社長自ら設計したものとなる
業務オペレーションを行う上で、よいＩ／Ｆとはどんなものか、それは、ずばり早い 使いいやすいの順番で作るほうがよいです。早いツールでない限り、時間的ロスばかり加算され、せっかくの設備投資による業務効率が台無しです。
１作業１秒いや０コンマ何秒でも早く表示ができないかということをまずはしっかりこだわってください。１秒のロスでさえ、１日、数千という作業を行う場合、掛けるオペレーターの数になります。数時間というオペレーターの手間を生み、無駄な休憩時間となるわけです。その分を還元しやる気を出させるようなツールでなくてはなりませんが、表示がとても遅くてはイライラとストレスしかたまりません。すべてのSEが、早いツールを作れるわけではありません。SEもピンキリです。早いツールを作れる、もしくは、契約内容に〇秒以内で表示するシステムと条件に記載し、納品が違えば、カスタムを無償にしていただくか支払いをしないことをお勧めします。
使い勝手に関しては、I/Fのフォーマットが重要になってくると思いますが、現場のオペレーターが、こんなＩ／Ｆにしてほしいということはなかなか職業的にも能力的にも厳しいところがございます。それでは、SEが、現場のためによいフォーマット知っているかというとそれはまずありません。よって、機能設計に関しては、社長自ら設計することをお勧めします。どのようなビジネスモデルで、どのような戦略でとういうことが、Ｉ／Ｆになることが多いなか、他の誰かがＩ／Ｆを作るということはとても難しいです。社長自ら、こんな機能をしれてほしい、こんなことをしたいということをおおざっぱでよいのでぜひ伝えてください。決して、まかせる ということは絶対にしないでください。それから、必ず開発ＳＥ達に現在のやり方で、現場の作用を体験させてやってください。ＳＥ達はとても人見知りで、また、とても現場に対し差別主義的な者もいます。その業務をしっかり勉強させ、現場の業務効率と精度は彼らが上げてくれるということを必ず現場で明確し、現場とのリンクをさあせて、ＳＥと現場とのベクトルを一致させて開発を始めてください。ＳＥと現場が対立し、罵りあい、免責のための言い訳をしあっている状況になると最悪です。ＳＥは我々みたいな特別な人間が作るものを使えばよいだけ、現場は、お宅っぽい鍛冶屋の人たちが作る得体のしれないものをわかりにくい遅いものを使いたくない。今までの方がよっぽどよかったというセリフを連発します。これを成功に修正し、導けるのは、社長 ただ一人だけなのです。
メンテナンスを意識した開発が重要
エンジニアはスキルより継続力を重視
システムは完成時に完了ではなく、継続して利用することを考慮に入れなければいけません。メンテナンス問題で、必ずといっていいほどあるあるなのが、旧開発者たちがおらずメンテナンスが難しいという事態が発生する 開発環境のバージョンが古くメンテナンス範囲外になった サーバー機を変更したいのだが、開発環境が古すぎて移行できない などの問題が必ずいずれ発生してしまうということを理解し予めメンテンナンス設計を必ず社長もしくは継続する責任者ＳＥがすることおすすめいたします。社内システムは、ローカルネットワークで稼働している場合が多く、外部との接続もVPNなどのプライベートネットワークでつながっている場合が多い。先進国の空港システムがいまだWindowsNTで動いているという話を聞いたことがありますが、プラットフォームのバージョンアップとデーターベースのバージョンアップは、小まめに行い稼働チェックをすることをお勧めいたします。バージョンは新しいに越したことがありません。昨今サーバー機に関しては、仮想化が可能になっており簡単に仮想マシーンへとバックアップのように移行することが可能です。バージョンが古いシステムは、データーバックアップをお勧めいたします。