アクセスありがとうございます!次は「とあるエンジニアのエソラゴト」で検索して頂けると嬉しいです!

【体験談】アジャイル開発のアンチパターン7選【脱失敗】

エソラ
エソラ

どうも、当ブログ(とあるエンジニアのエソラゴト)を運営している、エンジニアのエソラ(@ya6madev)です。
普段はSIer企業でDXとかAI開発をしながら、自社サービスの開発をしています。

アジャイル開発におけるアンチパターンの必要性

エソラ
エソラ

「アジャイル開発を採用したい」と考えている人が年々多くなっているみたいです。

しかしながら、アジャイル開発を採用しているプロジェクトは未だに少ないです。

そのため、アジャイル開発のノウハウはウォーターフォールモデルと比べると非常に少ない印象です。

ノウハウが少ないため、最初に大きな失敗をしてしまう可能性は結構高いような気がしています。

確実に成功する方法を見つけることは難しいです。

エソラ
エソラ

しかし、確実に失敗する方法を見つけることは経験を積めばある程度は見えるようになるので、失敗しないために確実に失敗する方法を避けることが大切です。

そのため、アンチパターンというものが存在します。

エソラ
エソラ

私は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番優先度高い案件として、チームに着手して欲しいので、優先度の再考が叶わなくなります。

アジャイル開発にはベロシティという考え方があり、決まった期間の中で安定して、決まった出来高を残していくことが良いとされていますが、こうなってしまうと、デスマーチに一直線となってしまいます。

最後に

ここまで現場でアジャイル開発をやってみた結果、得たノウハウについてアンチパターンとしてまとめました。

なにか参考になることがあれば、嬉しいと思います。

ここまでお読み頂き、ありがとうございました。
もし、「面白かった」、「参考になった」という方がいましたら、以下のソーシャルボタンからシェア頂けると泣いて喜びます!!
エソラ
エソラ
またブログランキングにも参加しています。 よろしければ、ポチッとお願いしまーす!
それでは、良いエンジニアライフをお過ごし下さい!
最新情報をチェックしよう!