Skip to content
Published on

職人とビルダー — LLMがキャリアを侵食するとき、開発者が立つべき場所

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 同じ週に公開された二つの記事

2026年5月末、開発者コミュニティのタイムラインに興味深い偶然がありました。Stack Overflowブログに「Artisans and builders」という記事が公開され、ほぼ同じ時期に、ある個人ブログの「LLMs are eroding my software engineering career and I do not know what to do」という記事がHacker Newsのフロントページを占拠し、GeekNewsでも熱く議論されました。

二つの記事は同じ現象を正反対の温度で扱っています。前者はAI時代の開発を職人(artisan)とビルダー(builder)という二つのアイデンティティに分け、比較的冷静に未来を展望します。後者は、10年以上かけて積み上げてきたスキルがLLMによって一夜にして減価されていくようだという、あるシニア開発者の切実な不安の告白です。

興味深かったのはHNのコメント欄の反応です。「私もまったく同じ気持ちだ」という共感と、「あなたの価値はコードのタイピングではなかった」という反論が、それぞれ数百件ずつ積み上がりました。この記事では二つの記事を軸にAI時代の開発者アイデンティティを再定義し、不安を実行可能な戦略に変える方法を整理します。

二つの記事の論旨 — 冷静な分類と切実な告白

Artisans and builders の論旨

Stack Overflowブログ記事の核心的な区分はこうです。

  • ビルダー(builder)は成果物を作ることが目的です。コードは手段であり、動くプロダクトがゴールです。AIツールはビルダーにとって史上最高の贈り物です。
  • 職人(artisan)は作る過程そのものと、作りの品質に価値を置きます。システムを深く理解し、エレガントな解法を追求し、ツールの内部まで掘り下げます。

著者の展望は二極化です。AIはビルダーの参入障壁を事実上取り除き、同時に、AIが作った膨大な成果物が壊れたときにそれを直せる職人の希少価値を引き上げたというのです。危険なのは中間地帯です。職人の深さもビルダーの速さもないポジションが、最初に圧迫を受けます。

LLMs are eroding my career の論旨

反対側の記事は理論ではなく感情から出発します。著者はおおよそこう語ります。

  • 私はコードをうまく書くことでアイデンティティと自尊心を築いてきた人間だ。
  • 私が一日かけて書いていたコードを、今はLLMが10分で書く。自分の差別化要素が何なのか分からない。
  • 会社はAIツールの使用を事実上義務化し、私は自分のスキルが溶けていくのをリアルタイムで見ている気分だ。
  • もっと学べと言われるが、学ぶ速度よりツールが進化する速度の方が速い。どこへ逃げればいいのか分からない。

この記事が爆発的に共有された理由は明確です。多くの開発者が口に出せずにいた感情を、正確に言語化したからです。2026年現在、Claude CodeやCodexのようなエージェントが数時間規模のタスクを自律実行する環境で、この不安は少数派のものではありません。

二つの記事を並べてみると

比較項目Artisans and buildersLLMs are eroding my career
視点産業構造の俯瞰図個人の一人称体験
温度分析的、冷静切実、喪失感
核心の主張アイデンティティが二極化する既存のアイデンティティが崩れつつある
AIへの態度ツールであり構造変化の動力自己価値を侵食する存在
提示する解法職人かビルダーへの整列解法なし(問いで終わる)
読者に与えるもの地図共感

興味深いのは、二つの記事が事実認識ではほぼ一致していることです。コード生産の価値が急落しているという診断は同じです。分かれるのはその先です。一方は価値が移動した先を指し示し、もう一方は移動についていけるかを恐れています。この記事の残りは、その隙間、すなわち地図と共感の間をつなぐ実行の問題を扱います。

実際に何が変わったのか — 民主化と再評価

二つの記事を重ねると、変化の実体が見えてきます。変わったのは開発者の価値ではなく、価値の分布です。

        AI以前の価値曲線                  AI以後の価値曲線

  価値 |        ____                価値 |  __
       |    ___/    \___                 | /  \
       |   /            \                |/    \
       | _/              \_              |      \____        ___
       |/                  \             |           \______/
       +--------------------->           +--------------------->
        入門   中間   熟練                 入門   中間   熟練(職人)

  なだらかな能力-価値の比例              中間地帯が陥没、両端が上昇

ビルダーの民主化

