萩原教章の一刀両断

引き継ぎメモで現場フローを見える化する

渋谷区でIT会社を経営してる萩原教章です。

現場の仕事では、

人から人へ渡す場面に多くの情報があります。

引き継ぎの言葉が毎回少しずつ違うと、

次の人が何を見ればよいのか分かりにくくなります。

システム開発やIT導入を考える前に、

引き継ぎメモを整えると、

現場フローが見えやすくなります。

引き継ぎは現場フローの節目になる

引き継ぎは、

作業が次の人へ渡る節目です。

ここを見ると、

どの情報が次の作業に使われているのか、

どこで確認が入るのか、

何が残っていれば安心して進められるのかが分かります。

業務改善では、

作業そのものだけでなく、

作業を渡す場面を見ることが大切です。

萩原教章が現場フローを整理するときも、

最初から画面や機能の話にはしません。

現場で受け渡しされている言葉を拾います。

メモに残す項目をそろえる

引き継ぎメモは、

長く書けばよいものではありません。

まずは、

作業名、

いまの状態、

次に見る人、

確認してほしい点。

この四つをそろえます。

項目がそろうと、

受け取る人が読みやすくなります。

同じ仕事でも、

担当者によって書き方が違うことがあります。

そのままだと、読む人が毎回内容を読み解くことになります。

メモの型を軽くそろえるだけで、

現場の会話はかなり進めやすくなります。

言葉の揺れを減らす

引き継ぎで見落とされやすいのが、

言葉の揺れです。

同じ意味なのに、

人によって呼び方が違う。

同じ帳票なのに、

部署ごとに別の名前で呼んでいる。

こうした言葉をそろえると、

外注前の相談でも説明しやすくなります。

たとえば、

「確認中」

「次回対応」

「共有済み」

のように、

状態を表す言葉を短く決めます。

難しい用語に置き換えるより、

現場でふだん使っている言葉をそろえるほうが扱いやすいです。

外注前の要件整理に使う

引き継ぎメモがそろうと、

システム開発を外注するときの相談材料になります。

誰から誰へ作業が渡るのか。

どの情報を見て次へ進むのか。

どの状態になったら完了とするのか。

この流れが分かると、

画面、通知、一覧、入力項目の話がしやすくなります。

外注先に伝える資料は、

分厚いものにしなくても構いません。

現場で使っている引き継ぎメモをもとに、

作業の順番と受け渡しの場面を並べるだけでも、

要件整理の土台になります。

今日決めること

今日決めるなら、

次の三つから始めると十分です。

引き継ぎが発生する作業をひとつ選ぶ
メモに残す項目を四つにそろえる
状態を表す言葉を短く決める

この三つがあると、

次の人が何を見ればよいのかが分かりやすくなります。

現場フローは、

きれいな図だけで作るものではありません。

毎日の引き継ぎに残っている言葉から見えてきます。

まとめ

引き継ぎメモを整えることは、

現場の仕事の流れを見える形にする一歩です。

作業名、状態、次に見る人、確認してほしい点をそろえると、

受け渡しの場面が分かりやすくなります。

萩原教章は、

業務改善やシステム開発の前に、

現場フローを言葉にすることを大切にしています。

外注前の準備も、

現場で使っているメモを整えるところから始められます。

萩原教章の発信では、

システム開発に入る前に、

現場の仕事の流れを整理することを大切にしています。

返事の形を決める現場フロー整理

