もがき系プログラマの日常

もがき系エンジニアの勉強したこと、日常のこと、気になっている技術、備忘録などを紹介するブログです。

カイゼンジャーニーを読んだ

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

はじめに

こんばんは。連続です。

書こう書こうと思ってどんどん間が空いてしまったので、今日気合い入れて書きます。

書くまで寝ません。

中身

カイゼンジャーニーという本を読みました。

控えめに言っても最高でした。

内容がストーリー仕立てになっていたので、一回目は普通に小説を読むように読んでしまい、中身をきちんと腹に落とし込むためにもう一周読みました。

なんか、他の本みたいに気になるところだけを抜粋して紹介するっていう方法がいいかな?と思ったけど、それだけでは自分のなかでまとまりきらないので、ストーリーに沿って紹介したいと思います。

あまりに引用が過ぎたら、削除するかもしれません。

感想

第一章 一人から始める

概要

現状を変えたい良くしたいと思って、あれこれ提案しても周りの反応は今ひとつ。

そんな保守的なチームにも、変える時間を作れない炎上案件ばかりの会社にも嫌気がさして、転職しようと考えている主人公(江島)の話からスタートする。

とある社外イベントできいたセッションに感銘を受けて、発表者(石神)に話しかけるが、

「あなたは何をしている人なんですか?」

という一言に言葉がでず、その言葉の答えを探すために、行動を起こし始める。

最初は自分ひとりで、行動を起こす。

タスクマネジメント・タスクボード・朝会・ふりかえり。

はじめはうまくいっていたが、ひとりでの限界を知る。

そんなときにタイミングよく、ともに行動してくれる仲間(片瀬)が現れる。

ひとりからふたり。小さなチームができあがり、江島+片瀬の越境は加速していく。

感想

こういう状況って本当にあるあるだとおもう。

今の現場もまさにそう。

自分はある程度の数、現場を渡り歩いてきたから、もうこういう状況ってしょうがないって諦めるようになっている。

でも成長意欲が強い若い主人公には辛い現場だったと思う。

自分も20代かつ独身だったら、今の現場にはおそらくいないと思う。

社外イベントでの出会いがとても大事というのも、すごく共感できる。

今回のこの江島と石神の出会いのように、「人生が変わる出会い」というのものも普通にあるとおもうから。

それ以外にも業界トレンドを吸収することや、業界内での自分の位置の確認など、参加しないとわからないことが山のようにあるため、社外イベントへの参加はメリットしかないと思っている。

同じ場所にとどまって、毎日タスクをこなすだけの仕事ってなんだか味気ないし、自分の成長が見えにくい。

やっぱり新しいことにチャレンジすることが、成長の第一歩だと思う。

ただ、ここで重要なことが本では紹介されている。

外に出て知見を得ていくにあたって、覚えておかなければならない大事なことがある。外から得られた学びを、そのまま自分たちの現場や仕事で適用しようとしても、たいていうまくいかない。自分たちの「状況」に照らし合わせてみることが必要だ。

これも結構あるある。

「いいねこれ!取り入れてみようよ!」

っていうノリとテンションでやってみることってベンチャーの会社ではよく起こることだと思う。

↑のようなスピード感はとても自分好みだし、実際自分もこういうふうに提案したことがあった。

でも、絶対とは言わないけど、カチッとハマったことはあんまりなかった。

それはまさに「状況」が見えてなかったからだ。

ラクティスを紹介した会社(人物)の、実践した背景や制約などをきちんと理解せず、形だけを無理やり自分のチームに組み込もうとしていたからだ。

チームに組み込むということは、自分以外のメンバーも行うということ。

自分たちのチームにあうかどうかキチンと見極めて、実践しないといけない。

第一章で紹介されたTipsは、比較的有名なものだ。

だけど、一旦見返してみるととても良い気付きがあった。

1. タスクマネジメント

ざっくりいうと、ふられたタスクの目的を把握すること。

作業者的な意識の人や、新卒の子などは、ふられたタスクを一生懸命「終わらせる」ことを目的としているけど、それって本質を見誤っている。

本質は、よりよいサービスをユーザーに届けること。

なので、ふられたタスクの目的を理解することが重要。

本ではタスクマネジメントについて以下のように書かれている。

目的を明らかにしておくと、目的を達成するための段取りが不足していたり、遂行するためのスキルが足りていないことにも気づける。早めに気づけば打てる手もある。「うまくいかない要素」を早めに見つけることも、タスクマネジメントの大事な観点だ。

