コミュニケーション能力の正体は、情報の非対称性を削減する力のこと

パーティでカレーを作る二人の寓話から見えてくるのは、開発現場でよくある光景です

ボブとエバはろくに話し合わずに作業分担し、それぞれが自分の役割に思考を閉じてしまった

レシピが曖昧で、途中でターメリックライスに変更

結果的にパーティは興ざめに終わります

他人は自分ではないという厳然たる事実

自分が理解していることを他人は理解していない、その逆もまた然り

コミュニケーションとは、この不確実性を減らしていく行為です

外向的であることや空気を読むことではありません

透明性や心理的安全性も、コミュニケーション不確実性を削減しやすくするアーキテクチャ

対人リスクを取るハードルの低さと多様性の受容が必要不可欠
https://t.co/4febaQerU2
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

技術選定で失敗したくないという気持ちは誰にでもあるもの。でも実は、プロジェクトの規模によって検討にかける時間の適量は全く違う。

1万行程度なら深く悩む必要はないが、1000万行級だと全工数の半分を設計検討に費やしても妥当。バリーベームの調査データが示すこの事実。

新しい技術を使いたいというエンジニアの気持ちも大切だし、それが学びにつながる。ただし、その技術選定のツケを払うのが自分以外の誰かになる可能性は常に意識しておきたい。

課題をオニオンモデルで整理すること。社会、ビジネス、システム、ソフトウェアという階層で問題を捉える。影響範囲が広い意思決定ほど、外側の層まで考慮が必要。

ライブラリとフレームワークの違いも重要。ライブラリは自分が呼び出すもの、フレームワークは自分を呼び出すもの。フレームワークの方が交換困難性が高い。

ペースレイヤリングという考え方。変化のスピードが違う層を分けて設計することで、システム全体の柔軟性を保つ。
https://t.co/pk0kqXAdW2
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

技術的負債という言葉を聞くとつい「古いコードが悪い」と思いがちですが、本当の問題はそこではありません。

年間12兆円もの経済損失をもたらす技術的負債の正体は、実はコミュニケーションの分断にある。

エンジニアにはCTスキャンのように内部構造が見えているのに、ステークホルダーには表面しか見えない。この情報の非対称性こそが問題を致命的にしている。

重要なのは「ソフトウェアコントローラビリティ」という視点。つまりビジネス要求に対してリーズナブルなコストで変化し続けられるかどうか。

古いシステムでも適切なスキルを持つエンジニアがいれば制御可能だし、新しいシステムでも属人化すれば簡単に制御不能になる。

最新技術でゼロから作り直したい気持ちもよくわかりますが、それは大抵の場合、以前の累積工数を圧倒的に短い工期で再現するという無謀な挑戦になってしまう。

技術の問題として捉えるのではなく、ソフトウェア開発という経済活動全体をどう経営するかの問題として向き合うことが、真の処方箋となります。
https://t.co/W6u8fAwYOU
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

SNSでよく見かける「プロならモチベーションで仕事をするな」という言葉。

そこで語られる「モチベーション」って、まるで朝の気分や天気のように日々変わる表面的なものとして扱われがちです。

でも心理学が定義する本来のモチベーションは、そんな薄っぺらなものじゃない。

自己決定理論では、自律性・有能感・関係性の三つが満たされて初めて人は主体的に動けると説いています。

裁量が奪われ、成長を感じられず、周囲とのつながりもない環境で、どうやってやる気を出せというのでしょうか。

期待-価値理論や目標設定理論を見ても、モチベーションは価値観、報酬設計、自己効力感、社会的文脈が複雑に絡み合った動的なエネルギー。

組織がこうした構造を整えずに「気分に流されるな」と叫ぶのは、エンジンに燃料を入れずアクセルを踏むようなもの。

言葉は思考を導くハンドル。

ずれた定義を使えば、解決策もずれてしまいます。

次に誰かが「モチベーションに頼るな」と言ったときは、こう言い換えてみてください。

「気分に左右されないために、動機づけの構造をしっかり整えよう」と。

#NewsPicksトピックス
https://t.co/y0znHuCmp9
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

技術キャッチアップに追われる日々、本当に疲れませんか

新しい技術を学ぶことが義務になってしまうと、本来楽しいはずの学習が苦痛に変わってしまう

大切なのは課題意識を軸にすること

解決したい問題があった時に「そういえばあの技術が使えるかも」と思い出せる程度で十分なんです

流行のGet Startedチュートリアルを追いかけるより、なぜその技術が生まれたのか、どんな課題を解決しようとしているのかという本質を理解する方がずっと価値がある

