「アジャイル開発を採用したい」と考えている人は年々増加傾向ですが、アジャイル開発を採用しているプロジェクトは未だに少ないです。
そのため、アジャイル開発のノウハウはウォーターフォールモデルと比べると非常に少ない印象です。
ノウハウが少ないため、最初に大きな失敗をする可能性は、結構高いような気がしています。確実に成功する方法を見つけることは難しいです。
しかし、確実に失敗する方法を見つけることは経験を積めばある程度は見えるようになるので、失敗しないために確実に失敗する方法を避けることが大切です。
そのため、アンチパターンというものが存在します。
私はSIerながら、アジャイル開発を約1年半の間やってきました。SIerだからか、完全なアジャイル開発というわけではなく、プロジェクトや顧客の現状に合わせて少しずつ書籍の内容からカスタマイズしていました。
そんな現場だからこそ得られた、アンチパターンがあります。
ということで、今回は現場から得た生のノウハウを共通させて頂きます！
アジャイル開発の誤解で生じるアンチパターン
以下では、「アジャイル開発の誤解で生じるアンチパターン」をまとめていきます。
アジャイル開発を銀の弾丸だと思って、盲信する
よくアジャイル開発について初心者の人に質問されるのが、このような疑問。
アジャイル開発ってドキュメントを作らないのですよね？
これは、「ドキュメントよりも、動くソフトウェアを重視する」という話です。
これはよくある誤解で、アジャイル開発ではドキュメントは全く書かないという話ではありません。
「アジャイル開発を採用すれば、ウォーターフォールモデルで抱えていた課題が解決する」という、銀の弾丸ではありません。
そのため、アジャイル開発のやり方を盲信して、効率の悪い方法を取るのは良くありません。
試しに「アジャイルソフトウェア開発宣言」というドキュメントを検索して見てみて欲しいのですが、アジャイル開発は非常に曖昧なもので、状況に合わせて解釈をする必要があります。
つまり、自分の組織や案件やその時の状況に合わせて、アジャイル開発とウォーターフォールモデルの良いところを取り入れて、カスタマイズをしていく必要があるということです。
アジャイル開発でのチームの在り方に対するアンチパターン
ここからはアジャイル開発とチームとの関係性で生じるアンチパターンです。
アジャイル開発において、民主化はいつでも正しいと思い込む
「チームのみんなで考える」ということは一般的には非常に正しいことのように思えます。みんなで考えると思考のプロセスを共有出来て、納得感が出ますね。
またみんなで考えたという事実によって、仮にそのアイデアが失敗したとしても、誰かに責任転嫁することは難しいので、そんな発想に至ることも少ないと思います。
しかし、最初からみんなで考えた意見ってイマイチなこと多くないですか？
心理的安全性が確保されているチームであっても、他人が言った意見に対して否定をするのは結構骨が折れます。
自分の意見が正しい選択なのか、自分の中でも頭の整理がついていない状況で、相手の意見を否定する時は、尚更しんどい。
みんなで1から議論をして、皆で意見を合わせていくというのはとても時間がかかる作業なのです。
それならば、自分でアイデアの草案を作って、持っていく方が建設的な議論が出来ると思うのです。
ただし、作業時間と品質のバランスは大切にすべきだと思います。
80点を目指すなら2割の時間で済むが、80点から100点を目指すと8割の時間がかかるというパレートの法則に従い、あまり時間をかけすぎず、議論が出来るようアジャンダを作成するようなイメージです。
民主化を意識しすぎて、非効率にならないように気をつける必要があると思います。
改善のループが回らない意味のないKPTをする
KPTというチームの改善のためのフレームワークがあります。
チームの取り組みをKeep(これまでのやり方を続ける)、Problem(チームの課題)、Try(チームが挑戦すること)という観点で、チームの活動内容を振り返ります。
KPTを行う頻度としては、1週間に1回とか、チームで頻度を決めて、決まった時間にやります。しかしながら、KPTをしても、「どんどんと改善されている感覚」が味わえないと、長続きしません。
例えば、Problemが議題として挙がらなかったり、Problemに対するTryを考えてもなかなか実行されなかったりすることがあります。
そうなると、言っても無駄という空気になり、とてもまずい空気がチームに流れていきます。
「言ってもどうせ何も変わらないという気持ち」がチームの中で蔓延してしまうと、チームが停滞していきます。
こうなると、チームの崩壊も近くなります。
チームの上手い運営方法については、以下の記事にまとめています
課題が大きいためにTryの内容も大きくなり、いつまでもTryが完了出来ません。
「課題は小さな単位で分けて、Tryはとても小さなことを設定する」といったことを意識します。
そして、完了ステータスは達成・未達成の2つにして、部分的達成という中途半端な状態を無くすことが大切です。
とにかく、状態がどんどんと変わっていく流動性を感じることが大切です。
直ちに解決が出来ない課題であれば、どこか保存出来る場所に課題を貯めておくことも大切です。
Redmineなんかにチケットとして起票しても、Excelで課題管理票を作成して、管理しても良いと思います。
ヒューマンエラーをいつまでも放置する
人のミスはなくならないということが前提です。
というわけで、人のミスはヒューマンエラーではなく、システムエラーとして捉えて改善することが重要です。
ミスが起こったら、なぜミスが起こったのかと原因追求をして、原因追求したら個人の努力に任せず、仕組み化によって解決することが大切です。
なぜなら、作業量を増やしても限界があるからです。
「頑張って確認作業を増やした結果、ミスはなくなったけど、今までの2倍時間がかかるようになった」となったら、本末転倒です。
頑張るよりも、仕組みを変えることが重要です。
チームの立ち上げ時点でリモートワークに移行する
アジャイル開発だから、リモートワークが出来ないかと言われると全くそんなことはないと思います。私のチームはここ1年くらいずっとリモートワークです。
ただし、チームが誕生したばかりでコミュニケーションが活性化していないと、リモートワークはオススメしません。
現在、自分のチームはリモートワークです。しかし、移行前にチームメンバーとの関係性が出来ていました。
そのため、急にリモートワークに変わっても、現場にいた時と変わらずに仕事が出来ています。
関係性が出来ていれば、「ZoomやTeamsによるビデオ会議をずっとON(顔出しなし、話す時だけミュート解除)で、いつでも話しかけられる状態」にしていると何も問題なく仕事が出来ます。
チームの関係性を作って、気軽に声をかけられる状態になってから、リモートワークに移行しましょう！
アジャイル開発を採用後、リリースまでのプロセスを変えない
アジャイル開発を採用した際に、あなたはアジャイル開発に何を期待して採用したのでしょうか？
おそらく多くの人が今よりも速くアプリケーションをリリースしたいという要望があり、そのためアジャイル開発を採用したという方は結構いるのかなと思います。
ウォータフォールモデルからアジャイル開発に移行したら、リリースまでのプロセスも当たり前に変えないといけないです
しかし、それを忘れることが多いことが意外に思われるかも知れませんが、あります。
例えば、以下のような作業をアジャイル開発になってもしていませんか？
- リリース判定のために、たくさんのドキュメントを用意
- 設計書にハンコを押す
- 色々な関係各所にリリース調整
このような雑多な作業が、ウォータフォールモデル時代と変わらず、残っている場合があります。
その作業の本質を考えて、安全にリリース作業を行うために必要なものであるのであれば、残ったままでも良いと思うのです。
しかし、「なぜこの作業を今もやっているのか説明が出来ないのだけれども、慣例として昔から残っているから今もやっている」という状態であれば、絶対にその作業はなくさないと行けないです。
そうしないと、素早くリリースしていくことは難しいからです。
自動化を本気でやらない
「アジャイル開発だから、自動化をすべきだ」という話ではないのですが、ウォータフォールモデルと比べて、アジャイル開発ではより自動化に本気になる必要があると思います。
なぜなら、短いスパンで成果物を仕上げていかないといけないアジャイル開発では、余計な作業をやってしまうとそのままプロジェクトの失敗に直進してしまうからです。
自動化するためにはLinuxのコマンドを覚えることが基礎となると思います。
参考記事はこちら
時間を作って、自動化を本気でやってみることをオススメします。
顧客との関係性についてのアンチパターン
ここからはアジャイル開発と顧客との関係性におけるアンチパターンです。
プロダクトオーナーと同等の立場の人が複数人存在する
「SIerがアジャイル開発をやってみた」という時に、1番陥りやすい罠がこれだと個人的には思います。
開発チーム側の都合でアジャイル開発を採用しているけれども、「エンドユーザーを含めた顧客までがアジャイル開発でチーム一丸となって開発をするぞと体制が整っていない」時に不整合が起こります。
プロダクトオーナーがフラットな立場でチームの中にいてくれるから、物事の意思決定に無駄がなく、迅速に物事を決められるため、開発スピードの向上に繋がるのです。
しかしながら、プロダクトオーナーがチームの中に入っていない場合は注意が必要です。
プロダクトロードマップをしっかりと作成して、案件の積み上がり具合と各案件の終了時期をしっかりと管理をしていないと、無計画にタスクを積み上げてしまって、後に戻れなくなります。
通常であれば、プロダクトバックログが貯まっていくと、プロダクトオーナーと相談して、優先度を再考して、立て直しを図ります。
しかし、複数のプロダクトオーナーがいる状況では、自分がオーナーの案件を1番優先度高い案件として、チームに着手して欲しいので、優先度の再考が叶わなくなります。
アジャイル開発にはベロシティという考え方があり、決まった期間の中で安定して、決まった出来高を残していくことが良いとされていますが、こうなってしまうと、デスマーチに一直線となってしまいます。
最後に
ここまで現場でアジャイル開発をやってみた結果、得たノウハウについてアンチパターンとしてまとめました。
なにか参考になることがあれば、嬉しいと思います。
アジャイル開発の関連記事は、こちら
コメント
コメント一覧 （1件）
[…] 関連記事 【体験談】アジャイル開発のアンチパターン7選【脱失敗】 […]