アジャイルを決めていない言い訳にするな！とある現場で起こった納期のかかるアジャイル開発

アジャイルを決めていない言い訳にするな！とある現場で起こった納期のかかるアジャイル開発

新年…とっくに明けてしまいましたが、おめでとうございます。
年末に事件が勃発し、ブログを書く時間がないという状況で2ヶ月放置してしまいました。
全然書けなかったなぁ
ちなみに、発生した事件と本記事の内容は別物でございます。
事件についてはまたのちの記事で記載していこうと思います。

最近どの案件でも「アジャイルで」「スクラムで」「ウォーターフォールは古いから」といった言葉を聞きます。

アジャイルを採用する一番の理由は『フレキシブルで短納期を実現できるから』と言うものだと思うのですが「やり方間違えると納期かかるよ」と言う話を実例を交えて記載していきたいと思います。

とある現場で起こった現象

当初2ヶ月あれば終わると判断していたプロジェクトが6ヶ月を経過しても終わりません。
開発スタイルは「アジャイル」です。

先に記載した通り、アジャイルは【納期】と【柔軟さ】に特徴があります。
その短納期というメリットが無くなってしまいました。
この原因はプロジェクトの進め方にあったのですが、コレは後述します。

まずはアジャイルってなんだっけ？を復習してみましょう。

アジャイル開発のメリット/デメリット

発注ラウンジと言うサイトからの引用抜粋です。

メリット

アジャイル開発のメリットは、不具合が発覚した際に戻る工数が少ないことです。従来のウォーターフォール開発の場合には、最初に決定した設計・計画を重視するため、トラブルの発生箇所によっては戻る工数が大きく、時間やコストが膨大に膨らむ可能性がありました。しかし、アジャイル開発の場合は、小さな単位で計画から設計、実装、テストを繰り返しているため、テストで問題が発生してもひとつイテレーション内を戻る分の工数で済みます。

また、計画段階で綿密な仕様を決めないため、開発途中でユーザーとコミュニケーションを取りながらフィードバックを行い、確認をしながら進められます。仕様変更や追加に対応可能なので、ユーザーのニーズに最大限応えることができ、高い満足度が得られる点もメリットでしょう。

デメリット

計画段階で厳密な仕様を決めていないため、開発の方向性がブレやすいというデメリットがあります。さらに良くしようと改善を繰り返し、テストやフィードバックで変更・追加を加えていくことで、当初の計画からズレてしまうことが理由です。

また、ウォーターフォール開発の場合は、最初に指標となる機能設計と併せて、開発スケジュールを決めます。あらかじめスケジュールを設定しておくことで現状の進捗度を把握することが可能になります。
しかし、アジャイル開発では計画を詳細に立案しないため、スケジュールや進捗具合が把握しにくくコントロールが難しくなります。チームごとに小単位で開発を繰り返すため、全体を把握しきれずに、気付いたら納期に間に合わないということも起こりえます

コレらをザクっとまとめてしまうと、次のようになります。

PMがしっかりしない現場のアジャイルは地獄という現実

「今どきウォーターフォールなんてあり得ないでしょ！」なんて事を言う人いますよね。
こんな発言をするPMは要注意です。

ウォーターフォールは開発陣を含めて皆んなで仕様をまず固めますが、アジャイルは概要が決まった時点から走り出すことが多いです。
つまりは、PMのしっかりとしたコントロールが必要なんですが、「アジャイルは概要だけ決めてあとは柔軟性が重要だ」なんてこと考えて仕事しないPMいるんです。こう言う現場で起こることは1つです。

ビジネスオーナーとしても納期が伸びる事は『良』ではないでしょうから、エンジニア陣に対する視線は厳しくなります。
なので、エンジニア陣は次に起こる事態を想定してコードを書いてみたりします。
そんな事をしているとPMから重大なアナウンスがあります。

実際に動いた現場で発生したアジャイルな事例

PM：「昨日ビジネスオーナーと話して、ログインの方法変わったからよろしく」

おいおいおいおい。

もうね、パンチがデカい修正で現場は混乱ですよ。
で、エンジニアから2つの手法が提案され、PMに判断が委ねられる事になります。

納期を考えて、PMが【方法 1】での実装を決め動き出すとビジネスオーナーの上層部から【方法 2】での実装を求められ…。

