はじめに
数年前、僕が勤めていた会社はメンバー全員、毎日0時まで残業することがほとんどでした。
プロジェクト開始直後から、「開発が遅いと言われたらどうしよう」「このプロジェクトを走りきれるのだろうか」という不安を感じていました。
仕事漬けにより学習時間がとれない悪循環も生まれてしまい、数年残業漬けの日々を過ごしていました。
転職して2年ほど経ち、働き方・開発手法・考え方が大きく変わった部分があるので共有したいと思います。
なぜ定時に帰れないか
- プロジェクトの方針を合意できていない
- チームメンバー同士、期待値に沿った動きができていない
- プロジェクト全体で作るべき機能が多すぎる
- 見積もりと作業量に差分がありすぎる
- 問題の発見が遅れ、作業が停滞する
- メンバー視点：弱みを見せられずに、問題の発見が遅れる
- チーム視点：作業、問題を見える化する仕組みがない
- 開発の手戻りが大きい
プロジェクトの方針を合意できていない
これを回避したい
「そもそもこのプロジェクト必要なんですか？」
「このプロジェクトは○○がないと成立しない」
というプロジェクト自体の手戻り
改善策
インセプションデッキを作成して、プロジェクト方針の合意形成をします。
インセプションデッキのテンプレート↓
https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
チームメンバー同士、期待値に沿った動きができていない
これを回避したい
プロジェクトの最終局面にて「最初からそれ言ってくれればやったのに！」というミスマッチ
改善策
ドラッカー風エクササイズを行います。
以下の4つの質問に対してメンバー全員で答えていくと、期待値をすり合わせることができます。
- 自分は何が得意なのか？
- どういうふうに仕事するか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどんな成果を期待していると思うか？
プロジェクト全体で作るべき機能が多すぎる
これを回避したい
「この新機能と同じようなやつなかったっけ」
「A機能とB機能って何が違うの？」
という提供価値の重複
改善策
ユーザーストーリーマッピングを行います。
ユーザーの行動フローに沿って提供価値（ユーザーストーリー）を並べていくことで、提供価値の重複を防ぐことができます。
「ハンマーを持つ人には、すべてが釘に見える」という言葉にもある通り、
エンジニアとして技術を身につけると、何かを作ることで問題解決したくなりがちです。
提供価値から逆算して、本当に作る必要がある機能にのみ絞っていきます。
見積もりと作業量に差分がありすぎる
これを回避したい
「見積もりめちゃくちゃ時間かかる割に激しくずれますよね」
改善策
スクラム開発を行い、イテレーションを回していきます。
まずスプリントプランニングを行います。
相対的に見積もりを行うことで、チーム内でざっくりどれくらいの重みがあるのか、共通認識を作ります。
ここでは議論はせずにあくまでも情報提供のみ、 チーム内の合意は不要です。
スプリント毎にどれくらいのストーリーを消化できているかを確認し、見積もる際の参考とします。
直近3スプリントを平均した値にすると、ブレが少なくなって扱いやすいです。
問題の発見が遅れ、作業が停滞する
- メンバー視点：弱みを見せられずに、問題の発見が遅れる
- チーム視点：作業、問題を見える化する仕組みがない
これを回避したい
「それ、言ってくれたら一瞬で解決できたのに」
「それ僕も同じ地雷踏んだから知ってる」
というムダ
改善策
Slackの投稿ハードルを下げます。
チームのチャンネルを作って全員が垂れ流していれば素晴らしいですが、
難しい場合はtimes_(人の名前)チャンネルを作って、垂れ流すのがよさそうです。
補足
僕はチームとしては問題が埋もれてしまうことが一番のリスクだと考えています。
エンジニア界隈では、よく「よく調べてから質問しなさい」と言われます。
しかし質問のハードルが高いことで、問題の発見が遅れてしまうとチームとしての生産性が大きく下がってしまうため、
以下の表において、問題が埋もれてしまう「検知漏れ」よりかは「誤検出」が多少多くても問題が共有されやすい方に
倒しておくほうが安全なように思います。
| -- | 実際に問題だった | 実際には問題ではなかった |
|---|---|---|
| メンバーが問題として報告した | 問題を発見できた | 問題ではないものにチームの時間を使ってしまった(誤検出) |
| メンバーが問題と認識せず、報告しなかった | 問題が埋もれてしまった(検知漏れ) | 問題は起きておらず、報告も必要ない |
開発の手戻りが大きい
これを回避したい
開発完了してPRを出し、テーブル構成から修正が必要になってしまう
改善策
- 空PRを作成して、TODOを記載
- テーブル構成や、初期にすり合わせたいこともここに書く
- slackを使ってざっくばらんに実況
- xxむずい、など気軽な投稿
イベントの全体像
やや粒度がバラバラですが、下記のようなサイクルで回していくと良いサイクルが作れると思います。
終わりに
今回は開発・チームビルディングをメインとしたアジャイル開発に関するイベントについて書いたので、プロダクトの価値検証の部分はあまり触れていません。
時間があれば、こちらは別の記事として書きたいと思います。