Mar 1, 2017
開発とデザインが分離している現場は、ディープ・ワークな働き方ができる気がしてます。
弊社 ひとひねりは、会社規模は小さいですが、大規模プロジェクトのフロントデザイン（ビジュアルデザインからHTML/CSS/JSまで）の一部を担当した経験が多くあります。
UIデザインをつくって、HTML化。それを開発部隊（おもにSIerさんになることが多いです）に納品。JAVAでできたシステムなどに組み込んでもらいながら開発さんのQAに答えて、HTML/CSS/JSを書き換えていくことになります。
同時に、今後のフロントの運用方式も考えたりします。企画の人から「ちょっとデザイン変えたいんですけど」と言われたときにどうやってシステムに組み込まれたサイトを低コストで更新していくか？などです。
小規模なシステムなら、railsなりを使って、ディレクターになる私を含めても３人位で作ります。その場合は、まあ、つかう言語やシステム納品物にも寄りますが、基本、githubのissueで看板をつくって、デザイナも含めてアジャイルな感じで作ることが多いです。
こんな感じ
http://lean-trenches.com/one-day-in-kanban-land/
キモなのはこのスタイルで案件進めると、「管理」するコストがかからない。反面、３人各自が自主的に攻めの姿勢で看板を消化していかなきゃいけないみたいな、各人のスタンス（スキルじゃなくて）に頼ることが多くなります。
各自がちょっとずつ進行管理やディレクタ的な意識を持つ感じでしょうか。
ただ開発さんだけで十人超、フロント側もデザイン、HTMLコーダーと数えてみると、５人もいる！となると、なかなか全員の意識レベルやスタンスをそろえるのが難しい。
直接話したこともない人もいたりするので、攻めのスタンスで仕事しましょう、みたいな文化を作るのも難しい。
その場合は、開発側が得意とするやり方になるべく寄り添うようにしています。
ガントチャートやタスクリストで管理コストをおおきくすると、各人のプレッシャーは弱まる
この開発側が得意とするやり方というのは、大規模プロジェクトになればなるほど、いわゆるウォーターフォールになることが多いです。
エクセルにびっしり書き込まれたガントチャートに、さすがに最近はタスク管理をエクセルでということは少なくなりましたが、Backlogなんかがよく使われますね。
このやり方はやはり管理コストが非常にかかります。
ただ、弊社のメンバーを含めた一人ひとりのプレイヤーにたいするプレッシャーというか、そういうのは非常にラクになります。
いい意味で、自分に振られたタスクをきっちりこなせさえすればOKだから。ディレクタ的な視点とかは持たずに、自分の仕事にしっかり集中できる。全体における自分の仕事の意味、なんか考えなくてもその辺の調整は管理担当（別会社の場合が多いです）がやってくれます。
大規模開発のほうが、ディープワークで品質の高いものが作れる気がしてます。
ウォーターフォールで古臭い文化、生産性の敵みたいな感じで見られそうな、ガッツリタスク管理ですが、個人的には（適切に運用できれば）大人数での開発における。品質の担保という意味だといい方法だなと。
各人がまわりを気にせず、ひとつの役割に没頭する。
それこそ流行りのディープ・ワークのように、すべての情報（おもにSlackから流れてくるプルリクとかデプロイとかの通知）から（次の納期まで）オフラインになり、自分の任された場所（弊社で言えば、UIセットのデザインとかコーディング）に集中する。
こうすると、思いつきやひらめきという、当たるとデカくてかっこいい手法に頼らなくなるのも良いポイントですね。
規模が小さい場合は、ひらめいて手を動かしてみて失敗しても手戻りコストが小さいので、手戻りしながらプロダクトを良くしてくというのもあるのですが、大規模なSierさんとチームを組むと、こちらの都合でそういうことをしてしまうと、ガントチャートが破綻してうまくいかない。
なので、期待されている仕事を期待と同等に（以上でもなく、以下でもなく）集中して仕上げていく。
ガチャガチャーと動く小規模プロジェクトもダイナミックでいいですが、淡々と、しかし専門的に深く関われる大規模プロジェクトも、なかなかやりがいがありますね。
ということで、株式会社ひとひねりでは
・UX/UIのコンサルティング
・フロントデザイン、コーディング
・取材記事やインタビューなどのコンテンツビルド
このあたりを得意としていますので、来期からちょっと相談に。。。みたいなかた、ぜひ、声をかけてください。
hello@hitohineri.jp
宣伝でした。
ら・ら・らんど みたい。