自分だけの研究テーマを持てば、新しい技術も冷静に判断できるようになります

すべてを知る必要はありません

#NewsPicksトピックス
https://t.co/BBlRbJn7Gk
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

技術的負債という言葉は、エンジニアと経営者のコミュニケーションのために生まれたはずなのに、むしろ断絶を生んでいることがある

本質は情報の非対称性

エンジニアはCTスキャンのように内部構造を見ているが、非エンジニアは外側からしか見えない

この認識の差が、開発速度の低下という現象を巡って様々な誤解を生み出している

シュミットの定義では、技術的負債は理想システムと現実システムでの機能追加コストの差で表現される

しかし重要なのは、技術的負債とは単体で存在するものではなく、新たに追加したい機能があって初めて成立する概念だということ

クイック&ダーティという考え方も神話に過ぎない

綺麗さと速さは本来トレードオフではなく、プログラマーの思考過程の問題

時間をかければシンプルになるものでもない

見えてしまえば技術的負債ではない

正体の見えた問題は非機能要件として管理可能になる

ブレーメンの音楽隊の化け物のように、正体がわからないから恐ろしく見えるだけ

結局、技術的負債論の核心は組織のコミュニケーション課題

アーキテクチャの資本コストという考え方で、より建設的な議論ができるようになる
https://t.co/luTO0xkw0b
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

機能を追加するたびにソフトウェアが複雑になっていく。

この現象の根本原因は、要求に隠れた「意図」を見逃していることにあります。

プロダクトバックログにWHYを書くのは、単なるコミュニケーション補完のためではありません。その意図こそが、実装すべき抽象構造を発見するヒントになるのです。

例えば「利用アカウントはメールアドレスと電話番号を持つ」という要求。これをそのまま実装すると、後から「LINEアカウントも追加したい」という要求が来たときに破綻します。

しかし意図を探ると「最低1つは連絡先が欲しい」という本質が見えてきます。すると「連絡先」という抽象が生まれ、拡張に強い設計になる。

これは存在論的抽象ではなく目的論的抽象の話。「シャケ」と「豚」から「今日の夕飯のメイン食材」を見出すような、問題領域で事後的に発見される抽象構造。

仕様の直交性も同じです。機能同士が無関係に動作できれば、複雑性は掛け算ではなく足し算でしか増えません。しかし直交性の低い仕様では、組み合わせが爆発的に増大してしまう。

映画館の料金表で考えてみると、50通りのパターンに見えますが、実際には「基本料金」「顧客区分割引」「時間帯割引」という3つの直交した意図の組み合わせなんです。

隠れた意図を発見することで、複雑な要求をシンプルな直交構造に分解できる。これが拡張性のあるソフトウェア設計の出発点だと思います。
https://t.co/eEPnfkbIyD
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

AIで業務を効率化するという発想そのものが限界に来ている

多くの企業でエンジニアがAIエージェントを使って生産性を2倍にしようと試みても、意思決定の密度が高くなって疲労感が増すだけ。会議の合間にAIに指示を投げて確認する作業に追われ、集中できる時間はむしろ減ってしまう

問題の本質は「今の仕事をAIでどう効率化するか」という発想自体にある

必要なのは「やること自体の再構成」という根本的な思考転換だ。レガシーシステムの移行やユニットテストの追加といった従来の大工数作業を、一つの指示で複数のサブタスクが自動実行される仕組みとして設計し直す。さらには外部APIの変化を自動監視し、WebサイトからJSONデータを自動更新するような手離れする仕事を作り出す

最終的にはプロダクト自体に価値創造プロセスを内蔵し、ソフトウェアの修正ではなく、プロンプトやデータの修正で対応できる自働化を実現する

しかし大きな課題がある。AIで業務効率化しても「みんなが少し楽になって終わる」ことが多いのだ。議事録の自動作成ツールを導入しても人件費は減らない。改善した生産性はどこかに消えていく

だからこそ先進企業ではAI推進部門と人事戦略部門を統合している。生産性向上を事業成果に変換するには必ず人事異動が必要だからだ。2年後にこの事業の人員を半分にするという大胆な目標を先に決め、そのためのAI活用を進める。この順序が重要

私たちはAIと争っているのではない。AIを使う競合と競っているのだ

#NewsPicksトピックス
https://t.co/GppV0yZ40Y
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

会議で緊張してしまう人の多くは、その場の説明力が問題なのではない。

実は事前の準備不足が原因なんです。

エンジニア系の人がよくやりがちなのは、説明が下手だと言われたときに説明量を増やそうとすること。でも相手が求めているのは、判断材料と選択肢、そして推奨案が揃った状態での相談。

