人間がやることはおはようと打つだけ!Claude×Linearでタスク管理全自動化実現した方法全て教えます!
こんにちは!カドベヤAI部です!
カドベヤはAIを使いこなすメンバーがたくさん所属している「超絶アウトプットAIサイボーグ集団」を目指しています。今回もClaudeとLinearを使った「バイブタスク管理」についてお話ししていきます。
前回の記事において、プロジェクトマネジメントの従来の方法論の限界を指摘した上で、個人の爆発的なアウトプットを組織の力に変えていく「代謝のいい組織」について語りました。
前回に引き続き、カドベヤの「バイブタスク管理」を設計した取締役COO・長津孝輔に、カドベヤAI部の岡安と野田がインタビューを実施しました。Claude Codeにタスクを管理させることによって、人間のしょーもなさを全てつぶしまくるための設計とは?——AIに興味津々の2人が心ゆくまで質問していきます。
【カドベヤAI部メンバー】
取締役COO:長津孝輔
エージェント:岡安健太
エージェント:野田逸平
なお、本記事は「Claude×Linearで代謝する組織をつくろう」シリーズの第2章「バイブタスク管理 設計編」です。このあとは第3章「バイブタスク管理 実践編」と続き、カドベヤLinearオペレーションに必要なCLAUDE.mdやskillsなどをgithubで公開するつもりです(絶賛準備中)。
この記事の内容を渡してClaude Designに生成してもらったスライドはこちら。スライドで概要だけ知りたい方はSpeakerDeckでもおたのしみいただけます。それではインタビューのはじまりです。
前回までのあらすじ
長津:AIを手にした人間の生産性が100倍になってしまったいま、そのアウトプットを組織的に管理することの重要性が上がってきています。組織のタスク管理・報告・意思決定のスピードを磨きあげ、個人のアウトプットをスムースに組織のアウトプットにつなげていく「代謝のいい組織」をつくらないとAI社会では生き残れない。
アジャイルやスクラムなどの組織管理の方法論は、「人間らしさ」を前提に構築されたもの。その方法論は素晴らしいし役にたつけれど、その気になれば24時間365日文句も言わずにアウトプットを出しまくるAIがいる世界の仕事でも耐えられるものなのかどうか疑問です。
AIからくる爆発的な量の成果物を前にしたときに、おそらく人間は立ちすくんでしまう。人間は認知能力の限界がある「しょーもない存在」だから、「タスク管理は人間には無理ゲー」という前提で、カドベヤではClaudeにタスク管理をさせてしまおう!と決意しました。

…と、いうのが前回までのお話でした。若干マッドサイエンティストのような発想ですが、ものすごいハイペースでプロダクトの新機能や成果物をリリースしていくAI企業が現実に存在する時代に対応するには、人間の認知能力の限界を超えていく設計が必要だと思うんです。
第1章の最後で、本記事で扱う7つのトピックを予告しました。
- CLAUDE.md で高品質な issue を生成する
- Linear を Claude の記憶システムに組み込む
- skills でセッション間のタスク管理文脈を維持する
- Routines で自動的にタスクの健康状態をヘルスチェックする
- 定例会やスプリントのアジェンダを自動的に生成する
- 暗黙知をタスク管理の OS に変えるハーネス・エンジニアリング
- OKR による目標管理とタスク管理を一体化させる
この7つのレイヤーがどういう設計思想で組み立てられているかをお話しします。

Linearは個人の「問い」を組織で解決するまでの流れをスムースにするタスク管理ツール
長津:まずはAIネイティブなタスク管理ツール「Linear」の簡単なご説明から。Linearはシンプルで直観的なUIを持つタスクトラッキングツールです。
ひとつひとつのタスクの単位が「issue」という名前になっていて、僕はこれが気に入っている部分なのですが、todoではなくて「問題」「課題」「論点」を意味する言葉が単位になっています。

