アジャイルとプロジェクト管理

みなさんこんにちは。
突然ですが、アジャイル開発をしてみたい！と思ったことはありますでしょうか？

『Agile』を辞書で調べると『機敏』、『敏捷』、『俊敏』、『素早い』・・・と、とにかく早そうな意味が出てくるかと思います。
読んで字のごとく、なんだかプロジェクトが早く回って、なんだか会議の時間も短くて、なんだかどんどんサービスや機能ができていくイメージがほわほわと浮かんでくるのではないでしょうか？

今回は「アジャイル経験者から見たアジャイルのプロジェクト管理」を私の感想からお話しします。

アジャイル開発をしていて嬉しかったこと

私が良かったと思う瞬間は「顧客と一緒にサービス作り、リリースできたとき」です。

どのようなものが喜んでもらえるのか仮説を立て、サービスを考え、価値を考え、小規模にリリースを重ね、利用者の声を聴きながら一緒にブラッシュアップしていき、より良い価値が出来上がっていくのはとても嬉しくやりがいを感じます！

アジャイルは変化に寛容

サービスをつくるプロジェクト全体がアジャイルに寛容であり、変化にも寛容でなければプロジェクト管理は難航するかと思います。

アジャイルで始めたはずなのに、プロジェクト管理をするために要件をしっかり決め、決まった動きを求め、変化に厳しくなっていき、気づいたらウォーターフォールに戻っている、なんてことになってしまってはもったいないですね。

 

なぜこのようなことが発生してしまうのでしょうか？

プロジェクトの進め方のちがい

アジャイルで進めることのメリットは、複雑なものや初めてのことを小さく検証しながら進めることでリスクを低減できることです。

『仮説を立て、サービスを考え、価値を考え、小規模にリリースを重ねる』と先述した通り、 “要件”や “技術”が不確定なものであるものがアジャイルに向いています。
一例としては “要件”は小さく仮説を立て、 “技術”は仮説を具現化するために何を使うかを決めるところからスタートします。

逆に、要件や使う技術が明確で仕様変更がないものであればあるほどウォーターフォールが向いています。

プロジェクト管理のトライアングル

先ほどのプロジェクトの進め方の違いを図にするとこのようになります。

リソース、時間、スコープの3点をどのように扱うのかを守ることで、サービスの品質が確保できます。

ウォーターフォールで要件定義を柔軟に変更してしまっては大変なことになってしまうのは想像がつきやすいですね。

まとめ

アジャイル開発は考えることがとてもたくさんあります。
ですので「仕様書や設計書を決めてもらわないとできません」はありえません。（外部連携のために仕様書をもらうことはあります）

お客様はもちろん、上司部下、先輩後輩、仕事には様々な人が関わっていますが、仮説に向かってみんなで考え、みんなでつくり上げていくように、アジャイルをするための方法を考えるのではなく、みんなでわいわい考えていたらいつの間にかアジャイルになっていて、そのモチベーションを保てる環境がアジャイル開発であると私は思っています。