ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

コミットメントとは何か?

みなさんこんにちは。@ryuzeeです。

昨年夏に同人誌として刊行された「Ultimate Agile Stories」に寄稿させていただいたのですが、昨日のJim Coplien氏の認定スクラムマスター研修でもコミットメントの話が出ていましたので、参考までに僕の考えを転載します。 なお、Ultimate Agile StoriesはIteration2として今年も刊行を計画されるそうなので、是非動向をウォッチしておいてください。昨年は平鍋さんをはじめとする日本のアジャイルコミュニティを牽引するすごい方たちがたくさん寄稿されていました。

システム開発をしていると「コミットメント」という単語をよく耳にするだろう。アジャイル、特にスクラムの文脈においては「コミットメント」は重大な意味を持っている。本稿ではシステム開発における「コミットメント」とは何なのかについて考察してみたい。

1. 辞書の定義からの考察

コミットメント(Commitment)を辞書で紐解くと、委託・委任、言質・約束・公約、責任、献身・傾倒といった意味を持っていることが分かる。この単語の興味深いところは、言質・約束と献身といった感覚的に相反する意味を持っている点であろう。

2. 日本の開発現場におけるコミットメント

日本の開発現場におけるコミットメントは多くの場合「約束」として捉えられているのではないだろうか。そして以下にあげるような問題を抱えている。

  • 見積りが「約束」とみなされる
  • チームの同意なき「約束」
  • 「約束」の達成に関する強い圧力

それぞれについて掘り下げてみよう。

見積りが約束とみなされる

不確実性コーン や納期の確率分布についての話 から分かるようにプロジェクトの見積りには不確実性があり、またそもそもソフトウェア自身が多くの不確実性の上に成り立っていることを踏まえれば、見積りをコミットメントと同一視することが如何に危険なことであるか分かるだろう。見積りは予測であり、予測は時に大きく外れる。そして外れる場合は大抵想像したよりも悪い方に外れてしまう。

チームの同意なき約束

製販分離という名のもとに、営業担当者や管理職等、実際に開発を行うチームのメンバー以外が「約束」してしまう場合も良く聞く。Scrumにおいてはスクラムチーム(PO,SM,開発チーム)は豚、それ以外の人は鶏として定義されており 、見積りは開発チームが行うことになっているが、日本の多くの現場では(場合によってはScrumを導入しているにも関わらず)営業担当者や管理職がコストやスケジュールを勝手に「約束」してしまう。そしてチームメンバーはプロジェクト開始時点から、到達が著しく困難なゴールに向かって絶望感を抱きながら立ち向かうことになってしまう。

「約束」の達成に関する強い圧力

前述の項目と同時に発生することが多い問題として、「約束」の達成に関して強い圧力がかかることがある。半強制的な長時間残業や休日出勤を強いられたりするケースも多い。「やる前からできないと言うとは何事か!」というような精神論や、効率や正確性を語らず長時間働いている人を評価してしまう文化も圧力と言えるだろう。そして達成できなかった場合に、時には人格否定かのごとく責め立てられることもあると聞く。

以上に挙げたような問題が組織の中で継続して発生していると、開発チームメンバーは疲弊し、時には病気にかかったり、優秀な人材が転職で組織を去っていく傾向が強い。そして事態が加速度的に悪化し組織がどんどん弱体化していくのである。

3. アジャイルな開発におけるコミットメント

一方で、アジャイルな開発におけるコミットメントを筆者は以下のように定義したい。

  • チームが最大限努力することを約束すること
  • チーム全員が自主的に同意して約束すること
  • 自分たちの速度を基準にその範囲内で約束すること
  • 進捗状況を明らかにし、問題が起こった時は隠さず、すぐに明らかにすることを約束すること

チームが最大限努力することを約束すること

前述の通り不確実性の高い状況下において「達成」に関する約束をすることは難しいが、一方で個人による努力ではなくチーム全員が同じゴールに向かって最大限努力することは約束できるだろう。誤解して欲しくない点として、これは長時間労働や休日出勤をするという意味ではないということだ。アジャイルな開発の特徴は、リソースと時間を先に固定し、その範囲内で最大のビジネス価値を実現するものである。固定された時間の中で成果を出さねばならない。そしてその努力の中には、自分達がより良い成果を早く出せるようになるために、チームで継続的に改善を行うことも含まれるのである。

チーム全員が自主的に同意して約束すること

鶏と豚の比喩を前述したが、身を切る存在である豚みんなが自主的に合意した上で約束する必要がある。Scrumにおいて見積りは開発チーム全体の活動であり、全員が意見を言う場でもある。ふりかえり等のその他の会議も同様だ。またチームには上下関係はないので、社内的な職位の上下や年次の上下によって同意を強制されてはならない。

自分たちの速度を基準にその範囲内で約束すること

Scrumにおいて、開発チームの開発速度を示す単位の1つのベロシティがある。ベロシティとはスプリントごとの「完了」したストーリーのストーリーポイントの合算値であり、数スプリントをこなすと徐々に安定した数値を示すようになる。この数値を利用して、例えばチームのベロシティの平均が20ポイントであれば、次のスプリントでは20ポイント分のストーリーの完了は経験則上約束できると言える。

進捗状況を明らかにし、問題が起こった時は隠さず、すぐに明らかにすることを約束する

アジャイルな開発における肝の1つに透明性がある。チームは常に問題を明らかにして、正直に進捗状況を明らかにする責任がある。問題の発生は責められるべきものではなく、早く明らかにして対処すべきものであるのだ。問題が発生した場合に個人が責められる文化の場合、チームはどうにもならなくなるまで問題を隠蔽してしまう。これは最も避けるべきことだ。

以上で述べたことは、端的に言えば、チームがプロフェッショナルとして献身的に働くことを約束するということだ。無理なことでも何でもやるのがプロフェッショナルなわけではないのだ。

4. まとめ

冒頭で辞書での「コミットメント」の定義についてふれたが、コミットメントとは、単なる「約束」や「言質」ではなく、チームがプロジェクトの成功のために「献身的」にかつ「誠実」に「持続可能なペース」で働く「姿勢」なのではないかと考えている。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 Jenkinsから送信されるメールをカスタマイズする
次の記事 プロジェクトを立ち上げる際に行うべき20の質問

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World