iwashi.co

あるソフトウェアエンジニアの1日（2028）

Tue, 19 May 2026 00:00:00 +0000

午前8:00 「夜の仕事」を確認する

起床してベッドの中で最初に開くのは、Slackでもメールでもなく、自分専用のエージェントダッシュボードだ。

昨日の終業時に5つのタスクを走らせて帰った。それぞれに「夜のうちにこのゴールまで進めてくれ」と指示しておいた。

先週リリースした検索機能のp95レイテンシ悪化の原因経路が特定されていること
カスタマーサクセスから上がった71件のフィードバックがテーマ別に整理されていること
競合の新機能を踏まえた自社プロダクトとのギャップが一覧化されていること
開発中SDKのドキュメント草稿が最新コードベースから書き上がっていること
昨日の小規模インシデントのポストモーテムドラフトが仕上がっていること

5つすべてに完了のチェックがついている。エージェントの仕事は完了していたようだ。

僕の手元に届いている成果物は、すべてエージェント同士の一次レビューを通過したものだ。作業エージェント、レビューするエージェント、テストを書くエージェント、セキュリティを見るエージェント。タスクに応じて、それぞれ別の役割を持ったエージェントが互いの仕事をチェックし合い、その結果が最終的に僕に上がってくる。

人間が真っ先に生のアウトプットを読む時代はもう終わっている。

僕の仕事は、AIたちが「これで問題ない」と合意したものに、最後に「本当にそれでいいのか」と問い直し、責任を持つことだ。

数年前の今頃なら、これは丸一日潰してこなしていたタスクだった。今は寝ている間に終わっている。今のボトルネックは、コードを書くことでも、情報をまとめることでもなくなった。僕の仕事は、AIたちが整えてくれたアウトプットに目を通し、「使えるもの」「捨てるもの」「人間が最終判断しなければいけないもの」に振り分けることだ。

2つ目のフィードバック要約には、目を引くものがあった。エンタープライズ顧客5社から、同じ要望が独立に上がってきている。

「監査ログのCSV出力時に、操作者のロールも一緒に出してほしい」

小さな機能だ。だが、5社が独立に要望しているなら、確実に他の顧客も困っている。

ベッドの中でSlackに投げる。

@product_team 監査ログCSVにロール列追加、簡易タスクな案件として今週中にやろうと思います。特にコメントがなければ午後にPRを出しますね。

60分後、PdMからいいねリアクションがつく。このレベルの判断は、チーム内のエンジニア・PdM・デザイナーの誰でも下していい。半年前にそう決めた。

いいねを確認して、すぐにコーディングエージェントに実装を投げる。

監査ログのCSV出力にユーザーロール列を追加してほしい。ロールはNULL許容（古いログレコードのため）。CHANGELOGエントリも書く。

送信する。エージェントはもう動き始めている。僕はまだ布団の中にいる。

ちょっとしたものなら、承認プロセスはほぼ消えた。代わりに、「事後に異議が出たらすぐ巻き戻せる」設計が徹底されている。

午前9:30 仕事開始

オフィスは週に2日。今日は在宅日だ。コーヒーを淹れて、デスクの前に座る。

「スタンドアップミーティング」というものはもう存在しない。代わりにあるのは、毎朝Slackに自動投稿されるチームの状態サマリーだ。

エージェントが、昨日のPR、今走っているCIジョブ、顧客から上がってきたサポートチケット、稼働中のインシデント、メンバーそれぞれの「今日やること」をまとめ、200ワードに収めて貼ってくれる。

僕もやること欄にこう書いた。

監査ログCSVのロール列追加（午前）。検索p95調査の続き（午後）。

午前10:15 監査ログのPRを出す

デスクの前に座ると、朝ベッドの中から投げておいたエージェントのPR通知が上がってきている。差分は147行。テスト追加が83行。エージェントのコードレビューやテストはすでに通っている。

さて、ここからが、僕の本当の仕事だ。

差分を一行ずつ読む。エージェントは優秀だが、イマイチなこともある。今回もあった。古いログレコードのロール列を、ユーザーIDから逆引きしてよしなに埋めようとしていた。

だが、ユーザーが既に削除されている場合、そのロールも消えているべきだ。これはプライバシー設計上の判断であり、エージェントのコンテキストにまだ渡せていなかった情報だ。

レビューコメントを入れて、再度エージェントに差分を修正してもらう。

過去ログのロール後埋めはやめる。削除済みユーザーの情報を復元してしまうリスクがあるため。プライバシー設計の意図についてはdocs/privacy-design.mdに追記しておく。

セキュリティとプライバシーの境界線は、まだ完全には機械に任せられない領域だ。コンプライアンス、デザインセンス、プロダクトの方向性。この3つは、人間が最後の番人として残っている。

修正したPRをマージリクエストに出すと、CIが走り出す。lint、ユニットテスト、統合テスト、E2Eテスト、セキュリティスキャン、依存関係の脆弱性チェック、パフォーマンスの回帰テスト。すべて自動で、各エージェントが並列で走り15分で終わる。

CIが緑になれば、コードはマージされる。マージされたら、その日のうちに本番へリリースされる。数年前は多くても週に数回、あるいは隔週でリリースするのが標準だった。今はそのサイクルが10分の1になった。

リリースが小さく頻繁になったので、何かが壊れても影響範囲が狭い。ロールバックも秒で終わる。

影響内容にもよるが、最終レビュアーに人間の同僚も指名される。前述のようにコードは上がってくる前に、すでに何重ものAIチェックを通過している。人間の同僚は、設計判断とプライバシーへの影響だけを見ればいい。

コーディングスタイル、テストカバレッジの欠落、ドキュメントの整合性。こうした項目は、もう人間の目には届かない。レビュー時間が劇的に短くなった理由はここにある。

午前11:30 プロトタイプ会議

11時半から、新機能の方向性について会議がある。といっても、会議室でホワイトボードを前にして、60分議論するような形式ではない。

先週、チームで意見が割れた。新しい「ワークフロー自動化機能」のUIをどう作るか。

デザイナーは「NodeベースのキャンバスUI」を推した。僕は別の形式のほうがエンタープライズ顧客に馴染むと主張した。PdMは「自然言語入力に振り切るべき」と言った。

5年前なら、実装の前にここから長い議論が始まっていただろう。来週に持ち越しになったかもしれない。でも、今は違う。

3人それぞれが、自分の案のプロトタイプを作ってきた。正確には、各自が一晩で10個以上作り、その中で一番出来のいいものを持ち寄った。

エージェントに少しずつ違う方向性で実装させ、自分で触ってみて、ダメなものを9つ捨てて、残った1つを会議に持ってくる。プロトタイプを作るコストが下がりすぎて、一発勝負で持っていく必要がなくなった。

たくさん作って、たくさん捨てる。これが今の当たり前だ。

デザイナーの作成したプロトタイプはNodeベースUIだった。彼女はエンジニアではない。それでも、AIアシスタントを使って実際に動くReactのUIを組み上げてきた。300行くらいの実装で、データのフローもドラッグ&ドロップも動く。後で聞いたら、12個作って、最後の3つで悩んだらしい。

PdMのプロトタイプは、自然言語からワークフローDSLを生成するデモだった。彼女もコードは書かない、はずだった。でも、エージェントと一緒にOpenAPI仕様までついた動くデモを作ってきた。彼女も15個作ったと言っていた。

僕のプロトタイプは最も保守的で、最も実装コストが低い。僕は8個で打ち止めにした。バリエーションがそんなに出ないUIだからだ。

3つのプロトタイプを並べて、画面共有する。それぞれを5分ずつ触ってみる。議論は、抽象論ではなく、実際に動くものの上で交わされる。

15分後、結論が出た。

自然言語UIをメインに据えつつ、生成された結果をNodeベースキャンバスで可視化できるようにした。アイデアのいいとこ取りだ。

これは、絵に描いたモックでは絶対に辿り着けなかった結論だ。動くものを見て、触ってみて、初めて気づくことがたくさんある。

会議は28分で終わった。デザインドキュメントは書かない。プロトタイプそのものが、デザインドキュメント以上の役割を果たす。

コードについても同じだ。ドキュメントは、もはや真実の情報源ではない。真実は、本番で動いているコードそのものにある。開発があまりに速すぎるので、仕様書は書かれた瞬間から古くなっていく。誰も無条件には仕様書を信用しなくなった。

