ウォーターフォール型は初期段階で全体の要件を仕様として定義し、アジャイル型は機能ごとに要件を仕様として定義し、お客の要件が固まっていなければスパイラル型になりますが、インドネシアで事前にシステムの仕様に落とし込むレベルまで要件をまとめることは難しいです。 インドネシアのビジネス インドネシア市場でのビジネスで重要な要素は価格とブランド、コネの3つと言われますが、必ずしもこれらを持ち合わせない日本人はどのように戦えばよいのか。これはインドネシアに関わり合いを持って仕事をする人にとっての共通の問題意識かと思います。 続きを見る
時代を反映するシステム開発手法
メインフレーム（汎用機）やオフコン全盛期のシステム開発はウォーターフォール型で行うのが当たり前であり、僕が1990年代に新卒で銀行系システム会社に入社した当時は、何故銀行システムの開発にウォーターフォール型が適しているかなどと考えたこともありませんでした。
ウォーターフォール型とは川の水が上流から下流に流れるように、要件定義⇒基本計画⇒詳細設計⇒プログラム開発⇒単体テスト⇒結合テスト⇒システムテストというフェーズを後戻りせずに一方通行で実施していく手法です。
システム開発手法の歴史の中で、ウォーターフォール型は日本政治史における自民党のような存在であり、2000年代に入ってからプロトタイプ型とかスパイラル型とか、反ウォーターフォール型の開発手法が提起され、紆余曲折を経た現在はアジャイル型という野党連合が結成されたという大きな流れがあります。
現在弊社がインドネシアで製造業システムを開発導入する場合の手法は、今はあまり聞かなくなったスパイラル型に最も近く、日本の情シスのプロジェクト管理の元で行う場合はウォーターフォール型で行われるケースが稀にあります。
スパイラル（螺旋）とか名前からしてヤバそうな香りしかしませんが、予想通り小さな要件定義と開発、レビューを繰り返しながら、成果の上の成果を積み上げながら少しずつ完成形を目指していくやり方です。
スパイラル型とアジャイル型の定義自体が異論各論あるため、手法的な違いを説明することに意味を感じませんが、現場で作業をする立場の意見としては、お客の要件が固まっていれば結果としてアジャイル型になり、固まっていなければスパイラル型になるという程度の違いだと考えています。
ウォーターフォール型は古い、今の時代はアジャイル型だとかいう問題ではなく、システムの特性とプロジェクトの環境に応じて手法が存在するだけであり、本来はその場に適した手法が選択されるべきなのに、現実には慣れ親しんだ手法を手放すことは難しいため、合わない手法で無理やりプロジェクトを進めてしまい、その結果現場のユーザーの意見が反映されない機能充実度の低いシステムが納品されたり、ある程度の完成度に到達した時点で時間とコストが異常にかさんでしまう、ということになりかねません。
銀行システムにウォーターフォール型が適している理由
僕は新卒入社した東京の銀行システム会社で、まさにウォーターフォール型開発の教科書みたいな企業文化の洗礼を受けました。
銀行システムは大きく分けて業務のコアとなる預金、貸出、為替送金など支える勘定系システムと、これらの取引データを元に顧客ごとの与信分析など勘定系業務に必要な情報を提供する情報系システムの2つに分かれています。
会社の組織体制は勘定系システムの開発と保守を担う開発チーム、メインフレームやオフコンのOS周りの環境整備や新機器などの導入、ネットワーク保守を行うテクニカルチーム、開発プログラムを本番反映しソースコードの履歴管理を行うライブラリーチーム、ニューヨークやロンドンなどの海外業務システムを専門に担当する海外システムチーム、PCやUNIX系システムの開発等を行う情報システムチーム、メインフレームやオフコンのバックアップや夜間保守などを行う運用チームなどで構成されていました。
PL/1、COBOL、RPG、Visual Basicなどで書かれた膨大な手書きのソースコードは、フロアの端から端まで約20mを縦断するように並べられたワードローブに、サフィックス（枝番）付きで履歴管理され、ラーメン屋の秘伝のスープのように何年も継ぎ足されるたびに機能が強化されていきました。
僕は半年間の研修後に海外システムチームに配属され、オフコン（AS/400）上で動くRPG（Report Program Generator）による海外支店向けシステム開発を担当し、その後テクニカルチームに異動し、お札の数を自動で数えるOTM（Online Tellers Machine）端末機を制御するシステムを、派遣で常駐されていた協力先さんと一緒に開発していました。
まあ開発からケーブルの配線まで、短期間にシステムに関わる仕事をいろいろと経験させてもらったのですが、当時はダウンサイジングという言葉が流行りだして、システム開発の中心はPCをベースとした分散型に移行せんとする時代で、そちらの開発を行うお隣の情報システムチームの仕事が気になっていました。
そこには当時発売されたばかりのWindows NT Workstationの前に朝から夕方まで座って、仕事しているのか遊んでいるのかよく分からない不思議な存在の長髪の先輩が居まして、その人が多機能メールソフト「Becky!」の開発者であるNさんだということを知ったのは随分後のことです。
これだけでも銀行システムの開発運用は大変だなあと当事者であった自分でも思うわけですが、巨大かつ厳しいセキュリティが要求されるシステムを、大人数で共同開発、共同管理していく手法として、ウォーターフォール型が適している理由の一つが、責任の所在が明確になることです。
ATMが止まっただの、支店から集計されてくる割引金融債の販売金額が間違っているだの、業後のバッチ処理で前日の繰り越し金額が間違ったせいで支店の業務が止まるなど（これ僕です・・・）、問題発生時に「誰が何をやったのが原因」というのが明確になります。
また開発システムの本番反映予定日を目標にして、工程別に後引きで全体スケジュールを立てて、慎重にテストを重ねて本番反映し、万が一障害が発生しても迅速なソースコードの分析が行える管理体制をとることで絶対的な信頼性を維持するために必要であり、そのために開発現場ではウォーターフォール型が最も適していたわけです。
要件定義が出来ないとスパイラル型にならざるを得ない
ウォーターフォール型はプロジェクトの初期段階で全体の要件を仕様として定義し、アジャイル型は機能ごとに要件を仕様として定義しますが、いずれにせよ顧客側での要件のとりまとめが終わっていることが前提です。
インドネシアの製造業で顧客側で要件のとりまとめができるのは、社内に情シスがある大企業のみであり、通常業務と合わせてシステム開発プロジェクトのリーダに任命された担当者が、システムの仕様に落とし込むレベルで要件をまとめることは不可能だと思います。
初期段階で要件のとりまとめがきっちりできて、エンドユーザーが従順であれば分担作業で責任の所在が明確になり、大人数で進めるプロジェクトでウォーターフォール型を採用するのはありだと思いますが、大体の現場は真逆の状況であり、導入支援する側からしても幅広い経験を多く積みたいインドネシア人エンジニアにとっては物足く感じると思います。
要件のとりまとめができないので、弊社のようなSI業者が担当者から要件を聞き出しながらプロトタイプを作成しレビューを繰り返すわけですが、プロジェクトが進みシステムの形が具体化されていく過程で「やっぱりこうしたい」という要件変更が普通に発生します。
このとき相手側の突発的な要求に感情的になることなくじっと耳を傾け、繰り返される仕様変更のせいで発生するエラーについて苦情を言われることに理不尽さを感じながらも根気強くバグを潰し、あくまで良好な関係を維持しながら、必ず訪れる絶妙のタイミングで「わかりました。ではこの新要件を実装したところで一旦検収お願いしますね」と線引きします。
要件がまとまっていなければ仕様変更が発生することは事前に予測できることであり、そんなプロジェクトを引き受けた以上は引くところは引きながらも、あるレベルで切っていかないと、発生するコストは永遠に自腹になります。
ある程度大きな予算が付く規模の大きい顧客の場合、コーディング以外の作業工数が膨れがちなウォーターフォール型やアジャイル型でも問題ないと思いますが、限られた予算内で見切り発車気味にプロジェクトが始まる中小規模の顧客の場合、作業工数に占めるコーディングの比率が高くなることが予想される以上、それ以外の仕様書の作成やテストなどの工数を減らし、全体のコストバランスを維持することが重要になります。