■コードを読めないプロCxOたち

APIを書き、CIを回し、バグを踏み、直し、また壊す。

そんな日々の中で最も厄介なのは、CxOたちだ。

──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。

PowerPointを開いて「DXを推進している」と言う人たち。

1. コードを読めないプロCxOたち

うちのCxOはこう言った。

「AIとクラウドを活用して競争力を高めたい」

翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。

その瞬間、何かが切れた。

──ケーキではない。

CxOたちはコードを読めない。

それ自体は罪ではない。

だが、読もうとしないことは怠慢だ。

経営層は「現場に任せている」と言う。

だがそれは委任ではなく放棄だ。

責任ある意思決定者が構造を理解しないまま判断することは、

“現場を信頼している”という名の無関心である。

2. 「経営層はコードを読む必要はない」という言い訳

よく聞く反論がある。

「経営層はコードを読む必要はない。経営判断こそが役割だ。」

確かにそうだ。

ただし前提が抜けている。

経営判断とは、構造を理解した上で行う選択のことだ。

構造を理解せずに選択するのは、“判断”ではなく“賭け”だ。

つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。

その区別がつかない時点で、DXを語る資格はない。

「技術的なことは詳しくないが、成果は出している」

それはたまたまだ。

成果が出たという事実は、理解が正しかった証拠にはならない。

1回の成功は偶然でも、構造理解の欠如は必ず再現する。

3. PMたちの同調が負債を増やす

PMたちはCxOの拡声器になりがちだ。

「上が言ってるから」「今期の方針だから」「スピード優先で」。

その瞬間、技術的判断は政治的判断に変わる。

Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。

技術的負債の意味を知らないまま「負債を減らせ」と言う。

借金の仕組みを知らない人間が財務を回しているようなものだ。

「リソースが限られているから仕方ない」

これもよく聞く言い訳だ。

しかし、リソースが限られているならなおさら、理解の精度が重要になる。

「考える時間がない」と言う人に、考える力がある例はない。

4. 技術を理解しない意思決定の帰結

僕が書いたAPIは、リクエストごとに外部APIを叩いていた。

「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。

半年後、アクセススパイクでAPIが落ちた。

CxOたちは言った。

「想定してなかったのか？」

──想定してた。

ただ、あなたたちが理解しようとしなかっただけだ。

「現場の説明が難しい」と言う人がいる。

だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。

理解する努力をしない経営層に、理解される説明は存在しない。

CxOたちは「モノリスからマイクロサービスへ」と言うけど、

組織はモノリスのままだ。

責任は分散せず、報告だけがマイクロ化している。

そして障害対応は現場に丸投げ。

Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。

5. 切れるのはコストだけ

CxOたちは「コストを切れ」と言う。

工数を減らせ、サーバを減らせ、障害をなくせ。

切れるのはコストだけ。

品質は切らない──なんて言葉、誰も言わない。

「現場は経営目線がない」と言う人もいる。

だが本当に経営目線を持つなら、

技術リスクも経営リスクとして扱うはずだ。

理解しないことが最大のコストだと気づかない限り、

彼らの「経営目線」はただのスローガンだ。

削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。

リファクタリングは「次のスプリントで」。

セキュリティ対応は「リリース後に検討」。

Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。

6. 「DX」という呪文の下で

CxOたちは「我々はデジタル変革を進めている」と言う。

だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。

クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。

「我々は経営視点で見ている。現場とは違う軸だ」

──違う軸を持つのは構わない。

だが、座標を理解していなければ軸は存在しない。

現場を理解しない経営視点は、地図を見ないドライバーと同じだ。

どこかに向かってはいるが、それがどこなのか誰も知らない。

7. 「ノーコードでいい」という幻想

最近では、CxOたちの間で新しい呪文が流行している。

「コードなんて書かなくていい。これからはノーコードの時代だ。」

確かに、ノーコード／ローコードは優れたツールだ。

反復作業の効率化や、ビジネス部門の自律化には意味がある。

だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。

ノーコードは、コードを隠す。

だが、隠したコードが消えるわけではない。

ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。

それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。

「ノーコードでいい」と言うCxOは、

「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。

確かに飛ぶ。だが、落ちたときに理由を説明できない。

理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。

ツールがコードを隠蔽してくれる世界では、

理解しようとする努力がさらに失われる。

そして、理解がないまま作られた自動化は、

人を楽にするどころか、誰も直せない仕組みを量産する。

DXとは、ツールを導入することではない。

ツールの背後にある構造を理解する文化を持つことだ。

それを理解しない限り、

ノーコードで作るのは「システム」ではなく、次のレガシーだ。

8. 結論 〜ケーキではなくコードを切れ〜

CxOたちは、ケーキを切れない非行少年たちのように、

現実の構造を理解できずに「甘い理想」を切り分けようとする。

だが今の時代、切るべきはケーキじゃない。

理解しないことだ。

理解しないまま意思決定をすることは、

無免許で運転するようなものだ。

現場はずっとブレーキを踏み続けている。

それでも上層部は「もっとスピードを」と言う。

そして事故が起きたとき、

真っ先に切られるのは、

──コストだけ。

最後に

CxOたちは「未来を見ている」と言う。

だが、コードを読まない者に未来は読めない。

未来とは、仕様書ではなく、Pull Requestの積み重ねだ。

経営とは、方針を語ることではなく、構造を理解して責任を取ること。

そして最後に、コミットログの一行が残る。

fix: typo in code

Permalink | 記事への反応(2) | 16:23

ツイートシェア