今日もお疲れ様です。
前回は、「プログラムは見て盗むもの」と教えられ、桐のプログラムコードを開くところから学び始めた頃のお話をご紹介しました。
👉 【社内SEの学び】「プログラムは見て盗むもの」と教わって得た力
今回は、その経験を活かして初めて桐のプログラム改修に挑戦したときのお話です。
入社してまだ1年目。
桐のプログラムを改修した経験はありませんでした。
それでも、自分から改善を提案し、約1か月かけて完成させた業務改善があります。
それが、送り状システムのバーコード対応でした。
月に2〜3回発生していた誤配送
当時、商品の誤配送が月に2〜3回ほど発生していました。
数字だけを見ると少なく感じるかもしれません。
しかし、一度誤配送が発生すると、お客様へのお詫びや再発送、社内確認など、多くの人が対応しなければなりません。
毎日の送り状発行は20〜30件ほど。
担当者はメインが一人、私はサブとして発送作業を手伝っていました。
送り状システムは、納品先コードを入力すると、そのコードをもとにデータベースから納品先情報を取得し、送り状を表示する仕組みでした。
問題は、その納品先コードを毎回テンキーで手入力していたことです。
私自身も実際に作業をしましたが、発送作業は時間との勝負でした。
何十件も入力を続ければ、隣のキーを押してしまうこともあります。
「確認すればいい。」
もちろん、その通りです。
しかし、現場で実際に作業すると、「間違えるな」という方が無理だと感じました。
だから私は、人に注意を求めるのではなく、間違えにくい仕組みを作るべきではないかと考えたのです。
改善のヒントは身近にあった
ちょうどその頃、基幹システムの更新が行われました。
新しい受注票には受注番号のバーコードが印刷されるようになり、そのタイミングでUSB接続のバーコードリーダーも導入されました。
送り状システムではまだ使われていませんでしたが、
「これを使えば手入力しなくても済むのでは？」
と思いました。
受注番号を読み取り、一度送り状を画面へ表示します。
備考欄などを確認してから印刷すれば、入力ミスを減らしながら確認作業も残せます。
必要なものは、すでに会社の中に揃っていました。
そこで私は、この改善を提案しました。
プログラムコードを開くところから始まった
提案したものの、私はまだ入社1年目。
桐のプログラム改修は初めてでした。
前回の記事でも書いたように、まずはプログラムコードの開き方を覚えるところからのスタートです。
コードを開けるようになっても、すぐに改修できるわけではありません。
どのプログラムがどこから呼ばれ、どのようにデータベースと連携し、送り状を表示しているのか。
既存プログラムを一つずつ解析しながら全体の流れを理解していきました。
桐のプログラムコードは日本語で書かれていました。
それでも独特の書き方や表現が多く、「この処理は何をしているんだろう」と頭を抱えることも何度もありました。
さらに苦労したのは、改修元のプログラムにコメントが一切入っていなかったことです。
コメントとは、プログラムの処理内容や目的を書いておく説明書きのようなものです。
当時のプログラムにはその説明がなく、「何から見ればいいんだろう」と最初は戸惑いました。
コードを読み、画面を動かし、またコードを読む。
その繰り返しで少しずつ処理の流れを理解していきました。
新しい処理を追加するときは、既存のプログラムをかなり参考にしました。
当時の私にとって、既存のプログラムは一番の教材でした。
似た処理を探し、動きを確認しながら少しずつ自分のプログラムへ取り入れていきます。
前回の記事でご紹介した「プログラムは見て盗むもの」という言葉を、この改修で初めて実感したように思います。
思ったようにはいかなかった
完成が見えてきた頃、新たな問題が見つかりました。
各拠点から送られてくる受注票はFAXで受信していたため、バーコードが潰れたり、かすれたりして読み取れないことがあったのです。
そこでFAXの解像度を上げることで改善を図りました。
読み取り精度は向上しましたが、今度はまれにFAXエラーが表示されるようになりました。
ただ、実際には正常に送信されていることがほとんどだったため、この問題は深追いせず運用することにしました。
さらに、バーコードが付いていない受注票もありました。
バーコードだけでは、すべての業務をカバーできなかったのです。
バーコードと手入力を共存させる
そこでバーコード入力欄を新たに追加し、従来の手入力欄もそのまま残しました。
通常はバーコードを使い、読み取れない場合だけ手入力します。
この二つを共存させることが、一番苦労した部分でした。
バーコードだけなら比較的簡単です。
しかし、手入力も残すとなると、入力方法によって処理を切り替えながら、最終的には同じ送り状発行処理へつなげなければなりません。
さらに、一番苦労したのはデータベースとの連携でした。
バーコードから取得した受注番号を既存のデータベースへ渡し、正しい納品先情報を取得する処理は思ったように動かず、何度もコードを読み返しながら動作確認を繰り返しました。
少し修正しては確認し、また修正する。
この作業の繰り返しだったことを覚えています。
動作確認は既存機能への影響がないことを確認したうえで、実際の受注データを使って行いました。
「できたー！」
約1か月。
コメントのないプログラムを解析し、データベースと連携させ、例外処理も考えながら改修を進めました。
そして、思いどおりに送り状が表示された瞬間、「できたー！」と思わず声が出ました。
実際の運用を開始すると、担当者から「確認が楽になった。」という言葉をもらいました。
毎日送り状を発行していた担当者だからこそ、その変化を一番実感していたのだと思います。
その言葉を聞いたとき、「頑張ってよかった」と素直に思えたことを今でも覚えています。
誤配送も以前より減り、この送り状システムは現在も改修されながら使われています。
当時は完成させることに必死で、十数年後も使われ続けるとは思っていませんでした。
でも、それだけ現場に合った仕組みを作れたということなのかもしれません。
仕組みで現場を支える
この改修で私は桐の書き方を覚えました。
しかし、それ以上に学んだことがあります。
それは、プログラムを書く前に既存の仕組みを理解すること。
そして、現場を理解して初めて、本当に役立つシステムが作れること。
もし今、当時の自分に声を掛けるとしたら、「頑張ったね。」と伝えたいと思います。
入社1年目の私が、コメントもないプログラムを解析し、約1か月かけて完成させた送り状システム。
「確認してください。」ではなく、「間違えにくい仕組みを作る。」
この考え方は、この改修を経験した当時から、今でも私の業務改善の原点になっています。
次回は、現場からの依頼をきっかけに作成した「桐」の発注管理表について、ブログ記事にまとめたいと思います。
現場長が必要としていたのは、膨大なデータの中から素早く判断できる仕組みでした。「これで仕事が回せる。」と言っていただけた発注管理表が完成するまでの経緯をお話しします。
👉 【元社内SE実録】「これで仕事が回せる。」その一言がうれしかった｜現場長の判断を支えた発注管理表
関連記事
👉 【社内SEの学び】「プログラムは見て盗むもの」と教わって得た力
👉 【元社内SE】余っていたパソコンが業務を支えた｜「無ければ作る」で生まれたバッチサーバー
👉 【元社内SE実録】トラブル対応の初動で一番大切にしていたこと
「もしこの記事が役に立ったと感じたら、SNSでシェアしていただけると嬉しいです！」
その際、インスタグラムやX（Twitter）で**「フォロー」や「シェア」**してもらえると、次の記事を書く大きな励みになります！
他にもSEの裏話や便利なガジェットやちょっと一息つけるようなコラムも用意していますので、ぜひご覧ください。
コメント