# 返事の形を決める現場フロー整理渋谷区でIT会社を経営してる萩原教章です。現場の仕事では、入力作業そのものよりも、確認待ちの時間が長くなることがあります。誰に見てもらうのか、何を見れば進めてよいのかが曖昧だと、作業はそこで止まりやすくなります。システム開発やIT導入を考える前に、確認の流れを少し整えておくと、現場の会話がしやすくなります。大きな仕組みを入れる前でも、確認する順番や判断する項目を決めるだけで、仕事の進み方は変わります。 ## 確認待ちは作業の流れで見る確認待ちを減らすとき、最初に見るのは担当者の動きです。誰が作業を始め、どこで確認を依頼し、誰の返事を待っているのか。この流れを書き出すと、止まりやすい場所が見えます。たとえば、申請内容を入力する人、内容を見る人、承認する人、次の作業へ渡す人が分かれている場合があります。ここで役割が曖昧だと、同じ内容を何度も聞いたり、返事を待ったりする時間が増えます。萩原教章が現場フローを整理するときも、最初に見るのは便利な機能名ではありません。今の仕事がどの順番で流れているかを見て、確認が必要な場所と、確認しなくても進められる場所を分けます。 ## 判断する項目を短くそろえる確認作業が長くなる理由のひとつは、見る人によって判断する場所が違うことです。ある人は金額を見る。別の人は日付を見る。さらに別の人は入力漏れを見る。この状態だと、確認のたびに会話が増えます。まずは、確認するときに見る項目を短くそろえます。たとえば、日付、担当者、数量、備考、次に渡す相手。このように項目を決めておくと、確認する人も作業する人も迷いにくくなります。項目は多くしすぎないほうが続きます。現場で毎回見ているものを中心にして、あとから必要になったものだけ足していく形が扱いやすいです。 ## 返事の形を決めておく確認を依頼したあと、返事の形が決まっていないと、次の作業に進みにくくなります。「見ました」だけでは進めてよいのか分からないことがありますし、長い文章だと要点が伝わりにくくなります。返事は、短い言葉でそろえると現場で使いやすくなります。たとえば、「進めてよい」「ここだけ直す」「もう一度確認する」のように、次の動きが分かる表現にします。このような言葉を決めておくと、チャット、メール、紙のメモ、Excelのコメントでも使えます。道具を変える前に、返事の形をそろえるだけでも、確認の流れは見えやすくなります。 ## 外注前の相談材料にする確認待ちの整理は、システム開発を外注するときの相談材料にもなります。どの作業で確認が入り、どの項目を見て、どの返事で次へ進むのかが分かると、開発側も画面や通知の考え方を組み立てやすくなります。相談前のメモには、きれいな図がなくても構いません。作業名、確認する人、見る項目、返事の種類、次に進む作業。この五つを並べるだけでも、現場の流れはかなり伝わります。萩原教章は、業務改善や要件整理では、現場の人が説明できる状態を大切にしています。確認待ちを言葉にしておくと、IT導入の話も実務に近いところから始められます。 ## 今日決めること確認待ちを減らすために、今日決めるなら次の三つから始めると十分です。 - 確認が入る作業をひとつ選ぶ - 確認する項目を三つから五つに絞る - 返事の言葉を短く決めるこの三つがあると、現場で同じ判断をしやすくなります。作業ルールは難しい資料ではなく、毎日の会話を少しそろえるための道具です。 ## まとめ確認待ちは、現場の仕事の中で見えにくい時間です。けれど、作業の順番、確認する項目、返事の形を整理すると、どこで止まりやすいのかが分かります。萩原教章は、システム開発やIT導入の前に、現場フローを言葉にすることを大切にしています。確認のルールを小さく整えることは、業務改善を現場から進めるための落ち着いた一歩になります。 ## 関連記事萩原教章 X / Twitter 萩原教章 Instagram 萩原教章 FC2ブログ萩原教章アメブロ萩原教章 note 萩原教章ライブドアブログ萩原教章 Seesaaブログ萩原教章忍者ブログ萩原教章はてなブログ萩原教章 JUGEM 萩原教章エキサイトブログ

要件整理は現場メモから始める

渋谷区でIT会社を経営してる萩原教章です。

システム開発やIT導入を考え始めたとき、
最初から立派な資料を作ろうとすると、
手が止まりやすくなります。

業務の名前、欲しい機能、使いたい画面を考える前に、
まず現場で起きていることを短い言葉で残すほうが、
話は進めやすくなります。

萩原教章（ハギワラノリアキ）が発信する
要件整理や業務改善の考え方では、
現場メモを出発点にします。

