Skip to content

Instantly share code, notes, and snippets.

@taea
Last active August 13, 2019 18:42
Show Gist options
  • Star 19 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save taea/9849802 to your computer and use it in GitHub Desktop.
Save taea/9849802 to your computer and use it in GitHub Desktop.
エンジニア向けデザインメンター(謎)をはじめて、2〜3ヶ月が経ちました

エンジニア向けデザインメンター(謎)をはじめて、2〜3ヶ月が経ちました

@ken_c_lo in 町田の部屋 新年会 2014-03-30

何やるの?

実際のプロジェクトに入って、エンジニアのデザイン業を支援する

デザインといっても広義。(案件のフェーズや人によってそれぞれ違うことやってる)

  • HTML
  • CSS
  • ビジュアルデザイン
  • UI設計
  • 仕様設計
  • ユーザーフローの設計
  • プロジェクトの価値の定義、コンセプトメイキング
  • コンサルティング 等…
  • 「考え方から伝える」というのを大切にして、気をつけてる

週1MTG 2時間前後

  • 受託案件の場合、お客さんも含めMTG

宿題で次週の話すテーマを用意してくる

  • MTG以外は、GitHub Issueでやりとり

基本、コーディングはしない

  • けど、エンジニアが書いたSassとかマークアップとか直してプルリクエストすることはある(後述)

なぜやるの?

デザインが(そこそこ)できる、わかるエンジニアを増やしたいと思った

  • 分業もいいけど、1人の中でデザインとエンジニアリング両方のセンスが融合することで、より面白い可能性が生まれそう
  • エンジニアの人、いいもの作るんだけど、なんか色々惜しい… みたいな人多くて、あと一声でもっと行ける感じする。
  • 開発の現場における、デザインに対する理解とデザインの地位向上
  • デザイン = ガワだけキレイにする仕事でしょ? みたいな認識を変えたい
  • デザインオリエンテッドな開発フローを作りたい。コードの中できちんとデザインを生かしたい。
  • 実際、小さなチームでデザイン業もやらざるを得ないエンジニアがいて、需要がある。
  • エンジニアという人種が好き。GitHubが好き。チーム開発は楽しい。

受託でデザイナーとしてがっつりプロジェクトに入ってご飯を食べるのを一旦やめてみよう

  • コーディングや開発も含めたデザイナーとしてプロジェクトにジョインして、本当にいいものを作ろうとしたら、仕様面からちゃんと踏み込んでいかなければならず、複数件の掛け持ちは自分には無理
  • システムはできてるからそこにCSS当てて、みたいな仕事をしたくない
  • 心血注いで作って、よりよいプロダクトにするために交渉しても結局、最終的な意思決定権はリスクテイカーであり自分ではない。→ 自分的には不本意な展開に… というのが続いてきた
  • エンジニアの成長にもコミットすれば、よしんばプロジェクト自体がうまくいかなかったとしても、それなりの価値を世の中に提供できていることになると思う(もちろん、プロジェクトの成功にも尽力はする)

自分のサービスを作ることに、なるべく専念したい(これが一番の理由)

  • 自分のサービスで食えるようになりたい。
  • 他のプロジェクトにガッツリ入ると、精神力持ってかれるので難しい
  • 過去の反省から、結局最後までデザイン(広義)に責任持とうと思ったら、自分がリスクテイカーになるしかないと思った。
  • 受託でコーディングをしないことで鬱憤をためて、それを自分のサービスで晴らすというよいサイクルを作りたい。
  • 自分のサービスでは、そこそこプログラミングもやりたい(動くプロトタイプくらいは作るようにしたい)

実際やってみてどうか?

思っていたよりも大変…採算が割りと厳しめ

  • 今4件持ってる → 来月から5件かも?
  • 当初、週に1時間MTGと、2時間くらいかけて宿題やる…くらいの心づもりでいたが、なかなかそれでは回らず、一件毎に週1日は取られてる感じする
  • そのかわり、進捗に応じてサボれる週もあるので、そういう時は積極的にサボらせてもらって帳尻を合わせてる
  • 課題が多すぎてエンジニアの進捗が追いつかない時とか → そういう時にサボる。何もしなくていい週もある。
  • 半年以上の長期見てくれるなら採算は合うのかもしれないけど、短期だと厳しそう
  • (単価あげたいなあ…しかし今までにあまりなかった業態なのでなかなか)

思っていたよりバラエティに富んでて面白い

  • 案件のフェーズや、エンジニアさんの特性によってやることがまちまち
  • 色んなエンジニアやお客さんやプロジェクトに触れることができて面白い
  • GitHub のフィードにいろんなプロジェクトの進捗が流れてくるので退屈しない

ケース1

状況

  • 実作業1人で自社案件を立ち上げ中のフルスタックエンジニャー
  • デザインやSassは既に結構できる。自分でサービス立ち上げるの得意で好き。
  • ローンチはまだだが、開発はだいぶ進んでた
  • 機能が膨れ上がって、サービス設計に無理が出てた

