はてなブックマーク

あえて、「このアプローチはAとB、どっちのアプローチにしましょうか」と選択肢を提示することがあります。 僕の中では「この方法しかないよな…」と思っていても、あえて複数案を出して説明することにしています。 今回は知っていると便利なハック的なものを紹介します。 なぜ一択にしないのか例えば、新しいサービスの技術選定で「TypeScriptを使うか、JavaScriptのままでいくか」という議論があったとする。僕の中では明らかにTypeScriptを選ぶべきだと確信しているのですが 相談されたときは必ず下記のように答えます。 「TypeScriptとJavaScriptの2つの選択肢がありますね。それぞれのメリット・デメリットを整理してみましょう」 そして両方の特徴を丁寧に説明する。TypeScriptは型安全性があってエラーも気づきやすい。開発してて明らかに恩恵は大きいです。一方でJavaScr

個人としては合理的な判断が組織として見た場合に非合理な判断となり、事業を圧迫する結果になるという話を書きます。 質問箱にて元々『「月間2.5億PVの時点でサーバー費用は月15万円+メール送信費用で月15万円で計30万円」だったのに 引き継いだら、インフラだけで毎月50万円近い赤字となっていた』という話は 僕にも似たような相談を受けることが多く どうしてこういったことが起こってしまうのか書こうと思い、筆を取っております。 皆様には混乱をお招きしましたこと謹んでお詫び申し上げます。 現状、インフラ費用だけで毎月50万円近い赤字が出ている状況ですので、まずはインフラの最適化や非効率なコードの見直しを早急に行う必要がある状況です。 （その状態でもなんとか運営を続けられていた元会社さんを尊敬です） (2/3) — 【公式】Peing-質問箱- (@Peing_net) August 23, 2025

ここ1年~2年でエンジニアやプロダクトマネージャーにおける仕事の進め方、考え方が大きく変わったように思います。 そんな中、「プロダクトマネージャーはエンジニアリングをどこまで理解すべきか？」という相談を受ける機会が増えてきました。 このnoteでは「AI時代のプロダクトマネージャーはエンジニアリングについてどこまで理解しておくと良いか？」を僕自身の主観で書いていきます。 結論僕の答えは「コードは書けなくても良いが、AIがどこまでやれるか試すことができたり、サービスの運用やコードベースを理解した上でエンジニアが詰まるポイントは理解すべき」です。 プロダクトマネージャーとは利益（ユーザー価値 x 事業性）と投資コスト（開発・運用コスト） を考慮した上でプロダクトに関する意思決定をしていくことがプロダクト価値を最大化するために必要だと考えています。 その上で、投資コストの解像度が低い状態での意思

「優秀なエンジニアを採用したい」という相談をよく受けます。 「技術的負債を解消していった方が採用力はあがりますよ」という話をするのですが技術的負債が採用に与える影響について、僕が考えていることを書きます。 エンジニアは何を求めて会社に入るのか優秀なエンジニアほど「事業に貢献したい」という想いを持って会社を選びます。 エンジニアは単に技術を使いたいわけではなくて、自分の技術力を使って、事業を成長させたいと思っています。 価値を生み出し、自分自身も成長したいと思っています。 技術的負債は「成長の阻害要因」である技術的負債があるということは、開発速度が著しく低下している状態を意味します。 新機能を1つ追加するのに、本来なら1週間で済むところが1ヶ月かかる。バグ修正に追われて、新しい価値提供ができない。 技術的負債によって、事業の成長速度そのものが低下しているのです。 「伸びない会社」に入りたい人

エンジニアリングのバックグラウンドを持っていない経営者に向けて書いています。 そのため、正確性や網羅性が乏しい箇所がありますのでご容赦いただけると幸いです。 はじめに前提としては僕は技術的負債があること自体を悪いとは思っていないです。 企業経営において、借金は必ずしも悪ではないように適切に管理された負債は、成長のためのレバレッジとなります。スタートアップが資金調達をするのも、大企業が社債を発行するのも、将来の成長のために今、資金を使うという判断となります。 技術的負債も同じで市場投入を優先して「とりあえず動く」実装を選ぶことは、ビジネス的には正しい判断であることが多い。 問題は、その負債を「管理していない」ことにあります。金利を把握せず、返済計画もなく、ただ借金を積み上げていくから破綻するのです。 重要なのは、技術的負債を「ゼロにする」ことではなくて、 「適切に管理する」こと。 経営者の方

