投稿者: 沼田 勇作

  • (8月16日通信)文字を読めない王はいた。しかし「システムを読めない経営」は許されるのか

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

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

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

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

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

    つまり重要だったのは、

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

    でした。

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

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

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

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

    税を記録する。

    土地の所有を記録する。

    契約を記録する。

    法律を記録する。

    命令を遠隔地へ伝える。

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

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

    つまり、

    権力
    ↓
    命令
    ↓
    文書
    ↓
    行政
    

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

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

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

    王が決める。

    書記官が文書にする。

    官僚が配布する。

    現場が実行する。

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

    現代企業でも同じです。

    経営者自身が、

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

    必要はありません。

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

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

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

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

    例えば会社の規程に、

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

    と書いてあるとします。

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

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

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

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

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

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

    経営者が、

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

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

    誰が。

    どのデータを。

    どの条件なら。

    どの期間まで。

    どの操作まで。

    許可されるのか。

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

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

    すると、

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

    という構造になります。

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

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

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

    経営環境が変わり、

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

    「承認制度を変えよう」

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

    と考えたとします。

    しかし、

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

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

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

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

    本来、

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

    であるべきものが、

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

    へ逆転します。

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

    経営権の問題です。

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

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

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

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

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

    経営者に必要なのは、

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

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

    言い換えるなら、

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

    です。

    文字を読めない王はいた

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

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

    むしろ大きな国家ほど、

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

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

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

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

    しかし、

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

    状態は話が別です。

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

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

    王は命令を出す。

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

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

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

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

    そして王が、

    「この制度を変えたい」

    と言うと、

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

    と言われる。

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

    現代企業で、

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

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

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

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

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

    「何を作るべきか」

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

    AIへ、

    「この機能を追加して」

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

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

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

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

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

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

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

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

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

    だけです。

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

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

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

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

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

    システム識字力

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

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

    しかし、

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

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

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

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

    同じように、

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

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

  • (8月15日通信)業務マニュアルがあるのに、新人が仕事を覚えられない理由

    特集【会社の見える化】— 従業員視点

    業務マニュアルを整備したのに、新人から同じ質問を受ける。読んでから作業するよう伝えても、間違いが減らない。そのようなとき、本人の読解力や教育担当者の教え方だけを原因にしてはいけません。

    マニュアルが説明するのは通常の手順です。一方、新人が目の前で困っているのは、「この案件は今どの状態で、自分は次に何をすべきか」という具体的な判断です。

    手順が分かっても、開始地点が分からない

    たとえば「見積書を作成し、上司の承認後に顧客へ送付する」という手順が書かれていても、目の前の案件に必要な資料がそろっているか、価格は確定しているか、誰が承認者か、すでに別の担当者が送っていないかは分かりません。

    経験者は顧客との過去のやり取りや社内の暗黙の分担から判断します。新人にはその背景がありません。マニュアルの最初から最後までを読んでも、自分がどの地点にいるかを特定できなければ、動き出せないのです。

    そこで質問をすると、「その場合は先に営業へ確認する」「この顧客だけ様式が違う」といった例外が口頭で伝えられます。重要な知識がマニュアルではなく、教育担当者の記憶に追加されていきます。

    マニュアルと、仕事を進める画面の役割は違う

    マニュアルは、業務の目的、全体像、標準的な考え方、まれな例外を学ぶために必要です。しかし、毎日の仕事では、その案件に関係する情報だけが、現在の状態に合わせて見える方が役立ちます。

    「必要資料が一件不足しています」「次は見積作成です」「金額が基準を超えるため部長の承認が必要です」という案内を、案件の記録から表示します。作業を完了すると状態が変わり、次の担当者の一覧へ現れます。

    迷ったときには、その画面から該当するマニュアルの節を開けるようにします。業務画面が現在地と次の行動を示し、マニュアルが理由と詳しい方法を説明する。二つを分担させることで、長い文書の中から毎回該当箇所を探す負担を減らせます。

    新人の質問は、仕組みに足りない条件を教えてくれる

    新人が同じ箇所で迷うなら、「どの条件で手順が分かれるか」が明文化されていない可能性があります。質問をその場で解決して終わらせず、案件の状態、迷った選択肢、回答と理由を短く記録します。

    たとえば「新規顧客は誰が承認するのか」という質問が続くなら、新規か既存かを案件に持たせ、承認者を自動で示せます。「この添付書類は必要か」という質問なら、取引条件と必要書類の関係を定義できます。

    回答をすべてマニュアルへ追記すると、文書は長くなり、さらに探しにくくなります。毎回判断する必要のない条件は仕組みに移し、人の判断が必要な例外だけをマニュアルや相談先に残します。

    会社の全体像を隠してはいけない

    画面が次の操作だけを指示すれば、作業は早く覚えられます。しかし、理由を知らせずにボタンだけ押させると、例外に対応できる人は育ちません。

    自分の入力が、見積もり、受注、作業、請求のどこに位置し、次の誰が使うのかを見せます。顧客、案件、契約、請求がどうつながるかを、新人にも理解できる言葉で説明します。会社の実態を写した構造なら、仕事と画面を別々に暗記する必要がありません。

    仕組みは判断を奪うものではなく、定型的な判断を支え、より難しい判断を学ぶ余地を作るものです。

    教育担当者が一日に受ける質問を集める

    まず一週間、教育担当者が受けた質問を記録し、「場所が分からない」「現在の状態が分からない」「次の手順が分からない」「例外の判断が必要」に分けてみてください。件数が多く、業務への影響が大きいものを一つ選びます。

    その質問に答えるために経験者が確認している項目を洗い出し、案件画面で見えるようにします。次の行動を決められるものは条件として組み込み、決められないものは相談先と判断期限を表示します。

    新人が仕事を覚えるとは、マニュアルを暗記することではありません。会社の仕事がどうつながり、今の事実から次の行動をどう選ぶかを理解することです。マニュアルを増やすだけでなく、仕事の現在地を見えるようにする。その両輪が、人材を育てる仕組みになります。