だから、ドキュメントを順番に読む必要もない。エージェントに「このコードベースで認証フローはどう実装されている？」と聞けば、5分でアーキテクチャの全体像が頭に入る。

午後1:00 昼休み

昼食を食べながら、ふと考える。

僕がこの会社に入ったとき、エンジニアは20人いた。今は40人。プロダクトの規模は5倍になっているのに、人数は2倍にしかなっていない。それでも回っている。むしろ、以前より速く動いている。

チームの単位そのものも小さくなった。以前は1チーム5〜6人が標準だった。ピザ2枚とか言われていた時代だ。今は2〜3人のチームが当たり前だ。エージェントを実働メンバーとして数えれば人数はもっと多いが、人間の頭数だけ見れば、プロダクトを2〜3人で回していることになる。

意思決定が速くなった一番の理由はここにあると思う。人数が増えれば増えるほどコミュニケーションコストは高まる。2〜3人なら、お互いのコンテキストは常に同期できる。だから、Slackの会話でほとんど決まる。

何が変わったのか？

まずコードを書く時間が減った。これは間違いない。でも、コードを書く時間は2025年末には大きく変わっていた。それ以上に変わったのは、「誰がどの仕事をするか」の境界が溶けたことだ。

PdMがコードを書く。デザイナーがプロトタイプを実装する。エンジニアがユーザー向けのヘルプ記事を書く。かつては役割が違ったから大変だったものも、今ではAIが下書きしてくれる。マネージャーも、変わらずコードを書き続けている。

エンジニア同士の専門領域の境界も同じだ。隣のチームの同僚は、入社時は「iOSエンジニア」だった。以前は、モバイル担当はiOSチームとAndroidチームに明確に分かれていた。プラットフォームごとに専任が貼り付き、別々のロードマップ、別々のリリースサイクルで動いていた。

今は、その境界もない。

彼はiOSもAndroidも対応している。プラットフォーム固有のコードはエージェントが大半を埋めてくれるので、彼は「モバイル体験全体の責任者」として両方を見る。それどころか、APIの変更が必要なときはバックエンドにもPRを出すし、管理画面のフロントエンドも触る。

「軸足はモバイルだけどね」と本人は言う。専門領域はあっても、そこに閉じこもらない。これが普通になった。

評価の軸も変わった。もちろん、一瞬話題になった消費トークン数みたいな謎の指標はとうの昔に消滅した。

今、評価されるのは2つの能力だ。

プロダクトへの鋭い直感と顧客理解。何を作るべきか、何を作るべきでないかを見抜く力。
真に深い技術的専門性。分散システム、セキュリティなど、人間が責務を持つべき領域での専門性。

コードを速く書けるだけのエンジニアは、もう特別な存在ではない。それは前提条件になった。

午後2:00 検索レイテンシのp95を追う

午後は、検索機能のレイテンシ調査から始める。

昨晩のエージェントの分析によると、特定のクエリパターンでp95が220msから410msに悪化している。

僕はエージェントに、本番ログの該当時間帯を画面共有してみてもらって、「相関するすべての変更を列挙して」と頼む。コード、設定、依存関係、データ分布。疑うべきものはすべて含める。

3分後、リストが返ってくる。候補は8つ。そのうち5つは明らかに無関係だった。残り3つを、僕が1つずつ精査する。

3番目で見つけた。

先週、誰かが入れた変更だ。Elasticsearchのインデックス戦略を変えていた。それ自体は正しい変更だったが、特定のクエリパターンでホットスポットを作っていた。たまたま、エンタープライズ顧客数社が多用するパターンだった。

昔の手癖で「誰が入れた変更か」を確認しようとして、 git blame を叩きかけて手を止める。

git blame は、もう意味を持たない。

そのコミットは、確かにある同僚の名前で入っている。でも、実装はエージェントが書いた。設計判断は彼とエージェントの会話の中で形成された。テストはまた別のエージェントが追加した。レビューしたのは僕を含む3人と、AIレビュアーだ。

コミットのAuthor欄に表示される名前は、もはや「最後にエンターキーを押した人」以上の意味を持たない。

このコードの所有者は誰か。

答えは、チーム全員としか言いようがない。コードオーナーシップという概念は、もはや個人の単位では成立しない。

僕はSlackで、その同僚をメンションする。責めるためではない。「こういうエッジケースがあった。一緒に直そう」と声をかけるためだ。

コードへの感情的な紐づきが薄れたことで、コードについて議論することが、ずっと楽になった。誰のメンツも傷つかない。

調査結果を反映した修正PRは、20分で出した。

午後4:30 廃止の判断

チームのEMから、DMが来る。

来週から金曜のロードマップ定例をやめようと思う。どう思う？

僕は即答する。

賛成。半年先のロードマップを毎週議論しても、3週間後には全部書き換わってる。
適宜、決めていけばいいと思う。

彼女はEMだが、毎週コードも書いている。エージェントを使うのが誰よりも上手い。

毎週金曜のロードマップ定例は、3年前にチームが15人だった頃に始まった。当時は意味があった。今は、ほとんど儀式になってきていた。

機能しなくなったプロセスを、誰の許可も得ずに廃止できる。この権限を現場が持っていることが、僕らの組織の最大の強みかもしれない。2年前に組織の階層構造が薄くなったことで、意思決定が劇的に速くなった。

長期ロードマップの代わりに、「次の2週間で何を出すか」だけを毎週決める。市場も、技術も、競合も、それくらいの速度で変わるからだ。いやもっと早いかもしれない。

午後5:00 終業前の確認

仕事を終える前、僕は毎日5分だけ、ある問いを自分に投げかけることにしている。

今日、自分が手作業でやった作業の中で、AIに任せられたはずのものはなかったか？

今日のリストを見返す。

監査ログCSVのロール列追加。エージェントが書いた。最終レビューと意思決定は僕。これはOK。
検索p95調査。候補列挙はエージェント。原因特定は僕。これは妥当。
Slackでの議論。全部僕がやった。これは意思決定であり、人間の仕事だ。OK。
朝、競合プロダクトの新機能リストを目視で確認した。10分くらい。これはもっと自動化できたな。

明日の朝までに、競合プロダクトのリリースノートを毎週自動でスキャンし、自社プロダクトと比較したサマリーを出すエージェントを仕込んでおこう。

エージェントに何でもやってもらうという発想は、最初は意識しないとできなかった。今は習慣になった。自分の仕事を、自分で観察して変えていく。それ自体が、AI時代のエンジニアの基礎体力だと思う。

5:30 PM 一日の終わりに

明日のために、今日のエージェントたちに新しいタスクを仕込む。

検索のp95悪化、再発防止のための回帰テストを実装完了しておくこと。監査ログ機能、デプロイ後24時間のメトリクスを監視して、何かあれば翌朝にアラートを出しておくこと。競合プロダクトのリリースノート定期スキャンの仕組みの実装が終わっていること

と、エージェントにテキストを送る。

返事は来ない。来る必要もない。

朝になれば、また夜の仕事が終わっている。

人間の仕事は、判断に寄っていく

この一日で起きていることは、単に「AIがコードを書いてくれるようになった」という話ではない。

本質的には、ソフトウェア開発のボトルネックが実装から判断へ移ることだ。いや、実は以前からボトルネックは実装ではなかったかもしれないが。

何を作るか。何を作らないか。どこまで自動化し、どこから人間が責任を持つか。どの提案を受け入れ、どの提案を退けるか。プライバシー、セキュリティ、ユーザー体験、プロダクトの方向性をどう重ね合わせるか。

AIエージェントが増えるほど、人間の仕事は正直増えていった。判断の回数もだ。

未来のエンジニアに必要なのはAIが大量に出してくる選択肢の中から、何が本当に正しいのかを見抜く力だ。

2028年のエンジニアは、コードを書かないわけではない。ただ、コードを書くことだけが、もう仕事の中心ではない。

中心にあるのは、判断すること。そして、その判断に責任を持つことだ。

という2028年の姿を妄想で書いてみました。内容は当然フィクションです。

もしかしたら、すでにこういう働き方をしている企業もあるかもしれませんし、部分的には実現しているところもあるかもしれません。スタートアップに近いほど実現している可能性が高いと思いますが、大きな企業では組織重力・組織慣性が強いので、もっと先の話かもしれません。

さて、2年後に、どこまで当たっていたか、何が外れているのかを振り返るのが楽しみです。

