チャット、メール、口頭依頼の問題点から考える理想的なタスクの進め方

開発部エンジニアの守屋です。
ゲーム開発に関わり始めて、気がつけば30年ほど経ちました。
これまでゲーム本体の開発だけでなく、ゲーム内データベースから仕様を整理するWebサービスを作ったり、メインプログラマとして開発を支えたり、開発環境を整えたり、ゲーム開発に関わることは、かなり幅広く担当してきました。

近年は学生や開発職以外の方と話す機会が増え、タスク管理についての悩みを聞くことがあります。

「依頼されたことは覚えているけれど、どこで言われたのか分からない」
「何を優先すればよいのか、誰が対応しているのかが分からない」
「とにかく優先するものが多くて、いつも締め切りに追われている」

仕事の依頼は、電話、チャット、メール、会議など、いろいろな場所からやってきます。
一つひとつは小さな依頼でも、電話、チャット、メール、会議など、入り口がばらばらだと、次第に混乱していきます。

不具合の修正はチャットで頼まれた。
仕様の確認はメールに書かれていた。
データの差し替えはチャットの別スレッドに残っていた。
レビュー対応は会議で口頭確認した。

そして、どれが今すぐ必要で、どれが後回しでよいのかが分からなくなる。開発の仕事では、こういうことがよく起こります。

このとき作業する側にとって大切になるのが、

誰が、何を、どこまで、いつまでに行うのか

が分かること。

言葉にすると当たり前のように聞こえます。
しかし実際の現場では、依頼の内容、優先度、完了条件、判断の経緯は簡単に散らばってしまいます。

この記事では、仕事を受けて処理する側の目線から、電話やチャット、メールだけではなぜ混乱しやすいのかを整理し、チケットドリブンの必要性について考えていきます。

チケットドリブンは、管理を強めるためだけの仕組みではありません。
作業者が迷わず動けるようにし、困っている人を早く見つけ、チーム全体で仕事を前に進めるための仕組みです。

チャットの依頼、その場では分かりやすい

チャットは、とても便利な道具です。

思いついたことをすぐに書けます。
相手にもすぐ届きます。
短い確認や、ちょっとした相談にはとても向いています。

一方で、受け取った依頼を継続的に追いかけようとすると、いくつかの問題が出てきます。

スレッドやチャンネルが分かれやすい

チャットでは、話題ごとにスレッドやチャンネルが分かれます。
これは整理しやすい反面、依頼の一部が別の場所に分かれてしまうこともあります。

たとえば、最初の依頼はチーム全体のチャンネルにあり、追加の仕様確認は個別のスレッドにあり、最終判断は会議後の別チャンネルに書かれている。
こうなると、作業者は実装や対応を始める前に、まず情報を集める必要があります。

依頼、相談、雑談が混ざりやすい

チャットでは、依頼、質問、回答、補足説明、雑談が同じ流れの中に混ざりやすいです。

そのため、あとから見返したときに「結局、何をすればよいのか」が埋もれてしまうことがあります。
短いやり取りでは便利でも、作業の根拠として読み返すには少し弱くなります。

最終判断がどこにあるか分かりにくい

チャットには履歴が残ります。
しかし、履歴が残ることと、あとから判断を追いやすいことは別です。

途中で「やっぱりこちらでお願いします」「この件は一度保留で」「さっきの内容で進めます」のような発言があると、最終的な判断を探すのに時間がかかります。
作業者は、対応そのものより先に、会話の流れを読み解くことになります。

チャットは、相談や連絡にとても向いています。
しかし、作業者があとから依頼の状態や経緯を追いかける仕組みとしては、限界があります。

メールの依頼は、あとから読み解くのが大変になる

では、メールならどうでしょうか。

メールは、相手に情報を伝える手段としては便利です。
文章として残りますし、添付ファイルも送れます。
社外とのやり取りでは今でも重要な連絡手段です。

しかし、メールで来た依頼をそのまま作業の中心に置くと、別の問題が出てきます。

情報が個人の受信箱に閉じる

メールの情報は、基本的に個人の受信箱に入ります。
そのため、関係者全員が同じ情報を見ているとは限りません。

CCに入っていない人は内容を知ることができません。
途中から参加した人は、過去の流れを追うのに苦労します。

チャットとメール共通の問題

タスクの状態が見えない

メールやチャットには、タスクの状態がありません。

未着手なのか。
対応中なのか。
確認待ちなのか。
完了したのか。

これらを把握するには、本文を読んだり、返信の流れを追ったりする必要があります。
結果として、「タスクの現在地」が見えにくくなります。