この記事のターゲット快適な開発環境のメリットを知らない経営者やエンジニアの方々に向けて書いています。 この記事の目的Claude CodeなどのAIを活用したコーディングエージェントを最大限活用するには、まず「快適な開発環境」という土台が必要です。その重要性と構築方法をお伝えします。 この記事を書いた背景最近、いろいろな会社のプロダクトの状況を見る機会が増えています。 とりあえず一旦見てほしいみたいなものや技術顧問、アドバイザー的な立場で関わることもあるのですが「非常にもったいないな」と思うことが多いです。 色々な会社を見ていると、 テストが書かれている、CIが回っている、デプロイが自動化されている みたいなプロダクトは実は少数派で テストはない。CIが常に壊れている。デプロイは手動でやっている みたいなプロダクトが多いことにびっくりしてる — すてぃお (@suthio_) August

プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では

最近、Claude Codeを使っている人から「レビューが追いつかない」という相談をよく受ける。これは偶然ではなく、必然的に起きる現象だと考えています。 このnoteでは どうしてClaude Codeによる生産性向上の限界が訪れるのか どうすれば、全体の生産性が向上するのか Claude Codeを利用した場合にレビュープロセスでのボトルネックをどのように解消させていくか の3つを書いていきます。 プロダクト開発の典型的なワークフローまず、多くのチームで採用されている機能追加のワークフローを整理してみる。 ※あくまで一般例なので、チームにより変更があると考えています 機能追加のワークフローこの流れ自体は理にかなっていると思っています。 問題は各プロセスの処理速度のバランスです。 ボトルネック理論で考える開発プロセス生産管理の世界には「制約理論（TOC: Theory of Constra

スタートアップのCTOをやった中で機能削除を積極的に行ったことはすごくメリットが大きくて、他もどうしてやらないんだろうという思うのですが やれていないという人たちがすごく多そうなので書いています。 CTOを6年ぐらいやったんだけどCTOとしてとても意識して取り組んだことは"機能削除をちゃんとやる"ということだったと思う。 機能削除ってどうしてもエンジニアからは言いづらいし、他からもあまり意識されないけど地味に機能があるだけでコストがかかり続けるので 経営上の意思決定として削除してた — すてぃお (@suthio_) July 15, 2025 なぜ機能削除ができないか僕の経験では、機能削除ができない理由は下記の3つある 1つ目は「機能の多さ＝価値」という誤解。特に新規セールスの場面で「うちのプロダクトは◯◯も△△もできます」とアピールしやすい。 2つ目は既存ユーザーへの配慮。月に10人し

直近に何度か、「社内にエンジニアがいないので受託で新規プロダクトを作っていこうと思うんですけど、どう思いますか？」という相談を何度か受けたので書いてみる。 僕の回答は「ビジネスの難易度を圧倒的に上げる意思決定なのでやめたほうがいい」です。 なぜ受託開発でプロダクト開発は難しいのか僕も過去に何度か受託開発の現場を見てきたし、実際に関わったこともある。その経験から言えるのは、受託開発と自社でのプロダクト開発は根本的に異なるということ。 受託開発にて受託側は納品したらゴールだが、発注側にとってはそこからがスタートになる。 この違いは想像以上に大きい。 インセンティブの問題まず、受託開発会社は契約通りの機能を作ることにフォーカスする。それ以上でもそれ以下でもない。ユーザーフィードバックを受けて素早く改善したいと思っても、それは「追加開発」として別途見積もりが必要になる。 受託開発のエンジニアにとっ

経営者から「AIを使った開発をうちの開発チームにもやってほしいんだけどうまく活用できていないようなので、うまく活用できるようにしたい」と相談を受けます。 僕も下記のような記事を書いているのですが、そもそも使い倒すためには前提条件があるので説明するためにこのnoteを書いています。 （ついでにエンジニアがこの記事を使って経営層に説明しやすくなると良いなと思ってます） 前提 エンジニアとしても生産性の向上するような施策はぜひやりたいと思っていて、Claude Codeなどのコーディングエージェントも活用してうまくやれるなら活用したいと思っている（はず。今回は現場のエンジニアも活用したいと思っている前提で進めます） エンジニアとしては活用したいが活用できないというジレンマが存在しています。 今回、掲載する画像は下記のような簡易的なツールから生成しているので 経営層に説明する際にエンジニアの皆様は