「ゼロから作るミニCPU」というアプリを作った

Tue, 12 May 2026 00:00:00 +0000

論理回路を組み立てながら、CPUの中身を入門レベルで理解する「ゼロから作るミニCPU」というスマフォアプリをリリースしました。本記事では、その裏側で考えていたことを書いてみます。

なぜ作ったか

大きく分けて2つ理由があります。

そもそも学びは楽しいから

本来、学びは楽しいものだと私は思っています。特に、普段なんとなく使っているものの、中身はよくわかっていないものを理解できた時の感覚は、何とも言えない楽しさがあります。

自分にとって印象に残っているのは、初めてネットワークの仕組みを理解した時です。CSMA/CDの仕組み、IPアドレスやルーティング、TCP/UDPなど、それまで「インターネット」として一塊に見えていたものが、解像度高く見えるようになった瞬間は、すごく楽しかったのを覚えています。

また、ネットワークの中では今は主流ではないですが、電話の仕組みを理解した時もそうでした。電話番号を押すとなぜ相手につながるのか。回線交換とは何か。インターネットとは何が違うのか。どのように技術が進化してきたのか、そういったことを理解できた時も、非常にテンションが上がりました。

何かの中身を理解すると、世界の解像度が少し上がります。これが楽しい。だから、そういう体験を提供できるものを作りたいと思ったのが、1つ目の理由です。

次世代を担う人たちを支援したいから

自分の人生のフェーズもあると思うのですが、次世代を担う人たちを支援することに強いモチベーションがあります。

個人的に人生でやりたいことの1つは、日本から強いプロダクトがどんどん生まれる可能性を高めることです。私の翻訳書籍のあとがきを読まれた方ならご存知かもしれませんが、ほぼ全てのあとがきの締めくくりで書いている内容です。

もちろん自分自身も仕事でプロダクトを作っていますが、自分以外でも日本から素晴らしいプロダクトが生まれればそれで良いと思っています。（その意味で、スタートアップであれ大企業であれ、気を吐いている人たちをすごく応援しています。）

強いプロダクトが生まれるためには、好奇心強くて、かつ技術に強い熱意を持った人が増えることが重要だと思っています。そういう人たちを少しでも支援したいと考えています。これが2つ目の理由です。

ブラックボックスが増えていく現代

現時点（2026年）以降、AIがプロダクト開発の主流になっていくのは間違いないです。AIは、プロダクト開発のハードルを大きく下げるでしょう。コードを書くことも、デザインすることも、アイデアを形にすることも、AIがサポートしてくれるようになります。抽象化のレベルが上がっていくこと自体はとても良いことです。より多くの人が、より簡単にプロダクトを作れるようになるからです。これまでは諦めていたアプリを簡単に作れるようになります。今回のアプリもその1つです。プライベートでほとんど時間が取れないので、AI無しではとてもリリースできなかったと思います。

一方で、抽象化のレベルが上がることで、ブラックボックスがさらに量産されます。AIコーディング以前は、何かをリリースしようとしたら、Web開発に関する理解がある程度必要でした。今はAIを使いこなせば、理解をすっ飛ばしてブラックボックスのままにしても、とりあえずリリースするところまでは行けるようになります。

もちろん、すべての人がすべてのレイヤーを理解する必要はありませんし、Before AIコーディングであっても一緒だったと思います。低レイヤを細部まで完全に理解している人はほとんどいないでしょう。私自身、例えばアセンブラは雰囲気でしか理解していません。

それでも、どこかで一度、ブラックボックスの蓋を開けてみる体験はあって良いと思っています。理解できる範囲が少し増えるだけで、前述のように世の中の見え方が変わります。また何かあったときに、正しい技術判断もしやすくなるでしょう。（あと大事なことなので、もう一度書きますが、何よりもブラックボックスの中身を知ること自体が楽しい！）

そのきっかけとなる候補はいくらあっても良い。今回、私はその候補の1つとしてCPUに注目しました。

CPUは面白いが、最初の一歩が難しい

CPUは、コンピュータの中でもかなり面白いテーマです。私自身、ヘネパタ本(コンピュータの構成と設計)を初めて読んだ時は、「めちゃくちゃすごいな」と思った記憶があります。また、あと、CPUの創りかたという書籍も非常に参考になりました。論理ゲートから始まり、現代のコンピュータは本当に神業的な積み重ねの上に成り立っているんだなという印象を持ちました。

上記の書籍に加え、このCPUの分野にはすでに良い教材がたくさんあります。たとえば Turing Complete は傑作だと思います。私もプレイしました。ただ、それなりに難易度は高いと思います。私も解答を見ないと厳しいものがありました。そもそも情報科学を履修していない人にとっては、序盤から相当難しいのではないかと想定しています。

もう1つ、NAND2Tetris も有名です。こちらも素晴らしい教材です。ただ、専用言語のHDLを書いて進める形式なので、人によってはとっつきにくい可能性があるかと思っています。

そこで、もう一段だけ難易度を下げたものを作れないかと考えました。今回のアプリは、ITパスポートや基本情報技術者などの内容を少しでもかじったことがあれば、なるべく進められるようにしています。

実際、ITパスポート令和3年度の試験ではこんな問題が出題されています。

CPU 内部にある高速小容量の記憶回路であり，演算や制御に関わるデータを一時的に記憶するのに用いられるものはどれか。

答えは「レジスタ」です。ただ役割はわかっても、どのようにレジスタが構成されているのかは、試験勉強の範囲ではわからないと思います。今回のアプリでは、レジスタそのものを自分で作るところも含んでいます。

学びのステージはパズル形式です。論理回路を組み立てながら、少しずつCPUを構成する概念に触れていきます。詰まった時のために、ヒントや解説、なんなら（広告を見る必要がありますが）解答例も用意しています。

個人的には、詰まったらどんどん解答例を見てもらって良いと思います。全部を自力で解くことが目的ではありません。CPUの中身を理解するための足場になれば十分です。

厳密さよりも、まずイメージを持ってほしい

大学などの授業では、CPUの構成を正確に教えることが普通です。一方でこのアプリでは、厳密さよりもまずはイメージを持ってもらうことを優先しています。そのため、例えばALU(算術論理演算器)はとんでもなく簡略化したものになっていますし、ビット数も8bit(1Byte)すらありません。それでも、CPUの全体像がちょっとでも見えるような構成にしています。

もちろん、できる限り変な理解につながらないようにはしています。ただ、CPUの仕組みをいきなり厳密に扱おうとすると、配線が複雑になったり、知るべき概念が多くなったりして、最初の一歩がすごく難しくなります。そうすると、そもそもCPUの中身を知る体験にたどり着けない人が出てきてしまいます。

なのでまずは「こういう部品が組み合わさると、足し算引き算ができたり、情報を記憶できるものになるのか」というイメージを持ってもらうことを優先しました。

その上で、もっと深く知りたくなったら、Turing CompleteやNAND2Tetris、あるいはコンピュータアーキテクチャの専門書に進んでいただければ良いと思っています。このアプリは、その前段にある入口/きっかけの1つです。

おわりに

というわけで、ブラックボックスとして普段見ているものを、自分の手で少しでも、組み立ててみて中身を知るのはは面白い！その感覚を少しでも体感してもらえれば嬉しいです。

無料なので、よければぜひ試してみてください。（良かったらレビューも書いてもらえると嬉しいです！）

Android: ゼロから作るミニCPU - Google Play
iOS: ゼロから作るミニCPU - App Store

AI時代のMOAT 8点

Mon, 04 May 2026 00:00:00 +0000

AI時代の競合優位性(MOAT)って、結局何なのだろう？と考えていた。あんまり従来と変わらないものが多いが、メモにしたので投下してみる。

1つ目はネットワーク効果。これは従来と変わらない。ソフトウェアのコピーは簡単になったとしても、参加者の関係性はコピーできない。たとえば、Xの機能はコピーできても、人が集まらないのでは意味がない。

2つ目は政府などの認可。これも従来と変わらない。認可プロセスを含む行政の仕組みはテクノロジーの進化速度に追従できるわけではない。将来的に変わる可能性はあるとしても、相当長い時間がかかる。ビジネスとして成立するには十分な時間だろう。医療だったり、交通だったり、防衛だったりでポジションを取れているならそれはMOATになる。

