アジャイル開発が導入される条件とは何か   翔泳社『DBマガジン』2006年2月号 「アプリケーション開発-そこが知りたい-」に掲載   石川智久/高橋英一郎/山本啓二

アジャイル開発が受け入れられなかった理由

ただし、プログラミングという活動に、すべてを包括させようとしすぎた嫌いがあるように考えられます。これが、アジャイル開発がある種の立場の人々に受け入れられなかった理由の1つでもありそうです。

アジャイル開発を受け入れた側であるプログラマが考えるように、プログラミングが高付加価値で専門的な活動であることは間違いありません。また、ひとかどのプログラマであれば、単にソースコードを記述する以上の、幅広い価値を生み出すことができるのも確かでしょう。ですが、それと同様に、システム開発にかかわる他の活動にも高い付加価値を生む、専門性の高い役割があります。「プロジェクトマネージャ」や、「ビジネスアナリスト」あるいは「ビジネスモデラー」と呼ばれる役割です。

プロジェクトマネージャは、昨今非常に注目を集めている役割で、システム開発のみならず、プロジェクトの成功のために、非常に重要な責務を担っていることが認識されてきています。プロジェクトマネジメントに関する知識体系であるPMBOKへの注目が高まっていますが、その中では、現代的なプロジェクトマネジメントにおいては、「スコープ、時間、コスト、品質、人的資源、コミュニケーション、リスク、調達、統合」という9つに渡る分野（知識エリア）を適切に管理する必要があるとされています。そのためには多岐に渡る知識と、実装技術とは異なる分野でのノウハウが必要となります（図4）。

図4 プロジェクトマネージャの役割

アジャイル開発の適用と定着を目指すのであれば、アジャイル開発プロジェクトにおけるプロジェクトマネージャの果たすべき責務について注視し、明確にしていく必要があるでしょう。アジャイル開発プロジェクトならではの観点やベストプラクティスについても共有されるべきです。

一例として、アジャイル開発では「変化ヲ抱擁」するのが当然となります。このとき、スコープ管理上の留意点やスケジュール管理上の観点が、ウォーターフォール型や非アジャイルの繰り返し型といった開発方法論を採用したときとは違ってきます。また、自動化テストによってリポジトリを常時結合可能な状態に保ち、それをバックボーンとして1～3週間という短期間でのリリースを繰り返すというアジャイル開発プロセスの中では、品質管理や統合管理における発想の転換も必要となるでしょう。人的資源やコミュニケーションの管理においては、アジャイルの持つ価値観をどのようにプロジェクトマネジメントに取り入れて仕組み化するかが問われることになります。

一方、プロジェクトマネージャと比べ、ビジネスアナリストやビジネスモデラーという役割は少し耳慣れないかもしれません。彼らはプロジェクトが扱うドメイン（業務分野）の知識と分析の専門技術を兼ね備え、顧客のビジネスに最適な業務とシステムの仕組みを描くことをミッションとしています。顧客へのヒアリングを繰り返し、業務上の「ムリ、ムダ、ムラ」をなくすことのできる業務改善プランを考え、改善策に則った上で、どこをどのようにシステム化すれば良いかを検討します（図5）。

図5 ビジネスアナリストやビジネスモデラーの役割

「そのような役割が本当に必要なのか」「対象業務の専門家である顧客と、システム開発の専門である開発者がいれば十分ではないか」という疑問を持つ方もいるでしょう。そのような方にビジネスアナリストとビジネスモデラーの有用性を説明するには、次の質問を投げかけることが一番だと思います。

「開発者が行なっている『システム開発』も業務の1つです。システム開発という業務の従事者であり、かつシステム開発の専門家でもある開発者が、システム開発業務を最適化できていますか？」

技術上の課題はさておいたとしても、改善の余地のない完璧なシステム開発組織を、筆者は見たことがありません。無理なスケジュールが横行し、無駄に混乱を招くメールが飛び交い、ムラのある品質で納品してしまうというのが、システム開発組織のよく見かける姿です。

余談になりますが、「顧客→開発者」の橋渡しはビジネスアナリストやビジネスモデラーが担うとして、「開発者→顧客」の橋渡しは開発者側の努力に大きく依存します。ビジネスアナリスト／モデラーがいる現場では、開発経験のある彼らが、その役割を代替するケースがよく見られますが、本来は個々の開発者自身が担うべき役割です。アジャイル開発では開発者に顧客への説明責任を求めていますが、うまくいっていないのが実態のように見受けられます。これについては、個々の開発者が努力するとともに、主任開発者的な役割を担う人がそれを支援／代替することも検討すべきでしょう。

個々のアジャイル開発方法論の中では、それぞれにプロジェクトマネージャやビジネスアナリスト／モデラーなどの役割を定めていることもあります。しかし、アジャイル開発の導入／適用を目指すとき、推進派となるのは受け入れ側のプログラマであることがほとんどでしょう。そのためか、アジャイル開発を推進していく中で、周囲にはプログラマがそうしたほかの活動／役割が不要、あるいは自分たちで代行可能と言っているように感じさせてしまう傾向があるようです。今改めてアジャイル開発の導入／適用を考えるのであれば、こうした役割を正当に位置付けることも必要でしょう。

アジャイル開発を導入／定着させるポイント

プロジェクトマネージャだ、ビジネスアナリストだと言っても、要は役割の問題です。システム開発を潤滑に進めるためには、どのような活動が必要か、その活動を行なう人に求められるスキルは何かを考えることが重要です（図6）。

図6 システム開発上のさまざまな役割

アジャイル開発が取り沙汰される背景に、プログラミング／プログラマ再評価の流れがあるのは確かでしょう。その流れの中でもアジャイル開発が普及しないのは、再評価の流れに大きく振れたあまり、プロジェクトマネージャやビジネスアナリストのように普通のプログラマでは担い切れないことも多いであろう重要な役割を、アジャイルではおざなりにしているように感じさせてしまったためだと筆者は考えています。そのためにアジャイルは受け入れられず、受け入れられたとしてもトラブルを招いているのです。逆にこの点を改善すれば、アジャイル開発を試してみようというプロジェクト数も、アジャイル開発の成功確率も増えるのではないでしょうか。

例えば、顧客からの要請が「ネットワーク構造のデータおよび情報を、ユーザーに理解しやすく操作しやすい形で見せたい」というものであれば、データ分析の専門家や、ユーザーインターフェイス設計のエキスパートの力を借りたくなるでしょう。同様に、数千万～数億件のデータを扱うデータウェアハウスの構築や、高度なセキュリティを担保することが必要なインターネットアプリケーションの開発など、特定技術に特化した専門家が必要なこともあるでしょう。

そういった要請は特殊なものかもしれませんが、プロジェクトマネージャやビジネスアナリスト／モデラーといった、一般的なシステム開発において必要と考えられる責務と役割については、アジャイル開発に取り入れることが必要です。もちろん、1人がプログラマとそれらの役割を兼務することもあるでしょうが、アジャイル開発導入のためには、「そうした役割が必要だってことも分かってるんだぞ」という姿勢を見せることが重要です。また、それを定着するためには、プロジェクトマネージャやビジネスアナリスト／モデラーの役割を果たしつつプロジェクトを成功させ、その実践の中からそうした役割がアジャイル開発で果たすべき責務とノウハウを蓄積することが必要だと思われます。