この記事はGoodpatch Advent Calendarの23日目の記事です。

私たちの開発チームでは現在、クライアントワークの中でスクラム開発を実践しています。
スクラム開発は、短く反復的に開発するアジャイル開発手法の１つであり、とても人気のあるソフトウェア開発プロセスです。スクラムの定義についてスクラムガイドでは以下のように述べられています。

スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

今回は従来の開発プロセスで発生していた問題からスクラム開発を導入する事で改善された事などを記したいと思います。

スクラム開発を導入する前に発生していた問題

プロジェクト初期のフェーズからウォーターフォール型に近い形で開発を進めていました。フロントエンドとバックエンドに開発リーダーを立てて、要件定義後に開発の管理者（ここでは開発リーダーと呼びます）がスケジューリングを行い、実装者（ここでは開発メンバーと呼びます）にタスクを割り当てていく形です。ウォーターフォールと言えども、開発途中で要件の変更は多少発生するので開発リソースを調整したり、納期を調整する事である程度の変化には対応していました。

しかし、開発規模が大きくなるにつれ、そのまま開発を進めていると、様々な問題が生じたのです。

開発リーダーにタスクが集中し、開発のボトルネックに

開発リーダーはあらゆるタスクを持っていました。たとえば以下のようなものです。

  • 要件が技術的に実現可能かの検討
  • 開発スケジュールの作成と開発メンバーのアサイン
  • 開発メンバーとして機能の実装
  • 周囲からの技術的な問い合わせの対応

開発メンバーが少ない頃はこれでも対応出来ていたのですが、あるタイミングで開発メンバーが急増し、開発リーダーが捌き切れない状況になってしまいました。

あらゆる情報を開発リーダーが把握していましたが、開発リーダーは常に忙しい状態が続いていたため、情報の共有が遅れがちになり開発メンバーを適切に動かす事が出来ない状況が生まれていました。

機能開発優先で品質が悪化し、致命的なバグが中々対応されない

それまでの開発プロセスでは要件定義の段階で企画チームと開発リーダーでリリース日を決めていました。開発メンバーは次のリリースに向けて、一生懸命スケジュールに沿って新機能の開発を進めていましたが、リリース日が近づくにつれて余裕が無くなっていき、本番環境でバグが発生したとしても新機能の開発が優先されてしまい、しばらくバグの対応に手がつけられない状況となっていました。

不確実性が高く、開発段階で後戻りが発生

企画段階で具体的なデザインを作成し、プロトタイピングまで行なっていました。企画の会議にはPMや開発リーダーも参加していましたが、基本的には開発リーダーの想定範囲内で実現可能かを判断していました。しかし、詳細設計に入ると考慮漏れが発覚したり、開発メンバーの進捗遅れなどでリリースが間に合わない事が後になって分かるような状況が発生していました。リリース日をずらせない場合は要件を削り、デザインの再修正を繰り返しながら、なんとかリリース日に間に合わせていました。

この状況を打破するためにスクラム開発を導入

前述の問題から開発チームは疲弊し、明らかに負のオーラが開発チームを漂っていました。しかし、スクラム開発の経験者が新たに開発メンバーに加わった事もあり、この状況を打ち破るためにスクラム開発を導入する事にしました。

結論からお話すると、スクラム開発を導入する事によって、以下の改善が見られました。

優先度の高いタスクに素早く対応できるようになった

スクラム開発では通常１〜４週間のスプリントという単位で開発期間を区切り、開発内容を決定します。私たちの場合はスクラム開発に慣れるために１週間のスプリントで開発を行なっていきました。
１週間ごとに開発する内容を決めていくので、本番環境で不具合が発生したとしても、遅くとも１週間後には対応できる状況を作れるため、優先度の高いタスクに対して細かく軌道を修正しながら対応できるようになりました。

タスクがチームに分散し、属人性が軽減された

スクラム開発ではチーム全員でタスクを完了させるという精神があります。
そのため、タスクの見積もプランニングポーカーという手法でチーム全員でやりますし、日々のタスクの担当決めや進捗確認もチームで話し合いながら進めていきます。また、タスクの完了責任は”チーム”にあるため、デザイナーやエンジニアという肩書きで厳密に作業分担は行わず、時には機能横断的に作業を行う場合もあります。これまでは多くのタスクが開発リーダーに依存していましたが、チームで情報を流通させる事によって他のメンバーでも対応できるようになっていきました。

チームのコミュニケーションが増えて、雰囲気が明るくなった

