アジャイル開発が導入される条件とは何か

アジャイル開発に本気で取り組まなくてはならない理由

「アジャイル開発」というキーワードは、そろそろ旬を過ぎているかもしれません。1999年ごろから「XP（eXtreme Programming）」をはじめとして、さまざまな開発方法論／プロセスが打ち出され、多くの開発者の心をつかんできました。しかし、日本国内においては、いくつかの事例をちらほら見かけるものの、開発の現場で主流を占めるとは到底言えない状況です。アジャイル開発は、しょせんは実用が困難な「絵に描いた餅」だったのでしょうか？

ですが、アジャイル開発の目指す「変化への対応」は、今の、そしてこれからのシステム開発にとって、いよいよ重要な要件になってきます。ビジネス環境の変化する速度に、システム開発の速度がついていけなくてはならないからです（図1）。このニーズは、ビジネス環境の変化する速度が速まっていくことと、システムがビジネス遂行上に占める重要性が高まっていくことにより、ますます無視できないものになっていくと予想されます。

図1 ビジネスの変化とシステムの対応速度

であれば、システム開発を生業とする私たちは、いかにしてその要請に応えていくかを考えなければなりません。反対勢力は多様で堅固ですが、今改めてアジャイル開発を考え直してみる意味はこの一点にあると言えるでしょう。

アジャイル開発を受け入れた理由／受け入れられない理由

日本国内において、アジャイル開発を受け入れたのは、あえて「末端の」と言ってもいいかもしれない現場の開発者たちです。一方、アジャイル開発を受け入れなかったのは、顧客やシステム管理者たちです。

ここでは、アジャイル開発を受け入れた者と受け入れられない者がいる理由を考えることで、この先どのようにアジャイル開発を進歩させていき、どうやって現場で適用していくかを見出す手がかりとしたいと思います。

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

アジャイル開発に分類される開発方法論の中で、最初に広く知られるようになったのはXPでした。XPは、開発者が重んじるべき「4 つの価値」と、価値を追及するための「12のプラクティス」（後に追加され19 以上とも）からなる方法論です。価値の1 つとして「コミュニケーション」が含まれていたり、プラクティスの1 つとして「週40 時間（持続可能なペース）」が挙げられていたりと、システム開発を行なう「人間」にフォーカスされている点がXPの特徴と言えるでしょう。ワインバーグやデ・マルコが繰り返し指摘してきたように、システム開発を改善するためには、その活動の主役である開発者に注目する必要があります。さらにXPは、その名称からも分かるとおり、開発者の中でも特に「プログラマ」に注目しています。ここがポイントでした。

日本におけるプログラマを取り巻く環境は、決して良好なものとは言えません（図2）。日本特有と言われる、元請け→下請け→孫請け......と連なるシステム開発業界のゼネコン的構造の中では、商流の下流を受け持つ中小の受託業者が、開発工程の下流であるプログラミングを受け持つことになっています。また、「プログラマ」→「SE（SystemsEngineer）」→「プロジェクトマネージャ」の順で昇進／昇格するという職制上の枠組みが、大手SI業者の社内職制を反映する形でIT業界全体に浸透しています。

図2 日本におけるプログラマの位置付け

さらに、「お金を払う側が偉い（お客様は神様です）」という商業上の観念が日本には根強く残っています。筆者は、ビジネス上の取引とは貨幣と貨幣以外のものの等価交換であり、貨幣を提供する側が一方的に上の立場に立つというのはおかしいと考えていますが、お客様を神様と考える人が多いことは事実です。そして、プログラミングはお金をもらう立場にある受託業者が行なっており、プログラマは社内的にも低い地位にあります。結果として、「プログラミングは、システム開発にかかわる活動の中で、最も下等なものである」「プログラマは、システム開発にかかわる職業の中で、最も下等なものである」という認識が、IT業界全体に定着して しまいました。

このような構造と認識は、「ずっとプログラミングしていたい。もっとすごいプログラミングができるようになりたい」と考えるプログラマにとっては、その枠組みの上でキャリアパスが描けないという悩みにつながっています。下請けや孫請けを主に行なっている会社のプログラマにとっては、こうした構造と認識が強いストレスになることは言うまでもありません。

アジャイル開発が「末端」の開発者、つまりプログラマに受け入れられた理由は、アジャイル開発がプログラマやプログラミングの重要性と価値を再評価させるきっかけになると期待したからだと、筆者は考えています。XPの流行と機を一にして、『達人プログラマ』（注1）や『ソフトウェア職人気質』（注2）といった書籍が話題になったのも、この流れに沿うものでしょう。

アジャイル開発の受け入れは妥当か

さて、そのようなアジャイル開発の導入やプログラマ／プログラミングの再評価も、システム開発全体から見て妥当なものでなければ、プログラマ以外の人には決して受け入れられないでしょう。しかし、コンピュータ資源の発達や環境の変化が、アジャイル開発導入に追い風となっているようには思えます。

