モラルと技術−パート1

プロジェクトにおけるモラルと技術について考える、2部構成の第1部。まずはスクラムにおけるプロダクト・オーナーの姿勢に関するブログを題材にリーダーの姿をふりかえる。第2部ではスクラムが内包する他の問題点として、スクラムの方法論から技術的要素が抜け落ちているという議論を確認し、それを支える存在としての共通基盤チームについて考察する。

はじめに:プロダクト・オーナーについて

Wikipediaによれば、スクラムにおける「プロダクト・オーナー ("Product Owner")」とは顧客の意見を代表し、ビジネスの視点から正しいものが作られていることを保証する存在です。スクラムではないプロジェクトには存在しないかと言われれば当然そのようなことはなく、日本のITゼネコン構造に照らしてみると、いわゆるPMないしPL、つまり早い段階から顧客と要件に関する打ち合わせを行い、その後プロジェクト全体を管理していくSIerプロパさんが該当するのではないでしょうか。次の章はそういった役回りの人を念頭に読んで下さい。

リーダー論



プロダクト・オーナー:ちゃんとコミットしていますか?
http://agilesoftwaredevelopment.com/blog/peterstev/product-owner-are-you-chicken

導入

開発を成功させる鍵の一つは顧客と開発チームとの協力にある。この間をつなぐプロダクト・オーナー(以下、PO)の仕事は簡単ではないが、POが開発チームと密接な関係を築いている程、プロジェクトはうまくいくことが多い。

ブタかニワトリか

これは「ハムと卵」の話から来ていて、要するにニワトリは参加するだけだが、ブタはコミットしている。ニワトリがプロジェクトに悪影響を与える可能性は無視できないので、スクラムはニワトリの影響を可視化し、そこからプロジェクトを守る方法を模索するのだ。
ものの本によれば、POはブタ、つまりブロジェクトに完全にコミットすることになっているが、現実には他のこともやらなければいけないことが少なくない。


POはたいていの場合、本当にコミットしている
「ふりかえりの場にPOは参加していて、発言を許可されているか」という質問に対して、70%が参加していると答えており、発言を許されていないという答えはなかった。


貧弱なPOが与えるインパク
情報伝達の遅れや不備、あるいは見積もりの甘さなど、POの能力不足はプロジェクトの成果に直結する。
しかし、それ以上に深刻なのはPOのモラルである。

More subtle but more damaging to the project is poor morale caused by a P-O who shows that he doesn’t care. If he doesn’t care, why should I? And people lose their sense of urgency.


もっと些末でありながら能力不足以上にプロジェクトにダメージを与えるのは、無関心なPOが引き起こすモラルの低下です。メンバーは「POが無関心なのに、どうして自分が?」ということになって、危機感を失っていくのです。


どういう時にPOはニワトリでなければならないか
それはメンバーがPOを恐れている時、あるいは変更をする気がないか、変更をすることができないPOを扱う時だ。

危険な兆候

ニワトリチェック
チームメンバーからニワトリとして扱われているならば、それはニワトリとしてふるまっている証拠。例えばふりかえりなどに来なくてよい、と言われるなど。


スプリントの失敗、リリースができない場合
要因は色々考えられるが、基本的には見積もりの失敗としてPOに帰される。


船頭多くしてなんとやら
POの役割は分担するべきではない。


メンバーのモチベーションが下がっている
POはむやみに現場を留守にするべきではない。

よりよいPOになるための3つのコツ

1. チームプレイヤーとなって、ルールに従って仕事をする
スクラムがもつすべての儀礼に参加することが重要。むやみに他に仕事を振ってはいけない。


2. 自分のコミットメントに誇りを持つ
スプリントの間、チームメンバーに課せられたタスクが増えないように、きちんと守る。


3. 必要なときに捕まえられる存在になる
ミーティングには時間通りに来て、最後までいる。チームが必要とする時間をきちんと割く。

スクラムのマネジメントは経験論的なマネジメント

最善の努力から始めて、少しずつ改善していきなさい。そういう態度がメンバーの信頼を得るのだ。


考察

"commit"という表現をすっきり日本語にできませんでしたが、ポイントはプロジェクトの成功に自分の存在を賭けているかどうか、つまり、「採算がどうの、スケジュールがどうの、の前に、プロジェクトを成功させるということに対して、本気でがんばろうと思っていますか?」ということですね。内容的には、もちろんごく当たり前のことだと思いますが、「その場にいること」を特に重要視しているあたりは、コミュニケーションを大切にするアジャイルの特徴が現れている部分かも知れません。それにしても、素晴らしいことが書いてあるにもかかわらず、読み終わると気持ちが落ち込むのは何故なのでしょうね。


ここで書かれていることを着実に実行しているようなリーダーがいるブロジェクトは、その段階でかなり恵まれているプロジェクトだと思います。しかし、残念ながらそれだけでは足りないようです。次回はスクラムプロジェクトを支える技術的な要素について考えていきたいと思います。