近年の「産業IoT」や「働き方改革」の旗頭の下、業務へのIT導入はもはや必須と言えるでしょう。
IT苦手！
パソコンよくわからん！
なんて言っている時代ではないのです。
新しい技術は活用し、同じ成果を出すための時間を短くしていかなければいけません。
人は、砥石で金属を削っていた作業をグラインダーに替えてきたじゃないですか！（笑）
キリで穴あけしていた作業をボール盤に替えてきたじゃないですか！（笑）
それと同じく、ITを使ってできる作業は、どんどん替えていかなければなりません。
でもちょっと待った！
そんなとき、いきなりソフトウェアを買ってきて業務に取り込もうとすると失敗します。
なぜなら、今の仕事のやり方（ワークフロー）とソフトウェアが想定しているワークフローが異なることがほとんどだからです。
そのせいで、思わぬ高額な買い物をしてしまうケースが後を絶ちません。
つまり、業務にITを導入しようとする場合には、現在のワークフローを改める必要が出てくるわけです。
今回は、そんなワークフローを改める６つのステップについて紹介していきます！
かつての私も（今も？）そうでしたが、この記事はITが苦手な方向けの表現を敢えてしています。エンジニアから見れば違った認識のものもあるかもしれませんが、私が製造業に深く携わっていた経験から、このような伝え方をした方が良いと考えてのことです。その点、ご理解いただければ幸いです。
目次
ワークフローをあらためる６つのステップ
それでは、６つのステップについて一つずつ見ていきましょう。
Step.1 現行業務のワークフローを描く
とにもかくにも、「今」を知らないことには何も始まりません。
まずは、「今の業務の流れ」がどうなっているのかを可視化して共通認識にする必要があります。
ここでポイントが２つほど。
ポイント①：品質保証体系図は参考程度
現場の管理業務に精通している人であれば、目にしたことがあるかもしれない「品質保証体系図」。知っていれば知っているほど、「業務の流れ」と聞いては、この品質保証体系図をイメージしてしまいます。
かくいう私も、一応品質のプロフェッショナルとして理解はできます。
ところが、この品質保証体系図は、あくまで「仕組み」を図にしているだけですので、「業務上の実務」に相当するワークフローとは異なるものであると認識してください。言い換えると、『粒の細かさが違う』ということになります。
あくまでも実務に合わせたフロー図の作成を心がけてください
ポイント②：難しくしない
フロー図の書き方は、正式にはいくつも決まりがあって素人がいきなりきちんと書こうとすると難しいです。ですので、私がいつも最初にお願いするのは、【作業（プロセス）】なのか【判断】なのかだけが分かるように書かれていれば良い、とお伝えしています。
まずは一通り書く！
それが大事です！そのあと、必要に応じてみんなで打合せしたり、専門家に見てもらったりしながら修正すればいいんです。
あまり難しく考えずに、まずは簡単に書いてみましょう！
Step.2 インプット/アウトプットを明確に
ISO9001でも言われていますが、プロセスには必ず「インプット」と「アウトプット」があります。
その作業（プロセス）に必要な情報（インプット）は何か、その作業（プロセス）から出すべき情報（アウトプット）は何か。
きちんと考え定義しましょう。
実は、問題が多い業務を調査すると、この「必要な情報」「出すべき情報」の定義があいまいであることが往々にしてあります。この場を使ってきちんと定義しましょう。
ところで、フロー図の書き方として、「オペレーション志向」と「データ志向」という言葉があります。簡単に言うと、やってる作業に注目してフロー図を書くか、情報の流れに注目してフロー図を書くか、くらいに捉えていただければ良いと思います。一般的には、ソフトウェア開発などではデータ志向を推奨する傾向にあります。なぜなら、作業のやり方自体は経験とともに変わってくるかもしれませんが、情報の流れに関しては大きく変わることが少ないからです。
何の情報を取り扱って、どこにその情報を届ける必要があるのか。
例えば、出荷検査の工程。
「製品」という情報を受け取って、その情報を定量化する【検査】という作業を行い、「検査票」という定量化した情報と「適合／不適合」の判断をして「製品」にレッテルを張る。なので、必要なインプットは、「モノ」出すべきアウトプットは、「レッテルを貼った製品」「検査票」というプロセスになります。
慣れないうちは大変かもしれませんが、難しくはないのです。慣れの問題です。頑張ってみてください！
Step.3 関係者のメリット/デメリットを整理する
意外と抜けがちなのがこのステップです。
これが抜けてしまうとどんなことになるか。
いままでできたことができなくなるの？
そっちのことなのにこっちも何かやらないといけないの？
こっちは手間が増えるだけなんだけど。。。
なんてことが、いざ進めようと思ったときにいろんな部署から声が上がってしまうんです。
そうならないためにも、今、改めようとしているワークフローの範囲はどうなっていて、その関係者は誰なのか。
そして、それらの関係者の作業はどうなってしまうのか。どんなことをお願いしないといけないか。事前に把握し、周知しておく必要があるんです。
直前になって、
ちょっと待て！
なんて言われても困りますもんね（苦笑）
Step.4 担当者をヒヤリングして言語化/図解する
次に、実際に業務を行っている人に、その業務に関するヒヤリングを行っていきます。
あれ？これって最初じゃないの？
そんな風に思った方。その感覚は少し改めてください。
実はこれ以前のステップは、基本的には一人、もしくはプロジェクトメンバーの限られた人で行った方が良い作業です。プロジェクトメンバーと業務の担当者は別です。このステップは、実際にそのワークフローに関わる実務担当者に直接話を聞き、
・この流れで合っているか
・何か現状の業務に対する問題はないか
・実は何か改善案を考えていたりするか
・やっていることに対して、ラクになることできなくなることは想定内か
などをヒヤリングしていきます。
そのヒヤリングした内容を基に、現状のワークフローを修正していきます。
Step.5 現状の問題発見/改善提案/情報の5Sをする
「今の問題は何か」
この点を冷静に考えていきましょう。
業務をIT化するには、プロセスの最適化の考え方は必須です。
この段階での失敗が一番多く、それは、
「今の業務をそのままIT化しようとすること」
なんです。
今の業務をそのままIT化しても、今抱えている問題は解決しません。むしろ、入力の手間も含めて作業はより面倒になることがほとんどです。
そして誰も使わなくなった。。。
お金と時間をかけて導入したシステムなのに、なんて悲しい結末でしょう。
そうならないためにも、現状の問題としっかり向き合ってください。そして、どのようなワークフローであれば問題が解決できるのかを考えるためにも、
「今の問題は要は何なのか」
をきちんと発見することが重要です。
そして、「必要な情報」「不要な情報」「誰にとって何の情報が必要か」などを考えながら、ここでもやはりデータ志向で情報を整理し、どのように現状の問題を解決していくのかの改善提案をしてください。
この段階では箇条書きで結構です。
例えば、
問題：事務作業に時間がかかっていて残業が発生している
改善すべき仕事内容：作業日報の集計に時間がとられている
改善提案①：集計が要らないようにタブレットでデータを入力してもらう
改善提案②：VBAを作成して集計作業を定型化する
改善提案③：作業日報の入力項目を精査して、入力の手間を削減する
のような簡単なことでも結構です。
そのあと、費用や時間、実現の可能性も含めて議論して決めていけば良いのです。
もう一点。
製造業の人は『5S』得意ですよね？目に見えるものの5Sにとどまらず、目に見えない『情報の5S』もしてみてください。仕事をするにあたって必要な情報、あるいは作業環境を取り巻く情報、いろいろな情報が現場には飛び交っています。それらの5Sを実践し、不要な情報は捨て、いつでも引き出せるようにするにはどうしたら良いか考え、取得したデータを使って計算し、不要なデータが増えないように管理する。そんな視点でも考えてみましょう！
Step.6 理想のワークフローを描く
さて、いよいよ仕上げです。
情報の流れ、現状の問題、などを踏まえて、理想のワークフローを描いていきます。
この際も、あくまでデータ志向であることをを心がけてください。そうすることで、現状のワークフローに書かれている「プロセス（作業）」とは区別して考えることができるようになります。
この時点でも「オペレーション（作業）」を中心に考えてしまうと、結局作業のやり方が変えられない悲しい結果になってしまいます。
仕上げの段階まで来てそれはないですよね（苦笑）
どのプロセスは誰が（どの部署が）担当することになるのか、というところまでイメージできると良いでしょう。
そして、プロセスのつながりも含めて、部署最適ではなく全体最適を狙う。そのために仕事のやり方を変えてもらうようお願いする。場合によっては人材配置も見直す。理想のフローの完成とともに、「お願いリスト」「理想のフロー実現のためにクリアするべき課題」なんかも作成しておくのが望ましいです。
これがいわゆる【企画書】の元になるのですから！
さいごに
この記事は、私が多く触れている中小の製造業の方向けに書いています。ですので、ITエンジニアの方から見ると稚拙な記事に思えるかもしれませんが、現実問題として、このようなざっくりとした易しい伝え方をしていくことが、IT導入の一番の近道であると考えています。
私が携わっている主に製造業の現場では、必ずしもITが得意な人ばかりではありません。私もそれほど得意な方ではないと認識していて、つい数年前までは、
「要件定義って何？」
「ワークフローって何？どうやって書くの？」
という状態でした。
ものづくりの技術者として重要と考えてこなかったため、ある意味では仕方ないと思いたいところですが、とうとうそんなことを言っている時代でもなくなったことは事実だと考えています。
一方で、ITエンジニアから見ると、製造業の現場はITかがかなり遅れていて、言葉も通じないし、リテラシーも低いから成果も出にくく、ものすごくギャップを感じる部分もあるかと思います。
そんなエンジニアは、もう少し現場技術のこれまでの蓄積に関する勉強をし、また一方で、製造現場の技術者はITの技術に関する最低限の勉強をするなど、お互いの理解と歩み寄りがIT導入、延いては生産性向上には不可欠なことであると言えます。
そして、
「業務効率が上がって業績が上がった！」
「ソフト導入してもらって売り上げが上がった！」
そんなWin-Winの関係になれると良いですね！
そんな橋渡し役として、私も微力ながら尽力させていただきたいと考えています。
GEMBAコンサルティングの実績事例の一部を、各案件の状況や提案した内容および実施した内容をまとめた資料として無料でダウンロードいただけるようにしました。
