F.O.X Meetup #3 ～スタートアップのチームビルド～に参加した

F.O.X Meetup #3 ～スタートアップのチームビルド～

6/18に開催された「F.O.X Meetup #3 ～スタートアップのチームビルド～」（@ヒカラボ）に参加してきました。

career.levtech.jp

カカカカックさんのプレゼン姿を見たかった & チームビルドに関心があった

現在、このブログを中心としたアウトプットについてのメンタリングを、カカカカック（@kakakakakku）さんにしていただいています。日頃のTwitterでのやりとり以外に、ブログやプレゼン資料、ゲスト出演されたポッドキャストについては拝読・拝聴していましたが、直にお会いしたことはなく、プレゼンという形のアウトプットに自分の目と耳で接したことがなかったので、いい機会と思い参加しました。

内容面でも、チームビルドという非常に関心を持っている分野について、スタートアップで働かれているお三方からお話をうかがえるということで、非常に楽しみにしていました。

資料はお三方ともに後日公開、かつメディア取材が入っていてそちらの記事が各登壇者についてそれぞれ1本（！）公開される予定とのことでしたので、内容についてはあまり触れず、感想を。

登壇資料とlogmiの記事

門田さん

成功したチーム失敗したチーム -F.O.X Meetup #3- from Noriaki Kadota

www.slideshare.net

logmi.jp

田中さん

Product managershouldask mvp from Tanaka Yuichi

www.slideshare.net

logmi.jp

吉田（カカカカック）さん

kakakakakku.hatenablog.com

logmi.jp

門田矩明さん「成功したチーム、失敗したチーム」

F.O.Xの門田さんです。F.O.X Meetupの主催者の方。

cyber-z.co.jp

これまでのキャリアで経験された3つのチームの事例をもとに、成功するチームと失敗するチームを分けるものは何かのか、というテーマでお話しされました。

結論としては、スタートアップで成功するのは、

チーム内でタスクや知識をシェアできる
専門領域を超えた仕事ができる
つまり、いわゆる「チームワーク」のできている

チームだというお話でした。この結論自体は、ありふれたものでしたが、お話を拝聴していて感じたことがあったので書き留めておきます。

時期によるタスクの偏りという問題

2番目のチームとして、アドテク製品のフルスクラッチでの開発において、4つのサブシステムにそれぞれ専任者を付けて開発を進めた結果、「失敗したチーム」となってしまったチームのお話がありました。

発生した問題は、サブシステム間（すなわちメンバー間）でタスクの偏りが生じた際に、手すきの人員に手伝わせようとしても、専任制でノウハウが共有されていないためにキャッチアップできない、ということでした。

誰も専門的な知識を持っていない領域に対する調査〜開発のあり方

3番目のチームとして、2012年ごろに携わったスマホアプリの開発についてのお話がありました。当時、スマホアプリ開発は現在ほど広く普及したものではなく、そこについての情報が少ない、専門的な知識を持ったエンジニアがチームにいないという状況で、どのように調査・開発を進めたか？というお話でした。

要点としては、

専門領域を問わず複数名で技術調査する
調査メンバーで全領域を設計し、そのメンバーがコードレビューする
調査〜開発までを複数名で実施する

という取り組み方をした結果、ドキュメントに書いていないことが起きるなどのトラブル発生時にも複数名で対応でき、プロジェクトは成功したということでした。

全員が未知の領域の場合、担当を割り振ってまずはその人にチーム内での第一人者になってもらうという行動に出たくなってしまいがちであるように思います。しかし、結果として後からキャッチアップするのに手間がかかる、レビューが正常に機能しなくなるなどの問題が発生するリスクはやはり大きいなと感じました。

田中裕一さん「タイムバンクでみるプロジェクトの立ち上げとMVP」

タイムバンクの田中さん。「見た目のせいか『デザインもやって！』と言われますが、デザインは全然できません」とのお言葉が印象的です。

timebank.jp