何をやったか

  • ユーザーに価値を提供できる状態を担保しつつ、最短リリースを目指すために、機能をがっつり削る
  • プロジェクトの価値の再定義 → 最終的に目指すべく理想像から一旦離れて(それを大事にしつつも)、まず最初にターゲットユーザーに価値を感じてもらって使ってもらえる、というところから目指すようにする。
  • 提供するものを少なく絞って、そのための機能だけに特化してなるべくシンプルに
  • …というところに着手できるまでに1〜2ヶ月かかってしまった。(全体像が自分自身なかなか掴めず、最初はCSSの話とかしてて反省)
  • 今は細かな作り込みは一旦おいといて、ざっくりした設計のところを直している
  • 何をボタンにするか、何をリンクにするか? UI設計の基本的なところとかを、設計の話と交えて話してる
  • やりとりはIssue + ヌーボード のみ
  • もともとかなりデザインできる人なので、こちらでの細かい作りこみがそれほど必要なさそう。

ケース2

状況

  • 受託案件。既にコア機能は出来上がっているが、UIやデザインが…という状態
  • お客さんも含めMTG。毎週の時もあるし、少し間を置くときもある。
  • もともとシンプルな構造のサービスなので、そこまで抜本的に変える必要なかった

何をやったか

  • UI設計や、細かいディティールを直しつつ、1箇所、抜本的な変更を加えた
  • コードのレビューまではまだあまり出来てなくて、今のところ表側のデザインのみ
  • Issue でやりとり。UI は Illustrator でざっくり作って、こんな感じって貼るときもある。
  • ざっくり作ってしまう時でも、なぜこうしたかの意図を伝えるようにしてる。

ケース3

状況

  • 新規案件。最初の段階からジョイン。
  • 毎週お客さんも含めたMTGで、仕様設計画面設計をホワイトボードでやる
  • プラス、事前MTGと事後MTGをエンジニャーさんと毎週やる
  • 作り込みが最近はじまったところ

何をやったか

  • 新規なのでひっくり返す必要がなくやりやすい
  • 事前の設計段階では、大体MTG時に話が済んでしまうので今のところ比較的 楽
  • 画面設計時に、UI設計の考え方(なぜこうなのか?)を交えて伝える
  • 作りこみがはじまったので、細かいSassの設計方法やBootstrapカスタマイズの方法とかを伝える
  • Pull Request 駆動で進めていく方針

ケース4

状況

  • 新規案件。最初の段階からジョイン。
  • 毎週お客さんも含めたMTGで、仕様設計や画面設計をホワイトボードでやったり
  • システムより前にまずはランディングページが欲しいというオーダー
  • ランディングページを作りつつ、システム込みのサイトも徐々に設計し作りはじめてる

何をやったか

  • ランディングページのデザインはビジュアル的な見た目も大事なので、Illustrator でざっくり作ったものを渡して、コーディングはエンジニアがやる(パララックス的な、デザイン構成自体はシンプルなもの)
  • GitHubでそれをレビューしつつ、具体的にコードに手を出して直しつつ、コミットを細かく分割して、どこをなぜ直したかの細かい説明をコミットコメントに加えつつ Pull Requestにする
  • 相談や疑問、詳しい話や感想などは、そのPull Request上で展開する
  • デザインのコミット細かくわけるのはめんどくさいが、これはよい方法かも

今後の課題

もう少し楽をしたい

  • 色々見て法則が見えてきたので(みんなが間違えやすいところとか)そういうのをドキュメント化する
  • 全員 Bootstrapを使ってるRailsエンジニアだし、Bootstrap の足りないところを補完するようなgemとかを作って、それを配れるようにしたい
  • より良いフローの確率。GitHub Flowチックなのにうまく乗せられるとうまくいきそうだなあと思って
  • 一緒にやってる人たちが、定期的に集まってどういうことをやってるのか共有しあう会をやってもいいと思う。(人によってやってることが違うので、共有すると面白そうだし楽できそう)
  • 今のところこれ以外の案件も抱えているので、自分のサービス作る時間があまり捻出できていない。来月からはもっと時間とれるようにしたい。
  • 進行途中からのジョインはやっぱり大変。最初から関われた方が楽。

感想

  • 色々大変ではあるけど、面白いし楽しい。
  • 結局デザイン的なことはやってるし、結構手も動かしてるんだけど、従来のデザイナーとエンジニアの協業の垣根をさらにゆるくフレシキブルにした感じでなかなかよい
  • エンジニアとのチーム開発はやはり楽しい。こちらも勉強になること多いし、最近1人の仕事はやる気がでなくてつらい。
  • 案件の根本的な課題に深く突っ込めるので、自分のスキル的にもコーディングに時間取られるよりプロジェクトの確度を高められると思うし、対時間でいう貢献度はこっちの方が高そうな感じ
  • まだまだどれも途上段階だけど、よりよい成果を出したい
  • 需要あるし面白いので、デザインメンター業マジオススメ

余談

  • 直接関係ないけど、エンジニアやデザイナー(実際作る人)発で、ちゃんとプロダクトを作って、うまくいきそうだったらお金集めて起業しようみたいな仕組み作れたら面白そうみたいな話してる。(これからこういうの作ります!へのクラウドファウンディングじゃなくて、もうすでに、つい作ってしまったいい感じのものにお金集める)
  • ポエムとか、色々作りはじめてるプロダクトとか、そういう足がかりにできたらいいと思う。
@shoota
Copy link

shoota commented Jul 17, 2014

ヨサソウ( ˘ω˘)"

@ogawaso
Copy link

ogawaso commented Jul 17, 2014

ヨサソウ( ˘ω˘)"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment