システム開発の前にやるべきこと。「業務設計」から始めるDX
「この業務を効率化したいので、システムを導入したい」
DXや業務効率化を考えるとき、最初にシステムの導入や開発を検討する企業は少なくありません。
手作業を自動化したい。
Excelでの管理をやめたい。
入力ミスを減らしたい。
情報を一元管理したい。
こうした課題に対して、システムは非常に有効な手段です。
一方で、システムを導入しただけで業務が改善するとは限りません。
むしろ、今ある業務をそのままシステムへ置き換えることで、
非効率な業務が、そのままデジタル化されてしまう
こともあります。
Triggerでは、システム開発を考えるとき、最初から「どんなシステムをつくるか」を決めることはありません。
まず考えるのは、
そもそも、その業務はどうあるべきなのか。
ということです。
この記事では、システム開発の前に行いたい「業務設計」の考え方と、現場で本当に使われるシステムをつくるために重要なポイントについて解説します。
＜関連記事＞
■ 目次
システムを導入しても、業務が良くなるとは限らない
システム化というと、
紙をデジタルにする。
ExcelをWebシステムにする。
人が行っていた作業を自動化する。
といったことを想像しやすいかもしれません。
しかし、業務そのものに無駄が多い状態でシステム化すると、システムも複雑になっていきます。
入力項目が増える。
画面遷移が増える。
例外処理が増える。
操作方法を覚えなければならない。
結果として、
業務を楽にするためにつくったはずのシステムが、使う人を疲れさせる。
ということが起こります。
そしてシステムが複雑になればなるほど、操作ミスも増えます。
最終的には、
「結局、以前のExcelの方が早い」
「現場では誰も使っていない」
という状態になってしまうこともあります。
だからこそ、システムをつくる前に、まず業務そのものを見直す必要があります。
「人が動かす業務」と「システムが動かす業務」は設計が違う
ここで重要なのが、
人為的に動かすことを前提とした業務と、システムが動くことを前提とした業務は同じではない
ということです。
例えば、人が作業する場合には、
「このケースなら、この人に確認する」
「この条件なら、こっちの処理をする」
「前回と同じだから、この方法で進める」
といった暗黙の判断が数多く存在します。
人は前後の文脈や経験から判断できます。
しかしシステムは、曖昧なままでは動けません。
どの条件なら、どの処理をするのか。
例外が発生したら、どうするのか。
何を入力必須にするのか。
どこで処理を止めるのか。
誰へ通知するのか。
こうしたことを一つずつ明確にする必要があります。
その過程で、
「そもそも、この確認は必要なのか」
「この入力は前工程のデータを使えないか」
「この承認フロー自体をなくせないか」
ということも見えてきます。
つまり、システム開発とは、
今の業務をそのままプログラムへ置き換えることではありません。
システムが動くことを前提に、業務そのものを再設計することが重要です。
業務フローだけでなく、その前後の「文脈」まで見る
Triggerがシステム開発の相談を受けたとき、特に重視しているのが業務フローです。
ただし、
「Aを入力したらBをする」
という一つの業務だけを見るわけではありません。
その前に何が起きているのか。
その後、その情報は何に使われるのか。
なぜその作業が必要なのか。
どの部署が関係しているのか。
場合によっては、事業全体や会社全体まで理解することを大切にしています。
一つの業務だけを最適化しても、その前後とのつながりが悪くなれば、会社全体では非効率になることがあるからです。
例えば、一つの部署では入力作業が減ったとしても、その結果、次の部署で加工や確認の作業が増えてしまえば、本当の意味で効率化されたとは言えません。
システムは、業務単体ではなく、
その仕事が会社全体の中でどんな役割を持っているのか
まで考えて設計する必要があります。
「鳥の目・虫の目・人の目」で業務を見る
業務設計をするとき、Triggerでは複数の視点を行き来することを大切にしています。
鳥の目｜業務全体を見る
まずは、業務全体の流れを俯瞰します。
何を起点に仕事が始まり、どの部署や担当者を経由し、最終的に何が完成するのか。
前後工程まで含めて見ることで、一部分だけを最適化することを防ぎます。
虫の目｜細かな動きを見る
次に、実際の作業を細かく見ます。
どの画面を開くのか。
何をクリックするのか。
どこから情報を探すのか。
何を転記するのか。
どこで確認するのか。
こうした一つひとつの動作まで見ていくと、現場に潜んでいる小さな負担が見えてきます。
人の目｜実際に使う人を見る
そして、もう一つ欠かせないのが、実際にそのシステムを使う人の視点です。
普段どんな仕事をしているのか。
どんな環境で働いているのか。
PCを使うことに慣れているのか。
スマートフォンを開くタイミングはいつなのか。
忙しい現場の途中で操作するのか。
落ち着いたデスク環境で使うのか。
同じ機能でも、利用する人や状況が違えば、最適なシステムの形も変わります。
「システムは導入したが、現場で使われない」を防ぐ
システム開発で難しいのは、システムそのものを完成させることだけではありません。
むしろ、
導入して、実際の業務へ浸透させることの方が難しい
と感じることもあります。
例えば、日常的にPCやスマートフォンを使う機会が少ない職種の場合、良いシステムを用意しただけでは利用が定着しないことがあります。
そもそも、
「いつシステムを開くのか」
という習慣自体が存在しないからです。
この場合は、
どの業務のタイミングで開くのか。
誰が利用を促すのか。
利用しなかった場合どうするのか。
既存業務の中へどう組み込むのか。
まで考える必要があります。
Triggerがシステム提供を行う際には、
システムは開発すること自体も大変ですが、導入して浸透させることはさらに大変です。
ということを、意思決定者へ事前にお伝えするようにしています。
開発が完了した日がゴールではありません。
現場の業務として自然に使われる状態になって、初めてシステムは価値を持ちます。
人がやるべき仕事を先に決める
業務設計をするとき、
「何を自動化できるか」
だけから考えることもおすすめしません。
先に考えたいのは、
人がやることで価値が生まれる仕事は何か。
ということです。
例えば、
顧客との対話。
複雑な判断。
企画や提案。
関係構築。
創造性が必要な仕事。
こうしたものは、人が担う価値が大きい領域です。
一方で、
情報の転記。
定型的な計算。
条件に応じた処理。
リマインド。
必要な情報の表示。
などは、システムへ任せられる可能性があります。
システム化の目的は、人をできるだけ排除することではありません。
人が本来価値を発揮すべき仕事へ、エネルギーを戻すこと。
そのために、システムを使うという考え方が重要です。
＜関連記事＞
良いシステムは、人に判断させすぎない
システム化する最大のメリットの一つは、
その業務に使っていた人間のエネルギーを節約できること
だとTriggerでは考えています。
そのため、
システムを動かすために、大量の確認が必要。
毎回マニュアルを読まなければならない。
常に人が判断しなければならない。
入力ミスがないか何度も確認する。
という状態では、システム化の効果が十分に発揮されているとは言えません。
良いシステムでは、
必要なタイミングで、必要なものが表示される。
ことが重要です。
さらに、
できるだけ直感的に操作できる。
迷ったときには、すぐ解決できるヘルプがある。
間違った入力では次へ進めない。
必要な確認を飛ばせない。
といった、
正しく使うための「制約」
も必要です。
自由度が高いことが、必ずしも使いやすさにつながるわけではありません。
むしろ業務システムでは、
「間違えようとしても間違えにくい」
状態をつくることが重要です。
「動くシステム」と「任せられるシステム」は違う
例えば、報酬を計算するシステムを考えてみます。
数字を入力すると報酬額が計算される。
それだけであれば、システムとしては動いています。
しかし、実際の業務を任せるためには、それだけでは足りません。
入力値が異常ではないか。
必要なデータが揃っているか。
例外条件は処理されているか。
エラーが起きたら誰に通知するか。
間違った計算結果がそのまま次工程へ進まないか。
必要に応じて人が確認できるか。
こうしたところまで設計されて、初めて
「このシステムに業務を任せられる」
状態になります。
Triggerでは、機能が実装されていること以上に、
人間が過剰に気を配らなくても、安心して業務が進むか
を重要視しています。
システムは、人間の注意力を増やすためではなく、できるだけ節約するために使うものだからです。
システム要件は、業務設計の結果として決まる
システムの要件定義を考える前に、まずは業務の設計自体を見直すことが重要です。
そもそもその業務の目的は何か？という前提部分から、全体の流れや、人がやるべき仕事・逆にシステムに任せたい仕事を考えていく。
さらに、どんな人がどんな状況下で利用するのか？システムに求めるべき制約や例外処理は？
ここまで整理していって初めて、
どんな画面が必要なのか。
何を入力するのか。
どこまで自動化するのか。
誰にどんな権限を与えるのか。
どんな通知が必要なのか。
他のシステムと連携するのか。
といったシステム要件が見えてきます。
つまり、
システムの要件を先に決めるのではなく、業務を設計した結果としてシステムの形が決まる。
という順番です。
「システムをつくらない」という選択肢も持つ
そして、業務設計をした結果、
「そもそも新しいシステムをつくらなくてもいい」
という結論になることもあります。
むしろTriggerでは、最初から大掛かりなシステムを導入することを前提にしません。
まず、
今あるツールで対応できないか。
業務フローを変えれば解決しないか。
既存の機能を組み合わせられないか。
その業務自体をなくせないか。
を考えます。
そのうえで、それでもシステムが必要なのであれば、
必要な機能だけを備えたシステムをつくる。
という順番です。
システム開発は目的ではありません。
事業や業務をより良くするための手段の一つです。
だからこそ、
「つくれるから、つくる」のではなく、「必要だから、つくる」。
という判断が重要だと考えています。
まとめ｜DXは「システムを入れること」から始めない
DXや業務効率化を進めるとき、新しいツールやシステムを導入することから考えたくなるかもしれません。
しかし、その前に一度、
今の業務は本当にこの形である必要があるのか。
人がやるべき仕事はどこなのか。
システムへ任せるべき仕事は何なのか。
実際に使う人は、どんな環境で仕事をしているのか。
まで考えてみることが重要です。
複雑な業務をそのままシステム化すれば、複雑なシステムができます。
逆に、業務そのものを整理し、必要な仕事と人の役割を明確にできれば、システムもシンプルにできます。
システムは、良い業務設計を実現するための手段です。
だからこそTriggerでは、
システム開発の前に、まず業務を設計する。
そして必要であれば、最適なシステムをつくる。
という順番を大切にしています。
%E3%83%AD%E3%82%B4_%E3%82%A2%E3%82%A4%E3%82%B3%E3%83%B3%E7%94%A8.png)
