プロジェクトを進めるとき、まず要件を聞いて、設計して、開発していくのが一般的な流れだろう。いきなり動くのではなく全体像を図に表したりして、計画を立ててから動き始めるのが基本である。

しかし、この一般的な流れはIT業界においてはちょっと違う。ITが他の業種と違うのは「後から修正ができる点」である。つまり、とりあえず動き始めてから修正していく、という流れが生み出せる。

ITスタートアップでは当たり前になっている開発手法である。下記のリーンスタートアップでは、とりあえず動き始めることをMVP(必要最小限の製品)と名付けている。

○ 従来の開発手法

• やりたいことがある！

• できるかどうか検討

• 計画を立てる

• 進める

○ リーン開発

• やりたいことがある！

• まず進めてみる

• 反応を見る

• 修正する

IT業界でも、規模が大きくなるほど、従来の開発手法を使いたがる人が多くなってくるが、やはりITはリーン開発が最も効率的だと感じる。でなきゃ、スタートアップが採用してないからね。

しかしながら、大規模になればなるほど、リーン開発の「えいや！」で始める手法が上手くいかなくなってくる。それを解説したのがイノベーションのジレンマという本。

大企業であっても、社内に小さなチーム(スタートアップ)を作り、常に破壊的イノベーションを起こさないといけないわけだ。

小さなチーム分けまではできている組織が多いが、従来の開発手法を導入しているチームも多いのがなんとも悲しい。

○ 今日の予定

• サンプル機能(設計は未完成！)を作る

• 月末の精算

• 報告書の提出

○ 明日の予定

• 新プロジェクトの導入

• 野球観戦！