依頼と議論が混ざりやすい

依頼、質問、回答、判断、補足説明が同じスレッドの中に混ざりやすくなります。

そのため、最終的に何をすればよいのかが埋もれてしまうことがあります。
作業者は、実装や対応を始める前に、まず文章を読み解く必要が出てきます。

チャットやメールは連絡には向いています。
しかし、作業者が依頼の現在地を追い続け、チームで状態を共有する用途には向きにくい面があります。

問題の本質は、情報が分散すること

チャット、メール、会議、口頭での相談、個人メモ。
それぞれの道具には、それぞれの良さがあります。

問題は、どれか一つの道具が悪いことではありません。
本当の問題は、タスクに必要な情報があちこちに分散してしまうことです。

たとえば、一つの不具合対応でも、情報はこんなふうに散らばりがちです。

場所	そこに残りやすい情報
メール	最初の依頼、添付資料
チャット	追加の質問、ちょっとした判断、別スレッドの相談
会議	最終判断、優先度の変更
口頭相談	急ぎの確認、その場の合意
個人メモ	なぜそう決めたか、どこまで確認したか

図にすると、こういう状態です。

タスクは一つなのに、必要な情報が別々の場所にあります。
この状態だと、作業を始める前に「探す」「確認する」「思い出す」時間が必要になります。
あっちを見て、こっちを見て、最後に自分の記憶まで掘り起こす。
これでは、作業を始める前から少し疲れてしまいます。

一つのタスクを進めるためには、さまざまな情報が必要です。

何をするのか
なぜ必要なのか
誰が担当するのか
優先度はどのくらいか
期限はあるのか
現在どこまで進んでいるのか
何が終われば完了なのか
関連する資料はどこにあるのか
途中でどんな議論があったのか
最終的にどんな判断がされたのか

これらが分散していると、作業そのものではなく、情報を集めることに時間を使ってしまいます。
チーム開発で本当に避けたいのは、この状態です。

理想的なタスクの進め方とは何か

では、理想的なタスクの進め方とはどのようなものでしょうか。
理想は、タスクごとに必要な情報が一か所にまとまっていることです。

この状態になっていれば、作業者は迷わず作業を始められます。
確認する人も、状況を把握しやすくなります。
後から参加した人も、過去の経緯を追いやすくなります。

タスク管理で大切なのは、単に作業を一覧にすることではありません。
チーム全員が同じ情報を見て、同じ前提で作業を進められるようにすることです。

チケットドリブンとは何か

ここで出てくるのが、チケットドリブンという考え方です。

チケットドリブンとは、作業をチケットとして記録し、そのチケットを中心に作業を進める方法です。

チケットには、作業内容、担当者、状態、優先度、期限、完了条件、関連資料、コメントなどを記録します。
そして、作業中の相談や判断も、できるだけチケットに紐づけて残します。

チケットは、飲食店の注文票のようなものだと考えると分かりやすいです。

厨房では、注文票を見れば、何を作るのか、どの順番で作るのか、特別な注意点はあるのかが分かります。
調理人は注文票を見ながら、未着手の注文を確認し、調理中に進め、できあがったら提供できる状態にします。

チケットも同じです。
何をするのか、誰が担当するのか、今どの状態なのか、何ができれば完了なのかを一か所に集めます。

重要なのは、チケットを作ること自体ではありません。
チケットを見れば、そのタスクの全体像が分かる状態にすることです。

つまりチケットは、単なる作業メモではありません。
チームで共有する、タスクの情報置き場です。
チケットがあると、まず見る場所が決まります。これだけでもかなり楽です。

チケットに書くべき情報

チケットに書く内容は、チームやプロジェクトによって変わります。
ただし、最低限、次のような情報があると作業を進めやすくなります。

項目	内容
タイトル	何のタスクかを短く表す
説明	具体的な作業内容や背景を書く
担当者	誰が対応するかを明確にする
状態	未着手、対応中、確認待ち、完了など
優先度	どの順番で対応すべきかを示す
期限	いつまでに必要かを示す
完了条件	何が終われば完了かを明確にする
関連資料	仕様書、画像、リンク、関連チケットなど
コメント	質問、回答、判断、作業メモを残す

ここで大切なのは、チケットを「あとで誰かが読める形」にすることです。
自分だけが分かるメモではなく、未来の自分や、途中から参加した人が読んでも分かるようにしておくと助かります。

状態は、最初から細かくしすぎなくても大丈夫です。
まずは次の4つを目印にすると、依頼の現在地を目で追いやすくなります。