岡安:todoやタスクではなくissue。何が違うんですか?
長津:issue一覧が「やること」リストではなくて「問い」や「実現したいこと」「ゴールイメージ」のリストになるんですよ。デザインでもなんでもそうですけど、いいアウトプットっていい問いを立てることからはじまるので「issueからはじめよ」という思想が最初から搭載されているツールって、その時点でいいですよねえ。インプットした情報から良質な問いを生み出すのが人間の仕事。クリエイティビティに寄り添った哲学だと思います。

Linearはアジャイル開発向けに設計されたツールです。通常のタスク管理だとissueの締切を設定していくものですが、Cycleという概念で実行完了までの期日を管理していくのが基本です(期日の設定ももちろんできます)。いちCycleをどのぐらいの期間にするかは管理画面で設定できるのですが、1週間スプリントにすることもできるし、2週間でも4週間でもチームに合った課題解決リズムの設定をすることができます。
issueに対して「私これやります」みたいな感じで、自分をアサインして、着手したら「in progress(進行中)」。完了したら「done(完了)」していくというのは一般的なタスク管理ツールと一緒です。

野田:slack連携したら、slackからissueを立ち上げたり管理したりできるのもいいですよね。
長津:そうなんです。Linearの一番いいところは外部ツールとの連携性の高さです。更新通知がslackに飛んでくるアプリは他にもたくさんありますが、APIを使ってLinearの外から操作できることを前提として機能開発されているので「連携みが深い」というか。Linearアプリを開いていなくてもいろいろな操作をすることができるんですよね。
もちろんAIとの接続も完璧でAIとチャットするだけで全部のLinearの操作ができるような仕組みになっています。

Claude CodeにLinearを操作させて「仕事が捗る」状態を別次元に引き上げる
長津:カドベヤのCOOである僕は全部の事業の意思決定をしていく立場です。クリエイティブ部・エージェント部の2つの事業部に加えて、マーケティングセールス・人事採用・広報と3つのバックオフィス部門を見ています。それは「人間だけチーム」です。
岡安:ん?人間だけチーム…?
長津:それに加えて、新規ソリューション開発チームが2つ。instagramやTikTokの動画コンテンツを作って発信する個人的なチームが3つ。これらは僕とClaude Codeだけしかいない「AI軍団」です。毎日向き合わないといけないチームが合計10個あって、それらの全部のタスクをLinearで管理しています。

岡安:えー!10チームも見てるんですか?
長津:10個のチームがLinearの上で並走しています。ちなみに、「人間だけチーム」より、「AI軍団」の方が1日でこなすissueが多いんだよ(笑)

僕はClaudeとLinearをめちゃくちゃ連携させて使っているので、会話の中で決めた方針をClaude がしっかり覚えてくれていて、やりたいこと、やらなくてはいけないことをissueとして正確にLinear に並べてくれます。それを優先度の判断しながら、アレやってこれやってとチャットで指示を出して、AIと人間で作業分担しながら仕事をこなしいていく感じになります。
しかも、寝ている間に進捗状況を自動的にスキャンして、朝の時点でtodoの詰まりを指摘してくれるようにしていますし、成果をまとめて自動的に定例会のアジェンダも作ってくれるようにしているから、人間リーダーとして俯瞰した目線で状態を把握して意思決定ができる。

岡安:それは夢のようなタスク管理じゃないですか。メンバー全員がそんな風に仕事ができたらカドベヤは最強になるのでは?
長津:そうだよね(笑)。最近その新規事業の「AI軍団」に、僕と同じぐらいClaude Codeを触っているメンバー ーー僕はAIサイボーグと呼んでいるんだけどーー を、2人追加して「AIサイボーグ軍団」に昇格させたんだよ。
結果として、僕×AIでほそぼそとやっていた「AI軍団」の頃に比べたらアウトプットは爆増したんだけど、自分だけで完結していた「いい感じのタスク管理」に混乱が起こってしまいました。これは新しい方法に進化させないといけないと思うに至り、AIサイボーグ用のタスク管理手法をメンバー全員が使えるように進化させたんです。
CLAUDE.mdにルールを設定して「問い」を「実行可能な設計書」に即時変換

