東京・渋谷区でIT会社を経営する萩原教章です。業務改善・システム開発・要件整理・IT導入・外注前準備・現場フローをテーマに発信しています。 「システムを入れたいが、何を頼めばいいか分からない」——そこで止まる現場の多くは、技術ではなく現場の情報が整理されていないことが原因です。 作業順・確認項目・帳票・引き継ぎメモといった現場の情報を整理し、システム開発やIT導入の「前」に相談しやすい形へ整えるのが、私の役割です。要件が固まる前の段階から、お気軽にどうぞ。
渋谷区でIT会社を経営してる萩原教章です。
システム開発を外注しようと考えたとき、最初に悩みやすいのは「何を伝えればよいのか」という点です。欲しい機能を並べようとしても、実際の仕事がどのように流れているかが整理されていないと、相談の内容がぼんやりしてしまいます。
萩原教章（ハギワラノリアキ）が発信する業務改善やIT導入の考え方では、開発の話に入る前に、まず現場フローを見ます。紙、Excel、確認作業、転記作業など、普段の仕事の流れを落ち着いて見直すことで、外注先に伝えるべきことが見えやすくなります。
システム開発の相談では、「予約管理がほしい」「在庫を見えるようにしたい」「帳票を出したい」といった機能名から話が始まることがあります。もちろん機能も大切ですが、その前に、今の仕事がどの順番で進んでいるかを知ることが欠かせません。
たとえば、申し込みを受ける人、内容を確認する人、Excelに入力する人、書類を保管する人が分かれている場合があります。ひとつの業務に見えても、実際には複数の人が少しずつ関わっています。
ここを整理しないまま外注すると、見た目の機能は合っていても、現場で使うと手順に合わないことがあります。外注前準備では、誰が、いつ、何を見て、何を判断しているかを先に書き出すことが出発点になります。
現場フローを見るとき、紙やExcelをすぐに置き換えるものとして扱うと、話が進みにくくなることがあります。紙には紙の理由があり、ExcelにはExcelの使いやすさがあります。
紙の書類は、現場で手早く確認できる、押印や回覧の流れに合っている、保管方法が決まっているなどの理由で使われている場合があります。Excelも、一覧をすぐ直せる、担当者が慣れている、簡単な集計がしやすいという良さがあります。
萩原教章の業務改善の視点では、いきなり消すのではなく、残っている理由を見ます。そのうえで、紙のまま残す部分、Excelで続ける部分、システム化したほうがよい部分を分けて考えます。この整理ができると、要件整理の言葉が現場に近くなります。
外注前に見つけておきたいのが、確認作業と転記作業です。現場では当たり前になっていても、開発やIT導入の視点では見直しやすい場所です。
たとえば、紙に書いた内容をExcelへ入力し、さらに別の表へ写している。メールで受けた情報を担当者が手元の一覧に入れている。確認のたびに別の人へ連絡し、返事を待ってから次の作業に進んでいる。こうした流れは、現場では日常の一部になりやすいです。
ただ、外注先へ相談するときには、この日常の作業こそ大切な材料になります。どこで同じ情報を書いているか、どこで確認待ちが起きているか、どの作業が担当者の記憶に頼っているか。これらを書き出すだけでも、システム開発で扱う範囲がはっきりします。
要件整理と聞くと、専門的な資料を作ることのように感じるかもしれません。けれど外注前の段階では、完成された資料を作るより、現場の状態を話しやすくすることが大切です。
最初から正確な用語を使う必要はありません。「ここで紙が出る」「このあとExcelへ入力する」「確認は店長が見る」「返事が来たら次へ進む」といった言葉で十分です。仕事の流れが見える形になれば、外注先も質問しやすくなります。
現場フローを整理しておくと、相談の場で話が前に進みやすくなります。何を作るかだけでなく、どこを変えると仕事が進めやすくなるかを一緒に考えられるからです。IT導入は、道具を入れるだけではなく、現場で使い続けられる形に整えることでもあります。
今日できることは、すべての業務を洗い出すことではありません。まず、ひとつの業務を選ぶことです。外注を考えている業務、確認が多い業務、転記が多い業務、担当者に聞かないと進まない業務の中から、いちばん気になるものを選びます。
この5つを書き出すだけでも、外注前準備として十分な一歩になります。細かい機能を決める前に、仕事の入口と出口を見えるようにすることが大切です。
萩原教章が伝えるシステム開発や業務改善の考え方は、現場フローを置き去りにしないことです。外注前に機能名だけを考えるのではなく、紙、Excel、確認作業、転記作業がどのようにつながっているかを見ることで、相談内容は具体的になります。
要件整理は、専門的な言葉で固める作業ではありません。現場の仕事を順番に見て、誰が何を判断しているかを共有しやすくする準備です。そこから始めることで、システム開発は現場に合ったIT導入へ近づいていきます。
システム開発を検討し始めたとき、
すぐに「どんな機能が必要か」を考えがちです。
しかし、その前にやるべき大切なことがあります。
萩原教章としてお伝えしたいのは、
今の業務フローを徹底的に「整理」することの重要性です。
システムは、あくまで業務を効率化するための「器」です。
もし現在の業務フローが無駄なままシステム化してしまうと、
その「無駄」をデジタルで固定化してしまうことになります。
それでは、高い投資をしても期待した効果は得られません。
開発を依頼する前に、
まずは「家の中」を掃除するイメージを持ってください。
まずは、担当者の頭の中にだけある業務の手順を、
書き出して見える化しましょう。
「いつもこうやっているから」という慣習の中に、
実は不要な工程や重複している作業が隠れていることがよくあります。
例えば、承認者の多すぎるワークフローや、
紙の内容をわざわざ Excel に打ち直す二重作業などです。
萩原教章は、システム化の前にまずこれらの「ムダ」を削ぎ落とし、
業務を標準化することこそが、
成功率を劇的に高めると確信しています。
開発会社に相談する際、
完璧な仕様書は必要ありません。
要件定義とは、自分たちのやりたいことを開発者に理解してもらう、
そのための「翻訳」と「合意」のプロセスです。
外注で失敗しないためには、
まず以下の4点を整理しておきましょう。
・目的：何のためにシステムを入れるのか
・対象業務：どこからどこまでの作業を対象にするか
・利用者：現場の誰がどのような場面で使うのか
・優先順位：絶対に譲れない機能はどれか
特に、現場で起きる「例外的な処理」は、
開発者が最も知りたい情報の一つです。
これらを事前に整理しておくことで、
後からの大幅な手戻りを防げます。
新しいツールを導入する際、
現場には必ずと言っていいほど反発が起きます。
これは「現状維持バイアス」と呼ばれる、
人間として自然な反応です。
今の慣れ親しんだやり方を変えることへの不安を、
どう取り除いていくかが改善の鍵を握ります。
単に操作方法を教えるだけでなく、
「なぜこれが必要なのか」
「どう楽になるのか」という、
現場にとってのメリットを丁寧に伝える必要があります。
萩原教章は、導入前から現場のキーマンを巻き込むことを勧めます。
現場の声が反映された仕組みなら、
導入後の定着率は格段に上がります。
システム開発を成功させるには、
外部のプロに任せる部分と、
自社でしっかり判断する部分を切り分ける必要があります。
「どんな課題を解決したいのか」は、
自社にしか決められません。
自社の判断軸、つまり優先順位を明確に持つことが、
開発会社を本当の「パートナー」に変えていきます。
いきなり全ての機能を盛り込もうとせず、
まずは最小限の機能、MVPから始めて
段階的に育てるのも賢い選択です。
ビジネスの現場が、
よりスムーズに、
より心地よく回るように。
萩原教章は、技術の話を始める前の「業務の棚卸し」を、
これからも全力でサポートしていきます。
#萩原教章 #業務改善 #システム開発 #要件定義 #DX