今年の4月末に1年半勤めていたプロジェクトから退き、新たなプロジェクトを行うようになりました。
今までの経験を噛みしめるて、これから経験するHARD THINGS的な参考になると思ってカイゼン・ジャーニーを読んでみました。
ソフトウェア開発者でチームとして働いていると、複雑な悩みを抱えると思います。
時には人間関係であったり、プロセスだったり、自分またはチームのスキル不足だったりと様々です。
今の担当しているプロジェクトのプロセスや、チームビルディングで悩んでいるなら、
一定の指針を示してくれる本書は参考になります。
目次
どんな本か
本書では、人間関係やプロセスといった点にフォーカスしています。
実際にありそうな（あった）困難なユースケースでどうしたら改善されるか？
という具体的な改善案がフレームワークや手法で提示されています。
初見のフレームワークであれば知識の引き出しになりますし、既に知っていても再確認できます。
めちゃくちゃ情報量が多いので、一気読みすると疲れます。
参考：実際に登場するフレームワークたち（カオスマップ）
また、特徴的なのは構成で、各章が物語ベース＋解説という具合で構成されています。
登場人物のキャラがそれぞれ個性的で、物語ベースは比較的サクサク読み進められます。
使い方としては、クイックリファレンスのような使い方をすべき本だと思います。
かなりたくさんのフレームワークや手法が出てくるので、慣れるまでは時間がかかります。
また、身に着けるにはある程度実践が必要です。
しかし、いざ実践する際にはそのフレームワークで気を付けるべきポイントを忘れがちです。
その時は物語を飛ばして解説だけ読むことによって反復が可能で、時間コスト的に有利です。
実際にKPTや狩野モデルを使用する際には、本書の解説と検索の内容を踏まえて実践できました。
何も考えずに図るより、フレームワークで定量化されるので気に入ってます。
寸評
終了日 ：2018/04/23
選択した行動 ：kindleで通勤中に読書
誰とやったのか：1人で
得られた快楽 ：10点 今まで経験した事のある事象で、同じ悩みが具体的に解決されてスッキリ
感じたやりがい：10点 今後の活動として、こういった引き出しが増えたのは有意義だと思う。
やる前の期待値：5点 話題の本なのは知っていたが、人気の本。くらいにしか期待してなかった。
結果
今まで感じていたモヤモヤした感覚は吹き飛び、これからどうすべきなのかのきっかけが得られました。
内容について
読み切る目安時間
7時間～10時間くらい。
物語だけであれば、2～3時間程度で終わると思います。
ただ、解説部で分からない単語が山ほど出てくるので、調べながらだと時間がかかります。
2週目以降は登場人物が何をしたか頭に入っているので、1時間～2時間程度で走破できると思います。
各章の内容
登場したフレームワークや手法はカオスマップに記載してあります。
それらはカオスマップを参照する方が効率的なので、割愛します。
参考：実際に登場するフレームワークたち（カオスマップ）
全体のあらすじ
物語の内容を簡単にまとめると、こんなあらすじです。
自分自身との葛藤、チームメンバーとの葛藤、外部との葛藤。といった具合に
現実のあるあるがてんこもりです。
3部構成になっていて、物語が進むにつれて実践規模がどんどん大きくなります。
1部では「ひとり」
2部では「チーム」
3部では「越境（外部）」
特に気に入った点
2部の11話あたりから、現実でも体験したあるあるが頻発して凄く気に入ってます。
ゴールデンサークルの問いは本当に大事だし、プロジェクト以外でも色々適応できて無駄がない。
なぜ、このプロジェクトを始めるのか。なぜ、このプロダクトづくりを行うのか。
もし、この問いに答えられる人がいなかったら。まだ、始める準備が整っていないようです。（ 市谷 聡 啓）
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで (Kindle の位置No.1536-1538). 株式会社翔泳社. Kindle 版.
この、「始める準備が整っていない」状態で開発して疲弊したことが何度もありました。
結果的に開発は完遂したものの、なんとも言えないモヤモヤを抱えた状態となってしまいました。
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで (Kindle の位置No.1528). 株式会社翔泳社. Kindle 版.
本書を振り返って、過去の自分のアプローチの反省
ゴールデンサークル知る前は、失敗が多かったように思います。
例えば、ソフトウェア開発ではこんなことがありました。
実装が「暫定的対処」でしかない時に起きた、疲弊感。
とある機能追加を行って、仕様漏れで修正が必要な場合に発生しました。
仕様漏れの時点で既にwhyが詰めれていない感はありますが、実際の作業として下記の問題が起こります。
- 開発するまでの準備と調整が成果に見合わず、長い
- そもそも論として、不要なコードを書くので技術的負債である。
- 「暫定的対処」のはずが、「恒久対処」がいつまでも実装されずに「恒久対処と入れ替わる」
といった開発をしなければならない（What）、実装箇所は具体的に分かっている（How)けど、なんでやるの？（Why）
Whyまで来ると、とたんに主張が弱くなりました。
理想論的には、機能追加時点で完遂していることが望ましいからである。
とすると、「じゃあ暫定対処やる価値なくないか？」「恒久対処やるように調整したほうがよくないか？」
という問いを「作業中ずーーーっと」抱えることになります。
当時はチーム単位でこの負の感情を抱いて開発してました。
認識というか、意識の方向もそれぞれのバラバラだったのでかなりギスギスした雰囲気だったのを覚えています。
おまけに、こういうタスクが発生すると別のタスクも同じような傾向に巻き込まれます。
この状況下での疲弊感、徒労感は筆舌しがたいです。
できれば二度と経験しないように、自分から修正していきたいです。
じゃあ具体的にどう修正すんの？
っていうのは、本書でもあるようにインセプションデッキとか使えばいいのかなって思ってます。
ただし、それぞれのフレームワークは銀の弾丸ではないです。
ケースに合わせて活用する事が大事です。
その他にも、こんなことで失敗しました。
リファクタリングしようの会
既存コードのメンテコストが非常に高いので、リファクタリングしよう（What)とプロジェクトに申し出た事がありました。
具体的には、TDDでテストコードを綺麗にして（How）、8,000行とかある巨大クラスを分割(How)したりしようと。
結果は「プロジェクトとして承認されません」という現場リーダーの一声で終了しました。
これは、必要性を認識していないリーダーが悪いというわけではありません。
手法先行で、「良い行いをやればプロダクトも良くなる。」という幻想に駆られていただけです。
当時、自宅でのリファクタリングにハマっていたので、いわゆる「試したい病」だったのも認めます。
やはりWhyが無いまたは、ニーズに合っていないと説得力も弱いですし、納得してもらえません。
リファクタリングはチーム単位でも納得が必要な行為だと思ってるので、完全に一人で先行してしまった感があります。
まとめ
本書の内容を簡単にまとめると以下のようになります。
人間関係やプロセスを解決するフレームワークや手法がたくさん提示されている。
クイックリファレンスのような使い方で、解説を読むことによって反復が可能
自分自身との葛藤、チームメンバーとの葛藤、外部との葛藤。といった具合に現実のあるあるがてんこもり。
今、開発現場でモヤモヤしている開発者には目から鱗の情報が転がっている可能性が高いです。
カオスマップ
雁行陣開発のイベントレポートも併せてどうぞ。
