言語モデルの物理学 (Physics of Language Models) とは、FAIR (Meta) の Zeyuan Allen-Zhu が提唱した、言語モデルの研究を進めるためのコンセプトです。ざっくり言うと、「あのモデルはこう」とか「そのモデルはこのモデルよりもこう」というような博物学的な知識を深めるのではなく、17世紀にケプラーやニュートンが物理学において行ったような原理に基づいた研究を進め、「言語モデルはなぜこのような振る舞いをするのか」という問いに答えられるようになるべきという考え方です。 言語モデルの物理学の特徴は大きく2つあります。 第一は、ウェブから収集したコーパスを使わず、きっちりコントロールされたデータセットを使って言語モデルを訓練するということ。ウェブは誰も全体像を理解できないほど複雑で、ノイズにまみれています。本物の物理学でも空気抵抗や摩擦があると、「鉄球は

はじめに こんにちは！今回は、私が最近開発した tfmcp というツールを紹介します。これは Terraform を LLM（大規模言語モデル）から操作できるようにするツールで、Model Context Protocol (MCP) を活用しています。 github.com このブログが良ければ読者になったり、GitHub リポジトリにStarをいただけると開発の励みになります。nwiizoをフォロワーしてくれるのもありがたいです。より良いツール開発のためのフィードバックもお待ちしています！ MCP とは何か？ 記事を始める前に、まず MCP (Model Context Protocol) について簡単に説明しましょう。MCP についてより詳しい情報は、公式ドキュメント modelcontextprotocol.io や Anthropic の Model Context Protoc

「エンジニアの管理職」の時代 かつては「課長/部長/リーダー」とだけ呼ばれていた。 「とりあえずマネージャやってね」の時代 マネジメント職になりたがらない技術者たち。 技術の現場から離れるとおいて行かれるのではないかという恐怖。 役割定義があいまい。各社で異なる状況。 ポータブルスキルが身につかないのではないかという懸念。 エンジニアリングマネージャーの登場 2018年頃から「エンジニアリングマネージャー（EM）」という肩書きが普及 人材育成・技術戦略・プロジェクト管理・プロダクト連携の専門職 ジョブディスクリプションや求められる知識・スキルも次第に明確に。 エンジニア"リング"マネージャ エンジニアのマネージャ EMコミュニティの活性化 2018年頃より活発化 EM Meetup（毎回多くのEMが参加） EM.FM（累計再生数10万回超） Engineering Manager Adve

Artifacts are user-generated and may contain unverified or potentially unsafe content.

Hiroya Iizuka @0317_hiroya 最近やっている、第二の脳とAIを融合したワークフローの流れ - DeepResearch(Gemini, Genspark, ChatGPT)で、気になることを調べる - 出てきた資料を、全てNotebookLMへ移行 - よくある質問、ブリーフィングメモなどを作成 - Chat欄で壁打ち - Obsidianに、リンクを保存。 - 壁打ち内容で、Cornel Noteを作成 - 裏側に図解かく - Permanent Noteを切り分ける 順に説明します。 2025-02-17 09:10:24 Hiroya Iizuka @0317_hiroya Deep Research => 資料作成 Geminiは、Google Docが作成されるから、これをそのままNotebookLMが、読み込むことができる。 Gensparkは、Spar

GitHub Copilotの活用は、開発者の作業手間を軽減するだけではない。実際に、プルリク数が約26%増えたと言う1。これは、生成AIをソフトウェア開発に活用することで具体的にどのような効果があるのかを数値化した調査結果の1つだ。 "The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers" と題された論文がその出典元である。日本語に訳せば、『生成AIが高度技能職に及ぼす影響: ソフトウェア開発者を対象とした3つのフィールド実験によるエビデンス』といったところか。“3つのフィールド実験” とは、マイクロソフト、アクセンチュア、フォーチュン100に名を連ねる匿名の電子機器製造企業での実験を指している。 本稿は、この論文を

