開発手法の改善とスクラム開発

こんにちは！R&D事業部(以下R&D)の菅野です。
今回はWEBアプリケーション開発におけるチーム開発の手法「スクラム開発」についてフィーチャーし、私達の経験をお伝えしていきます。

どの企業でも職場環境の改善を目指し、日々色々な手法が試されています。
もちろん、それはWEBの開発現場でも同様で、私達は開発環境を改善するために「スクラム開発」を導入いたしました。

スクラム開発とは何か

現在、R&D事業部では、このスクラム開発をメインの手法として、WEBアプリケーションの開発を行っています。

ちなみに、スクラム開発の語源は、ラグビーのプレーの型の一つであるスクラムからきています。
2019年にはラグビーW杯もあることですし、是非このスクラム開発に着目していただければ幸いです！

これまでのR&Dでの開発体制

今からおよそ1年半前(2017年夏頃)まで、私達はウォーターフォール開発と呼ばれる手法で多くのプロジェクトを進めていました。

しかし、この開発手法でプロジェクトの進行が難航したことが何度もありました。
プロジェクトメンバーが複数のプロジェクトを掛け持ちしていたり、突発的なタスクをこなさなくてはならなかったりと、一つの開発に集中できないことが多かったためです。

また、全体像を最初に設計してしまうことから、開発途中に起こるビジネスモデルや要望の変化に対応しにくい手法です。そのため、設計・実装の見直しや修正に膨大なコストを割くことになってしまっていました。

この問題には私達だけでなく、WEBアプリケーション開発を行っている多くの企業が悩まされていると聞きます。私としてはウォーターフォール開発だけでは、全ての開発案件に対応できなくなってきているのではないかと思います。

スクラム開発の導入と、そのメリット

そこで、私達は現状を改善すべく、スクラム開発を導入することに決めました。
スクラム開発は「変化に強い」といわれるアジャイル開発の手法の一つ。導入すれば、私達でもより効率的かつ柔軟な開発が可能になるのではないかと考えたのです。

スクラム開発は「スプリント」と呼ばれる開発期間を繰り返しながら、小分けにした機能をいくつも開発していきます。それらをつなぎ合わせて大規模なシステムとしていく。これがスクラム開発の根幹であり、柔軟といわれるゆえんです。

スプリントのサイクルがこちら。デイリースクラムでは各自の進捗や作業予定を簡潔に報告し合います。バックログとは全てのタスクを一覧にし可視化したもの。これを元に開発が進められます。

また、このスプリントの「プランニング」と「レトロスペクティブ」が開発現場の環境改善において特に有効だといわれています。
スプリント初日に実施するプランニングで行うのは、期間内で開発される機能の見積もりです。見積もりは機能単位で行われ、機能の開発に対してどんなタスクが必要なのか洗い出します。
そのプランニングに対し、レトロスペクティブはスプリントの最後に実行します。レトロスペクティブではスプリント期間内のあらゆることに対してKPT(Keep・Problem・Try)を行い、開発メンバー同士で活発に議論を交わし、振り返りを行うのです。

スクラム開発ではこのプランニングとレトロスペクティブがしっかりと定義されていることが特に着目すべき点です。プランニングとレトロスペクティブをスプリント毎に繰り返し行うことで、次第に開発の精度が上がり、問題点が洗い出され、改善されていくことになります。

スクラム開発導入の苦戦

スクラム開発導入時、私は多くのスクラムに関する書籍や記事を読み、実際にスクラム開発を行っている開発会社のセミナーにも参加してノウハウを学びました。

その中で「スクラムは難しい」という言葉をよく見かけました。難しい理由として、スクラム開発の考え方が開発チームの組織構造に合わない場合があること、開発の全体像が見えにくいこと、などが一般的にいわれています。
R&Dでもひとまずは見よう見まねで始めてみたものの、開発途中でボトルネックになることがいくつもあり、スクラム開発を思ったように進めることができませんでした。