状態	目印	作業者から見ると
未着手	○	まだ誰も手を付けていない依頼
対応中	→	いま誰かが調査や実装を進めている依頼
確認待ち	?	レビュー、判断、仕様確認で止まっている依頼
完了	✓	完了条件を満たして閉じられる依頼

チケットを書く前のミニチェック

タイトルだけで内容が分かるか
担当者が分かるか
今の状態が分かるか
完了条件が書かれているか
関連するチャット、メール、資料へのリンクがあるか

曖昧なチケットと、進めやすいチケット

たとえば、次のようなチケットは少し危険です。

タイトル: 修正する
説明: うまく動かないので確認
完了条件: 直ったら

これだと、何を直すのか、どこで起きているのか、何を確認すれば完了なのかが分かりません。担当者は作業を始める前に、まず依頼者へ確認する必要があります。

少しだけ具体的にすると、かなり進めやすくなります。

タイトル: オプション画面で設定保存後に反映されない問題を確認する
説明: 音量設定を変更して保存しても、画面を開き直すと変更前の値に戻る。
担当者: 守屋
状態: 未着手
優先度: C
完了条件: 設定保存後に画面を開き直しても、変更後の値が表示されることを確認する。

このくらい書いてあれば、作業者は最初に何を見ればよいか判断しやすくなります。
確認する人も、どこまで終われば完了なのかを共有できます。

特に大切なのは、完了条件です。

「対応する」だけでは、どこまでやれば終わりなのか分かりません。
「この画面でエラーが出ないことを確認する」
「レビューを通過する」
「指定されたデータに差し替わっていることを確認する」

のように、完了の判断ができる形にしておくと、認識違いを減らせます。

優先度は「重要そう」だけで決めない

チケットには、優先度を設定できるようにしておくと便利です。
ただし、優先度は単に「重要そう」「急いでほしい」という気持ちだけで付けるものではありません。
優先度は、チームの作業順に影響します。

あるタスクの優先度を上げるということは、別のタスクの着手が遅れる可能性があるということです。
そのため、優先度には一定のルールが必要です。

私たちは、優先度を S / A / B / C / D の5段階に分けています。

優先度	位置づけ	設定できる人
S	最高優先度	マネージャーが設定できる最高優先度
A	高優先度	リーダーが設定できる最高優先度
B	やや高い優先度	発注者と担当者が設定できる最高優先度
C	通常優先度	発注者と担当者が設定できる通常優先度
D	低優先度	発注者と担当者が設定できる最低優先度

このように、優先度ごとに設定できる権限を決めておくと、作業の重みが分かりやすくなります。

たとえば、Sのチケットが付いていれば、チーム全体として最優先で扱うべきタスクだと分かります。
一方で、Sを設定できるのはマネージャーに限定しているため、軽い判断で最高優先度が乱発されることを防げます。

Aはリーダーが設定できる最高優先度です。
チーム内で優先的に進める必要があるが、プロジェクト全体を止めるほどではない、という判断に使えます。

Bは、発注者と担当者が設定できる中での最高優先度です。
通常の作業範囲では優先して対応したいが、チーム全体の作業順を大きく変えるほどではない、という位置づけです。

Cは通常の優先度です。
多くのタスクはこの優先度から始めます。

Dは最低優先度です。
対応したい内容ではあるものの、急ぎではないもの、時間があるときに対応するものに使います。

この運用の良いところは、優先度と権限（重要度）が結びついていることです。

誰でもSを付けられる運用では、気がつくとすべてのタスクが最高優先度になってしまいます。
しかし、優先度ごとに設定できる人を決めておけば、「この優先度は誰の判断なのか」が明確になります。

優先度は、作業者を急かすためのものではありません。
チームとして、どの順番で作業するべきかを共有するための情報です。

「助けて」をチケットで見えるようにする

私たちの運用では、チケットに「助けて」というチェックボックスを用意しています。

これは、担当者のタスクがオーバーしているときや、一人では抱えきれなくなっているときに使う項目です。
担当者が「助けて」にチェックを入れることで、チームに対して支援が必要な状態であることを伝えられます。

この仕組みがあると、手の空いたスタッフが「今、誰を手伝えばよいか」を判断しやすくなります。

たとえば、ある担当者が調査チケットを抱えていて、思ったより原因が深そうだと分かったとします。
そこで早めに「助けて」にチェックを入れる。
すると定例確認のときに、チーム全体に「ピンポン！」と合図が届くような状態になります。
別のメンバーがログ確認を引き受けたり、レビュー待ちの部分だけ先に見たりできれば、作業は止まりにくくなります。