まずポジティブな変化から見ましょう。今や誰でも作れます。企画者が社内ツールを自分で作り、デザイナーがプロトタイプをコードで検証し、一人創業者が外注なしでプロダクトをリリースします。2026年のハッカソンの風景は象徴的です。ハードウェアハッカソンが復活し、参加者の半分が非専攻者で、デモの完成度は5年前のシードスタートアップ水準です。

これは脅威である以前に、市場の拡張です。ソフトウェアが作られる総量が爆発的に増えており、作られたソフトウェアはいつか必ず壊れ、統合されなければならず、拡張されなければなりません。

職人的価値の再評価

まさにその地点で、職人の価値が再評価されます。AIが生成するコードの量が増えるほど、次の能力の希少価値が上がります。

  1. 深いデバッグ能力。AIは自分が作ったコードの障害を説明できないことが多いものです。分散システムのタイミング問題、メモリリーク、ドライバレベルの問題は、依然としてシステムを層全体で理解する人が解きます。
  2. システムレベルの理解。個々のコードはAIが書きますが、サービス境界をどう切るか、データ一貫性をどこで保証するかは、システム全体を頭に入れた人の仕事です。
  3. 責任を取る能力。規制産業で、このコードがなぜ安全なのかを監査の前で説明し署名するのは、人間の仕事として残っています。2026年6月、npmサプライチェーン攻撃がRed Hat Cloud Servicesまで侵入した事件は、ボトルネックが生成速度ではなく検証の深さであることを改めて示しました。

2024-2026、認識変化のタイムライン

この論争が突然現れたものではないという点も押さえておく必要があります。コミュニティの空気の変化を大まかに時系列で描くと次のとおりです。

2024        2025上半期       2025下半期        2026上半期
  |              |                |                 |
「補完が       「エージェントが  「チーム単位導入、 「長時間自律作業、
 良くなった」   PRを送ってくる」  職務再編の開始」   アイデンティティ論争」
  |              |                |                 |
 物珍しさ  ->  生産性の興奮  ->  組織的摩擦    ->  実存的な問い
                                (レビュー負債、    (職人 vs ビルダー、
                                 ジュニア採用縮小)  キャリア侵食の告白)

2026年の特徴は、論争の層がツールからアイデンティティへ降りてきたことです。もはやどのツールが良いかは問われません。ツールは前提となり、問いは「では私は何者なのか」に変わりました。二つの記事が同じ週に爆発的に読まれたのは偶然ではなく、コミュニティ全体がこの問いに到達したというシグナルと読むのが正しいでしょう。

シナリオ — 10年目の決済バックエンド開発者の場合

抽象論を避けるため、具体的な人物を立ててみましょう。仮想の人物Kは10年目のバックエンド開発者で、決済と精算のシステムを主に作ってきました。Kの不安は明確です。決済API連携コード、精算バッチ、Webhook処理といったKの得意技を、今やエージェントが1時間で作り上げます。

しかしKの資産を分解してみると、話は変わってきます。

Kの資産AIによる代替可能性理由
API連携コードの作成高いパターン化された作業、ドキュメントから生成可能
精算バッチの実装高い仕様が正確なら生成可能
二重決済エッジケースの知識低い障害を直接経験して積み上がる暗黙知
決済代行会社ごとの精算差異と罠低い文書化されていないドメイン知識
金融規制対応の経験低い責任と信頼が結びついた領域
障害時の意思決定非常に低い文脈、権限、責任の結合

Kが脅かされているのは資産の上の二行だけです。しかしKは過去10年間、自分の価値を上の二行で説明してきたため、すべてを失う気分になるのです。再定義はこうなります。Kはコードを速く書く人ではなく、お金が漏れないシステムとは何かを知っている人です。そしてエージェントが決済コードを1時間で作り出す世界では、そのコードがお金を漏らさないかを判別できる人の価値は、むしろ上がります。

Kの戦略は逃走ではなく再配置です。ドメイン知識をAIツールと結合し、決済システムを検証するevalsを作り、エージェント用コンテキスト文書でチームの決済コード品質基準を明文化し、AIが量産する決済連携コードの最終ゲートキーパーになることです。

Kの実際の成果物 — ドメイン知識をコードに移す

Kがハイブリッド戦略を実行するなら、何を作ることになるでしょうか。最初の成果物は、決済ドメインの暗黙知をエージェントが読めるコンテキスト文書に移すことです。

# PAYMENTS.md — 決済モジュール作業時のエージェント必読ルール

