富士通が「巨額をかけた残念なシステム作り」から一線を引けるようになったワケ

なぜ日本企業の情報システムは「使いにくい」のか

ソフトウエア開発の分野で「アジャイル方式」と呼ばれる新しい開発手法が急速に広がっている。これまでは開発前にシステム全体の要件をきっちり定義する「ウォーターフォール方式」が主流だったが、アジャイル方式では要件定義よりも開発を優先させていく。いわば「走りながら考える」というやり方だ。

ひとつの大きな動きは、国内最大手の一角である富士通が、アジャイル方式の導入で受注を増やしていることだ。なぜ富士通は従来のやり方を変えられたのか。本稿ではそれについてみていく。

ビジネスなどへの情報システムの活用は日本でも大きく広がっている。この流れは企業でも、官公庁でも、あるいは病院や学校などの非営利組織でも変わらない。特に、大きな組織になると、生産、調達、開発、経理、人事、営業、そしてサービス提供と、多くの領域において専用情報システムが業務を支えるようになっている。

では、こうした職場で働く皆さんは、日々使用する情報システムに満足しておられるだろうか。例えば、次のような経験はないだろうか。導入された情報システムは、操作手順が複雑で、使用状況を十分に理解してつくられたとは思えない。さらに確認画面などもわかりにくく、ミスが起きやすい。事前のテストが不十分なのか、クリックしても先のページが開かなかったりする。別のタブを使ってたどっていけば、目当てのページにはたどりつくのだが、面倒だ。

「何とかならないか」と情報システム部に改修を申し入れるが、次のシステムの更新時までは無理といわれる。現場での作業手順の変更に合わせた改修依頼への返答も同様で、情報システムに縛られて身動きが取れなくなる。情報システムが、外部へのサービス提供や組織改革の障壁となってしまう。

融通がきかないシステムが生まれる根本原因

なぜ、このような残念な事態が、繰り返されるか。犯人は情報システムそのものではない。融通の利かない情報システムに縛られるのは、その開発が「ウォーターフォール方式」で行われているためである（図表1の左側参照）。

ウォーターフォール開発では、まず発注企業とシステムベンダーが協力して、開発する情報システムにどのような機能を搭載するかを、対象業務の調査や分析などを踏まえて検討する。そして搭載するすべての機能の要件定義を確定したうえで、設計と構築に移る。包括的なドキュメント（設計仕様書）を作成し、これを基にプログラミングを進めていくのである。

新たな開発手法「アジャイル」の誕生

このウォーターフォール開発の問題に気づいたソフトウエア開発者たちが、2002年に「アジャイルソフトウエア開発宣言」を米国で発表した。この宣言では、よりよい開発方式は、「包括的なドキュメントよりも動くソフトウエアに」「計画に従うことよりも変化への対応に」価値をおくことから生まれると語られている。

アジャイル方式では、情報システムに組み込む機能のすべてではなく、必要最小限の機能を備えた製品（MVP：Minimum Valuable Product）から開発をはじめる（図表1の右側参照）。情報システムの利用では、使ってみることで、何が必要かが明確化することが少なくない。それならば、必要最小限の機能を備えたシステムをまず作成し、導入して使ってみればよい。そして利用データを解析し、不足や不具合を洗い出し、その後に追加で改修や各種の機能を開発し、また使ってみる。

こうすることで、実際には使わない機能の開発に時間をとられることなく、使い手が必要とする機能を、どのように利用されるかを踏まえて開発することができる。この計画―開発―導入―検証のサイクルを、短い期間でクルクルと回していけば、開発する機能などを柔軟に後から付け足したり､変更したりできる。

小刻みの開発を繰り返すことの利点と欠点

ソフトウエアの開発企業が、リリース後に商品を随時改修して、購入後の利用者にバージョンアップの機会を提供する。こうしたアフターサービスの提供はインターネットの通信速度や容量が高まるとともに容易になり、今ではOSから、ゲーム、ビジネス・アプリと幅広い領域で採用されるようになっている。アジャイル開発は、こうした潮流に先駆けて提唱され、臨機応変なバージョンアップを支える開発方式となった。

