[#TiDD] ちょっとまじめにyaXP(yet another eXtreme Programming)

先日のXP祭り関西のライトニングトークでお話しした「yaXP: もう一つのXP」は、お祭りの雰囲気を盛り上げるためのネタでした。しかし、本の宣伝を除いた部分は、体験に基づくプロセス改善の提案です。ここではちょっと真面目に背景を説明してみたいと思います。

＜XPのむずかしさ＞

それは第1次アジャイルブームの頃でした。「アジャイル＝XP」のような時代で、これは良さそうだと、担当していた研究開発プロジェクトで実践したことがあります。

しかし、XPで効果をあげることはできませんでした。今から振り返ると以下のような問題がありました。

(１) 場所の確保

タスクボードを確保しようとするとホワイトボードを占有してしまい、打ち合わせに支障が出てしまいました。仕方がないので、エクセルシートをタスクボードに、1行をタスクカードに見立てて管理しました。これが以下のような問題をのベースにありました。

(２) 進捗管理が難しい

XPではタスクボードで進捗を管理します。タスクボードには3段階の進捗があるだけです。プロジェクトの進捗を管理するには、従来の管理単位よりも粒度の細かい作業に分割する必要があります。しかし、エクセルをタスクボードにしたために、新しいタスクの登録が億劫になってしまい、これまでの線表レベルのタスクに分割しただけでした。結果的に進捗が％で表されないので細かな進捗がわからず、管理が困難になっただけでした。

(３)　自律的でない

エクセルというツールの特性から、タスクのたたき台はリーダの私が作成し、その後にチーム内で確認しました。しかし、各担当者は従来の開発どおりに、与えられた作業を実施するという感覚のままでした。担当の作業を確認し、詳細化し、コミットする、といった感覚はありませんでした。

(４) 情報共有

全体のスケジュールは全員で共有していましたが、問題の発生を共有できていませんでした。誰かの作業に問題が発生しても即座に対応できず、結果的に問題が発生してもずるずるとスケジュールが遅れるだけでした。

結局、XPを意識した形だけの開発はうまくいきませんでした。

＜プロセス改善のキモ＞

今から考えるとXPやアジャイルを形で捕らえていたのが敗因でした。仕様や開発方針の決定権が開発チームにあり、ホワイトボーの件を除くとアジャイル開発に有利な環境でした。しかし、なぜそのような活動をするか、何が目的であるか、そのことを抜きにして安易にプロセスを「まねた」ので、うまく行かなかったのです。

当時「良いプロダクトは良いプロセスから生まれる」と言われていましたが、その良いプロセスとは、人のものまねではないのでしょう。よく考えられ、一貫性があり、組織的なものなのでしょう。

たとえばレビューを考えても、ベテランのレビュアなら何もしなくてもうまくいくでしょう。しかし、レビュアによっては教育が必要で、チェックリストやレビュー時間の基準なども必要でしょう。人を見て、開発対象を見て、どこにリスクがあり、どう攻め込むか、そんなイメージがはっきりしていなければ、どんなに良いプロセスをまねてもうまくいきません。

＜良いプロジェクト＞

私の考える良いプロジェクトは以下のようなイメージです。

• トップダウンでなく、自律的、協調的
• コミットメントによる見積もり精度向上
• もれなくタスクが実施される
• 問題が常に見える化される
• 混乱のすくないテンポの良いプロセス

リーダーの役目はメンバーの能力を引き出すことです。やってみたいではダメで、きちんと目論見があって実施すべきです。問題をきちんと見極めたなら、その問題を解決できる方策を考えます。それが仕事です。結果的にアジャイルや何かに近いかもしれませんが、アジャイルが目的でなく、プロジェクトを通じて関係者をより幸せにすることが仕事です。

＜チケット駆動開発がもたらすもの＞

上に書いた良いプロジェクトを目指す中で、私はチケット駆動開発を導入しました。そのプロジェクトはStrutsベースのパッケージをカスタマイズするという従来型の開発でした。多くの問題がある中で私が解決しようと思ったのは、システムテストに向けての環境構築などの細かな作業を管理することでした。

それまで閉塞感を感じていたプロジェクトの雰囲気は、目の前の問題が解決されることで少しずつ改善しました。そしてチケット駆動開発による、ワークフローやトレーサビリティによる安心感のほか、見える化によるコミュニケーションの改善、スコープの変更による想定外の問題への対処など、多くの効果がありました。

その効果の多くは目指したものではありませんでした。チケット駆動開発でプロジェクトのもっとも大きな問題を解決することで得られた副次効果です。あれもこれもと欲張らずポイントを絞ることで、メンバーに受け入れられてうまくいったのです。

いわゆる2割8割の法則、パレートの法則では、2割の問題が8割の負担を与えると言われます。もっとも大きな問題に注目することが最も効率が良いのです。チケット駆動開発はおまけの多い開発法ですので、大きな問題に注目することだけで十分なのです。

＜yaXP＞

さて、話をXPに戻します。yaXPはチケット駆動開発によるXPです。すでにXPを実践されていて、問題がないならそのままでよいでしょう。従来開発でうまくいっている場合も、そのままで良いでしょう。

ただ、現状の開発に問題があり、それがYaXPで解決できるものなら、一度検討してください。その問題についてだけ検討してください。もし、その問題を解決するもっと良い方法があったなら、それを採用してください。

次に具体的なイメージを思い浮かべてください。想像できなかったり、メンバーの個性を考えると難しそうなら、あきらめてください。イメージできないプロセス改善がうまくいくはずありません。

そして、メンバーに大切なことだけ伝えてください。一度に多くの支持を受けてもうまくいくはずがありません。なるべくポイントを絞ることで理解度が上がります。理解してもらえたなら、それだけは実践されるでしょう。

もし、反対意見が出たならよく話し合ってください。そして、より良い方法を見つけてください。あなたの考えたプロセスを実践することが目的ではなく、メンバーの能力を最大限に発揮させるのがあなたの仕事なのですから。

このようにyaXPを実践されたなら、きっとうまくいくはずです。もし途中で問題が出たなら、どんどん改善してください。「ふりかえり」が大きな力になるでしょう。

＜おわりに＞

もう一つのXP(yaXP)と言いながら、ほとんど説明しませんでした。それは、あなたが考えるものだからです。基本的なアイデアはスライドにあります。これをもとに現在の問題が解決できるかどうかを考えてください。そしてより良いプロセスで、メンバーの能力を最大限に引き出してください。論文のPDFのほか、良い参考文献はあります(^_^;