仕事では日々の忙しさに追われ、根本的な問題解決に手が回らないことがよくあります。 やらなきゃいけない大切なことがある。でも、日々の業務が忙しくて着手できない…このような問題を『樵きこりのジレンマ』と呼びます。 昔々、樵きこりが木を切っているところに、旅人が通りがかりました。 ある樵きこりが、必死に木を切っていました。 そこへ通りがかった旅人が、 樵きこりの斧は長く手入れがしてないようで、刃がボロボロです。 これでは切れるわけがありません。 旅人は見かねて「そんな斧では仕事ができなかろう。斧を砥といだほうがいいのでは？」と、樵きこりに助言をしました。 すると樵きこりは、答えました。 「そんなことは知ってるよ…でも、今日の仕事が一杯で、それどころじゃないんだ」中長期で考えれば、未来への投資をするほうが正しいのに、短期視点では現在の作業に全リソースを投入せざるをえない。 いわゆるパラドックスの一

振り返るのは、とある３連休直前の金曜日ーーー。 その日、最後のMTGは当社の取締役メンバー間での役員MTGだった。 詳細はさておき、アジェンダは決して軽いものではなく、議論の末に一定の解決が見えたので、私は安堵のため息を心の中でついた。 《ふぅ…これで安心してこの連休を迎えられる》 と。 MTGの最後、1人の取締役から私宛に「フィードバック」があった。 端的に言うと、私の管掌範囲におけるキャッチアップ不足を指摘するフィードバックだった。大変的を得たフィードバックだったので、私はその場で素直に感謝し、以後気をつける旨を話したと思う。 MTGを終え、その日の仕事もいつも通り切り上げ、家族との時間を迎えた。 するとどうだろう。子供を風呂に入れ、食卓を囲んでいても、気がついたらその日最後のMTGで受けた「フィードバック」のこと考えている。 実際、取締役間に限らず、当社のメンバー含めて「フィードバッ

これまでC向けサービスを作り続けて15年が経過しました。 このnoteは「課題を解決し、事業としてスケールするプロダクトを創る」ために自分が考えてきたことを改めて体系立てて、言語化したいなと思い書き残しています。 同時に以下のように機能することを目指しました。 自身のプロダクト開発の知識を集約させる プロダクトに関わる人にとって教科書的に振り返ることができる スマートバンク社のプロダクトの再現性が伝わる 学びに終わりはないので、このエントリー自体も更新し続けるようにしたいと思います。 1.サービスを作る前の心構え俺が考えた最強のサービスを作らないスタートアップで何よりも回避すべきは、長い労力を掛けて作ったプロダクトを「誰も欲しがらない」こと 作り手の思い込みの「仮説」は現実の誰かの問題を解決するとは限らない 頭の中にある架空のユーザーに対してプロダクトを作った結果、実際に市場では「使われな

プロダクトマネージャーカンファレンス 2023 Track A 15:35~ LIVE 50min プロダクトと事業を無限にスケールするための最強のロードマップの作り方 https://2023.pmconf.jp/session/zBfEEEcp 近年、多くのプロダクトマネジメントに関する…

記事タイトルに「たった一つのコツ」と挙げているくせに、さらに別のコツを挙げるのはロジカルにどうなのか？という反論はさらりと横に受け流して、この記事では「もう一つのコツ」についてお話ししたいと思います。 それは「人選」についてです。 人選　プロジェクトの成否の50％はここで決まる著述家のジム・コリンズは、彼の著書「ビジョナリー・カンパニー２」において、人材と経営計画の関係について、次のように指摘しています。 一般には「良い経営計画があって、それに沿って適した人材が集められ、結果として事業が成功した」と考えられているのに対して、成功した事業では多くの場合、「まず優秀な人材が集まり、その人々がああだこうだと議論しているうちになんとなく計画が固まっていき、結果として事業が成功している」ことを指摘しています。 ジム・コリンズ「ビジョナリー・カンパニー２」コリンズはこの発見を、「行き先を決め、そのあと

TL;DR（前編のみ） 「リソース効率重視」、「フロー効率重視」と呼ばれる開発スタイルは、それぞれソロ開発（個人分担制）とアンサンブル開発（1つのタスクを複数人で協働する方法）を指すのが一般的 短期的には、ソロ開発はスループットの高さ（開発アウトプットの総量）、アンサンブル開発はリードタイムの短さ（1タスクが完了する速さ） に長所がある どちらがいいかは状況次第だが、アウトプットでなくアウトカムを見て判断すべき 目次 TL;DR（前編のみ） 目次 僕はなんでこれを書いているのか 2つの開発スタイルについて 比較ポイント 短期的な比較：スループット vs リードタイム 2つの開発スタイルを比較してみる 結局どっちがいいの？ アンサンブル開発に関する補足 ここで思考を止めないで 僕はなんでこれを書いているのか アジャイルで開発やっていると、度々「フロー効率重視」という言葉が聞こえてきます。しか