それでも個々のメンバーが率先して推し進めてくれたおかげで、いくつかのプロジェクトの開発にスクラム開発を徐々に適用させていくことができました。他人に任せるのではなく、開発メンバーそれぞれが意見を持ち、スクラム開発に対する理解を深めてくれたことが大きかったように思います。

スクラム開発導入による成果

実際にスクラム開発を進めることで、この手法のキモである「変化に強い」という特長を感じることができました。
機能が小分けになっているので開発途中での要望の変化も取り入れることができましたし、不必要になった機能の削除にも対応することが可能になっています。

また、開発の進捗もその機能単位で表せるようになり、開発に携わるメンバーにとって開発内容の進捗確認がとりやすくなりました。
実際に機能ができて、それが動いているのを見ると開発者自身も前向きになれますので、心理的にもいい影響を与えているものだと思います。

スプリントの存在も、開発にいい面をもたらしました。
先述したプランニングとレトロスペクティブが定義されていることにより、しっかりと見積もりを立てながら、開発環境の改善を実行していくことができています。
特に、レトロスペクティブでは一つの問題に対して全員が意見を出し合い、その対策を考えることのできる場が自然と出来上がりました。これはスクラム開発以外の現場でも積極的に取り入れていくべきだと思います。

▲付箋を使ったかんばん方式でレトロスペクティブを行います。議論が活発になり、毎回白熱！

洗い出された課題

スクラム開発の導入で成果を感じていますが、全てが完璧ではありません。もちろん課題もいくつか露呈することになりました。
その中でも特に重要だと思われる3つをピックアップしましたので、紹介いたします。

①アプリケーションのフランケンシュタイン化
先述した通り、スクラム開発では後から機能のつなぎ合わせの調整が必要になります。このつなぎ合わせの結果、機能ごとにUIやデザインがバラバラだったり、プログラムの結合が突貫工事だったりと「つぎはぎだらけ」のようないびつなアプリケーションになってしまうこともあるんです。このアプリケーションの状態を「フランケンシュタイン化」と呼ぶ方がいます。私達はこの状態の有効な解決策をまだ見出だすことができていません。

②チーム内に「バックエンドエンジニア」と「フロントエンドエンジニア」が必要
機能の開発と画面の開発を同時に進めるため、両者が同じチームに必要だと分かりました。しかし、R&Dはバックエンドエンジニアが主体のため、デザインが必要な部分の制作などでフロントエンドエンジニアが引っ張りだこになってしまいます。そのため、フロントエンドエンジニア不在でタスクがうまく進められないことも想定しなくてはいけません。

③いかに意見の言いやすい環境を作れるか
開発を進めていると、開発チーム内で意見が分かれることが多々あります。しかし、この意見が自由に言い合える環境でないと、スクラム開発は回りません。開発者の意見も次々と反映しながら機能を制作し、柔軟に変化していくことが前提だからです。
この課題はR&D内では意見交換の活性化がクリア済なので解決されていますが、開発チームは常にこれを念頭に置いて進めていくことが特に重要だと実感しました。

まとめとこれからの展望

スクラム開発を導入して、以前よりも開発が円滑に進んでいることを実感しています。
しかし、スクラム開発を導入したからといって劇的に開発スピードが向上したということではありません。
マイクロソフトはアジャイル開発から「DevOps」という手法に移行していると聞きますし、「スクラム開発は遅い」と提唱し始めている開発者も出てきています。

開発手法を変えることで開発スピードを上げられるのであれば、私達もどんどん追随していきたい気持ちはあります。
ただし、まずはどの手法が私達の組織に合っているのかをしっかりと吟味することが必要です。
また、私達が念頭に置いているセキュリティや製品のクオリティを担保するためには、開発手法をR&D流にカスタマイズしていくことが必要だと分かりました。今回のスクラム開発の導入は、これらに気付くことのできた、いい契機になったと思います。
上記のことを意識しながら、R&Dではこれからもより良い開発を目指して取り組んでいきます。

以上、R&Dの菅野がお送りいたしました。次回のブログもお楽しみに！