コミットメントは有料である

私も執筆に関わった「わかりやすいアジャイル開発の教科書」のインタビュー記事が公開されています。

http://www.sbbit.jp/article/cont1/26283;title

その中で、私はコミットメントについて触れています。今回はそのコミットメントについて私なりに掘り下げてみます。コミットメントについては@ryuzeeさんがアジャイル同人誌であるUltimate Agile Stories Iteration1に書いたいただいており、ブログでも公開されています。

[Agile]コミットメントとは何か？ | Ryuzee.com

@ryuzeeさんが記事で書いてくださっていることも踏まえて、私なりの考えを書こうと思います。アジャイル開発では、タイムボックスを守って開発をする上で、スコープを調整します。しかし、多くの組織では、ある期限までのスコープをコミットメントする（させる）ことが重要視されています。何故、コミットメントが重要視されるのでしょうか？
コミットメントの一番の効用は、相手にコミットさせることで、自分が「安心感」を得られることだと考えています。
そして階層的な組織では、各階層で自分よりも上位とのコミットメントを守れるという安心感を得るために下位に対してコミットメントを求めます。こうしてコミットメントが積み重ねられていくのです。依存関係が複雑になって手を加えられないソフトウェアのように、あるコミットメントが変更すると、積み重ねられたコミットメントに影響が出てしまうため、変更がなかなかできない状況になってしまいがちです。
私はコミットメントを求めること自体は悪いと思いませんが、コミットメントは有料であるということを認識しておく必要があると考えています。「10日でやります」といってできなかったときに責任を取らされるのであれば、絶対に10日で終わりそうなスコープでしかコミットできません。うまくいけば5日で終わりそうだと思っていてもバッファを確保します。
コミットメントのプレッシャーが厳しい環境の場合は、「5日で終わらせたら今度はその基準でコミットメントを求められる」と思って、5日間で終わりそうな仕事で10日間かけてしまいます。これはやっている人が悪いのではなく、コミットメントを求める側がコミットメント料を支払っているということなのです。
コミットメント料が保険金のような性質があります。すなわち、よく事故がおきる相手へのコミットメント料は高くなるし信頼できる相手へのコミットメント料は安くなります。
先ほど説明したような階層的な組織では、上は経営者から下はリーダとメンバーの間まで各階層でコミットメント料が発生しているのです。しかも組織全体のコミットメント料の総額を把握することは困難です。
スクラムのフレームワークでは、チームが見積もりを行いますが、プロダクトオーナーはチームの見積もりを受け入れる必要があります。スクラムにルールがある理由は、開発チームに優しいのではなく、コミットメント料を支払わない方が得だからだと考えています。各層でコミットメントを行って、コミットメント料を発生させるよりも、本当にコミットメントをしなければならない部分を絞り込んで、そこだけにコミットメント料を発生させた方が合理的なのです。
スクラムを組織に導入するときに、コミットメントと向き合わなければならなくなります。そういうときには、コミットメントを求める相手にコミットメントをさせない方が得をするという体験をしてもらうことが大切だと思います。その上で、コミットメントを求められたときは、勇気を持って「コミットメント料がかかりますよ。」と言ってみるのも良いでしょう。
コミットメントをしたり、求めたりする際にその料金について考えてみましょう。