3つ目は物理で、特にインフラに近いもの。例えば、今から電力業界に参入して、電線などの物理まで敷くってのは、理論的にはできても現実的には難しい。AIに近い領域だと、データセンターを構築して運用できるのもMOATになる。ロボットも技術力に関連するが近い。

4つ目は資本力。3つ目に関連するが、データセンターの構築というのはもはや不動産と技術のセットであり、ちょっとした資金調達では太刀打ちできない領域。

5つ目は運用と責任のマネージド。何が言いたいかというとSIerの生き残りMOAT。AI時代で内製してものづくりできる企業はどんどん増える（し、良いことだと思う）。一方で、それを長期間にわたって脆弱性に対応しつつ、ユーザーサポートもしながら運用するのは簡単ではない。この辺を丸っと投げて受けてもらえるのには大きな価値がある。これも従来とある程度は一緒だが、その程度がAIで変わったんだと思う。

6つ目は顧客接点。これは古くからある企業が持っている強みの1つ。何らかの受注は、〜という技術が圧倒的に優れているから決まるというわけではなく、〜さんとの信頼関係が構築できたから決まったというのはとても多い。そのため、アカウント営業がすでに信頼を作っている場合は強い。（これを考えると、飲み会とかゴルフとかは強いんだろう）

7つ目はブランド。これもすでに持っている企業が強い。同じものを作っていたとしても、「〜社が作っているから」「〜の希少性があるから」というのは十分に選ばれる理由になる。人の記憶に強く残っているブランドのポジションまでは、AIではコピーできない。

8つ目は独自のデータ。現場のカメラで長年記録し続けた生データや、医療現場で日々蓄積される診断や検査のデータはコピーできない。こういうデータを取得できる立場を獲得して、評価のフライホイールを作れればそれがMOATになる。

と、ざっと書いてみた。実は多くに共通するのが「時間」である。時間をかけて構築したものが、MOATにつながっている。もちろん他にも色々とあるはず。何かあれば教えていただけるとありがたい。

意思決定で多数決ばかり使わないほうがよい理由と、おすすめの決め方

Mon, 06 Apr 2026 00:00:00 +0000

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

業務では、何らかの選択肢の中から1つを選ばないといけない場面が頻繁にあります。

エンジニアリングチームであれば、設計方針をどうするか、どの技術を採用するか、といった判断が日常的に発生します。プロダクトマネジメントでも、どの施策を続けるか、どの機能を優先するか、といった意思決定が必要になります。

そのときの決め方にはいくつかあります。リーダーが決めるのも1つですし、多数決で投票して決めるのも1つです。ほかにも、アジャイル界隈であればfist to fiveのような方法もあります。

このうち多数決は、比較的よく使われる選択肢の1つだと思います。選挙でも使われる方法なので、広く浸透しているのが強い理由の1つでしょう。

この多数決は、全員の意見を出すので一見公平に見えるかもしれません。ですが、実際にはそう単純ではありません。多数決にはデメリットが多くあります。代表的なものは、考慮されない意見の圧殺です。たとえば、文化祭の出し物を決める場合に多数決を使った場合、少数派の意見は切り捨てられるといったようにです。

個人的な意見では、多数決を意思決定のデフォルトの選択肢にしないほうが良い、というのが私の考えです。

多数決の問題

業務における多数決の問題は、少なくとも2つ大きな問題があると私は考えています。

最適解が選ばれるとは限らない

多数決は、「いちばん支持された案」を選ぶ仕組みであって、「いちばん良い案」を選ぶ仕組みではありません。

これが問題になりやすいのは、特にクリエイティブさや長期的な視点が必要な場面です。たとえば、選択肢のなかには、癖があるが独創的で長期的な価値をもたらすものがあります。ところが多数決では、こうした案が不利になりやすいです。理解しやすく、説明しやすく、無難な案が勝ちやすいからです。この辺りは、逆説のスタートアップ思考を読むと、よりイメージしやすいかもしれません。

いずれにせよ、平凡な意思決定に収束しやすくなります。短期的には納得感があるように見えても、最終的なアウトカムにつながりにくいのです。

やり方をミスると、ものすごく時間がかかる

もう1つの問題は、やり方を誤ると非常に遅くなることです。

多数決には、各人が内容を理解し（必要なら再説明して）、全員が投票して、結果をまとめる必要があります。人数が増えるほど、この一連のコストは急激に重くなります。

特に面倒なのは欠席している人がいて、投票が集まらない場合です。そうなると、意思決定が延期されてしまいます。

現代では、意思決定のスピード自体が競争優位の1つです。決まるのが遅ければ機会損失になります。逆に、すばやく決めてすばやく試せるなら、多少の粗さは後から修正できます。意思決定の速度を失うのは、かなりの痛手になります。

なお、多数決が向いている場面とコツもある

もちろん、多数決が全部悪いわけではありません。たとえば、飲み会の店、振り返りでちょっとしたネクストアクションを決めるなど、失敗しても影響が小さい場面では有効です。

また、多数決にもコツがあります。それはvote数を1つに決めないことです。では何個にしたらいいかというと、選択肢の半分ぐらいのvote数が良いでしょう。この辺りは、詳しくは『きめ方」の論理　──社会的決定理論への招待』を参照ください。

では、どうやって決めるのがいいのか？

個人的には、参加者の意見は取り入れつつ、誰か意思決定者を1人決めて、その人が決めてしまうのが良いと考えています。

理由は単純で、責任の所在が明確になり、決定が速くなり、文脈を踏まえた判断がしやすいからです。

意思決定は、単に票を数える作業ではありません。文脈を考慮し、選択肢のトレードオフを比較し、最後に組織としてどちらを取るかを決める作業です。ここでは、参加者全員の嗜好を均等に反映させることより、全体として良いアウトカムにつながるかどうかのほうが重要です。前述の通り、この方法であれば一定のスピード感を保ちやすく、試行錯誤もやりやすくなります。

実際の運用

実際には、以下のようなステップで意思決定するのが良いでしょう。

論点と選択肢を先に整理する
関係者から意見、懸念、前提条件を集めて、1に反映する
最終決定者が判断する、その際「なぜその案を選んだのか」をドキュメントに残しておく
周知する。必要に応じて、特に影響を受ける人には個別に説明する

この流れを事前に明確にしておくと、「全員の意見を聞いたのに、なぜ反映されないのか」という不満を減らしやすくなります。

大事なのは、全員の意見を全部採用することではありません。全員の意見を聞いたうえで、何を採用して、 何を捨てたか を明確にすることです。

採用されなかった意見への対処

もちろん、集めた意見の中には、最終案にまったく反映されないものもあります。

ですが、それをそのまま放置しないための手当てはできます。意思決定の記録として「こういう理由から、この案を選んだ」と残しておくことと良いでしょう。必要であれば個別に話をして、懸念点がどこで扱われたのかを説明すること。これだけでも、納得感はかなり違います。

全員の案を採用できないこと自体は、悪ではありませんし、そもそも現実的ではありません。問題になりやすいのは、議論が不透明で、なぜその案が選ばれたのかがわからないことです。

まとめ

多数決をデフォルトの選択肢にするのは、あまりおすすめしません。参加者の意見は広く取り入れつつ、最後は一人の意思決定者が決める。これが、速度と質の両方を保ちやすいやり方だと考えています。

AIに初手でたたき台を作らせない

Tue, 31 Mar 2026 00:00:00 +0000

生成AIをなんらかの叩き台の作成に使うという話や記事はいくらでも出てくる。だが、AIを使って初手から完全に叩き台を作らせない方が良い。この文章も、95% は手で書いている。

理由はアンカリング効果にある。簡単に言えば、最初に提示された情報が、その後の判断を強く縛ってしまう現象のことだ。

アンカリング効果では例えば、「トルコの人口は3500万人より多いか？」と尋ねられた後に具体的な人口を推定してもらうのと、「1億人より多いか？」と尋ねられた後に推定してもらうのでは、回答結果が大きく異なる。（なお、このパラグラフのみ、AIの力を借りて補強情報をまとめている。引用した例は HBR’s 10 Must Reads on Decision-Making, Updated and Expanded より）

転じて、AIに初手で叩き台を丸ごと作らせてしまうと、その情報がアンカーとなって人間の思考を強く引っ張る。初手からAIを使ったものは結果的に、自分の考えではなく、それっぽい情報を羅列したものになりやすくなる。何よりつまらないものが出来上がる。