長津:みんな当然そうだと思うのですが、朝起きてから寝落ちするギリギリまで、Claudeとずーっとチャットしているじゃないですか。
野田:みんなではないと思いますが、カドベヤではそんな人ばっかりですよね(笑)
長津:Claudeとずっと会話していく日常の中で、issueが自然に起票されていくようなskill設計がまずはなにより重要です。会話の中でやろうと思ったことがあった場合、「〜やろう」とチャットで言ったらすぐにissue化されるようなskillが発動する仕組みになっているんです。
そのときに重要な点があるのですが、自然に発行されるissueが、人間から見てもAIから見ても高品質なものである必要があるということです。

issueひとつひとつに記載されている内容が「実行可能な仕様書(Executable Specification)」でなくてはならない。実行可能で、達成条件が明確に定義されたissueテンプレートを使って起票するように、CLAUDE.mdに指定しています。issueを発行する際にこちらのテンプレートを使ってもらうようにしているんです。
## Problem
何を解決するか
## Context
背景情報・関連リンク
## Goal
このIssue完了後に存在すべき成果物
## Constraints
技術的・ビジネス的な制約
## Acceptance Criteria
- [ ] 条件1(具体的かつ検証可能に書く)
- [ ] 条件2
## Implementation Notes(任意)
実装のヒントや参照先
何を持ってこのissueを達成とみなすのか(Acceptance Criteria)を必ず書いてもらうことがポイントです。「テストファーストの原則」を僕のClaudeには叩き込んでいるのですが、ひとつの課題に対してテスト項目を事前に全て書き出して、全てクリアするようにタスクを遂行。条件を満たしていない限りdoneにしないということを徹底しています。
岡安:Acceptance Criteria(AC)?をタスクの実行前に書かせるテストファーストアプローチ?を全てのissueでやるんですか?
長津:そう。「正しく動く」「改善する」みたいな曖昧表現は禁止。Yes/No で判断できる条件しか書かないように義務化。うわ。めんどくさそう…って思ったでしょ?
野田:完全にそのままの文字で「うわ。めんどくさそう」と思ってました。
長津:それが第1章で話した「人間のしょーもなさ」の部分の核心で、めんどくさそうと思ったことは人間はサボるんだよ。だからそういうことをAIにやってもらうようにする。
野田:人間がついサボってしまうようなルール厳守もCLAUDE.mdに書いておけば、めんどくさがらずに実行してくれるんですね。

長津:さらにissueの品質をあげるために、CLAUDE.mdでこんなルールも設定しています。
1. issue名は動詞で書く
2. 担当者・期日などを必ず入れる
3. issueの初期状態を明確にする
4. issueを必ずプロジェクトに紐付ける
5. コンテキスト・背景情報を記載する
6. タスクのゴール・達成条件を記載する
7. 30分以上かかりそうなものはsub issueに噛み砕く
人間が厳密にやろうとするとうわっとなってしまうようなルールでも、Claudeが頑張ってくれるので、会話しているだけで高品質なissueが次々起票されるようになっていきます。
岡安:うわー。概念はなんとなくわかりましたけど、Linearもエンジニア向けツールだし、ルールの考え方がちょっと理系というか、エンジニアっぽい発想というか。僕に使いこなせるか不安です…
長津:人間がルールを覚える必要はないよ。CLAUDE.md がプロジェクトのルールブックになっていて、Claude がそれを読んで適用する。新しく入ってきたメンバーも、自分の手で AC を書くという作業を覚える必要がなく、Claudeに依頼すればテンプレに沿ったissueが出てくる。「高品質なissue を起票しないとダメだ〜」という認知負荷すら組織から消していくのが、この設計の本質です。

