ソフトウェア開発チームの "Measure twice, cut once"

私たちのチームが大切にしているキーワードのひとつに、"Measure twice, cut once" （二度測って、一度で切る）があります。もともとは優れた大工を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。

この短いフレーズには2つのレッスンが含まれています。

・"Measure" をおろそかにしないこと
・"Measure" と "Cut" を明確に分けること

開発チームにおいても、Measure twice, cut onceの大切さは大工にとってのそれと変わらない、というのが我々の意見です。手戻りはデリバリの速度だけでなく、実装のtangibilityにも影響するからです。ソフトウェアのバグが一番現れやすい箇所は「試行錯誤の苦労の末になんとか実装できた機能」だということを、我々は経験的に知っています。
Measureをおろそかにしないことについては、別の機会に改めて整理したいと思います。

我々が考える"Measure twice, cut once"の本質は、後者のMeasureとCutを同時に行わないことにあります。なぜなら、2つの作業は根本的に異なる性質を持っているからです。

Measure

開発チームとってのMeasureは「何をどのように行うか」についての計画を立てるフェーズにあたります。スクラム開発チームにとって一番身近なのはスプリントプランニングでしょう。これは市場環境やステークホルダーの意向、ユーザーの反応、現在のコード、チームの習熟度などを入力に取り、実行可能な計画として出力する作業です。

ここでの難しさは、要素のつながりや相互関係による複雑性（dynamic complexity）に由来します。この複雑性に対処するためには、明文化された仕様やソースコードといった「今見えているもの」だけでなく、プロダクトロードマップや過去の経緯といった時系列的な要素や、チームやステークホルダーを含めた利害関係者、ビジネスモデル、コミュニケーションの経路といった構造にも注目する必要があります。

それらの要素同士は矢印で繋がって系（system）を成しています。厄介なことに、系に対する行動の効果や影響は、幾多の要素のつながりを経由し、時間的な遅れを伴って現れます。解決策の副作用が意図した作用を打ち消してしまうだけでなく、新しい問題を生み出す原因になってしまうこともあります。具体的な例を挙げずとも、ソフトウェア開発者には思い当たることがいくつかあるかと思います。

ここで大切なのは要素間の関係性を俯瞰し、系のダイナミクスを捉えることです。これは独特な集中力を必要とする行為です。

Cut

Cutは計画を実行するフェーズに当たります。スプリントは「8割の確率で達成できるコミットラインが理想」と言われますが、そのような状況下においてチームが使える時間に余裕はありません。大切なのは「いまここ」に集中できる環境をどれだけ作ることができるかです。

ここにMeasureを混ぜるなら、様々な要素を考慮して計画を立てつつ、それを実行しないといけません。必然的にマルチタスクになります。マルチタスクがもたらすコンテキストスイッチがどれだけ生産性を低下させるかはよく知られています。ワインバーグは、5つの要素をスイッチすると個々の要素に使える時間は全体の5%になると述べています。75%もの時間がどこかに飛んでいってしまう訳です。

時間だけでなく、集中力が失われることにも注意してください。そのような状態で何かを計画することが、良い結果につながることは少ないでしょう。

誘惑と戦う

とは言っても、実際に手を動かさないと計画の立てようがないことも実際あります。そんな時に行われるのが"Spike"ですが、私たちのチームはそれに加えて ”Scaffolding & Re-planing” と呼ぶ方法を使うこともあります。これについてもまたいつか整理したいと思います。

大事なのは「計画モード」と「実行モード」を注意深く分離することです。時間的な焦りがあるときには特に、2つを同時に済ませたい誘惑に駆られますが、多くの場合これは不満足な結果につながります。私たちはその誘惑を押さえ込む必要があります。

ご武運を祈ります。

photo by Georgia National Guard in CC 2.0