2016-09-28

デザインファーストがクソな理由

Webでもアプリでも

作りやすいやり方、作りづらいやり方がある

 

たとえば、作りやすいやり方だとコスト10で80点のものができるとする

それを作りづらいやり方にされると、コスト20で60〜90点のものができる

作りづらいものバグや無理が出るから

うまくいくかもしれないけど、コスパ絶対悪

 

で、デザイナーで作りやすいやり方をちゃんとわかってる人をほとんど見たことがない

存在するのは知ってる

でもガチで見ない

割りとまともな会社数社で働いたけど、居るには居た程度

世間的に見ればわかってる人って1割2割とかじゃない?

まあ、エンジニアと違って覚えなきゃいけないこといっぱいあるし仕方ないとは思う

デザイナーに求めすぎずに、ちゃんとフローを整えて解決するべき

 

もちろんディレクターもそこら辺は知らないんだけど

ワイヤーレベルであがってくるのと、デザインレベルであがってくるのでは温度感が変わってしま

ワイヤーは要件デザイン仕様っぽくなってしま

 

理想

ディレクター要件レベルWF → エンジニア修正 → WF要件挙動 → デザイン入れ → エンジニア修正

こんなじゃない?

 

デザインファーストはこうね

ディレクター要件 → デザイン → エンジニア修正

ガチでやりにくい

コストかかるしバグも出る

 

エンジニア「その挙動めっちゃ作りづらいんですけど」

デザイン「えーでも作っちゃったし、またやり直すの?」

 

みたいな話になるから皆ツライ

 

あ、よく表に出てくる事業会社みたいなところは別ね

あいうところは既に人間関係ができてるから何とでもなる

(何ともなってない会社で働いたこともあるけどw)

もっと普通会社の方だと開発フロー重要になる

 

こういうの、まともなPMが居る組織だと当たり前に当たり前なフローになるんだけど

経験豊かなPMが居ないとか、組織が大きすぎるとかだと上手くいってないイメージ

 

ディレクターでもSEでもいいからワンクッション置いたほうが皆幸せだよ

要件定義→簡易WFエンジニア修正」のワンクッション

 

もしくは一堂に会して議論できれば一番いいけどねぇ

それはそれでファシリテーターの力が必要になるんだよね

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん