More Effective Agileを読んだ

More Effective Agile ~“ソフトウェアリーダー"になるための28の道標

More Effective Agileを読んだので、その感想を書いていきます。

読んだきっかけ

元々、発売前から存在は知っていたのですが、"ソフトウェアリーダーになるための28の道標"という副題が、自分自身にとってはあんまりピンとこなくて、手を出していませんでした。
対象読者の項目の冒頭に、Cレベルの責任者, バイスプレジデント, ディレクター, マネージャー...には是非読んで欲しいと記載があった点からも、自身の立場とはかけ離れた人が読む書籍だと感じていました。
ただ、先日のイベントできょんさんが2020年のアジャイル開発書籍の中で最もお勧めしていたので興味が出て、読んでみることにしました。(みんなでアジャイルとかClean Agileとか超良著だったので、それを超えるレベルとは一体...！？と興味が湧きました)

◆きょんさんがおすすめしていたイベント

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

Clean Agile 基本に立ち戻れ

全体を通しての感想

タイトルの通り、アジャイル開発を進めていく上で、何をなぜ大切にしなければいけないのか、が丁寧に解説されていました。
大切にしなければいけないことを無視した結果、どういう症状が顕在化するのかというのが具体的に記載されており、章末には簡単なエクササイズ(検査と適応)も用意されているので、実践的な内容に感じました。
また、本書の解説自体も十分丁寧ですが、参考文献も膨大な数が記載されていました。
なので、解説をもっと深堀したい場合は、記載されている参考文献を読むことで知識を深化させることができるのも良かったです。
アジャイル開発をしていて上手くいかないことが出てきて、何で上手くいっていないのか良く分からなくなった時は、本書にもう一度立ち返ってみたいと思います。

以下、本書の検査と適応のエクササイズを通して気が付いた自分のチームの問題とチームの良い点を、書ける範囲で箇条書きで幾つか記載していきます。(記載を省略しているものもありますが、本書を読んで21個の問題と22個の良い所が見つかりました！)

書籍を通して見えた自分のチームの問題点

• 作業の"質"の定義がないため、 作業の目的意識が薄くなりがち
• ミーティングのデザインができていないため、ミーティングのROIが低い。
• 感情が表に出るタイプ, 感情や声の大きさで議論を制するタイプが多い。そのため、意見が抑え込まれたり、頭が緊張状態, 混乱状態に陥り、メンバーの理解力や思考力が低下する場面がある*1
• テストの大部分を手動で実施する必要があるため、高頻度に検証することが難しい。フィードバックを得るまでに時間がかかる。
• DoRに開発者全員が理解していることを確認する条件が含まれていないため、開発に着手した後、チームメンバーそれぞれで違うイメージをPBIに対して抱くことがある(受け入れ条件やユーザーストーリーは必ず記載しているが、読み合わせをしていない。各自が読む形としている)
• 他人の作業を傍観し、作業者が失敗した後に「実は失敗しそうだと思っていた」「～したせいで失敗したので、～さん(作業者)は改善すべきだ」というような意見が良く出るため、責任を持った態度が取りにくい環境になっている(特に下の職位のメンバー)

書籍を通して見えた自分のチームの良い点

• ユーザーと直接話せる環境のため、 インパクトを実感しやすい。また、プロダクトに対してフィードバックを得やすい。
• クネビンフレームワークにおける"複雑"な環境であることをチーム全員が自覚しているため、事前に完璧なスケジュールを立てようとしたり、過剰な要件分析を実施しない。
• 仕事をチーム内で殆ど自己完結できる(外部チームに頼らないといけない技能や知識が殆どない)
• 技術的負債に敏感であり、リファクタリングを継続的に実施している。
• 技術的負債を全メンバーが返済できるように、毎週トレーニングを実施している。
• PBLの優先順位が価値分析の下、決定されている。
• チームがPBLの優先順位付けの判断を誤る要因の一つである、顧客からのプレッシャーや外部からの圧力がチーム内に流入していない。(顧客と会話する立場の人が吸収できている)

*1:自身の性格や、同期全員+若手の大部分が、チームから異動希望を出すor休職して異動することを経験している、自身のコンテキストから、気にし過ぎているだけかもしれない