準備の質が会議の成否を決める。

#NewsPicksトピックス
https://t.co/waLEmd43iS
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

以前の登壇の書き起こしなのですが、技術選定で後悔しない原則についてお話しした内容です。

技術的負債って古いシステムのことだと思われがちですが、実は違う。本質は組織が必要な速度でソフトウェアを交換する能力を失うこと。

アーキテクチャには見えない権力が宿っている。何かを選びやすくし、同時に選びにくくする力。この力の源泉は依存性と交換可能性の関係にあります。

不確実性を完全に先読みするのは不可能。すべてを柔軟に設計しようとすると実用性を失う。大切なのは「何をしないのか」を決めること。そして「何を容易にするのか」を同時に決める。

目的と手段には階層構造がある。一般的に目的は変化しにくく、手段は変化しやすい。この変化のペースの違いを捉えてレイヤリングする考え方が重要。

ソフトウェアコントローラビリティの不等式という概念を提唱しています。ライフサイクル、依存性、交換リスクの積が組織ケイパビリティを下回る限り、そのリスクは許容できる。

技術選定で最も重要なのは、失敗をリカバリできる体制やチームを作ること。意思決定の経験を正しく学び、未来のチームメイトに配慮する姿勢が欠かせません。
https://t.co/Qn37t9cWrJ
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

プラットフォーム戦略って結局は資源調達の手段なんですよね。

スタートアップの事業計画でよく見かける「将来はプラットフォームに」という話。でも多くの場合、なぜプラットフォーム化するのかの解像度が低い。

フランチャイズと同じ構造です。直営店の方が利益率は高いのに、なぜわざわざフランチャイズにするのか。それは店長や不動産といった資源調達が成長のボトルネックになっているから。

今の時代、お金よりも資源調達の方が難しい。

Appleがすべてのアプリを内製すれば売上の30%ではなく100%を取れる。でもそうしない理由は、開発リソースや事業アイデアを外部から調達したいから。成長速度を優先している。

闇雲にプラットフォーム化を目指すのではなく、自分たちが何を提供できて、どんな資源を呼び込みたいのかを冷静に見極める。そこが戦略の出発点。

#NewsPicksトピックス
https://t.co/eSxLWIUv1t
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

問題解決のお手伝いをしていると、自分で問題を難しくしている人によく出会います。

隣のチームリーダーとの関係がうまくいっていないだけなのに、「チーム間連携をスムースにするフレームワーク」という難しい問題に変えてしまう。エンジニアは特にこの傾向が強い。

数学でも同じです。x^2-4=0なら簡単に解けるのに、ax^2+bx+c=0に一般化すると解の公式が必要になり複雑になる。

でも実は、個別の問題をシンプルに解いてから一般化する方が効果的なんです。

隣のリーダーとギクシャクしているなら、まずはちゃんと話してみる。それだけで解決することも多い。お互いの勘違いや価値観のギャップが分かれば、自然と関係が改善したりします。

x^2+4x+1=0も、解の公式を使わずに平方完成で(x+2)^2=3の形に持ち込めば、使い慣れた方法で解ける。

問題は一般化するな。解法を一般化してみろ。

エンジニアリングの基本はDivide and Conquer。問題を分割して、個別化して、簡単化してから解く。メソッドや公式に拘泥すると、目の前の問題を難しくしてしまうだけです。

#NewsPicksトピックス
https://t.co/DudA8FlTve
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

機械学習プロジェクトの失敗は技術的な問題より、むしろマネジメントの問題であることが多い。

PoCで終わってしまうプロジェクトに共通するのは、モデルの性能だけに注目して実運用の現実を軽視すること。エッジでの計算量制約やデータドリフトへの対応、そして何より事業価値の継続的な検証が抜け落ちている。

シンプルな手法で十分な精度が出るケースでも、過度に複雑なアプローチを選んでしまう技術者の性。

重要なのは、MLエンジニアだけでなくビジネス担当者も含めた共通言語の構築。そして継続的なモニタリングによる自動アップデートの仕組み。

技術的実現可能性と事業価値を同時に検証できるプロジェクト設計こそが成功の鍵になる。

#DXCriteria
https://t.co/XQ9LmNogWH
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

フロー効率とリソース効率という2つの効率性があります

リソース効率は人が遊びなく稼働している状態を重視します。一方でフロー効率は価値を届けるリードタイムを重視する

コンビニで例えると、行列のないレジは客にとって嬉しいがスタッフの稼働率は低い。行列の長いレジは売上効率は良いが客の待ち時間は長くなる