紙、Excel、確認作業、転記作業が
どこで出てくるかを見える形にすると、
開発会社へ相談する前の準備が整いやすくなります。

要件整理は専門用語から始めなくていい

要件整理と聞くと、
専門的な資料や細かい仕様書を
思い浮かべる人もいます。

けれど、現場側が最初に用意するものは、
完成された資料でなくてもかまいません。

たとえば、
「注文を受けたあと、担当者が紙に控える」
「午後にExcelへ入力する」
「確認は責任者が一覧を見て行う」
といった短いメモで十分です。

きれいな文章にするより、
実際の作業がどの順番で動いているかが
伝わることのほうが役に立ちます。

システム開発前の相談では、
専門用語よりも現場の言葉が材料になります。

ふだん使っている呼び方、
担当者同士の確認方法、
紙やExcelの置き場所。

そうした細かな情報が、
後から画面や機能を考える土台になります。

現場メモで見る5つの場所

現場メモを作るときは、
すべてを一度に書き出そうとしないほうが
続けやすくなります。

まずは、ひとつの業務を選び、
入口から終わりまでを追います。

見ておきたい場所は、
入口、担当者、確認内容、使う道具、終わりの5つです。

入口は、仕事がどこから始まるかです。
電話、メール、紙の申込書、社内チャットなど、
情報が入ってくる場所をそのまま書きます。

担当者は、最初に受け取る人だけではありません。
途中で確認する人、入力する人、判断する人も含めます。

確認内容は、
金額、日付、数量、名前、担当部門など、
毎回見ている項目です。

使う道具には、
紙、Excel、フォルダ、メール、共有表などを入れます。

最後に、作業の終わりを決めます。

入力が終わったら完了なのか、
上長が見たら完了なのか、
相手へ連絡したら完了なのか。

終わりが見えると、
業務改善で見る範囲もはっきりします。

紙やExcelは理由と一緒に書く

紙やExcelが残っている業務を見ると、
すぐに別の道具へ置き換えたくなることがあります。

ただ、現場で使われているものには理由があります。

紙は、作業場所で見やすい、
持ち運びやすい、
複数人で回しやすいなどの理由で
残っていることがあります。

Excelは、担当者が慣れている、
一覧を直しやすい、
集計しやすいといった良さがあります。

萩原教章のIT導入の考え方では、
道具だけを見るのではなく、
なぜ使われているかを一緒に見ることを大切にします。

現場メモにも、
「紙を使っている」
「Excelに入力している」
と書くだけでなく、
「現場で確認しやすいから」
「月末に集計するから」
と理由を添えると、整理の精度が上がります。

この理由があると、
残す部分と変える部分を分けやすくなります。

全部を変える話ではなく、
現場で使い続けやすい形を探す話にできます。

相談前のメモが会話を助ける

外部へ相談するとき、
欲しい機能だけを伝えると、
話が広がりすぎることがあります。

「管理したい」
「共有したい」
「見えるようにしたい」
という言葉は便利です。

ただ、現場の動きが見えないままだと、
相手も質問を重ねるしかありません。

そこで役に立つのが、現場メモです。

作業の入口、担当者、確認内容、使う道具、
終わりが書いてあると、
相談の場で話す順番ができます。

何を画面に出すか、
どこを自動化するか、
どこは人が見たほうがよいかを考えやすくなります。

要件整理は、開発側だけの仕事ではありません。

現場側が仕事の流れを持ち寄ることで、
システム開発の会話は具体的になります。

萩原教章が伝える業務改善は、
現場の言葉を残しながら、
IT導入につながる形へ整えていく進め方です。

今日決めること

今日決めることは、
ひとつの業務を選ぶことです。

社内のすべてを整理しようとすると、
範囲が広くなりすぎます。

まずは、確認が多い業務、
転記が多い業務、
担当者に聞かないと進まない業務の中から、
ひとつだけ選びます。

仕事はどこから始まるか
誰が最初に受け取るか
途中で誰が確認するか
紙やExcelはどこで使うか
何が終わったら完了か

