DXは抽象化が9割
/ 11 min read
Table of Contents
バラバラに見える業務から共通点を見つけられるかどうかがシステムの成否を分ける。そして抽象化と具体化の往復こそが、思考そのものだという話。
前回の記事(DXとは人とシステムの境目をデザインすること)で、「人とシステムの接点を減らす」という話を書きました。今回は、それを実践するために避けて通れない「抽象化」の話です。
タイトルは、書店でよく見かける自己啓発本風にしてみました(笑)。少し大げさに聞こえるかもしれませんが、システム開発や業務改善において、この抽象化こそが成否を分ける鍵だと思っています。
抽象化とは?
まず言葉の整理から。抽象化とは、一言でいえば「複数の物事から共通する性質を抜き出して、まとめて扱えるようにすること」です。
たとえば「りんご」「バナナ」「みかん」という個別のものがある。これらをまとめて「果物」と呼ぶこと、これが抽象化です。色や形や味といった個別の特徴を一旦脇に置いて、「植物の実であり、食用になる」という共通点にだけ注目することで、ひとつのグループとして扱えるようになる。
対になるのが「具体化」です。こちらは逆で、抽象的な概念に詳細な情報を加えて、個別の事象としてはっきりさせること。「果物」というグループに「赤くて丸い」「甘酸っぱい」「青森県産」といった情報を足していって、「特定のりんご」として認識する。これが具体化。
私たちの日常業務は、基本的にこの「具体化」された世界で起きています。「A社の田中様から注文が来た」「B商品の在庫が足りない」といった、個別の事象の連続ですよね。
システムはルールでしか動けない
では、なぜシステムの話で抽象化が重要になるのか。
それは、システムがルール(共通点)でしか動けないからです。
人間なら「A社さんはお得意様だから、ちょっと締切を過ぎても受け付けよう」といった融通が利きます。文脈を読んで、その場で判断できる。でもコンピュータは融通が利かず、「もし〇〇ならば、△△する」というプログラムされた手順でしか動けません。
もし業務を具体化された状態のまま、つまり「今のやり方」をそのままシステムにしようとすると、どうなるか。
よくあるのが、「A事業部の販売システム」と「B事業部の販売システム」が別々に乱立するケースです。やっていることは、どちらも「注文を受けて商品を出荷する」という同じ業務。それなのに、「A事業部は特殊な商習慣があるから」「B事業部とは伝票の書き方が違うから」といった具体的な差異にばかり目が向いて、結果として似て非なるシステムをいくつも作ってしまう。
これでは開発費も保守費も2倍かかりますし、全社の売上データを統合するのも一苦労です。
ここで抽象化の出番。「A事業部もB事業部も、本質的にやっているのは『販売』である」と捉え直す。そうすれば、共通の販売管理の土台を作って、事業部ごとの細かな違い(入力項目の有無や承認の流れの長さなど)だけを設定として切り出すことができます。
一見バラバラに見える業務の共通項を見つけ出して、システムという共通のレールに乗せる。これが「人とシステムの接点を減らす」ということでもあるわけです。
でも、これがものすごく難しい
ここまで読むと「当たり前のことじゃないか」と思われるかもしれません。でも、実際の現場でこれをやるのは非常に難しい。理由が2つあります。
ひとつ目は、現場の課題が常に「具体的」だからです。
お客様や現場のスタッフからは、「このボタンを大きくしてほしい」「ここの入力項目を減らしてほしい」といった具体的な要望が上がってきます。これをそのまま鵜呑みにして対応してしまうと、その場しのぎの改修が積み重なって、システムは複雑怪奇なものになっていく。
「なぜボタンを大きくしたいのか」「なぜ入力を減らしたいのか」という背景を探って、本質的に解決したい課題は何かを突き止める。この作業には、けっこうな思考力が要ります。
そしてもうひとつ。抽象化された仕組みを、現場の人に理解してもらうことです。
作る側が苦労して業務を抽象化し、汎用的な土台を作り上げたとしても、現場の担当者からすれば「今までと画面が違う」「A社の案件を入れるときの手順が変わってわかりにくい」という話になる。現場の人は日々「具体的な」業務に向き合っているので、「全体最適のために抽象化しました」という理屈よりも、「今の自分の仕事がやりやすいか」のほうが重要なんですよね。これは当然のことだと思います。
システムの中身は抽象化してスマートにしつつ、画面や説明はいかに現場の具体的な感覚に寄り添えるか。あるいは、なぜ業務の流れを変える必要があるのかを粘り強く説明して、納得してもらえるか。
この翻訳作業とも言えるプロセスが、いちばん苦労するところだったりします。
思考とは、行ったり来たりすること
ここまでシステムの話をしてきましたが、実はこの「抽象化」と「具体化」を行き来することこそが、人間の「思考」そのものだとも言えます。
目の前の具体的な事象を見て「つまりどういうことか?」と法則を見つける。これが抽象化。見つけた法則を別の場面に当てはめて「このケースではどうなるか?」と考える。これが具体化。
この往復運動ができる人が、いわゆる「地頭が良い」とか「応用が利く」と言われる人なんじゃないでしょうか。
この能力は一朝一夕で身につくものではなくて、できれば子どものころからトレーニングしておきたいもの。「なんで空は青いの?」「なんで勉強しなきゃいけないの?」といった子どもの素朴な「なぜ」は、まさに抽象化への第一歩です。大人がすぐに具体的な答えを与えるのではなく、一緒に考えて抽象度を上げていく対話が大切なのかもしれません。
もっと詳しく知りたい方には、こちらの本が非常におすすめです。
https://str.toyokeizai.net/books/9784492047361/
抽象化と具体化を行き来する。これはシステムの話に限らず、考えるということそのものなのではないかなと思っています。