アジャイルな開発プロセス導入にあたって検討すべきこと - Ryuzee氏の講演資料から -

3/19（金）のTech Fieldersセミナー「Agile Day 2 - ペアで参加し、セッションとワークショップを楽しもう！」の講演の1つに表題の講演があったそうだ。講演資料がここで公開されている。全体とりまとめをされている長沢氏のエントリにも紹介がある。IBMエバンジェリスト玉川氏、すくすくスクラムの今村氏の講演とワークショップで構成されたそうだ。

講演資料にはプロセスを変える際に検討すべきこと、準備すべきことが書かれている。これからアジャイルな開発プロセスを導入しようとする方だけでなく、アジャイルに限らず開発プロセスの変更や新しい方法を導入するとき一般にも、通用する内容というのが私の印象。

私が興味深いと思ったことは以下のとおり。

• 現状がうまくいかないからといって、目的を明確にせず、プロセスを変えたり、技術・技法を導入しようとしない。
• 導入に際して組織のトップへの働きかけと現場への働きかけの両方からアプローチする。
• 説得（納得してもらう）するためには、客観性と論理性が必要（外部の調査事例、内部プロセスの分析結果を準備する）
• 導入当初は、小規模プロジェクトからはじめて実績を作る。
• （ツールを導入するときには）導入自体が目的にならないように。
• 表面的な結果だけをもって横展開しない。

もちろんアジャイルな開発プロセスを導入するために事前に検討すべきことも資料には含まれている。その中で私の印象に残ったのは以下のとおり。

• 契約スキーム（一括請負の問題）
• 外部からのマイクロマネージメントを止める。
• 顧客とゴールを共有するためにプロジェクト開始前に十分に説明する。
• 導入初期には顧客の協力が得られやすいプロジェクトを選ぶ。
• メンバには他の案件をかけもちさせない。
• メンバの技術力だけでなく、コミュニケーション能力も重要

実際の導入実績にもとづいた具体的な資料だと感じた。新しい技法や技術を導入しようとするときには、私も同じようなことを考えている（もちろんこれだけが正しくそれ以外の方法がないという意味ではない）。

開発プロセスや技術・技法の導入に伴い、私が意識していることで、（講演ではお話されたかもしれないが）資料からはみつけられなかった点がある。

• 開発しようとしているソフトウェアはどのようにして利用され、どのように利益を上げるものか（どのようなビジネスを成り立たせるのか）？
• そのビジネスの上で開発プロセス、技術・技法は期待する効果を上げられる見込みがあるか？

私以外の他の方も意識をされていると思うし、Ryuzee氏ご本人もそう思われているのでなないかと思うが。

ソフトウェアレビュー（私の専門の1つ）でも、上述2点の検討が十分でなく、計画時点から効果が期待できないという状況は起こっている。たとえば、長期にわたってソースコードをメンテナンスする見込みが薄いにも関わらずコードレビュー（特に保守性）に時間をかけたり、リリース時期が遅くなると、ソフトウェアの売行きが鈍くなることがわかっているにも関わらず網羅的な設計レビューをして、リリースが遅れていたりというビジネスとプロセス・技法が合致していないことがある。

アジャイル開発においても、顧客が協力的で作りたいソフトウェアが明確でなく実際に動くものを見せながら段階的にリリースすることによって、ビジネス上有利な点が多いものは、アジャイルにやるべきだと思う。逆に全部が揃ってからでないとリリースの価値がないソフトウェアでは別のプロセスも考えるべきではないだろうか。

特に国内のソフトウェアには様々なものがあり、ビジネス上での役割も多種多様だ。それらの前提を意識することなく、プロセスや技術が語られていることが少なくない。自身の開発しているソフトウェアはどのような位置づけで、新しいプロセスや技術はそれをどう支えていくのかという部分も考える必要があるように思う。