富士通ソフトウェアテクノロジーズが7年続けたウオーターフォールを辞めた理由：「ウオーターフォールはまるで遠洋漁業」

7年に渡ってウオーターフォール型で開発してきたプロジェクトでアジャイルを採用した富士通ソフトウェアテクノロジーズ。成功を収めたポイントはどこにあったのだろうか。

[高橋睦美，＠IT]

　アジャイル開発にはさまざまな利点がありそうだと感じながらも、ウオーターフォールによる今までのやり方を切り替えるとなるとなかなか難しい――そんな「目に見えないハードル」を感じ、二の足を踏んでいる企業は少なくないだろう。2019年7月に開催された「Agile Japan 2019」ではその変化に挑戦し、成果を収めつつある富士通ラーニングメディアと富士通ソフトウェアテクノロジーズの事例「今日からアジャイルで開発します！〜アジャイル開発人材育成のポイントと7年間続いたWaterFall型受託開発をAgileに転換した事例をご紹介〜」が紹介された。

開発側ファーストから、利用者ファーストへ

　世の中の在り方、そしてITの在り方が大きく変わる中、ビジネスのデジタル化に取り組む企業が増えている。過去の物作りは「きっとこんなものが必要だろう」とモノを提供する側、開発する側が考えたものを作り、提供する「開発ファースト」といえるものだった。だが、これからは「利用者が必要なもの」を提供しなければならない「利用者ファースト」の時代だ。ベンダーやSIerにも時代に即した開発スタイルへの変革が求められている。

富士通ラーニングメディアの森近佑次氏

　そんなデジタルビジネス時代に求められる人材とは何か？　そんな観点からアジャイル開発を実践できる人材の育成に取り組み、既に1000人ほどのアジャイル人材を育てている富士通ラーニングメディア。同社の森近佑次氏（第一ラーニングサービス部）は「市場ニーズの変化の速さには、ウオーターフォール型開発が合わないこともある。『動くサービス』を小さく作り、育て、継続的に改善できる実践的な人材が求められている」とアジャイル開発が求められる背景を説明した。

アジャイル開発に必要な要素とは

　では、アジャイル開発を進めるにはどのような要素が必要だろうか。まずは、スクラムをはじめとする手法（開発プロセスやベストプラクティス）が必要だ。加えて、ツールを活用し、実際にコーディングやリファクタリングができるスキルも不可欠となる。そして何より、「文化」を築いていくことが重要だと森近氏は述べた。

　「アジャイルは単なる知識ではない。マインドや振る舞いをどう形作っていくかが重要だ」（森近氏）

アジャイル型人材に必要な要素（出典：富士通ラーニングメディア）

　人材育成や研修を通してアジャイルを推進してきた富士通ラーニングメディア。そうした中で、森近氏がよく相談を受けたのは「ユーザーと開発者の距離感をどう縮めればよいか」だ。ユーザー側は「ベンダーは一緒にビジネスを考えてくれない」と不満を抱く一方、ベンダーも「顧客が協力してくれない」という具合に、どちらの側も不満を抱くことが多いという。森近氏は「それぞれの立場で考えるよりもさらに距離を縮めることが必要」という。

「よりニーズに応えられる」から選択したアジャイル開発

　「距離を縮める」と言葉で言うのは簡単だが、実際にはどのようにすればいいのだろうか。続いて登壇した富士通ソフトウェアテクノロジーズ（FST）IoTテクノロジーサービス部マネジャーの内田済氏が、とあるWeb会議システムの開発スタイルを、7年間続けてきたウオーターフォールからアジャイルに変え、ベンダーと顧客の距離を縮めた実践例を紹介した。

富士通ソフトウェアテクノロジーズの内田 済氏

　このWeb会議システムは、顧客の社内システムということもあり、さまざまな部署から多様な要求が寄せられていた。このため頻繁に仕様変更がある上、担当者が細かなデザインにまでこだわりを持っていたという。いったん要件が固まり、ようやく開発チームが作業に着手しても、新たな仕様変更が加わるといった状態になり、特に開発現場が振り回されることが多かった。一方で顧客側も、エンドユーザーの要望にどんどん応えていきたいのに開発チームに待たされがちで「サービス実装までのリードタイムが長い」という不満があったという。

「サービス実装までのリードタイムが長い」という不満があった従来の開発（出典：富士通ソフトウェアテクノロジーズ）

