アジャイルは「開発方法論」と「チームビルディング」の2本柱
私はアジャイルで重要なものは2つだと思います。1つ目は「アジャイル開発方法論」、2つ目は「チームビルディング」です。
■ アジャイル開発方法論
1つ目の「アジャイル開発方法論」とは、アジャイルプラクティスであったり、スクラムといったフレームワークのことです。
こういったフレームワークを使わずにアジャイル開発をしようとすれば必ず失敗します。失敗しなかったとしても車輪の再発明になるので、絶対にフレームワークは使うべきです。
■ チームビルディング
2つ目の「チームビルディング」とは、アジャイル開発ができるチームを作ることです。今回強く訴えたいのは、この「チーム作り」です。アジャイルの話をするとこの観点が漏れている人がほとんどです。
アジャイルは短いサイクルで工程を回すため、開発からリリースまでの期間が非常に短いです。なぜこれが可能かというと、開発メンバーが自分たちで考え、自分たちで判断し、自分たちで問題を解決していくからです。
つまり、リーダーが存在しません。ヒエラルキー型の組織であれば、開発メンバーから情報がリーダーに報告され、リーダーがその内容を精査し、リーダーが意思決定をします。
しかし、アジャイルなチームでは開発メンバーにその意思決定を任せるため、意思決定までがスピーディです。こういう組織を作ることから始めなければなりません。
なお、リーダーが存在しないと書きましたが「全員がリーダー」という方が正しいと思います。
■ 両方が揃って初めてアジャイルになる
「アジャイル開発方法論」を使いこなせるのは「アジャイルなチーム」だけです。ヒエラルキー型のチームに「アジャイル開発方法論」を使いこなすことはできません。
したがって、アジャイル開発をやろうと考えている方は「アジャイルなチーム」を作ることから始めてください。
実際にヒエラルキー型のチームにアジャイル開発を適用した私の経験として、リーダーの負担がウォーターフォールの比にならないくらい大きくなります。リーダーが不幸になりますので、ヒエラルキーでアジャイルはやめましょう。まずはアジャイルなチーム作りです!
この記事が参加している募集
最後まで読んで頂きありがとうございました! いただいたサポートは全て執筆活動の資金としてありがたく活用させていただきます。