コンピュータシステムの黎明期、中央に1台しかないコンピュータは利用時間が割り当てられ、コンパイルやテストなどのコンピュータ上でなくてはできない作業にだけ使われました。開発者がプログラムを入力しながらアルゴリズムを考えるような贅沢（！）な使い方は許されなかったのです。

現在では、どこでも開発者ごとにコンピュータが割り当てられていると思います。それにより、開発者はわざわざ詳細設計をドキュメント化しなくても、頭の中だけでアルゴリズムを考えて直接プログラムを入力し実行してみる、いわばトライ＆エラーによる開発が可能になったわけです。

もし、現在でも詳細設計書が必要なケースがあるとすれば、特定のプログラミング言語で書かれたプログラムを検証できる人材が不足しており、かつ特定の言語に依存しない擬似コードで詳細設計を記述し、検証することが必要な状況に限られるでしょう。つまり、第三者による検証可能な詳細設計書が求められる場合だけです。システムの特性により、そこまで厳重な検証が必要なケースがあるかもしれませんが、その場合でも、ソースコードをきちんとレビューできる人がいれば十分なはずです。可読性の高い高級言語の普及がそれを後押ししており、詳細設計書の重要性はますます低くなってきています（注3）。

また、オブジェクト指向プログラミング言語や DI（依存性の注入）、 AOP（アスペクト指向プログラミング）など、言語レベルでモジュール分割とその結合を行なう手段も増えてきました。これにより、プログラミングと、モジュール分割という設計作業とが密接になってきています。設計がプログラミングに吸収されてきているとも考えられます。

さらに、現場のプログラマが担っている仕事をすべて「プログラミング」と呼ぶのであれば、プログラミングという活動は非常に広範なものとなります。メモリ効率やパフォーマンスを考慮に入れたモジュール内部のアルゴリズムを決定するのは、まさにプログラミングの根幹です。デバッグはもちろんのこと、たいていの場合は単体テスト、場合によってはシステムテストの実施までもがプログラマの仕事です。プロジェクトによっては、IDE（統合開発環境）を利用し、画面プロトタイプ を作成しながら画面設計を行なうこともあります。この作業などは、本来、要件定義に位置付けられることの多い活動でしょう。

結局、「プログラムを作成すること」に結び付く仕事は、すべてプログラミングに含まれてしまうのかもしれません。プログラムの作成に際して渡されるもの（詳細な擬似コードや、画面定義書などの設計書、あるいは曖昧だが重要な示唆に富んだ顧客の発言など）により、仕事の範囲は変わってきますが、プログラマが長けている技術やツールを積極的に活用することの有用性から、その範囲はますます広がる傾向にあります（図3）。

図3 「プログラミング」の範囲

このように広範な活動を行なっているわけですから、プログラミング／プログラマに対する評価が先述のとおり低いものだとすれば、その評価をもっと高くし、システム開発の中心的活動／役割として位置付け直すべきです。アジャイル開発の導入は、プログラマの心理的要因だけでなくコンピュータ資源や環境の変化から見ても、妥当なものだと言えるのではないでしょうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アジャイルでもドキュメントは重要

アジャイル開発にまつわる誤解として、「アジャイル開発ではドキュメントを書かない」というものもあります。もし、仮に（あり得ないでしょうが）あなたが採用しようとしている方法論が、「ドキュメントなど一切書くな！すべてはソースコードが語ってくれる！」と説いているとしたら、そんなことは無視して、プロジェクトに必要なドキュメントは何かを真剣に考えてください。アジャイル開発が戒めているのは、手続きや形式の上で必要なドキュメントを実際に動くプログラム以上に重視することや、ドキュメントが膨大で修正手続きも煩雑になり、システムの変更に追随できなくなることだけです。アジャイル開発においても、必要なドキュメントはやはり必要なのです。問題はどう書くかにあります（図 7）。

図7 各種ドキュメントの内容と注意点

ドキュメントを書く目的は、読み手に対象システムを理解してもらうこと以外にありません。そのため、ドキュメントの構成を考える際は、どのような読者がどのような目的でシステムを理解したいと思うかに配慮することが必要です。例えば、設計の誤りを見つけ出すレビューや、改修や機能追加を行なう保守などの場面でドキュメントが必要となるでしょう。いずれの場面でもドキュメントによって対象物の理解を深めることが重要となり、ドキュメントの出来が作業に大きく影響します。

レビューでは、特に複雑な箇所を詳細に検証したいでしょうから、ドキュメントは複雑な箇所に重点を置いて書きます。複雑なロジックを持つモジュールと、名前を見れば内容が自明になるようなモジュールを、同じ粒度／詳細度で書く意味はまったくありません。また、システムの外部仕様や、その元となるビジネスルールの理解についてのレビューが必要となることもあるでしょうが、アジャイル開発では、そうしたレビューは短いサイクルで行なわれる実システムでの検証によって代替されます。実際にプログラムを組む前に、口頭で行なう理解内容の確認の補足資料を作る程度でまかなえることがほとんどでしょう。

