dots. CONFERENCE 「チーム開発を支える技術」に参加しました #dotsconf

2016年2月27日に開催されたdots. CONFERENCE SPRING 2016「チーム開発を支える技術」というイベントに参加しました。

チーム開発を支えるコミュニケーションツールや開発ツール、組織づくりをテーマとした、8つのプレゼンを聞くことができました。はじめてこういうテーマを扱うイベントに参加したこともあり、気づきも多く、とても参考になりました。

では、内容のメモと個人的な感想を忘れないように書いときます。

「ランサーズ株式会社」を支えるチーム開発

ランサーズ株式会社 横井 聡氏

以下、メモ。

  • 開発チームには他の色んなチームからタスク依頼がきやすく、手を打たないとチームがパンクする。
  • 業務の流れにフィルタリングレイヤを挟んでタスクの流量制御をしている事例。
  • 例えば、プロジェクト系、タスク系、障害系、基盤改善系といった感じにタスクを分類し、それぞれの比率を予め決めておく。
  • Team GeekのHRT(謙虚、尊敬、信頼)の考え方は開発チームに閉じてしまいがち。
  • 営業や企画など開発チームの外にもHRTの考え方を向けることで、会社・組織全体がうまく回り始めるんじゃないか、という考え。

以下、個人的感想、思ったこと。

  • タスクの分類して、それぞれの比率を決めたとしても、状況によってその比率を守れないことが多々あるような気がする。
  • そういう時はどのように対応すればいいんだろうか。

大企業に「技術で勝つ」を実現するチーム開発

Connehito株式会社 島田 達朗氏

以下、メモ。

  • スタートアップが大企業に勝つためには技術で勝つしかない、という考え。
  • 全体の15%-20%の時間を開発効率改善などの取り組みに使った。
  • 非エンジニアにもエンジニアツール(SQL)を使って業務してもらうことで、会社全体に技術を浸透させていく。
  • 変化を楽しみ、進化を続ける事が大事。

