見出し画像

Accessでシステムを作る前に実行すること。 俺の実体験。

まさおじさん

■ Xのポストがキッカケ

今日は、2023年11月14日（火曜日）　本格的に寒くなってきました。
それと、色々あって、考えることがありました。
そこで、こんなポストをしました。

自分が経験して得た事をなんとか伝えたいと、また思うようになったのです。　正直、生半可＋ド素人＋よっぱ＋おじさん　で頼りないですが、ちょっとしたキッカケになってくれることも、あるかもしれないという妄想で、今回、記事を書きます。
かなりの長編になると予測されます。
気長に付き合ってくれればと思います。

■ Accessのツールを作るキッカケ

「助けたい。」と思っただけ。
毎日、「運賃の登録作業」で、限られていた人が、残業していたから。
今回から、新シリーズもの「運賃の登録作業」を改善してみたを記事にしますので、生ぬるい目で見守ってください。

■ 今、令和だけど、昭和。

「運賃の登録作業」には、複数のステップ（工程）がありますが、簡単に表現すると、「紙」と「手書き」と「目視」と「手入力」が繰り返される業務でした。

基幹システム（Ｒ／３）から出荷指示書らしい伝票を印刷して、そこに、重量と荷姿を手書きして、運賃早見表から、運賃を探して、出荷指示書に記入して、最終的に、出荷伝票を探して、基幹システム（Ｒ／３）に運賃を手入力していました。

「紙」と「手入力」の繰り返し。
これを、私は「昭和のやり方」と言っています。
つまり、人海戦術が基本ベースになっているのです。

■ 俺が許せないポイント

  • そこにデータあるじゃん、なんで再入力するの？

  • こんな単純作業を、なんで人間様がやるの？

  • なんで、何回も、同じような項目を探すの？

ほかにもあったような・・・（よっぱで忘れた）

今回の事例は「こんな単純作業を、なんで人間様がやるの？」
です。

これらの「俺が許せないポイント」は、お客様目線で考えれば簡単です。

「あなたの、今の作業に対して、お客様はお金を支払ってくれますか？」

運賃の記録は、業務上やむを得ないとしても、手書き転記、運賃を目視で探して、紙に手書きで書いて、手書きで紙に書いた運賃を基幹システムに入力するという作業に対して、お客様は、お金を支払ってくれるでしょうか。

運賃は支払っても、運賃登録作業に対しては支払ってくれないと思います。

改善のポイントの一つに「付加価値の低い業務を改善する」があります。
これは、需要側、供給側、双方に利益をもたらします。
もう、人間様が単純作業をする時代は、過去の意識です。
そんな意識を捨てることから始まります。

■ 所詮、俺は素人

しかし、業務全部を自動化しようとすると、設備、システム、インフラ、時間、いろいろコストが生じてしまうのも事実。
そこで、「見切りの能力」が必要になってきます。
簡単に表現すると「俺だけで改善できる所の見極め」です。

| 見切りの能力

  • 追加設備や追加ライセンスが不要なこと

  • 情報システム部門の許可が不要なこと

  • 開発期間は長くて半年であること

  • 基幹システムに変更が生じないこと

  • 作業者が楽になる事が明確であること

  • 定期的な業務であること（しょっちゅう、毎日、毎週、毎月）

  • 俺１人で解決できるレベル

他にもあったような気がしますが、おもな判断基準は上記の７個です。
所詮、俺は素人です。なので、出来る範囲の見極めも重要です。

■ 現場を熟知する

外から見ても中身は見えないものです。
また、実務に対してマッチしたシステム（ツール）でなければ、作ったシステム（ツール）は、ゴミです。
現場の人が現場で喜んで使ってもらうためには、現場を熟知することが一番の近道です。
でも、現場を熟知する行為は、非常に地味なことです。
現場の作業者の横に立って、

  • 何をしているのか

  • 何をみているのか

  • 何を書いているのか

  • 何を映しているのか

  • 何を入力しているか

を、よく観察します。
それだけではありません。
観察して、メモしたことに対して、質問して、自分が納得するまで聞き込みをします。

  • なぜ、しているのか

  • なぜ、みているのか

  • なぜ、書いているのか

  • なぜ、写しているのか

  • なぜ、入力しているのか

この、なぜ？がとても重要な質問になります。
作業者は、「前任のやり方を、そのまま実行しているだけ」で、今の作業に疑問がありません。ただ、なぜ？を繰り返していくと、「こっちのアレをこうしてあげれば・・・」っていう発想が出てきます。

■ ことの真実を知る

現場を熟知したなら、半分以上は、問題解決したようなものです。
でも、ここからが、腕の見せ所です。
細かい内容は、後日に書きます。
初回では、今回の事例でもある「運賃の登録作業」においての真実をかきます。

  • 運賃の料金システムを熟知

結局、これだけでした。

■ 改善適用範囲を決定する

あとは、自分の実力値と、予算と、時間と、設備と、人から、改善できる範囲を絞り込みます。
この「改善適用範囲を決定する」って、とても重要です。
これを決めないと、あれもこれもで、結局完成しなかったり、完成しても機能不足で改善が弱かったりします。
事例では、こんな感じにしました。

  • 運賃早見表を見なくても運賃設定ができるようにする

  • 荷姿や重量を紙に書く作業は現状維持

  • ただし、運賃の料金は紙に記入しないで、パソコンが計算する

  • 基幹システムに登録作業は自動化する

■ おしまいに

今回は、システムを作る前の心構えややる事を書いたつもりです。

「そこまで、しねーよ！」っていう意見もあると思いますが、作り手（クリエイター）からすれば、ユーザーが喜んでくれる以上のご褒美は無いと思っています。だからこそ我々は「現場ファースト」でシステムを作っていくのです。
だからこそ、現場を知る事が重要になるのです。
現場をしらずして、ユーザーに喜ばれるツールは作れません。
それと、自分の限界を知ることも重要です。自分の能力を超えるシステムなんて作れませんからね、所詮、俺は素人です。

今回のネタは、事実をもとに書いています。
ただし、事実から切り取りした内容を書いていますので、書いた内容が全てではない事を、最後に書いて、つづきにしたいと思います。

読んでくれた読者様、本当にありがとうございます。

この記事が気に入ったらサポートをしてみませんか？