23
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

先日、とあるITコンサルタントの人が、こんなことを言っていた

「今の時代は、アジャイル開発が主流です。ウォーターフォールなんて時代遅れですよ。」

本当に、そうなのだろうか?

今まで様々なプロジェクトを見てきたが、アジャイル開発ほど、抽象的で、曖昧で、ファジーな開発手法を見たことがない。むしろ、ウォーターフォール開発のような決まりきったルールのない開発手法を「アジャイル開発」と呼んでいるような気がする。

一方で、アジャイル開発を採用する流れを確かに感じている。特に、スタートアップやベンチャー系の新規プロダクトは、アジャイル開発を採用することが多いだろう。しかし、「そうだ、京都に行こう!」というノリでアジャイル開発がうまくいっている現場を見たことがない。

私が、これまで見てきた開発現場(自分が参画したものもあれば、参画してないものも含む)のアジャイル開発は、悪い意味で曖昧で、悪い意味でいい加減、なカオスな現場が一定数あった。

ということで、この記事でアジャイルがカオス化する理由を書き連ねようと思う。この記事を読んで頂き、何か当てはまることがある方は、是非とも改善してみてほしい。

理由①「基礎を知らない行き過ぎた自由」

アジャイルのことを「自由に開発できるやつ」と捉えている人が多いだろう。間違いだ。何事もそうだろうが、「基礎」は大切である。アジャイル開発にも一定のセオリーがある。そして、このセオリーを勉強していない人が多すぎる。

「アジャイル開発=スクラム開発」と誤解している人すら散見する。私は、アジャイル開発の中に、スクラム開発・XP(エクストリームプログラミング)・FDD(機能駆動型開発)のような各種開発手法があるという認識である。と言う風な基礎を知らない。

スクラム開発を例に挙げても、たくさ〜んの単語を勉強する必要がある。

  • プロダクトバックログアイテム
  • スプリントバックログアイテム
  • スクラムマスター
  • プロダクトオーナー
  • スプリント
  • プロダクトバックログリファインメント

基礎あっての応用であり、なんとなくバックログの概念だけでどうにかしようとしていると、気づくとカオスになってしまうのだろう。一方で、「アジャイル開発は、自分たちの好きなようにルールを作ってもいいんだ!」という主張自体は正しいとも思う。アジャイルソフトウェア開発宣言の中にも以下のような文言がある。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

つまり、自分たちの好きなように最適化することは間違っていない。とはいえ、ある程度のフレームワークの中で自己流を出さなければいけないのだろう。テニスのフォームを自己流ですると失敗するみたいなことに似ているような気がする。

まだアジャイルに慣れていない・アジャイルの基礎を知らない人が多いチームは、「アジャイル開発ってなんだっけ?」という時間を作ってみるのは、とても良いのではないかと思う。

理由②「アジャイルをただの開発理論として消化している」

何言ってんだって話だが、要は「アジャイル開発は、広義のマネジメント論・組織論でしょ?」と私は言いたい。タスク管理をいい感じにすればいい訳でもなく、スプリントを切っていい感じにMTGをこなしておけばいい訳ではない。

働く人は人間であり、完全合理主義ではない限定合理的感情人(参考)なのである。まさに、この部分を円滑に進めるのが、スクラムマスターのような立場であり、スクラムマスターのトレーニングを真剣に進めなければならない。

「心理的安全性」「ティール組織」「サーヴァントリーダーシップ」など色々な組織論を学習する必要があると考えている。ちなみに、こんな研修もある。(→先に言っておくが、回し者ではない。むしろ、アフィリエイトのリンクがあるならば欲しい笑)

Registered Scrum Master® Training(2dayのコース)

ということで、1エンジニアとして捉えるのではなく、組織全体をマネージするHRのような立場からチームを考えてみると良いでしょう!

理由③「POが、顧客の声を拾えていない」

棘ある言葉で申し訳ないが、たまに感じることがある。POがプロジェクトマネージャー(PjM)になっている現場をちらほらと見たことがある。個人的な感覚だが、POはプロダクトマネージャー(PdM)の要素の方が強いと思っている。

POが、なぜかタスク管理やピープルマネジメントのようなことをしていて、どこからともなく上がってきた追加機能を意味もなく作って、気づいたら「その機能、誰も使ってなくない?」みたいなことは、よくあると思う。結果として、疲弊するのは現場のエンジニアである。気付かぬ内に大量のタスクを抱え、気づけばタスクボードが大量のタスクで溢れている。

だからこそ、POはよりPdMの思想を強くもち、本当に必要な機能とは何か?どう実装するべきか?を考えた方がいいと思う。

まとめ

以上、「なぜ、アジャイル開発はカオス化してしまうのか?」という話でした。これだけ偉そうに書かせてもらったが、「じゃあ、お前できんのか?」と言われたら、「たぶん、、?」くらいの自信でしか返答できない(笑)

開発ってむずかし〜〜。たんたん。

宣伝

Organizationsやってます。

23
12
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?