連載	“街づくり”で理解するシステム構築入門（2）

住居入手と比較する“システム構築の特殊性”

鈴木 雄介
2005/6/2

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

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

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

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

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

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

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

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

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

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

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

	関連記事
		【アジャイル開発：成熟期の到来、その道のり】The Rational Edge （30）（＠IT > IT Architect）
		【.NET開発者のための開発プロセス入門】（＠IT > Insider.NET）

3/3

第3回へ

index 連載：“街づくり”で理解するシステム構築入門（2） 　住居入手と比較する“システム構築の特殊性” 　 Page 1 注文建築か建売か 家具と備品が作り付けの住宅 　 Page 2 家を変えるか、ライフスタイルを変えるか 図面だけでは決められない コンピュータ利用の環境変化 Page 3 できたものを見て判断するという現実的方法 状況に応じて開発手法を選べ

この記事に対するご意見をお寄せください

managemail@atmarkit.co.jp

■要約 個人邸宅の入手方法に「注文建築」「建売」があるように、企業の業務アプリケーションに「開発」と「パッケージ」という2つの入手方法がある。注文建築に当たるのが開発、建売に相当するのがパッケージ導入だ。 ところがソフトウェアには家とは異なる特有の事情がある。それは、ユーザーが開発者に頼ることなく変更できる範囲が限られていることだ。そこで多くの場合、開発もしくはパッケージ製品を購入してカスタマイズを行うという方法を取ることになる。 パッケージでは、製品に用意されている機能を調査し、不足部分をカスタマイズで補うのか、業務変更で補うのか、よく検討する必要性がある。 開発には「ウォーターフォール」と「アジャイル」がある。ウォーターフォールは業務要件とシステム・アーキテクチャが固定的で、要求変更が少ない場合には、分かりやすい開発方法だといえる。他方、ビジネス環境の変化を受けてシステムへの仕様変更が多い場合には、アジャイルが向いているだろう。ただし、正しく導入しないと混乱を招くだけになることも考えられる。

▲記事の先頭<Page1>に戻る

profile

鈴木 雄介（すずき ゆうすけ） 東京生まれ。学習院大学経済学部卒業。 流通システム会社、マーケティングシステム会社を経て、2004年に独立。現在はフリーランスのJavaソフトウェアエンジニアとして、システムアーキテクチャ設計・開発、記事執筆などを行う。意見・感想などがあれば、ブログに書き込んでほしい。 ブログ：http://www.arclamp.jp/

「“街づくり”で理解するシステム構築入門」

■記事の「要約」がメールで読めます■ 記事の「要約」を毎週水曜日にメールでお届けしています。 下の「＠IT情報マネジメント メールマガジン」からお申し込みください。 サンプルを見る

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）