見出し画像

ざっくりわかるアジャイル開発

アジャイル開発とはどういうものであったか?
これについては1つの質問から始まる。「クライアントに価値ある成果を毎週必ず届けたいと思ったらどうすればいいだろうか?」

これについてクライアントの視点で考えてみるとアジャイル開発のあるべき姿が見えてくる。
まず、クライアントに信頼されるチームというのは以下のうちどちらだろうか?
・実施計画書や大量の製品文章、作業報告書を納品してくれるチーム
・一番大事だと思う機能を実装して、テスト済みのソフトウウェアとして毎週必ず届けてくれるチーム

事実、分厚い要件定義書に記述されている要件のうちの5%か10%、20%程度の機能を顧客に届けてみれば、実はそれがシステム全体で想定していたビジネス上の利益のほとんどを提供しているということに気づく。
残りの80%は「要件」とは呼べない。つまり、綿密に立てた計画でもやり過ぎてしまっては返って無駄が多くなってしまう。

ちゃんと動くソフトウェアを提供するためにはテストをこまめにたくさんする必要があり習慣化しなくてはならない。
いつクライアントに成果を見せてと言われてもすぐに提示できる状態にしておくことを心がけよう。

さらに、顧客にフィードバックを求めること以外にプロジェクトが狙い通りに進んでいるかを確かめる方法がないことを理解しよう。
フィードバックは行く手を照らすヘッドライトのようなもので、霧のたちこめる高速道路を時速100kmでかっ飛ばしながら、道に迷わないようにするためには絶対に欠かせない。
プロジェクトではいろんなことが怒るし、今週はきわめて重要だったことが翌週にはどうでもよくなることもある。
立てた計画に疑問を抱くことなくただしたがっていてはいけない。
あくまで計画を変えるのであって、現実を変えてはいけないのだ。

成果責任を果たし、クライアントの資金の使いみちを示すことも必要である。
それができて初めて成果責任を果たせたと言えるだろう。
そのためには
・仕事の質に責任を持たなければならない。
・スケジュールを守らなければならない。
・クライアントの期待をマネジメントしなければならない。
・身銭を切る覚悟でクライアントの資金を扱わなければならない。

最後にアジャイル開発における3つの真実を肝に命じておきたい。
1.プロジェクトの開始時点に全ての要求を集めることはできない
2.集めたところで、要求は必ずと言っていいほど変わる
3.やるべきことはいつだって、与えられた時間と資金よりも多い。

さて、「クライアントに価値ある成果を毎週必ず届けたい」と言ったが現実に毎週である必要はない。
これは言葉のあやで、実際には2週間のイテレーションで成果を届けているチームが多い。
大規模はチームであれば3週間となることもあるが、毎週である必要はないのだ。

僕も個人的には「計画と実装の比率を1:9〜3:7くらいで回せたらいいのに。。。」と思いながらプロジェクトを進めている。
いかに早く正確に、要求と要件を洗い出し、仕様に詰め、機能にまで落とし込めるかということを意識してSprintごとに試行錯誤を繰り返しているのが現状だ。

この記事が参加している募集

読書感想文

この記事が気に入ったらサポートをしてみませんか?