PR

 次に色分けされた伝票と資料群を、新システムの設計者である私と、手伝ってくれた部下数人とで議論し、さらに分類していった。例えば新システムでの発生タイミングにそって分け直した。新システムで出力する必要があるデータか、そうでないデータか、見分けた。後工程に伝える目的で集めていたデータがあったが、後工程で必要になった時に出力すればそれで済む。

 分類を徹底した結果、かなり精緻に業務の内容を把握できた。色とりどりになり過ぎ、見づらくなったものは再度、色分けをし直した。システム設計が終了した後、色とりどりに塗りつぶされた伝票と資料を床の上で重ねてみると机の高さと同じくらいになっていた。

 地道な作業をしっかりやったことにより、業務の把握に加え、業務に必要なデータと、そうしたデータが生成、活用されるまでの現状業務フローを整理できた。

 ここで強調したいのは、データの生成・活用の場面をきちんと業務視点で捉えた業務フローを作成したことだ。データの流れ(データフロー)ではない、業務の流れである。

 システム屋の視点ではなく、業務屋の視点でまとめたわけだ。データの流れを捕捉するだけでも開発者にとっては意味があるだろうが、それだけでは現場とのコミュニケーションツールとして役にたたない。特に上流工程ではそうだ。私は業務フローにこだわる。今も変わらない。

 この段階で作成した業務フローはラフなものであった。細部に入りすぎず、データ分析を手伝ってくれた部下と私の間で、現状認識できるレベルという意味である。

 現状分析に時間をかけ、詳細な業務フローを作成している開発プロジェクトを時折見かけるが、時間の無駄なので止めたほうがよい。現状は未来を補足する参考情報に過ぎない。もちろん、参考情報とはいえ、抜けが沢山あってはいけない。

業務設計とシステムの要件定義をほぼ同時に進める

 次の作業は新工場の新しい業務とフローを検討、設計することだ。当然ながら新しい業務の設計も私が担当することになった。

 システムの要件定義をする前に業務の設計を終えておくこと、などと書いてある書籍を見かけることがある。正論である。ぜひ、そうあってほしい、と切に思う。ただし、残念ながら私はソフトハウスで派遣のSEやプログラマーをしていた時も、ユーザー企業に移ってからも、こうした理想的な状況に遭遇したことが一度もない。

 今回の新工場の新システムもそうだった。業務設計とシステムの要件定義をほぼ同時に進めるしかなかった。

 新しい業務フローを描く前に、新工場の業務とシステムで必ず満たさなければいけない、いくつかの要求事項を確認した。

●期日必達

 当たり前だが、工場の稼働開始に間に合わせる。システム開発に着手してから工場の稼働まで1年をきっていたが遅れは許されない。

●HACCP

 新工場の狙いである「HACCPに沿った運営」を可能にする。例えば「諸室ごとに立ち入り禁止区域を明確化する」「工程一方通行」「冷却工程追加」「調理機器変更に伴う調理支援体制作り」といったことを考慮する。HACCPは属人性を排除し、仕組みで衛生管理をすること。アレルギー対応を含む衛生面、配送面、営業面のそれぞれで、クレームやミスを誘発しかねない旧来の業務フローをつぶしていく。手作業による職人仕事をある程度排除する。

●正確性とサービスレベル維持の両立

 業務を正確かつ迅速にこなすとともに、従来からやっていた各種の調整を可能にし、サービスレベルを落とさないようにする。新工場の組織を改編し、分掌を明確にして、業務を「見える化」し、さらなる効率化を図る。といって、あるべき業務フローを押し付けるだけでは工場が回らなくなるから、例えば前日までのメニュー調整に対応する。

 私が所属しているサービス企業が持つ弁当工場では、サービスの一環としてメニューの調整を引き受けていた。例えば、弁当100本のうち、2本は肉抜き、3本はベジタブルといった受注を可能にしていた。決められたメニューだけを製造するほうがもちろん楽なのだが、調整に応じることが私たちの強みだった。

●将来変化への対応

 今後の少量多品種、大量少品種、業種別の対応メニュー生産といった柔軟な営業方針への対応を可能にする。弁当以外の例えば総菜、贈答品を製造するといった今後の事業展開に対応できる拡張性を持たせる。

現場のやる気を維持するシステムを

 必達の要件を整理していく中で、もう一つ重要な要件があることに思い当たった。「モチベーション」である。工場で働く人たちが、食へのこだわりを持って、仕事ができなければ話にならない。