チーム開発では、忙しさが外から見えにくいことがあります。
本人はかなり詰まっているのに、周囲からは順調に見えてしまうことがあります。
逆に、周囲は手伝うつもりがあっても、どの作業を支援すればよいのか分からないこともあります。

「助けて」のチェックボックスは、その見えにくさを減らすための仕組みです。

重要なのは、これは担当者の失敗を示すものではないということです。
タスクが増えたり、想定より作業量が大きかったり、確認待ちが重なったりすれば、誰でも手が足りなくなることがあります。

逆に、「まだ大丈夫です」と一人で抱え続けると、締め切り直前になって初めて問題が見えることがあります。

これは誰かを責める話ではありません。
問題が見えるのが遅いと、助ける側も動きにくくなる、という話です。

早い段階で「助けて」を出せれば、チームはまだ余裕のあるうちに対応できます。

作業を分担する
調査だけ別の人が引き受ける
レビューを先に進める
仕様確認を代わりに行う
関連する資料を探して共有する

チケットに「助けて」を用意することは、弱音を見える化することではありません。
チーム全体で作業を前に進めるための合図を用意することです。

チケットを精査して、チームの状態を把握する

チケットは、作ったら終わりではありません。
定期的に精査することで、チームの状態を把握するための材料になります。
私たちは、定例会議で進捗を共有するときに、チケットの統計情報を確認しています。

たとえば、次のような情報を確認します。

現在どれくらいのチケットが残っているか
未着手のチケットはいくつあるか
対応中のチケットが増えすぎていないか
確認待ちのチケットが滞留していないか
優先度の高いチケットがどれくらいあるか
「助けて」が付いているチケットはないか
特定の担当者に作業が偏っていないか
締め切りが近いチケットはないか

こうした情報を見ることで、チーム全体の作業状況を把握しやすくなります。

個人の進捗報告だけでは、どうしても見えにくいものがあります。
本人は順調だと思っていても、チケット全体を見ると確認待ちが増えているかもしれません。
ある担当者だけに作業が偏っているかもしれません。
優先度の高いタスクが、思ったより多く残っているかもしれません。

チケットの統計情報を見ることで、感覚だけではなく、実際のタスクの状態をもとに話し合えるようになります。

チケットの状況に合わせて会議の頻度を変える

チケットの状況は、定例会議の間隔を調整する材料にもなります。

タスクが少なく、進捗も安定している時期であれば、進捗共有は週に1回でも十分かもしれません。
一方で、タスクが溜まってきたり、締め切りが近づいてきたりした場合は、週1回の共有では状況の変化に追いつけないことがあります。

私たちは、そのような時期には毎日進捗共有会議を開催しています。
毎日集まる目的は、担当者を細かく監視することではありません。
問題を早く見つけ、早く助けるためです。

確認する内容は、たとえば次のようなものです。

残チケットが急に増えていないか
優先度の高いタスクが詰まっていないか
誰かの作業量がオーバーしていないか
「助けて」が出ているチケットに対して、誰が支援できるか
締め切りに対して、今の進み方で間に合いそうか

タスクが少ないときは、会議を減らして作業時間を確保する。
タスクが多いときや締め切りが近いときは、会議の頻度を上げて問題を早く拾う。

このように、チケットの情報を使ってチーム運営そのものを調整できることも、チケットドリブンの大きな利点です。

具体的な運用環境

ここまで、チケットドリブンの考え方について説明してきました。
では、実際にはどのようなツールを使えばよいのでしょうか。

私たちのチームでは、Redmineを使っています。

Redmineは、チケットを中心にタスクを管理できるツールです。
チケットごとに担当者、状態、優先度、期限、カテゴリ、コメントなどを記録できます。
また、チケットの一覧や検索条件を使って、現在のタスク状況を確認しやすいところも便利です。

Trelloのような扱いやすいツールでも始められる

一方で、チケットドリブンを始めるために、必ずRedmineを使わなければならないわけではありません。
たとえば、Trelloのようなツールも扱いやすい選択肢だと思います。

Trelloは、カードをボード上で動かしながらタスクを管理できるため、視覚的に状況を把握しやすいです。
「未着手」「対応中」「確認待ち」「完了」のような列を作れば、タスクが今どの状態にあるのかを直感的に確認できます。
小さなチームや、まずは軽くタスク管理を始めたい場合には、Trelloのようなシンプルなツールの方が導入しやすいこともあります。

大切なのは、どのツールを使うかだけではありません。
そのツールを使って、タスクに必要な情報を一か所に集められるかどうかです。

何をするのか
誰が担当するのか
今どの状態なのか
優先度はどれくらいか
何が終われば完了なのか
困っていることはないか
判断や相談の履歴が残っているか

