【開発の段取り】アジャイルを都合の良い言い訳にしてませんか？

【開発の段取り】アジャイルを都合の良い言い訳にしてませんか？

そう感じるシーンに出会ったのでこんなタイトルにしてみました。
近年では開発スタイルとしてアジャイルを謳う案件が増えているように思います。
旧来型（ウォーターフォール）は遅れた手法というイメージが根付いた様に感じています。

「いやいや、それ違うでしょ！」と言うことをまとめていきます。

そもそもアジャイル開発って何だっけ

細かな解説は他のサイトさんにお任せして。メリット/デメリットだけに触れていきます。

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

つまりは、短いスパンでショートリリースを実行し、その都度【計画 → 設計 → 実装 → テスト】のフローを踏むため（全体のボリュームが少ないので）戻りが少ない。
ショートリリースの都度フィードバックが入り次弾の仕様に組込めるので「顧客満足度が高くなる」と言う仕組みです。

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

結局は「PMとガヤの腕次第」なのがよくわかりますね。
大人しいスタッフばかりの現場では…待っているのは地獄かもしれません。

一番効率の良いアジャイル運用は？

これには私的に持論があります。

人数が増えるとね、意思疎通が問題になるんです。
同じ言葉でもイメージが違って違うものが出来たり、要件の受け取り方が違いパーツAとパーツBに齟齬が生じたり。
ひどい場合にはパーツ間の変数名が違って全体として読みにくいコードが生まれたり。

こんな現場で発生するアジャイル開発の副産物がこちらです。

開発現場で起こっている面白い現象

アジャイル開発って機能だったりフローだったりで小分けして開発していく事が多いわけですが、前段の通りPMが下手だととんでもない状態に陥ります。
そんなコントロール下手なPMのおかげで、プログラマの現場では面白い事象が発生してます。

私じゃないですよ。（私はECと今の現場の掛け持ちで手一杯です）
そもそも、ECを自動化したおかげで手が離せるようになってプログラマの現場入ってるわけですから、私の稼働労力は今の現場に集中です。

が、3つ掛け持ちしても文句を言われない仕事が出来てしまう現場があるのも事実です。
その人的には 50×3 => 月収150万 ですから、まぁありがたい限りですよね、きっと。
で、その方を雇っている事業所さん、エンジニアの力をフルに活用できていないのは明白ですよね。

掛け持ちなんて稀？イヤイヤ、今増えてるそうです

「なんでそんなに掛け持ち出来るんですか？夜とか寝れるんですか？」とお聞きしたところ
「（仕様が決まってないから）実装出来ないとかあって、暇だから新しいところ探して、ブッキングしても問題なさそうだからそのままになってる」のだそうです。
更に、最近フルリモート案件が増えたお陰で掛け持ちしやすくなったんだとか。
なるほどねぇ。

こんな話を受けて、案件紹介サイトの私についてくださっているエージェントさん3名に実態をお聞きしました。
そのうち2名は「そんなのありえないです。（嘘じゃないですか？くらいの食い気味で）」と言い、もう一方は「あ～、よくありますね。会議に『別件で用あるから出れない』とか平気で言う奴いますよ」との事。自身もビデオをOFFにして2つの会議に出席するという会議のダブルヘッダーのご経験があるそうです。

どうやら、現実的には掛け持ちプログラマ増えてきているようです。

スタッフの手が空かない運用をするのが企業的には正解、その為には「決め」が必要

プロジェクトに関わる人間の増加とともにウォーターフォール的な仕様決めは大切になってきます。

開発に関係する人数が多く、階層が深い（発注主から最終スクリプターまでフィルターが5枚あるとか）場合はアジャイルで動いても発注主に否定されて手戻りなんてこともあります。
正直、無駄な時間ですよね。
プログラマ的にも、せっかく作成したシステムが世に出ず没になるのは嫌なものです。
こうならないように、全体をコントロールするPMの力がとても大切なんです。

「フレキシブルが何でも最高」なんて事はありません。

これがアジャイル開発成功のポイントだと思っています。

アジャイル開発を「決まっていない事」の言い訳にしていませんか？

タイトル回収します。

アジャイル開発を前面に出しながら、PMの募集を主力に案件人材を探している企業があります。
こういう現場の面談に参加すると「うちの現場はアジャイルだから、アジャイルで動いたことある？」なんて聞いてくる代表の方がいます。
「イヤイヤ、そちらこそ大丈夫？掛け持ちしてるスタッフ沢山いるんじゃない？」と言いたくなるのをグッとこらえて面談をやり過ごします。

アジャイルという開発手法の目的は何でしょうか。

この文章を見てもわかる通り、個々に開発できるように最低限の取決めをして統合した事。つまりは【最低限のルールを最初に用意した事】が重要なんです。
これが、最近では「機動的な開発手法」という意味で利用する方が増えたように思います。
「機動的な開発手法」になるのは前提条件【決まっている事】が存在してこそですから！

私はコレがアジャイル開発だと思っています。
【実装に影響が出るほどに物事が決まらないし、過去何が決まったか、書類がないから確認するすべもない。】
はい、それはアジャイルだとかウォーターフォールだとかの前に「PMさん、仕事してください」と言う事ですね。

まとめ

最近、現場ではPMの真似事の様な立ち位置で動いています。
具体的には「決まっていない仕様の確定」「決定仕様に対しての問題提起」「チーム内への作業配分」などです。

誰かの作業は他の誰かの下地になっています。
そして、やはりすべての実装の原点は確定した仕様になります。

決まっていないことを明確にする事。
決まっている事をしっかり残しておく事。
開発手法にこだわるのもよいですが「何も決まっていない所には何も生れない」と思います。

それで納期が後ろ倒しになったり、副業スタッフが沢山出現してたら意味ないじゃん。

「みんなが全力で動ける現場」そんな環境がうれしいですよね。
アジャイル開発こそ、仕様の確定とそのための段取りが大切だと感じる今日この頃です。