はじめに
先日PHPカンファレンスに行き、その物販コーナーでふと目についた 「仕事の問題地図」（沢渡あまね） を購入しました。
最近ミニマリストとか断捨離の影響で本はkindle版を購入してiPhoneで読んでいたのですが、
これもなにかの縁かなと思い、久々に紙版を購入するに至りました。
読み進めていくうちに「あるあるー！」という共感と、
これってつまりスクラムの枠組みで解決できるよね？という気付きとでとってもテンションが上がったので（笑）、
いくつか抜粋して記録に残しておこうと思います。
進捗不明の原因は、「相手依存だから」
「進捗がわからない」「気づいたときにはすでに遅し。大遅延、大炎上」
こんな事態の原因が「相手依存であること」だそうです。
管理側の立場としては「信頼しているから聞く必要ない」、
メンバー側の立場としては「忙しいと思って伝えられなかった」など
思いやっているようで相手に依存した理由付けがされてしまいがちだなと思いました。
そんな進捗不明問題への対処法は、 「コミュニケーション計画」 と 「フォロー役を設けること」
人は忘れる生き物だから、
忘れてしまわない仕組み、忘れても大丈夫な仕組みを作ろうという話です。
なるほどなるほど…と読みながら、
「これってスクラムの枠組みで完全にカバーされている」ということ。
- 「コミュニケーション計画」＝「スクラムのイベント」
（スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ） - 「フォロー役」＝「スクラムマスター」
この本で挙げられているような「仕事で起こりがちな問題」をきちんとカバーしてくれるのが、
スクラムの枠組みなのかなと感じました。
一体感のない問題は、「目的の共有」「ゴールを見せる」「役割と期待を明確にする」
チームとして一体感がない！という問題。
これらは、「意識がバラバラ」「一部の人が突っ走る」「終わりが見えない」「低モチベーション」といったことが原因で生まれてきます。
たしかに一部の人がものすごい遅くまで残業したり熱くプロダクトの夢を語ったりすると冷ややかな気持ちになる自分がいますし、
終わりが見えないと「なんかもうほどほどでいいかな…」という気になったりもします。
そういった問題への対策が、 「目的の共有」「ゴールを見せる」「役割と期待を明確にする」 という3つ。
なんのために頑張るのか？それはいつまでなのか？相手にはどんなことを期待しているのか？
それらを明らかにすることで、一体感を醸成できるそうです。
これもやっぱりスクラムでカバーされています。
- 「目的の共有」＝「インセプションデッキ」
- 「ゴールを見せる」＝「インセプションデッキ」「スプリント」
（スプリントは「区切りがつく」という意味で挙げています） - 「役割と期待を明確にする」＝「スクラムのロール」
（プロダクトオーナー、スクラムマスター、開発チーム）
スクラム愛を見せたいというわけではないのですが、必然的にそんな感じになってきてしまっています（笑）
個人的に、ここで挙げられている3点は自分の部署に足りないなあと思っていて、
自分のチームはともかく、いかに周囲に伝播させていくべきかと悩んでいます…。
期限までに終わらないのは「柔軟性のなさ」や「過度な自責」などが原因
いつも「期限までに終わらない」問題。
これは「柔軟性のなさ」「計画・管理が甘い」「知識やスキルがない」「過度な自責で抱え込む」が原因です。
一度計画を立てたとしても、割り込みや想定外の事態は絶対発生します。絶対。
そういった事態への対処がうまくできないと最終的にスケジュールを守れず、遅延してしまいます。
そんな問題への対策が 「変更管理」 と 「インシデント管理」 。
この本、そもそも読者の対象はIT企業に勤める人だけではないので、
IT企業的には当たり前のこの2つができていなかったりするのでしょうね…。
ここでいうインシデント管理は、障害やバグではなく「割り込みの仕事」すべてを指します。
こちらに関してはスクラムと1対1で対応させられるわけではありませんが、
スクラムではスプリントごとにプランニングしスプリント内で変更を行わない、プランニングした以外のことをやらないという意味で、
「変更管理」や「インシデント管理」ができていると考えてもいいのではないかと思います。
抵抗勢力を動かすストーリーを作るポイント
こちらはスクラムとは関係ないのですが、個人的に覚えておきたいので記載しておきます。
あからさまな抵抗勢力がいなかったとしても、
誰かを説得したい、動かしたいと言う時に使えるのではないかと思います。
- その仕事を進める目的はなにか？
- 終わった後に、どんな世界が待っているのか？
- 誰にどんなメリットが待っているのか？（相手にメリットはあるのか？）
- やらないとどんなことが起こるのか？
- なぜ、いまそれをやるのか？
- なぜ、自分がそれをやるのか？
- なぜ、相手に協力してほしいのか？
- その相手に、どう振る舞ってほしいのか？
失敗は隠れたがる
「恥ずかしいから」「面倒だから」「評価されないから」…
そんな理由で失敗をそのままにしてしまっては、何も学べません。
何も学べないということは、人に、組織に、知識が増えないということ。
そんな残念な組織を回避する方法は、
「振り返りをする」「共有を促す制度を作る」「自ら失敗を人に語る」 の3つ。
次へ活かす方法を考えたり、そもそも失敗について語りやすい空気を作ることです。
私も自分のチームで本番障害（顧客影響の有無は関係ない）が発生した際に必ず「対策会議」を行うようにしていて、
反省ではなく次への対策を考えるこの会議は「振り返り」に当たるのではと考えています。
スクラムでも主に開発プロセスに対して「スプリントレトロスペクティブ」で振り返りを行うのが近しいと思います。
とにかく 「失敗を共有することは尊い」 のだと作者は言っています。
終わりに
全体的にものすごく頷きながら、PHPカンファレンスから帰る電車の中でほぼ読み終えてしまうほどのスピードで読み終えた本なのですが、
その中でも特に共感した箇所・実践したいと思ったポイントを今回記事にしてみました。
通して読んでみての雑な感想は、 「スクラムってうまいなあ」 （笑）
結局スクラムって開発のための枠組みを提供してくれるのですが、
その枠組みに当てはめていくだけで、仕事を進めていくうちに忘れてしまいがちなポイントを押さえてくれているのです。
その枠組みをきちんと適用できるかどうかはもちろんそのチーム、その人にかかっていますが、
これも過去の様々なプロジェクトでの失敗が知識となって作られた枠組みなのではないかと思うと、
問題を抱えたプロジェクトでは一度試みてみてもいいのでは？と感じました。
この本はイラストが多く、文章も堅苦しくなくて本の重量もそこまで重くはないので、
気になった方はぜひぜひ読んでカイゼン欲を高めてほしいなと思います。
カイゼン欲が高まった方、カイゼンに疲れてきてしまった方にはこちらもおすすめです。
1人から、チーム、組織を超えて様々なカイゼンを進めていく勇気あるストーリーが読めます。
（こちらも書きっぷりがライトな本なのでおすすめです）