（Insラボ活動で学んだこと Advent Calendar 2022 7日目の記事です。）
みなさま、こんにちは。アオキです。
私は今年の5月からラボに参加したのですが、ラボではアジャイル開発のひとつ「スクラム」を採用しているものの、これまではウォーターフォール型の開発しか経験したことがありませんでした。
直近私がやった事は「SPAのウェブサイトをGA4でアクセス解析する方法を解説」や「AWS Amplify StudioのUI Kitをカスタマイズしてみた」に書いてるように、React、GTM、GA4やAmplify Studioのようなツールと格闘することが多かったのですが、5～11月の7ヵ月間、スクラムという開発手法を経験して、私なりに感じたことを整理しておきたいとおもい、このテーマで筆をとることにしました。
ラボ全体としての考察ではなく、プロマネ・SE・プログラマと各職能で現場経験を重ねてきた私個人の感想とご理解いただいたうえでお読みいただければと思います(^^)
スクラムの何がいいのか？
スクラムの良さを説明するまえにウォーターフォールでは何が課題だったのでしょうか。
ウォータフォールでは、最初の「企画」の段階で開発対象の機能を全て決めてから「設計」「実装」「テスト」と順に進めていきます。「企画」の成果物としてドキュメントを作成し、そのドキュメントにもとづいて後続の「設計」をしていくことになりますので、仮に「実装」の段階で「企画」に変更が入ったとしたら、「企画」のドキュメント修正からやり直すことになるため企画の変更がしにくい開発手法でした。
なので、ウォーターフォールの下流工程とよばれる「実装」「テスト」の段階まできて「企画」に変更が発生した場合、致命的な問題でない限りは予算の都合もあるので、元々の「企画」のままリリースまで走り切ってしまい、リリース後に仕切りなおすのが多かったように思います。
この進め方で問題になったのが、何をつくるか「企画」する時期と「テスト」を終えてリリースする時期で間があいてしまう、ということです。工数によっては長いと数年、短くても数か月はあいてしまいます。
ほとんどの事業は直接的や間接的に競合が存在しますので、「実装」している最中に当初企画していたものより、競合が優れたプロダクトを打ち出してくる可能性は多いにあり得ることです。
それに下流工程で実際に動かせるものを見ると、やっぱりこうしておけばよかったというのは、ウォータフォール開発を経験した事がある方は心当たりがあるのではないでしょうか(笑)
そこで「企画」から「テスト」までのサイクルを1週間から1ヶ月と区切り、短期間でどんどん機能を追加していくことで利用者のフィードバックを得ながら、プロダクトを少しずつ作っていくほうが、ユーザーが求める価値の提供に早くたどりつける、という考えにもとづいて出てきたのがアジャイルと呼ばれる開発手法で、アジャイル開発の代表的な手法がスクラムになります。
ウォータフォール開発との違い
大きな違いはスクラムマスター(以下、SMとします)の存在です。私はチームメンバーとしてスクラムに参加しましたが、ウォーターフォールからスクラムに移るとSMをプロジェクトマネージャー(以下、PMとします)と混同しがちな気がします。
SMはどの情報にあたっても、スクラムチームのサポート役・調整役・ファシリテーターと表現されており、あくまでもプロダクトオーナー(以下、POとします)とチームメンバーが意思決定する場を設け、プロジェクトの疎外要因があるなら回避する立ち回りをする役割です。
なので、プロジェクト全体をとりまとめるPMとはプロジェクトへのかかわり方が根本的に異なります。
縁の下で支える立ち位置のSMですが、時にチームメンバーにアドバイスが必要になってきますし、チームメンバーがウォーターフォールに慣れているほど、メンバーからはPM的な見られ方になってしまうため、少なくともスクラム導入初期はスクラム開発の啓蒙活動はしつつも、ウォーターフォール同様に開発経験ある方がチームを引っ張っていく動きが必要に感じました。
以前、私がSIerに在籍していたときにプロジェクトが炎上したら、炎上責任はPMにあるのだからPM自らコーディングしてでも火消しすべしと教え込まれましたが、SMもそのくらいの気立てがあってもよいのかもしれませんね。
また、ウォータフォールだとシステムエンジニアという職能の方が「企画」「設計」を担ってましたが、スクラムではそういった役割分担がないのでチームメンバーそれぞれがPOやステークホルダーと直接対話します。
従来は下流工程で「実装」を担当していたプログラマ(以下、PGとします)の方が、上流工程の作業をやることなったら、パフォーマンスを発揮しずらいこともきっとあるかと思います。
例えば調整ごとに慣れていれば、自ら動いてPOに相談し、合意をとって次のアクションを設定できるとおもいますが、不慣れならSMがサポートしていくことになるでしょう。
という具合にPGは元々コーディングがメインでしたが、スクラムでは報連相の場がふえるため、よりコミュニケーションスキルが大事になってきますし、テレワークが普及しつつある昨今テキストベースのコミュ力も重要になってくると思います。
スクラムの理想形はSMがいなくても開発が進行していくことだと思いますので、それを実現するにはより包括的なヒューマンスキルがこれまで以上に必要なのかもしれません。
スクラムイベントを通しての対話はもちろん、開発するにしても自身に経験がないことを求められたら、どうやったらできるようになるかを考えていくことになりますし、チームの内外から学びを得られるよう回りを巻き込む動きも時に必要になるでしょう。それにPMが不在になるので、各々のスケジュール管理も必要になってきます。
こういった動きをスクラムを通してできるようになったら、ウォーターフォール型に戻っても、より評価される人材になるのではないでしょうか。
アジャイル開発の導入時に気を付けること
アジャイルでは開発期間中でも企画の変更や追加が発生したりと作業が流動的になりやすいので、何かの事情で開発から数日離れると復帰時に状況が分かりにくいということが、ウォーターフォールに比べて特にあるかと思います。
なので、あとからでも状況を追いやすいよう、情報のオープン化とアクセスしやすい仕組みづくりを事前に設計した方がよいと感じました。
不在でなくても作業が流動的だと後日あの時はどういう経緯で判断したのかなど、振り返りたい場合があるとおもいますので、情報をどう管理するか前もってを関係者で議論しておくことをオススメします。
それにウェブ業界は人材も流動的だとおもいますので、途中参入されてきた方向けにオンボーディングを支援する情報になるハズです。
参考までにラボではRedmineにタスクの内容を画面キャプチャを併用しながら、なるべく細かく書くようにして、打ち合わせの場合は議事録を作成して議題と決定事項・TODOを残すようにしました。
ラボには他の案件と掛け持ちのメンバーもいたので、タスクを消化した当事者や打合せの参加者でなくても、その時のことが分かるよう情報を残そうと思っていたのです。
昨今、チャットによる非同期型のコミュニケーションが注目されていますが、新規事業のような開発の場合は掛け持ちになる事もあるかと思いますので、プロセスそのものも非同期で共有できるように意識したほうがいいかと思います。（フルコミットできるメンバーを集められるのであれば情報共有の優先度は落としてもいいでしょう）
さらに余力があれば社内Wikiにナレッジを書き連ねてもいいと思いますし、キビシければチーム内の識者が外部メディアの記事URLや課題図書のリンクを掲載するだけでも良いと思います。
このように非同期で情報を得られるようにして、その上で不明点があればチャットやビデオ会議といったツールで個別に確認するのがいいのではないでしょうか。
また、スキルレベルにバラつきがあると、特定のメンバーにタスクが偏ることがあります。
タスクが偏ってもまわりのメンバーでフォローしようという流れが自然にできればいいのですが、導入初期でそう上手くいかなければ、ウォーターフォールでのPM同様にSMが注視した方が良いかと思います。
もし、タスクの割り振りをまわりのメンバーと再配分しようにも、それ以前に育成コストがかかって早期解決できないなら、開発のスピードを落としてでも現メンバーを育成するか、スピードが優先ならチーム編成からやりなおすか、という判断をPOを巻き込んで下す必要があるでしょう。
スクラム開発を導入して効果を出していくには、PO・SM・メンバーの育成にはどうしてもコストがかかるので、導入したもののパフォーマンスが発揮しにくかったら、ダメだと割り切ってウォータフォールに戻さず、組織の都合(メンバー適正や育成状況など)にあわせて基本のフローはおさえつつ現場の作業のしやすさを鑑みて流動的に変えてしまうのもアリだとは思いました。
スクラムと言ってもあくまで開発手法のひとつなので、MVP(Minimum Viable Product=必要最低限の機能のみを搭載した製品)の作成などスクラム導入の目的の共有と、開発と改善をすばやく回そう、という文化づくりが先決に感じますし、大切なのはエンドユーザーへの提供価値を最大化することではないでしょうか。
まとめ
スクラムはスピード重視の開発に適しているため、例えばPMF(Product Market Fit=プロダクトが市場に受け入れられている状態)達成に向けて、MVPをつくるとしたら、実装はローコードツールを使ったり、CI/CDで自動化したりと開発のプロセスに必要なコストを極力削減し、顧客インタビューやカスタマーサクセスにコストを投下して、ユーザ体験を向上させる施策をすばやく取り込めるスクラムを採用したほうがいいと思いますし、情報技術によって作られたプロダクトはリリースして終わりではなく、ユーザーの動向を分析しながら改善し続けることが欠かせませんので、スクラムを取り入れるのは競争優位を保つのに大変意義があると感じました。
一方でウォータフォールに慣れている人がまだ多いと思いますので、外部を含めてリソース確保しやすく、計画を立てやすい特徴がウォーターフォールにはあると思います。それに役割分担が明確で各々がパフォーマンスを発揮しやすいメリットもあると思いますので、開発が流動的にはならない、例えばPMFを達成できたプロダクトをグロースさせるのにスクラッチ開発するとしたら、ウォータフォールが適していると思いました（運用に入ったらスクラムに戻せるよう要件を考えられるといいですね）。
現場からの感想は以上になります。本記事がスクラム導入の参考になれば幸いです(^^)
