カテゴリー: システム開発内製化

かつて、経営者がまず身につけるべきコンピュータスキルは「ワープロ」でした。

これは単に、文章をきれいに作成できるからではありません。

会社を経営するという行為のかなりの部分が、文書によって行われていたからです。

人事異動を伝える。
就業規則を定める。
業務上の指示を出す。
取引条件を決める。
社内へ方針を伝える。
契約を締結する。

経営者が決めたことは、最終的には「書面」になります。

この構造そのものは、コンピュータが登場するはるか以前から大きく変わっていません。

江戸時代であれば、和紙に筆で書き、必要に応じて印を押して書面を作る。

近代になれば、それがタイプライターや印刷物になり、やがてワープロ文書になった。

現在ではWord文書やPDFになっています。

媒体は変わりました。

しかし、

「権限を持つ人がルールを決め、それを文書として残し、人に伝える」

という基本構造は長い間ほとんど変わっていません。

ところが、会社のルールは「文書」だけでは決まらなくなった

ここに、現在のDXを考えるうえで非常に大きな変化があります。

現在の企業では、

「誰が何をできるのか」

というルールのかなりの部分が、文書ではなくコンピュータシステムによって決まり始めています。

例えば経営者が就業規則や業務規程に、

「営業部長は所定の範囲で値引きを承認できる」

と書いたとします。

紙の世界であれば、その文章を読んだ人間がルールを理解し、運用します。

しかし業務システムでは、それだけでは足りません。

システム上では、さらに細かく決める必要があります。

営業部長とは、どのユーザーなのか。

何円まで承認できるのか。

自分の部署だけなのか。

他の営業所の案件も見られるのか。

承認後に変更できるのか。

代理承認は認めるのか。

退職・異動した場合はいつ権限を失うのか。

どの記録を残すのか。

つまり、文書に書かれた一行の規則を、コンピュータ上では大量の具体的な条件へ変換しなければなりません。

文書を作る権限と、システムを作る権限が分離している

ここで大きな問題が起こります。

経営者には、規則を書く権限があります。

しかし、その規則をコンピュータシステムへ反映する能力を持っていない場合、その実装を外部のシステム会社やIT担当者へ依頼することになります。

すると、

経営者
↓
規則を文章で決める
↓
システム会社へ説明する
↓
システム会社が解釈する
↓
データ構造・権限・処理へ変換する
↓
実際の業務ルールになる

という構造が生まれます。

ここで注意すべきなのは、経営者が決めた「文章」と、実際に会社を動かす「システム上のルール」が必ずしも同じではないことです。

経営者は、

「部長には必要な情報を見せる」

と考えているかもしれません。

しかしシステムを作る側は、

「必要な情報とは具体的に何か」

を決めなければ実装できません。

顧客情報は全部見せるのか。

原価は見せるのか。

他部署の売上は見せるのか。

個人情報はどうするのか。

CSVで持ち出せるのか。

過去の情報まで閲覧できるのか。

ここまで来ると、単なるプログラミングの問題ではありません。

会社の権限構造そのものを設計しています。

外部依存が進むと、経営者は規則を自由に変えられなくなる

さらに問題なのが、システムが巨大化した後です。

経営者が、

「来月から承認制度を変えよう」

と考えたとします。

本来、これは経営判断です。

ところがシステム会社から、

「現在のシステムでは対応が難しいです」

「他の機能にも影響します」

「改修には半年必要です」

「次回のシステム更改まで待った方がよいです」

と言われる。

すると、経営者は本来必要だと思っている制度変更を、システムの都合によって諦めることになります。

これはかなり重大な逆転です。

本来は、

経営
↓
業務
↓
システム

であるべきです。

ところが、

システム
↓
変更可能な業務
↓
経営判断

となってしまう。

つまり、経営者が規則を作っているつもりでも、実際には「現在のシステムで実現可能な範囲から規則を選んでいる」状態になります。

これでは、経営の自由度そのものがシステムに制約されます。

昔の経営者にワープロが必要だったなら、今の経営者には何が必要なのか

ここで、最初の話に戻ります。

ワープロが普及した時代、経営者がワープロを使えることには意味がありました。

自分で文章を書き、自分で修正し、自分で意思を伝えられるからです。

誰かに清書を依頼しなければ規則を変更できない状態から、経営者自身が文書を扱える状態へ変わりました。

では、現在はどうでしょうか。

会社の規則そのものがコンピュータシステムへ埋め込まれ始めています。

そうであるならば、経営者に必要なコンピュータリテラシーも変わらなければなりません。

必ずしもプログラミング言語を習得する必要はありません。

経営者自身がPythonやJavaを書ける必要もないでしょう。

しかし、少なくとも、

データとは何か。

会社にはどのようなデータが存在するのか。

データ同士はどのようにつながっているのか。

誰がそのデータを見ることができるのか。

誰が変更できるのか。

誰が承認するのか。

業務と業務はどのように依存しているのか。

システム変更によって、どこへ影響が及ぶのか。

