読者です 読者をやめる 読者になる 読者になる

Yasuo's Notebook

ソフトウェア開発の話題が中心の備忘録です。

チームに対してどんなコミットメントを求めるか?

ソフトウェアの品質が悪くなる原因の一つに階層的な組織構造+オーバーコミットの組み合わせがあることを以前のエントリで書きました。

スクラム導入で開発を取り巻く矛盾はなくなるのか? - Yasuo's Notebook

オーバーコミットが発生するだけであれば、計画を即座に変更すれば大きな害にはなりません。しかし、階層的な組織構造におけるコミットメントは、変更コストが非常に高いという特徴があります。階層的な組織では、オーバーコミットの発生を認知してから、それを解消するまでの間に、多くの時間が費やされます。つまり、解消するまでの間は、計画とスコープが矛盾しているのです。この矛盾が存在するまでの間、プログラマやテスタは、プロダクトに矛盾を吸収させるしかなくなります。つまり、やっつけでコードを書いてしまったり、テストを省略したりする。まさにこのとき、ソフトウェアの品質はコントロールを失い、ものすごい速度で悪くなっていくのです。チームが品質をコントロールできているという状態は、組織でメトリクスをとって、誰かが統計に合っているか合っていないかを分析しているということではありません。(それはそれで大事なことですが。)
チームが品質について共有した認識を持っていて、それをどのような方法で維持していて、結果としてモデルやコードがどうなっていると良いかが分かっている。そして、それが今できているかどうか、皆がどこができていないかが分かっていてその対応について話し合っている。このような状態が自分たちで品質をコントロールできている状態だと私は考えています。
スクラムには、自分たちで品質をコントロールできている状態を破壊する存在を開発の枠組みに入れないためのフレームワークという面があると考えています。スクラムでは、プロダクトオーナーはプロダクトバックログを作ったり、優先順位を変えたりすることができますが、その見積もりはチームが行います。スプリント計画では、スプリントのスコープは決めますが、チームが設定したスコープを達成しそうにない場合は、早めにスコープを調整します。組織のマネージャに「期限厳守で頑張ってくれ」という権利はスクラムには存在しません。これは、スポーツ、例えばサッカーで言うとゲームを成立させるためのルールに当たる部分です。ルールを無視して手でボールを投げたり、部外者がフィールドになだれ込んで暴れたりしたら、没収試合になってしまいますよね?つまりゲームそのものが成立しません。じゃあ、スクラムを導入してそれをしっかりと守ったら、プロジェクトがうまくいって、品質も良くなるのか?というとそうではありません。ルールに従って試合ができても、良い試合ができるとは限りません。良い試合をするためには、戦い方をしっかりと考えてそれを実行する必要があります。考えた戦い方を実行して効果を発揮するには、そのベースとなる基本的なスキルが必要です。それは、サッカーでいうとキックやトラップ、ヘディングのような基本的な動作になります。ソフトウェア開発における戦い方と基本的なスキルを私はプロセスと型と読んでいます。プロセスというと会社の標準プロセスなど大きな開発プロセスのようなものを想像されるかもしれません。私が今言ったプロセスは大きなものではなく、あることをインプットして何かを実施すると、こういうものができますよ。というものです。一つ一つはとても小さいもので、それらを組み合わせて、開発を進めていきます。型は、可読性の良いコードを書く、テストで同値分割や境界値分析ができる、そんな基本的なスキルです。自分たちで品質をコントロールするには、そのためにどんなプロセスを組み合わせる、どんな型を身につけておかなければならない、というようなコミットする必要があります。テスト駆動開発を実施したり、継続的インテグレーションを実施するということもこの自分たちでプロセスと型を考えた結果として出てきます。「とにかく期限厳守で頑張ってくれ」という目先のコミットを重視する環境では、チームがプロセスや型をコミットすることはできません。逆に目先のコミットを求めないことによって、チームがプロセスや型をコミットすることができます。そしてこのプロセス、型についてのコミットは目先の期限を達成するコミットよりも、より厳密に評価を行い問題点を改善し続ける必要があります。
自分達がコミットしているプロセスや型自体も改善の対象になります。実際、プロジェクトが進行して行く中で、プロセスは変化し続けます。この変化を自ら考えて実行していく責任はチームにあるのです。目先のコミットメントを得るか、もっと長期的で実のあるコミットメントを得るか、どちらを選ぶことがよりよい製品作りに繋がるかをよく考える必要があります。
来週のScrum Alliance Regional Gathering Tokyo 2013の技術トークスというセッションは、開発チームにとっての技術をテーマにしています。技術そのものはもちろん大切ですが、今回書いたような開発チームが自分たちがどのようなやり方を行うかをコミットして、必要な技術を身につけて成長していくことが重要だと感じています。来週のディスカッションの中でもそのような話ができれば思います。