ゆきばた

ゆきばたの果てしない戯言

踊る!アジャイルという怪物

 

アジャイルって何でしょうか

近年、アジャイルという怪物が猛威をふるっています

 

この記事は、アジャイル推進でもなく、否定でもありません

開発の現場で取り入れているアジャイルの本質って何だろう

という記事です

 

アジャイルしているか

 

賛成派の人もいれば、反対派の人も、

はたまた良く分からないけどなんとなく・・・

と意見は様々であると思います。

 

ただ、一番良くないのは、

アジャイルをしている俺たちイイ感じだぜという勘違い

これを伝えたいのです。

 

アジャイルしているという勘違い

 

・アジャイル開発をすれば効率良く開発が出来るはず

・アジャイルっていう進んでいる手法で開発をしている

・アジャイル開発している俺たちカッコいい

 

これらに1つでも当てはまるのなら、

いますぐアジャイル開発を辞めるべきだと思います。

辞めなくとも、1から本を読んだ方が良いのかもしれません。

 

f:id:yukibata:20160322112236j:plain

 

アジャイルという言葉に踊らされていないか

 

最近、アジャイル開発をしているチームが多数存在します。

そして、それらのチームの半数以上が、

アジャイル開発という言葉に踊らされているような気がするのです。

 

そもそもアジャイルとは「俊敏」や「素早い」という意味で、

開発現場のイメージでいうと

「小回りが利く」と表現した方がしっくりくるかもしれません。

 

そういった「小回りが利く」状況下に環境を置くことで、

リスクを最小化し、目的を達成する開発を実現するということなのです。

 

 f:id:yukibata:20160322112919j:plain

 

小回りが利くことがそんなに大事なのか

 

違いますよね。仕事として働いている以上、

ぼくらにとって一番大事なことは、

大抵の場合「利益を上げる」ということです。

 

会社は、勉強の場でもなく実験の場でもありません。

利益を上げることが、最重要課題なのです。

「アジャイル導入した!みんなの意識を変えた!

オレスゲー!評価して!」は論外。

 

利益を上げるために僕らは

・顧客の満足度を上げる

・品質の高いものを提供する

・素早い開発を実現する

・コンプライアンスを守る

などを根底に仕事を進めていく必要があるのです。

 

それにもかかわらず、これを無視したり、

あるいはいくつか都合のよい項目だけをピックアップしたりなど

自分たちがアジャイル開発をする理由を見つけて

「俺たちはアジャイルで開発を進めている!」

と錯覚しているチームやスクラムマスターがいるんですね。

 

なんてこったい・・・・

 

早い開発をするなんてのは単なるチェック項目

 

f:id:yukibata:20160322113241j:plain

 

 

先にも述べたような、やろうとしていることの根底が

どのように、売上げに結びついているか、

あるいは影響を及ぼしているかを、

必ずチーム全員が認識していなければなりません。

 

何のために品質を上げるのかが分かっていなければ

単にテストケース数が増えるだけで、

本当の意味で品質を上げることには繋がりません。

(分かっていても難しいと感じる方もいるかも・・・)

 

品質について言うと、高い品質を追求することは、

・保守運用コストの低下

・契約機会の損失防止

などに繋がるということになると思います。

 

それを意識しなければ、

単なる「品質を上げる」というチェック項目をこなし

なんとなくの満足感を得ているだけになってしまいます。

自己満足です。

 

「ここの処理、運用の面を考えてエラーの時にファイル出力しておくか」

などと、自分たちが目指す方向を意識することが重要です。

 

ちゃんと「高い品質⇒利益の増大」という矢印

チームが意識していることが大切なのです。

 

 まず考えなければならないこと

 

 仕事の本質は先にも述べた通り

利益を上げるということです。

 

どうすれば利益が上がるかという考えを持てば、

今より良いコトをしようという考えに自ずとなるはずです

 

そう、改善です。

改善をするためには、2つの道のりがあります

・良い部分を伸ばす方法

・悪い部分を直す方法

あたりまえですよね。

 

そして、大抵の場合、良い部分を伸ばすのは難しいので

悪い部分を直していこうという考えになります。

 

そこからスタートして、

開発の際に仕様変更による手戻りが多いという問題があるから、

それを防ぐために2週間スプリントをやろう

必ずスプリント期間でデモ会 or リリースをやろう

きっとこれで、「後から変更」は半減されるはず!

となるのならアジャイル正解です。

 

2週間に1度の時間的制約を作って

・小さな機能はそこでソースフィックス

・大きな機能はそこでデモ会

デモ会で仕様の認識差異がないかを重点的にチェックする!

という具合に決めていくのが本筋かなと思うのです。

 

もし、デモ会が不要だと感じたら、止めればよいのです。

不要なものを改善対象にして、無駄な改善を試みる人もいます

やめましょう・・・・

 

アジャイル導入って本当に良いのか

 

これはもう、そのプロジェクトの内容によります。

アジャイルはあくまで方法です。

 

アジャイルが出来ることをゴールにしていませんか

アジャイルを導入して意味ありましたか

 

おそらく今までチームの開発スタイルに

アジャイルのような手法というのが

存在していなかったのではないでしょうか

 

自分たちのやり方は何だと聞かれたときに

「無いような・・・」と答えるしかなく、

なんとなく 設計 ⇒ 開発 ⇒ テスト とった

フワフワしたやり方をしてきたからなのではないでしょうか。

 

そして初めて、

やり方として型にハマった方法が見つかったという謎の達成感

からアジャイルが成功したと錯覚していませんか。

 

開発の本質

 

普通に考えてみましょう

 

利益を上げることが仕事の目的です。

利益を上げるためには、早く製品を作ったり

高い品質を維持したり、顧客を満足させる必要があります。

 

そのためには、改善をしなきゃいけません。

(改善にゴールはありません。

時代は変化するので理想も変わるはずです。)

 

そして、改善をするためにいままでのやり方に無駄が無いか

これをチームで振り返る必要があります。

 

・良かったことを明確にする

・良くなかったことを明確にする

・改善案を話し合う

・時代の変化を考え、従来のやり方を見直す

などなど、たくさんの改善にトライします。

 

ゴールを明確にして、

利益を上げるために達成すべきことに取り組む必要があります。

 

ここで出てくる一つの考え方がアジャイルなのです。

 

アジャイルの本を読むと

色々なプロジェクトマネジメントのやり方があります。

 

アジャイルを実現するために、それらに取り組むのではなく

それらの中で、自分たちに必要な方法は何かを考えるべきです。

 

決してスプリントで開発を回すことが

アジャイルの本質ではないです。

 

f:id:yukibata:20160322113518j:plain

 

アジャイルを見直す

 

もし既にアジャイル開発しているというのなら

もう一度考えてみてください

 

不必要な方法を取り入れていませんか

・見える化が達成したけど、自己満足になっていませんか

・振り返りに時間かけすぎていませんか

・スプリントリリースで逆に生産性落ちていませんか

顧客はそれで満足していますか

・チームのメンバーはそれで納得していますか

 

そして何より、

アジャイルという怪物に踊らされていませんか?

 

f:id:yukibata:20160322113751p:plain

 

おわり

 

 

 [image from]
http://know01.com/dokusyo-kouka-2463
http://www.hexblot.com/blog/disabling-checkbox-fapi-without-javascript
http://www.behavioradvisor.com/GlasserMeeting.html
http://storys.jp/story/10139