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

Webでもアプリでも

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

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

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

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

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

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

存在するのは知ってる

でもガチで見ない

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

世間的に見ればわかってる人って１割２割とかじゃない？

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

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

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

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

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

理想は

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

こんなじゃない？

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

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

ガチでやりにくい

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

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

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

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

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

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

（何ともなってない会社で働いたこともあるけどｗ）

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

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

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

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

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

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

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

Permalink | 記事への反応(0) | 16:32

ツイートシェア