海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

なんでもアジャイルなのだ

空前のアジャイルブーム到来(主観)

ここ2、3年? アジャイルブームが来ている、気がする。

 

一方で、アジャイルっていう必要あるんかそれ?っていうモノも見かけるようになってきた。

 

アジャイルアジャイル、みたいな接尾辞がつくのは特にそんな感じのものが多い気がする。

 

 

アジャイルを名乗るな!とかいうわけではなくて、本質を見失うと空回りしかないからよくないんじゃないかなーと思う

 

第一、”それ” を広め ら れ る 側の立場からすると、謎の横文字と出羽守スタイルで殴りかかってくる敵と戦う構図になるので拒否反応しか出ないのではないかなあ。

 

アジャイルってなんだったっけ

ところで、そもそもアジャイルってなんだったっけ、に戻ってくる。

アジャイル開発ではなくてアジャイル

 

みんな大好きアジャイルマニフェストのとおり、価値宣言と原則があって、っていう。

 

アジャイルソフトウェア開発宣言

アジャイル宣言の背後にある原則

 

表現がシンプルすぎて誤解を生みまくる、というか都合の良い解釈をされやすいこれら。

よくわかんないからって調べても、まあまあ怪しい解釈サイトがいっぱい出てきて中々腹落ちしづらいこともあるし、そこでみんないろんな解釈をしてすれ違いが生まれるんだろうなあ(他人事)

 

背景や過程を知らないで文言だけ追っても本来の意図とは違うものを解釈するのは当然起こる。

tree-swing-s-hogh

ので、背景や過程を知っておくのも、アジャイルとは?ってのを理解する上では重要だと思う。

(ユーザーストーリーにおける、so that ~~~ の部分。)

一応、Agile Manifesto のページにはちょっとだけ History ページもあるけどなんでこれ翻訳されておらんのやろ。

agilemanifesto.org

 

読もうね。

 

計画駆動(≒現実軽視)やプロセス重視(≒人間軽視) からの脱却であって、見える化とかチームとか速くデリバリするとかはそのための手段ちゃうんかな

 

アジャイルで部署の枠を超えて新商品発売の開発期間をxx%削減!とか言われても、会社が小さかった頃はアジャイルなんて言わずにそうだったんじゃないの?アジャイルっていう必要あるの?とか思ってしまう(性格悪い)

 

営業部は昔から組織目標の売り上げの達成グラフみたいなのを出すことはずっとやってる。でもアジャイルとは言わないだろう。

営業の現場でも昔から使われている見える化という取り組み(パターン)をアジャイルでも使われている、ってだけで。

土木の現場では毎朝朝会をやっている。でもそれをアジャイルとは言わないだろう。

毎朝現実の進捗に基づいてその日の計画を立てる、予測を立てる、っていうのをアジャイル開発も同じようにやっているだけで。

 

逆にアジャイルは朝会をやります、というのを、脳死でマネしても多分意味はないしそれでアジャイルとか言われてもツライだけだと思う。現場が。

 

とはいえ、

アジャイルとかいうのがなんらかの改善を伴う活動だっていうのは間違いないが、

 

「レビューで手戻りが起きた!」

→ 『よし、改善だ!』

→ 『事前に仕様に間違いがないことを合意して押印してもらうぞ!これで改善できるぞ!アジャイルだ!』

 

ぐらいのことはきっと起きるし起きてる。ツライ。

 

(例えは極端だけど、予実がズレたから1ポイントを1人日にしましょう!みたいなチームは稀によく見る。スクラムマスタークビにしろ)

 

じゃあどうすんのさ

どういう観点で改善進めるのかが肝心な気はしている。

 

ディスカバリーサイクルとデリバリーサイクルの流れをよく見るのが一番効果が高くなる気はしている。

バリューチェーンのどこがボトルネックだったり、サイクルタイムを長くしているのかを調査する。

(やることや観点はパフォーマンスのチューニングと一緒だったりする)

 

視野を狭めると効果がないので注意が必要だったりするし、難しい。

 

開発チームの中でスクラムを回して楽しく開発してても作ったものが本番にデリバリーされてないならそこに目を向けないでスクラムスクラム言ってるのはなんの意味もない。というか浅い。

よっしゃ DevOps や!とか言いながら改善スコープを広げていくしかない。

実は開発サイクルじゃなくて PO が顧客と話してまたは調査して課題発見するまでがボトルネックだったり長くなってるならそっちに手をかけないと意味がない。

一生懸命アプリケーションのチューニングばっかりしてるけど DB のレスポンス遅いのは DBA の仕事だから僕知らない、みたいな。良くないしそっちがパフォーマンスにおいて支配的なら自分のスコープに拘る意味がない。

 

f:id:Bashiko:20200317211947p:image

 

 ------2020/3/17 追記-----------

この辺で雑に書いてたことは全部綺麗に Ryuzee さんのブログに書いてあったから各意味なかったのと思ってるしそっちを参考にした方が1億倍健全ですのでそっちを見てください。

不確実な環境の中で 変化にどう対応すべきか | Ryuzee.com

 ------追記終わり-----

 

アジャイルを広める

とかいう難儀な仕事に就くなら、社内の改善サイクル、改善軸の手助けから始めるのがよさそう。

脳死で大規模プロセスとか導入するのはラクだし成果も見せられるだろうけど結果には繋がらんので。

(さいきょうのサーバーを1台置いたんで、ここでみんなかいはつしてでぷろいしてさーびすしてください!なんて悲劇しか起こらんでしょ)

スケールさせるのはプロセスじゃなくて文化。間違えると人間軽視に走って自己否定になるし。(もちろんプロセスも大事だけど。)

 

----

 

結局『アジャイル』とかいう実体の伴わないラベルは忘れた方が良いのかもしれない。

(AI やりましょう!くらい胡散臭いと思っていい)

 

自分らが顧客に何を提供するかの観点で、じゃあ何の問題を解決しましょうか、の繰り返しの結果、多分アジャイルみたいな何かになっている、はず。たぶん。知らんけど。

一方で、アジャイルっていうのが、どんな課題にどんな解決策で上手いことやってるか、というのは、知っておくと効率が良いし車輪の再発明しなくて済む。かな、って程度で。