業務の効率化や品質向上の一つの手段として、手動で行っている業務の自動化がありますが、自動化を進めていくステップをあらためて考えてみたので、その内容を共有したいと思います。
- ライター：片野 祐
- ネットワンシステムズに新卒入社し、PF, NW, SW, AIといった様々な製品、技術の担当として技術検証、提案導入支援、データ分析等を行ってきた。その後、よりお客様に近い立場でSW開発支援や自動化技術を中心とした案件推進活動を実施。現在は自動化技術を中心に扱うチームで製品担当やソリューション開発に従事。
目次
はじめに
以前の記事（ 流行りの「自動化」に取り掛かる前に行うべきこととは？）では、最近よく耳にする「自動化」をする前段階に注目して、普段考えていることを書き起こしてみました。
今回はその中でも業務フローの作成やその進め方について、より掘り下げてお伝えします。また、「自動化は手段であり、目的ではない」ことは非常に重要な観点であるため、こちらであらためて記載しておきます。
いくつかの段階や粒度でフローを把握する
様々な自動化業務に関わってきた経験から、フローは大きく二段階で見るのが良いと考えています。それが業務フローと作業フローです。
- 業務フロー： 複数の関係者が関わり、課題を解決したり目的を達成したいと考えている物事の全体像
- 作業フロー： 業務フローを構成する、実際のタスク
どちらも明確に、どの粒度で書く、という指標はありませんが、私は業務フローで人と物事の流れを追えるようにして、作業フローで閉じた部門で完結する一つのタスクを見るようにしています。
自動化によってより高い効果を得るためには、業務の中で自動化の適用範囲が広ければ広い方が良いですが、その分タスクが増えるためスピード感が失われるという面もあります。逆に、作業フローだけに注目すると自動化の効果が限定的になったり、ツールの選定によってはさらにサイロ化が進んでしまうことで自動化が継続、発展しないという面もあります。そのため、いくつかの段階や粒度でフローを作成し、視点、視座を行ったり来たりしながら実装、適用していくのが良いと考えています。（余談ですが、「視座は高いだけではなく、上下にコントロールできるといい」と、人財育成面で学んだことが、エンジニア業務にもつながった感じがしました）
作業フローを詳細化する（SIPOC分析のご紹介）
それでは次に作業フローに注目します。作業フローを詳細化、明確化していくことが、実際の自動化実装を楽にすることになります。また、同時にエンジニアではない方々に実装の難易度や具体的に何を行っているのかを示す道具にもなると考えています。そこで作業フローを詳細化するために、SIPOC分析という手法をよく使っています。
- SIPOC分析： プロジェクトの全体像を把握し、プロセスを分析するためのフレームワーク
SIPOCは以下に示すそれぞれの頭文字を取っており、これらを軸に作業フローを可視化、詳細化します。
| Supplier(供給者) | プロセスにインプットを入力する人や組織 |
| Input(入力) | プロセスに入ってくる物や情報 |
| Process(処理) | 価値を生み出す活動の流れ |
| Output(出力、成果物) | プロセスから出ていくものや情報 |
| Customer(顧客) | プロセスからアウトプットを受け取る人や組織 |
また、作業フローを可視化、詳細化していくにあたり、その順番によってCOPISやPOCISと呼ばれることもあり、得られやすいメリットが異なってきます。
| SIPOC | 顧客に提供するアウトプットを主体とした手順、業務プロセス順に考えるので作りやすい |
| COPIS | 顧客を主体とした手順で、ニーズから考えることで成果を最大化させやすい |
| POCIS |
プロセスを主体とした手順で、既にあるプロセスを改善しやすい |
私たちはこのSIPOC分析をするにあたり、追加で情報を付与していきます。時には手動で機器に投入するコマンドレベルで記載することもあります。これはAnsibleやTerraformといったローコードのツールを使う際に、作業の共通認識を持ち認識の齟齬を減らすほか、最終手段としてコマンドの投入さえできれば（効果が最大化できなくても）自動化の効果は得られるという心の余裕を生むことにもつながります。また、複数の機器が連携する場合は送信元（From）と送信先（To）や、使うツールが限定されている場合はそのツールで実現可能かどうか、モジュールやプラグインがあれば何を使うかまで整理することもあります。
もちろんこれはゼロから作るのではなく、既存の作業手順書をインプットにして作ります。そのため、事前に既存の作業内容を整理しておくことも重要です。自動化のためのSIPOC分析を行う際は、自動化用に手順の再編成も同時に行っています。
動くものを共有しながら完成に向かう
ここまで作業を明確化しておけば、あとは自動化に向けて実装するだけになります。その際、一気に最後まで作るのではなく、動くものを細かく作っていき、関係者に見てもらいながら作り切ることが重要だと考えています。
ウォーターフォールか、アジャイルか、の考え方に近いと思いますが、やはり机上で検討するよりも、動いているものを見た方がイメージが湧き新たな発想が生まれてきます。（生まれてきた新たな発想を、いつ採用するかはQCD等の指標との兼ね合いだと思います。）
実際に少しでも動くものができていると、微修正もしやすく、作り手の心理的負担も減ります。そのため、エンジニアだけで作り上げるのではなく、ビジネス側の方々を含めてできるだけ多くの関係者で作り上げる意識も必要になると感じました。
まとめ
今回は以前の記事から少しだけ技術視点に寄せて書いてみました。これらの分析をどの粒度で行うかはリリースまでのスピード感や成果物の品質によって異なると思いますが、関係者で共通認識を持って進めるには必要な要素であると考えています。また、昨今の生成AIの発展によって、より効果が出る進め方があると思うので、様々な方法を試しながら課題解決、目的達成のために活動していきたいと思います。この記事が何かの参考になると幸いです。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
