---
title: 仕事をサボるためのn個のTODO: VS Codeを触らなくなって早x年
tags:  #community #生成ai  
author: [アールスリーインスティテュート](https://image.docswell.com/user/r3it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JMY5N9PJW.jpg?width=480
description: 2026年08月28日 Shima Tech Hub #20
published: August 28, 26
canonical: https://image.docswell.com/s/r3it/5PRJ47-2026-08-28-204941
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JMY5N9PJW.jpg)

仕事をサボるためのn個のTODO:
VS Codeを触らなくなって早x年
2026/08/28 Shima Tech Hub #12
アールスリーインスティテュート 西島
www.r3it.com


# Page. 2

![Page Image](https://bcdn.docswell.com/page/PJR93DGY79.jpg)

こんにちは！
アールスリーインスティテュート
サービスグループ gusukuユニット
デベロップメントチーム
マネージャー
西島 幸一郎
@k_nishijima #しまてく
ハッカーズチャンプルーのなかのひと
https://hackers-champloo.org/
www.r3it.com


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PEXQ41X4JX.jpg)

アールスリーインスティテュート
システムの受託開発と
法人向けSaaSの二本立て
創業
社員数
拠点
2000年
50名
大阪 10億
東京
沖縄
みんなの家
以上
年商
以上
www.r3it.com


# Page. 4

