抽象化なんて言葉遊び？ DXに抽象化が必須な理由
デジタルに取り組む際には抽象化が必要と言われます。それは何故なのでしょうか。何を意味するのでしょうか。
営業活動を抽象化してみる
営業を例に抽象化を考えてみましょう。営業とは、商品を顧客に買ってもらう活動です。コンピュータ的に考えるなら、営業 (フィールドセールス) という機能を狭義に見たときには、商品と見込み顧客というインプットを与えられたときに、購入というアウトプットを引き出すものと言えます。
だとすると、e-コマースは営業なのでしょうか。e-コマースは、顧客が自発的にマーケットプレイスに来てくれて、そこで欲しいものの検索を開始する場合には、マーケティング&セールスに相当すると思います。ウェブ広告から飛んできて購入する場合には、ウェブ広告がマーケティングに、e-コマースが営業に相当すると見做せるかもしれません。
ここで重要なことは、機能と実現手段を混同しないことです。例えば営業とは本質的に何なのかの話をしているときに、顧客の心に寄り添う、商品知識を豊富に持つといった方法論の話になってしまうと、同じやり方の伝達・再生産以上のものにならず、他の在り方を想像できなくなってしまうからです。ですから、ここで言う抽象化とは、何を実現したいのか (What)、その実現手段は何なのか (How) というように活動を分解して考えることになります。もちろん分解の方法は他のフレームワークでも構いません。要するに、新しいアイデアを生み出すために、これまで一体不可分だと思われていた要素同士を引き剥がそうと試みる必要があるということです。
抽象化することで、発想を広げたり変化に強くなったりできる
もう少しこのフレームワークで話を続けましょう。
先とは逆の考え方として、HowからWhatを再考する方法もあります。例えば顧客に寄り添いニーズを深く理解するという側面を重視したとき、商品の購入を促す以外にもできることがあるかもしれません。例えば新たな商品の企画をするとか、ファンになってもらうためのブランディングを考えるとか、そういった具合です。
少し話が逸れますが、一般にWhatを固定しHowを検討するとITが人間の仕事を奪うという話になりがちな一方、HowからWhatを考えるとITは人間の可能性を広げるツールに見えてくることがあります。
実際にはこれほど単純な話ではなく、行ったり来たりしながら最適のWhatとHowの組み合わせを模索することになります。その結果として、現状から相当遠く変革が必要なアイデアになることもあれば、現状維持でDXは不要という結論になることもあるでしょう。どんな結論になるにしても、いちど要素分解と抽象化のプロセスを経ていることで、惰性ではない本質的な納得感が増し、将来の情勢の変化に強くなるのは間違いありません。
これまで抽象化が軽んじられていたのは、変化が少なく自社のビジネスが想定内だったから
ではなぜ特にデジタルで、抽象化の議論が要請されるのでしょうか。これまでのビジネスでも同様に議論すべきだったのではないでしょうか。
そのとおりです。
しかしそれは正論であって、実際にはなかなか機会がありませんでした。これまでは、自社の製品がどう役立つのかは想像できていましたし、誰が欲しがっているのかも、そこにどうアプローチすべきかも見えていました。だから敢えて時間をかけて「そもそも論」を議論する必要はなく、現状のプロセスを強化・改善することが重要でした。
しかしデジタルの時代が到来し、可能性が大きく広がりました。自社の製品を、思いもよらない顧客が想定外の用途で活用し、顧客接点は多様化、しかもその情報は瞬く間に世界中を駆け巡る。一方で人々はデータの洪水の中で認知コストが上限に達し、瞬間的に理解できる分かりやすい情報に飛びつくようになった。その中で、情報を提供して購買を促すという営業活動が変わらねばならないのは、よく考えれば自明です。
ではどう変わればいいのでしょうか。その姿を再考するためには、いちど本質に立ち返らない限り、思考の軸となるものが存在せず、目新しいカタカナの並んだ売り文句に惑わされることになります。そうならないように、変化の速い時代に揺るぎないコンセプトを持つためには、抽象思考のプロセスを経ている必要がある、それが本稿の主張です。
もちろん営業以外の業務にも当てはまります。
マーケティング、研究開発、製造、物流、人事、法務、経営戦略など全ての組織は何らかのインプットから何らかのアウトプットを生み出す機能を担っており、その実現手段には何らかの形でデジタルが採用できます。
プログラミングは必然的に抽象化を伴う
以前に、事例を学習することはパターンを抽出することであり、そのパターンが体系化されたものが経営学であると述べました。ですから、本稿を事例と経営学のススメとして書き進めることもできます。しかし今日は別の切り口にしてみましょう。
序盤で「コンピュータ的に考えるなら…インプットを与えられたときに…アウトプットを引き出すものと言える」という表現を使いました。実はプログラマは、後々の改変やメンテナンスなどを考え、処理を簡潔なブロックの組み合わせで書くよう訓練されています。それを実現するためには、将来の機能追加や仕様変更の際に大幅な変更が生じないように、やりたいことを抽象化する必要があります。
先ほどの例でいえば、まず「営業」という活動を、「商品」と「顧客」というインプットを与えられたときに「購入」というアウトプットを引き出すものとして定義した上でプログラムに書き下します。「営業の実現手段」は別のブロックとして定義し、そこに「顧客の心に寄り添う」「商品知識を豊富に持つ」といった内容を書き込みます。そうすることで、将来に「営業の実現手段」が変わっても、全体の処理が破綻せず方法の部分だけ更新すればシステムは問題なく稼働しますし、新しい手法がうまくいかないときには前のやり方に戻すこともできます。これが、本稿でいう抽象化に相当します。
抽象化・モジュール化の利点と欠点
抽象化しモジュール化することの利点は、様々な他のやり方を想像できることです。実現したいこととその方法論や、上流と下流のプロセスが緊密に一体化していると、どこを変えたときに影響がどこに波及するのか予測できず、変えるなら一気に全部変える、ダメなら全部戻すといった、気の遠くなるような作業になってしまいます。しかしモジュール化されていれば、定義された機能 (先の表現ならインプットとアウトプット) に従う限り、簡単に差し替えたり戻したりすることができますので、絶えず最新の手法を使ったり、斬新な取り組みを試したりすることができます。
一方でモジュール化することの欠点は、日本的な長所である擦り合わせの完成度を失うことです。プロセス間が高度に調整されたシステムは、高い生産性を誇ると同時に模倣可能性を下げ、競争優位性を生みます。これを標準化しユニット化することで、確かに柔軟性や拡張性を獲得できるものの、プロセスそのものが競争優位の源泉ではなくなり、目的達成の手段以上のものではなくなってしまうことがあります。言い換えるなら、速度や柔軟性を獲得するために、現在の競争優位を手放す可能性があるということです。
ですから、やみくもに会社のプロセスの全てをモジュール化し管理しやすいようにすればいい、といった暴論を展開するつもりはありません。むしろ、標準化の是非や競争優位性の特定、そして将来の在り方を構想するためにも、いちど抽象化し俯瞰してみることを勧めているのです。
現代の変革に抽象化は必須である
これまで日本企業の多くは、抽象化を言葉遊びや机上の空論として退け、現地現物を重視してきました。しかし、価値を実現するための手段としてデジタルの力が無視できなくなってきた今日では、有形無形を問わず様々な選択肢を包括的に考えるために、もはや抽象思考は避けられません。別の言い方をするなら、工業社会が成熟し情報社会に移行しつつあるこの現代において、目に見えるものだけを考慮に入れるのでは不十分なのです。