この程度の「システム構造を読む力」は、経営側に必要になってきています。

プログラミング教育より先に、システム設計を学ぶ意味

これは、いわゆるプログラミング教育とは少し違います。

プログラムを書くことが目的ではありません。

会社という組織を、

人
権限
業務
データ
処理

という関係として捉える能力です。

例えば、

会社
↓
部署
↓
業務
↓
担当者
↓
扱えるデータ
↓
実行できる処理

という構造を理解する。

これが分かれば、システム開発会社へ依頼する場合でも、

「この画面を作ってください」

ではなく、

「この部署のこの役職には、この範囲のデータだけを扱わせたい」

という指示ができるようになります。

この違いは非常に大きい。

前者は画面の発注です。

後者は経営構造の設計です。

生成AIによって、問題はさらに大きくなる

生成AIによってプログラムを書くコストは急速に下がっています。

以前なら、

「難しいから作れない」

という技術的な壁がありました。

現在は、

「AIに頼めば、とりあえず動くものは作れる」

という時代になっています。

これは非常に便利です。

しかし同時に、新しい危険も生まれます。

構造を理解していないまま、

「この機能を追加して」

「次はこの例外にも対応して」

「この人だけ特別に見られるようにして」

とAIに依頼し続ければ、動くシステムはどんどん膨張します。

しかし数年後、

「この会社では、なぜこの人がこのデータを見ることができるのか」

という質問に、誰も答えられないシステムが出来上がるかもしれません。

コードを書けるかどうか以上に、

「何を作っているのかを説明できるか」

が重要になります。

ワープロの次に必要なのは「会社をシステムとして読む力」

江戸時代、経営や行政の意思は紙に書かれました。

近代には印刷物になりました。

コンピュータ時代にはワープロ文書やPDFになりました。

そして現在、会社のルールそのものが、データベース、権限設定、業務システムの中へ移り始めています。

だからこそ、経営者に求められるコンピュータスキルも変わります。

かつては、

「自分で文書を作れること」

が重要でした。

これからは、

「自分の会社がコンピュータ上でどのような構造になっているのかを理解できること」

が重要になります。

システム会社にコードを書いてもらうことは問題ではありません。

専門家に実装を任せることも当然です。

しかし、

「誰が何を見られるのか」

「誰が何を決められるのか」

「どの業務からどのデータが生まれるのか」

「会社の規則がシステム上でどのように表現されるのか」

まで外部に任せてしまえば、経営者は徐々に規則を自由に作れなくなります。

コンピュータを使って経営する以上、システム設計は単なるIT部門の仕事ではありません。

それは、

会社のルールを、コンピュータ上でどう表現するかを決める経営そのもの

になり始めています。

ワープロを使えることが経営者の基本スキルだった時代の次には、

システムの構造を理解し、自社のデータ・業務・権限を自分たちで設計できること

が、経営者の基本的なコンピュータリテラシーになるのかもしれません。

歴史上、文字を読めなかった、あるいは書くことを十分に習得していなかった統治者は存在します。

それでも国家を治めることはできました。

なぜなら、王自身が読み書きをできなくても、

• 書記官
• 官僚
• 会計担当
• 法務を担う者
• 命令文書を作る者

が国家の内部に存在したからです。

つまり重要だったのは、

「王自身が文字を書けること」ではなく、「国家として文字を扱えること」

でした。

これは、現在の企業経営を考えるうえで、とても重要な示唆を与えてくれます。

文字の発明によって、統治は変わった

文字が使われる以前、命令や慣習の多くは人から人へ伝えられていました。

しかし社会が大きくなるにつれて、それだけでは統治できなくなります。

税を記録する。

土地の所有を記録する。

契約を記録する。

法律を記録する。

命令を遠隔地へ伝える。

過去の判断を後世へ残す。

社会が複雑になるほど、文字は単なるコミュニケーション手段ではなく、統治そのものの基盤になっていきました。

つまり、

権力
↓
命令
↓
文書
↓
行政

という構造が生まれたわけです。

王は書記官である必要はなかった

ここで大切なのは、王自身がすべての文書を書く必要はなかったことです。

王が決める。

書記官が文書にする。

官僚が配布する。

現場が実行する。

この分業は極めて合理的です。

現代企業でも同じです。

経営者自身が、

• Pythonを書く
• SQLを書く
• サーバーを構築する
• データベースを設計する

必要はありません。

それは専門家に任せればよい。

しかし、ここで一つ問題があります。

現代では、会社の規則そのものが「文書」だけに書かれているわけではなくなっているからです。

現在の会社では、ルールがシステムに埋め込まれている

例えば会社の規程に、

「営業部長は一定金額まで値引きを承認できる」

と書いてあるとします。

文書だけで運用するなら、人間がその意味を理解して判断できます。

ところがシステムでは、もっと具体的に決めなければなりません。

• 営業部長とは誰なのか
• どの営業所まで対象なのか
• いくらまで承認できるのか
• 自分の担当案件だけなのか
• 他部署の案件はどうするのか
• 代理承認は認めるのか
• 承認後に変更できるのか
• 誰が変更履歴を見られるのか