自分はこの他にも、以下のようなメリットがあると思う。

タスクをふる人も人間なので、時にはタスクの優先順位を間違えたり、「本質」と離れたタスクをふってしまうことがあるかもしれない。

タスクの目的を理解すれば、こちらから提案などができる。

「このタスクがこういう目的であれば、このアプローチがありますがどうでしょう?」

など、小さい会社であればあるほど、ひとりひとりの裁量権は大きいので、こういった提案も重要なものだと思う。

エンジニアのサービスの理解度も増すし、ひいてはよりよいサービスを作ることにつながるからだ。

ちなみに、今の現場ではgithub issueでタスクを管理しているが、カイゼンジャーニーを読んだ後、ISSUE_TEMPLATEに

「このissueの目的」

を記述するように変更を加えさせてもらった。

2. タスクボード

タスクの見える化

コレ大事だよね。人数増えてくると

「あいつ今何してるの?」

みたいなことが普通におきる。

やってることが見えなくて、何やってるかわかんないなら、見えるようにしてあげようってことだ。

ちなみに今の現場では、タスクボードはgithubのprojectsを使ってる。

f:id:kojirooooocks:20180602042216p:plain

こんな感じでステージごとに切り分けているので、チームメンバーにも好評。

他のチームメンバーも、それぞれprojectsがあり、このカタチがベースになっている。

3. 朝会

そのまま。

ただ、よくある朝会は、

「今日はコレやります」

みたいな、やることだけを淡々と述べていくものを想像していたが、本で紹介されている朝会は違った。

朝会では、昨日は何をやったのか?それを踏まえて今日は何をするのか?今日やることや計画を達成する上で困っていることはあるか?を整理する。整理した結果、もし計画とのズレが大きくなるようであれば、計画の立て直しを行う。

そうだよね。昨日なにやってて、今日はなにをやるっていうのを確認するのが正しい流れだと思う。

自分が今までいた現場でやっていた朝会って、今日コレやります。っていうタダの発表会みたいな感じだったので、正直、朝会の存在意義は自分の中で薄かったのだけど、これをみて大事だと再確認できた。

ただ、一点問題は自分がリモートで関わっているということ。

ここのベストプラクティスを知りたい。

常駐しろって答え以外で...

4. ふりかえり

これもそのまま。

作業のふりかえり。

ふりかえりのやり方で有名なのはKPTだ。

今の現場でも行っている。

  • Keep

    続けたいこと、やってみてよかったことをあげる

  • Probrem

    問題点、問題になる前の兆候や気付きなどもあげる

  • Try

    試したいことをあげる

勉強になったのは2回目のふりかえりについてだ。

2回目のふりかえりでは、前回のTryを見るところからスタートしよう。 Tryをやってみてどうだったのか?効果があって続けたほうが良さそうなら、Keepに移動させる。効果があるということは、Problemに変化が起きるということだ。問題の度合いが減じていたり、解消していたりするか、結果を捉えておこう。

前回のTryについては正直考えていなかった。

というより、Tryをやってみて、うまくいったらKeepにあがってくるでしょ?みたいな考えをしていたので、正直見逃していたものが多い。

このやり方を知ってから早速KPTにも取り入れてもらった。

ぶっちゃけ、今の現場にタスクボード・朝会・KPTを導入してもらったのは自分の発言からなのだが、それを「いいね!やってみようよ!」って即答してくれたデザイナーの@chups_cokeさんにはすごく感謝している。

現在は取捨選択しながら、今のチームにフィットするやりかたを一緒に探している。

こういうのも出会いだと思う。

自分の中での片瀬はまさに@chups_cokeさんだ。

第一章に関して、感じたところは以上だ。

物語的には、ひとりで行うことの限界を感じた江島に、片瀬という仲間ができて、二人で社内勉強会を開くという流れになっている。

ひとりで行っていたカイゼンが、仲間を巻き込み、大規模な社内勉強会を開くまでに成長する様は、正直感動モノだった。

第二章 チームで強くなる

概要

社内勉強会を開いてから1年が経ち、自信と経験がつき成長した、江島に、新たなプロジェクトへのアサインがきまる。

江島が尊敬する先輩(蔵屋敷)と行う新規プロジェクトは、社内プロジェクトで、江島がリーダーになり、チームを組んで開発を行っていくことになる。

個性の強いチームメンバー達と、見よう見まねで「スクラム開発」を行うが、スムーズに進まない。

