スクラムとウォーターフォールの間で開発スタイルを模索している話【アジャイル開発エンジニア勉強会/イベントレポート】

 

登壇者はこの方

*

ウチノ 氏

株式会社ラクスライトクラウド
フロントエンドエンジニア

webエンジニアとしてフロントエンド、バックエンドの開発を経験。ラクスライトクラウド入社後はフロントエンドエンジニアを担当しつつ、スクラムマスター見習い&プロジェクトマネジメント見習いとして日々研鑽中。

 

ウチノ:本日は「スクラムとウォーターフォールの間で開発スタイルを模索している話」と題して、私たちのチームでの取り組みをご紹介します。

スクラム導入の背景

私が入社した当初、エンジニアは3名体制で、使用言語はPHPのみという構成でした。のちにフロントエンドをReact/Next.jsに移行し、技術スタックのモダン化が進みました。

「blastmail」というサービスは、フロント・バックともにPHPで構成されており、各機能が1人のエンジニアに一任される体制でした。
機能の追加・改修がしづらい状況だったため、モダンなSPAへのリプレイスプロジェクトが立ち上がりました。

このリプレイスは、新機能の開発というより既存機能の再実装が中心だったため、開発スピードを重視し、要件定義や設計は簡略化されました。
結果として、ウォーターフォールでもなくスクラムでもない「独自の開発スタイル」で進めていました。

抱えていた課題とスクラム導入

プロジェクトごとに1人の担当がつく体制では、他のプロジェクトの状況が見えづらく、助け合いが難しい状態でした。また、情報やノウハウが共有されにくく、属人化も進んでいました。 

そこで、リプレイスを機に開発体制を見直し、スクラムの導入を試みました。

 

導入内容は以下の通りです:

  • チーム体制でプロジェクトを担当
  • スクラムイベント(デイリー、レビュー、レトロスペクティブなど)の導入
  • コードレビューの実施による知見共有と品質向上

スクラムの導入は、チームとして開発を進める文化を醸成することを目的としていました。
 

スクラム導入による効果

よかった点

  • 認識合わせや意見交換が活発に
    日々のコミュニケーションやイベントを通じて、開発中のすり合わせがしやすくなりました。
  • 進捗の可視化とタスクの平準化
    タスクの偏りが減り、適切に分担できるようになりました。
  • スキルの底上げ
    コードレビューを通じた知見共有により、チーム全体の技術力が向上しました。
  • チームの雰囲気改善
    コミュニケーションが増え、チーム内の風通しが良くなったと感じています。

悪かった点

  • “なんちゃってスクラム”による限界
     形式だけスクラムをなぞっていたため、スプリントレビューなどで手戻りが完全には解消できませんでした。
  • 振り返りの形骸化
    レトロスペクティブが形だけになってしまい、遅延が発生しても有効な対策が取れませんでした。
  • スクラムの知見不足
    社内にスクラムに詳しいメンバーがいなかったため、課題解決に行き詰まりやすい状態でした。

本当の課題は開発スタイルではなかった?

一見、スクラム運用に問題があるように見えましたが、振り返ってみると、本質的な課題は開発プロセス全体にあったと感じています。

 

主な問題点:

  • 要件定義・設計の省略
     初期フェーズで十分な要件整理や設計がされておらず、後工程での手戻りが多発しました。
  • 全体を管理する視点の欠如
    進捗や品質のマネジメントが不十分で、PDCAサイクルが回っていませんでした。

途中からプロジェクトマネージャーが参画したことで、進捗管理はある程度改善されましたが、スクラムの核心である「継続的改善」がうまく機能していないことも明らかになりました。

現在の取り組みと考え方の変化

現在は、必要に応じてウォーターフォールとスクラムを使い分けるスタイルへとシフトしています。

  • 設計や要件定義が重要な案件ではウォーターフォールを選択
  • 開発スピードやチームコミュニケーションを重視したい場面ではスクラムを継続

また、スクラムの継続にあたっては スクラムマスターを正式に任命し、私自身がその役割を担っています。

スクラムマスターとしての気づき

実際にスクラムマスターを経験して感じたのは以下の点です:

  • スクラムは少人数チームに非常に適している
  • チーム内の情報共有と自律的な改善がしやすくなる
  • 一方で、スクラムマスターには高いスキルと経験が求められる

チームの成熟度やメンバーの特性に応じて、最適な支援の仕方を模索し続ける必要があると感じています。

おわりに

開発手法は“目的”ではなく“手段”

最後にお伝えしたいのは、スクラムかウォーターフォールかという議論は手段にすぎないということです。
重要なのは、目の前の課題をどう解決するか。そのために、最適な手法を選び、試行錯誤しながら改善を重ねていくことです。

開発手法に正解はありません。だからこそ、「現場にフィットするスタイルを、自分たちで模索し続ける姿勢」が最も重要だと考えています。

 

 

以上で、発表は終わりです。

 

▼▼ぜひ他登壇者の発表レポートもご覧ください

アジャイル開発エンジニア勉強会
イベント中にあがったQ&Aはこちらをチェック!

www.tech-street.jp

 

こうして私はスクラムマスターをやめた。

小林壮太さんの発表内容については、以下の記事リンクからご覧ください。

こうして私はスクラムマスターをやめた。【アジャイル開発エンジニア勉強会/イベントレポート】 - TECH Street (テックストリート)

 

スクラムマスターなしでもいい感じにスクラム開発している
日下 亜紀子さんの発表内容については、以下の記事リンクからご覧ください。

スクラムマスターなしでもいい感じにスクラム開発している話【アジャイル開発エンジニア勉強会/イベントレポート】 - TECH Street (テックストリート)

 

スクラムとウォーターフォールの間で開発スタイルを模索している話
ウチノさんの発表内容については、以下の記事リンクからご覧ください。

スクラムとウォーターフォールの間で開発スタイルを模索している話【アジャイル開発エンジニア勉強会/イベントレポート】 - TECH Street (テックストリート)

Community Members

さまざまなテーマで事例や知見を学ぶ
IT・テクノロジー人材のための勉強会コミュニティ