@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

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

勉強会でよく発表しているのをお見かけする2人が本を書いたと知ったので買ってみた。

開発の現場をカイゼンしていくための手法、心構えが小説仕立ての3部構成で書いてある。

1部 : 一人から始める
2部 : チームで強くなる
3部 : みんなを巻き込む

本書の主人公は、社会人3年目でコードは書けるけどチーム開発はうまく出来たことがない転職を考えている若者。
この若者が1人での活動からチームでの開発へ越境し、会社内部のチームメンバーからプロダクトに関わる人達を巻き込んでの開発へと越境していく姿が書かれている。

自分の立場で考える

自分はもうすぐ8年目を終えそうな立場だが、この主人公みたいに1人でやらなければいけないタイミングは全くなかった。6人くらいまでのチームで開発をしてきただけ。ただし、同じ時期に1つのチームだけではなく複数のチームに所属していたことはあった。その時には1部にあるように1人でタスクを毎朝確認し、振り返りもしていた。 その後チーム開発を6年ほどやっているがチームメンバーとのやり取りで困った経験はないなと思う。

勉強会に行ってすごい人に会ってやる気が出るのはすごい共感した。勉強会に行って自分の知らない環境や知識を学ぶのはすごく大事なことだと思う。(僕は勉強会に行って著者のお二人の話を聞くたびに刺激を受けてます

チームでの開発

本書ではチームでの開発手法をリーダーがスクラムでやると決め、外部からスクラムマスターを雇いチーム開発をすすめていくことになっていた。

色々起きる問題をチームみんなで解決していくための手法や心構えを

実際に起きるであろう問題→解決へ向かうための方法→解決策の説明

の順番で書いてある。

自分が悩んだ時に見直せばそこに解決策が書いてあるはずだ。
自分はスクラムを学んだことがないのでやるべきことや困った時の解決手法が学べてとても役に立った。

読んでいて思ったのは、チームとして活動するなら開発を始める前にいろいろやっておく方が良いのではと思う。意思疎通がうまく取れない人とチームを組んでもなにもうまくできるとは思えない。逆に意思疎通ができるチームだったらどんな開発手法でもうまくいくのではないかと思う。

実際には、本書でチームが揉めた時に行っていることをチーム結成時に済ませ、チームとして活動できるようになってから全てを始めるのが良いのではと思う。
※自分は急に大半以上チームメンバーが変わる経験をしていないので勝手を言ってます。

チーム外も巻き込む

複数チームでの開発の仕方、スコープの決め方や変更の仕方が分かりやすく書かれていた。

  • 本当にこの変更は必要なのか?
  • なんでこの変更は必要なのか?
  • 視座を変えて問題を捉え直す

これらは、本書の中ではプロダクトの変更が外部から来た際に行っていたがチームメンバーで定期的に行うべきものだと思った。

今の自分は、チームで必要だと思ったのを作り続けているが、

本当に使われるものを作っているのか?
本当に使いたいと思われているものから作り始めているか?
今のプロダクトは動いているが変更をする必要がある箇所はないのか?

こういったことを今のメンバーと見直す会を頻繁に定期的に行っていこうと思った。

まとめ

本書ではスクラム開発を行うための手法、またスクラムでなくてもチーム開発をする時の心構えが小説仕立てで書いてあるので、技術書を読むのに疲れて読みきれない人でも読みやすいものだと思った。
チーム開発をやっている、これからやろうとして困っている人たちにオススメしていきたいと思った。

ただ、これから初めてみようという人に対しては書いてあるものが沢山あるので、必要になった際に必要となったものをやってみるのをオススメしてみたいなと思う。

追記

僕はこちらの資料を参考に新しいチームを作ろうと絶賛勉強中なので相談をさせてもらえる方や、僕と同じようにこれから始めようとしている人と話をしてみたい!