見出し画像

「ここアジャ」自称最速レビュー

今日、沢渡あまねさんと新井剛さんの「ここはウォーターフォール市アジャイル町」がアマゾンから会社に届いた。ここのところ沢渡あまねさんの共著は乱発(?)されているので読むのは大変(笑)なのだが、今回は自分が実際に取り組んできたアジャイルについての本だ。とりあえず一回目を呼んだので(もう一回読んでちゃんとしたレビューは書きたい)自称ではあるが最速レビューを書いてみた。雑ではあるが、心に響いたところを書き留めてみました。著者本人もファンの方も怒らないでくださいね

1.舞台が運用の現場

これだけでも充分に嬉しい。世の中の情死す(情報システム部門の蔑称w)の場合はビジネス観点が入りやすい顧客へのプロダクトとかサービスみたいな感じにはなかなかならない。「アジャイル開発」というからシステム開発に適用させようとしても、開発プロジェクトにはいろいろな面倒くさい人、例えば昭和のSIプロジェクトで成功(今となってはコンプライアンス違反とかブラック職場)を経験したエライ人が関係しているので、なかなか適用しにくい。いろいろ失敗してきた自分としても情シスにとってのアジャイル初体験は運用の世界のほうがマッチしやすい。面倒くさい人とはいえ、だいたいは同じ情シスの人だし、自分たちのエリアから始めることがしやすい。しかも「今居る決まったチーム」でやるしかない。(変な増員欲望出ないし)これってアジャイルで一番大切な「タイムボックス」の原則に従いやすい。これがシステム開発であればエライ人がすぐ「外注に増員を打診しろ!!」的な話がすぐ出てしまう。リアルな話、情シスにおいてのアジャイルは運用とか保守とかの地味で目立たないところから入るほうが圧倒的リアルリアル!!「運用大好きあまねさん」だからというところもあるのだろうが、ここは本当に嬉しかった。

2.バックログとふりかえり

アジャイルと言えばスプリントとかイテレーションばかり注目を浴びているが、大事なのはバックログで優先順位を意識する事、ふりかえりを行う事。現場ではついつい「急ぐこと」ばかりになってしまい。本質的なカイゼンをする時間が確保できない。バックログを見える化することで「急ぎだけど実は重要ではない」ものをコントロールできる。特に部長が言った「僕がユーザー部門にきっぱり断れば・・・」はものすごく大事です。現場の心を一気につかむし、それで出来た時間を本質的な問題解決に使える。これはものすごく大事な事・・・何となく「急ぎ」に追われているのは精神的にも良くないですしね。そして「ふりかえり」・・・ダメならやめていい選択肢があることは本当に大事ですよね。そして振り返りの闇wにも触れているのもいいです。ふりかえりは「反省会」になったり「糾弾の場」になったり「愚痴合戦」になってしまうのはやってみた事がある人にはリアルな話です。そこに触れて対策も書いてくれているのはうれしいです。

3.おやつ神社

これ、取り上げてくれたのはマジでうれしいです。アジャイルを意識しなくてもこれは取り組んでほしいです。マネージャであるならばやろうと思えばポケットマネーからでも出来ます。本当に好きなプラクティス(?)。これはバリバリウォーターフォールの現場でもできます。この本ではあまり触れられていませんが「おやつ神社」にはコミュニケーションの活性化だけではなく別な効果もあります。コミュニケーションがとりやすくなる結果として無理に話しかけて質問する事が少なくなるからです。せっかく集中してやっているのに「あの~」と突然質問されては集中が途切れます。おやつ神社があることで質問してよいタイミングがわかるので質問するほう、質問されるほう両方にメリットがあります。普通の本ではオマケくらいにしか扱われないおやつ神社がそれなりのボリュームで紹介されたのはうれしい!!

4.外部の勉強会

変わるきっかけも、その後のチームへの定着化も「外部の勉強会への参加」でしたね。アジャイルって手法ではなくて文化の問題。形だけやっても文化が変わらないとうまくいきませんよね。しかも「心の支え」になるのも外部の勉強会(コミュニティ)。コミュニティは「自分が孤独ではないことを知る場所」であり「背中を押してくれる場所」だと思っています。「自分たちで変えて行こう」という文化は上位下達では絶対に生まれないですよね。そしてコミュニティの文化とカイゼンを共有して進めていく文化って同じですよね。よくあるストーリーで「偶然来たコンサル」が教えてくれる話がありますが、コミュニティがきっかけというの変化というのは「自分から何とかする」事ができるのでいいですよね。ここはもっと書きたいですが・・・終わらなくなりそうなので・・・

あと、大事だと思ったのは「勉強しておくこと」ですね。相手(課長)とかの悩みを聞いてから考え出すのではタイミングを失いますよね。Slackの事例とかをあらかじめ勉強していたから、課長の課題に対応できたんですよね。

5.衝突の話

一番よくないのは「何も波風を立てないようにすること」。対立は良くないですが最悪ではないと思います。対立から「共通の敵」を導き出して共闘していくのがいいですよね。これはチーム内でも大事で失敗することを恐れずに「やってしまう事」って大事ですよね。机上の空論には非常に時間がかかる。そんなことよりも始めてしまう事が大事ですよねー。そういった意味ではBacklogとかSlackみたいなクラウドサービスって、こういうのにとてもあってますよね。こういったことに取り組む真希乃さん、共感できます。

6.ウォーターフォールvsアジャイルの愚

これって本当に誤解されまくっていますよね。実践している人というか教えてくれる人たちはみんなそう言っていますが、世間一般はいまだに「ウォーターフォールvsアジャイル」よく「ウォーターフォールとアジャイルの使い分け」なんて言われていますが、そういった問題でもない。ウォーターフォールは手法で、アジャイルは思想。同じ次元ではないはずなんですけどね。チームとしてセイチョウしていくことがアジャイルの神髄なのであって手法じゃないですよね。だからウォーターフォールの手法の中でアジャイルを実践することもできるんじゃないですかねぇ。ウォーターフォールだって何もカイゼンしないわけではないですしね。

7.なんかまとめ

この本はプロダクト開発している人よりも情シスの人、そしてルーチンワークをしている運用部門の人(経理とか総務とか)の人に読んでもらいたいです。めったに出ない社内向けの業務におけるアジャイルの本です。アジャイルはシステム開発だけの話ではないです。どんな業務にも適用できる「思想」であり「考え方」です。もうすでにベストセラーらしいですが、アジャイルなんて自分たちの会社には関係ないと思っている情シスの人だけでなく、もっとたくさんの人に読んでもらいたいです。

最後に・・・・ここでもダムネタwww

この記事が気に入ったらサポートをしてみませんか?