ラクを極める自動化:デザインに注意する

ラクを極める自動化:デザインに注意する

今日は「自動化でラクを極める方法」について検討します。

結論は、知覚力。とくに観察力が重要です。観察にもとづいた設計(デザイン)を小さく適用し、徐々に拡張する。リーン・デザインとでもいえましょうか。

自動化のポイント

結論:自動化はよく考えて

最大の過ちの1つは、人間にとってスパーイージーなのに、ロボットにとってスーパーハードなことをオートメーション化したことだった

これは、テスラのイーロン・マスクのコメントだそうです。書籍「知覚力を磨く 絵画を観察するように世界を見る技法 」の235ページに書かれています。

クルマの組み立てを自動化したときの、失敗理由だそうです。

要点だけいうと、ロボットにとって「知覚力」はスーパーハード。人間にとってはスーパーイージー。ここでいう知覚力とは、異常検知です。

人間の異常検知スキルを実装するのは、かなりハード。

つまり、人間の作業をそのまま機械化すると失敗するということです。いいかえると、アナログなワークフローをそのままデジタル化すると、失敗する可能性が高まります。

アナログのデジタル化については、このブログでも取り上げてきたトピックです。

自動化、失敗した

事例:ムダになった自動化

今週、動画で「ツライ自動化」と「ラクな自動化」について、軽く説明しました。

ここでいう「ツライ自動化」とは、トラブルシューティングに追われる自動化を指しています。自分の作業を自動化したはずなのに、メンテナンスに追われてしまう。

自分のアナログ作業をデジタル化したはずなのに、デジタルの面倒をみるだけで、一日が終わってしまう。そんな「あるある」なケースです。いわゆる、ブルシット・ジョブです。

これは、RPAもクラウド自動化も同じです。もっというと、システム開発も同じです。

こんな経験、ないでしょうか?

例えば、RPAで財務・会計の繰り返し作業を自動化したはずなのに、ロボットが止まりまくる。業務全体をまるっと自動化しようと、膨大な時間と多額のコストをかけたのが、実は失敗要因。

例えば、社内システム開発。当社のセールス・プロセスは特殊だから… と開発ベンダーと打ち合わせに打ち合わせを重ね、ゴリゴリのスクラッチ開発プロジェクトへ。障害だらけで結局廃棄。

例えば、たくさんのクラウド・ソリューションを一気に導入し、ほとんどの従業員が使えず、残業理由の大半は、ツールを使ったレポート業務。結局、Google Workspaceだけで事足りる。

そんな経験、あったでしょうか?

ちゃんとデザイン

根拠:デザインと全体俯瞰

これらはすべて、デザインに関係があります。デザインがうまくいっていない。もしくは、まったくデザインされていない。そんな理由です。

ここでいうデザインとは、設計です。つまり、観察から実装、テストまでを含みます。全体を総合して「サービス・デザイン」といい、一部を切り出すと「UI/UXデザイン」となります。

全体の流れを観る人がいて、コンセプト・デザインくらいはしておく。

何かを自動化するにも、アウトソーシング、クラウドソーシングでシステム化するときも、重要なポイントです。応急処置でポイントだけパッチワーク発注することも、問題の原因です。

ランサーズで安くお願いして、クラウドワークスで格安作業してもらい、ココナラで画像だけ用意してもらう。つなげて、使い始めたら… あれれ、なんだか、ぐっちゃぐちゃ。

これは、作業者の責任というより、発注側に原因があります。自身がよくわからないものを「単価」だけで、思いつくままに委託することは、避けたほうが無難です。

自身の脳内イメージをそのまま外部に委託することは、人間の作業イメージをそのままロボットに移植して失敗するのと、本質は同じといえます。

初期段階、超重要

根拠:ロボット導入の課題

さきほどの、ロボットや人工知能による異常検知に戻ります。

人間が視覚ベースで検知している(ように見える)イベントを、ロボットが画像認識だけで実現するのは難しい。よって、聴覚的要素を加え、音のパターンも使う。

こういうソリューションは、すでにたくさんあると思います。これは、どちらかというと技術ファースト、モノづくり側からのアプローチです。

実は、もっと重要なポイントがあります。

ロボットや人工知能が「働きやすい環境をデザイン」してから、本格的な自動化へ。ここをスキップして、コンセプト検証でマネタイズを急ぐようなことをすると、うまくいきません。

筆者なりに、日本のマーケットを観察すると、こう思います。観察、準備、投資といった初期フェーズが、かなり苦手なのではないかと。

データの前処理など、端的なものも含みますが、もっと大きく、全体的なイメージです。こういうところが、クラウド自動化にも出てしまいます。

ロボットをガッツリ買って、フルフルに実装しようとする。というか、ガッツリ買わせてコンサルで長く儲けようとするベンダーやコンサルの商売。

逆に、自分たちで自力で!というベンチャー精神でつくってみるものの、自動化されたフローが大きすぎたり、複雑過ぎたり。手に負えなくなっている例も多くあります。

問題なのは、問題をどう扱うのか。ということになります。よって、デザインと初期フェーズが非常に大切になってきます。

自動化に応用する

応用:クラウド自動化の例

もう一度、リーン・デザインに戻ります。

カッコつけてカタカナ表記しました。もっとカンタンにすると、シンプルに小さく自走していくのはいかがでしょうか。という、ご提案です。

マーケティング自動化(MA)を実現したいのであれば、ホームページのお問い合わせをちょっと自動化する。ソーシャル・メディアの検索を自動化する。顧客データベースを整備してみる。

そんな具合です。

例えば、腹筋割りたいなら、毎朝7分ワークアウトする。しかし、多くの自動化のケースを見ると、ライザップに入会し、プロテインやサプリメントでキッチンを満たす。失敗するか、続かない…。

そんな結末です。

これは、一気にたくさんのことを複雑にやろうとするからです。ですが、全体の流れとしてどうなっているかが見えないため、続かないか、体調を崩すことになってしまいます。

具体的な自動化でいうと、クラウド自動化ツール「Integromat(インテグロマット)」のシナリオ(自動化の単位)の場合…

連携モジュールは、10個以内におさめる。

連携モジュールの最適化も重要(Integromat)

このあたりが、評価ポイントです。

これは、単に自動化初心者だから、ということでは「まったく」ありません。むしろその逆で、そのくらい小さな単位で課題解決できるかどうか。

そこが、デザインのセンスやスキルを問われるといっても過言ではありません。別のいいかたをすると、コンテクスト(文脈)を感じて表現できているか。ということです。

ということは、単発の小さな文脈だけ見えていても、全体(問題解決の領域)が見えていないと、うまくいかない。ということです。

これは、システム開発プロジェクトにおけるマネジメント業務に通じるところがあります。

つまり、ラクを極める自動化とは「デザインがうまくいっているか」どうかなのです!

We Can Help You!

お問い合わせ、ご相談、お待ちしております。