こんにちは。現在プロダクトマネージャー兼ソフトウェアエンジニアとしてfreee人事労務の開発を行っている金山（@tkanayama_）です。私は現在、労務担当者の勤怠締めにまつわるペインを解消するための「勤怠モニター」という機能を開発しており、この開発を通して特にプロダクトマネージャーとして様々な学びを得ています。今回はその中から、「スコープの絞り方」について考えたことを整理します。 時間・予算・品質・スコープのトレードオフ プロジェクトにおいて、時間・予算・品質・スコープはトレードオフの関係にある場合が多く、私も日々このバランスに頭を悩ませています。 これについて、書籍「アジャイルサムライ」では以下のように主張されています。 時間と予算、それから品質は固定されたものとみなし、スコープを柔軟に扱うのだ。 たしかに実体験としても、苦渋の決断としてスコープを切り詰めざるをえない場面が多いように

はじめに 最初はなんとなくで書いていたDockerfileなのですが、社内用にベストプラクティスを整理するタイミングがあったので、実際にNode.js + TypeScriptでアプリケーションを作成しながらまとめることにしました。 この記事でフォーカスするのは、 Dockerfileのベストプラクティスそのものの詳細ではなく、それらを整理と「結局どう実装すんねん？」ってところです。 主に以下の内容を参考にしています。 想定読者 Node.jsにおけるDockerfileのベストプラクティスの具体を知りたい方についてはピッタリだと思いますが、その他の言語でも参考になる部分はあると思います。 本記事では、各用語やベストプラクティスの詳細は記載しませんが、該当箇所へのリンクを載せているので必要に応じて参照してください。 また、この記事に書いていない内容で、上記3つの記事に書かれているベストプラ

視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「

成人発達理論というジャンルがある。ここ半年くらいハマって調べていた。ここ数年の自分の変遷にピタリと当てはまっていてずいぶんと面白かった。 この「発達段階」というものがいわゆる「視座」にかなり近い概念なのではないかと思い、今日は紹介してみる。スライドも作ったのでスライドが好きな人はコチラもどうぞ 視野・視座・視点ずっといまいち意味がわからなかったのだが、成人発達理論を学んだ結果、「視座」という単語の意味が自然と理解できるようになった。 学んだ結果として得られた言葉の意味は「自身の価値観から離れ、より広い対象を主語にして見る俯瞰的な観点」という非常にメタなものであった。視座が上がるとは ✕ : 「見えるものが広がる」というシンプルな変化 ◯: 不可逆な思考パラダイムの遷移 であり、「前の自分を失う」ような要素を含むのではないかと思う。抽象的すぎるので詳しく見ていこう。 成人発達理論とは簡単にい

はじめまして、asachiです。 普段はプロダクトマネージャーとかデザインとかをやっています。 最近、会社・事業のインフラコストをどう評価するかという話に社内でなって、実際各企業どんなもんなんだろうなと気になり、IR資料から頑張って漁ってきました。 せっかく色々と見たので、気になった事例等含めて書いていこうかなと思います。 TL;DR 上場企業のインフラコストを調べた 規模・業態問わずで30社くらいのデータを発掘できた 最もコストがかかっていたのはゲーム会社アカツキ約11-12億/年 次点はツイキャス運営のモイ 約5.8億/年 「メメントモリ」が流行ったため、BANK OF INNOVATINが直近四半期でサーバー費用が3億円/四半期(前年同期比1,153%)になっていた 各種会計項目に対してサーバー費の比率が安定しているのは、GunosyとGameWith 売上原価に占める割合が高いのは

会社組織の中でどう動くことが「良い仕事」なのか。 LayerX のエンジニアリングマネージャー、「あらたま」さんこと新多真琴さんにマネジメントや日々の仕事で意識していること、実践している勘所などをお聞きしました。 マネージャー職ではない人が読んでも学びのある内容になっていますので、ぜひ最後のまとめまでお読みいただければと思います。