目的

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

背景

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

問題事象の分析

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

課題設定

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

結果

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

参考

  • アジャイル開発に習熟するために知っておきたい情報
  • アジャイルソフトウェア開発宣言
    • この宣言を道のりの起点にすると、アジャイル開発理解の見通しが良い
    • 2002年頃に宣言の文章を読んだ時は「理想はわかるが実際どうやるのだろう」と思った
      • エクストリームプログラミングという開発手法があるらしいという情報には触れたし、社内で少し話題になった
      • そのころに当時の先輩と2-3回ペアプロをしたが、それっきりやめてしまった
    • ソフトウェア設計の技術書を読みまくった時期(2021年-2022年)に、宣言した人の顔ぶれが読んだ技術書の著者だと気づいた
    • 気づいたきっかけは書籍「.NETのエンタープライズアプリケーションアーキテクチャ　第２版」
      • “Evansの代表作に著されているDDDの定義では、ドメインモデルという言葉は Martin Fowler が定義した Domain Model パターンに由来しています。”と書いてあった
      • この文章から、ソフトウェア設計技術というのは影響を受けながら進化・変化しているという理解ができた
      • さらに、それらの設計技術はアジャイル開発を成立させるための技術なのでは、という仮説に気づいた
      • この書籍の最初の方にアジャイルマニフェストについて言及があった
      • アジャイル開発手法としてエクストリームプログラミングやスクラムについて言及があった
  • アジャイルソフトウェア開発宣言の読みとき方
  • アジャイルマニフェストはいまだに重要性を持つか
    • スクラムがうまくいかなかった理由を分析していた当時にAtlassianの記事を見つけた
    • 以下の文章が目にとまった
      • “「偽のアジャイル」 (別名「ダーク アジャイル」) は、アジャイル教育とコンサルティングの収益化によってさらに悪化すると多くの人が主張しています。”
    • アジャイル開発のコンサルタントはポジショントークしている人がいるかもという観点を持つきっかけとなった
  • アジャイルプロジェクト実践ガイドブック
    • IPAがまとめた資料なので信頼できそう
    • アジャイルに取り組む前に読むべき資料
    • この資料はスクラムなどのプロセス寄りの話ではなく、必要な技術・スキルについて詳しく書いてあるという点で役にたつ
    • 「Ⅲ. アジャイル開発における技術と難所」
      • 「テスト駆動開発」「ドメイン駆動設計」は個人的に頑張ったし、必要性についても実感がある
      • 「CI/CD」「ペアプログラミング・モブプログラミング」「クラウド技術」は、取り組めてないのでこれから頑張りたい
    • 「Ⅳ. エンジニアのスキル」
      • “アジャイル開発では、１、２週間の繰り返しの中でも、拡張性と変更容易性を考慮した設計・実装・テストを実践できるエンジニアが必要である。”
        • 最初のスクラムが失敗した理由は、まさにこれだったと感じる
    • 「V. アジャイル組織の育て方」
      • 知らないことばかりなので試してみたい
  • アジャイル開発の進め方
    • IPAがまとめた資料なので信頼できそう
    • この資料の内容は初めてスクラムに取り組む前にチームメンバーは読んでいた(けど、うまくいかなかった)
    • 個人的には、アジャイルプロジェクト実践ガイドブックの方が必要な情報だった
  • スクラムとエクストリームプログラミングについて
    • ちょっと前まではどちらの手法でも好きに選べば良いと思っていたし、スクラムが一般的だと思ってた
    • 以下の違いがあるらしい事を最近知った
      • スクラムはプロジェクトマネジメント・ビジネス寄りの手法
      • エクストリームプログラミングはプログラミング・技術寄りの手法
    • 参考情報)

まとめ

  • 情報の整理ができた
  • 次にアジャイル開発する時のために何に取り組むか決まった
  • 次の取り組み
    • LeanとDevOpsの科学を読んでアジャイル開発の視野を広げる
    • エクストリームプログラミングの技術的プラクティスの全体像を把握する