冒頭で予告された内容は以下のような点でした。

スクラッチから立ち上げてどのような苦労があったか
チームワークをどのように作っていったのか
エンジニアの組織で起きがちな問題

拝聴していて印象に残ったことをいくつか。

各フェーズにおいて何を諦め、何を重要視するのか？

「有益な施策はたくさんあるが、それを一時期にすべて実施するのは無理」という厳然たる事実に基づいたお話でした。本を読んだりネットの記事を読んだりすれば、「こうすれば良くなる」という施策は技術の導入であったりプラクティスであったり様々なものを知ることができます。僕自身、日々そういうものを学び、「あれもやってみたい、これもやってみたい」と半ばワクワク、半ば焦燥に駆られています。

しかし、当然ながら「何ができて何ができず、何が有効で何が効果薄なのか」というのは、現場や時期によって異なることです。これは当たり前の事実で、様々なプラクティスを紹介している『カイゼン・ジャーニー』でも冒頭（第1部第1話の解説）にも似たような趣旨のことが書かれています。

私たちは、他者の実践の背景にどんな状況、制約があったのかを理解し、自分たちの状況、制約の下ではどのように実践するべきなのか捉え直さないといけない。（『カイゼン・ジャーニー』13頁）

今回の田中さんのお話は、ある現場において、立ち上げからフェーズを切りながら、それぞれのフェーズで可能かつ有効な施策を考え、実践していった記録として非常に面白く聴きました。

チームとしての取り組み

技術的背景も、価値観もバラバラなメンバーからなるチームにおいて、どのように行動をしていったかをお話しされていました。印象に残ったもののみ挙げておきます。発言ベースなので内容に重複があります。

お互いの「正義」が違うことを理解する
「開発チームとして、何を優先し、何を諦めるのか？」を合意し、それを時期に応じて変えていく
自分たちの現状と向かうべき先について共通理解を作る、そのためには時間を取る
一度決めたことは当面はブレさせない
チケットには最低限、いつ、何が起きて、誰が対応したのか？だけはわかるように書く（初期の妥協点）

MVP & the Wizard of Oz

MVPのお話。書籍で読んで知ってはいましたが、実際に適用されている方のお話を伺うのは初めてでした。下記のような発言がありました。

KPIの跳ね方を見てピボットするなどの行動をとる
仮説と検証を回す
- 検証不可能なものは検証可能な仮説にするか、聞かなかったことにする
- 心理的表現が含まれる仮説はボケたりするのでコストばかりかかることが多い
ユーザ体験を損ねる方向のMVPの使い方は危険

吉田慶章さん「さぁ！今すぐプロジェクトリーダーに立候補しよう」

大トリはカカカカックさん。下記のブログで公開している社内勉強会の内容をアップデートしたものをお話してくださいました。

kakakakakku.hatenablog.com

冒頭に、「資料を後日公開するのでメモはとらずに僕の話を聴いてください」と通告されました。スライドになかった発言だけメモしていましたが、ご本人が終了後に「めっちゃアドリブで喋っちゃう」と仰っていましたので、ちょうどよかったなと思いました。

長いプロジェクトは失敗する？

今回、章立てとしては、

「タスクの流れ」に着目する
「雑談」と「スウォーミング」を大切に

の2つに分けてお話をされたのですが、これらに入る前にされた「プロジェクトとは？」というお話の中で、下記のような趣旨の発言がありました。

4ヶ月以上のプロジェクトは切り分け方が悪い。絶対失敗する。3ヶ月くらいで何かしらリリースすべき。

僕はプロジェクトの経験があまりないので、このあたりの肌感覚はまだわからないのですが、おそらくタスクと同じで、長い間、目に見える成果を提出できないというのは辛いし、行き詰ってしまいがちなんですよね。リリースを文字通りに捉えるとスタートアップ限定の話に聴こえますが、一般（？）のプロジェクトも短く切れたほうがいいのかなと感じました。