＜この記事の著者＞
ばんか（bamka） - Tech Team Journal
Web制作会社の会社員（Webディレクター）として働きつつ、個人でブログ／メディアライターとしても活動するパラレルワーカー。
ChatGPT等AIを公私で駆使し、ITツール・ガジェットを用いて人々の生活をより豊かにするための活用術を提供するブログも運営。
ITエンジニアと関わることが多いWebディレクターの重要な役割のひとつがプロジェクトの進行と管理です。ひとつの目標に向かって進むべき道筋を示し、各メンバーがそれぞれ自身のパフォーマンスを100%発揮できるよう気を配ります。
プロジェクトのタスク管理も重要な仕事のひとつ。Notion・Todoist・Backlogなどツールはケースバイケースですが、複数人でひとつのタスク管理ツールを使い、互いの進捗やプロジェクトの進行状況を把握できるように促します。
そこで今回は、複数人でのタスク管理が円滑に進められるように、私が実施しているルールをご紹介します。僕ひとりが気をつけているものではなく、プロジェクトメンバー全員でルールを共有して、仕事がしやすい環境を作るのが目的です。
【目次】
- 1. 誰がタスクを作成・設定するのかを決める
- 2. 完了条件を明確にする
- 3. タスクひとつに対してアクションもひとつ
- 4. タスクの担当者は原則一人に限定する
- 5. タスクの進捗の確認時間を設ける
- 6. タスクの依存関係を明記する
- 7. コミュニケーションのルールを設定する
- 8. タスクの粒度を適切に管理する
- さいごに
1. 誰がタスクを作成・設定するのかを決める
まずはじめに、誰がタスクを作ったり、設定していいのかを決めます。チームメンバーそれぞれが自由にタスクを設定するのか、それともプロジェクトリーダーが一括で管理するのか、どちらが適しているかを判断します。
私はいつも、タスクの作成についてはWebディレクターである私に集約していました。プロジェクトの全体像は私が一番理解していたので、状況の変化については私が一番に把握しておくべきだと思ったからです。
複数人で自由にタスクを設定する場合でも、タスクの詳細な設定は担当者ひとりで行うほうがいいでしょう。あるいは、メンバーが参加しているミーティングで一緒に設定するなどの工夫したほうがよさそうです。
私は過去に、「Inbox」という未処理のタスクが入る箱を用意して、そこに入れてもらうようにしました。とりあえず必要なタスクだけを洗い出して、処理はみんなで行うのです。
2. 完了条件を明確にする
ありがちな失敗として「このタスクって終わってるんですか？」と宙ぶらりんなままのタスクが増えていくケースです。一応タスクは進んでいるんですが、完了なのかどうか判断できないまま、次のタスクに着手してしまうのです。
したがって「何が、どういう状態になったら、タスクは完了と判断するのか」を明確に言葉として残すようにしていました。
たとえば、Webサイトにおけるデザイン制作のタスクがあった場合。「作り終わったら完了」なのか「フィードバックへの対応も含めて、完全にFIXした状態になったら完了」なのかを、チームメンバー全員で判断できる状態が望ましいです。
3. タスクひとつに対してアクションもひとつ
タスクを進めていくと、途中で複数のアクションが必要になるケースがあります。たとえば「デザインを作っている途中、ロゴデータが未支給であるとわかった」という場合です。
「デザインの作成」と「ロゴデータの支給」というふたつのアクションができましたが、これをひとつのタスクの中で管理すると、状況が複雑になってしまいます。
この場合はタスクを分割し、新しく「ロゴデータの支給」というタスクを作り、別物として進行します。
4. タスクの担当者は原則一人に限定する
たとえば「トップページのデザインができたので、確認をお願いします」という趣旨のタスクがあった場合、確認を行うメンバーは複数人になります。しかしタスクの担当者を複数に切り分けてしまうと、責任の所在が不透明になり、タスクの進行が遅れる原因になります。
したがって、タスクの担当者は必ず一人に限定します。複数人に確認を依頼するときでも、それを取りまとめる人を一人設定して、その人が責任をもってタスクを完了に導くように促します。
5. タスクの進捗の確認時間を設ける
定期的に、タスクの進捗の確認時間を設けています。これは、プロジェクトが計画通りに進んでいるかをチェックし、必要に応じて調整を行うためです。
「ツールで管理しているし、いまはスムーズに進んでいそうだから、わざわざ時間を取る必要ないでしょ」と判断するのは、結構リスキーです。
プロジェクトは生物ですし、それに関わっているのも人間です。
体調や環境の変化もあるでしょうし、当初の見積もりよりも時間がかかってしまう場合もあるでしょう。「先々に控えているタスクに対して、漠然と不安を感じている」というケースもありました。
大切にしているのはコミュニケーション。メンバーそれぞれが “言いにくいけど、言っておかないといけないこと” を共有しやすい空気づくりを大事にしていました。
人間ですから、気分やテンションもあるでしょう。「思ったより捗らなくて、タスクが遅れそうです」なんていうのは、よくあること。誰もその人を責めません。
責めませんが、プロジェクトの調整は必要になるので、そういう「見えないリスク」をいち早くキャッチするためにも、対面での確認時間は必要なのです。
6. タスクの依存関係を明記する
「Aというタスクが終わらないと、Bというタスクが始められない」というような、タスクの依存関係をメンバーが把握できるように手配しています。
タスク間の依存関係を理解できれば、どの作業を先に進めるべきかが明らかになり、全体のプロジェクト進行がスムーズになります。また、予期せぬ遅延が発生した時の影響を事前に評価し、対策を立てやすくなります。
7. コミュニケーションのルールを設定する
チーム内でコミュニケーションのルールを設定しています。ツールの使い分けに似ているかもしれません。
たとえば私は「細かなコミュニケーションはSlackで」「何かしらの結論が出たようなアクションはBacklogで」というような分け方をしていました。
タスク管理ツールであるBacklogで、タスクの細かな質問をされても、迅速にレスポンスができません。逆にSlackのようなチャットコミュニケーションで「デザインができました！」と報告を受けても、記録として残りづらく、管理が難しくなります。
各プラットフォームの役割を明確にして、どういう目的で使用するのかを定めるようにしていました。
8. タスクの粒度を適切に管理する
タスクの大きさの判断は、いまも難しく感じています。大きすぎると進捗が見えにくくなりますし、小さすぎると管理が難しくなりますので、適切な大きさで切らなければなりません。
粒度の判断基準として、私は「一週間、なんの動きも起こせなかったタスクは、粒度が大きすぎる」としていました。
週に一回の定例ミーティングを行って、そのときに「状況に変化がありません」とフィードバックがあったときは、タスクの作り方に問題があるかもしれないと思うようにしています。
さいごに
Webディレクターの役割は、チームメンバーが100%のパフォーマンスを発揮できる環境づくりです。クリエイティブ以外の余計な疑念をなるべく取り除けるよう、自分にできる立ち回りを模索しています。
デザイナーやエンジニアの方で、「こういう配慮をしてもらったら嬉しかった！」などの経験がありましたら、ぜひはてなブックマークやSNSのシェアで教えてほしいです。
(文：ばんか（bamka）)
paizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
