アジャイル開発が導入される条件とは何か
|
開発対象システムの複雑化、短納期など、開発をめぐる環境は日増しに厳しくなる一方です。そうした現場を改善するために、変更に強く、品質や効率の高い開発を目指して考え出されたアジャイル開発でしたが、実際のプロジェクトで導入されたケースは日本国内においては決して多くありません。今回はアジャイル開発をテーマに、なぜ普及が遅いのか、なぜ導入に反対する者がいるのか、またどうしたら賛成を得られるのかといった現状と課題を考えます。
アジャイル開発に本気で取り組まなくてはならない理由
「アジャイル開発」というキーワードは、そろそろ旬を過ぎているかもしれません。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）デビッド・トーマス、アンドリュー・ハント著／長瀬嘉秀、テクノロジックアート訳／アスキー刊／ 2005 年3 月発行／ISBN4-7561-4599-X
（注2）ピート・マクブリーン著／村上雅章訳／ピアソン・エデュケーション刊／2002年3月発行／ISBN4-89471-441-8
（注3）重要性が低くなっているのは、あくまでも「詳細設計書」というドキュメントであり、「詳細設計」という活動ではありません。