矛盾するように見える、アジャイルの“プロセス・コントロール”の重要性

矛盾するように見える、アジャイルの“プロセス・コントロール”の重要性

アジャイルを信奉する皆さんにとって、管理やコントロールという言葉ほど嫌なものはないのかもしれません。アジャイルはがちがちに規定された管理のスキームからチームを解き放ってチーム主体の運営を行うことで、チームの開発能力を最大限発揮することを狙っています。

SCRUMやXPやらが世の中に紹介されてはや10年強。それ以前の開発標準とは違って、「これとこれがあればアジャイルだ！」という明確でかつ厳密な定義がなく、必要なときに必要なプラクティスを導入する、機動的な開発スタイルに価値があるといわれてきました。

この“定義”の無さは、ともすると同じ“アジャイル”といいながら、実際のやり方が少々違う、多くの“Myアジャイル”を産み出す土壌となりかねません。複数のチームが共同でひとつのシステムを作る場合、My アジャイルをある程度認めつつ、全体としての同期をとることを考慮しなければなりません。

また、開発者も人数が増えれば、全員に同じような成熟度を期待することはできません。開発者の裁量を最大限尊重しようとすれば、「ほかの開発者の自由裁量が、私の作業結果を壊した」といったトラブルは未然に防がないといけません。

つまり、人や組織が拡大してくれば、ゆるいながらもそれなりに一定の規範を設けないと、自由裁量のはんらんが逆に全体の足を引っ張る要因になりかねません。

Jazzテクノロジーでは、開発チームに科すプロセス上の制約を、ツールが自動チェックしてくれます。例えば…

• 単体テストを実施していないコードは、チェックインできない
• 変更理由を明記していないコード差分はチェックインできない
• チームメンバーに参加すると、最初にやるべきタスクが自動的に割り当てられる
• リリース間際になると、限定されたメンバーしかアクセスできない

これらをツールが自動的にチェックし、その対応をガイドすることで、開発者はルールに違反したときだけプロセスの存在を意識すればよくなります。これによって、開発者を膨大な量のプロセス文書から開放しつつ、プロセスの徹底を保証するのです。

アジャイル・スタイルに即したリソースマネジメント

伝統的なウォーターフォールであれば、しっかり設計してからコードへ…ということで、開発の時点でアルゴリズムは絞り込まれていることが当然と思われます。が、アジャイルの場合は、常にチャレンジです。コードへ手を加えることもいとわず、よりよいコードの完成に向けて日々リファクタリングにいそしみ、ペアプログラミングでロジックを研ぎ澄ましていきます。

しかし、分散開発体制では、それも不可能な夢です。多くのプロジェクトでは、商用・非商用問わずソースコード管理システムを利用していますが、その使い方を見ると、以下のパターンに大別されます。

• 単なる個人のファイルバックアップとしてしか使わない
• 承認され、一定水準の品質を達成したもののみ管理される（←きちんとした構成管理っぽい）
• インストールしたけど、誰も使わない（←実はこれが一番…）

アジャイル屋さんは「ソースコードで会話する」という表現を使いますが、これは見方を変えれば、「確定していないロジックの候補が複数あって、ためつすがめつしながら、最終的によりよいものを採用する」という活動が行われることを意味します。これをリソース管理へのリクエストとみなすと、次のような要件が必要となります。

1. （複数のチームによる開発なので）構成管理としての（当然）機能を有していること。バージョニングやラベルで、コードの成熟度を管理できること
2. 一定品質を達成しているリソースと、それ以前のリソース（アルゴリズム検討中のリソース）とを混乱せず、分離し、しかし関係性を維持・管理すること
3. ネットワーク上のほかの拠点で作業している開発者と共同で“ソースコードで会話“できること。

IBM Rational Team Concertでは、各作業者の作業領域のコピーをサーバー側にもって、それをほかの開発者とやり取りすることで、統合用の領域を汚すことなく、中間状態のリソースを共有して疑似的に“ネットワークを介したソースコードによる会話”が実現できます。

さて、次回は、管理者と開発者のコラボレーションをもう少し掘り下げて最後としましょう。もう少しの辛抱です。