業務フローの無駄をなくして効率化してる場合じゃない
お悩みを文書としてストックしておくことで懇親会での話のきっかけに使えそうという動機で書いてます。
お悩み
最近、業務を抽象化して共通化して、ムダをなくしていくというアプローチは間違いではないかと思っています。
業務効率化の成功例としてよく語られる例として、
『A部署とB部署似たようなデータを入力していて、このデータを統一すれば入力が一回で済むじゃない！効率化！』
という話。
これ、果たして成功例なのかと、エンジニアさんが腕を振るって共通化、抽象化したそのデータは果たしてA部署、B部署双方に使いやすいデータなのかと疑問に思っています。
もっと抽象的な概念ではなくて具体に寄り添うべきなのではないかと考えるようになりました。
ちょっと、仕事での気付きがあった例を適当にぼかして書いてみる。
Kintoneのレコード単位の権限の例
Kintoneではレコード単位で編集、閲覧などの権限が細かく設定できる。
イメージ的にはRDBのレコード単位に権限が設定できるイメージに近い。
これを見た大半の人はこう思うだろう… これ、必要？ と。
ある人は、そんな細かい権限設定が必要になった時点で設計のミスだとか
またある人は、特定の人間にしかできない業務などあってはいけない、業務を共通化、マニュアル化するべしとか
非常にそれっぽいことを言ったり思ったりする。
でもでも、実際の業務を知るとこの機能が必要とされている理由が分かる。
利用者によっては特別なオンリーワンレコード
このKintoneのアプリが営業職が自分の案件ごとの売り上げを入れるものだとしよう。
技術者からしたらどのレコードも変わらない一案件、ただの一レコードである。
しかし、これを入力している営業職からしたらどうだろう、この一レコードには案件受注の苦悩とか達成感とか思い出が詰まりに詰まっているのです。
またまた、売り上げの計算にお客さんとの秘密の約束があって、通常フローで更新されると困るということもあるかもしれない。
こういうときに自分の大事なレコードに権限制御をかけたいという気持ちが芽生えるのは理解できるような気がします。
(入力するのは営業事務だろとかいうのは今はグッと押さえて！例えだから！)
この場合、技術者はこの具体的な営業職の気持ちを正しく理解しレコードごとの細かい権限制御をいかに手間をかけずに運用するかにフォーカスするべきだと思っています。
営業職の縄張り意識はよくない！データの民主化！フローの共通化！なんて声高に主張するのは、ニーズからはズレている気がしています。
営業部門に問題意識がない、または技術者が根拠をもって良くない理由を説得できなければそれは問題ではないのです。
(少なくとも会社の営みとしては…)
請求書の作成送付の自動化システムの例
取引先への請求データから請求書をPDFで出力して、自動で取引先にメールで送付するシステムがあるとする。
請求データを入力すれば指定の期日に自動で請求書を出力してメールを出してくれる非常に優れた自動化システムだ。
しかしある日、請求書担当の社員がPDFをひとつひとつダウンロードして、手入力で 🙏 心を込めて 🙏 メール文面を打って送信している姿を目撃する。
これを見た大半の人はこう思うだろう… あれ、自動化の仕組みは使わないの？ と。
ある人は、システム化(自動化)したけど使われないパターンね。あるある！と
またある人は、手入力の温かみとか、自動化に適応できない非効率な人間がいるから日本経済は世界に後れを取っているのだとか
非常にそれっぽいことを言ったり思ったりする。
でもでも、実際の業務を知るとこの機能が必要とされている理由が分かる。
一万円と一千万円の請求書は同じ重さではない
実際に話を聞いてみると納得の理由。
請求書担当の社員は各取引先に応じて、手動送付対応と自動送付対応を使い分けていたのである。
額が大きい請求書には、自動送信メールでは対応できない特別な備考やメール文言を追加して送信する。
また、前月金額を誤って請求してしまった取引先には、改めて詫び文言を入れてメールを送信する。
などなど、これも技術者からはどれも同じ請求書に見えるが、担当者からはそれぞれの請求書の向こうに取引先の担当者や金額の大きさを意識していたりする。
この場合は、通常フローとは別の個別対応がしやすいようにPDFを単品でダウンロードできるようにしたり。
基本のメールの文面から場合に応じて編集できるようにする機能を追加する方向でシステムを改修したほうが良いと思っています。
決して業務フローの共通化、マニュアル化ができていないのが問題ではないのです。
具体に寄り添おう
この二つの例から学ぶことは『具体に寄り添おう』ということ。
無数にあるデータから共通点を見つけて抽象化するのは技術者にとっては当然の流れ、または良いことだと思いがちだけれども必ずしもそうではないということ。
その何気ない1レコードに会社の命運を左右するほどの金額が格納されているかもしれないし、
更新には創業より伝わる秘伝のテクニックが必要かもしれない。
秘伝のテクニックが存在すること自体は悪いことではないし、逆にそれが会社の競争力につながっているパターンもあると思う。
(例えば、その人だけが単独で複雑な事例に対してスピーディーに判断を下せることが優位性になることがありそう)
技術者はその一レコードの裏側にある事情とか思いを正しく理解し、より便利な仕組みを提供するのが大事だなと思いました。
技術者主導の自分勝手な効率化、共通化は良くないなという結論でした。
その後のA部署、B部署はどうなったか
冒頭の『A部署とB部署似たようなデータを入力していて、このデータを統一すれば入力が一回で済むじゃない！効率化！』の件、その後のオチとしてどうなったか。
A部署とB部署のデータは統一化され、それぞれ分担して入力するようになりました。
ですが、A部署とB部署のデータは入力の最終的な結果として同じなだけであって、項目が初めて入力されるタイミングや入力を間違っていけない重要な項目がそれぞれ部署ごとに違い、
双方にとって非常に使いにくいデータとなってしまいました。
数か月後そこには共通システムに入力される誰も使わないデータとA部署、B部署で秘密で運用される同じレイアウトのスプレッドシートが爆誕していたとさ。
※ここで挙げた具体例はすべてフィクションです