この度、2025年6月30日付けでidentify株式会社の取締役CTOを退任することになりました。2019年7月からなので丸6年の期間、CTOを務めました。 6年間の振り返り僕がidentifyに入った2019年7月はショート動画という言葉もまだ認知度が低く、TikTokが日本でも使われ始めてなかった時代です。 ショート動画という言葉すら知らなかったのですが「縦型の動画素材が市場で不足する未来が必ず来る」と代表の鬼山が言っていて「可能性はかなり高いし、そこまで遠くないだろうな…」と思ってたので僕も一緒に取り組むことにしたのでした。 結果として今では、ショート動画市場でかなりのシェアを獲得するまでに成長しました。特に最近のプレスリリースにもあるように、事業は順調に拡大しています。 ここまで成長したことは、本当に感慨深いものがあります。 CTOとして学んだことこの6年間で最も強く実感したのは

僕は食べ放題だとついつい食べ過ぎちゃうし、Netflixなども見放題だと永遠と見ちゃいます。 なんだか◯◯放題って使わないと損って思っちゃう派です。 Claude MAXも同様で、定額課金（しかも20xだと月200ドル）だと使わないと損って思ってしまいます。 使い倒した結果がこちらです Claude Codeを使い倒したいときに下記2つの問題があります。 Claude Codeに渡すタスクを作るのが大変でなかなかClaude Codeに渡せない Claude Codeが実装してくれた内容をレビューするのが遅れて、次のタスクが渡せない つまり、下記のような作業フローになっており、自分自身がボトルネックになってしまうのです。 これでは本当はもっとClaude Codeを使い倒したいのに使い倒せないのです。 できれば常にClaude Codeを立ち上げてなにかをやらせておきたいところです。 なの

Claude Codeが変えた開発の風景Claude Codeを使い始めて約1ヶ月経ちますが「Claude Codeを使ってから、開発の概念が根本的に変わった」と僕は思ってる。 ClineやCursor Agentの登場でもでも相当変わったと思う。でもClaude Codeはそれ以上の変化だと僕は感じている。何が根本的に違うのか。 自走力の高いClaude Code - ファイルを読み、修正し、テストを実行し、エラーを解決する。まるでペアプロしているような体験。 コードを書く能力が高いClaude 4 Opus - 複雑なロジックも正確に実装できる圧倒的なコード生成能力。 Claude MAXでの定額化 - API料金を気にせず使い倒せる。この「料金を気にしなくていい」という心理的な解放が、開発のアプローチを根本から変える。 従量課金のメンタルモデルから定額使い放題のメンタルモデルへという

エンジニアとして活動してきて、技術にコミットするエンジニアもいいのだけど事業成長にコミットすることで自分の価値を最大化できると思って僕は働いています。 20代の頃はOSSコミッターとか著名なエンジニアになりたいなと思ってたけど結局はなれませんでした。僕に才能ややる気がなかったのかそれ以外かもしれないですが理由はわかってません。 でも技術にコミットする中で技術力があってもあまり価値が出せないケースが多々あることを知ることができました。例えば現在だれも使っていないOSSをメンテナンスできたとしても価値を出せず、稼げることもありません。 それよりも◯◯というアプリを作ったエンジニアとか10億の売上を作るプロダクトエンジニアだと、他の人から見た際に価値がわかりやすいです。 技術にコミットするエンジニアもいいと思いつつも事業成長にコミットするエンジニアもいいぞという話です。 技術と事業成長の関係性テ

はじめに2024年、AIの進化は目覚ましく、特にソフトウェア開発の分野では革命的な変化が起きていると考えています。 CursorやClineも皆が注目している技術だと考えていますが僕個人として注目しているのが自律型AIソフトウェアエンジニア「Devin」です。 人間や機械からの指示に基づいて計画から実装、デバッグ、デプロイまでできるのが魅力的です。 しかしあんまり運用する際の知見がインターネットやX（Twitter）上に落ちていないので僕がしっかり書いておこうと思った次第です。 「Devinは使えない」と言っている人も居ますが、僕は「Devinは運用に使える」と非常に思っているので運用に使うための知識を書いていこうと思います。 ではここからが本編です Devinの得意なこと・苦手なことを理解するDevinの基本的な位置づけDevinを効果的に活用するための最も重要なポイントは、Devinを

