爆速開発　管理本部のタスク管理アプリが1週間で育った話

お疲れ様です！SI事業本部部長の島田です。

子どもの頃、しばらく放置していたドラクエを久々に再開したとき、冒険の書はちゃんと残っているのに「……で、次どこ行くんやっけ？」となった経験、ありませんか。レベルも装備もそのまま。なのに、誰に何を頼まれていたのか、どこで詰まっていたのかが思い出せない。

AI と長い開発をしていると、セッションが変わるたびにこれに近いことが起きます。最近の AI はメモリ機能である程度は覚えていてくれるんですが、「なぜそうしたのか」「どこでハマったのか」といった細かい経緯までは引き継がれにくい。だったら、次に何をすべきかまで書いた冒険の書を、AI 自身に書かせればいい。今回はそんな話です。

管理本部向けのタスク管理アプリを AI（Claude）と一緒に作っている中で「これはコツかもしれん」と思ったことがあったので、私見を交えて言葉にしてみます。

きっかけは「タスク管理ツール、移行しない？」という声から

シスナビ内で使っていたタスク管理ツールの Backlog ですが、最近は Slack のリストや Canvas でフロー業務の管理がある程度できるようになったこともあり、管理本部以外は使用頻度がめっきり減ってしまいました。そんな中で、プランを変更するか、いっそ別のサービスに乗り換えようか？？コスト削減もしたいし。。そんな声が上がっておりました。

そこで、管理本部専用に特化したタスク管理アプリを作ってみよう！と、管理本部に承諾を得ないまま、完全に私の趣味で内製してみることにしました。利用者は最大5名。イメージは Asana のような使い心地で、そこに管理本部の業務をぎゅっと詰め込むという作戦です。名前は「task-navi」。

開発はほぼ Claude Code に任せて、私はひとりプロダクトオーナーとして「何を作るか」と「できたものが正しいか」を判断する役に回りました。

↑マイタスク画面。期日が近づくと「あとで」→「近日中」→「今日やる」へ自動で繰り上がっていきます。（画面はテスト用のデータです）

やってみたら、1週間で Phase 5 まで来た

git の履歴から開発スピードを振り返ってみるとこんな感じです。

10/2：Phase 0〜2（設計ドキュメント、MVP、受信トレイ・Slack通知・繰り返しタスクなど）
10/3：Phase 3（管理本部の業務に特化。年間の定型業務プリセット、承認タスク、会社休日の管理など）
10/7：Phase 4（ダッシュボードなど）を実装して検証環境にデプロイ、続けて Phase 5（AIでタスク作成、自動化ルール、Googleカレンダー連携）

↑Phase 3 で入れた「定型業務プリセット」。給与の支給日や勤怠の締め日を選ぶだけで、毎月・毎年の業務を繰り返しタスクとしてまとめて作れます。「休日なら前営業日にずらす」みたいな、管理本部ならではの細かいところまで入っています。

↑ボタン1つでこうなります。月次5件・年次5件、手順はサブタスクとして中に入っています。

特に印象的だったのが 10/7 の Phase 5 で、私が出した指示は1回だけ。

docs/HANDOFF_PHASE5.md を読んで Phase 5 を実装して

これだけで、約27分後には型チェック・lint・テスト（ユニット57件、結合75件）が通った状態でプルリクエストが上がってきました。（言わずもがな、マージするかどうかは私が見て決めます）

コツは「次のセッションへの引き継ぎ資料」を AI に書かせること

AI と長い開発をやると、どうしてもぶつかる壁があります。セッションをまたぐと、前の会話の細かい経緯を AI は覚えていないんですよね。毎回「えーと、前回はどこまでやったっけ」から始めると、説明するこっちも疲れるし、AI も同じ落とし穴に何度もハマる。

なので、1つのフェーズが終わるたびに、こう頼むようにしました。

Phase X の引き継ぎ資料を作って

すると AI が、次の担当者（＝次のセッションの AI）が読めばすぐ着手できる資料を書いてくれます。中身はだいたいこんな構成です。

前提（変わっていないこと）：誰向けのアプリか、やってはいけないこと
現在の状態：どこまで終わっていて、何が人の判断待ちか
開発の進め方：コマンド、ブランチの切り方、確認方法
ハマりどころ：前のフェーズで実際に踏んだ落とし穴と対処
次のフェーズの仕様の叩き台と、着手前に人に確認すべきこと

これ、人間のプロジェクトでもちゃんとやろうとするとヒジョーに面倒な作業です。さらにこれを設計書にフィードバックするとなると、リリースが優先になったりして漏れがちです。それを毎回、AI が自分の作業を振り返って書いてくれる。次のセッションはそれを読むだけでスッと走り出せる。いわば AI 同士のバトンリレーです。

昨今は AI 同士のオーケストレーションを構築したり、グラフエンジニアリング・ループエンジニアリングという概念も出てきております。私も自分で構築したことはありまして、確かにスピードは爆速になるんですけれども、今、自分が何を開発しているかの理解が追いつかなくなってしまう時がありました。現場業務終了後にやっているので仕方ないのですけれどもね。

ということで、完全に趣味でと前置きしたこともあり、自分の理解・制御の範疇で開発が収まるように、敢えてスピードを落として進めております。

うまくいかなかったこと：手元では動くのに、デプロイだけ落ちた

もちろん全部が順調だったわけではありません。

Phase 4 を検証環境にデプロイしたとき、手元では何の問題もないのにビルドだけが失敗しました。原因は、中身が空っぽのフォルダが Git に載っていなかったこと。私の手元には空フォルダが残っていたので動いていた、という、いかにも現場あるあるなやつです。

ほかにも、画面のドラッグ操作で更新処理が二重に走りかけた、というのもありました。

ここで大事だったのは、直したことよりも、この「ハマりどころ」が引き継ぎ資料にそのまま書き残されたことです。次のセッションの AI は同じ落とし穴を踏まずに済む。人間のチームで「ナレッジを残そう」と言ってもなかなか残らんのに、AI にはそれを仕組みとしてやらせられる。ここがむっちゃ大きかったです。

人がやること、AI がやることの線引き

もう一つ、引き継ぎ資料の「前提」に必ず書くようにしたのが、AI にやらせないことです。一般的に「ハーネスエンジニアリング」と呼ばれているやつですかね。

クラウドの構築やデプロイなど、お金がかかる操作は人が手で実行する（AI は手順書を書いて渡すまで）
本番に出すタイミングは、管理本部のメンバーが「使いたい」と言ってから決める（AI が勝手にマージしない）
人事・給与の個人情報が載る前提なので、ログや通知に本文を出さない。AI に渡す情報も、閲覧権限のチェックを必ず通す

実際、自動デプロイの仕組みも作れる状態でしたが、「管理本部に使ってもらって『これでいきます』って合意をもらってから」と保留にしました。作るのは AI でもできる。でも、作ったものを誰にどう届けるか、正しいかどうかの判断は人間がやる。以前の記事「AI時代における力のかけどころについて」で書いた話と、まさに同じところに着地しました。

なお、Phase 5 で入れた「文章からタスクを作る」AI 機能は、まだ実際の環境ではちゃんと動かせていません。手元ではわざと失敗させて「AI を使わずに作成」に戻れることまで確認した段階です。ここは検証環境の設定が済んでから、精度を見ていきます。