僕のYak Shavingは終わらない

車輪の再発明をやめたらそこには壮大なYakの群れが

nanapi勉強会 vol6 - エンジニアとデザイナーの協働　に行ってきた！

top

http://nanapi.doorkeeper.jp/events/18274

Time Schezdule

時間 テーマ 発表者

19:00〜19:30 開場・受付開始 -

19:30〜19:40 挨拶 株式会社nanapi和田

19:40〜20:00 プロダクト開発を最適化するためにやめた4つのこと 株式会社nanapi 小島 泰洋

20:00〜20:20 Coineyのチーム文化 コイニー株式会社 松本 隆応

20:20〜20:40 未定 株式会社VASILY 村田 卓朗

20:40〜21:00 Qiita/Qiita:Teamの開発 Increments株式会社 小西 智也

以下個人的まとめ。

※個人の主観が入っているので、必ずしも発表内容を反映しているわけではない部分があります。予めご了承ください。また修正がある場合は即座に修正させていただきます。

19:40〜20:00 プロダクト開発を最適化するためにやめた4つのこと 株式会社nanapi 小島 泰洋

kozyty

nanapiの4人目のエンジニア

@kozyty

nanapodというpodcastをやっている メンバーをゲストに呼んだ雑談が主。

kozytyがおくる、nanapiのpodcast “nanapod”はじめました。 | kozyty.com

今日はemosiの話。知らん。

会議をやめた

  • その変わり席を隣にして蜜にコミュニケーションするようにした

カンバンをやめた

  • Pivotal+Slackを使ってる

できるだけ開発をやめた

  • 外部サービスにあるものは全面的に頼るようにした
  • 辺に最適化してしまうのを避けれるようになる

エンジニア、という型にハマるのをやめた

  • 開発以外のプロダクトに関する部分に集中するようにした

20:00〜20:20 Coineyのチーム文化 コイニー株式会社 松本 隆応

coi

Coineyは今は30人くらいに一気に増えた。デザイナーの人。

完璧主義による衝突

完璧なデザイン vs 理想のコード

本質のクオリティが低下する。無駄な部分に注力してしまう。プライドがある。変なものを出すのは恥ずかしい。

→100%をやめる。70％でいいとする。

作業は少なく、仮説検証を早目にやる

無駄な作り込みをして、現場で混乱が発生した。

UIなど遷移を増やすと開発コストもかさむし、単純作業も増える。

まずは現場を見て、それでUI・機能をつくって仮設を検証する

役割を意識しすぎる

助けてって悲鳴を上げている人がいても、領域を区分しすぎてしまって誰も助けない事象が発生してしまう。誰かが助けると思うのではなく、全員が互いに問題を共有して解決していくことが重要。

そのためには、自分自身の肩書を捨てることが重要。

20:20〜20:40 株式会社VASILY 村田 卓朗

（題名、ぎりぎりまで未定だったので、最初のスライド見逃してわからなかった。なんだっけ？）

iqon

エンジニア。 現在はAndroidエンジニアの統括。

iQonの開発者。めっちゃ優秀やん（一時期ベンチマークしていたのでわかる）。

昔

ディレクターの役割がすごい多くて、デザイナーはデザイン、エンジニアはコーディングと、ボールが偏っていた。

またディレクターがHubになっているので、コミュニケーションもディレクターに集中してしまう。

今

ディレクターがやっていたことを他に流して、デザイナーとエンジニアの役割を拡張する。

  • ディレクター
    • ビジネス・接客交渉
    • スケジュール管理（全体かな）
  • デザイナー
    • デザイン
    • ユースケース
    • アンケート
    • アンケート作成
    • スケジュール管理（自身の）
  • エンジニア
    • コーディング
    • ユースケース
    • アンケート
    • 数値管理
    • スケジュール管理（自身の）

互いのコミュニケーションコストが下がって、エンジニアとデザイナーとのコミュニケーションが増えた。

リリースまでのフロー

昔

→デザイン→開発→リリース

これだと動かしてみてからダメな部分に気づくことが多かった。

今

→デザイン
　　→開発
　　　　→リリース

デザインと開発の期間を被せた。早めに問題がわかるようになった。 軌道修正が早くなった。

最後にどれだけ磨き上げるかが重要。

Qiita/Qiita:Teamの開発 Increments株式会社 小西 智也

qiita

Qiitaのデザイナの方。開始から3.5年。

Qiita系はデザイナ2人、エンジニア3名で行っている。

文化

  • HRT（謙虚、尊敬、信頼）
    • ちーむぎーくで紹介されていたやつ
  • 属人性の排除
  • Focus

詳しくはこちら！

QiitaやKobitoを作る開発チームの文化 - Qiita Blog

体制

常に見直す。

基盤

  • Githubを全体で使う
    • デザイナーも4000コミットくらいしている
    • デザイナーもpull-reqしている
    • エンジニアとデザイナのコミュニケーション用でありデザイナーとデザイナーでもやりとりしてる
  • Slack
  • Qita::Team
    • 日報
    • 今後の方針などの重いやつも書いている
    • なおかつドッグフーディング

他

  • スクラム（みたいなやつ）
  • 課題の追求
    • 入社仕立てのr7kamuraくんがぶっこんで来て議論が一日中続くこともあった（良い意味で）
  • 検証サイクル（ユーザーヒアリング）

ポジションをとる

全員がお伺いを立てて物事が進まないことがある。なので個人が意見を主張して物事を進めていく。

まずは何か思ったら身近な人に話してみる。他のメンバーの意見を聞く。

意見を主張すると軋轢が生まれるかもしれないが、むしろウェルカム。