最近、プロダクト開発をしていて気づいたことがあります。 僕はもう、IDEやエディタをほとんど開いていません。 以前なら、開発といえば、まずVSCodeなどのエディタを立ち上げて、コードを書き始めるのが当たり前でした。 でも今は違います。AIに「こういう機能を作って」と指示を出して、生成されたコードを読んで、「ここを直して」とフィードバックする。この繰り返しでほとんどの開発が完結してしまいます。 プロダクト開発を行うメイン業務は「コードを書くこと」から「コードを読んでチェックすること」に変わりました。 この変化を経験して思ったのは、「書ける」能力より「読める」能力の方が重要になってきているということです。 これは何かに似ていると考えていまして、漢字です。 漢字の「読める」と「書ける」日本人なら誰でも経験があると思います。 「薔薇」を読むことはできます。でも、いざ手書きで書こうとすると書けませ

このnoteは全文無料で読めます。 会社を辞めてフリーランスとして働こうという人が増えているように感じます。収入が上がる、自由に働ける、リモートで好きな場所で仕事ができる。そういった魅力に惹かれて、独立を考えるエンジニアは非常に多いです。 僕の経験からになりますが、フリーランスになってどこかの会社で業務委託として働くというスタイルは、長期的にはオススメできません。 僕が2018年から2019年の夏頃までの1年半、フリーランスのエンジニアとして活動した経験を振り返りつつ、書いています。 注意事項最初にお断りしておきます。 この記事は「全てのフリーランスに対してオススメできない」と言いたいわけではありません。実際に、フリーランスとしてうまくいっている人はたくさんいます。 この記事の内容が当てはまらない人もたくさんいることもあるでしょう。 この記事は「構造」の話を主軸としています。フリーランスと

年末年始になると、「来年（今年）の目標」を決める人は多いのではないでしょうか。 今ごろ、2026年の目標を決めている人も多いと思います。 でも、次の年末にその目標を振り返る人はどれくらいいるでしょうか。 また、達成できた人はごく僅かです。そもそも、ほとんどの人は何を目標にしたか覚えていないのではないでしょうか。 このnoteではどうして、新年の目標は達成できずに終わるのか、 自分の脳をハックすることで自分が目指している姿になれるようにする 話を書いています。 なぜ長期目標は達成できないのか目標を立てただけで満足してしまう長期目標を立てること自体は悪くありません。でも、多くの人が長期目標を立てただけで満足してしまいます。 「3年後にリードエンジニアになる」「5年後に起業する」「10年後に年収2000万円」。目標を立てても、良くて紙に書いて、壁に貼って、そこで終わりです。 多くの人が目標を達成

これは「あらたま・いくおのアドベントカレンダー」23日目の記事です。 「あらたま・いくおのマネジメントRadio」のアドベントカレンダーということで、普段Podcastを聴いたり、実際お話していて感じる 二人の「表に出にくいけど実はすごい」スキルについて書いてみます。 なお、オススメのエピソードはこちら なぜ「相談されやすい」が最強なのかマネージャーにとって最も怖いのは「知らなかった」です。 チームメンバーが転職を考えていたことを知らなかった プロジェクトが炎上しかけていたことを知らなかった 人間関係のトラブルがあることを知らなかった 相談されやすいマネージャーには、これらの情報が「事件になる前」に入ってきます。早期発見できるのであれば、問題が大きくなる前に早期対処ができる。だから最強なのです。 逆に、相談されにくいマネージャーのもとには、問題が大きくなってから情報が来ます。「もっと早く言

「Slackで何を言いたいのかわからない」「ドキュメントを書くのに異常に時間がかかる」 こういった人は組織に一人はいないだろうか。 マネージャーとして「言語化能力を鍛えてほしい」と思うことは多いとは思います。また、LLMを利用して業務を行う際には言語化能力が非常に重要となると考えております。 ですが、正直なところ、できていない人に対して、トレーニングでなんとかなるのか疑問に感じることもあるのではないでしょうか。 僕は23歳の頃、会社の先輩に「お前、何言ってるかわからないから話すのやめるわ」と言われたことがあります。かなりショックだったのですが、それ以来、「どう伝えればわかってもらえるか」を強く意識するようになりました。 その結果、今では言語化能力が高いと言われることもあります。（このようなnoteを書いていると言語化してもらうの助かるとも言われます。） このような経験から言語化能力は天性の

AIでコードを書く人も増えた。 AIでブログを書く人も増えた。 AIで画像を生成してSNSに上げる人も増えた。 AIにより、アウトプットを手軽にできるようになった一方、下記記事に記載があるようにクオリティの低下も見られるようになっています。 業務でコードレビューをしていても、明らかにAIが書いていて、不自然な実装になっているのにも関わらず、レビュー依頼をしてくるケースも若干ですが、観測しております。 LLM登場以前よりもそれっぽいアウトプットになっているので確認するコストも高くて困りがちです。 このnoteで僕が言いたいことはAIを使って出したものも、あなたのアウトプットということです。 AIを使ってなくても使ったとしてもアウトプットの質が高ければ評価されるし、質が低ければ評価されない。 下記のQiitaもAIを一切使ってないかもしれないし、AIを使ったかもしれないけど内容を見て評価を受け

プロジェクトがうまくいかない原因の多くは、技術的な問題ではなくて、 プロジェクトの進行管理ができていないことだと思ってます。 もう少し具体的にすると、「どこで想定外のことが発生しそうか？」ということを事前に予測できているかどうかが、プロジェクトの成否を分けます。 飲み会の幹事を任せてみると、その人のプロジェクトマネジメント能力がよくわかるなと思って、書いてみます。 「飲み会やります」と言うのは簡単です。でも実際にやるとなると、こんな工程があります。 これを見て「大したことないでしょ」と思う人と、「いろいろ考えることあるな」と思う人がいますが、前者は幹事をやったことがないか、よほど素晴らしい環境でしか幹事をやったことないのではないかと思う。 飲み会で起きるトラブルを想像できるか飲み会の幹事をやったことがある人なら、こんなトラブルを経験したことがあると思う。 日程調整のトラブル候補日を出したの

ソフトウェア開発の見積もりというのはそもそも難しい。 要件の曖昧さ、技術的な不確実性、メンバーのスキル差。様々な要因で、見積もりは常に外れやすかった。 過去の類似機能を参考にしたり、経験を積んでも、「だいたいこのぐらいだろう」という予測は完全に当てれるわけでもない。 それでも、従来は少なくとも「どういう要因で外れるか」はある程度予測できていました。技術的な難しさ、要件の曖昧さ、既存システムとの絡みなどの変数は、経験によって少しずつ読めるようになってきました。 ところが、Claude CodeやCodexのようなコーディングエージェントを使い始めてから、状況が一変しています。 ある日、既存のパターンに沿った画面の追加が「これは5日ぐらいで終わるだろうな」と思ったのですがClaude Codeに渡したら数時間で、ある程度のものが出来上がってきて、そこから調整などを加えたら合計2日ぐらいで機能が

「言ったのに伝わってなかった」という経験は誰にでもあると思います。 ミーティングで説明した。Slackでも伝えた。ドキュメントにも書いた。それでもメンバーが理解していなかったり、優先順位を間違えていたりすることは多くの方が経験されているのではないでしょうか。 「なぜ伝わらないんだろう」と思うかもしれないのですが、伝える側が工夫することで伝わりやすくすることはできると僕は考えています。 本記事では、伝える側を「発信者」、伝えられる側を「受信者」として表現します。 伝わらない理由人は一度では覚えられないいくら大事なことでもポロッと1度言われただけで覚えられるはずがない。ミーティングで聞いた話、Slackで流れてきたメッセージ、ドキュメントに書かれた方針。全てを同じ重要度で記憶することはできません。 毎日、様々な情報が飛び交う中で一言一句、全てを覚えることは不可能です。 なのにもかかわらず、発信

「うちのビジネスは特殊だから、既存のフレームワークは合わない」 この言葉を僕は何度も聞いてきました。 「うちは特殊だから、独自のワークフローを作ろう」 「スクラムはうちには合わないからカスタマイズして使おう」 「この開発プロセス（僕が考えた最強の方法）が一番いいんだ」 プロダクトマネジメントでも同じです。 「このプロダクトの意思決定プロセスは独自に作ろう」 「優先順位のつけ方は、うちの事業に合わせたオリジナルで」 でも、今振り返ると、だいたい失敗していました。 ただし、誤解しないでほしいのは、独自性が悪いわけではないということです。 問題は、既存のパターンを理解する前に、いきなり独自の方法を作ろうとしてしまうことです。 「うちは特殊だから」は本当に特殊か？僕はこれまで何度も「うちは特殊だから」という言葉を聞いてきましたが、実際に全てが特殊だったケースは一度も見たことがありません。 確かに一

秋のブログ週間の7本目です。TIG 真野です。 アーキチーム（アーキテクト）やテックリードなどからの設計/開発のレビューで、こんな経験はありませんか？ 「その実装は、この機能ID “BL310” の実装パターンでお願いします」「そのライブラリの採用は見送りでお願いします」「そのミドル（DB）のその機能の利用は原則禁止です。え？ はい、あー、、ガイドラインには…確かに今、書いていないですね。後出しで申し訳ないのですが利用はしない方向でお願いします。開発規約には私がこれから追記しますね。え？ あ、はい。そうですね、今度タイ料理でも食べに行きましょう」難しい要件・厳しい期限・不確実性・そして必ずしも満足とは言い難い体制の中、こっちはベストを尽くしていて、ましてより直感的で意図が明確な設計や実装だと思っていて、ていうか品質やスケジュールで遅延が生じた際に結局、矢面に立つのは自分なのに、否定されてか

与えられた報酬分だけ仕事をするという考え方もあります。 でも、期待値をちゃんと超えるということをやることで信用に繋がったり、未来の仕事に繋がったりしていることを実感しています。 なので、毎回期待値を越えようとすることは自分のために非常に大事だと思う。 また、依頼者側の視点としては、なにかを依頼した際に相手が期待値を越えようとしてくれてるだけでも嬉しいものです。 なぜ期待値を超えるべきなのか僕の経験では、期待値を超える仕事を継続的にやっていると、明らかに機会が増えます。 新しいプロジェクトに声をかけられる頻度が上がったり、より重要な判断を任されるようになったり、重要なポジションに抜擢されたりする。 これは単純に「いい人だから」ではなく、「この人に任せれば想定以上の成果が期待できる」という信用を積み重ねた結果です。 実際に、僕が過去に関わったプロジェクトで期待値を超える成果を出した結果、次のフ

“作る”だけでは価値は生まれない。ソフトウェアエンジニアが学ぶべきプロダクトマネジメント 2025年10月29日 株式会社adding 代表取締役 レストラン「ワインと鍋」オーナー 岩崎裕馬 高校卒業後、SIerにエンジニアとして就職。複数社を経験後、2014年に株式会社Speeeに入社し、リードエンジニアとして「UZOU」などの開発に従事。フリーランスを経て、2019年7月からidentify株式会社のCTOを約6年間務める。現在は株式会社addingの代表取締役として開発支援や技術顧問サービスを提供する傍ら、「すてぃお」の名義でプロダクトマネジメントやソフトウェア開発に関する発信を続けている。 AIツールの進化は、ソフトウェアエンジニアの働き方に大きな変化をもたらしています。純粋な技術力がコモディティ化しつつある今、自身が開発するプロダクトが「誰の、どんな課題を解決するのか」を深く理解

エンジニアとしてプロダクトデザイナーと関わることがよくありました。 そんな中、エンジニアとして一番困るのは、デザインが"ポン"と出されるだけの状態です。 "ポン"と出されるのはよく遭遇します。デザイナーから「このデザインで実装してください」とFigmaが共有される。見た目は綺麗だし、UIの細部まで丁寧に作り込まれている。でも、配置や構成が「ユーザー体験上クリティカルなのか、ただ雰囲気で置かれたのか」が分からない。 エンジニアとしては「ここは手間に応じて調整していいのか、それとも厳密に守るべきなのか」判断に毎回迷う。デザイナーに相談すると「あ、それは気づかなかった。調整してもらって大丈夫です」という回答が返ってくる。 別の機会で勝手に調整した場合は「デザイン通りにやってもらいたいです」と言われる場合もある。 こういったことが積み重なると、エンジニアは実装時に「ここは厳密に守るべきか、調整して

あえて、「このアプローチは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

最近、キャリア初期（20代）の方から「ワークライフバランスを意識したい」「フルリモートで働きたい」「残業の少ない会社で働きたい」という相談をよく受けます。 確かに気持ちはわかります。プライベートの時間も大切にしたいし、柔軟な働き方ができればそれに越したことはありません。 結論から言うと、僕としてはオススメできません。 もちろん、ワークライフバランスを取ること自体は自由です。ただ、20代で時間を投資して能力を高めることが、30代以降の経済的自由や本当の意味でのワークライフバランスにつながると思っています。 ワークライフバランスを意識してプライベートの時間を充実させる働き方は、中長期にはプライベートを充実させる結果になりません。 ただし、これから話す内容には重要な前提があります。まずそこから書いていきます。 最も重要な前提： 健康が第一この記事を読む前に、絶対に理解してほしいことがあります。

プロダクト開発をしている際に 「この機能の優先度はどうしますか？」 「高でお願いします」 「じゃあ、これも高で」 「こっちも重要なので高で」 気がつけば優先度「高」のタスクだらけになっていることってよくありませんか？ 僕は優先度という言葉は明確に避けていて、 優先順位という言葉を使うようにしています。 優先度と優先順位の決定的な違い優先度、優先順位の違い優先度は「高・中・低」のようなカテゴリ分けです。一方、優先順位は「1位、2位、3位」という明確な順番を示します。 僕の経験では、優先度で管理すると必ず問題が起きます。なぜなら、複数のタスクが同じ優先度になることを許してしまうからです。 優先度「高」が10個あったとき、どれから手をつければいいのか。結局そこでまた議論が必要になります。 なぜ優先順位が重要なのか開発リソースは有限です。同時に全てをやることはできません。 優先順位をつけるというこ

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