もちろん、全行程でAIを全く使わないわけではない。大事なのは使うタイミングである。具体的にどうすべきかというと、任意の入力手段でまずは自分が言いたいことを箇条書きで書いてしまう方法が良い。自分の言いたいことが尽きるまで、箇条書きでもキーワードでもなんでも良いので、一旦出力してしまう。（音声入力が使えれば、一旦それで話し切ってしまうが個人的にはおすすめ）

おそらく、しばらく自分で文章を書いていないと、このプロセスがひどく苦痛に感じられるだろう。でも、その状態が正しいのだと思う。

このポストでまとめたように、「文章を書くことは筋トレと同じ」というのはまさにその通りだろう。筋トレを他人にやってもらっても意味がない。筋肉が自分についた状態こそ、思考の解像度が上がっている状態である。

叩き台を最初から作らせない。それだけで、体得できるものがだいぶ変わってくるはずだ。

「やめる」決断

Sat, 28 Feb 2026 00:00:00 +0000

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

新しい取り組みを始めるのは、簡単ではありません。取り組みを始めるためのリソースを調達する必要があるからです。

しかし、新しい取り組みよりもはるかに難しいのが、すでに続いているものをやめることです。個人的にはむしろ、始めるとき以上のコストがかかると感じています。改善施策であっても、プロダクト開発であっても、進んでしまっているものを止めるのは非常に困難です。

では、なぜやめる決断を下すのが難しいのでしょうか。

やめる決断が難しい理由

ステークホルダーの存在

着手してからある程度時間が経つと、PdM、営業、CS、運用など、複数のステークホルダーが自然と関わってきます。ちょっとした勉強会や情報共有の場であったとしても、チームや組織を横断していると、自然と関わる人が増えていきます。

そこでやめる決断を下すためには、（ものによりますが）関わる人全員に説明して合意を取る必要があります。「いや、やればいいじゃん」と思われるかもしれませんが、日々の多忙な業務の中で、この心理的なハードルと準備面のハードルを超えてやめる方向で動き出すのは、簡単ではありません。

特にプロダクトでリリースしているものがある場合は、顧客が関わってくるため、さらに難易度が上がります。顧客アナウンス、関連ドキュメントの更新、社内の調整、社内外の問い合わせ対応など、整理すべきことがたくさんあります。

サンクコストが重い

やめる判断が難しい理由のもう1つは、サンクコストです。すでに多大な時間やコストを投じてしまっているので、もったいないと感じてしまうのです。この兆候は会話の中で表出することがあります。「ここまでやったのだから」「せっかくだから」といった言葉が出てきた場合は要注意です。

すでに払ったコストは戻りません。やめるための判断時は「ここまで使ったコスト」ではなく、「ここから先の期間で、続ける場合の効果および他に費やした場合の効果」で考えたほうが良いです。いま継続して払っているコストは、将来の投資機会を逃し続けるコストでもあります。今やめて別のテーマに時間を使えば、新しい機会にチャレンジできるはずです。

やめる決断を下すためのポイント

やめる決断が難しいとはいえ、実現するためのポイントがいくつかあります。私個人が意識している、やめる決断を下すためのポイントを紹介しておきます。

始めるときに、終了条件まで決めておく

前回の記事でも書きましたが、何かを始めるタイミングで一番効くのは、最初から撤退ライン（終了ライン）を決めておくことです。

例えば、

どの指標がどこまで届かなければ止めるか
どの時点で判断するか
誰が最終判断するか

このあたりを決めておくと、「ラインに満たなかったのでここでやめる」と言いやすくなります。

とはいえ、実際には引き継いだ施策やプロジェクトもあるでしょう。その場合、こうしたラインが用意されていないことのほうが多いです。その場合は新規に期限を設けても良いでしょう。例えば、現状把握 → 2ヶ月後の目標値を設定 → 2ヶ月後に検証、そこで継続/縮小/終了の判断に持ち込む、という流れです。

「やめる」決断を下せるのは意思決定者だけ

基本的に決断しやすいのは、リーダーやマネージャーのように意思決定を担う立場の人です。逆に言うと、やめる判断は現場だけでは実現が困難です。

もし意思決定の役割を担っている場合は、「やめる」判断が長期的に大きな効果をもたらすことを意識しておいてください。自分にとっても簡単ではないかもしれませんが、チームメンバーは尚更難しいと感じているはずです。ちなみに書籍『みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた』では、組織重力の3法則として以下のように書かれています。

承認した最上位の人間が止めない限り動き出したプロジェクトは止まらない。

やめる決断をするときは、胃の中がキリキリするかもしれません。それでも長期的にみて正しい判断であることを信じて、勇気を持って決断しなければなりません。

やめるときは「結論」だけでなく「ストーリー」を語る

当然ながら「やめます」と話すだけだと、ステークホルダーや特に尽力してきたメンバーに納得感は生まれません。悪い知らせほど、背景の説明が必要です。

説明をする際は、できるだけ透明性を持って伝えることが重要です。例えば「戦略的見直し」といった抽象語で本音を誤魔化そうとしても、現場ではさっぱりわかりません。下手をすると不信感が募るだけになります。

それよりは、現状の診断、基本方針、次の行動をストーリーとして語ったほうが良いです。（なお、このスキーマは、書籍『良い戦略、悪い戦略』にあるものと同様です。戦略の話は別の記事で）

ストーリーを伝えるときは、少なくとも次の項目を押さえておくと納得感が高まります。

いま自分たちがどんな状況にあるのか
なぜ今やめる必要があるのか
組織としての大きな方向性は何か
この先何を目指すのか、どう行動するのか

伝える順番とタイミングを事前に設計する

やめる施策やプロジェクトの対象には、たいていキーマン、サブリーダー、関連部署のリーダー、現場メンバーなどが関わっています。ステークホルダーが多いほど、誰に・いつ頃・どの順番で話すかを意識しておくと良いです。これだけで着地の衝撃がだいぶ変わります。

順番を間違えると、意図しない形で話が先に伝わり、余計なハレーションが生まれます。そのため、「悪いことを伝えるためのコミュニケーション戦略」を先に設計しておくべきです。具体的には、簡易的ではありますが、次のように設計するイメージです。

キーマンに1on1で伝える、明後日までに実施
関連リーダーに説明して合意する（影響範囲、調整事項）、来週までに実施
実行メンバーに全体説明する + 問い合わせを個別に受けられるようにする、月末に実施
必要なら全社にも共有する（要点、問い合わせ窓口）、翌月初旬に実施

より詳細には書籍『レジリエントマネジメント』のChapter4が参考になります。

まとめ

始めるより、やめるほうが難しい。冒頭に述べたように、これは改善施策でもプロダクト開発でも同じです。やめる決断を下すために、

始めるときに終了条件を決めておく
引き継ぎ案件は期限付きを新たに設定して判断ポイントを設ける
サンクコストではなく、今後続けた場合とやめた場合の効果で判断する
最終的には、心理的ハードルを乗り越えて、意思決定者（リーダー）がやめる判断をする

を意識してみてください。わかっているけどサンクコストを払い続けている案件がないか、考えてみても良いかもしれません。

定例ミーティングのなくし方

Mon, 23 Feb 2026 00:00:00 +0000

本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

この記事では、定例ミーティングが増える理由と、その定例ミーティングを減らす方法について書いていきます。

まず個人的な定例ミーティングの捉え方として、「定例ミーティングは必要悪」だと思っています。同期的に人の予定を抑えることから、コストが非常に高いのです。ただし、意思決定や腹落ち感の醸成などの効果も大きいためゼロにはできません。参加者の役割にももちろん依存しますが、基本的にはパフォーマンスを出すためには少なければ少ないほどいい。

マネージャーという立場で考えると、ミーティングはどうしても多くなりがちです。外部調整や部門横断の相談も多く、カレンダーはすぐに埋まっていきます。そうなると、予定調整そのものがだんだんパズル化してきます。この状況が、定例ミーティングを増やす方向に自然と働きます。

なぜ定例ミーティングが増えるのか

定例ミーティングが増える理由は、主に3つあります。

1つ目は、予定調整コストが高いことです。「誰がどこで空いているか」を毎回確認するのは、地味に大変です。実際、その都度調整しようとしても、全員の空き時間を見つけるのが難しく、結局「毎週この時間で固定しましょう」となりやすく増えていきます。

