下林明正のブログ

個人的かつ雑多なブログです。

Vモデルと反復型開発の境界をどこに置くのか

ということについて一緒に話す機会あって、おもしろい話題という気がしたし、現時点での考えをまとめておくと何かしら便利な気がしたので、考えながら書いてみようと思いました。 特に学術的な裏付けなどはなく、個人の感想です。

別に特殊な話題ではない気がするので、世の中にもっと良い情報があっても良い気がする。何か知ってたら教えて下さい。

Vモデルと反復型開発の関係

基本的に、企業行動はVモデルに近い形で行われていることが多いように思う。例えば、今期の計画を立てる→予算を設定する→計画を実行する→売上を立てるというような概ね不可逆のプロセスを繰り返して、企業は存続していることが多いような気がする。

一昔前のソフトウェア開発プロセスもこうしたVモデルが一般的だったようだ。おそらく、それが企業行動として自然だったからだと思われる。 しかし実際はあまりうまくいかなかったので、最近ではソフトウェア開発プロセスとして例えばスクラムのような反復型開発が一般的になりつつあると感じる。

ここで、Vモデルと反復型開発という性質の違うプロセスが同居する必要性が出てきて、反復型開発からVモデルの世界観へ変換する境界がどこかで必要になった、と捉えている。

開発プロセスの変遷モデルで境界をどこに置くのか考えてみる

以前開発プロセスの変遷モデルというのを独自に考えていたので、これに当てはめて整理してみるとかんたんなのではないか、と思った。

  • フェーズ0: そもそも何も考えられていない、論外
  • フェーズ1: 境界は無い。すべてがVモデルの中で行われる
  • フェーズ2: 開発チームとプロダクトオーナーの間に境界がある
    • 何をつくるかまではVモデルの中で行われるが、どうつくるかは反復型開発の中で行われる
    • 世界観の変換は比較的容易なはず。なぜなら、反復型開発の世界観を取り入れるのは開発チームだけで良いから。締め切りまでにできあがったものを納品すればいい
  • フェーズ3: プロダクトオーナーと企業の間のどこかに境界がある
    • プロダクトの戦術に境界を置くとグロースハックっぽい
    • プロダクトの戦略に境界を置くとリーンスタートアップっぽい
    • それより外に境界を置くとどうなるのかは良く分からない。少なくとも日本の上場企業では難しそうな印象がある
      • 先述の通り、外形的にはVモデルで運営されることが求められているという認識
    • 境界を外に置こうとするほど影響範囲が広くなり、従来のVモデル的なパラダムシフトからのシフトを要する範囲も広くなるので、世界観の変換は困難になっていくはず
      • ナチュラルボーンフェーズ3だったり、一度パラダムシフトしてしまえば、それ以降はそれが自然状態になる可能性も普通にありそう。それが企業文化というものかも知れない

どこに境界を置くべきなのか

というのはどのような開発プロセスを採用するべきなのか、とも言えそう。

先ず前述の通り、ソフトウェア開発においては一般的にVモデルの成果はあまり芳しくないと思われるので、あまり積極的にフェーズ1を採用する理由は無いように感じる。

ではフェーズ2とフェーズ3はどうなのか。心情としては、何となく先進的な感じ・主体的でやりがいがありそうな感じ・うまくいきそうな感じがするのでフェーズ3で!と言いたくなる。けど実際は、取り巻く環境によって何が適切なのかという判断は変わりそう。

例えば、請負契約で受託開発をやってますといった場合ではそもそも何をつくるかは固定化されるはずなので、フェーズ3よりはフェーズ2のほうが適切なように感じる。 仮に契約で縛られていなかったとしても、業態のビジネスモデルとして大々的なマーケティングが前提となっているような場合もフェーズ2のほうが適切であるように感じる(例えば、コンシューマーゲームソフトなど?)。

逆に、スタートアップ企業の新規プロダクトのようなまだ仮説検証段階にあるようなプロダクトがフェーズ2のようなやり方をしていたら「無駄なものをつくっている」可能性が十分に高いと思われるので、フェーズ3の中でもプロダクトの戦略に境界を置くようなリーンスタートアップのようなやり方が適切なような気がする。 受託開発であってもサービスのグロースをやっていきたいんだよね~~という状況だったらフェーズ3が適切そうに思うけど、その場合は契約などから見直す必要性が出てきて、もしかしたら力関係や経済性や単なる実務能力などによってそれは実現できないということもあり得るかも知れない。 先述の通り、世界観を変換すべき範囲が広がっているので、比較的困難だと思う。

ただ、世の中の流れとしては境界を以前よりも外側に置くようになってきているように感じる。 例えば、コンシューマーゲームソフトにしても昔は発売してからの修正は困難だったのでクソゲーはクソゲーのままだったしバグもどうしようもないものだったけど、最近はパッチが降ってくるのが当たり前になって、なんならユーザーの反応を見て追加コンテンツを開発したりしていると思う。

結局、不確実性の高い状況において計画を精度高く立てるのはやはり人智を超えているし、無駄なものを多くつくってしまうような非経済性もあるので、技術の進歩などによって経済的なほうへ少しずつ移行してきているのだと思う。 また、VUCAの時代とか言ったりするけど、世の中そのものの不確実性が高まってきているという背景もあるかも知れない。 そういう意味では追い風が吹いていて、フェーズ3のような開発プロセスを採用するような敷居は(まだ十分ではないかも知れないけど)下がってきてるという見方もできる、気はしている。

なので、もし現状フェーズ2のやり方だけどフェーズ3のやり方に変えていきたいというような場合は、そうした非経済性を一つの切り口にして攻めたら良いのでは無いか?と思う。これはまさに開発プロセスの変遷モデルに書いた「次のフェーズへ進む問い」そのものだと思う。

参考になりそうな書籍

あまり記憶力は無い方だけど、思い出してみる。

shimobayashi.hatenablog.com

「通常のロードマップと製品開発ロードマップ」のあたりで、企業行動としてのVモデルの必要性に触れており、また、仮説検証型の開発プロセス(フェーズ3)とどう結合するのかについて述べていた記憶がある。

shimobayashi.hatenablog.com

世の中のアジャイル開発的な本を読んでいるとフェーズ2を飛ばしてフェーズ3の話を暗黙的にしていることが多いような印象なのだけど、この本は割とフェーズ2の観点でも語ってくれてる印象(特に第一章)。なので、フェーズ2とフェーズ3の使い分けについて参考になる気がする。

shimobayashi.hatenablog.com

フェーズ3はどんなものなのか、というところを掴むにはかなり良い本だった覚えがある。

shimobayashi.hatenablog.com

「不確実性をどう扱うのか」というのが開発プロセスのテーマだと思うので、その観点で参考になりそう。

shimobayashi.hatenablog.com

昔の読書感想文すぎてつらいけど、リーンスタートアップはもう前提知識みたいな雰囲気があるので読んでなかったら読んだほうが良さそう。

shimobayashi.hatenablog.com

これは開発プロセスと契約の関係について書かれていた本、だった気がする。

あとはグロースハック系の本も読んでおくと良さそうなんだけど、自分が過去読んだものの読書感想文がパッと見つからなかった。まあ多分最近はもっといい本が出ていると思われるので、新しくて良い本を読んだら良さそう。