基幹系の大規模システムを1年で作れ!
システム構築に許された時間はどんどん短くなっている。
過去の方法論を引きずっていては、経営が要求するスピードは達成できない。
要件定義から設計、開発、テストに至る全工程で、過去の常識を捨て去るときがやってきた。
サントリー、ガリバー、清水建設など、50社以上の証言をもとに、超高速開発への道を探る。

(システム構造問題取材班=戸川 尚樹、高下 義弘、矢口 竜太郎、星野 友彦)

Part1 決別:ウォータフォールの呪縛を断ち切れ
Part2 処方:割り切りと繰り返しがスピード向上のカギ
Part3 手法:超高速開発を実現「アジャイル」の全貌

こちらで「Part3 『アジャイル』の全貌」の全文をお読み頂けます

シリーズ特集 第1弾「【コスト編】不良IT資産を洗い出せ」のページはこちら


本記事は日経コンピュータ2002年10月21日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。なお本号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。


Part.1 決別
ウォータフォールの呪縛を断ち切れ

基幹系の大規模システムはウォータフォールでしか作れない――。こうした“常識”を捨て去るときがやってきた。企業経営のスピードはますます速まり、これまで以上の短期開発を情報システム部門に迫っている。半年先のビジネス環境さえ見えない今、仕様変更に対する柔軟性に欠け、完成までに2~3年かかるウォータフォール型のシステム構築スタイルは早晩、壁にぶつかる。ウォータフォールとの“決別”をいち早く宣言したサントリーとガリバーインターナショナルの挑戦をレポートする。

 なぜ今さらウォータフォールの是非を議論するのか――。こう思う向きも少なくないだろう。確かにウォータフォールの欠点は10年以上前から指摘され続けてきた。左に引用した1990年発行の事典にも、「柔軟性に欠ける」と明記されている。

 だが、現実を見わたすと、ウインストン・ロイス氏が1970年に提唱したとされるウォータフォール型のシステム構築スタイルは、今でも幅を利かしている。構築するシステムの規模が大きくなり、参加するエンジニアが増えれば増えるほど、「要件定義-設計-開発-テスト」の各工程ごとに成果物をチェックしながら進むウォータフォール型は威力を発揮するからだ。この長所の前に、仕様変更などの柔軟性に欠けるといった弱点は容認されてきた。

 ウォータフォールの欠点克服を目指す動きはこれまでもあった。しかしウォータフォールに完全に取って代わるまでには至っていない。

 例えば、1990年半ばに一大ブームを巻き起こしたRAD(高速アプリケーション開発)。「ユーザー部門を巻き込んだ少人数チームが全工程を一貫して担当することで、システム構築期間を3分の1に短縮できる」と期待を集めたが、大規模システムへの適用は思いのほか進まなかった。規模が大きくなると、ユーザー部門に要件を確認する作業に追われ、高速開発どころではなくなってしまうからだ。結局、大規模システムの多くは、今でもウォータフォール型で構築されている。

 しかし、さすがに限界だ。ビジネスを取り巻く環境が数カ月単位で変わる時代に、仕様の「漏れ」や「追加」、「変更」を罪悪視するウォータフォールの“常識”にとらわれていては、経営の要求を満たせない。数年がかりでシステムを作っているようでは、いつまでたってもITは「経営の道具」になり得ない。

 このことにいち早く気付き、ウォータフォールとの決別を宣言した企業も登場し始めた。

■サントリーの決断---ソフト部品の全面採用がきっかけ

 情報化先進企業とされるサントリー。1990年からCIO(最高情報責任者)を務める酒井朋久常務情報システム事業部長の指揮の下、「使う側の立場にたったシステム作り」を続けてきた。

 システム構築期間の短縮に取り組むのも早かった。1989年には米マスト・ソフトウエア・インターナショナルの第4世代言語「NOMAD」を自ら“輸入”して、プログラム開発の生産性をCOBOLの4~5倍に高めた。95年5月には社内のシステム構築標準にRADを全面採用し、さらなる生産性の向上を目指した。そのころ動き出した料飲店向け販売支援システムを例にとると、COBOL換算で60万ステップ以上のシステムを通常の3分の1の6カ月で作った。

 サントリーは90年代、多角化に積極的に取り組み、新規事業への参入や(企業の合併・買収 M&A)を続けてきた。情報システム部門も「NOMADの導入やRADの採用といった工夫を重ね、ユーザー部門から次々と寄せられるシステム化要求を可能な限り迅速にこなしてきた」。情報システム事業部の山内雄彦情報システム部課長は、これまでの取り組みをこう評価する。

