Calendarの23日目の記事です。私たちの開発チームでは現在、クライアントワークの中でスクラム開発を実践しています。スクラム開発は、短く反復的に開発するアジャイル開発手法の1つであり、とても人気のあるソフトウェア開発プロセスです。スクラムの定義についてスクラムガイドでは以下のように述べられています。スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。今回は従来の開発プロセスで発生していた問題からスクラム開発を導入する事で改善された事などを記したいと思います。優先度の高いタスクに素早く対応できるようになったタスクがチームに分散し、属人性が軽減されたチームのコミュニケーションが増えて、雰囲気が明るくなったスクラム開発の導入障壁スクラムの習得コストは高い常にコミュニケーションが取れること柔軟性と対応期限のトレードオフスクラム開発に取り組むための心構えコミュニケーションを面倒くさがらない肩書きに固執しない体調管理に気をつける終わりにスクラム開発を導入する前に発生していた問題プロジェクト初期のフェーズからウォーターフォール型に近い形で開発を進めていました。フロントエンドとバックエンドに開発リーダーを立てて、要件定義後に開発の管理者(ここでは開発リーダーと呼びます)がスケジューリングを行い、実装者(ここでは開発メンバーと呼びます)にタスクを割り当てていく形です。ウォーターフォールと言えども、開発途中で要件の変更は多少発生するので開発リソースを調整したり、納期を調整する事である程度の変化には対応していました。開発規模が大きくなるにつれ、そのまま開発を進めていると、様々な問題が生じたのです。開発リーダーにタスクが集中し、開発のボトルネックに開発リーダーはあらゆるタスクを持っていました。以下のようなものです。開発メンバーが少ない頃はこれでも対応出来ていたのですが、あるタイミングで開発メンバーが急増し、開発リーダーが捌き切れない状況になってしまいました。あらゆる情報を開発リーダーが把握していましたが、開発リーダーは常に忙しい状態が続いていたため、情報の共有が遅れがちになり開発メンバーを適切に動かす事が出来ない状況が生まれていました。機能開発優先で品質が悪化し、致命的なバグが中々対応されないそれまでの開発プロセスでは要件定義の段階で企画チームと開発リーダーでリリース日を決めていました。開発メンバーは次のリリースに向けて、一生懸命スケジュールに沿って新機能の開発を進めていましたが、リリース日が近づくにつれて余裕が無くなっていき、本番環境でバグが発生したとしても新機能の開発が優先されてしまい、しばらくバグの対応に手がつけられない状況となっていました。企画段階で具体的なデザインを作成し、プロトタイピングまで行なっていました。企画の会議にはPMや開発リーダーも参加していましたが、基本的には開発リーダーの想定範囲内で実現可能かを判断していました。詳細設計に入ると考慮漏れが発覚したり、開発メンバーの進捗遅れなどでリリースが間に合わない事が後になって分かるような状況が発生していました。リリース日をずらせない場合は要件を削り、デザインの再修正を繰り返しながら、なんとかリリース日に間に合わせていました。前述の問題から開発チームは疲弊し、明らかに負のオーラが開発チームを漂っていました。スクラム開発の経験者が新たに開発メンバーに加わった事もあり、この状況を打ち破るためにスクラム開発を導入する事にしました。結論からお話すると、スクラム開発を導入する事によって、以下の改善が見られました。優先度の高いタスクに素早く対応できるようになったスクラム開発では通常1〜4週間のスプリントという単位で開発期間を区切り、開発内容を決定します。私たちの場合はスクラム開発に慣れるために1週間のスプリントで開発を行なっていきました。1週間ごとに開発する内容を決めていくので、本番環境で不具合が発生したとしても、遅くとも1週間後には対応できる状況を作れるため、優先度の高いタスクに対して細かく軌道を修正しながら対応できるようになりました。タスクがチームに分散し、属人性が軽減されたスクラム開発ではチーム全員でタスクを完了させるという精神があります。そのため、タスクの見積もプランニングポーカーという手法でチーム全員でやりますし、日々のタスクの担当決めや進捗確認もチームで話し合いながら進めていきます。タスクの完了責任は”チーム”にあるため、デザイナーやエンジニアという肩書きで厳密に作業分担は行わず、時には機能横断的に作業を行う場合もあります。これまでは多くのタスクが開発リーダーに依存していましたが、チームで情報を流通させる事によって他のメンバーでも対応できるようになっていきました。チームのコミュニケーションが増えて、雰囲気が明るくなったスクラム開発ではチーム全員で作業計画から日々の進捗確認、プロダクトオーナーへの成果物レビュー、振り返りといったイベントを実施します。そのため、発言の機会が全員に与えられ、必然的にメンバー間のコミュニケーションが活発になり、協力的な関係が築きやすくなります。タスクの見積についてもチーム全員でやる事で認識齟齬や見積ミスが発生しにくく、心理的にも安心感を持って作業計画に臨めるようになりました。スクラム開発の導入障壁スクラム開発を導入する上で予め考慮しておいた方が良さそうな事をいくつか取り上げます。スクラムの習得コストは高いスクラム開発では必ずいずれかのロール(プロダクトオーナー、スクラムマスター、開発メンバー)に属します。スプリントで実施するスクラムイベント(スプリントプランニング・スプリントレビュー・スプリントレトロスペクティブなど)と呼ばれるものもあります。これらのロールやイベントの目的を理解するための学習が必要です。周囲にスクラム経験者がいるのであれば、勉強会を開いてもらうのも1つの手でしょう。それらを理解せずに実践したり、疎かにするとスクラムが上手く回らず、結果的に「スクラム開発はダメだ」とか「このプロジェクトには合わなかった」という失敗に繋がりやすいかもしれません。常にコミュニケーションが取れることスクラム開発ではチームで色々なイベントを実行していくため、コミュニケーションの取りやすさというのは重要です。私たちはクライアントワークでスクラム開発を実践していますが、クライアント先に常駐する事ですぐにコミュニケーションが取れる状態を作っています。リモートワークでも不可能ではありませんが、やはり設備やインターネット回線の問題もありますし、今のところはface-to-faceの方が情報の伝達がスムーズだと感じています。柔軟性と対応期限のトレードオフスクラムではスプリントの最初に見積を行い、スプリントの最後にチームの生産性をベロシティという形で算出します。次回のスプリントでは前回のスプリントのベロシティを参考に作業計画を立てていきます。そのように細かく計画と開発を繰り返す事で、定期的にタスクの優先順位を変えられる柔軟性が得られます。変化に適応しやすい一方で各タスクの対応完了日が予測しにくいため、キッチリと対応期限を決めて進めるタイプのプロジェクトには向かないかもしれません。スクラム開発に取り組むための心構えスクラム開発を失敗させないために、開発メンバーが意識しておくと良さそうな事をいくつか取り上げます。コミュニケーションを面倒くさがらないデザイナーやエンジニアの場合、何もかもSlackで議論してしまうケースがありますが、対面で話したらすぐに解決する事もあります。オンラインを使った方が効率的なケースもありますし、時には集中して黙々と開発する方が良い場合がありますので、状況に応じてオフラインとオンラインを使い分けられると良いかと思います。重要なのはメンバーが主体性をもってコミュニケーションを取ろうとする姿勢があるかどうかです。肩書きに固執しない自分の肩書きに固執すると変化に対応できず、チームとして成果を出しにくくなってしまいます。クライアントワークの場合、デザイナー、フロントエンドエンジニア、サーバーサイドエンジニアは完全分業の体制になる事が多いですが、スクラム開発では自分の強みを活かしつつ、他の職種の作業も手伝おうとするマインドセットが必要になります。体調管理に気をつけるチームメンバーが休んでしまった場合、基本的には他のメンバーが作業を補う必要があります。タスクを完了させる責任は個人ではなく、チームにあるためです。そのため、想定外の休みが多くなるほどメンバーは大変になります。休暇を取る場合はスプリントの初期にチームに共有しておくと作業計画に盛り込めるので良いかと思います。体調は人それぞれですので、無理して働いて悪化しないように休むべき時は休みましょう。終わりにスクラム開発では自己組織化されたチームを目指します。成果を生み出すアジャイルな開発プロセス:書籍案内|技術評論社には以下のように記載されています。スクラムチームのメンバー全員がチームの理想とする姿を考え、その理想に向かって能動的に学習と成長をし続けている状態が、スクラムにおける自己組織化です。「お前のためにチームがあるんじゃねぇ。いう言葉がスクラム開発にはピッタリだと思います。私たちはスクラムを導入して3ヶ月ほどなので、まだまだトライ&エラーを繰り返しながら実践しているところですが、従来の開発プロセスより安定して成果を出せるチームになったと感じています。ウォーターフォール型の開発プロセスが現場で上手く回っていないと感じるのであれば、スクラム開発の導入を検討してみてはいかがでしょうか。ナレッジ・ノウハウチームデザインプロジェクト進行/マネジメント開発この記事が気に入ったらいいねしよう!最新記事をお届けします。OsumiWebフロントエンドのエンジニアをやってます。楽しく生きていきたいです。BlogRECOMMENDこちらの記事も人気です。-本当のフィードバッ...ナレッジ・ノウハウ2019.2.26チームの士気を高めビジネスを成功に導く。【初心者向け】ビジネスに必要な「デザイン思考」とは何か?プロセスをイラストで紹介!僕が今まで愛してやまなかったUI達について語るロゴデザインを始めたいあなたへ!ロゴデザインの主な種類と参考になるウェブサイトまとめ黄金比を使ってロゴデザインをしてみよう任天堂のUI/UXデザイナーが語るデザイン思想。新着記事ラピッドプロトタイピングの実践!NEC×Goodpatchでデザインプロセスワークショップを開催しましたデザイナー出身の経営者に学ぶ新しい企業と「個」の関係性|PR3.0イベントレポート新しいものが大好きなGoodpatchで12月話題になったアプリ、サービス、デザインまとめ(2019)いま、組織デザインが求められている。