2つ目は、「念のため」の招待と情報共有の不安です。主催者側には「呼ばないと後で揉めるかもしれない」「情報共有の漏れを防ぎたい」という心理があり、本来は議事録共有で十分な人まで招待してしまうことがあります。参加者側にも「自分だけ取り残されるかもしれない（FOMO）」という不安や、「断ると角が立つ」という同調圧力があり、とりあえず出席が増えていきます。ちなみに参加者が増えた場合のミーティングでは、参加者が内職する可能性が上がるという結果もあります。(参考参照)

3つ目は、意思決定の責任分散と過度な合意形成です。誰か一人が決める責任を避けるために、「みんなで集まって決めた」という状態を作る目的で会議が設定されることがあります。加えて、事前根回しや全員の納得を重視しすぎると、情報伝達ではなく「顔合わせ」や「儀式」としての定例が増殖します。

つまり、定例は予定調整の合理性に加えて、組織心理の要因も重なって増えるわけです。

それでも、定例は増やしすぎないほうがいい

問題は、合理性を積み重ねた結果、カレンダーが定例だらけになることです。

本来やりたい仕事に使う時間、特に集中して考える時間が削られていきます。チームの生産性は、集中時間をどれだけ確保できるかでかなり左右されるので、定例ミーティングは冒頭に述べたように少ないほうが良いです。

では、どうやって減らすか。以下では個人的に効果があった方法を紹介します。

定例ミーティングをなくす方法

1. 最初から終了日を決める

定例を作るときは、できるだけ短い期間で取り、終了日時を必ず設定します。

例えば「このテーマは3か月で一区切り」と思うなら、3か月だけ定例を入れる。最初から1年やエンドレスで入れない。これだけで、かなりの会議が自然に整理されます。Google CalendarやOutlookの定例設定では、終了日を入れるのは簡単なので、新規に定例を作るときは、必ず入れるようにしましょう。

終了しても誰も困らないまま消える定例は、そもそも不要です。

2. 節目で定例をいったん全部消す

年末年始や期の変わり目など、区切りの良いタイミングで定例を一度すべて消す方法もあります。

必要な定例ミーティングは、結局また設定されます。逆に再設定されないものは、なくても回るということです。

「一度やめてみる」は、継続の惰性を断ち切るのに効きます。

なくしきれない場合のコスト削減

全部はなくせない前提でも、定例ミーティングのコストを下げる余地はあります。

1. 頻度を下げる

毎週開催しているなら、「本当に毎週必要か」を、ミーティングの終わり際にでも参加者同士で振り返ってみる手もあります。隔週に変えるだけでも、時間がかなり戻ってきます。5人参加で1時間の定例が隔週になれば、月間で10時間、年間120時間ほど集中する時間が増えます。

2. 参加人数を絞る

定例は、参加者を増やすのは簡単です。OutlookやGoogle Calendarでも、予定を転送すればすぐ増える。一方で減らすのは心理的に難しい。突然、参加者を削除したら「なんで？」となるかもしれません。

このときは、SlackやTeamsのチャットで次回以降の参加をオプトインにする方法が使えます。具体的には「参加したい人だけリアクションしてください」としておくと、自然と人数を絞り込めます。

まとめ

定例ミーティングが増えるのは、予定確保や調整コストだけでなく、情報共有の不安や責任分散の力学もあるからです。ただ、それを放置すると集中時間が失われます。

だからこそ、

定例には終了日時を入れる
節目でいったん全部やめる
頻度と参加人数を見直す

この3つあたりを意識するだけでも、一定の効果があります。というわけで、定例ミーティングの見直し、ぜひやってみてください。

参考：おすすめの書籍

ミーティング関係でおすすめの書籍がいくつかあるので紹介しておきます。

本文で言及していた、参加人数が増えると内職する人が増えるという結果も載っている書籍です。

amazon流でとても有名な、「会議冒頭で黙読する」を紹介されている書籍です。パワポやスライドを作るのが個人的に好きではないので、かなり参考にしています。

ミーティングというのは、ファシリテーターの振る舞いによって大きく成果が変わります。例えば、「今日は自由に話し合いましょう！」と投げかけても「シーン」となってしまうようなのは、ファシリテーターの振る舞いが不十分な例です。じゃあ、どうしたらいいかというのを、体系的に解説されている書籍です。

プログラミングは今が一番楽しい

Sun, 15 Feb 2026 00:00:00 +0000

AIコーディングの進化に伴い、特に2026年に入ってから、プログラミングに対する自分の見方がかなり変わってきました。現時点で考えていることを、いったん記録として残しておきます。あとで振り返ったら面白いと思うので。

なお、この記事はAIによる「てにをは修正」「タイポ修正」などの校正は入っていますが、内容そのものはすべて自分で書いています。

初めてのプログラミングは面白くなかった

Hello World を初めて書いたのは大学1年生のプログラミングの授業でした。SNSを見ていると「小学生から書いていました」という人も結構いますが、私はそういうタイプではありません。

大学の授業で最初に学んだ言語は Java。最初はマジでわからなかったです。そもそもプログラミング以前に、PATHを通すための環境変数の設定で詰まりました。MacとWindowsを両方使っていたこともあり、特にWindowsの設定画面 + DOS画面と格闘していた記憶があります。

この時期は「プログラミングが面白い」とはそこまで思えていませんでした。CLI上で for や if の分岐を書いて System.out.println() で出力するだけだと、あんまりテンションが上がらなかったためです。

プログラミングが面白くなる転機は研究室だった

転機になったのは大学3〜4年生の頃、研究室に所属してゼミのプロジェクトに携わり始めてからです。企業連携の取り組みがあり、プログラミングで現実世界につながる、誰かの役に立つものを作れる機会を得ました。

この頃から、プログラミングが一気に面白くなりました。プログラミングをはじめとして情報科学全般をもっと学びたいと思い、本気で勉強し始めました。CPUの仕組み、オペレーティングシステム、ネットワーク、データ構造とアルゴリズム、他にもGoF のデザインパターンを初めて学んだのもこの時期です。いま振り返ると、デザインパターンを使いたくて使う、みたいなひどい設計もかなりやっていました。卒論で書いた Chain of Responsibility は、間違いなく不要でした。

その後、大学院ではコンピュータネットワークの研究室に所属しました。研究領域はオーバーレイネットワークです。インターネット上で別のネットワークを組み、その上で最適なルーティングを行うような研究をしていました。この時一番書いていたのは C++ です。他にもちょっとしたスクリプトは Ruby で書いていました。C++はかなり大変でしたが、深夜まで悪戦苦闘して動いた瞬間はアドレナリンが出まくっていた記憶があります。

社会人5年目でもう一度コードにのめり込んだ

社会人になって最初は、いわゆるシステムエンジニア寄りの仕事だったので、オフィス系のドキュメントと向き合う時間が多かったです。プログラミングは本業では5%もなかったと思います。

ただ、思うところがあって5年ほど経ってからグループ内の別会社へ転籍し、ひたすらコードを書く仕事に移りました。ここが2回目の大きな転機でした。学生時代に感じた「プログラミングが楽しい」という感覚が、はっきり戻ってきました。

当時は会社の費用で技術書を買える制度もあり、技術書を読み漁っては、そこで得た知識を実装に応用する日々でした。気づけば、帰る時間が遅くなるくらい夢中で書いていました。

だいたいクラウドが浸透し始めた頃です。自身は WebRTCプラットフォーム開発をしていて、バックエンドやインフラを中心にクラウドを使って設計、構築していたのは本当に面白かったです。同時期に、（多分rebuild.fmで知った）ChefやAnsibleから冪等性という言葉に感銘を受けましたが、運用するにつれて現実の厳しさを知り、もう全部 disposable が一番だと思ったのもこの頃です。

DevOpsのチームに所属していたので、開発だけでなく運用にも携わっていました。この時は厄介なバグもたくさん経験しました。あまり詳細には書けませんが、たとえばグローバル分散環境でネットワークレイテンシーが絡む問題を解決できた瞬間は、いまでもよく覚えています。

その時の本番環境でしか再現してくれない不具合を切り分けながら潰していく過程は、しんどいけど最高でした。切り分けするにつれて原因がだんだん見えてきて、仮説を検証しながら修正して実際に動いた瞬間は最高なんです。

マネジメントに寄るほどコードは遠ざかった