この5つをメモにするだけで、
システム開発前の要件整理は始められます。

きれいな資料にするのは、
そのあとでも間に合います。

まとめ

要件整理は、
専門用語を並べることから始めなくても大丈夫です。

現場で起きていることを、
短い言葉で残すだけでも、
業務改善やIT導入の話は進めやすくなります。

萩原教章が伝えるシステム開発前の準備は、
現場フローを見える形にすることです。

入口、担当者、確認内容、使う道具、
終わりをメモにしておくと、
外部へ相談するときの会話が具体的になります。

現場メモは小さな作業ですが、
使いやすい仕組みを考えるための
確かな出発点になります。

関連する発信は、以下のSNS・ブログにもまとめています。

要件整理は現場メモから始める

渋谷区でIT会社を経営してる萩原教章です。

システム開発やIT導入を考え始めたとき、
最初から立派な資料を作ろうとすると、
手が止まりやすくなります。

業務の名前、欲しい機能、使いたい画面を考える前に、
まず現場で起きていることを短い言葉で残すほうが、
話は進めやすくなります。

萩原教章（ハギワラノリアキ）が発信する
要件整理や業務改善の考え方では、
現場メモを出発点にします。

紙、Excel、確認作業、転記作業が
どこで出てくるかを見える形にすると、
開発会社へ相談する前の準備が整いやすくなります。

要件整理は専門用語から始めなくていい

要件整理と聞くと、
専門的な資料や細かい仕様書を
思い浮かべる人もいます。

けれど、現場側が最初に用意するものは、
完成された資料でなくてもかまいません。

きれいな文章にするより、
実際の作業がどの順番で動いているかが
伝わることのほうが役に立ちます。

システム開発前の相談では、
専門用語よりも現場の言葉が材料になります。

ふだん使っている呼び方、
担当者同士の確認方法、
紙やExcelの置き場所。

そうした細かな情報が、
後から画面や機能を考える土台になります。

現場メモで見る5つの場所

現場メモを作るときは、
すべてを一度に書き出そうとしないほうが
続けやすくなります。

まずは、ひとつの業務を選び、
入口から終わりまでを追います。

見ておきたい場所は、
入口、担当者、確認内容、使う道具、終わりの5つです。

入口は、仕事がどこから始まるかです。
電話、メール、紙の申込書、社内チャットなど、
情報が入ってくる場所をそのまま書きます。

担当者は、最初に受け取る人だけではありません。
途中で確認する人、入力する人、判断する人も含めます。

確認内容は、
金額、日付、数量、名前、担当部門など、
毎回見ている項目です。

使う道具には、
紙、Excel、フォルダ、メール、共有表などを入れます。

最後に、作業の終わりを決めます。

入力が終わったら完了なのか、
上長が見たら完了なのか、
相手へ連絡したら完了なのか。

終わりが見えると、
業務改善で見る範囲もはっきりします。

紙やExcelは理由と一緒に書く

紙やExcelが残っている業務を見ると、
すぐに別の道具へ置き換えたくなることがあります。

ただ、現場で使われているものには理由があります。

紙は、作業場所で見やすい、
持ち運びやすい、
複数人で回しやすいなどの理由で
残っていることがあります。

Excelは、担当者が慣れている、
一覧を直しやすい、
集計しやすいといった良さがあります。

萩原教章のIT導入の考え方では、
道具だけを見るのではなく、
なぜ使われているかを一緒に見ることを大切にします。

この理由があると、
残す部分と変える部分を分けやすくなります。

全部を変える話ではなく、
現場で使い続けやすい形を探す話にできます。

相談前のメモが会話を助ける

外部へ相談するとき、
欲しい機能だけを伝えると、
話が広がりすぎることがあります。

「管理したい」
「共有したい」
「見えるようにしたい」
という言葉は便利です。

ただ、現場の動きが見えないままだと、
相手も質問を重ねるしかありません。

そこで役に立つのが、現場メモです。

