シリーズ: Gsd (7/7)
リアルシーンGSD：コード、記事、提案の三種タスクの実戦ルーティン
前の五回でGSDの問題、メンタル、ツール、罠をすべて語った。この記事の使命はただ一つ：それらを今日すぐ使える操作マニュアルに変えること。
タスクタイプによって詰まるポイントが違い、起動の方法も違う。以下で三つの最も一般的なタスクタイプを使って、完整なGSDリズムを示す——全部使う必要はない。今日の仕事に対応するものを見つければいい。
シーン一：コード開発タスク
最もよくある詰まりポイント
- 要件が曖昧で、「終わり」の境界がどこかわからない
- AIが何かを変更したが、触ってはいけない部分を動かしていないかわからない
- バグを直したら別のバグが生まれ、ループする
- 「先に作ってからテストを補う」でテストが永遠に補われない
GSDルーティン
起動（3分）
AIにこの四つを明確に伝える：
- 今回完成させること（機能/修正、一件に限定する）
- 触れない範囲（明確に言う。AIが「触ってはいけないと思う場所を推測する」より信頼できる）
- 終わりの基準（どんな動作/出力で完成と言えるか）
- 今回の既知の制約や依存関係
タスク：userログインのJWTリフレッシュロジックを実装する
触れない範囲：ログイン/ログアウトフロー、userスキーマは触らない
完了基準：refresh tokenで新しいaccess tokenに交換でき、古いrefresh tokenは自動的に無効になる
制約：既存のauth.service.tsを使い、新しいdependencyを追加しない
実行（集中帯）
- まずAIにどうやる予定か列挙させて、確認してから動かす
- 各小ステップが終わる度（例えば一つの関数）、ローカルで動かして検証し、問題なければ続ける
- AIの出力がよくわからなければ、それはシグナル——わかってから続ける。見えないまま走らない
締め（5分）
- メインフローの手動テストを一回走らせ、happy pathが通るか確認する
- commitメッセージを書く。何を変えたかを明確に
- 補えていないテストやエッジケースがあれば、ToDoに記録する。脳に残さない
よくある罠の注意
AIがバグを直すとき、「より良くなる」と思う部分を「ついでに」直しやすい。diffの中で頼んでいない変更をよく見る——それが悪いと言っているわけではなく、何を変えたかを知ってこそ「この機能が何をするかわかる」と言える。
シーン二：記事執筆タスク
最もよくある詰まりポイント
- どこから書き出せばいいかわからず、ずっと構想中
- AIが生成した草稿がAIっぽい読み味で、直す方が書き直しより大変
- 半分書いて構造が違うと気づき、全部やり直し
- まだ公開の準備ができていない感じで、ずっと「磨いている」
GSDルーティン
起動（5分）
書き始める前に、AIを使ってまずこの二つを確認する：
-
誰が読んで、読んだ後に何を知るか
「この記事は開発者向け」ではなく、「この記事を読んだ人は、Xがどういうものかを言えて、次のステップが何かわかる」ようにする。 -
記事の骨格（H2のリスト）
各H2が言いたい論点を一文で要約する——見出し自体ではなく、「この段落で何を言うか」。骨格が正しいか確認してから書き始める。
骨格が正しければ、AIが書く草稿が正しい方向に向かう。骨格を確認せずに書き始めると、半分書いてから構造がずれていると気づき、「記事の再構造」という時間のかかるモードに陥る。
実行（段落を順に完成）
推奨のリズム：一回に一つのH2段落だけAIに書かせる。一気に全部出力させない。
一回一段落にはいくつかの利点がある：
- 各段落が終わる度にトーン、観点が自分の求めるものかを検証できる
- 自分が介入して修正するコストがずっと低い——一段落直すのは全記事直すよりずっと楽
- 各段落が終わる度に小さな進捗感がある。一気に「少しで完璧」な草稿を見せられるより、心理的に処理しやすい
AIで原稿を書く指示に加えるといい：「トーンをもう少し直接的に、前置きを少なく、『注目すべきは』のような書き出しは使わないで」——これで最も直しにくいAI語調を最低限フィルタリングできる。
締め（10分）
- 全文を素早くスキャンして、各H2の論点が明確か、冒頭と結びに呼応があるか確認する
- 自分の話し方に聞こえない文章を直す（2、3文でいい、全部直さない）
- 公開する時間を設ける——今日か明日か、決めて、守る
よくある罠の注意
「この記事はまだ準備できていない」という感覚は、99%の場合本当ではない——「見られる」ことに少し緊張しているだけだ。自分にこう問う：「この記事を読んで一人が何かを得られれば、今それを達成しているか？」そうなら、公開する。
シーン三：提案準備タスク
最もよくある詰まりポイント
- 相手が本当に気にしていることがわからず、たくさん作っても核心に刺さらない
- 情報を詰め込みすぎて、何が重要かわからなくなる
- AIが生成する提案が「テンプレート感」が強く、説得力がない
- 複数バージョンを繰り返し修正するが、バージョン間の違いに方向がない
GSDルーティン
起動（5分）
提案の起動で最も重要な一歩は、まず「相手の問題」を明確にすること——何を提案するかではなく、「相手の現在の状況は何か、達成したい結果は何か、最も気にする制約は何か」だ。
AIで「相手の視点のサマリー」を作る：
受け手：[相手は誰、どんな役割か]
彼らの現状：[現在直面している問題や課題]
彼らが望む結果：[彼らの言葉で]
彼らが最も気にする制約：[時間、予算、リスク、社内政治...]
「相手が最も気にすること」の視点から、この提案が答えるべき核心的な問いを整理してほしい。
このステップが終わったら、ずれにくいフレームワークができる。
実行（構造優先、細部は後で）
提案執筆の正しい順序：まず「提案の核心論点を一文で言う」を確認し、次に構造を展開し、最後に細部を埋める。
逆から做と代価は：たくさんの時間を細部に費やしてから、核心論点が不明確だと気づき、提案全体を大幅に書き直す必要が出る。
AIを使う推奨順序：
- 提案の一文の論点を列挙させる（3バージョン、その中から選ぶ）
- 核心論点に基づいて3-4つの支持ポイントを展開する
- 各支持ポイントにどんなデータや例が必要か（先にリストを作って、それから探す）
- 最後がレイアウトデザインとビジュアル
締め（10分）
- 「相手の視点」で素早く一読する：この提案は「なぜこの方案が彼にとって最善か」に答えているか？
- 明確な「次のステップは何か」を確認する——相手が読んだ後に何をするか、どう返答してほしいか
- バージョンに名前をつけ、「今送り出すバージョン」を一部保存する。バージョンがドリフトし続けないように
よくある罠の注意
AIが生成する提案の言語は通常「堅すぎ」——「目標を達成するために」「効果的な方法を通じて」のような充填句で溢れる。これらの文章は文字数はあるが何も言っていない。送り出す前に、こういう文章を「私たちはXをやりました、だからあなたはYを得ます」という具体的な言語に置き換える。
共通の締め儀式
どんなタスクでも、終わる前にこの三つをやって、脳が本当に「これは終わった」と言えるようにする：
- 完了条件が達成されていることを確認する（「だいたいそうかな」ではなく、「DoDリストにチェックを入れた」）
- 未解決の問題を正しい場所に記録する（対話の中に残さず、ToDoリストかメモに入れる）
- 出力を草稿の状態から出す（commit、公開、送信——本当に「出た」状態にする）
GSDを習慣にする
このシリーズは「問題を診断する」から「リアルシーンのルーティン」まで語った。すべての内容を合わせて、最終的にあなたに持ち帰ってほしいのは、この一套の日常リズムだけだ：
朝：今日の三件は何か（タスクレベルのリスト）
各件を始める前：境界と完了条件は確認したか
各件を終えた後：チェックを入れられるか、未解決の問題を記録したか
一日の終わりに：本当に完成したものはあったか
この四つの問い、特別なツールは必要ない——でもこれがあれば、あなたのAI使用効率は、ほとんどの人より一段高くなる。より優れたモデルを使っているからでも、より長いプロンプトを使っているからでもなく、何をやっているか、どこまでやれば終わりか、終わったら締められるかを知っているから。
これがGet Shit Doneだ。
シリーズ概要に戻る
この記事はGSDシリーズの最終回で、コード、記事、提案の三種タスクの実戦ルーティンを語る。完整な読書ルートと他の記事のテーマは、**GSD入門コース**に戻って確認してほしい。