「超高速開発」という言葉そのものが誤解を生む、という指摘があります。その定義がはっきりしないというご意見もあります。
これはおそらく、超高速開発によって「短期開発・高生産性・高品質」を実現できる、という営業トークの背景を把握できていないためです。それを正確に伝えない営業に非がある、とお叱りを受けそうですが、それは超高速開発 = 魔法の類と勘違いしていると言わざるをえません。
昨日、超高速開発コミュニティの幹事会で「超高速開発」のシンプルな表現が示されました。次の一文です。
超高速開発は「工程の省略／自動化／標準化」によって、短期開発・高生産性・高品質を実現する手法である。
ここに特段の怪しさはありません。省略可能な工程を廃し、自動化のためのインフラを整備することです。そのためには何らかの標準化が必要です。多くのツールベンダーの営業現場では、表現方法こそ違えど、本質的には同じことを説明していることと思います。
超高速開発がうまくいかないプロジェクトの原因は、この前提を無視したことです。具体的に説明します。
失敗あるあるその1「要件定義と基本設計までは終わった」
すでに発注者が要件定義書と基本設計書の作成を終えています。次は製造工程ですが、安く作りたいので、ここから超高速開発ツールの選定を始めます、という案件です。
私はこのストーリーに出会ったときは、ほぼ、その案件に手を出しません。失敗の匂いしかしません。
繰り返しになりますが、超高速開発は、要件定義の段階で、ユーザの要求を「ツールの視点で標準化」し、「そのツールの自動化ライン」に乗せていくようにします。ツールがカバーしない部分は、省略あるいは代替案を示して、できるだけツールの特性を活かせるように仕様を作り込みます。結果として、要件定義終了時には、動作するシステムもあわせて出来上がっているのです。
超高速開発という言葉から、製造工程で使う魔法のツールと勘違いされたのでしょう。*1 超高速開発は、要件定義から利用されるべきものです。標準化という洗礼を受けずに要求を並べた設計書を正とするなら、原則はすべて作り込みの案件になります。オフショアなど製造工程を圧縮する手法と相性がよいでしょうが、品質や納期を担保できるものではありません。そういうことです。
失敗あるあるその2「現行どおり」
これは「その1」の亜種です。要件定義書と基本設計書の存在が、現行システムに変わっただけです。プロジェクトにはカスタマイズの嵐が吹き荒れ、超高速開発どころではなくなります。
失敗あるあるその3「何度でも作り直せる」
そのとおりですし、私自身、これはメリットと説明しています。が、実は経験豊富なエンジニアが最初に定めたモデルは、長く使えるものです。まったくの素人が何度もやり直すことで、それなりのモデルに進化することはありますが、そのツールをよく知っている人を招いて、アドバイスを受けながら作ることで、やり直しの手間を省くことができます。せっかくの超高速開発ですので目に見える成果を早めに出すべきですし、そのためには最初からわかっている人と一緒にやることです。超高速開発ツールがあるので素人でも素晴らしい設計情報が書けるというのは、高価なお絵かきソフトを購入したのでプロ並みの絵が描けるというのと変わらない誤解です。
以上、簡単な例を紹介しましたが、いずれもちょっとした視点の切り替えで解決可能です。それは「得意とするツールを定め、そのツールに精通したエンジニアに、プロジェクトの当初から関わってもらう」ことです。それだけで、そのプロジェクトの成功率は桁違いに上がります。
しかしそのような（私にとっては）至極、当然と思われる進め方が受け入れられない、ということであれば、それはそれで奇妙な問題が見えてきます。自動化可能なレベルの標準化が存在するにも関わらずそれを拒否し、独自仕様にこだわり続けることのデメリットを抱えたまま、いよいよ突入する AI や IoT の時代に進めるのか？という疑念です。
28日の Wagby Developer Day 2017 の基調講演では、エンタープライズアプリケーション開発分野はどういう立ち位置でAIやIoTの時代を迎え入れるのか、というテーマを考え抜いた、私なりの結論をお話させていただきます。
*1:この業界の悪弊である、上流と下流という工程の分断がその根っこにあります。