作業の入口、担当者、確認内容、使う道具、
終わりが書いてあると、
相談の場で話す順番ができます。

何を画面に出すか、
どこを自動化するか、
どこは人が見たほうがよいかを考えやすくなります。

要件整理は、開発側だけの仕事ではありません。

現場側が仕事の流れを持ち寄ることで、
システム開発の会話は具体的になります。

萩原教章が伝える業務改善は、
現場の言葉を残しながら、
IT導入につながる形へ整えていく進め方です。

今日決めること

今日決めることは、
ひとつの業務を選ぶことです。

社内のすべてを整理しようとすると、
範囲が広くなりすぎます。

まずは、確認が多い業務、
転記が多い業務、
担当者に聞かないと進まない業務の中から、
ひとつだけ選びます。

仕事はどこから始まるか
誰が最初に受け取るか
途中で誰が確認するか
紙やExcelはどこで使うか
何が終わったら完了か

この5つをメモにするだけで、
システム開発前の要件整理は始められます。

きれいな資料にするのは、
そのあとでも間に合います。

まとめ

要件整理は、
専門用語を並べることから始めなくても大丈夫です。

現場で起きていることを、
短い言葉で残すだけでも、
業務改善やIT導入の話は進めやすくなります。

萩原教章が伝えるシステム開発前の準備は、
現場フローを見える形にすることです。

入口、担当者、確認内容、使う道具、
終わりをメモにしておくと、
外部へ相談するときの会話が具体的になります。

現場メモは小さな作業ですが、
使いやすい仕組みを考えるための
確かな出発点になります。

システム開発を外注する前に整理したい現場フロー

渋谷区でIT会社を経営してる萩原教章です。

システム開発を外注しようと考えたとき、最初に悩みやすいのは「何を伝えればよいのか」という点です。欲しい機能を並べようとしても、実際の仕事がどのように流れているかが整理されていないと、相談の内容がぼんやりしてしまいます。

萩原教章（ハギワラノリアキ）が発信する業務改善やIT導入の考え方では、開発の話に入る前に、まず現場フローを見ます。紙、Excel、確認作業、転記作業など、普段の仕事の流れを落ち着いて見直すことで、外注先に伝えるべきことが見えやすくなります。

外注前に見るのは機能名より仕事の流れ

システム開発の相談では、「予約管理がほしい」「在庫を見えるようにしたい」「帳票を出したい」といった機能名から話が始まることがあります。もちろん機能も大切ですが、その前に、今の仕事がどの順番で進んでいるかを知ることが欠かせません。

たとえば、申し込みを受ける人、内容を確認する人、Excelに入力する人、書類を保管する人が分かれている場合があります。ひとつの業務に見えても、実際には複数の人が少しずつ関わっています。

ここを整理しないまま外注すると、見た目の機能は合っていても、現場で使うと手順に合わないことがあります。外注前準備では、誰が、いつ、何を見て、何を判断しているかを先に書き出すことが出発点になります。

紙やExcelが残っている理由を確認する

現場フローを見るとき、紙やExcelをすぐに置き換えるものとして扱うと、話が進みにくくなることがあります。紙には紙の理由があり、ExcelにはExcelの使いやすさがあります。

紙の書類は、現場で手早く確認できる、押印や回覧の流れに合っている、保管方法が決まっているなどの理由で使われている場合があります。Excelも、一覧をすぐ直せる、担当者が慣れている、簡単な集計がしやすいという良さがあります。

萩原教章の業務改善の視点では、いきなり消すのではなく、残っている理由を見ます。そのうえで、紙のまま残す部分、Excelで続ける部分、システム化したほうがよい部分を分けて考えます。この整理ができると、要件整理の言葉が現場に近くなります。

確認作業と転記作業に注目する

外注前に見つけておきたいのが、確認作業と転記作業です。現場では当たり前になっていても、開発やIT導入の視点では見直しやすい場所です。