そんななか、スクラムマスター(西方)がチームにアサインし、スクラム開発のイロハを教えてもらう。

時に遠回りかと思うような行動も、チームにとって、プロジェクトにとって、重要なことだということをチームメンバー・江島ともに理解し、文字通りスクラムを組んで開発を進めていく。

感想

正直この2章は、まだ理解しきれていない部分が多い。紹介されているTipsの数が多いからだ。

この章ではスクラム開発を前提に進められていく。

今の現場はスクラム開発を行っているわけではないし、自分自身でも経験がないので、1から勉強する必要があったのだが、自分の頭が悪いのかうまく理解できなかった。。。

なぜうまく理解できなかったかというと、

「既に運用フェーズに入っているようなプロジェクトでスクラム開発の動きを当てはめることが出来るのか」

というところだった。

これは今でもわかっていないので、誰か教えてほしい・・・

ただ、本で紹介されている、スクラム開発時に、起こる問題に対してのTipsは役に立つものばかりだった。

その中でも、個人的に、今すぐにでもチームに組み込めるなとおもった、ものを紹介したい。

1. Working Agreement

チームの中でのお約束みたいなこと。

このお約束は原則みんなが守ることになる。

スローガンのようなものは避けないといけない。

抽象的な言葉は、受け取り方が人によって違ってくるからだ。

  • チャットに30分以上応答できなくなるようなときは、事前に連絡する。
  • 週の残業が10時間を超えるような場合は、KPT時に必ず報告して、原因を話し合う。

など、明確なものをあげる。

更に重要だなと感じたのは以下だった。

こうしてチームの実際と合ったWorking Agreementは、新しいメンバーが参加する際にも、大いに役に立つ。チームが大事にしている価値観や行動規範を伝えやすくなるから、チームに溶け込む際の敷居を一気に下げられる。もっというと、中途採用面接などで、チームとの価値観が合うかどうかの判断にも使える。

たしかにそのとおりだ。

会社の雰囲気みたいなのは、大々的に紹介されているが、実際に入るチームの雰囲気は、入ってみないとわからない。

悲しいすれ違いをなくすためにも、今のチームメンバーの意識合わせのためにも、是非取り入れたいと思った。

2. ドラッカー風エクササイズ

チームメンバー同士の期待値の見える化ってイメージだと思う。

メンバーそれぞれが、

  • 何が得意なのか。

  • どうやってチームに貢献しようとしているのか。

  • 自分が大切に思う価値はなにか。

  • 他のチームメンバーは自分に何を期待していると思うか。

をあげていく。

否定をせず、ざっくばらんに、正直に書いてみる。

本では、プロダクトオーナーの土橋がwebアプリケーションの開発がほぼ初めてだということが、このドラッカー風エクササイズを行って気づいたことになっている。

ここまで衝撃的なことを発見できるかと言われると謎だが、3番目の「自分が大切に思う価値はなにか」という問いに対してのみんなの答えを聞いてみたいので、やってみたいと思った。

3. スキルマップ

簡単に言うと、プロジェクトで必要なスキルと、そのスキルを習熟度レベルをメンバー分つくって表にしてみるということだ。

このTipsですごくいいなと思ったのは、「習得希望」という項目を書ける点だった。

新卒メンバーは、勉強のために何でもやりますよ!っていう感じだと思うが、ある程度経験詰んだ人は、自分のroleモデルがなんとなく定まっていると思う。

そのうえで、どの分野を、今後伸ばすべきと思っているのかを見える化することが出来る。

たとえば、あまり興味が無いと思っているCSSとかをやらせても、仕事だからやるけれど本人も気乗りがしないし、スピードも遅いだろう。

それよりも、勉強中でもっと経験を積みたいと思っているpythonとかをやらせたほうが、意欲でるしもスピードも上がるはずだ。

ぜひやりたい。








これらが、第二章で知ったTipsで自分が実践したいと思ったものだ。

ただ、これらのほかにも良いものはいっぱいある。

とくに「むきなおり」は新規プロジェクトでは必須でやったほうがいいと感じた。

得てして長期プロジェクトでは、終着点が最初に考えていたところより、ぶれていくことがある。

それを軌道修正するためのTipsだ。

自分が新規開発にアサインされたときは、迷わずやりたいと思った。

第三章 みんなを巻き込む

概要

前回のプロジェクトをローンチまでもっていったことで、更に自信をつけた江島。

