アジャイル開発への道

目的

  • アジャイル開発に習熟したい
  • 自身の経験の棚卸し
  • 役に立ちそうな情報の整理
  • アジャイル開発を成立させる要因について自身の見解を持ちたい
  • 注意)記載内容は、あくまで個人の経験に基づく主観です

背景

  • 2020年にスクラム開発にチャレンジ中のプロジェクトにPMとして合流した
    • その時はプロジェクトがうまく進んでなかった、具体的には...
      • 2weekのスプリント期間にタスクが終わらない
        • 終わらなかった作業を別タスクとしてチケット化して継続開発してた
      • スプリントが終わった時点で動作するソフトウェアがない
        • スクラッチから開発したので動作するまでの実装量が多かった
        • GUI画面が多かったしUI/UX考えながら作ってた
        • 別システムとの通信部分が実装されないと主要な機能が動かないシステムだった
      • PBI(Product Backlog Items)が100個くらいあった
        • 作りたい機能の数が多そうに思うが普通なのだろうか？
          • 受託開発の見積もり規模算出のために必要だった
        • PBI全部にストーリーポイントを振ってた
      • ストーリーポイントの見積もりが妥当かどうか判断つかなかった
        • 経験を積んで見積もり精度が上がれば良い？
      • スプリント期間に対応中のタスクの半分は課題があって進みが悪かった
        • タスクに着手してから新しい事実がわかってストーリーポイント通りに開発できない事が頻発してた
      • スプリント振り返りを途中からやめた
        • KPT法で振り返りを実施していた
        • 議事録から推測するに、学びはあるが改善につながる分析・行動への落とし込みまでできてなかった状況
        • 開発が遅れてたため、振り返りの時間を開発に充てる方針となった
      • リリースマイルストーンに対して開発が順調でなかった
        • ベロシティが改善すれば間に合うという説明をしていたが、改善の見通しが立ってなかった
    • 3ヶ月ほど様子見したが最終的にスクラムやめてウォーターフォール開発に変更した
      • 開発計画を立て直した結果、顧客の要望に沿ったリリースができた
  • その後3年くらいクリーンアーキテクチャ・ドメイン駆動設計・テスト駆動開発などに取り組んだ結果アジャイルっぽくなった
    • アジャイル開発を実現させるために支配的な問題は、スクラムのプラクティスではなくて設計スキル不足だと思うようになった
  • チームの熟練度があがりドメインの知識も獲得したので、アジャイル開発に再チャレンジしようという意見が出てきた

問題事象の分析

  • スクラムをやめたあと、なぜ上手くいってないのか色々と分析した
  • そもそも難しいプロジェクトだった
    • 3プロジェクト(3つのシステム開発)を並行して進めるプロジェクトだった
    • 初めての顧客、初めてのドメイン知識となるプロジェクトだった
      • 会社としても新規事業領域だった
      • ブリッジSEとして出向している人がいて連携が取れる体制になってはいた
    • 複数のサブシステムを連携させる複雑なシステムだった
    • 3つのうち2つのプロジェクトは別会社が過去に開発したソースコードをベースに仕様追加・変更するプロジェクトだった
      • いわゆるレガシーコード
  • 良い設計について語れる人がベテラン１名しかいなかった
    • ベテランについていけるほど設計スキル・経験がある人は自分も含めていなかった
  • PLはプロジェクト運営経験が少なかった
    • スクラムガイド通りに運営することを目的化している雰囲気がうかがえた
    • チームが混乱していた時に立て直すための仕切りができていなかった
    • プロジェクトにどんな課題があるか整理されておらず、またチームに共有されてなかった
      • プロジェクト課題の分析・対策が着手できてなかった
      • プロジェクト課題の優先順位づけがされてなかった
  • 良かった点
    • チームメンバーが意欲的で協力的だった
      • 当時のPLや若手メンバーは自主的にスクラムについて勉強してた
      • 振り返りや勉強会でチームメンバーに対してスクラムの情報共有もされていた
      • スクラムのプラクティスは一通り取り組めていた
    • スクラムの運用ツールも用意されてた
      • Atlassianツール(JIRA,Confluence)を使ってスクラムを運用してた
      • ソースコード管理がGitではなくSVNだったのは残念だったが、そのことを課題と感じることはなかった
    • 顧客の担当者の方がとても優秀かつ意欲的・協力的だった
      • プロダクトオーナーとして密なコミュニケーションを主体的にとってくれた
      • デイリースクラムやりましょうと言ってくれて、毎日ミーティングでコミュニケーションとってくれた
      • ウォーターフォールに変えた後も、プロジェクトが安定するまでデイリースクラムを継続した
      • 率直な意見交換をしてくれた
        • アジャイル開発をとてもよく研究されているようで自身の見解を話してくれて参考になった
        • 設計改善のためにアーキテクチャや設計技法の導入を強く推進してくれた
        • 顧客はソフトウェアエンジニアではないのに、自分より設計技法について詳しかったのは反省点
        • それ以来、自分も継続的に勉強するようになった
        • プロジェクト課題を設計改善で解決するという視点は衝撃的だった

課題設定

  • ウォータフォールでの計画作成やプロジェクト課題解決は得意だったので、プロジェクトの混乱は解決した
  • 仕様追加に時間がかかる、バグが多い、機能追加の影響でバグが出る、開発期間が長いなどの課題が残った
  • ソフトウェアの設計改善により課題を解決する方針とした

結果

  • 設計改善により、ソフトウェアの理解容易性・修正容易性・テスト容易性が改善された
  • 開発期間が短縮された
  • バグも減った
  • 仕様変更も容易になった
  • 自身の設計スキルはとても向上した
  • チームメンバーも設計を理解して開発できるようになった
  • 設計スキル向上や開発体験向上によりチームメンバーが喜んでくれた

参考

まとめ