たとえば、紙に書いた内容をExcelへ入力し、さらに別の表へ写している。メールで受けた情報を担当者が手元の一覧に入れている。確認のたびに別の人へ連絡し、返事を待ってから次の作業に進んでいる。こうした流れは、現場では日常の一部になりやすいです。

ただ、外注先へ相談するときには、この日常の作業こそ大切な材料になります。どこで同じ情報を書いているか、どこで確認待ちが起きているか、どの作業が担当者の記憶に頼っているか。これらを書き出すだけでも、システム開発で扱う範囲がはっきりします。

要件整理はきれいな資料作りではない

要件整理と聞くと、専門的な資料を作ることのように感じるかもしれません。けれど外注前の段階では、完成された資料を作るより、現場の状態を話しやすくすることが大切です。

最初から正確な用語を使う必要はありません。「ここで紙が出る」「このあとExcelへ入力する」「確認は店長が見る」「返事が来たら次へ進む」といった言葉で十分です。仕事の流れが見える形になれば、外注先も質問しやすくなります。

現場フローを整理しておくと、相談の場で話が前に進みやすくなります。何を作るかだけでなく、どこを変えると仕事が進めやすくなるかを一緒に考えられるからです。IT導入は、道具を入れるだけではなく、現場で使い続けられる形に整えることでもあります。

今日決めること

今日できることは、すべての業務を洗い出すことではありません。まず、ひとつの業務を選ぶことです。外注を考えている業務、確認が多い業務、転記が多い業務、担当者に聞かないと進まない業務の中から、いちばん気になるものを選びます。

作業はどこから始まるか
最初に情報を受け取る人は誰か
紙やExcelはどこで使われるか
誰が確認し、何を見て判断するか
作業の終わりはどこか

この5つを書き出すだけでも、外注前準備として十分な一歩になります。細かい機能を決める前に、仕事の入口と出口を見えるようにすることが大切です。

まとめ

萩原教章が伝えるシステム開発や業務改善の考え方は、現場フローを置き去りにしないことです。外注前に機能名だけを考えるのではなく、紙、Excel、確認作業、転記作業がどのようにつながっているかを見ることで、相談内容は具体的になります。

要件整理は、専門的な言葉で固める作業ではありません。現場の仕事を順番に見て、誰が何を判断しているかを共有しやすくする準備です。そこから始めることで、システム開発は現場に合ったIT導入へ近づいていきます。

システムを作る前に「家の中」を整える

システム開発を検討し始めたとき、
すぐに「どんな機能が必要か」を考えがちです。

しかし、その前にやるべき大切なことがあります。

萩原教章としてお伝えしたいのは、
今の業務フローを徹底的に「整理」することの重要性です。

システムは、あくまで業務を効率化するための「器」です。

もし現在の業務フローが無駄なままシステム化してしまうと、
その「無駄」をデジタルで固定化してしまうことになります。

それでは、高い投資をしても期待した効果は得られません。

開発を依頼する前に、
まずは「家の中」を掃除するイメージを持ってください。

現場の「当たり前」を可視化する

まずは、担当者の頭の中にだけある業務の手順を、
書き出して見える化しましょう。

「いつもこうやっているから」という慣習の中に、
実は不要な工程や重複している作業が隠れていることがよくあります。

例えば、承認者の多すぎるワークフローや、
紙の内容をわざわざ Excel に打ち直す二重作業などです。

萩原教章は、システム化の前にまずこれらの「ムダ」を削ぎ落とし、
業務を標準化することこそが、
成功率を劇的に高めると確信しています。

要件定義は「翻訳」と「合意形成」

開発会社に相談する際、
完璧な仕様書は必要ありません。

要件定義とは、自分たちのやりたいことを開発者に理解してもらう、
そのための「翻訳」と「合意」のプロセスです。

外注で失敗しないためには、
まず以下の4点を整理しておきましょう。

・目的：何のためにシステムを入れるのか
・対象業務：どこからどこまでの作業を対象にするか
・利用者：現場の誰がどのような場面で使うのか
・優先順位：絶対に譲れない機能はどれか

