- 01要件確認
- 02計画
- 03レビュー
- 04引き継ぎ
技術への引き継ぎでも、目的を保つ。
顧客の依頼が、仕様になる前に届くことがあります。Tsumiraで顧客との関係と案件の進行をまとめ、ヒアリングや担当を記録します。タスクの記録自体がコード変更、自動テスト、本番リリースになるわけではありません。
具体的な業務の流れ
要件確認
課題、制約、範囲の判断者を記録。
計画
作業を割り振り、技術課題の管理先を確認。
レビュー
合意した成果と期待の変更を確認。
引き継ぎ
手順を共有し、残る対応を割り振り。
見積前に、必要なことを言語化。
課題、制約、確認条件を共有文書にします。窓口や未確定の前提を残し、要件が変わったときは判断と資料を更新します。最初から含まれていたかのように追加作業を割り振らず、範囲を確認してから進めます。
- 共有の要件文書と顧客判断
担当を決めて、開発を進める。
調査、実施調整、レビュー、引き継ぎのタスクを作成し、必要な工数を記録します。技術的な詳細課題をどこで管理するかはチームが決めます。案件画面にGit同期やデプロイ自動化があるとは想定しないでください。
- タスク・担当・期限・時間
引き継ぎ知識を、更新できる場所へ。
運用説明や顧客向けの手順をDocsにまとめ、確認済みのファイルをDriveで共有します。顧客への確認事項も残します。AIで説明文の草稿を作る場合も、技術的な正確さや提案アクションを担当者が確認します。
- 更新できる文書と管理された共有
実務を想定した例
活用例：顧客ポータル開発
新しいポータルの要件会議を記録します。案件計画では担当と確認日を管理し、コードは既存のリポジトリで扱います。顧客の承認フローが変わったら、仕様と範囲の合意を更新してから作業計画を変更します。 計画後に承認段階の追加を求められたら、窓口が範囲への影響を確認してから作業を変えます。別の担当が仕様と合意の一致を確認します。小さな改修で、顧客側と開発側の理解が揃い、代理担当にも変更理由が伝わるか試してください。コード履歴やデプロイ証拠は開発システムに残し、作業完了とリリースを区別します。
この機能についての質問
GitやCI/CDを置き換えますか？
いいえ。ソース管理、ビルド、テスト、デプロイは開発ツール側で行います。
要件を共同編集できますか？
Docsで共同編集と版管理ができます。社内編集を顧客の承認とみなさず確認してください。
開発課題と自動同期しますか？
この説明では連携を前提にしていません。正本の管理先を決め、必要な接続は別途確認してください。
AIは何を支援しますか？
権限の範囲で要約や草稿を支援します。技術確認と実行の判断は人が行います。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
