tobb422のブログ

スタートアップエンジニアの奔走

スタートアップで、チームビルディングを実施して1年たった

はじめに

以前、
1人目のエンジニアとして、スタートアップに入社して1年経過した
というエントリーを書きました。今回は、その続編といいますか、
この5月で、開発チームが私だけでやっていた状態からチーム開発に変わって、約1年が経過するので
この1年間で行ってきた one visa 開発チームのチームビルディングについて書いてみたいと思います。

タイムライン

まず、前提知識の共有のため
どんな形でチームが変化したかを簡単に説明します。

  • 2018年3月
    • 私がエンジニアとしてジョイン, 開発の内製化を進める
  • 2018年5月
    • 2人目となるフロントエンドエンジニアジョイン, チーム開発へとシフト
    • フロント1名, バックエンド1名の体制へ
  • 2018年10月
    • 3人目となるバックエンドエンジニアジョイン
    • フロント1名, バックエンド1名, 雑用(私)1名の体制へ
  • 2018年12月
    • 4人目となるバックエンドエンジニアジョイン
    • フロント1名, バックエンド2名, 雑用(私)1名の体制へ
  • 2019年4月
    • 5人目となるフロントエンドエンジニアジョイン
    • フロント2名, バックエンド2名, 雑用(私)1名の体制へ

と、こんな具合にチームは拡大しています。
余談ですが、現在も開発の合間に合間に採用活動はしており、
開発チームのさらなる拡大を図っています!ご興味お持ちいただける方はぜひw

以下は、全てチームビルディングとして、取り組んでいる具体的な施策の紹介です。

恒常的に行っているもの

以下の取り組みは、恒常的に行っているものです。
チームとして活動する上で、必要不可欠な取り組みだと考えています。

スプリント計画

チーム開発がスタートして一番最初に行った施策が、スプリントの実施でした。
2週間を1スプリントとして実施しており、チーム一丸となってプロジェクトを前に進めることを前提に
見積もり(プランニングポーカー)の実施で短中期的な計画の精度をあげることや
振り返りの実施でチームとしての成熟度を高めることを目的としていました。

また、当時のスプリントは、デザイナー, フロントエンドエンジニア, バックエンドエンジニアと
職種を超えたチームでの実施だったため、
振り返りの際にでてくる視点も様々なものがあり、大変興味深いものでした。

現在のチームでもスプリントを実施しており
見積もりと振り返りを定期的に行い、チームとして成熟度を高めていけるよう心がけています。
この振り返りで出てきた改善点や称賛すべき項目は、いまでは後述する開発思想の1つになっていたりと
one visa のチームらしさを作る意味で大きな役割を果たしていると思います。

プロダクトバックログ

こちらもチームメンバーが増えても実施し続けている施策の1つです。

スプリント計画を行うことで、2週間ないしは、1ヶ月先のプランニングはできるようになってきました。
しかし、長期的な計画に対しては、不確かなものが多く、3ヶ月先の着地に相当なブレがある状況が続いていました。
(いまでも、完全に解決できているわけではないのですが...)

そこで、スプリントでは見えてこなかった、もう少し長期的な計画として
プロダクトバックログを取り入れることにしました。
大きな企画単位で見積もりを行い, 3ヶ月, 6ヶ月先に自分たちがどれくらいできそうかを見積もることができるようになってきました。

スタートアップということもあり、半年後の状況は誰も読めない...という状況なのですが、
だからこそ、「どれだけ不確実性をなくせるか」が大切だと開発チームでは考えており
いまの開発チームは、◯◯くらいの大きさの企画であれば△ヶ月で終えられると自分たちで認識を持ち、 ボードメンバー等、他のチームに説明ができるように心がけています。

デイリースクラム

毎日、夕方にチームメンバーで進捗共有を行っています。
目的としては、チームの進捗確認で

  • チームがスプリントで立てた計画を無事実施できているかの確認
  • タスクの優先順位の確認

を行っています。
これらの確認のために、カンバンを導入しており
チームとして抱えているタスクの可視化ができるようにしています。

それ以外にも、困っていることや相談ごとの共有を行う場にもなっており、
個人で実装や設計で悩んでいることがあればチームで解決していけるように心がけています。

また、弊社ではリモートワークも取り入れており、普段は何をやっているのか全く見えない状況だったりもするのですが、
このデイリースクラムのおかげで常にチームの状況を把握できるようになっています。
チームメンバーが少なった頃は、デイリースクラムを行わなくても
他のメンバーが何をやっているのか、何に困っているのかを把握することが容易だったので
デイリースクラムを行っていない時期もあったのですが、人数が3人, 4人と増えてきたタイミングで復活しました。

必要に応じて行っているもの

以下の取り組みは、状況に応じて実施しているものです。
ほとんどが、恒常的に行う施策を機能しつづけさせるための点検・すり合わせの責務を担っています。

オンボーディング

新しくメンバーが増えたタイミングで行っています。
担当者と内容を決めて、個人にあったやり方で行うようにしているのですが、
共通して行っているオンボーディング施策として、キックオフMTGがあります。

