株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
週次定例の資料を作ろうとタスク台帳を開くと、状態は「完了」。ところが、添付された資料には「レビュー中」とあり、受け取る側からの返答も見つからない。このまま進捗を完了と報告してよいのか。PMOが短時間で現状を把握する際に、確かめたいのはこうした食い違いです。
本稿では、成果物の受け渡しを題材に、タスク台帳・課題・雑務・未報告の順で確認する手順を示します。核になるのは、「作った」「渡した」「受け取った」「内容を了承した」を分け、証拠で確認できた地点まで書くことです。以下の記入例は説明用に作成したもので、顧客の導入事例ではありません。
30分は本稿が提案する作業配分であり、短縮効果の実測値ではありません。日常の台帳と前回の合意が参照できることを前提に、タスクの照合に10分、課題に7分、雑務に5分、未報告に5分、メモの確定に3分を充てます。全件を調査し直すのではなく、次の受け渡しに関わる対象から始めます。
台帳を見る10分：「完了」の対象を成果物の版まで狭める
最初に、前回約束した提出物と、今回確認できるものを横に並べます。対象期間と確認の基準時刻を決め、台帳の作業名、予定日、担当、成果物の参照先を確認してください。前回の定例後から、次の定例までに受け渡す資料に範囲を絞ると、過去のファイルを読み直す時間を抑えられます。
たとえば、前回の約束が「説明資料の修正版をレビュー担当へ提出」なら、ファイルが存在するだけでは、約束のどこまで終わったか分かりません。修正版か、提出先は合っているか、送付した記録があるかを照合します。「完了」の文字より、何を完了とする合意だったかを先に見ます。
台帳は完了でも、見つかったファイルが下書きで、送付記録がなければ、「作成済みとの申告あり。修正版の提出は未確認」と残します。逆に、提出までが今回の約束で、該当する版の送付記録が確認できたなら、受領側のレビューが残っていても「提出完了」と書けます。受領や了承まで必要だったかは、別に確かめます。
ファイル名が似ている場合は、更新日時だけで選ばず、参照先と版の識別情報を揃えます。台帳のリンクが古いままなら、その不一致も記録します。予定日が動いている場合も、元の日付を消して順調に見せず、変更の合意があるかを確認してください。
ここでは仕事の種類を増やす必要はありません。タスク・課題・雑務を分けて現在地を見る考え方を土台に、まず「今回渡すものは何か」を確定します。その対象が決まってから、渡せない理由へ進みます。
課題を見る7分：作業の残りか、了承待ちかを確かめる
次に課題の記録を見て、受け渡しを止めている理由を探します。「レビュー中」という言葉だけでは、修正作業が残るのか、内容は揃っていて回答を待っているのかを区別できません。資料のコメント、確認依頼、前回の決定を突き合わせ、どこで止まっているかを具体化します。
修正が必要なら、何を直す担当が誰で、次に見せる対象はどの版かを確認します。回答待ちなら、誰にいつ依頼し、いつまでに返答が必要かを見ます。「回答がないので遅延」ではなく、「利用可否の回答待ち。後続の説明準備を始められるか未確定」と、確認した状態と影響を分けて書きます。
記入例は「課題：記載内容の利用可否が未確定／依頼先：レビュー担当／確認したいこと：修正後の版で説明を進めてよいか／必要な時点：説明準備の開始前」です。日付が分からなければ、空欄を想像で埋めず、確認事項として残してください。
担当者が「おそらく大丈夫」と話していても、了承済みへ書き換えるのは早計です。PMOは、判断者が見られる材料と不足を揃えます。定例へ渡す問いも、「進捗はどうか」から「この版で先へ進めると誰が確認するか」へ絞れます。重大な支障が分かったときは、定例まで保留せず、組織の連絡ルールに沿って共有します。
雑務を見る5分：送った資料を相手が使えるか確認する
課題の理由が内容に見つからなければ、受け渡しの周辺を確認します。共有リンクを送ったが閲覧権限がない、送付先が以前の担当のまま、確認してほしい箇所を伝えていない。こうした状態を、資料の完成度とは別に拾います。
見る範囲は、その成果物の受け渡しを成立させる用事です。会議の設定、閲覧権限の確認、依頼文への参照先の追記、会議資料への反映などについて、担当と必要な時点を確かめます。周辺の用事をすべて列挙するより、次の人が作業を始められる条件を確認してください。
ここでの記入例は「修正版のリンクは送付済み。受領側で開けるか未確認。送付担当が閲覧可否を確認する」です。PMO自身が開けたことを、相手も開ける証拠にしないようにします。また、権限を変える必要があっても、関係のない人まで読める設定へ広げず、必要な相手への共有を確認します。
この段階で「確認依頼を出す人がいない」と分かれば、残っている用事を引き受ける担当を決める対象になります。小さな用事かどうかより、それが済まないと何が渡らないのかを書けば、定例でも扱う理由を説明できます。
未報告を見る5分：返事のない欄を遅延と決めない
最後に、更新されるはずだった情報と、実際に見つかった情報を比べます。提出側の記録だけでなく、受領側から何を返してもらう約束だったかを確認してください。未報告を見つけるには、期待する返答の内容が先に決まっている必要があります。
海外の公開例では、GitLabの当該チームの週次の非同期更新手順が、進捗と現状、次の行動、障害を分けて記載する運用を示しています。返答欄を「順調かどうか」だけにせず、次に何をするか、何が必要かまで揃える参考になります。
受領の返事がなければ、「対象の修正版を開けますか」「内容の確認は残っていますか」「この版を後続の説明に使ってよいですか」と分けて聞きます。一度に全部を問い直すのではなく、分からない地点から質問します。すでに受領だけ確認できているなら、同じ質問を重ねず、利用可否の回答に絞れます。
返事が定例に間に合わない場合は、「提出済み、受領確認待ち。確認依頼は送付済み。次の確認担当は送付側」と残します。連絡先が違うのか、確認が終わらないのか、単に記入がないのかは、返答なしという事実だけでは確定できません。
記録を取得できなかった場合も区別します。閲覧権限がなく確認できない欄と、読める記録に回答が存在しない欄を同じ空欄にすると、次の動きが曖昧になります。「参照できず」と「参照したが該当記録なし」を書き分け、確認する相手につなげます。
残り3分：確認できた地点をメモにし、AIの下書きを点検する
会議へ持ち込む前に、食い違いを短いメモへまとめます。次は、これまでの確認結果を並べた記入例です。スライドを整える前に、この内容で何を確かめたいかが伝わるかを見てください。
- 前回の約束：修正版をレビュー担当へ提出する。
- 確認できた地点：対象の版と送付記録を確認。提出までは完了。
- 残る食い違い：台帳は完了だが、受領と内容了承の記録は見つからない。
- 定例で確かめること：後続の説明で、この版を利用してよいか。
- 次の確認：送付担当が受領側へ利用可否と回答予定を確認する。
AIを使うなら、このメモを作る直前の抜き出しと照合から始めます。対象の版に関する記述、原記録の参照先、記録時刻、矛盾する表現、見つからない項目を並べさせます。集めるのは利用を許可された台帳や記録の必要な範囲に限定し、依頼先への送信や台帳の書き換えは別の操作として扱います。
Atlassianの2026年6月8〜15日の公式更新情報には、Projects画面からRovoでプロジェクトについて質問・検索する機能の展開が記載されています。また、同社の状態更新の下書きを作る公式手順では、参照時点でベータ版とされる機能について、保存・公開の前に内容の正確性を確認する手順が示されています。
これら海外企業の公開運用・製品資料は、日本の組織に対する制度上の要件を定めるものではありません。情報の扱いと報告責任は自組織の規程に合わせます。本稿では、記録から下書きを作り、人が確かめる工程を考える材料として参照しています。
自動化の前には、人がどの記録を開き、何を照合し、どこで判断者へ確認しているかを一度書き出してください。その手順を小さな範囲でAIに任せ、人が残したメモと比較します。日次の収集まで広げる際の詳細は、日次収集で根拠や重複を検証する設計に整理しています。関連する機能の範囲は、タスクや定例会議の情報を統合する機能の説明でも確認できます。
時間内に確認が終わらなければ、調べた対象と、残っている確認を明示して区切ります。会議後は、毎週同じ欄が空く理由を見直し、提出時に版を添える、受領側が返す内容を決めるなど、受け渡し方を直します。進捗の現状把握を速める出発点は、食い違いをきれいに消すことではなく、誰が次に何を確かめれば前へ進めるかを揃えることです。