なんちゃってアジャイルだっていいじゃないか

はじめに

アジャイル開発（スクラム）において

・開発対象となる機能が最初から決まっており、スコープは固定
・システム初リリース日は固定（ずらすことはできない）
・必要に応じて人員リソースを足すことも可

と、聞いたときにあなたはどう感じますか？

きっと、「そんなのアジャイルじゃない」、「スクラムとして間違っている」と感じた人が多いんじゃないでしょうか

私も最初、この話を聞いたとき、「あぁ、これはアジャイルに偽装したただのウォーターフォールだ、経営層を騙すためのなんちゃってアジャイルだ、大炎上して大変な思いをするのだろうな」と思いました

これは私が現場でアジャイルの理想と現実と向き合って戦った実体験から得た
"私なり"の「アジャイル」の価値観を語っていこうと、そういった趣旨の記事になっています

この記事はTDCソフト株式会社Advent Calendarの23日目です
https://qiita.com/advent-calendar/2022/tdc

1.アジャイル（スクラム）って何なんだっけ

顧客が求めるものをより迅速に市場に出していくプロセスがアジャイルだと
まぁそんなところかなと思います

各々自分にとってのアジャイルの定義（価値観）って少しずつ違うと思うので、あまりカッチリしない感じで

2.どこから「アジャイルじゃない！」に変わってしまうのか

何が欠けた段階でアジャイルじゃない！に変わるんでしょうか

例えば先に挙げた例３つをシンプルにするとこのような感じになる
１．開発するものが決まっている
２．納期が決まっている
３．チーム数が増える減る

これ、いずれも普通に起きる出来事じゃないでしょうか
１．開発するものが決まっている
→MVPって概念は必ず存在する

２．納期が決まっている
→プレスのことを考えれば期限があるのはエンタープレイズでは当たり前のこと
　いくらプロダクトの価値が高くとも、それを知ってもらわないことには利用されないので、蔑ろにはできない

３．チーム数が増える減る
→大規模アジャイルってものがあり、SIerという職種が存在している限りこのイベントを0にすることはできない

こんなの普通に起きるね、って内容だなと私は思うわけです
じゃぁ、こんな当たり前なことに適応できなくて何がアジャイルかと

これを受け入れないとしてしまうと、もう日本のSIerはPOCアプリ開発ぐらいでしかアジャイル開発はできないってことになってしまいせんか？

もう少しよく聞く例を出すと

４．設計書を書く
５．なぜなぜ分析をする
６．絶対見積もりをする

とかでしょうか？

設計書を書くのは、ＰＯがそこに価値があると考えているなら問題はないんじゃないでしょうか
なぜなぜ分析をして不具合の再発を防ぐことはユーザー体験の向上そのものではないでしょうか
相対見積もりって結局のところテクニックなので、絶対見積もりをする＝アジャイルじゃないとはならないんじゃないでしょうか

大抵の事は簡単に否定されてしまうと思うんですよね（賛否はあれど）

じゃぁ私の考えるアジャイルじゃなくなってしまう要素は何かというと

改善をしない

改善してないけどアジャイルだ！ってさすがに言えないと思います
レトロやめたらさすがにアジャイルじゃないと感じる、私だけでしょうか？

3.実体験

開発スコープは最初から決まっていて、リリース日も決まっていて、チーム数もタスクに応じて増やしていた案件
そういう案件でしたが、私はこの案件が「アジャイルでよかった！」と思っています。

じゃぁアジャイルマインドや進め方だけでもアジャイルを意識していて、結果として何が良かったのか。
超具体的な良さを伝えておこうと思います

・要件がすべて決まっていなくても開発が始められる！
　ウォーターフォールだと工程ごとに進むので、未確定な要件があるとどんどん遅れに繋がりますよね
　でもアジャイルであれば決まったところから作り始めて、変わったら修正すればいい
　これだけでもメリット特大ですよね
　いったん作ってダメなところは後で直せばいいって改善マインド

・レトロスペクティブのためのタイムボックスが確保されている
　ウォーターフォール案件だとなかなか難しいですよね
　まずタイムボックスを取るだけで調整稼働がかかる、でも大丈夫、アジャイルならね
　改善をするのが当たり前であるという文化

・全てにおいてDEVの意見が反映させられる
　開発の進め方や決め事がトップダウンで決まってしまうことってあると思います
　でもアジャイルをうたっている以上、DEVの意見を聞いてみよう！って流れに自然となるんです
　開発が一番うまく進むようにしたいという全員の改善意識がこの流れを生み出している

少し改善とはずれるけど、

・どの機能でもみんな直せる
　バックログの優先順に作業していくおかげで、俗人化が防げていた
　●●さんがお休みした、ってことはこの機能の仕様がわからない！って事件は避けられる
　これってすごく大きいですよね

こんなこともありました

一般的にそんなのアジャイルじゃない！って言ってしまうような要素をたくさん含んでいても
アジャイルでやっててよかった！って思える箇所ってたくさん存在するはずです

LeSSでも語られている「守破離」の考え方からすれば
●●でなければならない点なんてほとんどないはずなんですよね

4.私にとってのアジャイルとは

結局のところ答えはシンプルで

現状を良しとせず「より良くする方法は無いのか？」と、疑問を持ち改善に全力を注ぐこと

つまり 改善 これがすべてだと思っています

もし今あなたが「なんちゃってアジャイルだ・・・嫌だ・・・」って思っていたら、
改善に目を向けてください

改善に取り組んでさえいれば、少しずつ物事は良くなり
私たちはアジャイルな心を持っていると胸を張って言えるはず。です。