また、将来保守や改修を行なう、あるいは途中からプロジェクトに参加するメンバーは、システムの全体像を理解することから始めますが、最終的には手を入れるべきソースコードを読みます。ドキュメントですべてを説明しなくても、ソースコードを読んでみて初めて細かいところが分かるという形 で良いのです。今は開発ツールが、ソースコードのブラウズを助けてくれます。

それに、アジャイル開発であれば、自動テストのテストケースがモジュールの仕様を最もよく表わしているでしょうから、テストケースと別にモジュール仕様書を書く必要は少ないと思います。個別のメソッドを見ても分かりづらい複雑な状態遷移などは、別に ドキュメントを起こす価値があるかもしれません。

保守などの場面では、ソースコードを読み込めば分かる詳細よりも、システムが実現している業務／ビジネス上の価値を理解することや、システム全体の構成やサブシステム／モジュールの役割分担をざっくりつかむことができる「システムの詳細にたどり着くための地図」のほうが、何よりの助けになります。そうしたドキュメントは、大部になることも少ないですから、手間と見返りを考えても積極的に書く価値があると思われます。

また、そのような概要資料には、網羅性があります。網羅性を何より重視する人がいますが、詳細なドキュメントで網羅性を保とうというのは愚かしい試みです。抜けや漏れがないことを防ぐ必要はありますが、ドキュメントでは大きな粒度で抜け／漏れを防ぎ、後はいずれにせよ網羅性を持たねばならないソースコードとテストケースで確認していけば良いでしょう。

逆に、詳細に見ていけばいくほど、「あれ？どうしてここはこんな風になっているんだろう？」という疑問が生じることがよくあります。詳細だけを見ていては分からない、もっと大きな粒度での設計判断かもしれませんし、実装上の制約回避のためのクイックハック（注4）かもしれません。クイックハックを行なうことの是非はさておき、どうしてそのような設計上／実装上の判断が下されたのかを知ることが、改修や機能追加を行なう上では大変重要になります。そうしたポイントについては、設計資料やソースコード中のコメントとしてでも、確実に残していくことが必要でしょう。

そうした各種のドキュメントをいつ書くかというのも問題になります。官僚的な進め方をするのであれば、工程ごとに成果物を定め、成果物の完成をもって工程の完了とし次工程に進むということになりますが、変化し続けるシステムを扱っている以上、完成ということはありません。システムとともにドキュメントも常に改修され続けることになり、結構なコストになります。

であれば、システム概要などの重要な資料については、メンテナンスし続けることが可能な程度にボリュームを抑えつつ作成し、そうでないものは適宜メモとして残しておいて（注5）、開発の大きな区切り目にまとめて文書化するのが得策と言えます。

どのようなドキュメントが必要で、どのように更新していくかは、プロジェクトの体制と扱うシステムの特性によって異なります。さらに、そのシステムの特性も、どんどん変化していきます。プロジェクトで公式に作成するドキュメントについては、メンバー間で議論した上で、作るべきものを決定していくのが良いでしょう。

おわりに

システム開発におけるアジリティ（agility：俊敏性、機敏さ）の獲得は、顧客にとっても開発者にとっても急務であることは間違いありません。しかし、現場におけるアジャイル開発の適用状況を見るに、その必要性とは相変わらず大きなギャップがあるように見えます。

アジャイル開発の適用とは、大仰に言えば、システム開発を行なう組織を「管理者の命令によって動く制御型組織から、現場での判断に基づいて動く自律型組織」へ変革することにほかなりません。その実現には、個々人の働き方や価値観を大きく変えることになります。権限の委譲が求められる管理者層や、指示に従う慣習が染み付いた現場から抵抗があって当然です。どのようにして、そうした抵抗感を取り除いていくかが大変重要になってきます。また、急激な変化を起こそうとすれば、慣れないやり方を押し付けることとなり、慣れないが故のミスやリスクの見落としなど、トラブルを引き起こすこともあります。

アジャイル宣言のうたう価値と原則は、システム開発とシステムを利用するビジネスにとって大きな意味を持っています。ただ、それらはまだ効果がうまく出ていないように思われてなりません。本稿に述べたこと以外にも、大規模チームや分散開発への適用可能性、契約面での課題など、論点はまだまだ残っていますし、個々の論点についても、もっと掘り下げて考える必要があります。

しかし、本稿がアジャイル開発の導入をあきらめていた方々がもう一度挑戦してみようと考え直すきっかけとなり、それによってもっと多くの事例が生まれ、日本の環境特有のさまざまなプラクティスが導き出されることにつながれば、筆者にとっては望外の幸せです。