先ほどの転載抜粋のデメリットを再び

計画段階で厳密な仕様を決めていないため、開発の方向性がブレやすいというデメリットがあります。さらに良くしようと改善を繰り返し、テストやフィードバックで変更・追加を加えていくことで、当初の計画からズレてしまうことが理由です。

また、ウォーターフォール開発の場合は、最初に指標となる機能設計と併せて、開発スケジュールを決めます。あらかじめスケジュールを設定しておくことで現状の進捗度を把握することが可能になります。
しかし、アジャイル開発では計画を詳細に立案しないため、スケジュールや進捗具合が把握しにくくコントロールが難しくなります。チームごとに小単位で開発を繰り返すため、全体を把握しきれずに、気付いたら納期に間に合わないということも起こりえます

まさにデメリットを全部実行したような現場ですよね。

アジャイル開発の肝はPMにある

コレは私の持論ですが『PMの頭の中にビジネスオーナーと共通の未来像が描かれているか』がアジャイルが成功するかの肝であると思っています。ダメPMは「アジャイルだから」と言う言葉を仕様をFIXせずに開発着手する言い訳に使います。いやいや、それ違うでしょ。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

引用元：アジャイルソフトウェア開発宣言

これさ、重要なのは次のフレーズだと思うわけです。

残念なPMだと【先のことがらには意味がない】になってしまい、次のことが実践されます。

PMのコントロールが十分に効いている場合、イテレーションの期間が短く2週間とかで回す事になるので、仕様変更も覚えてますしドキュメントなくてもいいかもしれません。でも、ダメPMほど実装期間が長くなるので、覚えていられません。

そう、全ては実装したい全容を小さな単位に分解してオーダーできないPMに責任があります。
全体設計から参加する事多いですが、ざっくりと決まった事を丸投げするPMほど指揮も納期もダルダルになってきます。

PMが行うべきただ1つのこと

現場に入っているエンジニアは皆んな優秀です。
初現場というエンジニアだって、やる気と根気があるので課題を与えれば調べながらなんとかしてくれることが多いはずです。

PMはオーケストラで言えば指揮者です。
指揮者は音を出すタイミングや強弱などを指示しますが、オーケストラの場合は各楽器が奏でるための楽譜「設計図」があるため「どの音を鳴らすか」の指示は不要になります。
一方でIT現場でのPMは設計図の提示もしなくてはなりません。前述したように皆んな優秀ですから、ある程度の設計指示を出せば夫々が最適解を導き詳細設計に落としてくれます。でも「ある程度の設計指示」は必要ですし、この為には「最終型に向けた設計の段取り」が必須になります。どこが揃えば最小構成でリリースできるかといった段取りですね。その為には「何が必要」で「何がある事が理想」で「じゃぁどう段取るか」を考える必要があります。

PMが行うべきただ1つのこと、それはシステム構築の【段取り】です。

段取りができてないからプロジェクトの「仕様が右往左往」し「後期が伸びる」んです。

【仕様を決めずにスタートする事 ＝ アジャイル】ではない

アジャイル開発は決して万能な思考ではありません。
PMの腕に左右される開発手法であり、場合によってはウォーターフォールの方が柔軟で短納期かもしれません。

なぜか納期が伸びてしまうPMさんは開発手法をウォーターフォールの方に少し傾けてみましょう。
必要事項を細かくFIXし、それを書類に残し、開発陣に投げてみてください。
考えながら作るアジャイルよりも実装期間は短く済むはずです。時間がかかるのはこれらの情報整備だと理解できるでしょう。

大きな絵を描いて、その一部を先にまとめてスモールスタートするとかね。
この段取りを行うのがアジャイルの肝だと思うのです、決して仕様を決めずにスタートする事を指した言葉じゃないと思います。
もちろん【書類を整備しないこと＝アジャイル】でもないと思います。それらは段取りをしっかり行った時の副産物でしかありません。

まとめ

「ウォーターフォールは古い」

それは違います。現場と人に合わせて適材適所、であり2択ではなく中間（書類はしっかり整備するアジャイルとか）が存在するのです。
プロジェクトに合わせた開発手法を選択しましょうね。

愚痴っぽくなりましたが、遅い新年一発目の記事でした。
本年もよろしくお願いいたします。