タグ: #engineering
GPU・LLM・MLOps・Kubernetes、そしてマインドセット · 22 件
文章で説得する — 設計文書とRFCが通る構造
設計文書、RFC、提案書、障害後のフォローアップ勧告を書く人のための記事です。自分が問題を解いた順序ではなく、求める決定を一番前に置く方法、却下した代替案を示すことがなぜ提案書と広告を分ける唯一の目印なのか、何もしなかったときのコストをどう数字にするか、流し読みする決定者にどう向き合うかを整理しました。そして最も重要なこと、自分がいない会議で引用される段落をどう書くかを扱います。弱い提案の段落を一つ実際に書き直し、文書で実際に効く手を表
2026-08-02 · 27 分で読めます #career#writing#persuasion#design-doc#engineeringリファクタリングの経済学、コストはいつ回収されるか — 変更頻度で計算する方法
2026年7月30日にmartinfowler.comに掲載されたThe Economic Benefit of Refactoringは、約1万7千行のモジュールを15段階でリファクタリングしながら、同じ変更要求を毎回繰り返し実行し、入力トークンが159,564個から27,360個へと83パーセント減少することを測定しました。興味深い実験ですが、著者自身が単一の実験であり、グリーンフィールドのアプリ一つに限られると釘を刺しています。こ
2026-07-31 · 29 分で読めます #refactoring#engineering#technical-debt#ai#metricsAIでコードベースを移す実践手順 — 審判を先に立て、行数ではなくレビュー率を測る
2026年上半期に公開された大規模LLMマイグレーションの事例（53万5千行のZigからRustへ、16万5千行のPythonからTypeScriptへ）から共通の手順を抜き出し、実行可能な順序に整理します。核心は順序です — 翻訳を始める前に振る舞いのオラクルを立て、わざと壊したコードでそのオラクルが落ちるかどうかをまず確認します。そのうえで検証可能な境界で切ってキューを作り、完了判定をディスクの状態に任せてすべての工程を元に戻せるよ
2026-07-31 · 23 分で読めます #ai#migration#refactoring#testing#engineering教えるコードレビュー、傷つけるコードレビュー — 同じ指摘の結果を分けるもの
コードレビューには欠陥の発見、知識の伝播、コード所有権の共有という三つの目的がありますが、多くのチームは最初の一つだけをやって残り二つを取りこぼします。レビュアーは完璧を求める人ではなくコードが明確に良くなったかを判断する人だというグーグルの承認基準、強度を示す接頭辞が生む違い、観察と影響と提案に分けた文の構造、200から400行というPRサイズの通説の出所とその限界、往復を減らすPR説明、そしてレビューを受ける側の技術までまとめました
2026-07-26 · 21 分で読めます #career#code-review#engineering#feedback#teamworkシステム設計面接の準備法 — 正解ではなく「絞り込む過程」が採点される45分
システム設計面接に正解はありません。だからこそ採点されるのは「何を描いたか」ではなく「どう絞り込んだか」です。45分を5分・10分・15分・10分・5分に割る時間予算、メモリ参照から大陸間往復まで桁で覚えておきたい遅延の階層、DAU一つからQPSとストレージを導く概算、そして候補者が最も頻繁に崩れる4つの習慣を整理しました。最後に、減点ではなく加点になる「わかりません」の伝え方まで扱います。
2026-07-26 · 20 分で読めます #career#interview#system-design#engineering#job-search効果的なAIエージェントを作る — 5つのワークフローパターンとエージェントのリファレンス
Anthropicのエンジニアリングガイド「Building Effective Agents」を実務リファレンスとして整理しました。ワークフローとエージェントの正確な区別、すべての土台となる増強されたLLM(検索・ツール・メモリ)、そして5つのワークフローパターン(プロンプトチェイニング・ルーティング・並列化・オーケストレーター/ワーカー・エバリュエーター/オプティマイザー)を、それぞれの使いどころと具体例とともに扱います。自律エージ
2026-07-11 · 16 分で読めます #ai#agents#llm#engineering#anthropic科学者のようにデバッグする：仮説駆動デバッグ
バグをにらみつけてコードを手当たり次第に変える代わりに、科学者のように仮説を立て、予測し、実験で検証する方法。問題空間を二分探索で狭め、最小再現例をつくり、git bisectで犯人コミットを見つけ、エラーメッセージを実際に読む。推測を方法論に変える実践的デバッグガイド。
2026-07-03 · 26 分で読めます #debugging#engineering#productivity#fundamentalsフォワードデプロイドエンジニア（FDE）とは何か
Palantirが広め、いまOpenAIやAnthropicといったAI企業のソリューション組織で再び注目を集めるフォワードデプロイドエンジニア（FDE）の役割を整理します。顧客に張り付き、ソフトウェアエンジニアリング・プロダクト・ソリューション・少しのセールスとコンサルティングを混ぜ合わせ、顧客の本当の問題を最後まで解決する人。SWE・SE・PM・コンサルタントと何が違うのか、そしてなぜAIがFDEを再び必要にしたのかを見ていきます。
2026-07-02 · 14 分で読めます #career#engineering#fde他人が書いたコードの読み方
開発者はコードを書く時間よりも読む時間のほうがはるかに長い。ところがコード読解は誰も教えてくれない。エントリポイントを見つけ、すべての行ではなくデータを追い、テストと型をドキュメントとして使い、grepとIDEジャンプでコールグラフを描き、実際に動かしてprintを仕込み、何かを変えて何が壊れるかを観察する。見知らぬコードベースを素早く掌握する実践戦略。
2026-07-01 · 21 分で読めます #code-reading#engineering#onboarding#fundamentalsコードの名前付け：最も難しい簡単なスキル
「コンピュータサイエンスで難しいのは二つだけ、キャッシュの無効化と名前付けだ」という冗談は、半分は本気です。良い名前がなぜ実装ではなく意図を表すべきか、名前の長さとスコープの関係、ハンガリアン記法を避ける理由、検索可能性、真偽値・関数・コレクションの慣習、そしてリネームを一つのリファクタリングとして扱う方法までを整理します。
2026-06-30 · 16 分で読めます #clean-code#engineering#fundamentalsFDEプレイブック：使い捨てプロトタイプで勝つ
フォワードデプロイドエンジニア（FDE）が数日で顧客の実データの上で動くデモを作り、状況をひっくり返す方法。意図的で使い捨てにできる技術的負債、リスクを取り除くスパイク、いつハードコードするか、アハ体験までの最短距離、期待値のマネジメント、そしてプロトタイプからプロダクションへの移行まで。現場で検証されたFDEのプロトタイピング・プレイブックを整理します。
2026-06-30 · 16 分で読めます #engineering#prototyping#fdeエンジニアのための対話術：技術的決定を通す方法
良いアイデアが採用されない理由は、たいていアイデアが悪いからではなく、伝え方が悪いからです。本記事では、設計ドキュメントやRFCで提案する方法、解決策ではなく問題から説得する方法、経営層とエンジニア同僚でメッセージを変える方法、議論に負けた後に前へ進む「同意できないが従う」、非同期と同期の使い分け、あらゆる決定のコストを明示する方法、そして「強い意見を、緩く保持する」が支配のための言い訳に変わる罠を扱います。
2026-06-27 · 26 分で読めます #career#communication#engineeringコードレビューの対話術：摩擦のないフィードバック
コードレビューは欠陥を見つける技術的な作業であると同時に、人と人との対話です。本記事では、人ではなくコードに向けて批評をフレーミングすること、nit と blocker を区別する Conventional Comments、命令ではなく質問すること、小さな PR が実質的にレビューされ大きな PR が形だけで承認される理由、良いコードを称賛すること、作成者としてフィードバックを上手に受け取ること、そしてレビュアーと作成者が分担する双方
2026-06-26 · 29 分で読めます #code-review#communication#engineering技術的な背伸びとスコープ — カーマックの回顧から学ぶこと
ジョン・カーマックが公開したQuake開発の回顧を手がかりに、初期ゲーム開発の技術的野心と組織運営の問題を一般的な教訓として解きほぐします。安定した基盤を選ぶ価値、スコープ管理と技術的負債、野心と現実のバランス、小さなチームの意思決定を整理します。
2026-06-25 · 50 分で読めます #culture#engineering#scope#technical-debt#team理解する喜び — LLM時代でも深く理解すべき理由
検索とLLMは速い答えをくれますが、深い理解は制御と所有権をくれます。抽象の向こうを見ることの価値、ツールに引きずられない態度、デバッグと障害で表れる理解の差、学習としての理解、そしていつ抽象に頼ってよいかのバランスを整理します。
2026-06-25 · 47 分で読めます #culture#learning#craftsmanship#understanding#engineering分散システムが教えてくれた恋愛の技術
リトライとバックオフ、タイムアウト、ハートビート、一貫性モデル、バックプレッシャー、グレースフルデグラデーション、冪等性、二人の将軍問題、そしてTTL付きキャッシュとしての信頼。分散システムを難しくしている問題は、誰かと近づくことを難しくしている問題とそっくり同じでした。信頼できないネットワークと長年つき合って学んだことを、恋愛の言葉で読み直してみます。
2026-06-25 · 26 分で読めます #engineering#relationships#fun#distributed-systems個別対応からプラットフォームへ：FDEの成果を製品化する
フォワードデプロイドエンジニア（FDE）とプロダクトのあいだのフィードバックループ。N人の顧客から同じパターンを見つけ、設定と抽象化として抜き出し、三の法則でいつ一般化すべきでないかを判断する。一顧客のために速く作ることと、みんなのために築くことの緊張、そして優れた製品がいかにフォワードデプロイドな仕事から生まれるのかを語ります。
2026-06-24 · 15 分で読めます #product#engineering#fde初心を忘れない — 楽の誘惑に勝つ方法
初心は大げさな決意ではなく、毎日少しずつ薄れていくものです。楽の誘惑と短期的な甘さがどう自分に跳ね返るのか、そして与えられた期間にミッションを完遂する人であり続けるための仕組みを整理します。
2026-06-19 · 63 分で読めます #beginners-mind#discipline#engineering#habits#cultureエンジニアのための哲学 — ストア哲学とプラグマティズムを仕事に活かす
ストア哲学のコントロールの二分法、プラグマティズムの「うまくいくものが真理」という考え、エッセンシャリズム、職人気質をエンジニアの日常に活かす方法を扱います。抽象的な説教ではなく、コードレビューや障害対応、キャリアの決断といった具体的な場面でどう使うか、そして行き過ぎた自己啓発の罠をどう避けるかを見ていきます。
2026-06-16 · 45 分で読めます #philosophy#stoicism#pragmatism#engineering#mindsetSQLiteはどこにでもある
地球上で最も多くデプロイされているデータベースは、OracleでもPostgresでもなくSQLiteです。あなたのスマホ、ブラウザ、さらには飛行機の中にもあります。サーバーのない単一ファイル設計、クライアントサーバーDBに勝つとき、WALモード、インメモリDBでのテスト、WASMでブラウザで動かす、litestreamで耐久性を確保する、までを整理します。
2026-06-15 · 20 分で読めます #databases#sqlite#engineering