## 絶対ルール
- すべての決済リクエストは冪等キーを受け取る。冪等キーなしの決済APIは作成禁止。
- 金額計算に浮動小数点の使用禁止。通貨の最小単位の整数のみで計算。
- 外部決済代行の呼び出しはタイムアウト5秒、再試行は冪等保証区間でのみ。
- 返金は元取引の状態検証後にのみ。状態マシン図を参照。

## 頻出する罠(実際の障害履歴に基づく)
- 決済代行AはWebhookを最大3回重複送信する。受信側の冪等処理必須。
- 決済代行Bの精算金額は消費税込み、Aは税抜き。比較ロジックに注意。
- キャンセルAPIは営業日の締め時刻以降の呼び出しで翌日処理になる。

## 状態遷移(これ以外の遷移はすべてバグ)
READY -> PAID -> (CANCELLED | REFUND_PENDING -> REFUNDED)

二つ目の成果物は、エージェントが作った決済コードを機械的に検証するevalです。

# payment_evals.py — AI生成の決済コードの自動検証
import re

CRITICAL_PATTERNS = [
    (r"float\(.*(amount|price|fee)", "金額にfloatを使用 - 整数の最小単位で"),
    (r"requests\.(post|get)\((?![^)]*timeout)", "外部呼び出しにtimeoutなし"),
    (r"def\s+(charge|pay|refund)\w*\((?![^)]*idempotency)",
     "決済関数に冪等キーのパラメータなし"),
]

def eval_payment_code(source: str) -> list[str]:
    findings = []
    for pattern, message in CRITICAL_PATTERNS:
        if re.search(pattern, source):
            findings.append(message)
    return findings

def test_no_critical_findings():
    for path in changed_payment_files():
        assert eval_payment_code(read(path)) == []

この二つのファイルが象徴するものが重要です。Kの10年がKの頭の中にしかなかったとき、その価値はKが自分でコードを書くときにしか発揮されませんでした。文書とevalに移された後は、エージェントがコードを100倍生産しても、Kの基準がすべてのコードに適用されます。これがドメイン専門家のレバレッジ転換です。

私はどこにいるのか — 自己診断チェックリスト

戦略を選ぶ前に、現在地を診断してみましょう。次の項目にはい/いいえで答えます。

[職人軸]
1. 直近1年以内に、他の人が諦めた障害の根本原因を突き止めたことがある
2. 主力スタックの内部実装(フレームワークのソース、DBエンジンの動作)を説明できる
3. AIが生成したコードから、動くが危険な箇所をよく発見する
4. パフォーマンス問題に推測ではなく計測でアプローチする

[ビルダー軸]
5. アイデアを一週間以内に動くデモにできる
6. 技術選定で新しさよりリリース速度を優先したことが多い
7. コード品質よりユーザーフィードバックの獲得を先に考える
8. AIエージェントに作業を委任する自分なりのワークフローがある

[ドメイン軸]
9. 特定の産業/ドメインの障害事例をメモなしで列挙できる
10. そのドメインの規制や慣行のせいで技術的な正解が変わるケースを知っている
11. ドメイン専門家(非開発者)と彼らの言葉で会話できる
12. 私のドメイン知識を求める人が社内外に存在する

各軸で3つ以上なら、その軸が強みです。職人軸だけが強ければ深化パス、ビルダー軸だけが強ければ拡張パスが自然で、ドメイン軸が3つ以上ならハイブリッドパスの原材料をすでに持っています。三つの軸すべてで2つ未満なら、それこそが二つの記事が警告する中間地帯であり、どれか一つの軸を決めて意識的に投資を始めるべきというシグナルです。

キャリアの選択肢比較 — 三つの経路

Kのような状況で選べる経路を三つに整理すると次のとおりです。

項目スペシャリスト深化ジェネラリスト拡張ドメイン + AI ハイブリッド
方向一分野の最後の専門家プロダクト全体を扱うビルダードメイン知識でAIを指揮
例DB内部、カーネル、コンパイラ、セキュリティフルスタック + プロダクト感覚 + 営業決済専門家 + エージェント運用
AIとの関係AIが解けない問題を解くAIで生産性を最大化するAIの成果物をドメインで検証する
リスク分野自体の需要縮小差別化が弱く、競争が激しい二兎を追って両方逃す可能性
報酬構造少数ポジション、高単価多数ポジション、変動の大きい報酬新興ポジション、現在は供給不足
向いている人深く掘るのが楽しい人作って世に出すのが楽しい人ドメイン経験5年以上の保有者