いまのところ、開発チームメンバー全員参加で行っている施策で
以下のようなアジェンダで実施しています。

  • 得意分野, 好きな技術, 興味がある分野
  • チーム開発で大切にしたいと思っていること
  • 何で貢献したいと考えているか
  • (メンバーが)期待していること

どんなことが好きで、何を大切に考えているのか, どんなことでチームに貢献したいと考えているのかを
チーム間で共有することで、タスクの振り方などにちょっとした差が出てくると思っています。
そのため、実際の業務に入る前に、メンバーについて知ってもらう, 教えてもらう場を作ることを意識しています。
また、最後の期待していることをしっかりとメンバー間で伝え合うことで、期待値のすり合わせも行っています。

全ては、心理的安全性を担保するためであり、 こうした価値観の共有を行うことが非常に重要だと考えています。

カンバンの見直し

タスク状況の可視化を目的として、カンバンを導入していますが、
人数が増えてくると、カンバンが上手く機能しなくなってきます。
これは、カンバンにかかわらず、スプリントの方法やプロダクトバックログの方法にもいえることなのですが
絶えず変化するチームの中で、常に完璧な方法は存在しないです。 そのため、定期的に時間を取り、それぞれの取り組みが
現在のやり方で果たそうとしている目的を達成できるかを点検するようにしています。

カンバンでは、人数が増えることで Waiting(待ち)にタスクが溜まってしまう事象が多くなりました。
そのため、現在では、デイリースクラムで Waiting にあるタスクについて全員でネクストアクションを確認するようにしています。

当時は、上手く機能していたとしても、メンバーが増える・プロジェクトが変わるなどして
常に機能し続けるものは存在しないと考えています。
チームとしても絶えず機能し続けるためには、
日頃の取り組むを点検する場を設けることは非常に大切だと考えています。

ドキュメント作成

ドキュメントに関わらず、議事録なども重要なのですが、
チームで決めたルールや原則は、基本的には全てドキュメントに残すことを心がけています。
スタートアップであるため、スピード感を持って開発することがが非常に重要だと考えています。
それと同時に、持続可能な開発を行っていくこともまた、非常に重要だと考えています。
そのため、開発チームとしては、1時間手が止まってしまうとしても、
決めたこと等は、必ずドキュメントに残し、明文化するように心がけています。
そのドキュメントは全メンバーがいつでもアクセスできるようにしており、
メンバー間で暗黙知が増えないようにしています。

誰が入って、誰が抜けたとしても、「開発チームとして機能し続ける」仕組みづくりは、非常に重要です。
過去に決めたルールなどは、定期的に点検するコストもあるのですが、
これが一番スピード感を持って、開発し続けられる方法だと考えています。

単発で実施した大きな取り組み

日頃行っている取り組みの指針となる指針となるより抽象的な概念について
チームですり合わせを行うことを目的に実施しているものです。
まだまだ回数をこなせていないので、ブラッシュアップの余地がある施策ではありますが、
これからも継続していきたいと考えています。

開発思想すり合わせ会

チームが4人になったタイミングで、開発思想すり合わせ会というものを行いました。
目的は、普段の開発で何を大切にすべきかについて目線を合わせることで
会社のバリューのような位置付けだと考えています。
(実際に、開発思想の中から会社のバリューとしてランクアップしたものもあります。)

詳しくは、弊社Wantedlyページにて記事が上がっているので、そちらをご覧ください。

www.wantedly.com

向き直り会

こちらは、大きなプロジェクトのリリースを終えたタイミングで実施しました。
目的としては、非連続的な成長に繋がるきっかけづくりで
チームの最終目標から逆算して、現在との差分を把握する場になっています。

こちらも詳しい記事が上がっているので、そちらをご覧ください。

www.wantedly.com

開発戦略目線合わせ会

一番最近に行った施策です。
事業戦略に沿った形で、1年先に開発チームとしてはどんな体制になっていなければならないか
そのために、いまやっておかなければならない取り組みは何かを把握する会として実施しました。

こちらは、私のブログにて、別途詳細に書いていきたいと思っています。
書きました → 【レポート】開発戦略目線合わせ会を実施した

まとめ

振り返ってみると、1年間でチーム開発といえども非常に変化があったなぁと感じます。 特に、施策に取り組むにあたっては、以下をしっかりと抑えておく必要があるなと学ぶことができました。

  • 目的のすり合わせ
  • 価値観のすり合わせ
  • 価値観の明文化, オープンな知識の蓄積
  • 仕組み(取り組み)自体の点検

その時々で、最もパフォーマンスを発揮できる仕組みを作ることが非常に重要であり、
個人的には取り組むべき面白い分野だと考えています。
これからも引き続き、チームとして正しく前に進み続けられるように
創意工夫を凝らして、より良い仕組み作りに努めていきたいと思っています。

最後に宣伝になりますが、
開発はもちろん、こうしたチームビルディング
開発チームがパフォーマンスを発揮し続けられる仕組みづくりについて
一緒に考えることに興味をお持ちいただける方がいらっしゃれば、ぜひお会いしましょう〜!
ご応募いただけると嬉しみです。

www.wantedly.com