LinearをClaudeの記憶システムに埋め込む ーgrounding(着地)とdistill(蒸留)
ー「Linear を Claude の記憶システムに組み込む」。これはどういうことでしょうか?
長津:Claude Code には「セッション」という概念があります。1つの会話が1つのセッションで、セッションが終わると Claudeは基本的にそれまでの会話を忘れてしまいます。最近はメモリー機能が進化してきてるけど、セッションをまたいで仕事を続けるためには、人間側がやるべきことを覚えておいて、次のセッションでまた渡す必要があります。
そこで!Linearを「セッションまたぎの記憶システム」として使うんです。
grounding — 朝の儀礼で前日の文脈に着地する

長津:僕は、セッションを開始するときにgroundingというskillを使います。「おはよう」と Claudeに打つだけで自動発火するようにしています。
groundingは「地に足をつける」「着地する」イメージで名前をつけたんですが、前日までの自分とClaudeの文脈にきちんと着地してから1日を始めるという想いが込められたskillです。
1. git pull --rebase で、作業開始前にドキュメントを最新の状態にする
2. 前回のClaudeの記憶(claude-mem の observation)を復元
3. その日のLinearの状況レポートを確認
4. 進捗が芳しくなかったり差し迫っているissueに対して「やる /やらない / スキップ」を1 件ずつ質問攻めする
つまり、おはようと挨拶するだけで、Claudeが覚えているあやふやな記憶だけではなく、その日やるべきことの優先順位・異常対応・進捗の把握がその場で完了する。スムースに昨日の続きを始めることができるんです。
「今日何やらなくちゃいけないんだっけ」と覚えておかなくてはいけない認知負荷がほぼ消えるように設計しています。
distill — セッション終わりに翌日の地図を描く

長津:1日の終わりには /distillと打つか「distillして」とClaudeにお願いします。distillは「蒸留」という意味で、次のセッションでやることと、その日の学びを抽出して翌日の自分たちに渡す作業です。
未実行アクションのチェック:会話中に「〜しよう」と合意したが実行していないタスクがないか、Claude独自のメモリではなくて実際の Linear / Git / ファイルを見て確認
振り返りサマリー:完了した作業、失敗→修正のトレース、意思決定、次にやることの振り返り
メモリキュレーション:その日の学びを feedback / project / reference の型でメモリに書き出す
パターン検出:直近2週間で3回以上出現したパターンを skill 化候補として報告
野田:「未実行アクションチェック」が最初に来るんですね。
長津:Claudeって自分のメモリ用に自前のtodoリストを持ってるんだけど、他の指示が入ったりしてコンテキストが汚れると、やると言ってたのにやらないことが結構多いんですよ。だからセッション最後の蒸留の工程の最初に「会話を遡って合意した内容の棚卸し、実体確認、未実行を即実行」を必須化しています。
岡安:このskillって Linearがどう絡んでくるんですか?
長津:grounding が「前日のLinear状態を読み込む」、distillが「今日の決定をもれなくLinearに書き出す」。Linear がセッションを跨ぐ記憶のハブになっているんですよ。Claude のセッションは消えても、Linear に書かれた issue・コメント・状態変更は永続的に残る。次のセッションでgroundingすれば、前日Linearに書き出された状態がそのまま新しいClaudeの文脈になる。

野田:Claudeの脳みそがLinearに外付けされている感じですね。
長津:そう。Linear は「タスク管理ツール」というより「Claude の長期記憶」として使っている。だから issueの品質が低いと、翌日のClaudeも低品質な記憶しか持てない。今日issueを真面目に書くことが、明日の自分たちへの最大のプレゼントになるんです。
Linear issueの健康状態を定期的にチェックして報告してもらう
ー「Routines で自動的にタスクの健康状態をヘルスチェックする」。Routines って何でしょう?
長津:Anthropic 公式の「Routines」という機能です(以前は「Scheduled tasks」と呼ばれていました)。簡単に言うと、指定した時間にClaudeによるアクションを定期実行できる仕組みです。決まった時刻に決まった指示を自動で走らせる。

