私が大切にしているのは、システム開発に入る前の段階です。
新しい仕組みを作る話の前に、**今の業務がどう流れているか**を整理する。
ここに時間をかけると、後の工程がずっとスムーズになります。
急いで作り始めるより、まず足元を見る。
これが私のやり方です。
## 業務改善は「流れを見る」ことから
業務改善というと、一つひとつの作業を速くする話だと思われがちです。
でも私が最初に見るのは、作業そのものではなく**作業と作業のつなぎ目**です。
ある人の仕事が終わって、次の人に渡るまで。
そこに待ち時間や行き違いが隠れていることが多いからです。
たとえば、担当者の確認待ちで書類が止まっている。
一つの作業が速くても、その先で止まっていては全体は進みません。
個々の作業より、流れ全体を眺める。
これが現場を整える出発点になります。
## システム開発は「整理してから」
業務が整理されないまま開発に進むと、今のやり方をそのまま仕組みに写し取ることになります。
ムダがある流れのまま作ってしまうと、その不便さも一緒に固定されてしまいます。
だから私は、**まず流れを整え、それから開発を考える**順番を大切にしています。
整理された業務は、何を作るべきかをはっきり教えてくれます。
逆に、整理が足りないまま進めると、作っている途中で「やっぱりこうしたい」が次々に出てきます。
## 現場の言葉を拾う
業務の流れは、実際に動いている人がいちばんよく知っています。
机の上だけで整理しようとすると、現場の実態とずれてしまいます。
「ここはいつも手間取る」「この確認が地味に時間を取る」。
現場で交わされている言葉には、整理のヒントが詰まっています。
私は、その言葉を拾いながら、流れを書き起こしていきます。
## 書き起こすと見えてくる
頭の中にある流れを、紙やホワイトボードに書き出してみる。
それだけで、ふだん気づかなかった引っかかりが見えてきます。
見える形にすることが、改善の第一歩になります。
## 整理は一度きりではない
業務の流れは、時間とともに少しずつ変わっていきます。
一度整理して終わりではなく、折にふれて見直していく。
そのたびに小さな引っかかりを取り除いていくと、現場はだんだん動きやすくなっていきます。
## 萩原教章のまとめ
業務改善とシステム開発は、別々のものではありません。
**まず流れを整え、そのうえで仕組みを考える。**
この順番を守るだけで、開発の手戻りがぐっと減ります。
現場を起点に整理することが、私の仕事の土台です。
