Septeni Engineer's Blog

セプテーニエンジニアが綴る技術ブログ

nanapi勉強会に参加してきた

こんにちは、どうでしょう藩士飯田です。

来年の1月14日(水)から水曜どうでしょう 一番くじ 第2弾が始まります。
第1弾では発売当日にどうでしょう藩士が青屋敷に討ち入りし即完売になりました青屋敷が多数あったとネットで話題になってました・・・どうでしょう藩士おそろしや〜

今回の景品ライナップもどうでしょう藩士にとっては大変魅力的なものになっているので、即日完売になりそうですねー
他のどうでしょう藩士に遅れを取らないよう、当日は青屋敷に討ち入りしてから出社したいと思います。

さて、本題です。

2014年12月19日(木)にnanapi勉強会 vol6 - エンジニアとデザイナーの協働に参加してきので、その時とったメモを公開します。
参考程度に見てもらえればと。

挨拶(KDDIの人)

  • 経歴:ヤフー → FacebookKDDI
  • Facebook社はエンジニアが企画をしている
  • Facebook社はエンジニアが本番環境で作っている
  • Facebook社はエンジニアからめちゃくちゃなサービスがどんどん上がってくる
  • エンジニアがプロデューサーになって、どんどん作っていくべき
  • Facebook社のエンジニアはマーケティングの知識を持ってる

プロダクト開発を最適化するためにやめた4つのこと(株式会社nanapi 小島さん)

自己紹介

  • http://nanapod.kozyty.com を粛々とやってます
  • Git AdventCalendar2014に3回参加してるよ
  • Git覚えたい人はDMしてね
  • emosiってアプリがあるよ

資料

会議をやめた

  • リアルタイムコミュニケーションが活発になった

カンバンをやめた

  • Pivotalを導入
  • +Slack連携
  • カレンダーはホワイトボードで管理(丸見えカレンダー)

開発することやめた

  • 外部サービスにあるものはやらない

エンジニアをやめた

  • 開発だけすることをやめた
  • プロダクトに合わせて立ち振舞を最適化する

まとめ

  • チームは「自走」と「歩み寄り」が重要

質問

Coineyのチーム文化(コイニー株式会社 松本さん)

エンジニアもデザイナーも完璧を求めすぎだね

完璧主義の問題(完璧主義を捨てる)

  • ツールとコードの間にギャップがあるよ
  • 一番大事な部分の質が低下する・・・
  • プライドってかなり邪魔するよね・・・

改善してみた

  • 完璧主義をやめて70%ルールにした
  • あえて手を抜きチームで考える余白を残すことで創造を超えるアイデアを発見できるようにした
  • どんなデザインも最初は駄作だよね
  • 衝突がないのは危険信号だ!

作業しすぎることの問題(思い込みを捨てる)

  • オフィスでは本当の問題は解決できない・・・
  • 画面とにらめっこしすぎて、視野が狭くなりユーザー体験が見えなくなる・・・

改善してみた

  • ヒアリング遠足 → 実際にユーザーの声を聞いてみよう!
  • これからは、オフィス+リモートワーク+フィールドワーク になる
  • お互いのことを知り信頼関係を気づくのが大事

役割分担の問題 (肩書を捨てる)

  • 「誰かがやるだろう」の文化・・・良くないね

改善してみた

  • 肩書を捨てよう
  • ちょっとウザいくらいがちょうど良い
  • 問題解決の化学反応を起こす → チーム全体の問題として捉えることで化学反応が起こる
  • きれいなジャイアニズム → おまえのものは俺のものw

まとめ

お互いのことを理解・尊敬し、信頼しあうことが重要!

質問

  • 広めるための工夫は? → 自らやって結果を出して示していく

デザイナーとエンジニアの何を変えて開発効率を変えたか?(株式会社VASILY 村田さん)

  • 元ヤフーの人
  • 41名(デザイナー4名、エンジニア18名)

ICONについて

ユーザー数:200万人、投稿数:1,400万

デザイナーとエンジニアの役割の拡張

  • ディレクターってやること多いね
  • 役割分担が偏るとコミュニケーションコストが高いな

改善してみた

  • エンジニアも数値管理をするようにした

プロダクト開発の仕方を変えた

  • プロトタイプを作り、懸賞と修正を重ねる時間帯
  • プロトタイプが重要

プロトタイピングでよかったこと

  • 認識のズレが減った
  • 検証の効果が高くなった
  • 軌道修正が格段にしやすくなった
  • プロダクトを速く作る能力がついた

まとめ

  • 社外のUIアドバイザーの意見をもらっている
  • プロトタイプをどれだけ速く作り、最後にどれだけ磨ききるかが重要

質問

  • 数値を見る等の役割の拡張はどうやってるの? → 人によって決めている(全員ではない)
  • リリースサイクル → 1週間〜2週間で回している

Qiita/Qiita:Teamの開発(Increments株式会社 小西さん)

  • サービスを開始して3年
  • Qiitaはデザイナー2名、エンジニア3名で作っている

文化(意識していること)

基板

  • ツールは超重要
  • Github + Slack + Qiita:Team を使ってます
  • デザイナーもGithubを使っている
  • デザイナーだけど、3年間で4600コミットしてます
  • docomoruは面白い
  • 日報もQiitq:Teamを使っている

体制

  • スクラム(みたいなやつ)→ 自社サービスなので、緩くスクラムをやってる
  • 課題の追求
  • 検証サイクル(ユーザーヒアリング)
  • 常に改善し続ける

個人

  • 個人が強く主張する
  • ポジションを与える
  • 一番身近な人から話を聞く

所感

他社の開発チーム事情を知ることができすごく良かったです!

どの会社もチームビルディングには苦労してるし、正解は無いんだなとも思いました。
なので、常に改善して成長し続けるチーム作りが必要なんだなと。

自分も社外にアピールできるチームになるよう、試行錯誤しながらチームビルディングをしていこうと思います!

元記事はこちらです。
nanapi勉強会 vol6 - エンジニアとデザイナーの協働