新規事業チームのマネジメント方法を開発部分に絞ってまとめてみた

Adways Advent Calendar 2019 9日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2019


 

お疲れ様です。森脇です。
新卒入社後、新規事業をやり始めて、2年目になりました。
プロダクトオーナーとして、C向けのサービスを運用しています。

チームで開発をしていると、
"他のチームは、こういうときどうやって対処しているんだろう"
"チームのマネジメントってどうやったらいいんだろう"
と思ったそんな時、隣のチームがどうやってるのかふと気になったことはありませんか。

本投稿では、私たちのチームのマネジメントについて紹介します。
最近、自分のチームでプロセスマネジメント系のルールが増えてきたので、これらを俯瞰的にまとめ、仕組みという無形資産を残しておきたいと思って記事を書きました。
内容のボリュームが多いので、今回は開発部分にスコープを絞りました。
あくまでチームマネジメントの一例だという認識で読んで頂けると幸いです。

読者のターゲット

  • 自分のチーム(新)メンバー
  • PMの方
  • PMを兼業でやられてる方
  • チームリーダーの方
  • チームで何かを創りたい学生の方

概要

私たちのチームの開発マネジメントはちょうど5つのフェーズに分かれているので、この順番でマネジメント内容を紹介していきます。
先に全体像を載せます。

f:id:AdwaysEngineerBlog:20191209110214p:plain

私達の開発技法に名前を付けるなら、超高速版ウォーターフォール です。
なぜなら、「企画→要件定義→設計→実装→テスト」サイクルが1週間で回っている=週1で新たな仮説が立てられ、検証するためのissueが立てられ、リリースされているからです。