カドベヤでは日次や週次でLinear issueの健康状態のスキャンをしています。
dashboard 全チーム横断進捗ダッシュボード、issueスナップショット
daily-health-propose 全チームの Issue 異常検知(14日放置 / Urgent 未着手 / Overdue)+ 対処提案
retro-week 先週の振り返りレポート自動発行
spark チーム横断の Issue 接続(意味的に関係のあるペア)の検出
entropy-scan スキル・ドキュメントの陳腐化検知
weekly-security-scan Claude Code 設定とスキル群のセキュリティ監査
まずは、全チーム横断の進捗ダッシュボードを作るために、issue状態のスナップショットを毎日確認します。そこからほったらかしのissueを検知したり、絶対やるUrgent状態のissueが未着手だったり、期限切れだったりするものを洗い出しレポートを作成するんです。
backlog状態のissueは「いつかやれるときにやる」タスクという意味を持ちますが、これが溜まりにたまっていくことがチームの精神衛生をじわじわ侵食していくのです。
人間は、いつかやろうと思っていたのに先送りにしていたことにメンタルが押しつぶされる生き物なので、2週間以上放置されているissueを自動的に掘り起こして、やるならやる!やらないなら消す!という判断をClaudeが徹底的に求めてくる仕様にすることで、チーム全体の精神衛生が保たれます。
野田:たしかに。部屋が散らかっていくこと自体よりも、ふとしたときに片づけなくちゃと思うことの方がストレスかもしれません(笑)
長津:先ほど話したgroundingスキルでは、ここで自動発行されたレポートを読むというプロセスが搭載されているので、朝おはようといった瞬間にゴミ掃除からはじめるイメージになるね。

長津:ClaudeでLinear活用を徹底的にやって、そのレポートを自動的に出しておけば、タスク管理と進捗の真実が全て見える化できるようになります。そのデータを使って、Routine機能を回すことで日次・週次・月次開催の定例会のアジェンダ作成の自動化も行っています。
日次ハドル(朝会/夕会):担当者別に昨日やったこと・今日やることをLinearから自動取得してアジェンダissueを自動発行
週次スプリント:プロジェクト別の一週間のタスク進捗と今後やろうと思っていることをLinearから自動取得してアジェンダissueを自動発行
月次定例:月次・年度の売上高をスプレッドシートから、OKRの進捗をLinearから自動取得してアジェンダissueを自動発行
Linearだけではなくて、売上高や営業活動、採用活動などの情報も合わせて拾ってくれば、データとタスクを掛け合わせたダッシュボードが毎日発行され、データに基づいたマネジメントができるようになるわけです。
Linearをgithubと連携させて暗黙知を一撃で共有する
長津:Linearはgithub連携が強力なのも大きな特徴です。
Team単位でgithubリポジトリを連携させることができ、github issueと状態を双方向連携させることが可能です。二重管理をしたいわけではなく、タスクを進めた記録がgithubに全て残っているので、後からその流れごとClaudeが参照できるログになっているのが僕にとってはありがたい。
ClaudeもLinearがgithubとつながっていることを知っているので、作業をする時の背景情報として、githubに格納されたデータを見にいきます。
適切にgithubにファイルを格納しておけば、Linearでissueを管理するための背景情報をClaudeが理解できるようになるんです。これはチーム全体のハーネス・エンジニアリングに使えます。

岡安:ハーネス・エンジニアリングとはなんですか?
長津:ハーネス・エンジニアリングというのは「Claudeを組織で使うための装備一式の設計」だと思ってください。
skill(特定状況で発火するルールブック)
hook(Pre/Post の自動処理)
CLAUDE.md(プロジェクト取扱説明書)
Routine(定期自動実行)
各種ドキュメント
・ADR(意思決定の記録)
・frontmatter 規約(artifact のメタデータ)
・命名規則(skill / コマンド / ラベル)
さっき話したスキルやCLAUDE.mdなどがひとつの「共有フォルダ」のようなところに格納されている状態をイメージしてほしいのですが、適切なドキュメントが揃っていれば、Claudeは期待通りのふるまいをしてくれるようになるんです。「ハーネス」というのは「馬具」という意味なんですが、AIの手綱を引いてClaudeを正しく動かすための方法論です。
githubは共有フォルダのようなものなので、「Claudeをみんなで同じように使う」ための装備をチームメンバーに配布・運用できるようになるんです。

