住居入手と比較する“システム構築の特殊性”：“街づくり”で理解するシステム構築入門（2）（3/3 ページ）

[鈴木 雄介，＠IT]

できたものを見て判断するという現実的方法

　ここ数年、一部の案件でアジャイルの有効性が証明され、注目を集めるようになってきた。システム工学が少しは進歩したことも理由だが、そもそも思想的な変化が大きい。簡単にいえば、「本当に必要・有用なものかどうかは、作ってみなければ分からない。それには少しずつ作ってみて、それを評価するしかない」ということだ。

　ユーザー（システム発注者）にとってみれば、少しずつでも具体的に実際のソフトウェアを見ることができるので、評価を行いやすい。小さいレベルでの欠陥であれば、すぐに修正対応できることもあるだろう。また、ビジネスが変化した場合も、開発順序などを柔軟に変化させることができる。

　しかし注意しなくてはいけないのは、これが非常に大きな転換だということだ。ユーザーが、この現実を受け入れるには勇気が要る。この開発プロセスを導入しながら正しく運用できなければ、最悪の場合、作ったものをすべて捨てて、またゼロから作り直さなくてはならなくなり、コストや期間に深刻な影響を与えることになる。アジャイルでなければうまくいかないと担当者が頭で理解できても、社内でこのやり方に合意を求めるのは大変だろう。ユーザー（仕様決定者）に求められる役割やプロジェクトへのかかわり方は大きく変化するし、評価や優先順位の決断を素早く、連続的に行っていく必要がある。社内調整に時間がかかっていてはアジャイルにはならない。アジャイルは、決断するタイミングを遅らせることはできるが、決断を長引かせることができるわけではないのである。

　一方、開発者には、小さく評価しやすいものを継続的に開発することが求められる。こういった手法は、まだまだ一般的ではないため、知識はもちろん、それなりの技術スキルが必要となるだろう。

状況に応じて開発手法を選べ

　ここまで、企業アプリケーションを手に入れるいくつかの方法を紹介した。最初に述べたとおり、企業の状況によって、どれが最適であるかは一概にいえない。

　ウォーターフォールが旧来の手法だからといって、“ダメだ”というわけではない。開発者とユーザー双方が早い段階で業務／システムの仕様に合意・納得することができ、システム・アーキテクチャが固定的で、開発期間中に要求の変更が頻繁にないのであれば、計画の見通しが立ちやすく、分かりやすい開発方法だといえる。ただ、こうした条件に合うプロジェクトは多くはないというのも事実である。

　一方、アジャイルは優れた開発手法だが、ユーザー企業の文化や開発者のスキルによっては、混乱を招くだけになることも考えられる。アジャイルは、ユーザーと開発者が協力し、密接にコミュニケーションを取る必要性があるため、「一方的に発注するだけ」「いわれたものを作るだけ」では、やみくもに導入しても絶対にうまくいかない。

　いずれにせよ家の入手方法がいろいろあるように、システムの入手方法も選択肢が広がっているのは良いことだ。どの開発手法を選択するか、あるいはどのパッケージ製品を選ぶかは、それら自体の進化や機能強化の具合を見極めながら、同時に自社のビジネスや業務のどこが不変で、どこが変化する可能性が高いのかを考慮して判断することになるだろう。

　次回は、いよいよ街づくりというメタファを用いて、企業全体というより大きな視点から見たシステム開発について述べていく。