1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

はじめてのアドベントカレンダーAdvent Calendar 2023

Day 6

実際にアジャイルをやってみて感じたこと

Last updated at Posted at 2023-12-06

元々ウォーターフォール開発をしていて
今アジャイル開発(スクラム開発)を3年ほどしています。


今では、「これからもアジャイル開発をやっていきたいな」
と思うくらい魅力を感じています。
(まだ序ノ口の魅力しか感じられてないかもですが)

はじめに

初めの1年弱くらいは

手順は分かった。
目的や意図もなんとなく分かった。
…けどなんか上手くいっている感じがしない

みたいな感じでした。

ですが色々繰り返すうちに、現在、少しは
アジャイル的な思考回路になってきた気がします。

自分の考えを整理するためにも
備忘メモを残したいと思います。

前置きですが、私はウォーターフォールを否定するつもりはありません。
「ウォーターフォールと比較してより良い」といった表現に
なってしまっている箇所があるかと思いますが
アジャイル開発の良さを書きたいだけなのです。

短期間で繰り返しリリースを行う開発

出典:1

両者の比較といえばこういった図です。

  • ウォーターフォール
    • 要望のシステムに対して、各工程を順に実施して最後に一度だけリリースする
  • アジャイル
    • 要望のシステムに向かって、各工程を順/並行に実施して、動かせるシステムを何度もリリースする

この

要望のシステムに「向かって」、
各工程を順または「並行」に実施して、
「動かせる」システムを「何度も」リリースする

という進め方による、具体的な違いはどう出てくるのか?
私が実際に経験して感じたものの一つに

成果物・計画の作り方が全く違う

があります。

今回は一旦はじめのメモとして
ある絵を見ながら、上記について感じたことを書いていきます。

出典:2


「ある地点からある地点までより速く移動できるように」という顧客要望から 移動可能なものを常に作っているというものです。

徒歩よりは早く移動できそうなスケボー、スケボーより方向転換しやすそうなキックボード…という形かと思います。

この図を見ると
そうそう、アジャイルは下の図のようにやってくんだよな〜と思うのですが
私は、気付かぬうちに上の図のように進めてしまっていることがあります。


それは個人的には

  • とりあえず常に顧客が使えるように作る
  • 発想の転換

の不足が一因としてあるなのかなぁと思いました。

とりあえず常に顧客が使えるように作る

アジャイル開発のよくある誤解で

ウォータフォールよりも早く手戻りなくリリースできる

というものがあるかと思います。

「最短経路で」や「必要になるもののみ作るから」みたいなことを
指しているのではと思いますが、この考え方で臨むと
上の図のようにいきがちなのかなぁと思いました。


一見上の図のように各パーツを作っていく方が
作った全てのものが無駄にならない
(4の段階で全て使用されている状態)し、
着実に最短経路で完成形に向かっているような気がしてしまうからなのかなと…。


でも、そうすると絶対に「とりあえず常に顧客が使える」形で作れない気がします。
上の図みたいに「あと、これとこれのパーツが揃えばいけるんです…!」という感じでズルズルとのびます。


あと実際の現場は、完成形が本当に「車」なのかも
実はあやしい形で進んでいくのではと思います。

新しく作る機能だと、0の状態から完成形を明確にイメージするのは
そもそもとても難しいことのはずです。


だからこそ、上記絵での顧客の要望は「速く移動できるようにしたい」なので

「もちろん今後どんどん改良を重ねていく予定ですが
一旦徒歩よりは速く移動できそうなスケボーを作りました」

という形で
常に顧客が使えるものを作成し・使ってもらって・FBをもらう…を繰り返していくように進めていく必要があるんだと思います。


発想の転換

結構大事なのではと思っています。


「この機能を一旦こういう風にすれば、すぐ出来るし一旦使える状態にはなるか」とか
「この機能は必須だと思っていたけど、要望的にはこういう風にすれば、一旦無くてもいけるんでは?」
という感じで、言葉にするとそうでもな感じなんですが

システム開発に落とし込むと、もはや「発見」に近い感覚があります。

でも前述の下の図のように進める時に
効率よく確実に進めるには、必須なのではと思っています。


この発見を、少しでも早く確実にできるようにするために
私が意識しているのは、以下です。

  • 顧客が欲しいものでなく、顧客がどういうことが出来るようになりたいのか
  • 機能もっと削れるはず
  • 開発コストもっと削れるはず
  • 少しだけ「いや流石にそれは…」みたいなことも持ち出してみる

「欲しい」をイメージするとあれもこれもってなりがちですが

「最低限どういうことができないと操作がままらないか」や
「今よりマシにするには最低限何がいるか」

という感じで考えながら
チームメンバーとあれこれうんうん話していると
発見出来ているような気がします。

(今も絶賛試行錯誤中です)

最後に

言語化が難しい。
語弊のある・誤解を招くような書き方になっているかもしれないです。

続きはまた別途書きたいです🏃‍♀️

  1. https://seleck.cc/agile

  2. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

1
0
0

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
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?