■ 1. 少人数チームのツール選定の行き詰まり
- 有料プランの過剰性:
- 機能が過剰で、数人のために払う額ではない
- 欲しい機能が全部そろった手頃なツールも見つからない
- ツール分散の弊害:
- 進捗、見積の管理、依頼元とのやりとりの記録がそれぞれ別の場所に分かれる
- 手間が増えるうえに全体の見通しが悪くなる
- 台帳の死:
- 使い勝手が悪くなれば更新が滞る
- 滞った台帳は誰も見なくなり、そこで終わる
■ 2. 原本の持ち方だけを決める発想
- 表示は後から化けさせる:
- データの原本さえAIに管理させておけば、表示はいくらでも化けさせられる
- 期限順の一覧が欲しければそう言えばよく、週次レポートが欲しければそう言えばよい
- ツール選定の放棄:
- ツールを選ぶのをやめ、原本の持ち方だけを決める
- 前提環境:
- 使っているのはClaude DesktopのCowork
- ファイルを直接読み書きできて定時実行の仕組みがあれば、考え方はそのまま流用できる
- 本文中の件数はすべて動作イメージを示すためのサンプル
■ 3. 運用の全体像
- 回っている4つの流れ:
- 自然言語で伝えるとAIがカードに登録する
- 平日朝9:30に未完了を自動提示させ、番号で進捗を伝える
- 原本を更新してビューを再生成する
- 週次でまとめて棚卸しする
- 3つの原則:
- 入力形式も出力形式も決めず、台帳は自然言語のまま置く
- 原本は1つに限定し、期限別ビューや一覧はすべて原本から作り直す
- 更新の起点を人ではなくAI側に置き、朝に未完了だけを突きつけてもらう
■ 4. 以前と現在の対比
- 情報の置き場所:
- 用途ごとにツールが分散していた状態から原本1つへの集約に変えた
- タスクの伝え方:
- ツールのフォームへの入力から話し言葉で伝えるだけに変えた
- 見たい形式:
- ツールが用意した画面に合わせる形から、欲しい形を言えば出てくる形に変えた
- 期限の基準:
- 形式上の締切から実質的な制約に変えた
- 取りこぼしの検出:
- 自分の記憶頼みから、AIが原本と照合して指摘する形に変えた
■ 5. 発生時の登録は話し言葉のみ
- フォームを開かない:
- 帳票の記載内容の不具合調査を今週金曜までと話し言葉で投げるだけで、番号付きのカードとして登録される
- フェーズや作業種別はAIが会話から埋め、埋まらなかったものは後で聞かれる
- 関連タスクの指摘:
- 登録時に、同システムの表示不具合が調査中のまま動いていないと指摘し、まとめて確認するか聞いてくる
- 別件だと思っていたものが同じ画面に紐づいていたという発見は、棚卸しでしか気づけない
■ 6. 番号による進捗伝達
- 自動提示される未完了一覧:
- 未完了12件を期限超過、本日期限、今週中、期限なしに区分して提示する
- 期限超過は超過日数と現在のフェーズを添えて表示される
- 番号だけで通る:
- 24番完了、工数1.5h、12番は先方待ちに変更、と伝えるだけで処理される
- タスク名を言い直す必要はない
- 更新後の応答:
- 完了とアーカイブを実行したうえで、期限を据え置きでよいか確認してくる
- 未完了件数の増減も返る
■ 7. 取りこぼしの照合
- 全部終わったは信用できない:
- 全部終わったと言った側は、たいてい全部終わっていない
- 把握している全部は直近で触ったものに限られる
- セット運用の記録による指摘:
- リリース関連3件のクローズ時に、納品書・検収書の作成送付が未完了だと指摘される
- リリース完了時にこの2件をセットで処理する運用として記録されている
- 原本を持っているのはAI側なので、この照合はAIにやらせたほうが正確
■ 8. 宙に浮いていた情報の回収
- 期限欄が1つしかない問題:
- タスク管理ツールの期限欄はたいてい1つしかなく、実際の仕事はそれでは表せない
- 契約更新では、契約書を送付する期限と先方から受領する期限は別物
- 以前は送付期限だけを入力し、受領期限は頭の中に置いたままだった
- 書けなかった情報は忘れる:
- 送付した時点でタスクを完了にしてしまう
- 受領できていないことに気づくのは期限を過ぎたあとになる
- 自然言語ならそのまま書ける:
- 今月末までに契約書を送付し、翌月10日までに受領する、と一文で書いておけばよい
- AIが期限が2つ含まれると判断し、依存関係を持たせた2件への分割を提案する
- 構造化はAIの仕事:
- まとめて書いておけば、管理単位への切り分けはAIがやる
- 入力の時点で構造を決めなくてよいという点が効いている
- 入力欄がないという理由だけで捨てていた再現条件、依頼元の言い回し、前回対応時の判断根拠も残せるようになった
■ 9. 原本1つとビューの再生成
- 二重管理の破綻:
- 期限別一覧、フェーズ別集計、週次レポートは見やすいので作りたくなる
- 原本とは別に手で保守した瞬間に破綻し、同じ情報を2か所に持つと必ず乖離する
- 更新したら両方直すと決めても守られないため、守られない前提で構造のほうで防ぐ
- 具体的な取り決め:
- タスクカードを唯一の正とする
- 一覧、期限別ビュー、レポートはすべて原本からの再生成物として扱う
- ステータス更新、期限変更、アーカイブの各操作から再生成を自動で呼ぶ
- 不整合を検査する仕組みを用意し、不一致なら異常終了させる
- ビューには手動編集禁止を明記する
- 再生成で消える注記は原本側の任意フィールドへ退避させる
- 警告ではなく異常終了:
- 集計やレポートを作るときは冒頭で必ず整合チェックを走らせる
- 警告は読み飛ばされるため、異常終了させて直さないと次に進めないようにする
- 実行日はシステム日付から取得:
- ファイル内に書かれた日付を読ませると、過去に生成されたビューのヘッダを実行日として採用する
- 結果として超過日数の計算が丸ごとずれる
■ 10. 毎朝の未完了提示
- 平日朝9:30の自動実行:
- 未完了タスクを期限順で提示させる
- 出力区分は本日着手予定、期限超過、今週中、期限なしの4つに固定した
- 日によって形式が変わると読むほうに負荷がかかり、結局読まなくなる
- 自動実行は読み取りと整形出力のみ:
- 無人実行中の書き込みは、間違っていても誰も気づけない
- 更新は人が朝の一覧を見てから対話でまとめて指示するという分担が定着した
- 識別子は登録番号:
- 一覧に振った通し番号は並び順が日によって変わるため、識別子として使えなかった
- 登録番号を先頭に置いてから、番号だけでタスクを指せるようになった
- 期限は実質的な制約:
- 見積送付期限を設定しても、送付した時点でその期限は意味を失う
- 効いている制約は契約満了日のほう
- 形式上の締切ではなく実質的な制約を入れると、一覧の並び順が実態と合う
■ 11. 週次の棚卸し
- 日次で拾えないもの:
- 月内に発注書取得が必要という注記と、設定されている翌月初の期限が矛盾しているケースがある
- 日次チェックは期限日しか見ないので素通りする
- 週次の集計項目:
- 新規登録数、完了数と工数、進行中の件数、期限超過の件数を集計させる
- あわせて暗黙知と自動化候補を抽出させる
- 判定基準の事前提示:
- 同じ判断ルールが1週間で3つのタスクに重複記録されたら、共通ナレッジとして独立文書化すべきサインとする
- 基準がないとAIは思いつきで候補を並べるが、渡すと優先度が付いた形で返ってくる
- 記録の蓄積による分析:
- 長期間動いていない積み残し、特定期間への期限集中、依頼元の偏り、外部待ちの発生状況が読める
- 依頼元が1社に6割ほど集中しているといった偏りは、感覚では出てこない数字だった
- 厳密な計測値ではない:
- 期限分布とフェーズ別比率から読み取っているだけで、今の段階では傾向の把握まで
- 省力化のために記録を集めていたら副産物として測れるものが増えたという順序
- 続けながら精度を上げていく
■ 12. 出力形式と精度の扱い
- HTMLダッシュボード:
- 一覧性が欲しくなったら作らせ、開くたびにデータソースから再取得させて内容を最新にする
- 作らせる前に接続済みのデータソースを実際に叩いて応答を確認させると手戻りが減る
- 実データが揃わないパネルは、サンプルであることを画面上に明示する
- 形式は好みでよい:
- 表でも十分で、必要なときだけ出力させる形でも構わない
- 守るべきなのは原本が1つに保たれていることのほう
- 事実誤認の前提:
- 数字を出す成果物には別のエージェントによる検証工程を挟む
- 数えられる指標と、分布から推定するにとどまる指標は分けて扱わせる
- 完了率のような集計値とコンテキストスイッチが多いという読み取りは確度がまったく違う
- 同じレポートに並べるときは区別できる書き方をさせる
■ 13. まとめ
- ツール選びをやめて原本の持ち方だけを決めたことで、入力形式にも出力形式にも縛られなくなった
- 入力欄がないせいで捨てていた情報を書けるようになり、管理単位への分割はAIが提案してくれる
- 原本は1つに限定してビューはすべて再生成物として扱い、不整合は異常終了で止める
- 平日朝に未完了だけを自動提示させ、更新は対話でまとめて指示し、自動実行に書き込みはさせない
- 登録番号を先頭に出しておくと、以降のやりとりが番号だけで済む
- 管理のための作業を減らしたかっただけだが、続けているうちに測れるものが増えたのは想定外の収穫