ソフトウェア開発でも同様です。リソース効率重視ならプロジェクト型でスペシャリストを必要なタイミングで動員する。フロー効率重視なら固定チームで価値の小さな単位を継続的にリリースしていく

でも、リソース効率の世界から見るとフロー効率の取り組みは「もったいない」と映ってしまう

設計もできる高単価の人に実装をお願いしたり、フロントエンドエンジニアがバックエンドも触ったり。専門性を活かしきれていないように感じられる

しかし変化の早い現代では、素早い仮説検証や競合への対応スピードが価値に直結します

重要なのは二項対立を超えて効率フロンティアを見つけること。まずは片方の効率性を体験的に理解してから、段階的にもう一方も取り入れていく

異なる価値観の文化を創ることこそ、チームで仕事をする最大の意義なのです
https://t.co/QzyGlCGQpQ
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

エンジニアのパフォーマンスを妨げるもの、それは「集中の阻害」です

睡眠不足、寒いオフィス、突然の会議、通勤ストレス。これらすべてが私たちの集中を奪っている

リモートワークは、その「快適な状態」を確保するための有力な手段だと考えています

重要なのは、業務の95%がリモート環境からアクセス可能であること。一時的な対応策ではなく、常用可能な働き方として機能するかどうか

しかし落とし穴もあります

PCの起動時間で業務を監視したり、リモートワーカーとオフィスワーカーの間に情報格差が生じたり。オフラインに固執するマネージャーの存在も課題です

リモートワークの成功には、アウトプット重視の評価と情報の透明性、そして新たなマネジメントスタイルへの適応が不可欠

自由と効率性を提供する一方で、それをサポートする工夫が求められる働き方。その本質を理解することが成功の鍵になります

#DXCriteria
https://t.co/zYqMAzDsqU
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

セキュリティは守るだけでは不十分な時代になった

シフトレフトやゼロトラストといった概念が生まれているのも、従来の境界防御だけでは開発生産性が犠牲になってしまうから

デジタル人材が最も重視するのは使いやすい開発環境。ガチガチのファイアウォールに阻まれた環境では、優秀な人材は集まらない

攻めの組織と守りの組織の価値観の不一致

これを解決するには、セキュリティ担当者も事業や生産性改善を評価軸に含めること。対話なくしてイノベーションは生まれない

#DXCriteria
https://t.co/l8r5zSEKSJ
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

「業務効率化」って発想が
AI活用を狭めてる気がしてる

議事録を要約しても
仕事が終わった感じがしないのは
人間を挟んだ瞬間に
フローが止まってるから

必要なのは既存業務の効率化じゃなく
仕事そのものの再定義

価値提供までのフロー全体を見直して
自分の仕事の範囲を
与えられたものじゃなく
価値から逆算して決める
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

AIとの協働で感じる疲労感の正体は、
私たちの役割が「作業者」から「マネージャー」に変わったからです。

プロンプト設計、出力評価、指示出し...
絶え間ない意思決定は有限リソース。

これはHPではなくMPを消費し続ける状態。
新技術は常に職務の高度化をもたらしてきました。

働き方そのものの再設計が必要です。
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

AIツールを使っているのに仕事が変わった実感がない理由。それは業務効率化という発想自体に限界があるから。

議事録要約やタスク抽出を単発で使っても、人間を挟んだ瞬間にフローが止まる。人間の処理速度が遅くて並列処理もできないため、価値提供までのリードタイムが長くなってしまう。

問題は「開発業務」と「それ以外」に区分してしまうこと。でも本当は、要件定義からデリバリーまで全てが価値提供に向かう一本の流れ。開発業務以外なんて存在しない。

仕事の範囲は与えられるものではなく、価値から逆算して自分で決めていい。

必要なのは既存プロセスの効率化ではなく、仕事そのものの再定義。AIは単なるツールではなく、これまで不可能だった価値提供を可能にする存在です。

#NewsPicksトピックス
https://t.co/SxmI7OoMz9
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025

エンジニア採用でよく聞く
「誰かいいエンジニアいませんか？」

この一言で候補者は
「私を個人として見てくれるのか？」
と疑問に思う。

優秀なエンジニアは選ぶ側にいる。
彼らが求めているのは

「あなたのこの経験を
うちのこの課題で活かしてほしい」

という具体的なメッセージ。

一人ひとりの経験や関心に
深い関心を示すことから始めよう。
--
『AIエージェント　人類と協働する機械』Kindle版も発売開始
https://t.co/ID5r1mMgPT December 12, 2025