デザインタスクの切り方を変えてみた話
はじめに
もう26日になってしまいましたが、この記事は「クラスターAdvent Calendar 2023」8日目の記事です。大遅刻ですがよろしくお願いします。
7日目の記事はuzzuさんの「UnityのPlay Asset DeliveryをtargetSdk34に対応させる」でした。アプリサイズはデザイナーとしても気にかけていかねば……。
こんにちは。クラスター株式会社でデザイナーとして勤めているよしおかです。この記事では、今年の振り返りとして、僕が仕事でどのようにデザインタスクを管理してきたかについて書いていこうと思います。
タスクの管理で今年気にかけたこと
2023年も残りわずか。今年の自分の仕事を振り返ると、より速くより安定して物事を進められるようタスク管理を工夫してきた年でした。
工夫の甲斐あり、今もとても順調にデザインタスクをこなしています。大まかに次の3つのことを心掛け実施してきました。
制作に使えている時間を細かく計測する
スイッチングコストが起きない粒度に切る
“物”ではなく“表現すべきこと”をタスクに書く
デザインタスク特有でなく、タスク管理においてごく一般的な話も混ざっていますが、それぞれの詳細について見ていきます。
1. 制作に使えている時間を細かく計測する
様々な業務の中で、自分がどのくらい制作時間にあてられているかを把握することは重要ですよね。タスクを見積もっても、制作に使える時間がわからなければスケジュールを立てられません。
これは大まかに把握するのではなく、きっちり計測・記録して、数値として認識することが大事です。
昔の自分は、制作に使える時間は大体把握してる……と思い、スケジュールを切っていました。しかしその把握は実態よりも多く時間があると思い込みがちでした。
スケジュールはジリジリと厳しくなり、何とか詰め込んで終わるということがちょいちょい起こり、大体見積もりの倍かかりがちだったこの事象に“吉岡係数”なんて名前がつくことに……。
計測すると何が見えてくるか
計測は、Toggl Trackというサービスを使って、ここ一年間ずっと記録してきました。
実際に計測してみると、カレンダーに載っていないミーティングだったり、作業のスイッチングコストで時間を食っていたり、時にはSlackを眺めすぎた……ようなことも。予想していないことに時間を使ってしまっていることがあらわになりました。
完璧なスケジュールを立てるのは不可能です。僕は予定していないことは起きるものだと思って計測しました。週ごとに行った仕事の割合を見て、予想外のことが起きても最低限どのくらい制作時間は確保できるのか平均を割り出しました。
こうして実測値を知っておくことで、無闇にタスクを積みすぎなくなるし、ちょっと予定以上に頑張る必要がある時に、ちゃんと頑張れる時間と精神的余裕を確保できるようになります。
2. スイッチングコストが起きない粒度に切る
スイッチングコストとは、それぞれ異なるタスクに移る際の精神的、時間的にかかる負荷のことです。
先の項でも意外と時間を喰っているものとして上げましたが、そもそもこれはなるべく起きないようにするのが良いです。起こさない方法は簡単で『とにかくタスクの粒度を細かくする』ことです。
普通、これを解消しようと思うと様々な通知を切って割り込みが入らないようにしたり、同種の業務をまとめて長時間それに集中できるような環境を整えようとします。
この集中する環境を過剰に揃えてしまうと、チームとしてのコミュニケーションに支障が出て、結果進捗のトラブルになりかねません。加えてクラスター社はリモート勤務が当たり前なのでより影響は大きく出るでしょう。
1つのタスクの最大サイズ
クラスター社のデザインチームは各人の重みづけによるポイントで見積もりをしています。1日の労力で終わるもの = 1ポイントといった感じです。
僕はこのルールに加え、タスクはどんなに大きくても『1ポイントが最大値』となるように分割します。ポイントが2や3もあるようなタスクは、1以下になるまでひたすら細分化していきます。
タスクを細分化できるということは、つくるものを深くイメージできていて、手を動かす準備ができているということです。
逆に細分化できない時は、まだまだイメージ不足で、迂闊に手を付けると無駄に悩む時間が増えてタスクの達成が遠のくでしょう。
タスクを細かくすることの副次的効果
タスクが小さいことは他にもたくさん良いことがあります。
声を掛けられるなどして作業を中断しても、タスクが小さく取り組みやすいので、作業に戻ったときに集中力がトップスピードに戻りやすい
多くのミーティングなどで作業時間が分断されるような日でも、タスクが小さいので隙間の時間でも着実に進めることができる
タスクが小さいと完了するのも早いので、その日の達成感を得られやすく進捗をより体感できる
細かく進捗を可視化できているので、遅れた時の検知が早く、見積もりし直しもしやすい
周りのメンバーも何をしているか把握しやすくなり、安心できる。
取り組むタスクの1つ1つが小さいと腰が軽くなります。精神的、時間的なコストはほとんど感じなくなり、慣れてくるといずれスイッチングコストは発生しなくなるでしょう。
3. “物”ではなく“表現すべきこと”をタスクに書く
僕は昔、タスクを次のようなイメージで書き出していました。
画面Aのワイヤーフレームを描く
画面Aのモックアップを組む
ヘッダー
ボディ
フッター
画面Aのアニメーションをつくる
ボタンのトランジション
ヘッダーのドロップダウン
etc.
イメージなので簡略化されていますが、変わったタスクの書き出し方ではないと思います。粒度も細かいです。ですが、このように画面や要素の数といった量的なかたちでタスクを小さくしてもそれほど意味がありません。
デザインは単に量をこなす作業ではありません。情報を紡いで関係性をつくり、ユーザーの振る舞いをイメージして制作することが重要だからです。
“物”が中心なこの細分化では、振る舞いに対してのイメージが不十分でアウトプットが安定しませんでした。
大きな目的から表現すべきことを見い出す
デザインタスクを書き出す時、デザインで“表現すべきこと”を中心にタスクを書き出すようにしました。新しいデザインが持つ大きな目的を細分化し、それぞれを表現すべきこと、達成すべきこととして書き出します。イメージとしては次のような感じです。
画面Aの主要機能のイメージをユーザーが持てるようにする
ヘッダーはグローバルナビゲーションにあたり位置的にも十分認知がとれているので控え目にする
ボディに配置した機能a, b, cのボタンを各コンテンツの要素を使って大きなビジュアルを使って際立たせる
ボティに配置した他ボタンが小さく共、a, b, cに負けて見落とされないぐらいの視線位置に置いて存在だけは認識させる
etc.
この書き出し方は、一種のデザインチェックリストのようなものです。デザインする時は目的を意識することが大事ですが、タスクとして細かに書き出すことで、その意識をより強固にしています。
ちなみに“物”でタスクを書き出していた時も、決して目的を忘れているわけではありません。ですが、目的のサイズは大きいままです。目的が大きなままだと、そのデザインが包括しなければいけない細かな目的を見落とし、アンバランスな手段を取るようなことがあったり、あるいは、デザインをひらめきだけに頼ってしまいアウトプットが安定しなくなったりします。
おわりに
デザインのような絶対の答えがないタスクは、安定してアウトプットを出すのは困難と思っていたのですが、ここ1〜2年でその考えは変わり気持ちよくデザインできています。
来年は、この気持ちよくデザインできている余裕を、clusterの次のステップに投じて、さらに良いデザインをできればなと思っています。
次の記事は9日目。ねおりんの「趣味でまたアバターアプリを作り始めた」です。iPhoneだけで手を動かせるすてきアバターアプリのなぜなにが読めます!
この記事が気に入ったらサポートをしてみませんか?