以前、ソフトウェアの開発には
計画型とアイデア型があるという
お話をしました。

計画型の開発は
きっちり計画を立てて
その計画通りに開発を進め、
アイデア型は、
開発途中で出てくるアイデアを
柔軟に取り入れながら、
最初に決めた通りのものを作るのではなく
ソフトウェアの価値を最大化する事に
重点を置いて開発をします。

そもそも、
ソフトウェアの開発といえば
ほとんどが計画型の開発でした。

それでアイデア型の開発が
出てきたのは、
計画型の開発にはいろいろな
問題が出てきたからです。

  • 急な仕様変更に対応できない。
  • お客様が実際に動くソフトをなかなか見る事ができない。
  • そもそも最初の計画が間違えている。
    (お客様の要望通りのものを作ろうとしていない。
    計画通りに進まない・・・など)

もちろん、計画型の開発でも
作り始める前に、文書等で確認はできますが
それだけで、実際に出来る物を
把握・イメージするというのは
少し無理があります。

そこで、出てきたのが
アイデア型の開発です。

アイデア型の開発は
計画型の開発では
一度ずつ行なっていた

  • 要件定義
  • 設計
  • プログラミング
  • テスト

のフェーズを繰り返し行ない、
テストの後に
お客様にお見せして
実際に作って欲しいものと
作っているものが合っているか?
さらに、その上で
変更すべき点は何か?
それを相談しながら、
進めていきます。

アイデア型の開発はある意味、
変更が起こる事を前提で
進めていく開発手法と言えます。

しかし、手法を変えれば
ソフトウェアは変更にも対応できる様に
なるかと言うと、そうではありません。

エンジニアが打ち合わせの場にいると
よく出てくる言葉があります。

それは
「今の○○では、それは難しいです。」
という言葉です。

この○○には「設計」「構造」「ポリシー」
ソフトウェア名など、いろいろな言葉がきます。

これは、何を意味しているかというと
手法がアイデア型の開発で
変更に対応しようとしていても、
エンジニアがそれに対応できる様な
作り方をしていないのです。

つまり、プロセス (行程) が
それに対応していても、
エンジニア達のマインド (意識) が
ついて行っていないと
それは、ほとんど意味を成さないのです。

もちろん、方針を180度変える様な
要望にはなかなか対応できないので、
限界はあります。

しかし、エンジニア達が
意識しているか、していないかで、
その対応力には大きな差が生まれます。