その後、やりたいことが変わっていったこともあり、徐々にポジションが変わって、マネジメントに近い仕事へ移っていきました。その過程で私自身の興味の変遷もあって、一時期は人事も経験しています。そして直近では R&D のエンジニアマネージャーを担当していました（プライベートの事情もあり、2026年1月末まで。現在は休業中）。

エンジニアリングマネジメントの仕事に携わると、実際にコードを書く時間は激減します。業務で必要なら書くこと自体はできますが、チームや組織全体のパフォーマンスを最大化しようとすると、少なくとも私の場合は、どうしても実装以外に時間を使う比率が高くなりました。

ただし、プログラミングの時間が完全にゼロになったわけではありません。機械学習のちょっとした勉強や検証でPythonを書いていましたし、他にも大学の非常勤講師として PWA や Flutter を教える機会もあり、一定量は毎年書いていました。

この時のプログラミングも面白いと言えば面白いのですが、やっぱり本番環境に対して書いている時に比べるとちょっと物足りない感じはありました。プライベートで作りたいものもありましたが、家族との時間を優先するポリシーでまとまった時間も取れないので、タスクリストに積まれたままでした。

ただこの状況が変わり始めます。

Claude Codeから始まった進化の傾き

1年弱前、Claude Code を触り始めました。Claude Code以前のAIコーディング体験は、主に GitHub Copilot の「Tab で補完する」スタイルでした。それはそれで便利でしたが、Claude Codeを初めて触った時に「これは一線を超えたな」と感じました。

もちろん、かなり厳しいコードも出てくるので手直しも必要で、まだ人の関わる余地はかなりありそうだなと思っていました。

ただ2026年に入ってから、最新のLLMを使った Codex App や Claude Code、Antigravity を触るにつれて、さらにもう一段変わった感覚があります。もちろん、以前と同様にまだうまくいかないことも多いし、手直しが必要なこともあります。でも「ここまで書けるなら十分に使える」「これぐらいで十分では」と思える場面が明確に増えました。

この感覚が本記事のタイトルにつながっていきます。

結局、いまが一番楽しい

AIコーディングでの体験を重ねるにつれて、結局何が言いたいかというと、ものづくり、そしてプログラミングそのものが、いまはめちゃくちゃ楽しいということです。

思いついたものをすぐ形にできる感覚は、過去と比べても段違いです。以前は「何か作ろう」と思っても腰が重かったのですが、最近は「ちょっと作ってみるか」くらいの軽さで始められる。この変化はかなり大きいです。ライフステージが変わるにつれて、まとまった時間を取りにくくなる中では特にそう感じます。

もう1つ楽しくなった要因は、様々なものの学習ハードルが劇的に下がっていることです。難解な技術や概念にぶつかっても、今は LLM と議論すれば、かなり短時間で理解の足場が作れます。また、NotebookLM のようなツールもあり、プライベートの片手間にマルチモーダルでの学習もできるようになっています。これも、学習のハードルを大きく下げてくれています。

プログラミングを始めてから20年以上経つわけですが、プログラミングそのものが一番楽しいのは現在になりました。バグと悪戦格闘する時間は確かに減っていますが、実際に何かを作って物が動いた瞬間をすぐに体験できるのは、やっぱり最高です。

これから確実に変わること

約1年前、ティム・オライリーが The End of Programming as We Know It を書きました。オライリー氏の記事を（恣意的ですが）ざっくりまとめると、以下のようなポイントになると思います。

プログラミングの「終わり」ではなく、かつてアセンブリから高級言語へ移行したのと同様に、AIという新たな抽象化レイヤーによる「進化」である
AIがコード記述（How）を支援することで、人間は解決すべき課題や設計（What）により集中できるようになり、開発の民主化と生産性向上が加速する
過去の技術転換と同様、この変化は開発者の職を奪うものではなく、AIを使いこなすことで新たな機会やより高度な役割を創出する

AIによってソフトウェアエンジニアの作業が減るという記事もよく見ますが、以前と同じような役割のエンジニアの仕事が減るだけであって、AIコーディングのオーケストレーションエンジニアといったような役割がどんどん増えていくんだと思います。

また、組織設計もかなり変わるはずです。これまで主流だった2pizzaチームの形も、AIネイティブな前提で再定義されると思います。従来のプロダクトトリオ（PM、デザイナー、エンジニア）の分担も確実に変わるでしょう。

マネージャーにとってもかなり面白い時代です。少人数でAIを前提にプロダクトを作るチームは、スタートアップだけでなく大企業でも増えていきます。現状の組織は、おそらく従来型の構成やプロセスで動いているはずです。今後は将来からバックキャストして、AIネイティブな組織・プロセスづくりを積極的に先導していく動きが必要になり、マネージャーが大きな役割を果たすことになると思います。もちろん役割の中には、変わるものもあれば、変わらないものもあるでしょう。前回の記事は、それでも変わらないものがあると考えて記しています。

何もわからん

これまで私は、ソースコードレビューやステークホルダー説明をはじめとした人間の役割は長く残るだろうと思っていました。一定は今後も変わらない部分はあると思います。人間の信頼貯金は偉大です。

ただ最近は思ったより早く変わっていくだろうなと思っています。たとえば、レビューそのものも専用エージェントの精度が上がっていき、実用上かなりの範囲を担えるようになるのではないか、と感じるようになりました。そもそも人間のレビューにも見落としや設計上の抜けは当然ありますし、人間は完璧ではありません。高性能なLLMがこの領域を大きく置き換える可能性は十分あると思っています。

ちなみにOpenAIでは「OpenAIのエンジニアの95%がCodexを使用しており、すべてのコード変更はAIによってレビューされるという徹底した活用が行われている」（95% of engineers use Codex. 100% of our PRs are reviewed by Codex）だそうです。

もう1つ、最近のプロダクト開発では「今できること」だけを前提にしないほうがいいと感じています。半年後、1年後にAIがどこまで進化するかを見込んで設計する。その視点が、実際の戦略に入ってきています。

などといろいろ書いてきましたが、この1年の界隈の進化速度を見ていると、10年後は本当に何もわからんなと思います。

現時点で、「AIはまだまだ」「人間のほうが良いコードを書ける」という声があるのも事実です。私もその指摘自体は理解できます。ただ同時にクラウドがおもちゃ扱いされていた頃を思い出します。前提は想像以上に速く更新される。現時点の限界よりも、半年後・1年後に何が可能になるかを想像して課題設定、および意思決定したほうがよいと考えています。

あともう1つ、「最終的に責任を取るのは人間」という話もよく出ます。説明責任の観点から見れば、その通りだと思います。ただ、それがどこまで、どの形で続くかは正直まだわかりません。AIが作った説明の方が真っ当だな、と思うこともあるからです。「ハルシネーションがーーー」という声もありますが、人間もハルシネーションをたくさん生み出しています。

最後に

約20年前、Java の環境変数で詰まっていた頃の自分に、「2026年には、こんな速度で作れる時代になる」と言っても、たぶんまったくピンと来なかったと思います。

でも、実際にいまはそうなりつつある。良くも悪くも変曲点に立ち会えているのは、すごく面白いことだと思います。さて、来年の今頃に記事を読み直したら、自分がどんな感想を持つのか、楽しみです。

1時間で読み終わるエンジニアリングマネジメント本を書き始めてみる

Sat, 14 Feb 2026 00:00:00 +0000

はじめに

これまで、エンジニアリングマネジメントに関する本を何冊か翻訳してきました。どれも学びが多く、実践につながる内容です。

一方で、翻訳しながらずっと感じていたこともあります。

日本の現場にはそのまま当てはめにくい
理解はできるけれど、個人的にはあまり共感できず採用しづらい
要点は有用。だが、そこに至るまでがやや冗長で、時間がないマネージャーは読み切りにくい

私自身のN=1ではありますが、共感した部分や実践して有用だった部分を軸にして、もっと手早く読める形でまとめたいと思いました。自分自身がすべてできているわけではありませんが、そこは棚に上げつつ、こうするとうまくいく、あるいはうまくいったものを現時点でのスナップショットとして残しておきたいと思っています。

本書で作りたいもの

目指しているのは、エンジニアリングマネージャーになったばかりの人が、最初に短時間で読めて「だいたいこれぐらいやれば及第点を取れる」という内容です。

1トピックは短く
全体を30分、長くとも1時間で読み切れる
読んだ直後から使える

