10/1(金)のエントリーでも書いたのですが、DevLOVE Energized Work!」で「闇アジャイラー」というネタLTをしてきました。
諸処の事情でボツにしたネタやスライド、そもそものLTの背景などをメモしておきます。
■「闇アジャイラー」について（P2-P11）
・なんで「闇アジャイラー」なのか？
冒頭で説明したとおり、XP祭の翌週、ネット上でにわかに盛り上がっていた「闇プログラマー」にインスパイア(笑)されました。アジャイル原則と架空の闇アジャイル原則を比較したらそこそこ笑ってもらえるだろうか、と。
実際のところはただ単純に闇アジャイラーって言いたかっただけなので、そんなに深いねらいはありません。LTだから出オチでいいだろう、という程度。
・カットしたスライド
当初、アジャイル原則と闇アジャイル原則の比較はもっと「エグい」話を入れていたため保険として入れておきましたが、エグい話はカットしたので不要となりました。
きっとみなさん律儀にEnergized Work!の話をするだろうなと予測しました。LTで14回もEnergized Work!の話を聞いたら参加者はみんな飽きるだろうと判断しカットしました。実際、Energized Work!については一言も喋っていません。
しかしテーマとしては外していないつもりですし、闇アジャイラーはEnergized Work!の障害の一種です。
「闇アジャイラーかわいいよ闇アジャイラー」
実は平鍋さんバージョンもあったのですが、ご本人の前でやるのは気が引けたのでカットしました。
■アジャイル原則と闇アジャイル原則の比較(P12-P19)
アジャイル原則は全部で12項目あので、闇アジャイルバージョンも12項目すべて作りましたが、しつこいのとエグすぎる（笑えない）ため4項目を残してカットしました。尚、アジャイル原則は言い方がいろいろあり、日本語訳も何種類かあるようです。
アジャイルを表面的に都合良く解釈して関わるメンバーに無理強いをさせる、前言を翻すためにアジャイルをもちだす、そういう人に対して言いたいことがあったりなかったり（※フィクションです）。
■【図解】闇アジャイラーが生まれるまで(P20-P45)
小ネタ（「絶対領域」、「すまぬ…すまぬ…」、「だが断る」）を仕込んでいますが結構まじめな話です。
「曖昧領域／調整領域／絶対領域」
twitter上で「あいまいなことが多すぎてプロジェクトの見通しが悪い」みたいなことをつぶやいたときに「あいまいなものはなくならない」ととある方がおっしゃいました。あらためて考えると確かにその通りで、プロジェクトの特性（独自性、有期性、段階的詳細化）を考えてみてもあいまいなモノゴトが存在するのは確かです。
しかし本当にマズイのは、あいまいなモノゴトを都合良く解釈したり、思い込みがあったり、またほのめかしをしたりすることで、それがステークホルダーで共有されていないことです。この「曖昧領域／調整領域／絶対領域」の図ではプロジェクトの様々な情報がどのような状態にあるのかを可視化することが大切であることを言いたかったのです。これはPMBOKのプラクティスが全てプラクティスの前後にインプットとアウトプットがあることがヒントになっています（それだけじゃないよ）。
加えると曖昧だから見積もれない、計画できないということもよくあるかと思いますが、そんなことはありません。確定していることは少なからずあり、それがあるのであればそれを制約として利用するという発想ができるはずです。何をしたいのか、何ができるのかをステークホルダーでちゃんと共有しましょう。
話はそれからです。
私が関わったとあるプロジェクトですが、そのプロジェクトでは技術はほぼ初めて採用するもの、期間は半年以上、検証をしつつ本番実装をする、ユーザー数未定、実装する機能も未定といった条件で見積もりと計画をつくったことがあります。その際、こちらの確保できる工数を伝え1ヶ月ごとのタイムボックスを切り、その都度、優先順位付けをしてスコープを検討し、見積もりを提出していく手法を提案して採用されたことがあります（この時はアジャイルじゃなくて統一プロセスを参考にしましたが）。毎月精査な見積もりを提出するのは本当にしんどかったのですが、プロジェクトの進め方としては悪くなかったと思います。
これはアジャイルや統一プロセスなどについて書籍を通じて学んでいたからできたことです。たとえ形式知のレベルであっても日々学ぶことで何かの役に立つことは多々あります。
また書籍のよいところは形式知化されているため他者に伝える際、伝え方の参考になることです。「わかっていはいるし実践もできるけど説明ができない」ことありませんか？ 書籍を通じて体系的な形式知を学ぶことで助けられるはずです。
ところでこの「曖昧領域／調整領域／絶対領域」の図ですが、こういった情報を意識して共有することが大切なのでこの図や言葉を使う必要はありません。
貸借対照表のような書き方をするのも面白いかもしれませんね。
■ プロセスからオチまで（P46-P58）
プロジェクトは以下の特性を持っています。
１．独自性
２．有期性
３．段階的詳細化
これをちゃんと理解しているのであれば、万能なプロセスがないことはわかるはずです。
ウォーターフォールが悪いのではなく、ウォーターフォールが適さないプロジェクトを無理矢理ウォーターフォールにあてはめることが悪いのです。これはアジャイルもそうです。
様々なプロセスについて論じること自体は嫌いではありません。むしろ積極的に飛び込んで意見を出したり聞いたりすることは好きです。でもちょっと皮肉っぽくきのこ厨vsたけのこ厨の話を引き合いに出しました。
ちなみに私はtakeだけにたけのこ派です。
・カットしたスライド
「ガンプラ」
私がプロセス偏重の危険性を説明する際、よく使う喩えなのですが時間の都合と、そもそもガンプラの組み立てはアジャイルである必要はなく、話の流れの中で違和感が生じるためカットしました。
「曇りなき眼で見定めてプロジェクトを計画すること。」
スライドは残しましたが画像はカットしました。オチにでてくる光のインパクトを最大化したかったためです。
「不確実性のコーン」と「ブルックスの法則」
不確実性のコーンはネガティブな印象を持ちそうですが、これはプロジェクトの曖昧なモノゴトを明確にしていくという学習プロセスを象徴したものだと思うとなかなか良い図だと思います。しかし初期段階における不確実性を無視することで曖昧なモノゴトの暴走を許します。
ブルックスの法則に対する無理解こそが、人を機械部品のように扱う闇アジャイルの最たるものだと思います。
いずれも時間都合でカットです。
「光のアジャイラー」
このLTのオチになるところですが、３つの候補画像からどれをどのように使うかで悩みました。
１．森の中に光が差し込むパターン
２．ああっ女神様のベルダンディーが輝く地球のようなものを抱えているパターン
３．風の谷のナウシカが「いのちは闇の中にまたたく光だ！！」と言い切るシーンのパターン
無難に１．でスライドを作っていたのですが、本番の前日にMicrosoft台湾が光をリリースしたことによりあのようになりました。これは完全にラッキーですね。
いつも使っているThank you Marioのページ、Let'sで始めたらwith meはいらないよね。今更だけど恥ずかしいミスです。。
■さいごに
再度「曖昧領域／調整領域／絶対領域」
闇アジャイラーも2つのパターンがあって、一つは1人のリーダーやマネジャーによってもたらされるとき、二つめは関わる人の多くが暗黙的な考えや振る舞いによってもたらされるときがあると思います。
今回のLTの図では、闇アジャイラーが生まれる直前、カオス状態になって全員が「死ぬまで働けば」と思い詰めてしまいます。それは時間が経つと、その状態に否という人に対して攻撃や排除をし始めたりします。過剰な残業が常態化している組織であるのかもしれません。
個人的には1人のリーダーによってもたらされる闇アジャイルよりも、チームメンバーが暗黙的にやっている闇アジャイルの方が多くの不幸を生み出す気がします。これは組織の文化であることもあるので根深い問題です。
もしそういった状況におかれている方がいたとして、その方が「Energized Work!」を知って何かが変わり始めれば良いな、と思います。
0 件のコメント:
コメントを投稿