user_name ECシステム開発, 機能設計, 経営日誌

ECシステムの意義は使いやすさではなく仕事量の削減が第一

ECシステムを作る意義は、仕事量を削減することが第一ではなく、作業スピードと品質を上げることが第一ではないということを強く言いたい。
EC業務における仕事といわれる部分、つまりオペレーターによるオペレーションが必要な部分は、ほぼ皆無です。なぜなら、商品を出品し、受注いただき、商品を確保（引き当て）し、発送するまで何事もなければシステムにより管理され発送されるだけになります。それではなぜオペレーターが必要なのかといいますと、イレギュラーな受注があるため作業が発生いたします。

　イレギュラーな受注とは何か？
　当社では、以下のような受注をいいます。
　数量が多い受注・高額な商品の受注　（出品ミスの可能性があり、販売リスクが大きい）
　外国人のお客様からの受注（発送先の打ち合わせ　いたずら不正受注の場合があり）
　沖縄への発送の受注
　大型商品の受注（別途送料の可能性）
　ブラックリストに入っている方からの受注
　コメントをいただいている受注
　希望日をいただいている受注　など

これらをマスタ化し、条件ごとに分類し、オペレーターに作業依頼をすることを仕事をなくすということになります。当社では、受注量がそれだけ集まらないため、受注リストに赤色で帯を付け　イレギュラーな受注　を示し作業依頼をしています。受注量がそれなりに多くなりますと、専用I/Fを設けるほうが効率は高くなります。

仕事量を減らす　＝　仕事の整理整頓　＝　仕事のマスタ化　が　つまり、仕事量を減らしてシステム化するということになることだけは忘れてはいけません。このマスタ化により受注管理に関しては、受注作業の８割以上もの　仕事をなくす　という　成果がありました。システムが得意なこと、人が得意なこと、をしっかり整理して、仕事を分別することが　作業効率を上げるシステム　ということになります。

user_name ECシステム開発, 機能設計

オペレーションツールよりも監視ツールの方が優先的に

オペレーションツール（フロントサイドシステム）を先に優先的に作り業務効率を上げたいと思う方が多くいらっしゃいますが、最終的に効率より品質が優先されないといけません。つまり、サービスが一番優先であり、サービスが疎かになった受注を上げたところで、二度と使ってもらえないユーザー様をたくさん作ってしまう結果になり、一時的な売上は上がっても長期のロイヤルユーザー様には育ちません。極端な表現かもしれませんが、親切につかっていただいているお客様を、殴らないでよいのに毎日殴っている　ような状態が続くとなると１年以内にそのショップは、リピーターがなくなりつぶれてしまいます。
　つまり、サービスの品質こそがショップ一番優先されるべきところになり、それを維持するためには、監査・監視ツールを優先して作るべきであります。まずは、作ったシステムがちゃんと稼働しているかどうか、相手がいれば、相手のデータは本当に大丈夫なデータか、私も、これを疎かにした結果、さんざんな目に遭った経験を持っています。具体的にどのようなことがあったかを簡単に例をあげると、
　相手から提供されている商品情報データがでたらめで、人力でのチェックが疎かになり、また、取込み部分の不具合はみとめられなかったため、問題なしの結果が続いた。結局、相手のデータがカスタム時にデタラメなものになっており、２年以上も気づかずに、大損害を被った。数字で言えば、売上規模は、数億、利益ベースでいっても、４，５千万円規模の損害を被った。
　カスタム時に、2次被害にて、販売価格が原価で出品された。消費税抜きで販売された。
　各モールへのエラーチェックがなく、更新がされていなかった。など、数千万円単位で損害を被った。
これらは、すべて監査ツールが優先されていなくて、目先の効率や売上に走った結果、数億単位の損害を出すことになりました。責任は、誰も取ってくれませんというより、取れません。現場が、SEが作るシステムを過信する　と損害は膨らむばかりです。導入されるシステムは、でたらめで、SEは、試作品を送ってきているくらいの気持ちで現場には伝えて、テスト結果をSEにフィードバックする仕組みを作っておくべきであります。それよりも何よりも、何か不具合があれば、すぐに判明するツールを先に作り、フロントサイドを取り掛かるという方が、結局なところ得する部分が多く、欲におぼれてしまうという結果になりかねません。ここはとにかく過信することなく、注意をして進めてください。

user_name ECシステム開発, 機能設計

バッチ処理は現場を怠慢にし混乱にさせる

　バッチ設定（タイマー自動稼働設定）は、当社ではなんでもバッチに頼り、一時期１００以上ものバッチが毎日稼働していました。バッチ処理は、一見して自動で何でもやってもらえて楽で正確で良いようなイメージがあるが、まったくの逆です。バッチ処理は、本来現場のオペレーターがやるべきものをタイマー仕掛けで代行をさせるというものであるが、ツールを自動稼働にするほど、意味のないものになりかねない。人のよいところは、条件変化に対応する、コミュニケーションができる、などつまり、頭脳の部分であり、ツールは、所詮道具であり、頭脳ではない。そのところを、現場が理解し得ないところで処理をしてしまうと現場は、毎日経験を積み育たないし、トラブるを監査する監視ツールもなく、現場は、ただただ怠慢なものになってしまうだけであります。
　余談ではあるが、バッチの提案は、SEたちの、既得権益や工数に生まれ変わり、現場を支配するものになりかねない。SEは、鍛冶屋であり、現場の戦士に最適な武器を作っては送り、古くなれば、問題があれば、メンテナンスをするという立場であり、現場を統率しうるだけのリーダーシップや肩書は持ち合わせていない。現場が金を生み、現場の努力や痛みにより会社は売り上げを最前線で稼ぎ出す。SEたちのような鍛冶屋は、所詮鍛冶屋で、現場が上に立ち、このようなツールを作れや前のツールはこのようなところがだめだなど、気軽にSEにダメ出しができるような環境が望ましい。SEは、現場を隠れ蓑にし、自分たちの利益をためるような行動をとる場合が多々あり、学と技術がない現場を少し下に見てバカにしているようなSEも多い。だからこそ、社長やトップたちが、SEや現場に対して、それぞれのポジションを意識させ、相乗効果を生ませるような関係を築き上げる必要があります。
　バッチ処理は、すべてを否定するものではないが、せめて、現場担当と、バッチリストをもとにどのようなバッチが用意されているかの説明うや必要か否かのの議論は、かならず必要であろうとかと思っています。