スクラム開発ではチーム全員で作業計画から日々の進捗確認、プロダクトオーナーへの成果物レビュー、振り返りといったイベントを実施します。そのため、発言の機会が全員に与えられ、必然的にメンバー間のコミュニケーションが活発になり、協力的な関係が築きやすくなります。
また、タスクの見積についてもチーム全員でやる事で認識齟齬や見積ミスが発生しにくく、心理的にも安心感を持って作業計画に臨めるようになりました。

スクラム開発の導入障壁

スクラム開発を導入する上で予め考慮しておいた方が良さそうな事をいくつか取り上げます。

スクラムの習得コストは高い

スクラム開発では必ずいずれかのロール（プロダクトオーナー、スクラムマスター、開発メンバー）に属します。また、スプリントで実施するスクラムイベント（スプリントプランニング・スプリントレビュー・スプリントレトロスペクティブなど）と呼ばれるものもあります。これらのロールやイベントの目的を理解するための学習が必要です。周囲にスクラム経験者がいるのであれば、勉強会を開いてもらうのも１つの手でしょう。しかし、それらを理解せずに実践したり、疎かにするとスクラムが上手く回らず、結果的に「スクラム開発はダメだ」とか「このプロジェクトには合わなかった」という失敗に繋がりやすいかもしれません。

常にコミュニケーションが取れること

スクラム開発ではチームで色々なイベントを実行していくため、コミュニケーションの取りやすさというのは重要です。私たちはクライアントワークでスクラム開発を実践していますが、クライアント先に常駐する事ですぐにコミュニケーションが取れる状態を作っています。
リモートワークでも不可能ではありませんが、やはり設備やインターネット回線の問題もありますし、今のところはface-to-faceの方が情報の伝達がスムーズだと感じています。

柔軟性と対応期限のトレードオフ

スクラムではスプリントの最初に見積を行い、スプリントの最後にチームの生産性をベロシティという形で算出します。そして、次回のスプリントでは前回のスプリントのベロシティを参考に作業計画を立てていきます。
そのように細かく計画と開発を繰り返す事で、定期的にタスクの優先順位を変えられる柔軟性が得られます。しかし、変化に適応しやすい一方で各タスクの対応完了日が予測しにくいため、キッチリと対応期限を決めて進めるタイプのプロジェクトには向かないかもしれません。

スクラム開発に取り組むための心構え

スクラム開発を失敗させないために、開発メンバーが意識しておくと良さそうな事をいくつか取り上げます。

コミュニケーションを面倒くさがらない

デザイナーやエンジニアの場合、何もかもSlackで議論してしまうケースがありますが、対面で話したらすぐに解決する事もあります。もちろん、オンラインを使った方が効率的なケースもありますし、時には集中して黙々と開発する方が良い場合がありますので、状況に応じてオフラインとオンラインを使い分けられると良いかと思います。重要なのはメンバーが主体性をもってコミュニケーションを取ろうとする姿勢があるかどうかです。

肩書きに固執しない

自分の肩書きに固執すると変化に対応できず、チームとして成果を出しにくくなってしまいます。特にクライアントワークの場合、デザイナー、フロントエンドエンジニア、サーバーサイドエンジニアは完全分業の体制になる事が多いですが、スクラム開発では自分の強みを活かしつつ、他の職種の作業も手伝おうとするマインドセットが必要になります。

体調管理に気をつける

チームメンバーが休んでしまった場合、基本的には他のメンバーが作業を補う必要があります。タスクを完了させる責任は個人ではなく、チームにあるためです。そのため、想定外の休みが多くなるほどメンバーは大変になります。もし、休暇を取る場合はスプリントの初期にチームに共有しておくと作業計画に盛り込めるので良いかと思います。もちろん、体調は人それぞれですので、無理して働いて悪化しないように休むべき時は休みましょう。

終わりに

スクラム開発では自己組織化されたチームを目指します。自己組織化されたチームについて スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス：書籍案内｜技術評論社には以下のように記載されています。

スクラムチームのメンバー全員がチームの理想とする姿を考え、その理想に向かって能動的に学習と成長をし続けている状態が、スクラムにおける自己組織化です。

安西先生のお言葉を借りるなら 「お前のためにチームがあるんじゃねぇ。チームの為にお前がいるんだ!!」 という言葉がスクラム開発にはピッタリだと思います。

私たちはスクラムを導入して３ヶ月ほどなので、まだまだトライ＆エラーを繰り返しながら実践しているところですが、従来の開発プロセスより安定して成果を出せるチームになったと感じています。
もし、ウォーターフォール型の開発プロセスが現場で上手く回っていないと感じるのであれば、スクラム開発の導入を検討してみてはいかがでしょうか。

Share on

Masaki Osumi
デザインとエンジニアリングについて日々考えています。