Subscribed unsubscribe Subscribe Subscribe

CHROMA

Web Designer の頭から飛び出たアイデアの記録

タスクよ、終われ

Misc

「タスクが終わらぬ (・┏Д┓・) 」ってなったので、チームで諸々のルールを作った。

タスク管理ツールは Backlog を使ってる。
タスク関係者は基本的に制作物の確認者と製作者の 2人になる。この 2人が迷走しだした時、他の人が横から槍を突いてくる。

ルールは出来たので、あとはこのルールを守りながら動くようにする。
制約が厳しいと思うところや良くないところは、振り返りの度に見直す。

一部デザインタスクに寄った内容の記載がある。

目次

  • タスクの進め方
    • 事前に必要な事項の確認
    • レビューの期限と方法
  • タスク関係者間での伝達方法
  • タスクの振り返り方

タスクの進め方

事前に必要な事項の確認

タスクに取り掛かる前にこれらを決定、確認する会議を行なう。
決定したものについては Backlog のタスク詳細に記載する。

  • タスク責任者(制作物の確認を行う人)の確認
  • 文言や写真素材など、コンテンツが揃う時期の確認
  • タスク主旨の確認
  • 情報の分類や強調箇所の決定

他に開始日・期限日、担当者、状態といった情報を Backlog の形式に沿って記載する。

レビューの期限と方法

期限内にタスクを完了させるため、以下の取り決めを守っていく。

  • レビューを5時までとする
  • レビュー回数を3回までとする
  • タスク主旨に沿ったものに限り、複数案の作成を2案まで行う
  • デザインの詳細に関わる明言を行わない

レビューを5時までとする
この時間を過ぎると、レビュー後の修正時間が取れないため。
5時を過ぎた場合、タスク期間を延長する。

レビュー回数を3回までとする
レビューに対する修正を無制限に設けていると期限内にタスクが完了しない恐れがあるため。 レビューする人と制作物を修正する人、それぞれ限られた回数の中で頑張って返答や製作を行なう意識を持つ。

タスク主旨に沿ったものに限り、複数案の作成を2案まで行う
タスク主旨に沿ってデザインを作成している場合、大きく異なる案を作成する機会は無い。
もしコンテンツの配置などで異なる案が要求された場合、これはデザインを複数案作成するのではなく、(タスクに取り掛かる前に決めたことを振り返りながら)話し合いでどちらで進めるのか決める。

個人の印象や感覚値の問題で複数案が必要なときは 2案まで作成する。

デザインの詳細に関わる明言を行わない
レビューの際に色やサイズ、余白幅やエフェクト(シャドウ、ハイライトなど)といったデザインの詳細に関する明言は避ける。
「○○のサイトの○○と同じデザインにしてください」とだけ伝えるのをやめる。変更する理由がない。

レビューは変更要件ではなく、変更理由を書くようにする。

タスク関係者間での伝達方法

状況毎に Backlog と口頭や電話といった伝達手段を使い分けていく。
それぞれの長所と短所から、このように使い分けていく。

  • タスク要件、確認依頼、必要事項の受け渡し、レビューは Backlog にて行なう
  • Backlog 上で 2往復(目安)以上のレビューと応答が繰り返された場合、内容が決定しなければ口頭での話し合いで解決する
  • 複数人からの主張が3つ以上出てきた場合、口頭での話し合いで解決する
  • 緊急の要件を伝える必要がある場合、口頭や電話で伝達する

タスクの振り返り方

タスク完了後、タスクの進め方について振り返る会議を行なう。 内容は以下の通り。

  • タスクの進め方、決めた通りにできたか
  • タスクの進め方、次のタスクでは改善したほうが良いものはなかったか
  • 今回のタスクで対応できなかったもので、別タスクとして立てたほうが良いものはなかったか