開発フローとしてはあくまでウォーターフォールの早い版なので、アジャイルではありません(参考:アジャイルとウォーターフォールの違いがよく分かる記事
ちなみに、このチームの状況は以下の通りです。

項目 内容 詳細
事業フェーズ PSF ソリューションを提供して、顧客のAsIsからToBeの変化を示すKGI/KPIを探索するフェーズ
チーム人数 5人 プロダクトオーナー、プロダクトマネージャー、アプリケーションエンジニア1名、インフラエンジニア1名、web/イラストデザイナー1名
チーム歴 6ヶ月目 このチームが結成されてから現時点で6ヶ月目です

では、(1) 仕様決定フェーズから詳しく紹介していきます。

(1) 仕様決定フェーズ

f:id:AdwaysEngineerBlog:20191209110232j:plain

開発依頼 = すり合わせるもの

まずは仕様を決めましょう。

私がチーム開発において意識していることは、メンバーへの忖度です。
マネージャーがメンバーに開発依頼する場面で、メンバー自身が実装内容や目的に疑問を持ったまま依頼をお願いするのは不本意だなと思っているので、その開発を依頼する意義を伝えた上で、開発会議の中で相談、または設計をすり合わせることを大事にしています。

ポイントは、 開発依頼は決定した仕様を伝達するものではなく、認識を一緒に"すり合わせる"という感覚 です。

なぜその開発が必要か?を明確に

事業を運用する中で、ある仮説を検証したり、ユーザーにヒアリングをしたりすると、得られた学びによって「〜〜について、○○すると、XXになる」というような新たな仮説が出ると思います。
それを企画会議でゴールを決めた後、次回の開発会議アジェンダに入れておくのですが、その際に、「その仮説が目指すGoal+Signal+Metrics」と「現状+課題+解決案(プロトタイプやフローチャート)」をセットで書き込みます。

こうすることで なぜやるのか? を明確にすることができます。

また、議事録や仕様項目の作成・運用にはesaを利用しており、アジェンダは確認事項/設計相談/WIP項目にタグを分けることで頭の切り替えが楽になり、 思考ストレスが減って、会議の効率が良くなりました。

会議で実装イメージまで立てる

私たちのチームはエンジニアのマネージャーが居ないので、プロダクトオーナーが直接エンジニアに開発依頼することになります。なので、仕様書を決定する前に会議の中である程度のデータ構造や仕様内容を見通してしまいます。
エンジニアが仕様を確認後すぐに取り掛かれるくらいのレベルまでにしておくと、手戻りも少ないので安心安全です。

認識のすり合わせのために作るプロトタイプやフローチャートはLINE Bot Designermiroを利用しています。(提供しているサービスがLINEbotなため)
認識合わせができたら、esaに仕様書を作成/更新して開発を始めます。

(2) 開発フェーズ

f:id:AdwaysEngineerBlog:20191209110257p:plain

仕様書⊇テスト項目

(1) 仕様決定フェーズの開発会議を終えた次の日に、仕様書を作成します。
各機能単位でesaのpostを作成/更新し、開発単位でGitHubのissueを立てます。
issueには、esaのdiffリンク、フローチャート、バグ発生時の画面スクリーンショットを添付します。
ポイントは、仕様書をテスト項目と併用できるように、各動作をチェックボックスで記載することです。(下記参照)

f:id:AdwaysEngineerBlog:20191209110315p:plain

これによって、わざわざテスト用でテストケースを作成する必要がなくなります。
また、仕様書作成中にフローの分岐や形式外入力時の動作も書くことによって、"仕様漏れ"防止になりました。

(3) テストフェーズ

開発のキリが良いところでstaging環境にデプロイしてテストをします。

まず準備として、(2)で作成したテスト項目を複製してフォルダを 試験/テスト実績/yyyymmdd/post_name とします。

次に、データの準備をします。
テストをしたい機能が動作するユーザーデータパターンをPosticoでstaging用のデータベースを編集して再現させます。(サービスがPostgreSQLを利用している為GUIで操作できるPosticoを採用)
データ条件の準備ができたら、テスト項目に沿って全パターン試験します。
テストの中にはある時間になったタイミングでデータ発行や通知が行われるものがあるので、その場合は数日かけたりコンソールでjobを叩いてテストすることもあります。

ここでバグが発覚したら原因仮説を考えてエンジニアに伝達し、issueを立てます。
意外に3回に1回くらいはここで仕様の穴やケアレスミスが見つかるので、テストの重要さを毎回感じます。

11月から、SREやCI/CD系なども徐々に進めているので、今後このテストフェーズはもっと楽な仕組みになりそうです。

(4) リリースフェーズ

f:id:AdwaysEngineerBlog:20191209110334j:plain

さて、staging環境でのテストが無事終了したら、いよいよリリースです。
以前、私たちのチームでは「どこまでリリースしたっけ」現象が起こり、開発しづらくなったことがあったため、上記のように#release にアラートをすることにしています。(リリースアラートテンプレート
そして、本番デプロイをインフラエンジニアに依頼する際に、#release に投稿されたスレッドを引用して本番リリース依頼をします。

そうすることで、開発した本人以外のメンバーにもいつ、何がリリースされたのかが把握しやすくなり、認識がすれ違うことが無くなりました。

(5) バグ改善フェーズ

f:id:AdwaysEngineerBlog:20191209110349j:plain

リリース後のバグは、なるべく早く気付けることが肝心だと思います。
早く気付けるために行っていることとしては以下です。

  • SlackでDatadogやRailsを用いてエラー通知をする、alertチャンネルを作成
  • ユーザがバグ報告をする仕組みを簡単にする(お客様サポート用のLINEアカウントを用意)
  • 開発メンバーもサービスを日常的に利用する
  • 新規リリース直後のデータチェック

バグが起きてしまっても、すぐに対処できる環境を予め作って認識しておくと、精神が健康的です。

上記のいずれかの方法でバグが発覚すると、データ確認をして、バグの原因仮説を立てます。
その後に該当する領域を担当するエンジニアに相談し、ユーザにバグ通知をして、issueを立てます。
バグが起こるというイベントは、精神的にも応えるので起こらないことが理想的ですが、バグが起こったときの対処フローが明確であると、いざ起こったときに冷静に対処することができます。

また、想定しないバグだった場合は、再度起こったときにも早く気付けるように、エラー通知を追加したり、水際処理を検討するなどもしておくと再発防止になります。
ここまでを1週間で行い、また新たな仮説が生まれ、(1)からスタートするというプロセスが私達が行っている超高速版ウォーターフォールです。

最後に

今回は、私たちのチームのプロセスマネジメントについてまとめました。

ほとんどの方が(そんなこと当たり前だろっ!)と思われたかもしれません。
しかし、チーム開発は個人個人の"当たり前"が実現されずに、気持ちがモヤモヤして開発スピードが落ちたり、無駄な時間を作ってしまうことがあるものだと私は思います。

なので、チーム1人1人が一丸となって、強いチーム、価値の高い事業を生み出していくために、改めてあなたのチーム状況を振り返ってみてはいかがでしょうか。

おまけ:利用サービス一覧

サービス名 内容
THRUSTER 新規事業立ち上げのための事業開発ツール
Slack コミュニケーションツール
miro オンラインで利用できるホワイトボード
esa 自律的なチームのための情報共有サービス
GitHub ソフトウェア開発のプラットフォーム
LINE公式アカウント 「LINE」を通じて、企業や店舗がユーザーとコミュニケーションをとることができるサービス
LINE Bot Designer プログラミングの知識がなくても簡単かつ短時間でLINE Botのプロトタイプを作成できるツール
Postico OSXで使えるpostgresqlのGUIクライアント(無料)
metabase OSSのデータ可視化ツール(無料)

それでは引き続きアドウェイズのアドベントカレンダーをお楽しみください!


 

次はさたかさんの記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2019/10