開発のチーム体制についてまとめてみた
Wed+DB PRESS Vol.60でプロジェクト運用ノウハウについて学んだのでまとめました。
アウトプットを最大化するチームづくり
- チームラボ(株)
チーム開発の重要性
- 求められるアウトプットに対して最適なチームを運営する必要がある
- チームメンバー個人個人がサービスの目的や、最適な開発フローを常に考えてることが重要
- 一人一人のアウトプットの結晶が、プロジェクト全体のアウトプットにつながる
- 個人個人のアウトプットを担保するのがチーム
- チームとして品質を向上させることが必要
レビューの重要性
- プロジェクトの方向性を疑うことを忘れないのが大切
- プロジェクト内のみにとどまらない
- プロジェクト間においても横断的に、かつ定期的にレビューを行う
- レビューを活性化するために
- プロジェクトに直接コミットしていない、異なるスペシャリストもレビューに含める
- レビューはフラットな関係性で行う
チーム分けのパターン
- スキルの高いメンバーだけで構成されている場合
- 機能でチームを分ける
- 各担当者が1つの機能の開発を担当
- 設計から動作確認まで自分で全て行う
- 開発の楽しさを感じられるチーム編成
チーム分けの際に同時に考えること
チームリーダー
- チームリーダーはメンバの、最高のパフォーマンスと最高のアウトプットを担保する必要がある
- ただし、その目的はプロジェクト全体のアウトプットに向けられているべきで、決してチーム内のアウトプットを担保するものではない
- チームリーダーは、チーム内で技術的にもっとも優れている必要はない
- チーム内で最もアウトプットに対して求めるクオリティの意識が高い人である
- 全体のアウトプットの進捗や品質を意識しながら、自分のチームへとブレークダウン
- 他のチームへ正確な情報を伝達することも求められる
- チーム内の進捗の把握と共有は、リーダーが管理するためのものではなく、プロジェクト全体のアウトプットを最高のものにするために、正しい情報をリーダーたちと共有するために行うべき
- プロジェクトのアウトプットを考えて、自分のチームが苦戦を強いられているときは即座にアラートを出す
アジャイルな見積りと計画づくり
- (株)永和システムマネジメント
受託開発の難しさ
- プロダクトは「百聞は一見にしかず」
- プロジェクトは「一期一会」
見積もり
- 近いものほど細かく、遠そうなものほど粗く見積もる
- それぞれを相対的な大きさで見積もる
- 見積もりはなるべく開発チームメンバー全員で行う
完了の定義
- 完了の定義をお客様と開発者で合わせておくことが重要
- 完了の定義をフィーチャ(プロダクトで実現したいことをユーザー視点で記述したもの)ごと、イテレーションごと、プロジェクトごとに設定することも重要
アジャイルUXDによる"試行錯誤"のプロセス化
- ゼロベース(株)
UXD
- ユーザーエクスペリエンスデザイン
設計と失敗
- 作る前に考えすぎることなく、まず現物を作ってから考えること
- なるべく早く、少しずつ、実際に動くものを作ること
- 実験して「失敗」しても「学習」と捉える
- 取り返しの付く小失敗は学習のために不可欠
- その学習を短期間に何度も繰り返す
- 「分からない」とこは「分からない」と認めることが重要
- あらゆる願望は現実の前に無力
- 現実に立脚することでしか、失敗を避けられない
- 取り返しのつかない大失敗は、それが失敗だと気がつかずにどんどん進んでしまったときに発生する
不都合を生じる可能性があるものは、いずれ必ず不都合を生じる
アジャイルUXDのプロセス
- 戦略
- 何をしようとしているのか、利用者にどんな体験を提供しようとしているのかを共有
- スコープ
- スコープ(要件リスト)を検討し、決定
- 各メンバーのパフォーマンスを最大化するようなタスクの割り振りを行う
- 構造、骨格
- 要件を実際に設計する際には、まず構造レベルでUIフローを考る
- その後骨格レベルの「HTMLモック」を組む
- 表層
- HTMLモックをもとに静的HTMLのテンプレートを作成
- テストとリリース
信頼とコミュニケーション
- 新規事業の不確実なことが多いので、「やってみなければわからない」ことが多い
- 細かい修正をやり直している暇があったら、そのままリリース
- 利用者の反応を見ながら、別の要件を開発したほうがよい
- このことにより、チーム全体のパフォーマンスを上げる
タスクベースの計画
- 「何をすれば新規事業が成功するか」ということが事前に分かっていることはない
- つまり、事前に計画しすぎないことが大切
- これにより、急な戦略変更/要件変更にも柔軟に対応できる
- 戦略とスコープを押さえた上で、直近のタスクの優先順位だけをしっかり決める
- チームメンバーは最も重要な作業から一つづつ処理していく
- 要点は、チーム全体のパフォーマンスを最大化すること
ソーシャルゲームの創り方・育て方
考えた人が作る
- スピードを第一に考えると、「どんなものを作るか」について頭の中にイメージがある人がそのままコーディングして実現するのが理想的
- エンジニア自身がデータ分析に関わり、ユーザーのニーズやユーザビリティを理解し、仕様を決める過程に多く関わるようにする
シンプルかつ少数精鋭でユーザーインパクトの大きいものを
- システムはできるだけシンプルに
- 少人数でも開発・運用できるものに
- ユーザーへのインパクトはできるだけ大きなものに
- できるだけ多くのユーザーに喜んでもらえるものに
前例がないものを作る
- 前例がないものを作るときはやってみないとわからない
- 手っ取り早く動くものを作って、自らそれを使ってみる
- 動かしてみたら、違う側面も見えてくる
- そこでプログラミングしなおす
- 動かして、修正するといういわば「粘土をこねる」ような作業を繰り返す
- 誰も見たことのないサービスやゲームが生まれる
- つまり、サービスの企画者が実装も行えると、良いものを考えながら作ることができる
- サービスの実現性が技術と表裏一体になっていて、出来れば、一人の人間が両方の側面を持っているのが理想的
サービスは「創る」だけではなく「育てる」もの
- 開発のゴールはリリースではない
- リリースしたあと、どれだけサービスとして成長させられるかが勝負
- ユーザーの行動をDBやアクセスログなどからつかみ、改善点を見つけて改善していく
- 状況を把握し、次の打つ手を考え、開発/投入し、効果を分析して次にまた活かすというサイクルを、できるだけ少人数で素早く回していく
- 考える人とコードをいじる人を分割しないことが重要
インフラチームと開発チーム
- インフラチーム
- サーバの運用/保守、システム性能監視を担当し、障害発生時の一時切り分けなどを担当
- それに加えて、データベースのテーブル設計のレビューやSQLチューニングでも貢献
- 開発チーム
- このような体制を敷くことによって
- インフラチームが常時性能監視を実施し、適切な対応方針を定めることができるため、急激なユーザーの増加や新規機能追加時のシステム負荷増加に即時対応出来る
- そのためには、インフラチームの高いシステム運用力が必要
大きめのチームによる開発サイクル
- 案件出し
- 案件計画
- 2週間に一度、登録された案件を確認し、優先順位をつけて、スケジュール概要と開発担当を決める
- 日々の作業
- 業務終了時に現時点での作業状況をチケットに記載する
- 朝会で前日にアップデートされた案件リストを見ながら各メンバーが作業報告を行う
- 進捗が計画より遅れている場合は、他のメンバーに手伝ってもらうように依頼する
- 逆に前倒しで進んでいる場合は「このチケットも吸収できそう」というような提案を行う
- 前日の実装を通して見えてきた仕様に関する議論を行うこともある
- 朝会は、「今」に焦点を合わせたMTG
- 週次MTG
- 長期的なスパンの話題をする場
- 分析の結果やアイデア出しなど
- 案件レビュー
- イベントがひとつ終わるごとに関係したメンバーで振り返りを行う
- 売上やユーザー行動の分析を行い、次の施策に結びつける
- 障害が発生した場合は、再発防止の検討やプロセス自体の改善について議論する
情報共有・記録
- チーム間での情報共有がおろそかになりがちなので、情報共有の場の提供を意識する
- エンジニア全員が集まる定例会議を実施
- 各ゲーム開発の進捗状況を共有するとともに、発生した障害の共有、技術/運用ノウハウの共有を行う
- Wikiには、技術情報、運用情報など記録
- やるべきことのチェックリストなどを記録化し、作業の抜け漏れを防ぐ
まとめ
- 体制を変化
- 関わる人数が増えることで体制を変化させてきた
- ある程度のルール化や会議体を設定
- 自由度を持たせながらも効率よくビジネスの要求を満たせるような開発が進むような体制
- 人数に応じたルールやプロセスを選ぶことも重要だが、変化に対応することがもっと大切
- 状況の変化に応じて、どういうやり方にすればもっとうまくいくかということ考えて適宜取り入れていく
- 関わる人数が増えることで体制を変化させてきた
- 重要なこと
- 同じことを続けない
- 常に最善な方法を検討する
- 誰でもそういった提案を行って改善につなげるということ
最後までお読みいただきありがとうございました。
