みんなをバスに乗せる

アジャイルサムライ−達人開発者への道−

以前この本を読んだときに「みんなをバスに乗せる」という章があった。

チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがだめになるんだ。

まあ、そうだよね。

この本は基本的に受託開発の視点をベースに書かれていると思うけど、別に受託開発に限った話でもなく、アジャイル開発に限った話でもなく、この章に書かれている話題はチームで仕事をするという上で当たり前のことだと思う。

そして、あるプロジェクトのサブプロジェクトにメンバーとして参加していたのだけど、「みんなをバスに乗せる」ことについては失敗していた。 そもそも、当の本人たちでさえバスに乗れていたのだろうか？

そのサブプロジェクトを始めたときにはまだアジャイルサムライを読んでいなかったのだけど、僕は一応この問題を認識していた。 なので、最初にリーンキャンバスをつくろうと提案して、実際につくった(なぜリーンキャンバスにしたのかというと、チームで既にリーンキャンバスは導入されていて慣れていたことと、その他に都合のよさそうなフレームワークを知らなかったからだ)。 しかし結局、リーンキャンバスはサブプロジェクトメンバーの間でも段々と参照されなくなり、大元のチームメンバーに説明をする際にも全く活用されなかった。

そもそもリーンキャンバスはチーム内で合意を取るためのフレームワークではないので向いていなかった、という話もあると思う。アジャイルサムライではインセプションデッキというフレームワークが紹介されているけれど、リーンキャンバスの代わりにインセプションデッキを利用していたら少しは変わっていただろうか。

また、フレームワークがどうとか言う前に、僕は新しい会社においては新参者ということでなるべく前の会社のやり方を押し付けないようにしようと努めていたのだけど、その態度が失敗につながっていたな、とも思う。

結果として引き起こされたのは、意識のビッグバン結合だった。 結合自体は、一先ずのところなんとかいったと信じている。けれど確実に、様々な不満や不信といったような負の遺産も生んだと感じる。

ちゃんとみんなをバスに乗せていれば、ちゃんとソフトランディングできたはずだと考えている。また、意思決定も明確になり、もっと良いプロダクトを生み出すことができたはずだとも考えている。

色々な方法論や道具があるけれど、先ずはきちんとやって当たり前のことをやろう、と反省した。