一方で今でもウォーターフォール開発への需要は根強くある。情報システムの開発を発注する側の組織の担当者は、必要な予算については早期に確定したいと考える。最終的なシステムの仕様が曖昧なまま、社内の予算承認を受けるのは不安だ。

ところが、小刻みの開発を繰り返していくアジャイル開発では、開発の初期に予算や仕様を確定できない。アジャイルでは、初期コストは低減できるが、最終的にはどのくらいの金額が必要となるかは、やりながら決まっていく。不確実性を嫌い、早期に見通しを立てたがる組織の担当者には、アジャイル開発は手離れが悪く、リスクを先送りしているように見える。

「イノベーターのジレンマ」に直面した富士通

ウォーターフォールやアジャイルといった方式は、情報システムに限定されない幅広い製品やサービスの開発や生産の基礎となるロジックである。日本では、自動車産業などのように以前からアジャイル的なスタイルの開発や生産が主流となっている領域も少なくない。

しかし情報システムの開発においては、ウォーターフォール開発が主流だった。ところが、日本のシステムベンダーがお手本としていた米国で、2000年代に入るとアジャイル開発への移行が進んでいく。

富士通も、米国でアジャイル開発が提唱され、情報システム開発の潮流に変化が生じはじめていることは当然つかんでいた。同社で技術戦略の策定を担当する岡田英人理事によると、同社は変化をとらえるべく学習を進め、アジャイル開発を手がける体制を2000年代の後半には整えるようになっていた。

しかし、アジャイル開発ができるようになりさえすれば、受注が順調に増加するわけではなかった。富士通が受注するアジャイル開発の案件は伸び悩む。

これはアジャイル開発に特有の問題ではない。新たな技術や開発手法をマスターしさえすれば、千客万来となるわけではない。なぜなら、顧客との関係を変えなければ、旧来の方式での受注が続いてしまうからである。

アジャイル開発についていえば、発注する顧客の側はウォーターフォール開発になじんでおり、開発する情報システムの予算と仕様を早期に確定したいと考えていた。ハーバード大学教授のC・クリステンセン氏がいう「イノベーターのジレンマ」に富士通は直面したのである。

顧客課題の性質に応じた開発手法の選択

アジャイル開発は万能の手法ではなく、利点はあるものの、開発の条件によってはウォーターフォール開発が適することも少なくない。アジャイル開発への受注を拡大するためには、顧客との関係にていねいに向き合う必要がある。富士通ではこのように考え、アジャイル開発の営業を進めてきた。

富士通では現在、顧客組織の課題をその組織のビジョンや中長期の計画にさかのぼって理解する営業への取り組みを進め、手応えをつかんでいる。同社の金融機関向けのシステム開発や営業を担当する第三ファイナンス事業本部・証券事業部の齊藤弘樹氏によれば、このような営業が必要となるのは、どのような課題の下での業務であるかによって、適したシステム開発の方式は異なるからである。

例えば、銀行の店舗などで人の手で行っていた作業をシステム化していくような場合には、ウォーターフォール開発を採用する方がむしろ適していることもある。しかし、デジタル技術を活用して、今までになかったビジネスを新たにはじめるような場合には、当初はビジネス・フローの詳細は完全には見通せない。

新しいビジネスのシステム構築に適した「アジャイル開発」

金融の領域では、フィンテックを活用して、事業者の取引履歴などの分析を融資の審査に活用する新しい事業に取り組むといったケースが近年増加している。このように金融機関の側にも前例がない、あるいはあっても極めて少ないビジネスを、デジタル技術を活用してはじめる場合には、ウォーターフォール開発を採用して早期に仕様の確定を行うと、使わない機能が満載の一方で、肝心の機能が使いにくいシステムが出来上がることになりがちである。経験がない事業や業務に何が必要かを、経験を蓄積する前に見定めることは難しいからである。

このようなケースではアジャイル開発を採用して、必要最低限の機能のシステムをまず作成し、実際に使ってみることで、付加する機能の必要性の高さを見極め、追加で開発サイクルを回していく方がよい。