会社の服務規定や各種業務マニュアルなどの静的な情報に加えて、意思決定が記録されたドキュメント(ADR)や、ミーティングの文字起こしなどをそのリポジトリの中に格納しておけば、Claudeがタスク管理をする際の文脈をまるごと共有することが可能になります。
これって、どんな組織でも起こっていることなのに一生解決されていない課題の筆頭だった「暗黙知の共有」に対するソリューションだと思っていて、AI社会が企業にもたらすものの中で最もクリティカルなことなんじゃないかと僕は思っているんですよね。

「アウトプット」ではなく「アウトカム」を重視せよ
ーすごいです。確かにClaudeにLinearを操作してもらえば、人間の認知の限界を突破するタスク管理を実現できそうな感じがしてきました。
長津:でしょー?人間の認知限界を突破することが可能になったのは、人類史で初めてのことなんじゃないでしょうか。個人のアウトプットが爆発的に増加したとしても、チームでのタスク管理は可能だし、流れをよくすれば個人のアウトプットを会社のアウトプットに変換できそうな気がしてきましたよね。
マネジメントする際に重要な観点があるので話しておきたいのですが、量的なアウトプットの問題だけではなく、アウトカムの問題を考えていかないといけなくなります。
岡安:タスクの量だけではなく質にこだわっていく?

長津:わかりやすく例えるなら「牛乳を買う」っていうissueがあったとします。
普段なら往復15分かかるスーパーだけど高速移動することで3分で牛乳を買ってくることに成功した。という場合は、効率が5倍になってアウトプットが増えたという評価をすることができるわけです。
でも、「北関東でいちばん美味しいシチューを作る」という組織の目標が本当にあったとしたら…3分で牛乳を買ってくることが本当に正しいアクションだったのかを考える必要があったりします。
もしかしたら栃木の山奥にある牧場の牛の乳をしぼってこないと意味がないみたいなことがあるかもしれないですよね。
つまり、個人のアウトプットが増えても、それが組織が求めるアウトカムにつながっている状態に持ってこれないと意味がない。問題解決の速度だけじゃなくて、それが生み出す成果の質のマネジメントが重要なんです。
岡安:目的を見失った爆速の行動をしてしまわないようにしないといけないということですかね。
長津:その通りです。ただ「営業電話をする」というイシューを10件doneすることが目的ではなく、それによって新規顧客の獲得フローが確立されなかったら意味がないし。コード10,000行書くことが重要なのではなく、その結果ユーザーの離脱率が10%下がったということが重要なんです。
これもまた人間のしょーもなさのひとつなのですが、目の前のタスクに取り組んでいるうちに「簡単に目的を見失う」という重要な欠陥があります。ここまで徹底的に人間のしょーもなさをAIでつぶしてきたからには「ClaudeとLinearでそこんとこまで解決したろやないか」という気分です。記事がすでにだいぶ長くなっていると思いますが、最後に目的を見失ってしまう人間のしょーもなさの解決に関しての話をさせてください。
すべての仕事を会社の「目的」に接続する——OKRとイシューの一体化
長津:カドベヤのClaude×Linearのタスク管理において、少し野心的で実験的な部分がここなんですが、アウトカム重視のタスク管理を実現する上で、すべてのissueが会社の目標や目的に接続されていることを理想の状態としました。
カドベヤの目標管理はOKRを導入しています。
OKRとは、Objectives and Key Resultsの略で、直訳すると「目標と主要な結果」という意味。企業が四半期で達成したい目標と、目標を達成した場合の主要な指標を定義して、それを個人の目標とリンクさせる目標管理の方法論です。
KGI・KPIは「全体の数値目標/分解した数値目標」という数字だけを指す場合が多いと思いますが、Oは「目当て」。KRは「目当てを達成するために出しておきたい状態と数字の組み合わせ」だと思ってください。
Linearにはイニシアチブとプロジェクトという項目があります。issueはプロジェクトの下にぶら下げることができて、そのプロジェクト群を「束ねる」感じでイニシアチブを設定できます。
issueを目標と接続するために、プロジェクト名にKR(主要な成果指標)を記載する設計にしています。そのKRプロジェクトをO(組織の目標)で束ねる。
Claudeがissueを起票する際には「プロジェクトと紐付ける」というルールが設定されますので、ひとつひとつのタスクをClaudeが自動的に組織の目標に接続してくれるということになるんです。

