システムリプレイスをウォーターフォール開発で進めようとしたがハイブリッド開発にした話

ソフトウェア開発プロジェクトはウォーターフォール開発が良いかアジャイル開発が良いか、という議論は、エンジニア界隈でも盛んに取り沙汰されてきた興味深いテーマの一つです。 今回、スクーがSchooサービスのシステムリプレイスプロジェクトを進めるにあたり、どのような選択をしたのかや失敗したことなど、一つの事例としてご紹介したいと思います。

Transcript

1. システムリプレイスをウォーターフォール開発で進めようとし たがハイブリッド開発にした話 株式会社 Schoo 滝沢 浩樹 4社が語るリプレイス・リニューアル最前線 25/09/25
2. 自己紹介 株式会社Schoo 滝沢 浩樹 (Takizawa Hiroki) @schoo_hiroki_takizawa(Qiita) 業務内容 開発チームの組織化 エンジニアの育成 開発組織の課題定義 プロジェクトマネジメント
3. 簡単に事業の紹介
5. 本題
6. システムリプレイスをしたことはありますか？
7. システムリプレイス、どう進めたらいいんだろう...
8. システムリプレイスを始めるにあたり、やることはいろいろある プロジェクトの目的、成功条件を明確にする 現行システムの課題を明確にする 移行方式を決める 一括移行方式、段階移行方式、並行移行方式、パイロット移行方式 進行方式を決める ウォーターフォール開発、アジャイル開発 使用する技術やシステム構成を決める プロジェクトの期間、予算（メンバーアサイン）を決める ...etc
9. システムリプレイスを始めるにあたり、やることはいろいろある プロジェクトの目的、成功条件を明確にする 現行システムの課題を明確にする 移行方式を決める 一括移行方式、段階移行方式、並行移行方式、パイロット移行方式 進行方式を決める ←今回はここの話 ウォーターフォール開発、アジャイル開発 使用する技術やシステム構成を決める プロジェクトの期間、予算（メンバーアサイン）を決める ...etc
10. 現代、プロジェクトの進行方法の主流は大きく2つ ウォーターフォール開発 アジャイル開発
11. それぞれのメリット/デメリット メリット デメリット ウォーターフォール開 発 ・計画性が高い ・品質管理がしやすい ・大規模プロジェクト向き ・ドキュメントが充実する ・変更への対応が困難 ・完成まで時間がかかる ・顧客との連携が少ない アジャイル開発 ・変化への対応力が高い ・顧客満足度が高い ・リスクの早期発見 ・チームのモチベーション向 上 ・全体像の把握が難しい ・ドキュメントが不足しが ち ・チームの連携が不可欠
12. さて、今回のプロジェクトはどうだろうか？ 大規模であり、計画的に進めたい 要件は明確で、変更は少ない ドキュメントをしっかり残していく必要がある ということで...
13. ウォーターフォールで進めるぜ
14. ...うまく行きませんでした
15. どうなったか？ 実装以降のフェーズが上手くいくイメージを持てなくなった。 詳細見積の精度が想定より低く、上げるためには更に調査・検討の時間が必要な 状況となった 一方で、既に調査・検討に多くの時間を使っており、停滞感からモチベーション が低下していった
16. どうしてこうなったのか？ 不確実性の多さ（＝複雑さ）を見誤っていた。 要件を決めるための情報が足りない 既存仕様の把握や意図の理解が不十分 採用する技術スタックへの学習が必要 データ仕様の把握が簡単ではない
17. 問題の状況分類で思考する 問題の複雑さを分類する手法の1つ としてCynefin Frameworkがあ り、 どう見立てるかによって、その 後取るべきアクションを決める。 明白系：自分たちで解く 煩雑系：専門家に相談して解く 複合系：試行錯誤で答えを導く 混沌系：解けるか分からない が、まずはやってみる 謎・混乱：分類不可能
18. システムリプレイスをどう捉えるか 経験則として、システムリプレイスは「煩雑系」に類する問題になりやすく、その場 合の進め方としてウォーターフォールが適している場合が多い。 既に数年運用しているケースが多く、得てして大規模システムになりやすい 既に動いているシステムがあり、要件定義すべきところは多くない 関係者が多く、調整が大変なので、なるべく運用は変えない 判断 私「そんなに複雑なことはないだろうし、煩雑系と見るなら、ウォーターフォールが 適しているだろうな」
19. 結果、それはただの思い込みだった！
20. 実際は... 複合系に近い問題だった。 既に数年運用しているケースが多く、得てして大規模システムになりやすい → ◯ 既に動いているシステムがあり、要件定義すべきところは多くない → ✕ （そんな ことはなかった） 関係者が多く、調整が大変なので、なるべく運用は変えない → ✕ （今より良くな るなら変える） 新しい技術への挑戦と習熟のためには試行錯誤が必要 → 新しい気づき
21. この状況に対して、より適した方法はないのか？
22. ハイブリッド開発、あるよ
23. ハイブリッド開発とは ハイブリッド開発とは、開発手順を1つずつ確認しながら工程を進める「ウォー ターフォール型開発」と、仕様や設計の変更を前提として厳密な仕様は決めずに イテレーション（反復）を繰り返す「アジャイル開発」の2つの利点を組み合わ せた開発手法です。従来通りプロジェクト計画をしっかり立てつつ、主にモノ作 りの工程を反復的に実施することを基本としています。 ハイブリッド開発とは何か？ “アジャイル型”との違いや推進体制を解説より引用 https://www.sbbit.jp/article/cont1/88907
24. ハイブリッド開発とは ハイブリッド開発とは何か？ “アジャイル型”との違いや推進体制を解説より引用 https://www.sbbit.jp/article/cont1/88907
25. アジャイル開発ではだめなのか？と思った人もいるかも知れない 結論、アジャイル開発でも良かったかも知れない。 ただ、今回は、 期日へのコミットも担保したい 全体最適で考えたい ということで、中間案を採ることにした。
26. 今回の流れの紹介 1. 要求整理 2. 全体設計（システムアーキテクチャ、運用、移行など） 3. イテレーション計画 （#0） 4. イテレーション #1 5. ... 6. イテレーション #10 7. 結合テスト、性能テスト、セキュリティテスト、受け入れテスト 8. リリース ※イテレーション 設計〜実装〜評価（機能、性能、デザインなど）〜振り返り〜リファインメント
27. やってみて良かった点 反復練習によりチームが成長し、イテレーションをやればやるほど安定性が増し ていった 反復的でありながら、部分最適に陥らずシステムの統一感を保てた
28. やってみて難しかった点 初期は開発スピード（ベロシティ）が安定せず、何度かリリースまでの計画見直し を行うこととなった 最初は、特に開発スピードを安定させることに気を払ったほうが良さそう ウォータフォール開発の考え方もアジャイル開発の考え方も抑えておく必要があ り、要求されるマネジメントレベルが高い 他社事例など、もう少しきちんと調べてからやると良さそう
29. まとめ きちんとプロジェクト内外の状況を分析し、最適な方法を選択しよう！
30. ご清聴ありがとうございました。