はじめに
この記事は アイスタイル Advent Calendar 2024 3日目の記事です。
アットコスメのWEBを担当しているyamaguchiiです。
私は、アイスタイルの新規事業の開発プロジェクトでスクラムチームにエンジニアとしてジョインしたときに、初めてスクラムの開発プロセスを経験しました。
その時は、これまでの開発プロセスとは全く異なることで、戸惑いつつも必死に付いていくことで精一杯でした。
その後『スクラム』という本を読んで、スクラムの背景となる思想や理念と手法について学びました。
今回は、スクラム開発の経験とこの本から学んだことをテレビショッピング風に紹介したいと思います。
スクラムとは現場の不幸を解決するアプローチだった
現実問題としてこんな現場はイヤだという不満や不幸が多々あると思います。
- 誰が読むのか分からない無駄な資料や報告の作成
- チームの人数が多すぎて、他のメンバーが何をやっているのか分からずコンフリクトが増大する
- 目的も分からないまま修正し、結果のフィードバックもない
- 不具合は開発者個人の責任とされ、無茶な再発防止策や過剰な承認ルールが科されていく
- ルールや承認フローが多すぎて、欲しい情報を得るのに時間がかかる
- 依存するシステムが多すぎて、うかつに修正できない
- 複数のプロジェクトを兼務して、割り込みが入り作業に集中できない
などなど・・・
仕事の目的も結果も分からず、チーム内でメンバー同士のコミュニケーションが取れず、主体的に判断、コントロールできず、やがて燃え尽きてしまうのが「最悪」の現場だとすると、その反対のことができれば、「幸福」な現場となるはずですね。
このスクラム本は、全部で第九章まである構成の中で一章まるまる「幸福」について書かれているのです。
「幸福」なんて書くと、なんだか精神論や自己啓発のエモい話と思われそうですが、そんな仕事の「不幸」を取り除き、解決する具体的なアプローチがまとめられているのが、スクラム開発の手法です。
どうでしょう。少し興味が沸いてきたのではないでしょうか？
具体的なスクラム開発手法とは
チームの人数
まず、スクラムチームは、少人数です。
3～9人まで（ピザ2枚を分けあえるくらい）がちょうど良いとされています。
それ以上になると、コミュニケーションパスが増大し、メンバー間でそれぞれ何をしているのか分からなくなります。
人数が少ないと、誰が何をやっていて、困っていることが分かり、すぐに相談したり助けられます。
単純に人を増やせば、仕事がはかどるというのは幻想（人月の神話）だということはご存じですね。
メンバー構成
- プロダクトオーナー：1～2人
- スクラムマスター：1人
- エンジニア＆デザイナー：2～4人
といった感じ。
各メンバーの役割
プロダクトオーナー
製品の価値やビジョン、目的を明確に伝え、優先順位決め、製品の結果に責任を取る人
スクラムマスター
チームの障害を取り除き、仕事を進みやすくする人
エンジニア＆デザイナー
製品を作る人
スプリント
仕事の流れは、スプリントという一定の短い期間を何周も繰り返しながら進めます。
スプリントの期間は、1～3週間で、同じ一定の期間を繰り返すことで、チームにリズムが生まれます。
１つのスプリント期間内で、プロダクトバックログの中から取り組むタスクを決めて、動くものを顧客に提供します。
その後チームで振り返りをして、改善を次のスプリントに活かします。
見積もり
タスクの優先順位は、メンバー全員で話し合い、プロダクトオーナーが決めます。
タスクの見積もりは、PMやPLなどエライ人が決めるのではなく、全員で行い同意して見積もります。
1,2,3,5,8,13とフィボナッチ数が書かれたカード（プランニングポーカー）を一斉に全員が表にみせ、ポイント付けします。（工数ではないところがミソ）
これは、一部の専門家の意見より、みんなの意見の方が正しいという法則にのっとっています。
全員で決めることで、タスクの重さを共有できます。
振り返り
毎回スプリントの終わりに、何ポイント消化できたかを振り返り、チームの生産性の傾向を測ります。
スクラムでは、メンバー個人の生産性は全く問いません。チームとしての生産性だけが問われるのです。
いかにチームの全体最適を行い、価値を素早く提供することに主眼がおかれているからです。
スプリント内の日常
デイリースタンドアップ
毎日15分間、メンバー全員が集まり、立ったままミーティングを行います。
それぞれが今日チームを良くするためにすることを話します。
カンバン
ホワイトボードを、未着手、進行中、完了の３つの列に分割し、現在のスプリントで、タスクがどの列にあるか付箋をはります。
付箋にはタスク名と、見積もりした時のポイントを記入しておきます。
これにより、誰でもスプリントの進行状況が一目で分かります。
スクラムはゾーンに入る
スクラムマスターは、スプリントの障害物となることにフォーカスし、問題を取り除く手助けをします。
依存する他システムと調整したり、無駄な仕事を無くし、タスクに集中できる環境を整えます。
管理のためのルールや報告を押し付けてくる外部の圧力からチームの主体性を守ってくれる、サーバントリーダーともいえるでしょう。
さて、
- タスクの優先順位はプロダクトオーナーが決めてくれる
- 障害物はスクラムマスターが取り除いてくれる
- 困ったことは、チーム全員で解決してくれる
としたら、開発者はタスクに全集中できるはずです。
「ゾーンに入る」ということを聞いたことがあるでしょうか？
「ゾーンに入る」状態とは、日々の事柄や寝食も忘れて集中する忘我の境地で、今ココに集中し、時間もあっという間に過ぎていくことです。
仕事が面白いように進む。いわゆる「ノッテいる」ときのことで「フロー」状態とも呼ばれます。
この状態になると、高パフォーマンスを発揮して充実感が得られ、「幸福」な状態となります。
スポーツやパチンコでも、この状態が訪れることがあります。
人はこの状態を得たいために、日々体を鍛えたり、スキルを学んだり、パチンコ店に朝から並んだりするのです。
どうでしょうか？
冒頭で挙げた「不幸」な現場と比べて、「幸福」だと思いませんか。
みんなが嬉しいスクラム開発
ここまでエンジニアの視点でメリットを書いてきましたが、
顧客だって、動く製品が素早く提供され、フィードバックが反映されることは嬉しいでしょう。
経営層だって、プロジェクトの状態や生産性が良くなり、それが常にわかると喜ばれるでしょう。
おわりに
現場でうまくいってないと感じたら、今回紹介したスクラム手法を参考に開発プロセスを見直してみてはいかがでしょうか。
Happy Christmas!