概要ClineやCursor、Devinによってソフトウェア開発のやり方が変わっていくと確信をしています。基本は下記の記事に書いてある通りなのですが、僕はClineだけに限った話ではなく、Cursor、Devinでも実現できるし、将来的には似たようなソリューションや更に優れたものがたくさん生み出されると考えています。 将来的にはAIを使って、特定のタスクにおいて、10倍やそれ以上早くなるというのは全然ありえて、 また、従来のソフトウェア開発は将来、「昔は人間の力だけでプログラミングしてたんだよ」と笑い話として話されると思ってます。現代の感覚としては「洗濯板で洗濯をしている」、「薪を焚べて火起こしをしている」に近いです。 AI時代になることでどう変わるのか僕が経験してきたWebベンチャーやスタートアップにおいて、ソフトウェア開発は下記の工程があると考えております。 アイデア・仮説立案: 課題

元々は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で解

はじめにFigmaやMiroなどのフリーハンドのツールは図を書いたりビジュアルでなにかを表現する際にとても便利です。ですが使い方によって読み手にとって高い負荷をかけることになるので僕が思っていることを書いていこうと思います。 書き手にとってのフリーハンドツールの魅力FigmaやMiroなど、フリーハンドで自由に書けるデザインツールやコラボレーションツールは、書き手にとって非常に魅力的です。 自由なキャンバスで直感的にアイデアを描けるため、思考のスピードに合わせて情報を記録できます。特に、ブレインストーミングやラフなプロトタイプの作成においては、そのスムーズさが大きな武器になります。 複数人で議論する際や、ブレインストーミング、振り返りなどでも共通認識を取りながら見やすく表現できるのでとっても便利なものだと考えています。 読み手の視点：どこから読めばいいのかわからない問題一方で状況を共有され

メインは下記の発表をしに行きました。 割ともっと話せるかと思ったけどうまく話せない部分もあって難しかった。 本当は他の人の発表をもっとちゃんと聞きたかったのですが、自分の発表があり、ドキドキしていたので集中できなかったのは反省です。 どこかで飲食店経営の話ができたらいいなと思っていたのですがこんな機会をいただき、magnoliak さんありがとうございました！ 会場では非公開情報をたくさん話したのですが、公開する資料には情報を抜いてから公開しています。（本当は全部公開したいんだけど色々なステークホルダーがいたりするのでごめんなさい） 伝えたかったこと「ソフトウェアエンジニアリングやプロダクト開発で学んでいる内容って他の分野での応用可能性はかなりあるのでは？」と昔から思っていて、みなさんにも同じように思ってもらえたら他の業種でもソフトウェアエンジニアリングの知識が広がっていって世の中良くなっ

事業再構築補助金を受けてサービスを開発したんだけど相談に乗ってほしい という話を最近数件受けているのでどうしてうまくいかないのかをまとめてみようと思います。 ※全ての関係者から直接話を聞いているわけではないのでだいぶ憶測が入ります https://twitter.com/suthio_/status/1709385560006316540 最近、事業再構築補助金を受けてサービス開発したんだけど全然うまくいってなくて助けて的な相談を何件も受けるんですが共通する失敗をしている気がする。 — 今別府すてぃお (@suthio_) October 4, 2023 事業再構築補助金とは経済産業省が実施している補助金制度で最大1.5億円の補助金が受けれる制度となります。 私自身、相談をしていただいたや元々の知り合い含めて複数人が数千万以上で採択を受けているのを観測しています。 この補助金は枠ややること

技術選定の話題がX（Twitter）で盛り上がっていたので僕の考えを書いていこうと思います。 想定読者エンジニアリング領域に対してあまり詳しくない経営者 結論からエンジニアと経営者が一緒に話し合って決めるべきだと考えています。 場合によっては外部からアドバイスを受けながら意思決定をしていかなければならない重要項目です。 理由を書いていきます。 技術選定のプロセスの重要性技術選定は中長期的なプロジェクトの品質、効率、成功に直結するプロセスであり、経営者とエンジニアが共同で検討すべき重要な課題だと考えています。適切な選定することによって短期的にも長期的にも多岐にわたる利点をもたらし、企業全体の戦略的な成功に貢献します。 要求を満たすことができるかの確認そもそも選んだ技術がシステムに必要な要件を満たしていない可能性が考えられます。 必要な要件を満たしていないのであれば採用を見送るべきです。 ※広