Anthropicはなぜ異次元の速度で開発できるのか｜すてぃお
「Anthropic（Claudeを作っている会社）、開発が速すぎる」 最近、周りのエンジニアと話していると、この話題がよく出ます。僕も同じことを思っていて、いろいろ調べているうちに、単に「AIを使っているから速い」という一言では説明できない構造があることが見えてきました。 例えば、下記になります。 2026年Q1の3ヶ月で120以上の機能をリリース（18時間に1機能） エンジニア1人あたり1日約5PR（Pull Request、コードの変更を提出する単位） 社内では毎日60〜100回のリリース Claude Coworkは約10日で構築 Claude DesignはOpus 4.7のリリース翌日に公開 普通のソフトウェア開発企業の感覚からすると、明らかに異次元です。この記事では、公開されているインタビューや内部研究、関係者の発言をもとに、「なぜこんなことが可能なのか」というのを調べた限り
技術ニュースを毎朝スマホで流し読みしたい、だから自分専用サイトを開発した話
Next.jsは使っていません。更新は1日1回で動的コンテンツもないので、Viteのbuildで十分です。 テストは先に書いて、実装と分けた Claude Codeに実装を任せるときに怖いのは、テストを通すためだけの嘘実装ができてしまうことです。 ダミーデータで埋めたり、assertを弱めたり、skipを入れたりするパターン。 対策として、テスト設計と実装担当を物理的に分けて、最後にクロスレビューするフローにしています。 1. テスト設計担当がテストとスケルトンを先に書く 2. 僕がテスト観点をレビュー 3. 実装担当がテスト全 PASS するまで書く。テストファイルには触らない 4. テスト設計担当がクロスレビュー。テストファイルのmtimeが自分の作業時刻で止まっているかを確認する Python側99テスト、Web側 35テスト、合計134テストで固めました。 mtimeベースの検証は
Cursor・MCPを活用した画面刷新プロジェクトにおける開発サイクルと教訓
はじめに PKSHA Technology のソフトウェアエンジニアの新冨です。 私のチームでは社内問い合わせ管理ソフトウェアである PKSHA AI ヘルプデスクを開発しています。PKSHA AI ヘルプデスクに関する詳しい説明は以下の記事を参考にしてください。 先日、問い合わせ者用の Teams 風なチャット画面を ChatGPT 風なデザインに刷新しました。このプロジェクトで私は主担当エンジニアとして、Cursor と MCP（Model Context Protocol）を中心に複数の AI ツールを統合し、開発サイクル全体を AI フローとして再構築しました。「AI にコードを書かせる」だけでなく、タスク起票から仕様参照、フィードバック反映、QA、PR 作成までを一連の循環として AI に組み込むと、開発の速度と品質が変わりました。 この記事を通して読者が、Cursor と MC
なぜバイブコーディングをめぐる議論は噛み合わないのか
AI楽観派にとって、「動く」ことがすべての証明。 AI慎重派にとって、「なぜそう動くか」がすべての理由。 両者が同じコードを見ても、 前者は「成果物」を見ており、後者は「思考の痕跡」を見ている。 視点の深度が違うのだ。 5. 設計＝抽象、コード＝具象 コードを書くとき、頭の中には「構造」がある。 それは最初から完璧ではなく、書いて、動かして、違和感を覚えて、直していく。 命名、依存、責務、階層を少しずつ整える。 この「書きながら考える」行為こそが設計であり、 設計書よりもコードの構造そのものが本当の設計書になる。 AI楽観派の前提は、「設計と実装は分離できる」。 AI慎重派の前提は、「設計と実装は不可分」。 この一点が、AI時代の開発を分ける境界線だ。 6. バイブコーディングの議論が噛み合わない理由 バイブコーディングをめぐる議論は、 実は技術論ではなく認識論の衝突だ。 AI楽観派：AI
新規アプリ開発を請け負う時の流れ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 まずは、このご時世に新規のアプリ開発を出来るというチャンスに感謝しましょう。 もちろんすでにあるアプリの追加開発や運用で得られる経験値はとても素晴らしいですが、同じように新規開発も胸踊るものがあります。 あなたのRoleがDeveloperなのか、あるいはProject Managerなのか、Product Managerなのかで主に考慮すべき点は変わってきますが、それはそれとしてすべての点を理解して、抜け漏れがあったら指摘あるいは巻き取る覚悟を持っておきましょう。 ラストマンシップは良い資質です。具体的にはラストマンシップがある
品質重視のアジャイル開発 ｜AI・実績・強み｜ソフトウェアテスト・第三者検証のベリサーブ
ビジネス環境の変化が激しく、先行きも不透明な昨今、動くソフトウェアを短期間に繰り返し作るアジャイル開発が注目されています。しかし、アジャイル開発の意義や必要性は認識しながらも、いざ実施するとなると躊躇してしまう組織が少なくありません。「アジャイル開発における品質確保をどうするか」という問題が、採用をためらう理由の1つです。本講演では、アジャイル開発の特徴や難しさを、ウォーターフォール（WF）モデル開発と比較しながら解説します。その上で、「短期間」という条件を乗り越え、品質重視のアジャイル開発を実現するためのポイントをご紹介します。 ※この記事は、『ベリサーブ アカデミック イニシアティブ 2021』の講演内容を基にした内容です。 ポストコロナ時代に求められるアジャイル開発 ここ1、2年のテレワークやデジタル取引の普及から分かるように、新型コロナウイルス感染症の流行は日本のデジタル活用を一気
ソフトウェア開発の “見積り” と “計画” を混同するから話が噛み合わない｜mtx2s
“見積り” を作成した開発チームと、それを確認したビジネス担当者や経営者が、その内容を巡って対立することがあります。「見積りが大き過ぎる」「いや、これぐらいはかかりますよ」といったあのやり取りです。 これはおそらく、両者がともに “見積り” と “計画” を区別せず、混同しているから発生しています。見積り依頼を受けた時、開発チームが提出するものは、おそらく “見積り” です。しかし、ビジネス担当者や経営者が期待するアウトプットは “計画” なのです。 こうして “見積り依頼” という名のもとに、ソフトウェア組織に対立が日々生じているのではないでしょうか。 “見積り” と “計画” は別物見積り結果の「30人月」という数字（①）は、計画ではなく見積り工数です。そんなことは当たり前ですよね。 工数が明らかになれば計画なのか？それでは、30人月の開発を5人でこなすから「6か月」かかる（②）、とい
今さら子育て講座 - みずうみ2023
末っ子が発達診断を受けるにあたって、市の子育て講座を半強制で受けることになり、今、第二回が終わったところ。 隔週で2時間の講座がなんと5回。私は相当しぶしぶであった。 だって「子どもを怒鳴ってはいけません」とか、それができれば苦労せんわいというような正論を今さら座学で聞かされるとか、罰ゲームすぎませんか・・・ でも参加してみたら、そういう分かりきったことをやる場ではなく、思いがけなく学び多いものだった。 脳の発達という観点から、幼児という生き物の特性を知った上でのアプローチも面白いし、何より「ままならない他者とのコミュニケーションをいかに和やかなものにできるのか」に対する人間心理をふまえたさまざまな工夫には気付かされることが多かった。 これは幼児だけでなく、老人や思春期の子どもや同僚やパートナーや、つまり他人全てに対して応用できる有益なメソッドだと思う。 それが、「子育て中でいっぱいいっぱ
「視座」の上げ方が成人発達理論にわかりやすくまとまってた｜中村修三(ShuzoN)
成人発達理論というジャンルがある。ここ半年くらいハマって調べていた。ここ数年の自分の変遷にピタリと当てはまっていてずいぶんと面白かった。 この「発達段階」というものがいわゆる「視座」にかなり近い概念なのではないかと思い、今日は紹介してみる。スライドも作ったのでスライドが好きな人はコチラもどうぞ 視野・視座・視点ずっといまいち意味がわからなかったのだが、成人発達理論を学んだ結果、「視座」という単語の意味が自然と理解できるようになった。 学んだ結果として得られた言葉の意味は「自身の価値観から離れ、より広い対象を主語にして見る俯瞰的な観点」という非常にメタなものであった。視座が上がるとは ✕ : 「見えるものが広がる」というシンプルな変化 ◯: 不可逆な思考パラダイムの遷移 であり、「前の自分を失う」ような要素を含むのではないかと思う。抽象的すぎるので詳しく見ていこう。 成人発達理論とは簡単にい
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
マネージャー依存の構造をいかにして解決するか？ LINE NEWSの事例に学ぶ、プロジェクトマネジメントの知見と工夫 | ログミーBusiness
2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Project Management & Agile全社横断組織の戦略と事例」に登壇したのはLINE Effective Team and Delivery室 室長の横道稔氏。LINEの全社横断組織「Effective Team and Delivery室」のミッションと、実際の取組みについて紹介しました。後半パートとなる今回は、LINE NEWSにおけるプロジェクト支援事例と、実際に取り
エンジニアと初めて仕事をした時の話と、ドラえもんが好きな話 - なにげなくなんとなくなブログ
この記事はユアマイスターアドベントカレンダーDAY21の記事です。 qiita.com せっかくの開発メンバーとのセッション企画なのでいつもと違う開発に関わる話でいきたい思います。 僕が初めてエンジニアと仕事をしてから 今まで学んだことを簡単に書きたいと思います。 あ、 もしエンジニアの方が読んでたら こちらも前回書いた背伸びブログなので合わせて読んでいただけると嬉しいです。 yourmystar-engineer.hatenablog.jp 僕が初めてエンジニアさんと仕事したのはかれこれ５年くらい前でした。 自分のチームの数字をもっとわかりやすく知りたい。 「ダッシュボードでレポートを管理したい」 そう思って、どうしたら良いか聞いたら 「それは開発案件だよ」と初めてエンジニアと働くという扉を案内されました。 ここで先にお伝えしておきたいのは、 プログラミングがわからない人が、エンジニアと
業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary
昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か
プロダクトオーナーにリーダーシップは不要なのか？サーバントリーダーシップで「男の子なチーム」になるのを防ぐ
プロダクトオーナーにリーダーシップは不要なのか？サーバントリーダーシップで「男の子なチーム」になるのを防ぐ 2016/11/26 「プロダクトオーナー祭り2016 ～世界を創るのは俺たちだ！」で講演した内容です。 都合上、一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/
事業会社に転職して半年経ったので、ふりかえり - TONY0922のブログ
今年の頭に中小SIerから事業会社に転職をして、 半年以上経ったので、振り返えりを書こうと思う。 なんで転職したか？ Sierで受託開発の仕事をしている間に 個人で小さなWebサービスをいくつか作った事があり、 それを周りの人につかってもらったり、そのサービスを大きくしていく上で、 BtoCの受託開発も良いけど、自社Webサービスをグロースさせる仕事も 面白そうだなーという気持ちが徐々に強くなり、転職を考えるようになった。 結果、去年の末にとある事業会社から内定をもらったので、転職することにした。 事業会社に転職でどうだったか？ 「技術はあくまで手段であって、プロジェクトのKPIにコミットできないエンジニアはいらないよ。」 最初に上司に言われた言葉がこれだった。 恥ずかしい話だが、 入社する前は、事業会社のエンジニアの仕事って 企画サイドが考えた施策を開発者が実現可否やスケジュールを判断し
2014年に読んだ技術書で良かったもの - うさぎ組
概要 新刊にかぎらず、今年読んでいて「あー、良書だなー」って思ったものをあげています。これ、ダメじゃないの？とか、あー、やっぱりこれいいよねっていうコメントもらえると嬉しいです。 基本は、.NETにおけるWeb APIやFW開発でQA * POな人が思う良書です。今年は技術書より論文、言語仕様書、実装を読んでいることが多かったので、去年の半分の30冊くらいしか読んでいないかな。 開発チーム系 エッセンシャル スクラム 作者: Kenneth S. Rubin出版社/メーカー: 翔泳社発売日: 2014/08/01メディア: Kindle版この商品を含むブログを見る スクラムなんとなくわかっているんですけど、自分以外の状況よくわからんしなー、進め方変じゃないかなぁっていうときに、読むとめっちゃ参考になります。 組織パターン 作者: James O. Coplien,Neil B. Harri
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
総務省｜電子政府｜政府共通ルールの策定(標準ガイドライン等)