三つの経路はすべて有効ですが、2026年現在の市場で供給が最も不足しているのは三つ目です。ドメインを知る人は多く、AIツールを使う人も多いですが、ドメイン基準でAIの成果物を検証する仕組みを作れる人は稀です。

避けるべきは、選ばないことです。職人の深さも、ビルダーの速さも、ハイブリッドの結合もなしに昨日と同じ仕事をする中間地帯こそ、二つの記事が共通して指摘する危険地帯です。

四半期ごとの実践プラン — 1年のロードマップ

方向を決めたら実行です。ハイブリッド経路を例に、業務外で週4時間の投資を仮定した4四半期プランです。

第1四半期 — 診断と基盤

  • 自己資産インベントリの作成: 上記のKのように、自分のスキルをAI代替可能性の基準で分解した表を作ります。
  • AIエージェントワークフローを一つ業務に定着: コードレビュー補助、テスト生成など小さなものから。
  • 自分のドメインの暗黙知の文書化を開始: 障害事例、エッジケース、罠を週1件ずつ記録します。

第2四半期 — 結合の実験

  • ドメイン知識をエージェントコンテキストに変換: 第1四半期に記録した文書をCLAUDE.mdやAGENTS.md形式に整理してエージェントに注入し、成果物の品質変化を観察します。
  • ドメイン特化evalの初作成: 自分の分野の致命的ミス(決済なら冪等性違反、金額の丸め誤差)を捕まえる検証スクリプトを作ります。
  • 社内共有1回: 小さくても発表し、ハイブリッドポジションを可視化します。

第3四半期 — レバレッジの拡大

  • チーム単位の導入: 個人ワークフローをチーム標準に昇格させる提案をします。
  • 外部発信の開始: ブログ記事2本またはミートアップ発表1回。市場での識別可能性を作ります。
  • 深さの補強: 自分のドメインに隣接する基盤技術(決済なら分散トランザクション、冪等性設計)を一つ体系的に学習します。

第4四半期 — ポジションの整理

  • 成果の定量化: エージェント導入前後のレビュー時間、欠陥率、処理量の変化を数字で整理します。
  • キャリア文書の更新: 履歴書とポートフォリオを、コードの書き手ではなくシステム品質の保証者の観点で書き直します。
  • 翌年の方向決定: 1年のデータを根拠に、深化、拡張、移動のいずれかを選びます。

核心原則は二つです。第一に、すべての四半期に外部から確認可能な成果物(文書、発表、数字)を残します。第二に、ツール学習自体を目標にしません。ツールは四半期ごとに変わりますが、ドメイン知識と検証体系は蓄積されます。

四半期プランを週間ルーチンに換算すると次のとおりです。

曜日活動時間蓄積される資産
月ドメイン暗黙知1件の文書化30分コンテキスト文書
水AI成果物の精密レビュー1件1時間評価能力、eval候補
金evalまたは自動化スクリプトの改善1時間検証体系
週末深さの学習(基盤技術1テーマ)1.5時間職人軸の能力

週4時間で、すべて業務に直結するため、かなりの部分は業務時間内で消化できます。重要なのは4時間という量ではなく、毎週4種類の資産がすべて1ずつ増える構造です。

履歴書と面接 — 再定義された価値を証明する方法

方向を変えたなら、市場に見せる言葉も変えるべきです。2026年の採用市場で実際に変わった点を反映した書き方です。

まず、産出量の記述から判断の記述へ移します。

以前の書き方(生産中心):
- 決済モジュールの新規開発および決済代行3社との連携実装
- 精算バッチシステムの開発、日次500万件処理

2026年の書き方(判断とレバレッジ中心):
- 決済ドメイン検証体系(evals 12種、コンテキスト文書)の構築により、
  AI生成コードの決済関連欠陥を四半期あたり9件事前遮断
- エージェント協業ワークフローの設計でチームの決済機能リードタイムを
  60%短縮、同時に障害率を維持(導入前後のデータ保有)
- 決済代行の精算不一致障害5件の根本原因分析と再発防止設計

面接でも質問の軸が移動しています。コーディングテストの比重が減った場所に、次のタイプが入ってきています。

  • AIが生成したコードの塊を渡し、欠陥を見つけさせるレビュー面接
  • 曖昧な要求事項をスペックに整理させる仕様面接
  • 障害シナリオを与え、対応を指揮させるシミュレーション面接

三つのタイプすべてで、上記の週間ルーチンがそのまま練習になる点に注目する価値があります。準備と実務が分離しないのが、この転換期のせめてもの救いです。

