• Column
  • デジタルシフトに取り組むためのソフトウェア開発の新常識

ウォーターフォールモデルの限界と“PoC貧乏”が起こる理由【第2回】

梶原 稔尚(スタイルズ代表取締役)
2018年10月31日

 最近ネット記事で、ちょっと流行した言葉に「PoC貧乏」があります。PoCは、Proof of Conceptの略で、新しいビジネスを生み出すためのアイデアの実証を目的に、ハードウェアやソフトウェアを試行・検証してみることを指します。この「PoC貧乏」を巡っては、解釈の違いから色々な議論がわき起こっています。

 この議論においては、PoC貧乏に対し2つの解釈があり、それぞれの解釈に沿って意見を述べ合っていることから、さなざますれ違いが起こっているようです。その解釈とは、誰が「PoC貧乏」になるかという主体の問題です。

解釈1:PoCが本番システムの開発につながらず、PoCを受注したベンダーが期待した利益をあげられない=受注者側が貧乏になる

解釈2:PoCを繰り返しても期待した成果が得られず、ベンダーにPoCのための費用を支払うだけ=発注者側が貧乏になる

デジタルシフトの“PoC”はビジネスモデル検証であるべき

 これらは、PoCという行為を(1)ハードウェア/ソフトウェアの技術的検証と見るか、(2)ビジネスモデルやアイデアの検証と見るかの違いによるものです。技術的な検証であれば、明確な動作目標があり、それが実現できるのか、できるとすれば、どの程度の期間とコストがかかるかが主題ですから、ベンダー側が主体になります。

 これに対し、ビジネスモデルの検証では、企業とベンダーが一体になってリーンに(素早く)プロジェクトを回しながら、仕組みや使い勝手を確かめていく必要があります。この場合の主体は発注者側(ユーザー企業側)です。

 筆者らが、ある大手企業が実施したPoCプロジェクトに参加したケースでは、技術検証自体はうまくいったのですが、本格展開しようとした段階で中止になったことがあります。予算が億単位に、期間は年単位になり、採算が取れるどうかの確信が持てなくなったからです。その原因は、プロジェクトをウォーターフォールモデルで一挙に進めようとしたことにあります。

 本来なら、ビジネスモデルへ落とし込む段階で、検証を繰り返しながら代替策を練り上げ、大きなビジネスに徐々に育てていくというプロセスが必要なのです。なかには、デジタルシフトに真剣に取り組みたくないのか、PoCに取り組んでいることを言い訳に、その成否を問わないという風潮すら感じられます。

 企業のデジタルシフトは、あるビジネスを1つ創出すれば終わりというわけではありません。ビジネス改革に永続的に取り組める組織の実現や方法論の浸透を土台に、進化し続ける企業文化を獲得しなければなりません。そのためには、企業がITやソフトウェア開発に対する考え方を根本から改める必要があります。その最初の取り組みになるのがPoCプロジェクトの進め方でしょう。

反復することで失敗のリスクを最小にする

 スタートアップ企業では、誤りがあることを前提に、それをできる限り早期に修正する、つまり、「小さく、早く失敗する」ことを重視しています。その開発手法として推奨されているのが「アジャイルモデル」です。

 アジャイル開発では、「反復(イテレーション)」と呼ぶ短い開発期間を1つの単位とし、その単位ごとに成果物を提示し検証することで、失敗するリスクの最小化を図ります(図2)。

図2:ウォーターフォールモデルとアジャイルモデルの比較

 図2を見ていただければ、ウォーターフォールモデルでは初期工程で正しい要件が得られなければ最終段階で大きく失敗するのに対し、アジャイルモデルでは、初期段階から小さな失敗を織り込みながら、少しずつビジネスを改善していけることが理解いただけると思います。

 次回は、開発手法としてのアジャイルを解説し、デジタルシフトのための開発における具体的な方法論を探っていきたいと思います。

梶原 稔尚(かじわら・としひさ)

スタイルズ代表取締役。慶応義塾大学卒業後、舞台俳優を志しながら、アルバイトでプログラマーになるも、プログラムのほうが好きになり、30代前半でIT企業を設立。以来、自らエンジニアとして数多くの業務系システムの案件をこなしながら、社長業を兼任する。

「最新技術やOSS(オープンソースソフトウェア)を積極的に活用することで、IT業界の無駄をなくし、効率の良いシステム開発・運用を行う」をモットーに、日々ITソリューションの企画・開発に取り組んでいる。趣味は散歩と水泳。