かつて、経営者がまず身につけるべきコンピュータスキルは「ワープロ」でした。
これは単に、文章をきれいに作成できるからではありません。
会社を経営するという行為のかなりの部分が、文書によって行われていたからです。
人事異動を伝える。
就業規則を定める。
業務上の指示を出す。
取引条件を決める。
社内へ方針を伝える。
契約を締結する。
経営者が決めたことは、最終的には「書面」になります。
この構造そのものは、コンピュータが登場するはるか以前から大きく変わっていません。
江戸時代であれば、和紙に筆で書き、必要に応じて印を押して書面を作る。
近代になれば、それがタイプライターや印刷物になり、やがてワープロ文書になった。
現在ではWord文書やPDFになっています。
媒体は変わりました。
しかし、
「権限を持つ人がルールを決め、それを文書として残し、人に伝える」
という基本構造は長い間ほとんど変わっていません。
ところが、会社のルールは「文書」だけでは決まらなくなった
ここに、現在のDXを考えるうえで非常に大きな変化があります。
現在の企業では、
「誰が何をできるのか」
というルールのかなりの部分が、文書ではなくコンピュータシステムによって決まり始めています。
例えば経営者が就業規則や業務規程に、
「営業部長は所定の範囲で値引きを承認できる」
と書いたとします。
紙の世界であれば、その文章を読んだ人間がルールを理解し、運用します。
しかし業務システムでは、それだけでは足りません。
システム上では、さらに細かく決める必要があります。
営業部長とは、どのユーザーなのか。
何円まで承認できるのか。
自分の部署だけなのか。
他の営業所の案件も見られるのか。
承認後に変更できるのか。
代理承認は認めるのか。
退職・異動した場合はいつ権限を失うのか。
どの記録を残すのか。
つまり、文書に書かれた一行の規則を、コンピュータ上では大量の具体的な条件へ変換しなければなりません。
文書を作る権限と、システムを作る権限が分離している
ここで大きな問題が起こります。
経営者には、規則を書く権限があります。
しかし、その規則をコンピュータシステムへ反映する能力を持っていない場合、その実装を外部のシステム会社やIT担当者へ依頼することになります。
すると、
経営者
↓
規則を文章で決める
↓
システム会社へ説明する
↓
システム会社が解釈する
↓
データ構造・権限・処理へ変換する
↓
実際の業務ルールになる
という構造が生まれます。
ここで注意すべきなのは、経営者が決めた「文章」と、実際に会社を動かす「システム上のルール」が必ずしも同じではないことです。
経営者は、
「部長には必要な情報を見せる」
と考えているかもしれません。
しかしシステムを作る側は、
「必要な情報とは具体的に何か」
を決めなければ実装できません。
顧客情報は全部見せるのか。
原価は見せるのか。
他部署の売上は見せるのか。
個人情報はどうするのか。
CSVで持ち出せるのか。
過去の情報まで閲覧できるのか。
ここまで来ると、単なるプログラミングの問題ではありません。
会社の権限構造そのものを設計しています。
外部依存が進むと、経営者は規則を自由に変えられなくなる
さらに問題なのが、システムが巨大化した後です。
経営者が、
「来月から承認制度を変えよう」
と考えたとします。
本来、これは経営判断です。
ところがシステム会社から、
「現在のシステムでは対応が難しいです」
「他の機能にも影響します」
「改修には半年必要です」
「次回のシステム更改まで待った方がよいです」
と言われる。
すると、経営者は本来必要だと思っている制度変更を、システムの都合によって諦めることになります。
これはかなり重大な逆転です。
本来は、
経営
↓
業務
↓
システム
であるべきです。
ところが、
システム
↓
変更可能な業務
↓
経営判断
となってしまう。
つまり、経営者が規則を作っているつもりでも、実際には「現在のシステムで実現可能な範囲から規則を選んでいる」状態になります。
これでは、経営の自由度そのものがシステムに制約されます。
昔の経営者にワープロが必要だったなら、今の経営者には何が必要なのか
ここで、最初の話に戻ります。
ワープロが普及した時代、経営者がワープロを使えることには意味がありました。
自分で文章を書き、自分で修正し、自分で意思を伝えられるからです。
誰かに清書を依頼しなければ規則を変更できない状態から、経営者自身が文書を扱える状態へ変わりました。
では、現在はどうでしょうか。
会社の規則そのものがコンピュータシステムへ埋め込まれ始めています。
そうであるならば、経営者に必要なコンピュータリテラシーも変わらなければなりません。
必ずしもプログラミング言語を習得する必要はありません。
経営者自身がPythonやJavaを書ける必要もないでしょう。
しかし、少なくとも、
データとは何か。
会社にはどのようなデータが存在するのか。
データ同士はどのようにつながっているのか。
誰がそのデータを見ることができるのか。
誰が変更できるのか。
誰が承認するのか。
業務と業務はどのように依存しているのか。
システム変更によって、どこへ影響が及ぶのか。
この程度の「システム構造を読む力」は、経営側に必要になってきています。
プログラミング教育より先に、システム設計を学ぶ意味
これは、いわゆるプログラミング教育とは少し違います。
プログラムを書くことが目的ではありません。
会社という組織を、
人
権限
業務
データ
処理
という関係として捉える能力です。
例えば、
会社
↓
部署
↓
業務
↓
担当者
↓
扱えるデータ
↓
実行できる処理
という構造を理解する。
これが分かれば、システム開発会社へ依頼する場合でも、
「この画面を作ってください」
ではなく、
「この部署のこの役職には、この範囲のデータだけを扱わせたい」
という指示ができるようになります。
この違いは非常に大きい。
前者は画面の発注です。
後者は経営構造の設計です。
生成AIによって、問題はさらに大きくなる
生成AIによってプログラムを書くコストは急速に下がっています。
以前なら、
「難しいから作れない」
という技術的な壁がありました。
現在は、
「AIに頼めば、とりあえず動くものは作れる」
という時代になっています。
これは非常に便利です。
しかし同時に、新しい危険も生まれます。
構造を理解していないまま、
「この機能を追加して」
「次はこの例外にも対応して」
「この人だけ特別に見られるようにして」
とAIに依頼し続ければ、動くシステムはどんどん膨張します。
しかし数年後、
「この会社では、なぜこの人がこのデータを見ることができるのか」
という質問に、誰も答えられないシステムが出来上がるかもしれません。
コードを書けるかどうか以上に、
「何を作っているのかを説明できるか」
が重要になります。
ワープロの次に必要なのは「会社をシステムとして読む力」
江戸時代、経営や行政の意思は紙に書かれました。
近代には印刷物になりました。
コンピュータ時代にはワープロ文書やPDFになりました。
そして現在、会社のルールそのものが、データベース、権限設定、業務システムの中へ移り始めています。
だからこそ、経営者に求められるコンピュータスキルも変わります。
かつては、
「自分で文書を作れること」
が重要でした。
これからは、
「自分の会社がコンピュータ上でどのような構造になっているのかを理解できること」
が重要になります。
システム会社にコードを書いてもらうことは問題ではありません。
専門家に実装を任せることも当然です。
しかし、
「誰が何を見られるのか」
「誰が何を決められるのか」
「どの業務からどのデータが生まれるのか」
「会社の規則がシステム上でどのように表現されるのか」
まで外部に任せてしまえば、経営者は徐々に規則を自由に作れなくなります。
コンピュータを使って経営する以上、システム設計は単なるIT部門の仕事ではありません。
それは、
会社のルールを、コンピュータ上でどう表現するかを決める経営そのもの
になり始めています。
ワープロを使えることが経営者の基本スキルだった時代の次には、
システムの構造を理解し、自社のデータ・業務・権限を自分たちで設計できること
が、経営者の基本的なコンピュータリテラシーになるのかもしれません。