読者です 読者をやめる 読者になる 読者になる

Uni-Q blog

うにきゅう ぶろぐ

大きいチームと小さいチーム

以前、大きいプロジェクトにデザイナーとしてアサインした時。関わる人も多く、チームメンバーも多かったです。

今のお仕事は小さいプロジェクトで、関わる人は少ないです。

同じ「デザイナー」としてアサインしているけど、仕事の内容や意識が違う感じ…で、そこそこ苦労?してます。
今まで「デザインだけじゃなくプロジェクトに目を向けた仕事」を意識してやってたつもりだったんですが、実はあまり出来てなかったんだなーと、最近感じるようになりました。とくにエンジニアよりの「タスク管理」「リリース計画」、あと企画よりの「問題提起」といった所かしら…。

私が感じたことをメモメモー。

以前経験した大きいチーム

f:id:uniq:20140215143156p:plain
※黄色い部分が私の視界・意識みたいな感じです。

  • 私の視界や意識、外に向かってるのは、えらい人・企画・エンジニアさんがそれぞれ何を考えてるか、どういうやり取りしてるかーあたりです。
  • 自分の中では、ユーザーに対してどうするかーとか、どんなデザインがベストかーとか、えらい人・企画・エンジニアの意図するモノに私のデザインは対応してるかーとか、このデザインはプロジェクトに本当に相応しいのかーとか、そんな事を考えます。
  • エンジニアチームにアサインする時は、毎日、スタンドアップミーティングで進捗共有。
  • プロジェクトに関する雑用(チケット管理やマイルストーンやKPIなど)は、エンジニアの女子マネ(!)や、企画がやってくれてるので、そこの部分の気遣いまで出来てません。 - 企画から「数値を見るとこんな結果になってて、ここを強くしたいんですよ」っていう問題提起があります。そこからデザイナーの私は、問題解決策を考えます。
  • エンジニアの女子マネ(!)が、チケット管理してくれてます。さらに「デザイナーさんスケジュール大丈夫です?」「企画からこの話は聞いてます?」みたいな気遣いまで、色々としてくれてます。
  • 大きいプロジェクトだと、commitするものが、たくさんあります。releaseブランチにmergeといった作業は、決まった人が行う感じ。一本化されてる感じだと思います。「デザイナーはreleaseブランチにmergeしないように」と言われてました。(なにかトラブルあっても対応できないしね)
  • レビューは、デザインチームにいる時はなかったです。エンジニアチームにアサインするとレビューがありました。最低でも自分でブラウザ・端末確認をしてHTML lint/CSS lintでチェックはする。
  • チケットの作業をエンジニアから自分にバトンタッチされて、デザイン作業が終わったとき、「デザイン作業終わりましたー」って報告はしてましたけど、その後に何してるのか、あまり把握してなかったです。開発環境にあがると確認、本番にあがると確認する程度。

今経験してる小さいチーム

f:id:uniq:20140215143343p:plain
※黄色い部分が私の視界・意識みたいな感じです。ほぼ全体見てないと仕事できないー(と思う)。

  • 大きいチームと同じく、えらい人・エンジニアさんがそれぞれ何を考えてるか、どういうやり取りしてるかを把握します。
  • これまた大きいチームと同じく、自分の中で、ユーザーに対してどうするかーとか、どんなデザインがベストかーとか、えらい人エンジニアの意図するモノに私のデザインは対応してるかーとか、このデザインはプロジェクトに本当に相応しいのかーとか、そんな事を考えます。
  • 毎日、朝会で進捗共有します。skypeで行うこともあり。

〜ここまでは同じ感じ〜

  • 3人ぐらいのチームの、うちひとりが私。私の言動が、チームの雰囲気に影響することもあったり。(人数多いチームだと影響力少ないけど。)なので、雰囲気に気を使う!「おはようございま〜す(^o^)」とか朝会前に声かけたりしてます。
  • MTGがグシャグシャになる事が多いと思いました。理由は、キーマンがいない(例えば「全ての決定事項は社長次第」みたいなのが無い)のと、メンバーが少ないので「◯◯さんは司会に専念」っていうのが出来ないんだろうなあ…とかとか。それと、2-3人だとMTG前の情報共有わざわざしなくても何とかなってたんだろうなーと予想するけれども…。なので意識的に、自分からMTG前に「議題は何?なんの目的のMTG?私は何を用意すればいい?」って聞くし、MTG中にも「今はアイディア出すターン?事項を決定するターン?」って聞くことにしてます。
  • 自分でも積極的にチケットを作ります。(かぶってたら消せばいいし、内容が良くなければ編集して直せばいい。)
  • チケットが仕様書!みたいなモノなので、チケットにデザインの理由・説明をメモします。(もうちょっと頑張りたい)
  • 自分で作ったチケットは、releaseブランチにmerge、テスト項目作成、テスト実施の依頼?まで面倒をみます。(今はまだテストが不慣れですが…。)releaseブランチにちゃんと入ってるかなーとか、リリース終われば、チケット閉じられたかなーとか。ちぇっくちぇっく。 - デザイナーだけど、必ずレビューします。小さい変更は「hg diff 」で差分見てもらったりもします。
  • 「プロジェクト全体としての優先的なこと」を常に意識します。自分のタスクもあるけれども、メンバーが少ないこともあって。
  • 仕様をアイディア出しすると同時に、KPIの方法について考えます。(あんまり出来てない)

まとめ

いじょううーーーーー。

なんか、小さいチームは、みんながリーダーになれるような感じだなーと思いました。 うむーーー。