まずはこのブログに連載として書き、フィードバックにもよりますが最後に再編集して1冊の本にまとめられないかと思っています。¹

なお分量イメージとして近いのは『新1分間マネジャー』のようなサイズ感です。²

前提にする考え方

エンジニアやテックリードがマネージャーになるのは、ほぼ転職に近い変化だと思っています。求められるスキルセットが大きく変わるからです。

そのときに大事なのは、「唯一の正解」を覚えることではなく、文脈に合わせて使える手札を増やすことです。状況に応じて出せるカードが多いほど、現場で柔軟に対応できるようになります。もし手札が少なければ、毎回同じカードを出すことになり、うまくいかないときのリカバリーも難しくなります。

マネジメントに絶対の正解はありません。例えば、よくアンチパターンとして挙げられるマイクロマネジメントは必ずしも悪ではありません。マイクロマネジメントは平時には副作用が強い一方で、危機対応では有効に働く場面があります。厳しい状況では、壮大なビジョンを語るより、目の前のタスクをこなすことのほうが重要になることもあります。

これから扱うテーマ

今のところ、次のようなテーマを扱う予定です。

方向性を明確にして、理解と共感を得るのがすべて
環境を作ったうえで、信じて任せることの難しさ
ビジョン・戦略・戦術って結局何なんだ？
やらないことを決める重要性
「やめる」決断
意図的に採用に時間を使う
なぜ一人の責任者を決めることが重要か
なぜオーナーシップを持たせるべきか
自分がいなくても回る環境をどう作るか
1on1は有効だが必須ではない
ティーチング、メンタリング、コーチングの違いと使い分け
意思決定で多数決ばかり使わないほうがよい理由と、おすすめの決め方
マネージャーが背中を見せることで文化を築く
マネージャーが学ぶ姿勢を見せること、技術を追い続けること
マネージャーからICに戻るのは簡単ではない
信頼貯金をどう作り、どう使うか
メンバーに数年後のなりたい姿を言語化してもらう難しさと向き合い方
業績評価をどう伝え、どう納得を得るか
フィードバックを受ける/渡す技術
コミュニケーションを整えるための「取扱説明書」
判断基準や期待値を、できるだけ言語化すること
期待値を上げすぎない運用と、精神的ダメージを減らす考え方
権限が弱い状態で変化を起こす方法
社内外のネットワークがなぜ効果的なのか
ミーティングは少ないほど良い
定例ミーティングのなくし方
アカデミックな知見の活用方法と限界
ファシリテーション技術はレバレッジが効く
KPIなどのメトリクスをどう設計し、どう使い分けるか
セルフマネジメント：高いパフォーマンスを出し続ける方法
チームビルディングとふりかえり
組織デザインの基礎と「例外」を扱う視点
上司に活躍してもらう
他部署との共通言語の作り方
焦らない、楽観的に構えておく

実際に書いてみて、内容や順番は変わるかもしれませんし、このリスト自体も変わるかもしれません。最終的には、何らかの法則に沿ってカテゴライズすると思いますが、今のところは書けそうなところから書いていこうと考えています。

結局一番大事なこと

マネージャーの成果は「仲が良いチームそのもの」ではなく、どんな手段であっても、組織が出したいアウトカムを出せるかで判断されます。チームビルディングや合意形成は、そのための重要な手段の1つです。最前線でコードを書くことも、採用に時間を使うことも、部署をまたいで仲間を増やすことも、環境を整えて信じて任せることも、すべてはアウトカムを出すための手札の1つだと考えています。

というわけで、次の記事からは内容に入ってきたいと思います。お楽しみに！³

もし出版社の方で興味がありましたら、footerの連絡先までご連絡ください ↩
出版するには短すぎて難しいかもしれません ↩
反応次第で、ひっそりと終わる可能性もあります ↩

スクラムフェス大阪2025に登壇してきた

Sun, 27 Jul 2025 00:00:00 +0000

大変ありがたいことにお声がけいただいて、2025/7/19(Sat) スクラムフェス大阪2025のクロージングキーノートに登壇してきた。その時の資料は以下の通り、 SpeakerDeck にアップしてある。一部削っているが原則そのまま載せている。

全体は資料に譲るとして、1) 本記事では登壇に向けて何を考えていたか、 2) 登壇で特に伝えたかったこと、3) イベントで色々な方と話し、登壇を終えて考えていたこと、を記しておく。

登壇に向けて考えていたこと

月並みだけど、登壇の前はかなり不安になっていることが多い。当日はある程度開き直っているのだけど、それまでの数日が一番考え込んでいる。

ちなみに、クロージングキーノートで初めて登壇したのは RSGT2023 であった。RSGTのこれまでの歴代の講演を見て「これは本当に自分が話してよいのだろうか？」と、当時は心底思っていた。今回のスクラムフェス大阪でも同様に「期待に応えられるだろうか？」「この話で良いのだろうか？」と例に漏れず考えていた。結果、だいたい1週間前ぐらいから、ずっと悶々としながらストーリーを考えていた。

ストーリーを考える時は、ここ半年ぐらいのカレンダーを見直したり、読んだ書籍を見直したりしていると、伝えたいメッセージが出てくることが多い。すぐに出てこないとしても、通勤中だったり、ぼんやり買い物をしているときにふと思いつくことがある。なので、比較的新しい経験を思い出すのは一定効果があるのだと思う。

それとクロージングキーノートでいつも意識しているのは、クロージングまでのセッションで聞いた内容や、その日に廊下などでの会話を盛り込めないかどうか。今回も、直前で聴いていた@sasakendayoさんのセッションを引用させていただいたし、イベント前に参加者と話した内容を当日のトークに盛り込んでいた。

登壇で伝えたかったこと

今回のクロージングではいくつかメッセージを込めている。ただ、強いて1つ抜き出すとすれば、「自分を卑下しすぎなくていい」ということ。

なぜ、このメッセージを意図的に強調したいかというと、カンファレンスやイベントに参加するたびに元気をもらう一方で、「あぁ、これもできてないな」「〜さんのところはめちゃくちゃ頑張っている。あれは自分には難しすぎる」と凹むケースが個人的にあるためだ。特に聴いている内容によっては「それはそう！」「言ってることはわかる！だが実行に落とし込むのがしんどい！」と思っていることがよくある。

ただ、一方でそれでもやれる範囲で十分に頑張っている人がほとんどだと思う。みんな色々な環境条件・制約条件のもとで働いている。企業によっては予算制約が厳しいかもしれないし、別の企業では市場変化に苦しんでいるかもしれない。その十分な頑張りは、意外と認知・承認されることが少ない。というのも、同じ企業にいる別の同僚にとっては当たり前の制約であるためだ。

講演ではグッドウィルハンティングの1シーンの内容を引用させてもらった。ざっくり言えば「自分が選んでいなかった道は、なぜか困難や不確実性をないものとして考えてしまいがち。一方で自分が歩んできた道は苦労がわかっているから、公平に比較できない」という話。講演を聞いていると、他の発表者の講演が輝いて見えるのはこれが要因にあると思っている。

イベントで色々な方と話して、かつ登壇を終えて考えていたこと

まず前提として、イベント運営が素晴らしかった。（運営の皆様、大変お疲れ様でした＆ありがとうございました）

アジャイル系のカンファレンスやイベントに最後までいると、会場撤収の速さにびっくりすることが多い。どこか段取りが落ちていても、例外が即捕捉されて自律的に対処が進むのは見ていて本当にすごい。

それとは別に、色々な方と話していて思うのは、この同じイベントに参加している人同士であっても文脈が全然違うということ。ソーシャルメディアでは、一部の情報発信力の強い人や企業が目立つ。アルゴリズムもそれを加速している。ただ現実では、本当に色々な状態が存在しており、これはその条件で働いている中の人と話さなければ、全く気付けない。その話す機会を得られるというだけで、イベントに参加する意義があると思う。学べるところも多いし、もしかしたら相手にとって何かしら有益な話をできることもある。なので、不定期であっても参加して、他企業の方とどんどん話していきたい。

最後に、アジャイルラジオで話を伺っていた、みさコーチと少しでもお話しできたことが感激ポイントだった。かなり前のエピソードだったので、具体的に「どこに」を失念してしまってお伝えできなかったのが心残りだけど、今度の通勤でも復習したいと思う。

おわりに

というわけで、またどこかのアジャイル開発イベントでお会いしましょう！