つまり、文章で一行の規則が、システム上では大量の条件へ変換されます。

ここで経営者がシステム構造を理解していなければ、その具体化をシステムを作る人間へ任せることになります。

経営者が決めた規則と、実際に動く規則は同じとは限らない

経営者が、

「必要な人には必要な情報を見せる」

と考えていたとしても、それだけではシステムは作れません。

誰が。

どのデータを。

どの条件なら。

どの期間まで。

どの操作まで。

許可されるのか。

最終的には、誰かが決める必要があります。

もし経営側で決められなければ、SEやSIerが設計します。

すると、

経営者の考える規則
↓
SIerによる解釈
↓
データモデル
↓
権限設計
↓
プログラム
↓
実際の会社の行動

という構造になります。

つまり、会社のルールを作ったつもりでも、そのルールを実際に実行可能な形へ変換したのは外部の人間、ということが起こります。

システムを変更できない会社は、規則を変更できない会社になる

さらに問題なのは、そのシステムが巨大化した後です。

経営環境が変わり、

「来月から組織を変えよう」

「承認制度を変えよう」

「営業所長へもっと権限を与えよう」

と考えたとします。

しかし、

「現在のシステムでは対応できません」

「改修すると別機能へ影響します」

「次回の更改まで待ってください」

と言われたらどうでしょうか。

本来、

経営判断
↓
業務変更
↓
システム変更

であるべきものが、

既存システム
↓
変更可能な業務
↓
その範囲で経営判断

へ逆転します。

これは、システムの問題ではありません。

経営権の問題です。

「システムを読める」とは、コードを読めることではない

ここで誤解してはいけないのは、

「経営者はプログラミングを学ばなければならない」

という話ではありません。

昔の王が、書記官と同じ速さで筆を使える必要がなかったのと同じです。

経営者に必要なのは、

• どんなデータが存在しているか
• データ同士はどう関係しているか
• 誰がどの情報を見られるか
• 誰がどの情報を変更できるか
• 誰が承認するか
• どの業務からどの業務へ情報が流れるか
• システムを変更すると何に影響するか

という、会社の情報構造を理解する力です。

言い換えるなら、

「コードを読む力」ではなく、「会社がコードによってどう表現されているかを読む力」

です。

文字を読めない王はいた

歴史を見れば、本人が読み書きを得意としなかった統治者はいました。

しかし、国家そのものが文字を扱えなくてよかったわけではありません。

むしろ大きな国家ほど、

• 記録
• 帳簿
• 法
• 命令
• 契約
• 税

を扱う仕組みが必要になりました。

ここに現代企業との共通点があります。

経営者自身がコードを書けなくてもよい。

しかし、

経営中枢の誰もシステム構造を理解していない

状態は話が別です。

もし国家の書記官が全員外国人だったら

少し極端な例を考えてみましょう。

王は命令を出す。

しかし、その命令を文書にする人間は全員外国から来た専門家。

過去の法律を読めるのも彼らだけ。

税の帳簿を理解できるのも彼らだけ。

どの文書がどの行政機関へ影響するかを理解しているのも彼らだけ。

そして王が、

「この制度を変えたい」

と言うと、

「それは現在の文書体系では難しいです」

と言われる。

これでは、誰が国家を統治しているのでしょうか。

現代企業で、

• データモデル
• 権限構造
• 業務フロー
• 会計連携
• システム間依存

をすべて外部のSIerしか理解していない状態は、これにかなり近いものがあります。

生成AI時代には、この問題がさらに重要になる

生成AIによって、コードを書くこと自体はどんどん簡単になっています。

しかし、コードが簡単に作れるほど、

「何を作るべきか」

を決める力が重要になります。

AIへ、

「この機能を追加して」

「この人だけ例外にして」

「この処理も自動化して」

と依頼すれば、機能は増やせます。

しかし設計思想がなければ、数年後、

「なぜこの人にこの権限があるのか」

「なぜこの数字が会計へ入るのか」

を説明できなくなるかもしれません。

それでは、AIへ経営判断を委ねているのではありません。

AIが生成した、誰も理解できない構造へ経営を従属させている

だけです。

現代の経営者に必要なのは「システム識字力」

かつて、文字を扱えることが統治に不可欠になりました。

その後、ワープロを使えることが経営者にとって重要なコンピュータスキルになりました。

そして今、会社の規則や権限がシステムによって実行されるようになっています。

そう考えると、次に経営者へ求められる能力は、

システム識字力

なのではないでしょうか。

プログラマになる必要はありません。

しかし、

「自分の会社がコンピュータ上でどのような会社として定義されているのか」

を読める必要はあります。

文字を読めない王はいました。

しかし、文字を扱えない国家は大きく発展できませんでした。

同じように、

コードを書けない経営者はいてもよい。
しかし、システムを理解できない経営中枢でよいのか。

これは、DXや生成AIが普及するほど重くなる問いだと思います。