組織の観点 — シニア価値の再評価

個人だけの問題ではありません。組織も同じ問いに直面しています。ジュニアがエージェントと共にシニア分量のコードを生産するとき、シニアの年俸は何への対価なのか。

先進的な組織がたどり着きつつある答えは、シニアの役割の再定義です。

  従来のシニア                          2026年型シニア

  - 最も難しいコードを自分で書く       - 最も難しい決定を下す
  - レビューで品質を守る               - 品質基準をevalsとコンテキスト
  - ジュニアを1対1でメンタリング          文書に明文化して自動化
  - 障害の最終解決者                   - エージェント群の作業設計者
                                       - 依然として障害の最終解決者

注目すべきは最後の行です。障害対応だけは変わりませんでした。AIが作ったシステムが崩れるとき、復旧を指揮できる人の価値はむしろ急騰しました。組織がシニアを評価する軸は、産出量から二つへ移動しています。第一に、この人がいなければ解決しない障害があるか。第二に、この人の判断基準がチームのシステム(レビュールール、evals、コンテキスト文書)にどれだけ移転されているか。

逆説的ですが、二つ目の軸は自分を代替可能にする作業です。しかし自分の判断をシステム化できる人は、次の段階のより難しい判断へ上がっていくことになり、それがシニアキャリアの新しい梯子になりつつあります。

組織が実際に導入している制度の変化も参考になります。

制度内容意図
レビューゲート職AI生成コードのマージ承認権限を明示的な役割に検証責任の明確化
コンテキスト文書のオーナーシップCLAUDE.md類の文書をコードと同格の資産として管理暗黙知のシステム化
障害指揮ローテーションシニアのインシデントコマンダー能力を公式評価項目に代替不可能な能力の可視化
エージェント予算制チーム別AI使用量を予算で管理、ROI測定無分別な生成の抑制

これらの制度の共通点は、生産ではなく検証と責任に役職と報酬を付けていることです。個人のキャリア戦略と組織の制度変化が、同じ方向を指しているわけです。

メンタル管理 — 不安と共に働く方法

bearblogの記事が投げかけた本当のテーマは技術ではなく感情です。いくつかの実質的な助言を整理します。

  1. 不安の解像度を上げます。漠然とした「代替されそうだ」を具体的なリストに変えます。上記Kの表のように書き出してみると、代替されるのは大部分がスキルの一部であって全部ではありません。不安は解像度が低いときに最も大きくなります。
  2. 比較対象を変えます。エージェントの生産速度と自分を比べるのは、ショベルカーとスコップの速さを競うことです。比較は、同じツールを持った1年前の自分とします。
  3. アイデンティティを行為ではなく価値に置きます。私はコードを書く人ではなく、問題を解きシステムに責任を持つ人だという再定義は、心理的防衛ではなく、事実により近い記述です。
  4. 手を完全に離しません。定期的にエージェントなしでコーディングする時間を別に設けます。スキル維持の目的もありますが、作る楽しさというこの職業の源泉燃料を守ることでもあります。
  5. 話せる場所を作ります。bearblogの記事に数千人が共感したという事実自体がメッセージです。この不安は普遍的であり、口に出した瞬間、半分は軽くなります。

不安が日常の機能を侵害するレベルなら、職業的助言の範囲を超えているので、専門家の助けを受けるのが正しい選択です。その前の段階で使える、簡単な週間チェック表を添えます。

週間メンタルチェック(金曜5分)
- 今週、自分が下した判断のうちAIにはできなかったもの一つ: ______
- 今週、新しく学んだこと一つ: ______
- 今週、誰かの役に立ったこと一つ: ______
- 来週、手放すこと一つ(エージェントに委任): ______

四つの欄が毎週埋まるなら、侵食されているのはキャリアではなく、古い自己定義だけです。

批判的視点 — 恐怖マーケティングを警戒せよ

最後に、この言説全体にかけるべきフィルターがあります。

第一に、恐怖はよく売れます。開発者終末論は、再生数、講座販売、ツールのサブスクリプションに直結するコンテンツジャンルになりました。「今このツールを学ばなければ淘汰される」というメッセージの発信者が何を売っている人なのか、常に確認すべきです。

第二に、外挿の誤りです。直近2年の進歩速度を直線で延長して5年後を描く予測は、ほぼ常に外れてきました。自動運転がそうで、ノーコードがそうでした。能力の向上が続いても、組織の導入速度、規制、責任の問題ははるかに遅く動きます。

