iwashi / Yoshimasa Iwase
@iwashi86
NTTドコモビジネスでEM(育休中)。その他、早稲田大で非常勤講師、#fukabori#.fmの中の人、書籍翻訳者。
AI、マネジメント、Dev、PdM、Agile、HRに関する個人メモをポストしています。
発言は個人の見解であり、所属する組織の公式見解ではありません。
Amazonアソシエイト・プログラム参加者。
694 フォロー中 20.4K ファン
この外側のループがすべて。いかに内側が高速回転していても、外に波及しなければ顧客価値につながらない。
カンファレンスで登壇者に対して「発表が良かった」と直接伝えるといいよという記事だった。
・カンファレンスで登壇者に話しかけたいと思いつつ、気後れする参加者は多い
・会話に付け足せるような大した話題がないからと遠慮してしまう
・この記事の筆者自身も登壇やMCを経験しているが、他の登壇者に声をかける際は今でも緊張する
・ただ、ステージに立った側の人間も発表直後は強い不安を抱えている
・頭の中は言い間違えた箇所や、完璧にできなかった反省点ばかり
・かつてのようにSNSで感想が流れてくることも減り、無反応に終わるケースも珍しくない
・フィードバックが何もないと、受け入れられなかったのでは、と不安になる登壇者は多い
・友人同士であっても、最前列で応援しているから伝わっているはずと思い込み、直接褒めるのを忘れがち
・しかし、実際には言葉にして直接伝えない限り相手には届かない
・登壇者は膨大な労力をかけて準備している
・で、楽しんでもらえたかを知りたがっている
・深い議論は必須じゃない
・すれ違いざまに「良かったです」と一言声をかけるだけで十分
・たとえ些細な一言であっても、直接伝えることに価値がある
もっと見る
社内プラットフォームを作ったのに誰も使わなかった、というあるあるな内容。
・記事の筆者は、8ヶ月かけて社内MLプラットフォームを構築した
・技術的に堅牢な基盤を作ったが、シニアエンジニアは誰も使っていなかった
・各自が自作ツールや手作業に頼り、プラットフォームを回避していた
・なぜか？
・現場にとっては、使い慣れた手順で納期を守る方が合理的だったため
・技術的な正しさとユーザー価値を混同し、設計者の理想を押し付けていた
・これは説明や研修の不足ではなく、現場からの信頼の問題
・そこでプラットフォーム担当者を現場の開発スプリントに6週間送り込んだ
・そこでは、売り込みではなく観察に徹した
・で、現場がどこで詰まっているかを特定した
・さらにロードマップを公開し、機能の優先順位を現場に委ねた
・すると、開発側のトップ3の優先項目は、現場のトップ10にすら入らないことがわかった
・リリースと現場の定着は別の成功基準であると認識を改めた
・具体では、機能説明ではなく現場の疑問に答える実務ハンドブックを作った
・最初のモデルを1日で本番デプロイできる状態を目指した
・その上で、強制ではなく現場が自発的に選び直すことで、利用が定着していった
もっと見る
AIの利用コストが高騰しすぎたため、SAPが出張と新規採用を止めている、というポスト。
・SAPが、先月から出張と新規採用を大部分で止めている
・例外として認められるのは、AIに関連する出張や採用のみ
・7月に報じられた凍結措置だが、社内では現在も継続中とのこと
・ある従業員によれば、新しい社内向けAIツールの全社展開がコスト爆増の要因になっているらしい
（残りはペイウォールで読んでおらず）
もっと見る
AIツールを使っても、良いソフトウェアを作るには開発者自身の技術理解と判断力が不可欠だ、という主張記事だった。
・ただフライパンに肉を置くだけのステーキ調理に、スキルはほとんど要らない
・だが、本当に美味しいステーキを安定して焼くのは非常に困難
・AIを使った昨今のソフトウェア開発も、これと同じ状況になりつつある
・誰もがAIに指示を投げ、想像通りの完璧なソフトウェアが出てくることを期待している
・しかしAIは熟練のシェフではなく、単なるレシピ実行機にすぎない
・運が良ければAIは素晴らしいコードを出力してくれる
・ただ、堂々と黒焦げの炭を出して「これはミディアムレアだ」と言い張ることもある
・これで困った人は、高価なAIプロダクトや新しいフレームワークに課金して解決しようとする
・しかし、そうしたサービスの裏側でも結局は同じAIが料理をしていることが多い
・AIは反復作業を自動化し、開発を大幅に高速化できる
・一方で、品質を定義し、トレードオフを判断することはAIにはできない
・技術的には正しくても本質的に間違っているコードを見抜くのは人間の役割
・結局のところ、望む結果を安定して得るには、自分自身でソフトウェアを深く理解して学ぶしかない
もっと見る
技術のエキスパートから組織のリーダーへ移り変わる際の難しさと、その乗り越え方をまとめたIEEEのポスト。
・STEMのキャリアにおいて、純粋な技術者からリーダーへの移行は最も困難なフェーズの一つ
・なぜかというt、技術的な卓越性への依存から離れ、システム思考やチームの連携を習得する必要があるから
・エンジニアの意思決定は、それ単体で完結するわけではない
・自分の技術的な選択が、組織のビジネスや運用の現実とどう関連するかを認識しかねばならない
・そのためには、自分が唯一の技術の専門家であるという固執を捨てる
・代わりに、コラボレーションを促進し、取り組みを組織の戦略と一致させることに注力する
・また、指示を待つのではなく、自律的なビジネスオーナーのように振る舞うことが求められる
・与えられたタスクを実行するだけでなく、組織に価値を生み出す隠れた領域を積極的に発見していく
もっと見る
Cloudflare OS、本当にいいところをついてくる。さすが。
・Cloudflareが自社向けに構築したAIワークスペースをOSSとして公開
・全従業員が社内の文脈やツールにアクセスできるエージェントを持つための基盤
・すでに社内で数千人が利用し、資料作成やタスクの自動化に活用している
・チャットを通じたリサーチだけでなく、業務アプリの構築も可能に
・エージェントがクライアントとサーバーのコードを書き、独自のアプリを生成する
・アプリの実体はDynamic WorkerやDurable Object Facetとして動作
・生成されたアプリはチーム内で共有でき、各々がAIを使ってさらにカスタマイズできる
・エージェントへのAPIキーの直接付与は危険であり、またスケールしない
・MCPを利用すればツール呼び出しの制御自体は安全に行える
・ただ、MCP単体ではエージェントがどの機密データを閲覧したかの追跡が不十分
・そこでGatekeeperと呼ばれる仕組みを間に挟んでアクセス制御を実現している
・機密データを読み取ったエージェントは、その後の共有や外部通信が自動で制限される
・これにより、生成されたアプリ経由でのデータ漏洩をシステム側で防ぐことが可能に
・推論には組織が許可した任意のAIモデルを組み合わせて利用できる
・Cloudflare AI Gatewayを経由させることで、高価なモデルの使いすぎやコストを制御できる
もっと見る
IIFE、めちゃくちゃ懐かしい。以前に書いた即時実行、いつだったかもう覚えてないわ。
90% vibe coder will fumble during interviews if asked what this is
これも実体験上わかるところ。
インセプションデッキに限らず、KPIツリーだったり、チームで大切にしていることの言語化だったり、話すこと自体に大変価値がある。
もっと見る
コストが100分の1の安価なオープンモデルを事後学習し、検索タスクでGPT-5.6 Solと同等の性能を出す手法を述べている。（プロダクト宣伝の記事でもあるので、そこは注意）
・かつてのRAGは単発検索だった
・だが、現在はエージェントが自律的に検索を繰り返すアプローチへ移行している
・ただ、GPT-5.6 Solなどの最先端モデルでこれを行うと、1リクエストに10秒以上かかりコストも高すぎる
・一方で、100倍安価なオープンモデルはそのままでは推論能力が足りない
・そこで、検索などの特定タスクに特化し、オープンモデルを強化学習で事後学習させるアプローチが有効
・記事中では、開発したCastformを使っている
・で、社内の既存ドキュメントから学習用タスクを自動生成した
・学習時にはAIが検索を何度も繰り返すため、数千の並列タスクが走りデータベースに瞬間的な高負荷がかかる
・ここはNeonの動的なオートスケーリングを利用し、スパイク負荷を効率的にさばいて対処した
もっと見る
日経BP社からSteve Yegge氏らが原著の翻訳書籍
『バイブコーディング 生成AI→チャット→エージェントによる「本番品質のソフトウェア」の未来』
をご恵投いただきました！
同氏のブログはたまに読んでいることもあり、書籍の中身の楽しみです！
購入リンクはこちらから：
もっと見る
AIコーディングツールの指数関数的なコスト増をいかにコントロールしていくかについてのdatabricks記事。（一部引き算して読む感じ）
・AIコーディングツールは生産性を劇的に向上させる
・しかし、それに伴ってコストも指数関数的に増大している
・放置すれば、AIによる恩恵がコストで相殺される
・そのため、最高性能ではなく、コスパに優れた効率性フロンティアの追求が必要になっていく
・具体的な対策の筆頭は、より安価で効率的なモデルへの移行
・特定のモデルへの依存を防ぐため、メタハーネスを導入して柔軟性を確保する
・また、タスクの難易度に応じて安価なモデルと高性能モデルを動的にルーティングする手法も有効
・予算管理において、利用上限でアクセスを完全に遮断するのは悪手
・これは、最も生産性の高い開発者の足を引っ張ってしまうため
・代わりにコストを可視化し、閾値を超えたら安価なモデルへダウンシフトさせる仕組みが望ましい
・さらに、不要なコンテキストを削ってトークン消費を抑えることも大事に
・また、プロンプトキャッシングを活用することで、コストを大幅に削減できる
（で、Unity AI Gateway というプロダクトの宣伝になるので、以下は略）
もっと見る
SON.stringifyとJSON.parseはデータを完全に再現できず、意図せず情報を失うことがあるよね、という解説記事。
（スキルは書籍を参照いただくとして）
これができる人材の希少性がすごくて、事業と組織を反復横跳びしつつ、価値提供に至るまでのボトルネックを見つけて潰せるマンは最強。
もっと見る
こういうCoding Agentの使い方は良いなぁ。
Lost my phone at the office and spent 30 minutes turning the place over. Find My was disabled by MDM.
Out of ideas, I asked Claude how I could find it. It suggested tracking the Bluetooth signal strength, then wrote me a meter in about a minute.
I walked around watching the number climb. Found it.
Apparently you can just make the tool you need now.
Code:
もっと見る
これは良い問いだ
実際に価値のあった自作の社内ツールは何か、を語り合うRedditスレッド。
人気のあるレスに
「開発チームに直接送られてくるプロダクト関連のメールをすべて、無人の受信トレイに転送するOutlookルール」
というのがあって笑った。
もっと見る
この引用部を見て、
の発表を思い出した。まさに行き来した事例。
ほんとそう
趣味の（ニッチな）プログラミングコミュニティが、なぜLLMの利用に猛反発するのか、について意見を述べているポスト。目的の違い。
・OSDevやLangDevなどのニッチな趣味界隈では、LLMへの敵意が高まっている
・ここでは、難しい分野を習得する学習プロセスそのものが目的だから
・単に「動くコード」を得ることはおまけに過ぎない
・界隈で尊敬されるのは、深いドメイン知識を持ち、仕組みを理解している人
・コードが動くことより、それがなぜ、どう動くのかを知っているかが重視される
・そのため、LLMで完成品を生成することは、ものづくりのプロセスを奪う行為
・ただ、学習自体が目的であるコミュニティにおいては、クラフトマンシップを奪う存在に
もっと見る
