AI時代に価値が出るのは「作る力」ではなく「評価して回す力」｜すてぃお
最近、AIを使ったソフトウェア開発の話をしていて、話が噛み合わないことが増えました。 「Claude Codeすごいですよね」「Cursor使ってます」みたいな表面的な話で終わる人もいます。一方で、「いまうちはCIに3つのエージェント並走させて、人間はラベル付けるだけにしてます」みたいな話が出てくる人もいます。同じツールを使っているはずなのに、見ている景色が全然違うわけです。 両者の差がどこから来ているのか、最近ずっと考えていました。 そのうちにだんだん見えてきたのは、AIを使いこなしている人とそうでない人の違いは、ツールの知識量でもプロンプトの上手さでもないということです。 差がついているのは、「評価して、改善ループを回す力」だと思っています。 AIは「作る能力」は持っています。AIの作る能力は年々急速に上手くなっています。ただ、「評価する能力」は持っていないか、持っていても極めて不完全
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のリリース翌日に公開 普通のソフトウェア開発企業の感覚からすると、明らかに異次元です。この記事では、公開されているインタビューや内部研究、関係者の発言をもとに、「なぜこんなことが可能なのか」というのを調べた限り
言語化が下手な人は5つのタイプに分けられる｜すてぃお
「Slackで何を言いたいのかわからない」「ドキュメントを書くのに異常に時間がかかる」 こういった人は組織に一人はいないだろうか。 マネージャーとして「言語化能力を鍛えてほしい」と思うことは多いとは思います。また、LLMを利用して業務を行う際には言語化能力が非常に重要となると考えております。 ですが、正直なところ、できていない人に対して、トレーニングでなんとかなるのか疑問に感じることもあるのではないでしょうか。 僕は23歳の頃、会社の先輩に「お前、何言ってるかわからないから話すのやめるわ」と言われたことがあります。かなりショックだったのですが、それ以来、「どう伝えればわかってもらえるか」を強く意識するようになりました。 その結果、今では言語化能力が高いと言われることもあります。（このようなnoteを書いていると言語化してもらうの助かるとも言われます。） このような経験から言語化能力は天性の
期待値を超える｜すてぃお
与えられた報酬分だけ仕事をするという考え方もあります。 でも、期待値をちゃんと超えるということをやることで信用に繋がったり、未来の仕事に繋がったりしていることを実感しています。 なので、毎回期待値を越えようとすることは自分のために非常に大事だと思う。 また、依頼者側の視点としては、なにかを依頼した際に相手が期待値を越えようとしてくれてるだけでも嬉しいものです。 なぜ期待値を超えるべきなのか僕の経験では、期待値を超える仕事を継続的にやっていると、明らかに機会が増えます。 新しいプロジェクトに声をかけられる頻度が上がったり、より重要な判断を任されるようになったり、重要なポジションに抜擢されたりする。 これは単純に「いい人だから」ではなく、「この人に任せれば想定以上の成果が期待できる」という信用を積み重ねた結果です。 実際に、僕が過去に関わったプロジェクトで期待値を超える成果を出した結果、次のフ
経営者が知るべき、なぜエンジニアの「合理的な判断」が事業を圧迫するのか｜すてぃお
個人としては合理的な判断が組織として見た場合に非合理な判断となり、事業を圧迫する結果になるという話を書きます。 質問箱にて元々『「月間2.5億PVの時点でサーバー費用は月15万円+メール送信費用で月15万円で計30万円」だったのに 引き継いだら、インフラだけで毎月50万円近い赤字となっていた』という話は 僕にも似たような相談を受けることが多く どうしてこういったことが起こってしまうのか書こうと思い、筆を取っております。 皆様には混乱をお招きしましたこと謹んでお詫び申し上げます。 現状、インフラ費用だけで毎月50万円近い赤字が出ている状況ですので、まずはインフラの最適化や非効率なコードの見直しを早急に行う必要がある状況です。 （その状態でもなんとか運営を続けられていた元会社さんを尊敬です） (2/3) — 【公式】Peing-質問箱- (@Peing_net) August 23, 2025
ユーザーに「欲しい機能」を聞いても意味ない｜すてぃお
「どんな機能が欲しいですか？」 この質問、プロダクト開発をしているとプロダクトマネージャーやエンジニアが聞いているのを良く耳にします。 お客さんに質問してしまっているケースもよく見ます。でも僕は、この質問は意味はなく、無駄だと考えています。 なぜ「欲しい機能」を聞くのが悪手なのか聞かれたら何か答えなきゃいけない心理ユーザーインタビューで「欲しい機能ありますか？」と聞かれたら、ユーザーは何か答えなきゃいけないと思ってしまいます。 実際、僕も他社のサービスについてインタビューを受けた時、同じ経験をしたことがあります。特に困ってないけど、聞かれたから「あったら便利かも」程度のことを答えてしまう。でも、それにお金を払うかと言われたら、絶対に払いません。 この「聞かれたから答える」という機能要望は、本当のニーズとは全く違うものです。 ユーザーは自分が欲しいものを知らない「もし顧客に望むものを聞いてい
なぜWhyを書くだけで生産性が上がるのか？｜すてぃお
プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では
Claude Code時代のソフトウェアエンジニア生存戦略｜すてぃお
Claude Codeが変えた開発の風景Claude Codeを使い始めて約1ヶ月経ちますが「Claude Codeを使ってから、開発の概念が根本的に変わった」と僕は思ってる。 ClineやCursor Agentの登場でもでも相当変わったと思う。でもClaude Codeはそれ以上の変化だと僕は感じている。何が根本的に違うのか。 自走力の高いClaude Code - ファイルを読み、修正し、テストを実行し、エラーを解決する。まるでペアプロしているような体験。 コードを書く能力が高いClaude 4 Opus - 複雑なロジックも正確に実装できる圧倒的なコード生成能力。 Claude MAXでの定額化 - API料金を気にせず使い倒せる。この「料金を気にしなくていい」という心理的な解放が、開発のアプローチを根本から変える。 従量課金のメンタルモデルから定額使い放題のメンタルモデルへという
Cursor Agentベストプラクティス｜すてぃお
元々はJebbrains製のIDE（Goland、Webstorm）を利用していたのですがCursorを使い始めて数ヶ月経ちます。 Cusorを使い始める前よりもだいぶ早く実装できるようになったと感じます。 Cursorベストプラクティス ・Claude Sonnet 3.7を使え ・Project Rules（.cursor/rules）を使え ・ビルド、lint、テストなどで高速にフィードバックさせろ ・1セッションあたりで依頼することはできるだけ少なくしろ ・よく使うコマンドやライブラリはチートシート作れ — 今別府すてぃお (@suthio_) March 3, 2025 このプラクティスはCursor Agentに限ったものではなく、ClineやDevinを利用する際に活きてくることが非常に多いです。 Claude Sonnet 3.7を使えClaude Sonnet 3.7で解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
