More Effective Agile読書会(17章)
イベントはこちら（More Effective Agile チラ見会）
17章 より効果的なアジャイル：組織文化
読書会の中で上がっていた話、気になった点を列挙していきます。
1.freeeのteyamaguさんが言っていた心理的安全性の話（大意）
「私はその点を知らない」と言った時に相手の心理的安全性に強いデバフがかかる
・「分かるようにしゃべってよ」
・「お前のいうことが理解できない」
というニュアンスで相手に解釈されることがある
その場合相手に強い威圧効果を与え、相手の発言がより不活発になる
という話をしていました
2.バディ単位でのレベル
DevOps 文化: Westrum の組織類型 を読んだ上で
たとえばチームが８名で４名が一番右側の「創造的な組織」よりの人間。
残りの４人が左や真ん中の不健全/官僚的な組織よりの人間だった場合
ただ単にチームの平均値を取ろうとすると真ん中あたりが平均値になります。
ところが創造的な組織よりの人間を、それ以外の人間とバディを組ませた上で「バディの平均値」を取るとより右の「創造的な組織」よりにできるのでは？と言う話が出ました。
3.計算づくの間違い
スクラムはクネビンフレームワークで言う複雑系のプロジェクトに強いです。
スクラムは最初に素早く間違いを繰り返すことを特に重視します。
間違いから学ぶことを重視するのではありません。
間違いを「早期に」「素早く」繰り返すことを重視するのです。
「スクラムはいくら間違いをしてもOK！学びがあればいいんだよー！」という話ではありません。
必ずプロジェクトの早い段階で、間違いを「早期に」「素早く」繰り返せる状態にしなければいけません。
そうでないとスクラム開発のプロジェクト進行のやり方として健全とは言い難いです。
4.それ、コード書く必要あった？
スクラム開発は未知の探索的要素が多い「複雑系」と呼ばれるプロジェクトに有効です。
ここでいう複雑系プロジェクトは「その道のプロを以てしてもどうやるべきか、やってみないと分からない」プロジェクトのことであり
対して比較対象となる煩雑系プロジェクトは「その道のプロならどうすべきかは分かる」プロジェクトのことです。
よく見かけるのが、「俺にはどうやるべきか分からない！複雑系に違いない！とりあえずスクラムでやってみよう！」みたいなプロジェクトです。
ここでいう俺にはどうやるべきか分からないは本当に複雑系を意味したのでしょうか？
社内や社外の有識者に聞いてみればまた別の回答があったのではないでしょうか？
マーケティングなどの段階でもう少し調べれば分かったのではないでしょうか。
何ヶ月もコードを書いて、ローンチして、さらに数ヶ月もがいて結果が出ない。
ピボットを試みたいので社内や社外の有識者に話を聞いてみようと思い会議をセッティングする。
ピボットのアドバイスが欲しいと言われた有識者は、会議で企画書を一通り眺めたあと一言「うん。これ無理。クローズしよう。」
こういうケースは本当に何度も見たことがあります。
企画書を書き上げた段階で有識者に聞いてみればこれが煩雑系であり、こうすればいいよ、あるいはこの問題をクリアする必要があるよ、というアドバイスがもらえたはずです。
コードを書き始めるのはそれからでよかったのに、と思うケースは本当によくあります。
5.キャパシティ
「今の進捗スピードは１００だけど、３ヶ月後には慣れてスピードが上がるから１２０〜１３０くらいは出せるよね？」
みたいなことを言われることがあるんですけど、パッと見は筋が通っているように見えて実際にはスクラム開発が的した探索的要素が多い開発ってなれてスピードが上がる分なんて微々たるもので、むしろ３ヶ月たっても新たな難題が次々現れるので上がるわけないんですよね
なのにそこで開発スピードの前提が１２０になっていると無理な圧がかかって開発が壊れていくだけなんですよね、っていう話をしました。
これは議事録的なやつなんですけどこれを語るだけで３０分は潰せてしまう
この記事が気に入ったらサポートをしてみませんか？