見出し画像

よい開発者とよい経営者の条件は似ている ─AIが気づかせてくれたこと─

前々回、「コードが書けない40代事務員が特許出願レベルのシステムを作った話」という記事を書きました。CGP(Core Growth Prompting)の元となる手法で、自動車業界の事務員をしている自分が、AIとの対話だけでシステムを組み上げた話です。

あれから、CGPを使ってさらに別のシステムを作る中で、ずっと考えていたことがあります。

「開発を通じて、マネージャータイプの仕事ができる人間はよい開発者になれる印象がある」

今回はその話をしたいと思います。


AIに任せられる部分、自分で決めるしかない部分

バイブコーディングで開発を進めていくと、作業がはっきり二つに分かれてくることに気づきます。

一つは、AIに任せられる部分。技術的な実装、矛盾のチェック、コードに落とし込む作業。ここは正直、AIの方が自分よりずっと得意です。

もう一つは、自分で決めるしかない部分。何をコアにするか、何をもって完成とするか、優先順位をどうつけるか。ここはAIがいくら賢くても、代わりに決めてはくれません。

そして気づいたのは、この「自分で決めるしかない部分」が、全部、経営者的な判断だったということです。

たとえば、私はこんな判断をしてきました。

  • ある核となるプロンプトを「絶対に触らないコア」だと決めたこと

  • 「完璧はあり得ないから、実用レベルで十分な堅牢性とハルシネーション耐性、低レイテンシーがあればいい」を完成の定義にしたこと

  • 特許出願が終わるまでは、どんなに公開したくてもGitHubには出さないという順番を守ったこと

  • 別の使い道が見えていても、規制リスクを先に整理してから動いたこと

  • A方式では予算が足りないが、B方式なら自分の持ち出しゼロでできる、とアイデアをひねり出したこと

どれもコードの話ではありません。「何を守り、何を諦め、どこまでをゴールとするか」という決断です。
これは、事業の核を定めたり、KPIと撤退条件を決めたり、リソース配分を決めたりする経営者の仕事と、驚くほど似ています。

求められる資質は同じだった

対話を重ねる中で、開発と経営に共通して必要な資質が見えてきました。(CGPだけでなく、コードが書ける人たちが行う開発も同様です。念のため。)

  • 決断力:何をコアにし、何をもって完成とするかを自分で決める力

  • 発想力とリスクヘッジ:「これは他にも使えるかもしれない」と「これをやったら何が困るか」を同時に考える力

  • 対話力:AIから必要な答えを引き出し続ける力。経営者で言えば、メンバーや顧客との対話力

  • しつこさ:長い対話を通じて、投げ出さずに完成まで持っていく粘り強さ

CGPでの判断と経営者の仕事を並べてみると、こんな対応関係になります。

「経営者視点を持て」と言われても

会社では、よく「経営者視点を持て」と言われます。上司からも、研修でも、本でも。
でも正直、あの言葉ほど、意図は伝わるのに実践が難しいものはないと思っています。

「視座を上げろ」「全体最適で考えろ」と言われても、じゃあ具体的に何をどう考えればいいのか。
ロールプレイのように「経営者ならどう考えるか」と頭で意識しても、結局は他人事のシミュレーションで終わってしまう。自分の仕事、自分のお金、自分の失敗ではないからです。

CGPでシステムを作っている間、僕は一度も「経営者視点を持とう」と意識したことはありませんでした。
ただ、コアを決めなければ前に進まないから決めた。完成の定義を決めなければAIとの対話が終わらないから決めた。規制リスクを整理しなければ次の一歩が踏み出せないから整理した。

必要に迫られて判断していただけです。それが、後から振り返ると全部、経営者の仕事そのものだった。

バイブコーディングを通じて、意識しなくとも経営者視点に触れられる。

これが今回の一番の発見だったように思います。「視点を持て」と言われて持てるものではなく、「自分で決めるしかない状況」に置かれて初めて、体で覚えるものなのかもしれません。
教養としてAIに触れるだけでなく、意識的にトレーニングとしてバイブコーディングを行う社員研修が将来生まれるのかもしれません。

技術の壁がなくなったとき

これまでのソフトウェア開発は、「高性能なPC、高速回線、高額なIDE、長年の学習コスト」が前提でした。だから、経営者的な思考回路を持つ人がいても、技術の壁がその人の参入を阻んでいました。

でもバイブコーディングという手法が生まれてから、状況が変わりました。経営者的な思考回路を持つ人が、そのままの形で技術者的なアウトプットを出せるようになったのです。

コードは書けなくていい。高性能なPCも要らない。必要なのはインターネット回線と、クラウドLLMへのアクセスだけです。

対話の中で、ふとこんな言葉が出てきました。「これは技術の民主化を超えて、開発と経営の境界を溶かす手法なんじゃないか」と。

シビックテックへの想像

余談ですが、この話をしていて連想したのが台湾のシビックテック文化でした。g0vやオードリー・タンが体現してきた「技術と市民参加の融合」という文化に、以前から憧れを抱いています。

シビックテックの理想的な担い手は、実は「技術者」よりも「社会課題に具体的な不満を持っている市民」だと言われます。
行政の非効率に怒っている公務員、医療制度に疑問を持つ看護師、教育現場に課題を感じる教師。彼らの「具体的な不満」こそが出発点になる、という考え方です。

これは、CGPの起点である「具体的な不満・疑問」と、そのまま重なります。技術者に頼らなくても、自分たちの手で解決策のプロトタイプを作れるとしたら。

「問題提起はできるけど、技術者を動かせない」という壁の正体は、たぶん「言葉」と「動くもの」の間にある翻訳コストの高さです。
プロトタイプが一つあれば、技術者もゼロから想像するより、目の前にあるものを改善する方がずっと動きやすい。プロトタイプは、最良の仕様書になり得ます。

技術の壁がなくなったとき、残るもの

技術の壁がなくなったとき、最後に残るのは、純粋に判断力と発想力、そしてしつこさだけなのかもしれません。

それは特別な誰かだけが持っているものではなく、どの組織にも一人はいる、マネージャータイプの人間が普通に持っているものです。

もしかしたら、あなたの組織にも、まだ本人すら気づいていない開発者がいるかもしれません。


いいなと思ったら応援しよう!