たとえば、カドベヤのエージェント部のObjective=Oは「夢中でものづくりに没頭するクリエイター集団を作る」。それに紐づく営業KRには「嗅覚が研ぎ澄まされた前傾姿勢のパートナーになってクライアント10社から褒めてもらう」というようなものあります。そこに紐づくissueとして具体的な営業活動があるわけなのですが——全てのタスクがアウトカムに向かって繋がっている状態ができあがります。
人間が目標・目的に対しての方向性を見失うということがなくります。もし仮に見失っていたとしても、その人が使うClaudeは見失っていない。
ちなみに、お客様に褒められることが目標になってるのをみられたらアホな会社だと思われるかな?笑
野田:そのリスクはありますね(笑)。確かにいま説明してもらった「目的を見失わないタスク管理」の重要性については納得感がありますが、タスクが勝手に目標に紐づいてしまっていたら、自分がLinearの画面を見た時になんかちょっと混乱しそうな気がしました。
長津:そう。そうなんです!なんかちょっと違和感あるよね。実はまだこれに関しては結果がどうなるかまで検証しきれていない機能でして…
「人間がルールを理解していなくても高品質なタスク管理が実現する」。というとレベルのことは、既に何人かと試してみて、いいことしかなさそうだなと思っているのですが、「全てのタスクが自動的に目標に紐づいている」状態まで自動化したことに関して、社内で賛否両論あるんです。どちらかというと否が多いかもしれません。
岡安:目標とタスクの関連付けぐらいは、自分で判断したいような気がします。
長津:だよね。人間は目的を見失いがちだというしょーもなさを持っているんだけど、目標と行動の紐付けまで自動でやられると抵抗感があるみたいなんだよね。
導入してみて3ヶ月後経ったら、自動的にどんどん目標が達成されている状態になっているのか?人間が目的や目標を意識しなさすぎる状態になるのか?そこがまだわからない…

すべてのタスクが自動的にアウトカム思考で実行されるようにすることは技術的に実装可能だし、理屈的にはいいことしかなさそうだけど、何か拭いきれない「堕落感」があって、なんかちょっとイヤかもしれない。という直感があるんですね。
もしかしたら、ここが人間が本当にAIサイボーグになれるかどうかの分岐点だったりするのかもしれないとすら思います(笑)

次回予告:カドベヤメンバーのClaude×Linear導入はうまくいったのか?
今日は「Claude×Linearで代謝する組織をつくろう」シリーズの第2章「バイブタスク管理 設計編」についてお話しました。最後まで読んでくれてありがとうございました。第3章「バイブタスク管理 実践編」では、以下のような内容をお伝えするつもりです。カドベヤメンバーで試してみた結果を記事にして、読者の方にskillなどをgithubで共有する予定(絶賛準備中)です。
- Claude × Linearでのバイブタスク管理の社内導入
- 人間がAIサイボーグになる瞬間
- Claudeのハーネスが機能するようになるまでのチューニング
- バイブタスク管理の際のTips
- カドベヤのバイブタスク管理を読者のみなさまにgithubで公開
カドベヤは今後も会社のAIナレッジをガンガン発信していきます。続きが気になる方は、ぜひフォローといいねお願いいたします!
↓↓↓カドベヤマガジンはこちら↓↓↓
記事を見てもカドベヤに興味を持っていただいたら、下記フォームより
面談できますので、お気軽にお申し付けください!
