あるソフトウェアエンジニアの1日（2028）
午前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週間で何を出すか」だけを毎週決める。3ヶ月先のことは、3ヶ月前になったら決める。市場も、技術も、競合も、それくらいの速度で変わるからだ。いやもっと早いかもしれない。
午後5:00 終業前の確認
仕事を終える前、僕は毎日5分だけ、ある問いを自分に投げかけることにしている。
今日、自分が手作業でやった作業の中で、AIに任せられたはずのものはなかったか？
今日のリストを見返す。
- 監査ログCSVのロール列追加。エージェントが書いた。レビューだけ僕。これはOK。
- 検索p95調査。候補列挙はエージェント。原因特定は僕。これは妥当。
- Slackでの議論。全部僕がやった。これは意思決定であり、人間の仕事だ。OK。
- 朝、競合プロダクトの新機能リストを目視で確認した。10分くらい。これはもっと自動化できたな。
明日の朝までに、競合プロダクトのリリースノートを毎週自動でスキャンし、自社プロダクトと比較したサマリーを出すエージェントを仕込んでおこう。
エージェントに何でもやってもらうという発想は、最初は意識しないとできなかった。今は習慣になった。自分の仕事を、自分で観察して変えていく。それ自体が、AI時代のエンジニアの基礎体力だと思う。
5:30 PM 一日の終わりに
明日のために、今日のエージェントたちに新しいタスクを仕込む。
検索のp95悪化、再発防止のための回帰テストを実装完了しておくこと。監査ログ機能、デプロイ後24時間のメトリクスを監視して、何かあれば翌朝にアラートを出しておくこと。競合プロダクトのリリースノート定期スキャンの仕組みの実装が終わっていること
と、エージェントにテキストを送る。
返事は来ない。来る必要もない。
朝になれば、また夜の仕事が終わっている。
人間の仕事は、判断に寄っていく
この一日で起きていることは、単に「AIがコードを書いてくれるようになった」という話ではない。
本質的には、ソフトウェア開発のボトルネックが実装から判断へ移ることだ。いや、実は以前からボトルネックは実装ではなかったかもしれないが。
何を作るか。何を作らないか。どこまで自動化し、どこから人間が責任を持つか。どの提案を受け入れ、どの提案を退けるか。プライバシー、セキュリティ、ユーザー体験、プロダクトの方向性をどう重ね合わせるか。
AIエージェントが増えるほど、人間の仕事は正直増えていった。判断の回数もだ。
未来のエンジニアに必要なのはAIが大量に出してくる選択肢の中から、何が本当に正しいのかを見抜く力だ。
2028年のエンジニアは、コードを書かないわけではない。ただ、コードを書くことだけが、もう仕事の中心ではない。
中心にあるのは、判断すること。そして、その判断に責任を持つことだ。
という2026年の姿を妄想で書いてみました。内容は当然フィクションです。
もしかしたら、すでにこういう働き方をしている企業もあるかもしれませんし、部分的には実現しているところもあるかもしれません。スタートアップに近いほど実現している可能性が高いと思いますが、大きな企業では組織重力・組織慣性が強いので、もっと先の話かもしれません。
さて、2年後に、どこまで当たっていたか、何が外れているのかを振り返るのが楽しみです。