以下、個人的感想、思ったこと。

  • 「技術で勝つ」ということよりも「スピードで勝つ」ということが重要なのではないかと自分は思っている。
  • 「技術」に[スピード」が含まれているのかもしれないけど。

キモは品質、メンテナンス性、そして非同期コミュニケーション

Kaizen Platform Inc. 石橋 利真氏

以下、メモ。

  • B2Bシステムなので品質に気をつかっている。QAチームが横断であり、1日感QA環境で試験してからリリースしている。
  • 必要な情報のスナップショットやサマリがSlackにかなり集約されてるイメージ。
  • DBのSlow QueryをSlackに投稿するのは便利そう。
  • 組織の人数や体制で使っているツールが変わっていった。
  • 最初はGitHubのIssue。その後JIRA。現在はチームが分割され、各チームで自由なツールを使うように。

以下、個人的感想、思ったこと。

  • パネルディスカッションでの「エンジニアが使うツールはエンジニアが決められる状態を維持することは大事」という言葉が身にささった。
  • 人数、体制、働き方によって最適なプロセスは異なるはずだから、それをサポートするツールとして何を採用すべきかも変わってくるんだろうな。
  • ツール導入が目的にならないようにしたい。プロセスをツールに合わせるようなことはやりたくない。と、なんか思った。

「NewsPicks」の異能集団を支える技術

株式会社ニューズピックス 松原 孝司氏

以下、メモ。

  • ChatOpsの目的は、エンジニア以外も黒い画面見ずにオペレーションできるようにすることと、属人性の排除。
  • 緊急性の高いPush通知を送りたい時など、スピードが求められる時もChatOpsは有用。

以下、個人的感想、思ったこと。

  • 「エンジニアではない人も考慮した属人性の排除」=ChatOpsの目的、という考え方は納得。

Qiita/Qiita:Teamの開発を通して見つけた、Incrementsの文化を作る方法

Increments株式会社 東峰 裕之氏

以下、メモ。

  • メンバーが少なく、いちいち手でやってたら回らないので、属人性排除と自動化を推進したとのこと。
  • 尖っているメンバーが多い、多様性のあるチームになった。
  • 多様だけど、メンバーが一つのビジョンに共鳴できるチームを目指している。
  • 多様性を許容するための細かい試行錯誤をあきらめない。
  • リモートワーク導入、飲み会・遊びを強要しない、月1の1on1ミーティングで期待・不安・噂をヒアリングするなどが、具体的な取り組み。
  • 「チームが機能するとはどういうことか」という本を輪読している。
  • 意見の相違が乗り越えられ、解決策が生まれるまで議論できる関係性があり、安心して率直な意見を伝えることができることが必要。

以下、個人的な感想、思ったこと。

  • 飲み会や「仲良し」の強要、特に何も罪悪感感じることなく、やってしまいがち。でもそれが嫌なメンバーもいるんだよな、きっと。
  • そんなことよりも、多彩なメンバーがチームのビジョンに共感して、一つの目標に向かって進んでいけるようにすることが大事なんだろうな。
  • 「チームが機能するとはどういうことか」はぜひ読んでみたい。

クラウドソーシングでチームを作る方法

株式会社StartupTechnology 菊本 久寿氏

以下、メモ。

  • 募集時には、業務内容を明確する、時給制にする、労働時間をコミットさせないのが大事。
  • 応募→スクリーニング→仕事ではなく、応募→仕事→スクリーニングの順番。まず仕事をしてもらってから判断する。
  • 間口を広げるために、できるだけ一般的な技術スタックを採用する。

以下、個人的感想、思ったこと。

  • クラウドソーシングを使ってお仕事を発注したことはないけど、もし今後することがあったら参考にしたい内容だった。

チームリファクタリング – 強いチームをつくる技術

楽天株式会社 及部 敬雄氏

以下、メモ。

  • 開発現場の問題は、技術的な問題ではなく、チーム・コミュニケーションの問題であることが多い。
  • タックマンモデルを意識すべし。チームが混乱している段階で新しいことに挑戦するのは難しい。
  • チーム改善のロードマップ(1年分くらい)をつくって、計画的に改善が進むようにする。
  • 組織課題がボトルネックになることもある。
  • 自分たちの組織を変えるのは、現場で実際に困っている自分たちであるべき。
  • 「未来会議」をマネージャ、メンバー一緒に実施。組織課題の洗い出しと解決策の議論・検討をブレスト的にみんなでおこなった。

以下、個人的感想、思ったこと。

  • 「未来会議」はぜひ、今の職場でもやってみたいと思った。どちらかから一方的に問題提起するよりかは、より本質的な解決策が打てそう。
  • ロードマップがないと、どうしても短期的な手を打ってしまいがち。まずTo-Be、As-Is、登り方をまずしっかり決めてからアクションするようにしようと思った。

チーム開発を妨げる壁とその壊し方

株式会社シーエー・モバイル 大八木 晋平氏

以下、メモ。

  • 同じ組織は二つとないので、組織づくりに「正解」はない。
  • 企画/開発の壁を壊すためには、メンバーがより市場価値の高い人材(企画がわかる開発、開発がわかる企画など)になれるよう仕向ける
  • プレイヤー・マネージャの壁。優秀なプレイヤーが優秀なマネージャになるわけではない。
  • ずっとコードを書いていたい、エンジニアリングしていたい、新しい技術を使い続けていたい、という意志を、組織として明確にサポートするという姿勢を示すべき。
  • 開発マネジメントと組織マネジメントを分けて考える。片手落ちになっているチームが多い。

以下、個人的感想、思ったこと。

  • 組織がある程度大きくなると、会社が違っても同じような課題が発生するんだな、と思った。
  • 「MTGエンジニア」(ミーティングに出席してばかり開発に時間が避けないエンジニア)に自分はなりたくないなぁ。
  • プレゼンでも言及あったけど、MTGエンジニア本人のモチベーション低下よりも、その人を見た他のメンバーのモチベーションが下がることのほうが、組織としては重大な問題だと思った。
  • kantarock

    自己流チームリファクタリング俺もまとめようかな

  • まとめてブログに投稿ですね