前編の振り返り

工場のリードタイム（注文から発送までの時間）を調査することを最終的な目的に、以下のような順で段階的に取り組みました。

1. 現状の分析
2. 課題発見のためのデータ探索
3. 「聞き取り→改善→データ確認」の繰り返し

前編では現状の分析とデータを探索するところまでを書きました。その結果、待機時間が長いという問題と「どの基板がどの工程をいつ通過したか」という基本的なデータがリアルタイムに登録されていない問題が見つかり、これらの問題の原因を調査して解決することになりました。後編はこの調査から解決までの過程を書きます。

「聞き取り→改善→データ確認」の繰り返し

本質的な原因は何か？

待機時間が長いという問題やデータがリアルタイムに入力されていないという問題は表面的なもので、直接的に解決しようとするのではなく、これらの問題を生んでいるより本質的な原因を見つけることが必要だと思われました。「なぜなぜ分析」「Five Whys」などと呼ばれる手法が製造業では知られていて、5回の「なぜ？」を繰り返すことで本質的な原因が見つかるとされていますが、実際にはどこまで原因を深く掘っていけば本質的な原因と言えるのかという判断に知識や経験が生かされると感じます。

今回のケースで言えば、本来リアルタイムに作業記録を登録してほしいところ登録が後回しにされているという問題だったため、直接的な解決案としては「リアルタイムに登録してくださいと作業者に改めて伝える」という方法になりますが、これは経験的にうまくいかないだろうと思われました。リアルタイムに登録する方が作業も楽なためあえて後回しにする理由がなく、リアルタイムに登録されてないとすればそうなる構造的な原因があると考える方が自然なためです。

その原因を調べるために工場に作業者の意見を聞き取りに行きました。実際はリアルタイムな登録の問題以外にも運搬が少なく工程間でシート（基板が複数並べられた製造の最小単位）が待機している時間が長い問題も調べましたが、ここでは長くなるので印刷・焼成工程のリアルタイムな登録に絞って書きます。

一回目の聞き取り–七月下旬

七月下旬に、リアルタイムな登録が最もされていなかった印刷と焼成の工程の聞き取りを行いました。

印刷〜焼成の工程では、印刷開始時、印刷終了時、焼成終了時に登録をすることになっていましたが、聞き取りをしたところ焼成終了時に全ての登録をまとめてしているということがわかりました。生産中はシート1枚につき登録用のバーコードが記載された紙1枚が一緒に運搬されるという前提で登録の仕組みが作られていたのですが、印刷を開始する時点ではまだシートが1枚ずつにカットされていないためシートとバーコードの紙が一緒に運搬されておらず、どのバーコードを使って登録すれば良いのか分からないという問題が挙がりました。そこで単純な解決策としてバーコードが記載された紙を印刷を開始する時点で印刷用プリンタの横にまとめて置く箱を作ることで、今印刷しているシートがどのバーコードのものか分かるようにすることにしました。

二回目の聞き取り–八月中旬

しばらく他の仕事に取り組んだ後、八月中旬に改めて登録の状況を調べることにしました。まずデータを確認したところ、3割くらいはリアルタイムに登録されていたものの、多くのシートは相変わらず後でまとめて登録されていました。

このデータを持って改めて工場に行き聞き取れた内容は次のようなものでした。

1. バーコードの紙を置くスペースはプリンタの横に作られていた
2. 印刷〜焼成の間で登録は3回行うが、登録を行える場所が1ヶ所しかなく、1回にまとめて登録をする方が楽だった
3. 登録用のフォームがシート8枚まとめて登録するようになっていたが、現状では運用が変わり4枚単位で製造されていた

前回の聞き取りの後に提案したバーコードの紙を置くスペースが作られていたのは良かったことですが、逆に言うとそれでも結果があまり改善しなかったのは他に重要な原因があると言うことを示唆していると考えられました。幸い聞き取りの中で重要そうな問題がさらに二つ挙げられたので、これらを改善していくことにしました。

まずは登録できる場所を増やす取り組みをしました。印刷開始・印刷終了・焼成終了のうち、印刷終了したシートと焼成終了したシートは近い場所に保管されているため、その近くにあるPCとバーコードリーダで登録をすることは理にかなっています。一方で印刷を開始するのは離れた場所にあるPCだったので、そのPCに新しくバーコードリーダを設置することで印刷開始の指示を出すPCから同時に登録もできるようにしました。

また、登録用フォームがいつの間にか現状の運用と合わなくなってしまっていた問題については、早めにソフトウェアを改善することとして、9日後に改めてデータの確認と聞き取り作業を行う予定を立てました。

三回目の聞き取り–八月下旬

前回出たソフトウェアの問題もすぐに修正し、その結果が出たかどうか9日後にデータを確認したところ、ほぼ完璧にリアルタイムな登録がされていました。

念のためにもう一度工場に聞き取りに行き話も聞きましたが、作業者も登録がしやすくなったと感じていて他の問題も特に感じないようだったので、めでたくこの取り組みは一旦終了となりました。

この調査を通しての感想

ソフトウェアを作ったものの思ったように使ってもらえないという問題はしばしば起きることですが、しっかり問題を聞き取って粘り強く対応していけば使ってもらえるということが分かったのはとても良いことでした。様々な試行錯誤をしましたが、結果的には挙がった問題を修正したところ予想外にすぐにソフトウェアを使ってもらえるようになったのはやった甲斐があって嬉しかったです。ソフトウェアの分析・データの分析・現場の分析を包括的に行うことで課題発見・解決がうまくできました。

また本文中では触れませんでしたが、二人のチームでこの調査を行ったのはとても良い点でした。視点や聞き取り方が違って聞き取りの結果も変わりますし、改善もそれぞれの得意なことの違いを生かしてより素早く対応できました。効果が大きそうな改善案を選び、工場の環境改善や作業者への連絡はお願いし、僕はソフトウェアの開発に集中しました。一人で取り組んでいるとやらないと決めた改善案にも未練が出てプログラムを書き始めたりしてしまいがちですが、チームで取り組むと聞き取り作業にしても改善作業にしてもスケジュールを合わせてその日までの宿題を終わらせて臨まないといけないので、自然とメリハリがついたのも良い点だったと思います。

一方で、今回の取り組みで結果が出ない問題もありました。（シートの運搬と待機時間の問題です。）このような業務用ソフトウェアは開発と実作業の運用が密接に繋がっていて、実作業の運用を変更しないとソフトウェアの変更だけでは意味がないことも多くあります。現状でも運用ルールの変更には手間がかかることが多いですが、今後会社が大きくなり、縦割り化や運用のルール化が進むとますます変更が難しくなることが想定されます。ソフトウェア開発では規模が大きくなっても変更がしやすいソフトウェアが良いソフトウェアとされますが、組織や運用についても同じように変更されることを前提に仕組み作りをすることで固定化することを防げるのではないでしょうか。運用を決めたらその見直し時期や方法を同時に決めるなど、常に変更される仕組みづくりを初めからすることが重要だと感じました。