![Page Image](https://bcdn.docswell.com/page/3EK9Z2WPED.jpg)

https://hackers-champloo.org/2026/
ハッカーズチャンプルー 2026
10月12日（月曜日・スポーツの日）
浦添市てだこホール 市民交流室
www.r3it.com


# Page. 5

![Page Image](https://bcdn.docswell.com/page/L73WD41475.jpg)

本日のお品書き
●
「早く、俺の仕事を、奪ってくれ...」
を目標に、奮闘した(今もしている)歴史の共有
●
良いMCPサーバ/スキルの共有
この資料は(図以外は)人間が書いています（deck使ってます）
www.r3it.com


# Page. 6

![Page Image](https://bcdn.docswell.com/page/87DKPQX5JG.jpg)

質問：
ねぇそこの人間、
そろそろ仕事サボれる
ようになってきた？
www.r3it.com


# Page. 7

![Page Image](https://bcdn.docswell.com/page/VJPKNLPDE8.jpg)

先に結論
人間はどんどん忙しくなっている(あれ？
●
AIが判断を求めてくる
●
しかも複数同時並列に動かせる
●
なんなら就業時間もなにもなく、いつ何時でも聞いてくる
ということで、これに立ち向かうため、態勢を整える取り組みの共有です(答えはまだない)。
www.r3it.com


# Page. 8

![Page Image](https://bcdn.docswell.com/page/2EVVKQ2GEQ.jpg)

自分的、生成AIとの開発の歴史
モデルの発展とともに、任せる領域が増えていった
いつまで自分の手でコードを書いていたか/見ていたか、覚えていますか？
www.r3it.com


# Page. 9

![Page Image](https://bcdn.docswell.com/page/57GLQWLDEL.jpg)

自分的、生成AIとの開発の歴史
が、思いもよらぬ問題がいろいろ出てきた
●
あちこちでアイデアをもとに実装させるが、
人間が何も見ていないコードの残骸があちこちに
※これぞ「バイブコーディングじゃ！」と楽しむのはいいが、仕事にはならない
●
テスト・レビューをどうするか問題
www.r3it.com


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4EQYK3YXJP.jpg)

自分的、生成AIとの開発の歴史
が、思いもよらぬ問題がいろいろ出てきた
●
バイブコーディングは別に悪ではない
0-80% までは一瞬で持っていけるので、アイデアを試すのはあり。
残りの20%を詰めるのは、きっちり職人の仕事が必要と心得るべし
●
テスト・レビューはどうするか、答えはまだない(このあとちょっと話す)
www.r3it.com


# Page. 11

![Page Image](https://bcdn.docswell.com/page/KJ4WP1W271.jpg)

とあるプロジェクトの進め方
新規開発も既存のリファクタリングも、基本はこのループ
www.r3it.com


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LE1Y9GYK7G.jpg)

仕様を詰める、詰める、つめる...
お花畑で夢を語るが、実はここが地獄
●
「実装とは離れ」、欲しい機能を検討する
●
曖昧な境界や不定な挙動は後で面倒ごとになるので、
なるべく先に決めておきたい
が、ひとりではなかなか難しいので...grillしてもらおう
www.r3it.com


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GEWGQKGPJ2.jpg)

ここは Matt の skill を頼る
"/grill-with-docs" で脳を焼かれろ
https://github.com/mattpocock/skills
●
決めるのに迷う仕様、課題、不具合、何でも聞いてみると、
生成AIが気の済むまで質問攻めにしてくれます
(なお、大きい仕様では本当に時間がかかるので、腰を据えて実行しましょう)
●
おおよそMeceな状態(漏れなく、ダブりがない状態)に持っていけるので、
後が楽になる
www.r3it.com


# Page. 14

![Page Image](https://bcdn.docswell.com/page/47ZLWZL6J3.jpg)

仕様が決まったら、次は技術選定
仕様(ふわっとした夢)を実世界に下ろす瞬間、ここは人間の独壇場
●
require.md でも tech.md でも
なんでもいいですが、あれこれ使えと規定する
●
新規開発ならここは楽しい
●
既存の改修ならまずなにがどうなっているのかの、棚卸しを
言語選定、全体的なアーキテクチャ、なんでもご自由に！
www.r3it.com


# Page. 15

![Page Image](https://bcdn.docswell.com/page/YJ6WGZWLJV.jpg)

仕様が決まったら、次は技術選定
仕様(ふわっとした夢)を実世界に下ろす瞬間、ここは人間の独壇場
●
自由なだけに、ここは経験と知識が
モロに差が出る部分
(残念ながらジュニアエンジニアに辛く、シニアエンジニアに優しい領域)
●
今回のプロジェクトではめっちゃ冒険をしてみた(そして物理の壁がw
😎どうせコード見ないんだからサーバ側はRustで、フロントエンドは
マルチOSのFlutterデスクトップと、ブラウザ向けには HTML + ポーリングはHTMXで超ライトウェイト配信だだだ！
www.r3it.com


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GJ5MVWMMJ4.jpg)

仕様と技術前提から、実装計画を作る
ここが世界の境界線
●
https://github.github.com/spec-kit/
でいうところの plan.md
●
仕様を生成AIに渡して、「実装計画作ってちょ」とw
●
仕様と技術選定を踏まえて、どう作るかを決める(決めさせる)。
人間がレビューして、なにかおかしな方向に進んでいないかはチェック
www.r3it.com


# Page. 17

![Page Image](https://bcdn.docswell.com/page/9E293Q9R7R.jpg)

実装計画を、実際のタスクに割る
バカでかい計画を、1つのプルリク程度の粒度にしたい
●
この作業自体も生成AIにやらせるので、
ルールを決める(いわゆるAGENTS.md)
●
依存タスクがどれで、受け入れ条件はこれで、
実装時の計画やメモやテストはこう書いて、などなど
www.r3it.com


# Page. 18

![Page Image](https://bcdn.docswell.com/page/D7Y41W45EM.jpg)

実装計画を、実際のタスクに割る
バカでかい計画を、1つのプルリク程度の粒度にしたい
●
「大きいタスクは分割して」はNG ->
「受け入れ条件が4個以上になったら」など具体的に
このタスクづくり/分割のルールは、チーム/プロジェクトごとに
いろいろあると思いますが...特に生成AIとの開発の場合、
「コンテキストウィンドウに乗る程度の粒度」というのも大事。
www.r3it.com


# Page. 19

![Page Image](https://bcdn.docswell.com/page/VENY29Y4J8.jpg)

タスクは縦に割ろう
縦？ もしかして通じない世界線かもなので説明する...
●
機能ごとに、ひととおり動く単位で、などなど言い方は様々
●
横に切ると、例えばデータベースにアクセスする層は
仕様で決めたすべてのテーブル、すべての読み書きが実装されるまでが
1タスク、みたいなことになって死ぬ😱
www.r3it.com


# Page. 20

![Page Image](https://bcdn.docswell.com/page/Y79P12P4E3.jpg)

タスク管理はどうする？
ぶっちゃけご自由にw
●
Linear でもなんでも、生成AIからダイレクトに使えるものならなんでもお好みで
チーム開発の際、ここは共有リソースになるのでボトルネックの1つになる。
ものすごく多くの読み書きが発生するので、なるべくレイテンシーの低いものが良いと思います。
みんなのおすすめを教えてほしい！！
www.r3it.com


# Page. 21

![Page Image](https://bcdn.docswell.com/page/G78D45DV7D.jpg)

タスク管理はどうする？
ぶっちゃけご自由にw
●
今のプロジェクトでは https://backlog.md/ を使っています
とても完璧とは言えないけど、
●
.mdファイルをCLIだけで管理する
●
ファイルなのでgrepで生成AIは読む
●
最悪手で書ける
という軽さは結構気にいってます。
チーム開発だとbacklog.mdでは機能不足だと思う。
ただ、ファイルの手軽さ、安定性は捨てがたいので難しい...
(自分で作る？ ←またそれ
www.r3it.com


# Page. 22

![Page Image](https://bcdn.docswell.com/page/L7LM6YMRJR.jpg)

忘れそうなので先に、おすそ分け
巨大なソース理解のお供に codebase-memory-mcp
●
https://github.com/DeusData/codebase-memory-mcp
● よく世の驚き屋さんが騒いでいるが、試しても(試す前からも)ポンコツなのは多い
● でもこれは本当におすすめで、社内に展開して標準としましたw
● 人間が雑に調べ物するときにも超便利
● 160以上のプログラミング言語に対応してるので、モノリポでも安心
www.r3it.com


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4EMY5NYPEW.jpg)

タスクを作った(作らせた)ら...
優先度ごと、並列可能な単位で整理
●
もちろんクリティカルパスから
先に片付けるのは、大前提
●
タスクを優先度ごと並列可能な単位で整理し、
それぞれの作業用git worktreeを作成
※注意 : タスクは必ずmainとなるブランチで。
その後作業用worktreeを作る(これを守らないとこんがらがる)
www.r3it.com


# Page. 24

![Page Image](https://bcdn.docswell.com/page/PER93D9YJ9.jpg)

働け！
俺の代わりに！
お前が！
仕事しろ！
www.r3it.com


# Page. 25

![Page Image](https://bcdn.docswell.com/page/P7XQ41Q4EX.jpg)

やっとかよw
仕事をサボるまでの道のりが、尋常じゃなく遠い
●
言うまでもなく、
生成AIは「いい感じ」にはしてくれない、
言われたことをやるだけ
●
気づいて方向修正してくれるのも、前提条件次第
●
困ったら質問してくる → 結果、あんまりサボれない🤣
www.r3it.com


# Page. 26

![Page Image](https://bcdn.docswell.com/page/37K9Z29P7D.jpg)

実装・レビュー・マージの実行
このループが肝になる
●
未完了タスクを並列可能な単位でworktree
→ 終わったらメインとなるブランチに取り込み
●
タスク間の重複や依存関係による実行順序制御、並列数を環境から計算して最
適化する、などはお手の物
●
取り込み時に「独自検証」「敵対的検証」でレビュー
○
できればここは、別々のモデルの方が良い
www.r3it.com


# Page. 27

![Page Image](https://bcdn.docswell.com/page/LJ3WD4W4J5.jpg)

実装・レビュー・マージの実行
このループが肝になる
●
この作業は繰り返し機械的にできる
→ 2回以上やる作業は、全部スキル化するんだ！
「今やったこれスキル化して」で、またちょっと人間がサボる隙ができる。
前提条件を整えれば、全自動でひと晩でもふた晩でも実行し続ける。
www.r3it.com


# Page. 28

![Page Image](https://bcdn.docswell.com/page/8JDKPQK5EG.jpg)

が、もちろん
それは漫画の中の
世界のお話
www.r3it.com


# Page. 29

![Page Image](https://bcdn.docswell.com/page/VEPKNLKD78.jpg)

実装・レビュー・マージの実行
山盛りの苦労が襲ってくる
●
Worker がサボって
Orchestrator が怒り狂う
> 指示書に「原因を実測で確認せよ、仮説に合う直し方を当てて落ちなくなったで終わらせるな」
「直す前後で並列 10 回以上測れ」「ignore / assert 緩め / RUST_TEST_THREADS で逃げるな」を明示
●
ちらっと見たら↑な指示をしていたが、人間がこんなこと言われたら、泣いちゃう🤣
まぁレビューが効いてる証拠ではある。
www.r3it.com


# Page. 30

![Page Image](https://bcdn.docswell.com/page/27VVKQVG7Q.jpg)

実装・レビュー・マージの実行
山盛りの苦労が襲ってくる
●
構造的にどうしても Orchestrator が詰まる
RustのフルビルドやFlutterのテストを流すと、
相当に時間とメモリとディスクを費やしてしまう。
そして最後には systemd-oomd にプロセスごと kill される
●
ただし、時間はお金で買える。More Poweeeer!
EC2なら m8gd.8xlarge 32 vCPU / 128 GiB RAM / 1.9 TB NVMe SSD の Graviton4（ARM64）を1日1万円弱で使える。
NVMe SSDにcargo-targetを置くとクッソIO稼げて爆速だよ！(とAIが言っていたw
www.r3it.com


# Page. 31

![Page Image](https://bcdn.docswell.com/page/5JGLQW1D7L.jpg)

が、当然全自動は壊れるw
どれだけ頑張っても、完璧な仕様など作り得ないのだよ...
●
あるのは美しい設計、ベターな仕様、しかない
●
仕様の隙間、実装上の制約、その他考えられる諸々の障害により、
また判断を迫られる
www.r3it.com


# Page. 32

![Page Image](https://bcdn.docswell.com/page/47QYK3DXEP.jpg)

が、当然全自動は壊れるw
どれだけ頑張っても、完璧な仕様など作り得ないのだよ...
●
仕様を文字にした瞬間に腐り始めるので、
実装しつつ継続的メンテ大事
●
改善のタスク/issueを作って、振り出しに戻る(仕様を作成する)。
つまりタスクが全然減らないwww
逆にいうと、タスク/バグ収束曲線の監視で、終了予測が可能になる。
みんな大好きバーンダウンチャート
www.r3it.com


# Page. 33

![Page Image](https://bcdn.docswell.com/page/KE4WP1Z2J1.jpg)

仕様のメンテは人間ではかなりしんどい
決めた仕様を書くのも読むのも、生成AI
●
ファイルのリネームすら生成AIにやらせる理由はここにある
●
とはいえ、本当にAI任せで、全部のドキュメントを更新し続けられるか？
→ かなり頑張っても、気づけば破綻の可能性はある
まだ人間の方がコンテキストウィンドウが広く、勘も働くので、
「お前な、それはあれや」と指摘してあげるしかない。いずれこの問題は解決されるはず(本当か？
www.r3it.com


# Page. 34

![Page Image](https://bcdn.docswell.com/page/L71Y9GRKJG.jpg)

ようやく: できたものを動作確認
もちろん AI側でのできる限りのテストはパス済みの前提
●
UIが絡むところは人間の好みもある
●
サーバ側のログ調査
→ read権限のみの権限で調べさせる(これは最近楽できる
●
フロントエンドのe2eテストを頑張る？
→ これは結構頑張る価値がある
気になったところはガン詰めして、またタスクを起こす → 実装のループへ
www.r3it.com


# Page. 35

![Page Image](https://bcdn.docswell.com/page/G7WGQK1PE2.jpg)

ということで
まとめ
www.r3it.com


# Page. 36

![Page Image](https://bcdn.docswell.com/page/4JZLWZP6E3.jpg)

これは果たして「エンジニアリング」なの
か？
確かに設計から実装まで、幅広い知識が必要
●
絵空事を現実世界に変換するのは、確かにエンジニアリングではある
●
実世界の制約をもとに、アーキテクチャを検討するのも、まだ人間の仕事
●
早く頭の中の妄想を生成AIが読んで、具現化してほしいw
www.r3it.com


# Page. 37

![Page Image](https://bcdn.docswell.com/page/YE6WGZMLEV.jpg)

はやく全部の仕事
を奪ってくれると
いいな🌟
www.r3it.com


# Page. 38

![Page Image](https://bcdn.docswell.com/page/GE5MVWZME4.jpg)

おわり
www.r3it.com