なんとなく身につまされるものを感じたので、書き込んでみる。＊大前提..

なんとなく身につまされるものを感じたので、書き込んでみる。

＊

大前提として、それはディレクターという職種の問題というよりは、そのディレクターが仕事ができていないということな気がする。

なのでアウトプットのクオリティが低ければ、それはディレクターの責任で、エンジニアやデザイナーは、ディレクターの引いたスケジュール、ディレクターの出した指示だと当然こうなりますということで泰然自若としていればよろしいという気がする。筋論としては、エンジニアやデザイナーは別にそこでストレスを溜め込む必要はないはず（これが一番言いたい）。

＊

「知識が中途半端」なのはある程度仕方がないかもだが、わからないことはその場で知ったかぶりで安請け合いせず安全側に倒して持ち帰ってもらうようにしないと困るね。

自分でデザイン＋ディレクション／コーディング＋ディレクションもできるフルスタックな人間がいるのが理想ではあるけど。増田の書きぶりだと職種自体の存在意義を疑っているみたいだけど、ディレクターの仕事が何であるかを理解するのも、マイナスにはならないと思う。そういう本やウェブ記事などを読んでディレクションの知識をつけるのも悪くないのでは？すくなくともディレクターが言っていることがおかしいと思ったとき、漠然とではなく根拠づけて反論する材料にはなる。

＊

あとなんか、職場で口頭で指示を出されたりしている雰囲気の記述だけど、タスク管理システムとか（ToDo 管理／イシュー管理／チケット管理、言葉は何でもいいけど）、メールや口頭でのものとは別に、やるべきことをブレイクダウンして項目を立てて共有／アサインできるシステムを職場全体で使うべき（使っていないなら）。それをやれば、個別のタスクごとに、これは時間があればこうできるけどいまの納期だとこうしかできないとか、そのデザインの指示だと全体から見てこういう齟齬があるのでその指示の根本的な動機を教えてくれたら考えますとか、これはディレクターの仕事なのでディレクターにアサインしますね（^^）とか、論理的に切り分けした回答ができて、なおかつそれが共有でき、記録にも残るので、漠然とした話ではなく個別具体的にネゴシエーションができるのではないかと思う。

うちはGitHub Issueでやっているけど、なんでもよい。

エンジニアだけでなくデザイナーもディレクターも入ってもらって、そこに書いてないことはやらないくらいの気で、全員で本気で使わないと意味ない。

これは目下の不満とは関連付けずに提案したほうがいいかもね。

＊

土日が奪われているとか、そんなので続くわけがないし、客観的に見てダメなので、改善が必要なことは明らかで、問題提起すべき。

あと自分も無意識のうちに土日出勤や残業を前提にしたスケジュールを提案してないか？

書きなぐってしまった。

大半余計なことかもしれません。

＊

＞これに対してなんで、相談なしに決めてくるのか、納品できなかったときお前はどう責任とるんだ、責任取る気はないのか

これはそのとおり。オブラートに包み方がむずかしい。

＞ディレクターにあれこれ注文をつける「権限」があるのは、出来上がったものの最終的な「責任」をディレクターが全部負うからだよね。権限と責任がセットになってる。

＞他のチームメンバーはそれぞれ自分の専門分野について、コミットした仕事を全うする責任はある。でも要求される仕様や納期に今のリソースで無理なら無理ですとディレクタに言うのもプロとしての責任のひとつ。そうなった時に解決策を考えるのがディレクターの仕事(顧客と折衝して仕様を変更するとか、足りない部分について専門家を呼んでくるとか)。

これもそう思う。

記事への反応 -

記事への反応（ブックマークコメント）