カンバンによるムダのカイゼンの事例　を聞いてきたよ

今日はGW前のスプリント振り返りもあってぐったりしながら、この勉強会に参加してきました。

デブサミ行きたかったなーと思ってたんですが、登壇者の高橋さんが関西で再演してくださるということでありがたやありがたや・・・。

今回は資料に加筆されていたようですが、諸事情でUPはまだとのことですのでデブサミの時のスライドをここに貼らせていただきます。

カンバンに関してはうすーい知識のみですがざっくりとは知っていまして。

仕事ではJIRAを使ってタスクのチケット管理をしています。

あまり詳しくは書けないのですが仕事で最近問題だなぁと思うことが多くて、今日のお話を聞いてヒットすることが多く色々と思うことがありました。

以下、高橋さんと中村さんのお話を聞いてざっくりと殴り書きです。

見える化をするから、ボトルネックが見つかってカイゼンしやすいってことなのかなぁ。

振り返りについては、アジェンダを決めて行なっているとのこと。

フリーにしちゃうとぼやけちゃうんですかね。そういやTryがそんなに出なくてふんわり終わっちゃうことあるなー。

アジェンダ決めちゃうと他に言いたいことがあった場合、言いづらいってことはありますかね・・・。

新規参入者へのカンバンやカイゼンについての説明はチームメンバーが自発的に行っているんだそうで、いいチームだなーと。皆、納得してやっているから説明できるんでしょうね。

カイゼンでやり方がコロコロ変わるとメンバーは戸惑わないのか？との問いには、基本的に振り返りでTryが出て、皆で決めたことを試してゆくので不満は出ないんだとか。

まぁ、つまりですよ。チームを管理する人が一人で頑張って決めたことをメンバーにやれ、っていうのは大体上手く行かないとのこと。

激しく同意します。

面白いところではDoneになったふせんはどうするの？って疑問。

ふせんは時間が経つと剥がれやすくなるので、捨てちゃうことが多いみたいですね。

残しておいて束になったのを見るのもモチベーション上がっていいかも、というお話も出てましたw

デジタル vs アナログについて。

導入時はアナログの方が手軽にはじめられていい、というお話が。

デジタルだとツールの仕様を理由に（というか言い訳？）管理できないものが出てきたり・・・

ただ、ツールは同じものを使い続けるとフォーマットが揃っているので過去のデータによる分析ができるメリットもあるのでは、というお話も出てました。

あとカンバンの奴隷にはなっちゃダメだ、とw

カンバンの管理に必死になるのは良くないですね。目的が違う。

高橋さんのお話でコードレビューによる手戻りの話がありまして、カイゼン策として「最初に設計して認識を合わせて合意をしておく」という下りが。

丁度気になっているところだったので質問して具体例について教えていただきました。

なるほどーと思いました。合意しておくと手戻りの時間も短くなりそうだし、特定の人の良くわからないこだわり等で振り回されてレビュー終わらない問題も解消されるかなと。

今日の結論。

チーム皆で手分け・協力して決定、調査、開発。

これがまるっと幸せ。

runaround’s diary