新しい開発手法が受注を増やしてくれるわけではない

富士通が経験したのは、アジャイル開発ができるようになりさえすれば、受注が順調に増加するわけではないという営業問題である。この問題は、発注する組織の担当者が、アジャイル方式での開発を依頼した経験がなったり、少なかったりすることから生じていた。

経験がなければ、開発方式の適否の見極めの判断は難しい。あるいはアジャイル開発だとどのように発注を行い、設計や構築が進んでいくかも、見通しを立てにくい。そのために、本来であれば適しているはずのアジャイル開発ではなく、慣れ親しんだウォーターフォール開発での発注が続き、残念なシステムがつくられ続けるということすら起きていた。

そこで富士通は現在では、発注側の組織の経営課題をビジョンなどの上流にさかのぼって理解し、提案を行う営業を強化している。これは、受注するシステムの上位にある顧客組織の課題に向き合う営業であり、顧客がどのようなビジネスのために情報システムを利用しようとしているかのヒアリングを行い、その結果を踏まえて提案を行うという、一種のコンサルティング営業である。

回り道に見えても顧客とともに考える

顧客組織の経営課題を、上流にさかのぼって理解する営業の利点はどこにあるか。

第一に、アジャイル開発とウォーターフォール開発それぞれのメリットとデメリットに通じている富士通は、顧客組織の担当者では判断がつかない選択問題に踏み込んで提案を行うことができる。

第二に、富士通がアジャイル開発の提案を行う際は、最初に作成する必要最小限の機能は何か、その仕様の検証を踏まえて拡張をどのように進めるか、といった、「ビジネスを育てながらシステムをつくる方法」を顧客組織とともに考え、提案していくことができる。

目先の受注を増やすそうとするのであれば、この富士通の営業は回り道かもしれない。たしかに顧客がウォーターフォール方式での開発を発注してくるのであれば、手っ取り早いのはそのまま受注する対応である。

しかしその結果、富士通が納入するシステムが顧客組織の活動の足を引っ張るものとなると、確実に顧客の不満を招くことになる。こうなると、将来の富士通の受注の喪失へとつながりかねない。富士通がアジャイル開発も提供できるのであれば、必要な顧客組織にはアジャイル方式を提案していくことが健全であり、将来のリスクの低減にもつながる。

イノベーションを実現するための2本柱

こうしたコンサルティング型の営業を強化したことで、富士通では近年、アジャイル開発の受注が増加している。アジャイル開発を経験した顧客がその利点を実感し、次の受注につながるなどの好循環も生まれはじめている。開発する情報システムの全体を早期に確定しないアジャイル開発への理解が、富士通の顧客組織のあいだに広がりはじめている。

ウォーターフォール方式とアジャイル方式にはそれぞれの利点があり、開発効率等を単純に比較するのは難しい。富士通がアジャイル方式で手掛けたあるプロジェクトで、立ち上げからわずか8カ月で試験運用を開始できた事例がある。これは60％の状態でもいいからユーザーに早い段階で触れてもらい、改良を行いたいという意図に基づくスケジュールで、単純に従来方式と比べて開発期間全体を短縮できたというものではない。

それでも、2020年に出されたマッキンゼーのレポートによれば、アジャイル方式にヒントを得て組織改革に取り組んだ22の企業では、開発期間や生産性が30～50％改善し、顧客満足度が10～30％高まるなどの成果が見られたという（“Enterprise agility”, McKinsey, March 2020）。富士通もまた、積年の課題だったアジャイル方式の市場導入のボトルネックを克服していくなかで、同様の成果を実感している。

アジャイル方式という新たな開発方式と、その特性を顧客組織の課題解決に活かす提案を行う営業方式という2本の柱を確立したことで、富士通はアジャイル開発の受注を増やしつつある。アジャイルに限らず、デジタル時代にあって日進月歩の各種の開発方式については、技術的手法をマスターするだけではビジネス機会を拡大させるには十分ではなく、営業をはじめとするマーケティングにおいても新たなやり方を開発していく必要がある。