　こうした中、顧客社内でアジャイル化の取り組みが始まった。その流れを受けてこのWeb会議システムのプロジェクトにもアジャイル開発を導入することになった。FSTも以前からアジャイル開発に力を入れており、「アジャイル化した方が、よりニーズに応えられる」と思い切って実現に踏み切ったそうだ。

成功の秘訣（ひけつ）は「ギャップ分析」

　とはいえ、プロジェクト担当者のほとんどはアジャイル開発の経験がない。加えて、FSTがあるのは静岡、顧客がいるのは東京と物理的に距離が離れている。そんな中でうまく進められるのか、開発費や契約はどうすればいいのか……、不安要素は多々あったという。

　内田氏らは、まずギャップ分析と目的の共有を行った。ヒアリングを通じて、顧客との「溝」は何かを踏まえた上で、プロセスや役割分担、管理調整のルールなどを作り、互いに合意していった。

ギャップ分析を実施し、顧客との「溝」をどう埋めるかを調整（出典：富士通ソフトウェアテクノロジーズ）

　「溝の部分を分析することで『そもそも何のためにやるのか』を明確にできたし、細かなルールを詰めていくことで、双方の納得度が高まった」（内田氏）

　こうして開始当初は半信半疑だったアジャイル開発だが、確実に成果を生み始めているという。

　まずリリースサイクルが高速化し、以前は四半期に1回だった新機能のリリースが、月に1回のペースで行えるようになった。開発（実装）と検証をそれぞれ2週間のスプリントで回すことで、品質を満たしながら、以前よりも迅速なリリースを実現しているという。それでいて「残業時間も削減でき、以前は月平均で50時間ほどあった残業時間は、今は平均20時間、ピーク時でも25時間程度になっている」（内田氏）

　マネジメントを行う内田氏自身にもメリットがあった。

　「以前は1つ1つの案件ごとに提案と見積もり、価格交渉と発注処理を行っていて、この作業のためだけに多くの時間を割いていた。それがアジャイル開発では、開発に張り付ける体制と期間で価格が決まるため、そうした作業に要する時間が圧倒的に減った」（内田氏）

　開発プロジェクト自体のかじ取り役は必要だが、案件管理業務を担うという意味での「マネジャー役はいらないといってもいい」と内田氏は語る。

　顧客にとってはリードタイムの削減と負荷軽減、コストの削減といったメリットが得られたし、開発者も無駄な作業をしなくて済む。受注は安定し、先が見通せるため開発者自身の成長にもつながる、などさまざまな効果が得られた。内田氏はこの取り組みを通じて「顧客にとってのメリットがあることが成功の鍵だと思うし、アジャイル化を通じて、顧客と開発者がともに進んでいく関係性ができたと思う」と振り返った。

アジャイルは「顧客とベンダーが同じ船に乗って漁に出掛ける」こと

　内田氏は「以前のウオーターフォール型の開発は、まるで遠洋漁業のようでした」と語る。開発者は営業やマネジャーが顧客と調整した最終結果をいきなり渡される。「陸揚げされて、はじめてどんな魚かを知った直後に調理法を考えるようなものだから、開発現場は大混乱だった」（内田氏）

従来の開発は目的が分からないオーダーで開発していたようなもの（出典：富士通ソフトウェアテクノロジーズ）

　これに対しアジャイルでは、顧客と開発者が一緒の船に乗って、どの魚を捕るのかを一緒に考える。

　「何を、何のためにやるのかが分かるので、顧客との距離を非常に近く感じるようになった」（内田氏）

　副産物として、これまで「個人スキル」に頼りがちだった開発作業が、チームとしてどこまで達成しているか、全体の進捗（しんちょく）を気にするようになったのも変化の1つだそうだ。

　とはいえ、アジャイル開発は決して「魔法」ではない。スプリントごとに課題を洗い出すということは、常に顧客の強い圧力にさらされることでもある。また常に時間に追われ、余裕がない場合は納得がいかないリリースでもコミットしたり、見積もり時間内に終えられなかったりという苦労があるのも事実だ。

　内田氏は「アジャイルはあくまでツールの1つであり、『良いものを作って顧客に喜んでもらう』という開発者としてやるべきこと、開発者としての喜びは変わっていない。ただ、アジャイルによって今までよりもアクティブに取り組めるようになった。だからこそ、うまくいったのではないだろうか」と振り返った。