仕事をサボるためのn個のTODO: VS Codeを触らなくなって早x年
>100 Views
August 28, 26
スライド概要
2026年08月28日 Shima Tech Hub #20
アールスリーインスティテュートは、kintoneを中心とした クラウドサービスを活用することで お客様の継続的な業務改善をサポートします。
関連スライド
各ページのテキスト
仕事をサボるためのn個のTODO: VS Codeを触らなくなって早x年 2026/08/28 Shima Tech Hub #12 アールスリーインスティテュート 西島 www.r3it.com
こんにちは！ アールスリーインスティテュート サービスグループ gusukuユニット デベロップメントチーム マネージャー 西島 幸一郎 @k_nishijima #しまてく ハッカーズチャンプルーのなかのひと https://hackers-champloo.org/ www.r3it.com
アールスリーインスティテュート システムの受託開発と 法人向けSaaSの二本立て 創業 社員数 拠点 2000年 50名 大阪 10億 東京 沖縄 みんなの家 以上 年商 以上 www.r3it.com
https://hackers-champloo.org/2026/ ハッカーズチャンプルー 2026 10月12日（月曜日・スポーツの日） 浦添市てだこホール 市民交流室 www.r3it.com
本日のお品書き ● 「早く、俺の仕事を、奪ってくれ...」 を目標に、奮闘した(今もしている)歴史の共有 ● 良いMCPサーバ/スキルの共有 この資料は(図以外は)人間が書いています（deck使ってます） www.r3it.com
質問： ねぇそこの人間、 そろそろ仕事サボれる ようになってきた？ www.r3it.com
先に結論 人間はどんどん忙しくなっている(あれ？ ● AIが判断を求めてくる ● しかも複数同時並列に動かせる ● なんなら就業時間もなにもなく、いつ何時でも聞いてくる ということで、これに立ち向かうため、態勢を整える取り組みの共有です(答えはまだない)。 www.r3it.com
自分的、生成AIとの開発の歴史 モデルの発展とともに、任せる領域が増えていった いつまで自分の手でコードを書いていたか/見ていたか、覚えていますか？ www.r3it.com
自分的、生成AIとの開発の歴史 が、思いもよらぬ問題がいろいろ出てきた ● あちこちでアイデアをもとに実装させるが、 人間が何も見ていないコードの残骸があちこちに ※これぞ「バイブコーディングじゃ！」と楽しむのはいいが、仕事にはならない ● テスト・レビューをどうするか問題 www.r3it.com
自分的、生成AIとの開発の歴史 が、思いもよらぬ問題がいろいろ出てきた ● バイブコーディングは別に悪ではない 0-80% までは一瞬で持っていけるので、アイデアを試すのはあり。 残りの20%を詰めるのは、きっちり職人の仕事が必要と心得るべし ● テスト・レビューはどうするか、答えはまだない(このあとちょっと話す) www.r3it.com
とあるプロジェクトの進め方 新規開発も既存のリファクタリングも、基本はこのループ www.r3it.com
仕様を詰める、詰める、つめる... お花畑で夢を語るが、実はここが地獄 ● 「実装とは離れ」、欲しい機能を検討する ● 曖昧な境界や不定な挙動は後で面倒ごとになるので、 なるべく先に決めておきたい が、ひとりではなかなか難しいので...grillしてもらおう www.r3it.com
ここは Matt の skill を頼る "/grill-with-docs" で脳を焼かれろ https://github.com/mattpocock/skills ● 決めるのに迷う仕様、課題、不具合、何でも聞いてみると、 生成AIが気の済むまで質問攻めにしてくれます (なお、大きい仕様では本当に時間がかかるので、腰を据えて実行しましょう) ● おおよそMeceな状態(漏れなく、ダブりがない状態)に持っていけるので、 後が楽になる www.r3it.com
仕様が決まったら、次は技術選定 仕様(ふわっとした夢)を実世界に下ろす瞬間、ここは人間の独壇場 ● require.md でも tech.md でも なんでもいいですが、あれこれ使えと規定する ● 新規開発ならここは楽しい ● 既存の改修ならまずなにがどうなっているのかの、棚卸しを 言語選定、全体的なアーキテクチャ、なんでもご自由に！ www.r3it.com
仕様が決まったら、次は技術選定 仕様(ふわっとした夢)を実世界に下ろす瞬間、ここは人間の独壇場 ● 自由なだけに、ここは経験と知識が モロに差が出る部分 (残念ながらジュニアエンジニアに辛く、シニアエンジニアに優しい領域) ● 今回のプロジェクトではめっちゃ冒険をしてみた(そして物理の壁がw 😎どうせコード見ないんだからサーバ側はRustで、フロントエンドは マルチOSのFlutterデスクトップと、ブラウザ向けには HTML + ポーリングはHTMXで超ライトウェイト配信だだだ！ www.r3it.com
仕様と技術前提から、実装計画を作る ここが世界の境界線 ● https://github.github.com/spec-kit/ でいうところの plan.md ● 仕様を生成AIに渡して、「実装計画作ってちょ」とw ● 仕様と技術選定を踏まえて、どう作るかを決める(決めさせる)。 人間がレビューして、なにかおかしな方向に進んでいないかはチェック www.r3it.com
実装計画を、実際のタスクに割る バカでかい計画を、1つのプルリク程度の粒度にしたい ● この作業自体も生成AIにやらせるので、 ルールを決める(いわゆるAGENTS.md) ● 依存タスクがどれで、受け入れ条件はこれで、 実装時の計画やメモやテストはこう書いて、などなど www.r3it.com
実装計画を、実際のタスクに割る バカでかい計画を、1つのプルリク程度の粒度にしたい ● 「大きいタスクは分割して」はNG -> 「受け入れ条件が4個以上になったら」など具体的に このタスクづくり/分割のルールは、チーム/プロジェクトごとに いろいろあると思いますが...特に生成AIとの開発の場合、 「コンテキストウィンドウに乗る程度の粒度」というのも大事。 www.r3it.com
タスクは縦に割ろう 縦？ もしかして通じない世界線かもなので説明する... ● 機能ごとに、ひととおり動く単位で、などなど言い方は様々 ● 横に切ると、例えばデータベースにアクセスする層は 仕様で決めたすべてのテーブル、すべての読み書きが実装されるまでが 1タスク、みたいなことになって死ぬ😱 www.r3it.com
タスク管理はどうする？ ぶっちゃけご自由にw ● Linear でもなんでも、生成AIからダイレクトに使えるものならなんでもお好みで チーム開発の際、ここは共有リソースになるのでボトルネックの1つになる。 ものすごく多くの読み書きが発生するので、なるべくレイテンシーの低いものが良いと思います。 みんなのおすすめを教えてほしい！！ www.r3it.com
タスク管理はどうする？ ぶっちゃけご自由にw ● 今のプロジェクトでは https://backlog.md/ を使っています とても完璧とは言えないけど、 ● .mdファイルをCLIだけで管理する ● ファイルなのでgrepで生成AIは読む ● 最悪手で書ける という軽さは結構気にいってます。 チーム開発だとbacklog.mdでは機能不足だと思う。 ただ、ファイルの手軽さ、安定性は捨てがたいので難しい... (自分で作る？ ←またそれ www.r3it.com
忘れそうなので先に、おすそ分け 巨大なソース理解のお供に codebase-memory-mcp ● https://github.com/DeusData/codebase-memory-mcp ● よく世の驚き屋さんが騒いでいるが、試しても(試す前からも)ポンコツなのは多い ● でもこれは本当におすすめで、社内に展開して標準としましたw ● 人間が雑に調べ物するときにも超便利 ● 160以上のプログラミング言語に対応してるので、モノリポでも安心 www.r3it.com
タスクを作った(作らせた)ら... 優先度ごと、並列可能な単位で整理 ● もちろんクリティカルパスから 先に片付けるのは、大前提 ● タスクを優先度ごと並列可能な単位で整理し、 それぞれの作業用git worktreeを作成 ※注意 : タスクは必ずmainとなるブランチで。 その後作業用worktreeを作る(これを守らないとこんがらがる) www.r3it.com
働け！ 俺の代わりに！ お前が！ 仕事しろ！ www.r3it.com
やっとかよw 仕事をサボるまでの道のりが、尋常じゃなく遠い ● 言うまでもなく、 生成AIは「いい感じ」にはしてくれない、 言われたことをやるだけ ● 気づいて方向修正してくれるのも、前提条件次第 ● 困ったら質問してくる → 結果、あんまりサボれない🤣 www.r3it.com
実装・レビュー・マージの実行 このループが肝になる ● 未完了タスクを並列可能な単位でworktree → 終わったらメインとなるブランチに取り込み ● タスク間の重複や依存関係による実行順序制御、並列数を環境から計算して最 適化する、などはお手の物 ● 取り込み時に「独自検証」「敵対的検証」でレビュー ○ できればここは、別々のモデルの方が良い www.r3it.com
実装・レビュー・マージの実行 このループが肝になる ● この作業は繰り返し機械的にできる → 2回以上やる作業は、全部スキル化するんだ！ 「今やったこれスキル化して」で、またちょっと人間がサボる隙ができる。 前提条件を整えれば、全自動でひと晩でもふた晩でも実行し続ける。 www.r3it.com
が、もちろん それは漫画の中の 世界のお話 www.r3it.com
実装・レビュー・マージの実行 山盛りの苦労が襲ってくる ● Worker がサボって Orchestrator が怒り狂う > 指示書に「原因を実測で確認せよ、仮説に合う直し方を当てて落ちなくなったで終わらせるな」 「直す前後で並列 10 回以上測れ」「ignore / assert 緩め / RUST_TEST_THREADS で逃げるな」を明示 ● ちらっと見たら↑な指示をしていたが、人間がこんなこと言われたら、泣いちゃう🤣 まぁレビューが効いてる証拠ではある。 www.r3it.com
実装・レビュー・マージの実行 山盛りの苦労が襲ってくる ● 構造的にどうしても 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
が、当然全自動は壊れるw どれだけ頑張っても、完璧な仕様など作り得ないのだよ... ● あるのは美しい設計、ベターな仕様、しかない ● 仕様の隙間、実装上の制約、その他考えられる諸々の障害により、 また判断を迫られる www.r3it.com
が、当然全自動は壊れるw どれだけ頑張っても、完璧な仕様など作り得ないのだよ... ● 仕様を文字にした瞬間に腐り始めるので、 実装しつつ継続的メンテ大事 ● 改善のタスク/issueを作って、振り出しに戻る(仕様を作成する)。 つまりタスクが全然減らないwww 逆にいうと、タスク/バグ収束曲線の監視で、終了予測が可能になる。 みんな大好きバーンダウンチャート www.r3it.com
仕様のメンテは人間ではかなりしんどい 決めた仕様を書くのも読むのも、生成AI ● ファイルのリネームすら生成AIにやらせる理由はここにある ● とはいえ、本当にAI任せで、全部のドキュメントを更新し続けられるか？ → かなり頑張っても、気づけば破綻の可能性はある まだ人間の方がコンテキストウィンドウが広く、勘も働くので、 「お前な、それはあれや」と指摘してあげるしかない。いずれこの問題は解決されるはず(本当か？ www.r3it.com
ようやく: できたものを動作確認 もちろん AI側でのできる限りのテストはパス済みの前提 ● UIが絡むところは人間の好みもある ● サーバ側のログ調査 → read権限のみの権限で調べさせる(これは最近楽できる ● フロントエンドのe2eテストを頑張る？ → これは結構頑張る価値がある 気になったところはガン詰めして、またタスクを起こす → 実装のループへ www.r3it.com
ということで まとめ www.r3it.com
これは果たして「エンジニアリング」なの か？ 確かに設計から実装まで、幅広い知識が必要 ● 絵空事を現実世界に変換するのは、確かにエンジニアリングではある ● 実世界の制約をもとに、アーキテクチャを検討するのも、まだ人間の仕事 ● 早く頭の中の妄想を生成AIが読んで、具現化してほしいw www.r3it.com
はやく全部の仕事 を奪ってくれると いいな🌟 www.r3it.com
おわり www.r3it.com