仕様固めはウォータフォールと同じ

 だが、サントリーを取り巻く経営環境は、システム構築期間のいっそうの短縮を求めている。来年9月の酒類販売免許自由化を控え、酒類メーカー各社は熾烈な競争を繰り広げている。サントリーもここ数年、新商品を数カ月単位で投入したり、商品の販売戦略をこまめに見直している。システム構築に許される時間は短くなる一方だ。

 これに対して、システム部門のメンバーは危機感を抱いた。RADによるシステム構築スタイルには限界が見えつつあった。「経営スピードがさらに加速するのを見越して、システム構築のギアを上げるには、新しいスタイルに切り替えるしかない」。1999年ごろから、こうした声がシステム部門内でわき上がった。

 サントリーの場合、RADを使っていても、システム構築の最初の段階で要件定義を終えなければいけない点は、ウォータフォールと同じだった。システムの目的や方向性を明確にせずに、RADで要件を決めようとしても、まずうまくいかない。要件を固めた後は、その仕様をきっちり満たすことを目標に設計、開発、テストを順番に進めるしかない。

 「そうした意味では、当社のシステム構築スタイルは、本質的にはウォータフォールそのものだった」と山内課長も認める。さらに「当時は基本的にウォータフォールで進めるしかなかった」と前置きをした上で、「ウォータフォールにこだわっていては、経営が求める柔軟性を確保できない」と断言する。

 さらにNOMADによる生産性の向上にも陰りが見えてきた。サントリーはプログラム・モジュールの再利用に挑戦してきたが、第4世代言語のNOMADでは「しょせん既存のプログラムの“流用”で終わっていた」(山内課長)。

 折しもシステム部門の技術調査チームが、Javaの採用を前提にした新しい開発手法を研究していた。その研究成果も踏まえて、サントリーはウォータフォールとはまったく別のシステム構築スタイルを2000年から導入し始めた。

「70点のシステム」でリリース

 サントリーの新スタイルの特徴は、「優先度の高い機能に絞って先行開発し、できたものから早期にリリースする」(山内課長)という方針を明確にしたことだ。具体的には、ユーザー部門から上がってきた要件のうち、ビジネス上の優先度が高い「70点分」を満たすシステムを3カ月で作り、ユーザーに渡す。

 残り「30点分」や構築を始めてから追加された要件は、必要に応じて順次システムに盛り込む。開発言語にはオブジェクト指向言語のJavaを使う。作成したプログラム・モジュールの再利用や変更が容易になるので、追加開発の効率が上がる。サントリーは生産性をさらに高めるため、Javaによるソフト部品群の整備も進めている。

 システム構築の過程では、要件定義から設計、開発、テストに至る工程を何度も繰り返すことになる。システムの部分部分を何回にもわたってリリースし、段階的にシステム全体を構築していく。

 こうした繰り返し型の構築スタイルを採ることで、「その時々の要件を取り入れつつ、大規模なシステムを構築できる」と山内課長は強調する。「リリースのたびに、何度も要件を検証するので、重要な要件を見落とすといった問題を早期に発見・解決できるメリットもある」。

 新スタイルに基づくシステムの第1弾は、あと数カ月で動き出す。山内課長は「現時点ではまだ評価は下せない」としながらも、「新しい構築スタイルの成果は確実に出るだろう」と自信をのぞかせる。


続きは日経コンピュータ2002年10月21日号をお読み下さい。この号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。




 「システムの短期開発に近道なし」。今回の取材を通して探り当てた真実をひとことで表せ、と言われれば、この言葉を選ぶでしょう。

 「短期にシステムを構築したいのであれば、とにかく開発すべき機能を絞り込むことだ」。元・日立製作所 システム開発研究所の研究員で、現在コンサルティング会社ストック・リサーチ取締役の大槻 繁氏はこう話します。開発すべき機能は、要件を必要最低限のものに絞り込んだり、パッケージやソフト部品を使うことで少なくできます。結局、「システム開発は必要なところに必要な力を注ぐしか道はない」(同)のです。

 成る程、いままで「短期開発に成功した」と言われるプロジェクトはECサイト関係が多いですが、言い換えると「『人が死なないシステム』で要領よく機能と品質を落とし、突貫工事で済ませた」ということでしょう。「複雑な実社会を落とし込むシステム開発で、そんなに都合良く生産性が上がるような道具や方法は存在しない」(大槻氏)。

 「エクストリーム・プログラミング(XP)」や「Scrum」など、短期構築を狙った開発手法群「アジャイル開発手法」が話題を呼んでいます(http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20021015/2/をご参照下さい)。開発する機能を絞り込み、ときどきのユーザーの要望を取り入れながら繰り返し作っていくアジャイル開発プロセスは、行き着くべくして行き着いた時代の流れなのでしょう。

 なおアジャイル開発手法では、「生命にかかわるシステム」は適用対象外としています。(高下)