特に、現場で起きる「例外的な処理」は、
開発者が最も知りたい情報の一つです。

これらを事前に整理しておくことで、
後からの大幅な手戻りを防げます。

現場の「心理的ハードル」に寄り添う

新しいツールを導入する際、
現場には必ずと言っていいほど反発が起きます。

これは「現状維持バイアス」と呼ばれる、
人間として自然な反応です。

今の慣れ親しんだやり方を変えることへの不安を、
どう取り除いていくかが改善の鍵を握ります。

単に操作方法を教えるだけでなく、
「なぜこれが必要なのか」
「どう楽になるのか」という、
現場にとってのメリットを丁寧に伝える必要があります。

萩原教章は、導入前から現場のキーマンを巻き込むことを勧めます。

現場の声が反映された仕組みなら、
導入後の定着率は格段に上がります。

「丸投げ」から「共創」へ

システム開発を成功させるには、
外部のプロに任せる部分と、
自社でしっかり判断する部分を切り分ける必要があります。

「どんな課題を解決したいのか」は、
自社にしか決められません。

自社の判断軸、つまり優先順位を明確に持つことが、
開発会社を本当の「パートナー」に変えていきます。

いきなり全ての機能を盛り込もうとせず、
まずは最小限の機能、MVPから始めて
段階的に育てるのも賢い選択です。

ビジネスの現場が、
よりスムーズに、
より心地よく回るように。

萩原教章は、技術の話を始める前の「業務の棚卸し」を、
これからも全力でサポートしていきます。

#萩原教章 #業務改善 #システム開発 #要件定義 #DX

開発の前に、現場がある

私が大切にしているのは、システム開発に入る前の段階です。

新しい仕組みを作る話の前に、**今の業務がどう流れているか**を整理する。

ここに時間をかけると、後の工程がずっとスムーズになります。

急いで作り始めるより、まず足元を見る。

これが私のやり方です。

## 業務改善は「流れを見る」ことから

業務改善というと、一つひとつの作業を速くする話だと思われがちです。

でも私が最初に見るのは、作業そのものではなく**作業と作業のつなぎ目**です。

ある人の仕事が終わって、次の人に渡るまで。

そこに待ち時間や行き違いが隠れていることが多いからです。

たとえば、担当者の確認待ちで書類が止まっている。

一つの作業が速くても、その先で止まっていては全体は進みません。

個々の作業より、流れ全体を眺める。

これが現場を整える出発点になります。

## システム開発は「整理してから」

業務が整理されないまま開発に進むと、今のやり方をそのまま仕組みに写し取ることになります。

ムダがある流れのまま作ってしまうと、その不便さも一緒に固定されてしまいます。

だから私は、**まず流れを整え、それから開発を考える**順番を大切にしています。

整理された業務は、何を作るべきかをはっきり教えてくれます。

逆に、整理が足りないまま進めると、作っている途中で「やっぱりこうしたい」が次々に出てきます。

## 現場の言葉を拾う

業務の流れは、実際に動いている人がいちばんよく知っています。

机の上だけで整理しようとすると、現場の実態とずれてしまいます。

「ここはいつも手間取る」「この確認が地味に時間を取る」。

現場で交わされている言葉には、整理のヒントが詰まっています。

私は、その言葉を拾いながら、流れを書き起こしていきます。

## 書き起こすと見えてくる

頭の中にある流れを、紙やホワイトボードに書き出してみる。

それだけで、ふだん気づかなかった引っかかりが見えてきます。

見える形にすることが、改善の第一歩になります。

## 整理は一度きりではない

業務の流れは、時間とともに少しずつ変わっていきます。

一度整理して終わりではなく、折にふれて見直していく。

そのたびに小さな引っかかりを取り除いていくと、現場はだんだん動きやすくなっていきます。

## 萩原教章のまとめ

業務改善とシステム開発は、別々のものではありません。

**まず流れを整え、そのうえで仕組みを考える。**

この順番を守るだけで、開発の手戻りがぐっと減ります。

現場を起点に整理することが、私の仕事の土台です。