脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック

14章リズム

いろいろなソフトウェア開発組織で働き、さまざまなソフトウェア開発組織を訪問してきました。あるプロセスに従っているところもあれば、別のプロセスを使っているところもありました。特定のプロセスに従っていると言っている組織でも、実際にしていることが違っていることもありました。

デイリースタンドアップをしているというチームが、実際には2日に1回気が向いたときにしているだけということもありました。

デイリースタンドアップを毎朝実施するチームで働いたこともあります。メンバーの1人はスタンドアップの中心を自分のデスクの近くに移動させておいて、本人は座ったままでした。昨日やったこと、今日やること、困っていることというフォーマットは完全に無視して、15分間適当なことをしゃべっていただけで、立っている足がだんだん痛くなることもありました。

かっこいいカンバンボードのあるチームでも働きました。でも、いつも消火作業に追われていました。素晴らしいカンバンカードも、実際に何が起こっているかを知るのには役立っていませんでした。

これまででベストだと思ったチームには、プロセスがほぼ存在しませんでした。継続的デプロイを実現していたので、あまりプロセスが気にならなかったのです。ステークホルダーが消化できない速度で機能をリリースしていました。「これはもう終わった？」とたびたび聞かれることはなく、逆にメンバーはステークホルダーに「ご要望の機能の出来を見ていただけましたか？」とときどき聞いていました。答えはたいてい「忙しくて時間が取れなかった」でした。

ここで、どのように組織を作るかを語るつもりはありません。スクラム、エクストリームプログラミング[5]、PRINCE2、あるいはデイリーカオスなど、どんなプロセスに従っていても、みなさんが使えるアイデアを本書で提供したいと考えています。特定のソフトウェア開発プロセスを推奨したいとは思いませんが、1日のなかに緩いリズムや構造があることは役に立つと考えるようになりました。あなた個人の働き方に適用できますし、チームにも役立つかもしれません。 ...