これらをチームで共有できるのであれば、RedmineでもTrelloでも、チケットドリブンの考え方は実践できます。
ツールはあくまで手段です。
重要なのは、タスクを個人の記憶や口頭のやり取りに閉じ込めず、チーム全体で見える形にすることです。

チケットを作れば解決するわけではない

ただし、チケットドリブンにも注意点があります。

チケットを作っただけでは、タスク管理は良くなりません。
たとえば、次のようなチケットが増えると、かえって混乱します。

タイトルだけで内容が書かれていないチケット
完了条件が曖昧なチケット
状態が更新されないチケット
大きすぎて何をすればよいか分からないチケット
細かすぎて管理コストが高くなりすぎるチケット
優先度だけが高く、理由が書かれていないチケット

このようなチケットが増えると、結局また情報を探すことになります。

チケットドリブンで大切なのは、チケットの数を増やすことではありません。
チケットを見れば、作業に必要な情報が分かる状態を保つことです。

チケットは、管理者のためだけに作るものではありません。
担当者が迷わず作業するため、確認者が状況を把握するため、チームが支援し合うために作るものです。
注文票が分かりやすいと厨房が迷わず動けるように、チケットが分かりやすいと作業を始めやすくなります。
「どこから手をつけるんだっけ？」という時間を減らすだけでも、現場の空気はかなり軽くなります。

小さく始めるなら、まずここから

チケットドリブンは、最初から完璧な運用を作ろうとすると重くなります。
小さなチームなら、まずは最小限の形から始めるのがよいと思います。

最初は、次の3つだけでも十分です。

状態は `未着手 / 対応中 / 確認待ち / 完了` から始める
完了条件だけは必ず書く
週1回、残チケットと詰まっているチケットを確認する

今日から試すなら、この3分チェック

いま抱えている依頼を3つだけ書き出す
それぞれに 未着手 / 対応中 / 確認待ち / 完了 を付ける
完了条件が曖昧なものに一文だけ追加する
困っている依頼には「助けて」を付ける

慣れてきたら、優先度、期限、関連資料、コメントの残し方を少しずつ整えていきます。
チームの人数が増えたり、締め切りが近づいたりしたら、「助けて」のような支援の合図を追加するのも効果があります。

大事なのは、ツールをきれいに使うことではありません。
作業者が迷う時間を減らし、チームが同じ状況を見られるようにすることです。

最初の一歩としては、次のようなチケットを一つ作ってみるだけでも、かなり感覚がつかめます。

タイトル: 次の記事のアイキャッチ画像を追加する
説明: 記事の内容がひと目で伝わる横長画像を作成し、本文冒頭に配置する。
状態: 未着手
優先度: C
完了条件: 記事ディレクトリに画像を置き、Markdownから相対パスで表示できることを確認する。

このくらいの小さなタスクでも、目的、状態、完了条件が書かれていれば、あとから見返しやすくなります。

まとめ

チャット、メール、口頭での相談は、どれも便利なやり取りです。
しかし、それらだけでタスクを管理しようとすると、情報が分散しやすくなります。

タスクの目的、担当者、状態、完了条件、議論の履歴があちこちに散らばると、チームは作業そのものではなく、情報を探すことに時間を使ってしまいます。

チケットドリブンは、その問題を解決するための考え方です。

作業をチケットとして記録し、タスクに必要な情報を一か所に集める。
チケットを中心に相談し、判断し、進捗を更新する。
そうすることで、チーム全員が同じ情報を見ながら作業を進められるようになります。

私たちは、優先度をS / A / B / C / Dの5段階に分け、設定できる人を権限ごとに決めています。
また、担当者が困っていることを伝えるために「助けて」というチェックボックスも用意しています。
さらに、定例会議ではチケットの統計情報を確認し、タスク量や締め切りの状況に応じて会議の頻度を調整しています。

これらはすべて、チケットを単なる作業メモではなく、チームで作業を前に進めるための情報源として扱うための工夫です。

チケットドリブンは、管理を強めるためだけの仕組みではありません。
作業者が迷わず動けるようにするための仕組みであり、困っている人を早く見つけるための仕組みであり、チームが安心して開発を進めるための土台です。

理想的なタスク管理とは、タスクを増やすことではなく、迷いを減らすことです。
そのために、チケットという形で情報を整理し、チームで共有していくことが必要なのです。

お知らせ

株式会社グレッゾではエンジニアを募集しております！
もしご興味がありましたら是非、下記リンクより応募よろしくお願いします。
https://www.grezzo.co.jp/jp/careers/