システムを導入すれば、会社の困りごとは解決するのだろうか。
私は長年システム開発に携わってきたが、そう簡単なものではないと考えている。
まず何に困っているのかを知り、その原因を整理して、何をどう変えればよいかを考える。
そして、システムが稼働した後も、実際の使い方に合わせて改善していく。
以前、手がけたトラック運送会社の運行管理システムは、まさにそんな仕事だった。
複雑な運賃計算や原価管理をシステム化し、本店と支店をつないで情報を一元管理する。
さらに稼働後には、蓄積したデータを使って経営分析ができるようにした。
この仕事で何より幸運だったのは、元運転手で、現場の仕事を知り尽くした非常に優秀な部長さんと出会えたことである。
1. システムの話をする前に、まず人間関係を作る
この運送会社は、当時の私の会社から比較的近い場所にあった。
そこで、週に一回ほど訪問し、業務の話だけでなく、雑談を交えながら少しずつ人間関係を作っていった。
システム開発では、最初から「どんな機能が必要ですか」と聞いても、なかなか本当の困りごとは出てこない。
日頃当たり前に行っている仕事ほど、本人にとっては説明する必要がないと思っているものだ。
また、困っていることがあっても、それがシステムで解決できる問題なのかどうか、現場の人には分からないこともある。
だからこそ、普段の仕事について気軽に話してもらえる関係を作ることが大切なのだ。
その会社で中心となって対応してくれたのが、以前はトラックの運転手をしていた部長さんだった。
この方が業務を熟知した上、頭の良い方でとてもありがたかった。
運転手としての経験があるので、現場の仕事をよく知っている。
それだけでなく、複雑な業務を整理して、相手に分かるように説明することがとてもうまかった。
私自身、父が運送会社に勤めていたこともあり、以前には荷物追跡システムの開発にも携わっていた。
運送業について、ある程度は理解しているつもりだった。
しかし、荷物の流れを知っていることと、運行管理や原価管理の実務を理解していることは別である。
運転手がどのように仕事を進め、何を記録し、それが運賃や原価の計算にどうつながるのか。
実際に仕事をしてきた人でなければ分からないことが、たくさんあった。
そんな部長さんから、雑談のなかで面白い話を聞いたことがある。
「大切なことは強調して言ってくれ。聞き流したらいけないから」
奥さんに、いつもそう言っているのだそうだ。
奥さんには逆らわず、何を言われても「うんうん」と聞くのが自分のポリシー。
ただし、本当に大切なことは、聞き流さないように念を押してほしいというのだ。
笑いながら聞いた話だが、この方の説明のうまさにも通じるものがあると思った。
何が大切なのかを理解し、相手に伝わるように話す。
私に業務を教えてくれるときも、重要なところは必ず強調して説明してくれた。
この部長さんと最初に良い人間関係を築けたことが、その後の仕事を進めるうえで大きな助けになった。
2. 現場の話を聞いて、複雑な業務を整理する
運送会社の業務は、外から見る以上に複雑である。
今回のシステムでは、トラックの定期便・非定期便の運行管理に加え、運賃計算や原価管理、乗務手当の計算などが対象になった。
なかでも難しかったのが運賃計算である。
運賃は、単純に走行距離を掛け算すれば求められるものではない。
一つの便に複数の請求先が関係する場合もあれば、積載重量によって計算する場合、最低保証運賃が設定されている場合など、さまざまな条件があった。
整理していくと、運賃の計算方法だけで10種類程度のパターンが存在していた。
こうした業務を、最初からプログラムにしようとしても無理がある。
どんな場合に、どの計算方法を使うのか。
例外的な取り扱いはないのか。
日報には何が記録されていて、その情報はどこで使われるのか。
部長さんに一つひとつ教えてもらいながら、業務の流れと計算の仕組みを整理していった。
ここで重要なのは、今やっている仕事を、そのままコンピューターに置き換えればよいわけではないということだ。
今の仕事のどこに手間がかかっているのか。
どの情報を共通で使えるようにすればよいのか。
何を整理すれば、もっと正確で効率的な仕事になるのか。
現場の事情を理解したうえで、どう変えるかを考える必要がある。
今回の開発でも、部長さんの知識と経験に何度も助けられた。
システムを作る側だけで業務を理解したつもりにならず、実際に仕事を知っている人と一緒に考える。
この過程がなければ、使えるシステムにはならなかったと思う。
3. 日報を起点に、運行管理から原価管理までつなぐ
業務を整理した結果、運転手の日報を中心に情報を管理する仕組みを構築した。
運転手が日々記録する走行距離、燃料の投入量、運行時間などをもとに、運行の実績を把握し、原価管理につなげていく。
また、便名ごとに運賃を計算し、売上に応じた乗務手当の計算なども行えるようにした。
複雑な運賃計算については、整理した10種類程度のパターンを、それぞれ計算ロジックとして組み込んだ。
さらに、本店と支店で同じシステムを使えるようにする必要もあった。
当時は、今のようにインターネットやクラウドサービスを手軽に利用できる時代ではなかった。
そこで、ISDNの専用回線を利用して本店と支店をつなぎ、データベースを本店で集中管理する仕組みを構築した。
開発にはMicrosoft Access、データベースにはSQL Serverを使用した。
これによって、支店で入力した情報も本店で速やかに把握できるようになった。
今なら別の技術を選ぶだろうが、当時の環境では、こうした仕組みを実現することにも工夫が必要だった。
ただ、ここで伝えたいのは、どんな技術を使ったかということではない。
日々の仕事で発生する情報を整理し、それぞれの業務につなげることで、会社全体で使える仕組みにしたことだ。
日報を入力することが目的ではなく、そのデータを運賃計算や原価管理、乗務手当の計算にも活用する。
業務を整理したからこそ、こうした仕組みを作ることができたのだと思う。
4. システムが稼働してから、次の課題が見えてくる
システムが完成し、日々の運行管理ができるようになった。
しかし、仕事はそこで終わりではなかった。
日々のデータが蓄積されるようになると、今度はその情報を経営管理にもっと活用したいという話になった。
そこで、統計分析用のテーブルを追加した。
社員別の稼働時間帯や、便名別・社員別の乗務手当の構成など、さまざまな角度からデータを集計できるようにし、経営層や親会社での会議に利用する統計表やグラフも作った。
当時は、こうしたデータの分析を「データマイニング」と呼んでいた。
ところが、ここで部長さんから新しい希望が出てきた。
「自分でExcelを使って、もっと自由にデータを分析してみたい」
この言葉を聞いて、なるほどと思った。
決まった形式の統計表やグラフを見るだけでなく、自分でデータを切り出し、条件や集計方法を変えながら、いろいろな角度から分析してみたいというのだ。
さすがだと思った。
日々の仕事を理解しているだけでなく、集まったデータをどう活用すればよいか、自分で考えているのである。
そこで、統計テーブルから必要なデータを取り出し、部長さんと一緒にExcelでグラフを作ることにした。
二人で画面を見ながら、
「このデータを使えば、こんな分析ができるんじゃないか」
「ここを変えたら、もっと分かりやすいね」
そんな話をしながら、グラフを作っていった。
システム側で必要なデータを整え、Excelでは部長さんが自由に分析できるようにする。
すべてをシステムの機能として作り込むのではなく、使う人が自分で工夫できる余地を残すことも大切なのだと感じた。
何より、最初に業務を教えてくれた部長さんと、稼働後もこうして一緒に仕事ができたことが、私には印象深く残っている。
5. システムは作って終わりではない
システム開発の仕事というと、要件を決め、設計して、プログラムを作り、完成したら納品する。
そんなイメージがあるかもしれない。
もちろん、それも必要な仕事である。
しかし、実際には、システムが稼働して初めて分かることもある。
日々の仕事がシステムで処理できるようになれば、それまで見えなかった数字が見えるようになる。
すると、今度はその数字を使って別のことを考えたくなる。
今回の統計テーブルの追加やExcelでの分析も、まさにそのような流れだった。
最初からすべてを予測して、必要な機能を用意することは簡単ではない。
だからこそ、稼働後もお客様の話を聞き、実際の使い方を確認しながら、必要に応じて改善していくことが大切なのだ。
そして、そのためにも人間関係が欠かせない。
今回の仕事では、初めに週一回の訪問を重ね、部長さんと信頼関係を築くことができた。
だからこそ、分からないことを率直に質問できたし、複雑な業務も丁寧に教えてもらえた。
稼働後に新しい要望が出てきたときにも、一緒に考えることができた。
お客様の仕事を理解することと、人間関係を築くことは、別々の話ではないのだと思う。
6. 今のDXやAI活用にも通じる、変わらない仕事の進め方
この運送会社のシステム開発を振り返ると、私が長年大切にしてきた仕事の進め方が、よく表れていると思う。
まず、お客様の困りごとを聞く。
次に、現場の仕事や情報の流れを理解し、課題を整理する。
そのうえで、何をどう変えれば解決につながるのかを考え、必要な仕組みを作る。
そして、稼働した後も一緒に考え、改善を続ける。
今回の案件では、元運転手の部長さんが持っていた豊富な経験と知恵が、そのすべての過程で大きな力になった。
会社のなかには、こうした貴重な知識や経験を持った人がいる。
ただ、その知恵が最初から業務フローや仕様書になっているとは限らない。
日々の仕事のなかに埋もれていることも多いのだ。
その知恵を引き出し、整理し、会社全体で活用できる形にしていくこと。
これは、今の私が取り組んでいる「WITS整理法」にもつながっている。
経営として何を実現したいのかという意思（Will）を確認し、組織や現場が持っている知恵（Intelligence）を整理する。
そして、必要な道具（Tools）を選び、どのように仕事を変えていくかという方針や道筋（Story & Strategy）を描く。
今回の運送会社の仕事も、振り返ってみれば、そうした流れで進めていた。
今はAIやクラウドなど、利用できる技術が大きく進歩している。
しかし、技術が進歩したからといって、会社の困りごとを理解することや、仕事の仕組みを整理することが不要になるわけではない。
むしろ、使える道具が増えた今だからこそ、何のために使うのか、どこをどう変えたいのかを考えることが重要になっていると思う。
困りごとを知り、課題を整理し、解決方法を考えて形にする。そして、稼働後も一緒に改善する。
運送会社の部長さんと二人三脚で取り組んだこの仕事は、私にとって、その大切さを改めて教えてくれた経験だった。
あの部長さんの分かりやすい説明と、二人でExcelの画面を見ながらグラフを作った時間は、今でもよく覚えている。
