最近、顧客企業から
・レガシーなシステムをクラウド（うちの会社の場合はAWSほぼ一択なのですが）に移行した
・その時に（モノリシックな ということばを使うかどうかは別として）マイクロサービス、サーバーレス関連の技術を使いたい
・クラウドのマネージドサービスを使いたい
・クラウドネイティブ化したい
といったような感じの相談が増えてきています。
ネットを探して相談をもらうケースが多いのですが、どうも、、「これまで基幹システムの構築・運用を依頼していた大手のシステムインテグレーターに相談しても、どうもピンとこない。意向にそった動きや提案をしてくれない」という感じらしいのです。
もう少し具体的に言えば、ビジネスのデジタル化に関連する企画を考えていて、それを実現するためのソフトウェアを開発したいと思っています。ただし、システム開発関連の取引先としては、既存の委託先である大手システムインテグレーターしか知らないため、まずはそこに相談するわけです。
でもその回答が、スケジュール感や開発スタイルが合わず、1年以上かかるスケジュールを提示されたり、分厚い提案書を提示され予算が数億から数十億だったりします。それで困ってしまい、ネット検索し弊社にたどり着いたというケースです。どうもデジタルシフトのためのソフトウェア開発に関しては、大きなミスマッチが起きているようですね。
ソフトウェア開発力が競争力の源泉なのに
デジタルシフトの必要性が叫ばれ始めてから、すでに4〜5年は経つでしょうかね。企業にとっての顧客接点がスマートフォンに移行したのを契機に、デジタルマーケティングを課題にとらえるB2C（企業対個人）型の企業が急増して、B2B（企業間）型の企業は、IoTだ、AIだ、データだ、といった技術をテコに、なんとかビジネスでおいていかれないようにとようやく考え始めているんでしょう。デジタルマーケティングや、IoT、AI、APIといったデジタル技術を使ってデータをリアルタイムに収集し、そのデータを素早く解析することで、ビジネスの改善や新しいビジネスの創出にフィードバックしていく流れ全体が必要になってきている。そのためには「ソフトウェアを素早く開発できる能力」が必要だと徐々にわかってきた、感じなのです。
素早いソフトウェア開発力はスタートアップの前提条件
ソフトウェアを素早く開発できる能力を持った企業というと、当然、Apple、 Google、 Facebook、Amazonとなになるんですが、それだと、あまりに巨大すぎて、ちょっと現実味にかけます。
ではスタートアップ企業はどうでしょう。彼らは新しいソフトウェアを世に問うて、それをテコに市場を開拓する企業です。ソフトウェアの開発力や開発スピードによって、その成否が決まってきます。
日本で言えば、メルカリなんかが、ソフトウェアの開発力によって成功してきたスタートアップ企業の代表例と言えるんでしょうか。既存業種の企業がデジタルにシフトするためには、メルカリのような成功したスタートアップ企業と同様のソフトウェア開発力を身に付ける必要があります。では、スタートアップ企業は、どのようにソフトウェアを開発しているのでしょうか。彼らが獲得している方法論を学ぶことは、企業のデジタルシフトに必ず役に立つはずです。
スタートアップの「リーンな経営」と「アジャイル開発」
スタートアップ企業が獲得を目指す方法論の1つが「リーン・スタートアップ」です。「リーン・スタートアップ」はよく聞くワードだと思うのですが、ちょっと解説っぽいことをすると、米国の起業家であるエリック・リース氏が2008年に提唱した、起業や新規事業の立ち上げに向けた管理手法です。「リーン（Lean）」とは「痩せて引き締まった」と言う意味です。そもそもはトヨタ自動車の生産方式である「TPS（Toyota Production System）」をもとに、米MITが提唱した「リーン生産システム」に由来します。
リーン・スタートアップでは、ギリギリのコストと短いサイクルで、ビジネス上の仮説の具現化と、その検証、仮説の改良を繰り返しながら、本来のニーズを掘り当てていきます。この考え方が、新規事業や顧客との新しい接点の創出を目指すデジタルシフトでも求められているのだと思います。
そのプロセスは簡単に言えば次のようになります。
（1）仮説をできる限り低コストで素早く形にし、必要最小限の製品として顧客に提供する
（2）それが受け入れられるかどうかについて顧客からフィードバックを得る
（3）その結果を元に改善や軌道修正を繰り返す
（4）そもそもの仮説が誤りであれば、ダメージが少ないうちに進路を変更（ピボット）する
つまりリーン・スタートアップでは、新規事業をできる限り小さく作り、顧客からのフィードバックによってサービスを改良するなど、軌道修正（ピボット）を繰り返し成功に導いていきます（図1）。
図1：リーン・スタートアップの管理手法に基づく事業創出のサイクル
一般に、新しいサービスを提供しようとすれば、多くの人は、できるだけ完全なものを作り上げようとします。しかしリース氏は、「開発の初期段階は失敗することを前提に計画を作るべきであり、そこの多くの時間とコストをかければかけるほど失敗した場合にムダが大きくなってしまう」と解説します。検証すべきアイデアだけを最低限に盛り込んだ機能である「MVP（Minimum Viable Product）」を提供し素早く検証することが大事だと訴えます。
リーンとアジャイルは従来型企業の“敵”か
そして、リーン・スタートアップのためのシステム構築プロセスと言えるのが「アジャイル開発」という手法です。「アジャイル（Agile）」とは、直訳すると「素早い」「機敏な」という意味です。
今さらアジャイルの解説をしてもという感じではあるのですが、今でも、エンタープライズというかSIの世界では、ウォーターフォールを中心とした従来のソフトウェア開発方法論が中心なので、あらためて書いてみます。
アジャイル開発では、初めから全体の細かな仕様は決めず、おおよその仕様だけで細かな反復的スケジュールで開発を始めます。小単位の「開発とテスト」を繰り返すことで、徐々に開発を進めていきます。
僕の経験では、これまで日本のIT部門は、リーンやアジャイルといった考え方をなかなか受け入れようとしませんでした。それは、彼らが大事にする「要求通りに完成させる」「成果物への責任」といった、これまでの“常識”的な考え方と相反する概念だからです。
多くの企業向けシステムは、「ウォーターフォールモデル」でソフトウェアを発注し開発してきました。（図2）。
図2：「ウォーターフォールモデル」の概念
具体的には、開発プロジェクトを（1）要件定義（どんなシステムを作るか）、（2）基本設計（機能の概要や画面のデザイン）、（3）詳細設計（開発するプログラムの細かな機能の定義）、（4）プログラミングといった段階（工程と呼びます）の順に、だんだんと細かい内容に落とし込んでいきます。前の段階（上流工程と呼ぶ）が完了してから次の段階（下流工程と呼ぶ）へ進んでいくわけです。
ウォーターフォールはソフトウェアのためのモデルではない
ウォーターフォールモデルは元々、土木や建築、プラントなどの巨大な工事を正しく進めるために生み出された方法です。それが1960年代に、メインフレームと呼ぶ大型コンピューター上で動作するソフトウェアが大規模、かつ著しく高価になった頃、開発プロジェクトを科学的アプローチによって正しく進めるために、ソフトウェア開発にも適用されるようになりました。
しかし、ウォーターフォールモデルについては、20年ほど前からすでに、次のような問題点が指摘されています。
・前工程の誤りによって手戻り作業が発生すると、大幅に工数が増える
・テストなどの下流工程になればなるほど手戻りが深刻になる
さらに近年は、米国を中心にウォーターフォールモデル離れが進んでいます。「海外におけるソフトウェア開発において、ウォーターフォールモデルが採用されている率は1割にも満たない」との調査結果もあります。にもかかわらず日本では、多くの企業がウォーターフォールモデルでソフトウェア開発を続けています。まだまだウォーターフォールモデルしか経験したことがない、それ以外の進め方を知らない企業が多いことには本当に驚いてしまうのですが、そこには日本のIT業界特有の構造上の問題があります。
・技術者のほとんどがユーザー企業ではなく、システムインテグレーターに所属しており、文書化された要件がないと開発ができない
・工程がきれいに分離されるほど技術者を外部から調達しやすい
ソフトウェア開発では当初から「正しい要求」は確定できない
ウォーターフォールモデルのプロジェクト成功の鍵は、「できる限り早い段階で“正しい要求”を確定する」ことが握っています。であれば発注側は、正しい要件に基づいて見積もりを依頼し、それに沿って発注しなければなりません。受注者側にしても、顧客から提示された要件（仕様）通りにソフトウェアを開発することが自らの責任範囲になります。
当然、最初の要件が間違っていれば、間違ったソフトウェアが完成します。それでもベンダーにすれば要件通りに開発しただけですから、「要件通りです」と胸を張って答えるといったことが起きます。よくいう「仕様です」というやつですね。ベンダーが無責任といったことではなく、ウォーターフォールモデル自体が、発注者に正しい要件定義を求めているのです。
デジタルシフトのための開発において、このウォーターフォールモデルの最大の問題は「変更を前提としていない」という点です。デジタルシフトに向けた開発では、初期段階では何が正しい要求かは分からないことがほとんどです。そのため、間違いを修正しながらビジネスモデルの検証と同時にプロジェクトを進めなければなりません。
反復することで失敗のリスクを最小にする
ソフトウェアの開発は、本来、ビジネスモデルへ落とし込む段階で、検証を繰り返しながら代替策を練り上げ、大きなビジネスに徐々に育てていくというプロセスが必要なのです。企業のデジタルシフトは、あるビジネスを1つ創出すれば終わりというわけではありません。ビジネス改革に永続的に取り組める組織の実現や方法論の浸透を土台に、進化し続ける企業文化を獲得しなければなりません。そのためには、企業がITやソフトウェア開発に対する考え方を根本から改める必要があります。
スタートアップ企業では、誤りがあることを前提に、それをできる限り早期に修正する、つまり、「小さく、早く失敗する」ことを重視しています。その開発手法として推奨されているのが「アジャイルモデル」です。
アジャイル開発では、「反復（イテレーション）」と呼ぶ短い開発期間を1つの単位とし、その単位ごとに成果物を提示し検証することで、失敗するリスクの最小化を図ります（図3）。
図3：ウォーターフォールモデルとアジャイルモデルの比較
図2を見ていただければ、ウォーターフォールモデルでは初期工程で正しい要件が得られなければ最終段階で大きく失敗するのに対し、アジャイルモデルでは、初期段階から小さな失敗を織り込みながら、少しずつビジネスを改善していけることがわかると思います。
※この記事は以前、Webメディア（（DIGITAL X（デジタルクロス） | インプレス社））に連載したものを、最近の自分の問題意識とともに手直ししてまとめ直したものです。あと何回かにわけて書いて行きたいと思います。
ソフトウェア開発（リーンとアジャイル） その２ に続きます。