日々の破片

_ 30日でソフトウェアを開発できるかな？

アスキーの鈴木さんから頂いた本の中にSoftware in 30 Daysというスクラムのマネージャ向けの本がある。

マネージャ向けというのは僕の印象論ではなく、著者の言葉だ。『本書は、生き残りと競争力をソフトウェアに依存している組織のリーダーたちに向けて書いたものだ』。でもプレイングマネージャっているし、という前にもっと明確に『ソフトウェア開発を「しない」人に向けて書いたのは、本書がはじめてである』と書いている。さらに定義として『優れたソフトウェアを短期間・低コスト・高い予測可能性・低リスクで届けたい組織のCEO・経営者・シニアマネージャに向けて書いたものだ』としている。

まず、薄い本だ。全部で208ページだが、P.140以降は用語集とスクラムガイド、プレイブック、そして索引なので実質150ページ程度で、なるほど、この読解高速性というか即席性からしてすでに開発しない人のための本となっている。薄さにあわせて価格も抑え気味だ。

ところで、プレイブックってなんだろう？ スクラムをプレイするための心構えや方法が書いてあるのだけど。シナリオっぽくもあるし、辞書をひくと脚本、計画、戦略と書いてあるから、読んで掴んだイメージ通りのものらしい。追記:アメフトらしい。

であれば、実は、この実質30ページ弱の付録C『エンタープライズアジリティを獲得するためのプレイブック』だけ読んで済ませても良いように思う。

そうではなく、まず説得されて納得したければ、本文を読めば良い。

すると、Software in 30 Daysというのは、30日で開発するのではなく、適切な区切りで（全然別の言い方をすれば）PDCAを回すと、ソフトウェアだと最大でも4週間程度が区切りとして良いという意味だということがわかる。

根拠はわからないが、30日のコストに対して2週間だと1.5倍のコストがかかり、1週間だと3倍にコストが膨らみ、30日を超えると情報が処理しきれなくなったりだれてしまうから問題外ということらしい。

根拠はわからないと書いたが、最初のほうでソフトウェア開発では経験主義が正しいとしているので、経験的にそうなるということだろう。

というわけで、本文はスクラムの概要を盛り込みながら、なぜ経験主義が正しく、そして経験に基づけばスクラムがソフトウェア開発には最適であるということが説明され、付録で用語を示し、ガイドでルールを覚え、プレイブックを参照してプランするという構成となっている。

妙に簡潔にまとまっていること、内容がこなれていることから、アジャイル15年の歴史で、ここまで洗練されたのだな、と考える。

というわけで、チームの進め方がまだアジャイルになっていなければ、とりあえずスクラム、手元にこの本、でやってみるのが良いのだろう。

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド(Ken Schwaber)

判型は技術書の定番のサイズより一回り小ぶりで、ページ数と価格も手ごろなので、読みやすい。

_ 分身

イメージフォーラムでベルトルッチの分身。とりあえずメモ。