今度はクライアントがいる受注プロジェクトのリーダーを任されることになった。

プロジェクトのスタート序盤で、社内の別プロジェクトの影響で、チームメンバーの入れ替わりが発生し、社内リソースが足りず、フリーランスエンジニアに協力を求めることになる。

それ以外にもクライアントとの進捗確認やMTG、外部デザイン会社の人との打ち合わせなど、前回のプロジェクトでは発生しなかった事が次々と発生していく。

試行錯誤しながら、今まで行ってきたプラクティスを使い、プロジェクトを進めていく江島。

このプロジェクトの終わりに、彼が感じるものとは。

感想

3章は、社外の人を巻き込んでのカイゼンが主な話になる。

今の現場は、自社サービスの運用なので、現状関係があるわけではない。

しかし、3章で紹介されているTipsにもとてもよいものがあったので、紹介したいと思う。

1. プランニングポーカー

結構有名なので、わざわざやり方を紹介する必要もないと思う。

これは実は何回か、やりませんか?って提案したことがある。

見積もり工数をタスクごとに設定しているので、プランニングポーカーは相性が良いと感じたからだ。

ただ、実際にやるとなると、すべてのタスクでやるのか、それとも時間がかかりそうなタスクだけやるのかなどを決めたほうが良いと思う。

毎回やるの正直だるいしね。

でも、2〜3日かかりそうなタスクの場合、プランニングポーカーで他の人はどれくらいに終わると思っているのか、その理由は何かを聞けるのは、すごく重要だと思った。

それをきくことで、思わぬ解決策や、思わぬ障害に気づくことが出来るからだ。

もっかい提案してみようと思う。

2. CCPM(Critical Chain Project Management)

タスクの見積もりお願いします。

といわれて、3日で終わりそうだな〜と思っても、バッファをとって4日で設定した経験って絶対あると思う。

自分もしょっちゅうある。

ただそれって、全体的に見るとマイナスだよってこと。

本で紹介されているパーキンソンの法則がまさにそれだ。

仕事の量は完成のために与えられた時間を満たすまで膨張する、という法則です。大きく余裕を持って見積もったとしても、バッファというゆとりを追加したとしても、なくなっていきます。顧客側か開発側かにかかわらずです。一度期間が設定されてしまうと、その中で対処するように人間は考えてしまうわけですね。当初の計画時点でのバッファは、ただただ消費されていくだけなのです。

CCPMは、各タスクに対してはバッファを持たず、プロジェクト全体でバッファを持とうという考え。

プロジェクト全体のバッファはどれくらいかというと、プロジェクトに紐づくタスクの合計の見積もり工数の半分が妥当のようだ。

つまり以下のような感じ

  • 各タスクにバッファをもたせた場合

    • タスク1 = 工数: 5(実工数: 3, バッファ: 2)
    • タスク2 = 工数: 3(実工数: 2, バッファ: 1)
    • タスク3 = 工数: 2(実工数: 1, バッファ: 1)
    • タスク4 = 工数: 8(実工数: 5, バッファ: 3)
    • (3 + 2 + 1 + 5) + (2 + 1 + 1 + 3) = 18
  • プロジェクト全体にバッファをもたせる場合

    • タスク1 = 工数: 3(実工数: 3, バッファ: 0)
    • タスク2 = 工数: 2(実工数: 2, バッファ: 0)
    • タスク3 = 工数: 1(実工数: 1, バッファ: 0)
    • タスク4 = 工数: 5(実工数: 5, バッファ: 0)
    • (3 + 2 + 1 + 5) + ((3 + 2 + 1 + 5) / 2) = 16.5

全体で見ると工数が削減できるがわかる。

今関わっているのは運用フェーズのサービスなので、ここまでどでかい工数のタスクが来ることは稀だけど、来た際には実際にやってみたいと思う。

おわりに

自分の文章力が稚拙なので、キチンと良さを伝えられないのがとても悔しいです。。。

それに自分の認識が間違っているものも多々あると思います。。。

ただいいたいのは、すげー感動したということです。

冗談ではなく、涙がでそうなほどでした。

これをいうと嘘っぽくきこえてしまうんですが、本当なのでどうしてもいいたかったです。

現状の環境を変えたいけど、うまく変えられない、伝えられないという憤りを感じている人に是非読んでほしいです。

きっと、何かをつかめる「きっかけ」もしくは、何かを始めようと思う「熱」をもらえる本だと思います。

おしまい。