インドカレーファンクラブ

パソコン、カメラ

『カイゼン・ジャーニー』感想

kaizenjourney.jp

公式サイトを見ると登場人物が絵になっててカワイイ!

会社で借りて読んだのでその感想というか、気に入ったとこのまとめ

気に入ったとこ

チームのWorking Agreementを決める

Working Agreementというのはチームの価値観・行動規範という感じのもの
取り決めとかルールって言ったほうがわかりやすい

僕はこの考え方が好き。人間はルールで縛ったほうがいい
でもルールを増やしすぎるとそれが軽い内容でも嫌がられるので難しい

試しにググったら良い取り組みをしている例があった

blog.engineer.adways.net

許可を求めるな謝罪せよ

何かの取り組みを始める時の話として、失敗を恐れず小さなところからやれ!という話が気に入った

「許可を求めるな謝罪せよ(It is easier to ask forgiveness than permission.)」という言葉を胸に。まずは"小さく試みる"ことだ。

いざ新しいことを始めるにあたっては、小さく試みることからスタートすることが大切です。大がかりに始めてしまうと、うまくいかなかったときに失敗の影響が大きくなってしまいます。

僕のチームでは最初から完璧を求めすぎるので、こういうことを大事にするべきだ(後述)

なぜチームで振り返りをするのか

僕はそもそもスクラム開発のチームでの振り返り(レトロスペクティブ)に懐疑的で、
「反省・改善ができる人間は一人でするし必要に応じてチームに展開もできるし、何故わざわざ全員でやるのか?」とか思っていた
(まあ、今でもまだそう思っている節がある)

というところでこの話は多少いい薬になった

そうか、他の人に気づかせてもらうんだ。自分で気づけないのはどうしようもない。だから、他の人に気づかせてもらう仕組みにしないといけないんだ。 自分の経験や思考だけだと、自分自身が限界になる。でも、他人の経験や思考を活かす仕組みにすれば、自分の限界は越えられる。

こう考えるとチームの振り返りは他人の動きに対してもっとバシバシ意見が出るような形である方が有意義 エンジニアはキツいこと言いがちなので難しいけど

失敗を積み重ねる

頻繁に変わる時代のニーズや市場の変化など、不確定要素が多々ある今日のソフトウェア開発では、プロダクトやプロセスをチームでふりかえりながら、 継続的にカイゼンていくことが、より良い選択といえる。その際、Fail Fast(早く失敗する)の精神が、漸進的に開発していくことの後押しになる。

僕のチームではチームとしての取り組み・チャレンジを決める(やるんじゃなくて決めるだけ)にも最初から完璧を求めすぎるきらいがある 振り返りの時間がが最たる例でそこで異様に討論して時間をかけすぎだ。というのが僕の意見 ※僕は完璧を求めすぎないという説もある

コードとしてのプロジェクトの根幹の設計とか、そういうとこは徹底的に最初から練るべきだけど そうじゃないところはさっさと試行してダメだったら変える、くらいの方が気が楽だと思う

何のためにアジャイルでやってるの?ウォーターフォールでやりたいの?とかたまに思う

越境する開発チーム

開発チームもプロダクトオーナーも互いの役割を学んでいこうね~、という話

役割を学ぶというと、ハイ学んだ終わり~って感じになりそうだけど、そういうことじゃなくて、
そもそもエンジニア以外にはわかりやすい言葉使うとか、そういう心掛けをこう...と僕も思う

スクラムマスターは役割

スクラムマスターは、役職でも専任でもなく、単なる役割ということを忘れてはならない。

内容はググれば出てくるだろうからいいか

アジャイルな見積もり、アジャイルな計画づくり

初期フェーズで長い期間をかけて、使えない緻密な計画を作成するよりも、現場で活用できる使える計画づくりをし続けることが重要なんです。

初期のリリース計画は、作成したら完成ではないのです。スプリントごとに毎回リリース計画を修正するといっても過言ではありません。むしろ積極的に変更するためにつくっていくのです。

僕のチームではプロダクトオーナーから「いつリリースできるんですか!」と詰められることがあるんだけど、
そもそも当初スケジュール立てた後、ろくに修正してなかった(そりゃわからんわ)

でも修正するのめんどくさいんだよね

SL理論

ググれば出てくる

単純に知らなかったのでホ~と思った

leadershipinsight.jp

全体的な感想

本自体が物語になっててわかりやすい

カイゼン的な行為を取り組むスコープが個人から始まってチーム内、チーム外へ広げていくような流れで、アジャイルだのスクラム的な文化はそのためにある、という話がわかりやすい

偉い人の鶴の一声でいきなり「スクラム開発をするぞ~!」といって始まるようなチームのメンバーにとってはいい本だと思う
何を思ってスクラム開発を始めたかったのかが汲める

もっとも碌でもないことをいうと、「スクラム開発」という「よくわからんけど進んでるIT企業で流行ってるやつ」をチームに採り入れた結果開発効率が上がった!みたいな話が成立すると偉い人の評価が上がるんだろうな、とも
※マネジメントする職分にある人の目標にはチームの育成とかそういうのがある筈なので