第三に、生産性統計の罠です。AIツールでコード生産量が増えたという統計と、そのコードが生んだ障害や手戻りまで含めた純生産性は別の数字です。2026年の複数の現場報告は、レビュー負債と誰も理解していないコードの蓄積という新しいコストを指摘しています。

第四に、それでも変化自体を否定するのは、もう一つの安楽な嘘です。方向は明確です。コード生産の価値は下がり、判断と責任の価値は上がります。恐怖でも否定でもなく、冷静な再配置が必要な時点です。

よくある質問

このテーマで社内勉強会やメンタリングをしていると、繰り返し出てくる質問があります。短く整理します。

Q1. 決済のようなドメインがない普通のWeb開発者はどうすればいいですか?

ドメインは産業だけを意味しません。アクセシビリティ、国際化、パフォーマンス最適化、レガシー移行のような横断領域もドメインです。核心条件は二つです。失敗事例が蓄積される領域か(暗黙知が積み上がるか)、そしてAIの成果物の品質をその知識で判別できるか。今担当している業務で最も頻繁に事故が起きる領域は何かを見るところから始めればよいのです。

Q2. 今からでも深さを掘るべきですか、ツールから習得すべきですか?

順序の問題ではなく比率の問題です。ツールの習熟は2026年現在、数週間あれば十分追いつける領域になり、格差も急速に縮みます。一方、深さとドメインは追いつくのに年単位かかります。したがって時間配分はツール2対深さ8程度が合理的です。ただし、ツールの2を0にしてはいけません。ツールを知らなければ、ツールの成果物を検証する感覚も鈍ります。

Q3. ジュニアですが、職人になる機会自体が消えていくのではないですか?

最も難しい質問です。単純作業という伝統的な訓練場が減っているのは事実です。代案は意図的な修練です。エージェントが1時間で終える仕事を週末に自分でやってみること、エージェントの成果物を行単位で説明してみること、小さなシステムを最初から最後まで一人で作ってみること。非効率と知りながら選ぶ非効率は訓練であり、知らずに被る非効率は浪費です。訓練の非効率を意識的に買わなければならない最初の世代になったのです。

Q4. 会社がAIツール導入だけ推し進めて、検証体系には関心がありません。

よくある状況で、逆説的にチャンスです。組織の関心が生産に偏っているとき、検証の空白は広がり続けており、その空白はいつか障害やセキュリティ事故という請求書になって戻ってきます。請求書が来る前に検証体系を静かに作っておいた人は、事故の後、組織が最初に探す人になります。2026年のnpmサプライチェーン攻撃の後、多くの組織で実際に起きたことです。

Q5. 二つの記事のうち一つだけ読むなら、どちらを読むべきですか?

bearblogの記事を先に読むことをお勧めします。戦略は感情を直視した後にしか機能しないからです。不安を飛ばして立てた計画は、不安が戻ってきた瞬間に崩れます。

おわりに — 職人かビルダーかは、間違った問いかもしれない

二つの記事をもう一度重ねてみましょう。Stack Overflowの記事は職人とビルダーを区分しましたが、実際の現場で生き残るポジションは、その区分のどちらか一方ではなく、切り替え能力にあるようです。午前はビルダーとしてエージェントに作業を委任して速度を出し、午後は職人としてその成果物の深部を検証する人。ドメインという錨を下ろしたまま、二つのモードを行き来する人。

bearblogの著者が感じた喪失感は本物です。コードをうまく書くことがそのまま自分だった時代は、実際に暮れつつあります。しかしそのスキルが消えるのではなく、より大きな仕事(判断、検証、責任)の基盤として吸収されるのだとしたら、これは降格ではなく昇進に近いものです。ただ、昇進がいつもそうであるように、昨日まで得意だった仕事と、明日から得意であるべき仕事が違うだけです。

立つべき場所は明確に見えます。AIが作るものの横ではなく、AIが作ったものと世界の間。その場所の名前が職人であれビルダーであれ、重要なのはその場所に立っているという事実です。

最後に実践の要約です。今週やることは三つだけです。

  1. 自己診断チェックリストを記入し、自分の軸を確認します。
  2. 自分の分野の暗黙知を1件、文書に移します。
  3. bearblogの記事を読み、共感する文に下線を引きつつ、最後に上の表の右の列(地図)をもう一度開きます。

不安はデータではなくシグナルです。シグナルを受け取ったなら、今度はデータを作る番です。

参考資料

Discuss on Twitter • View on GitHub