プロトタイピング開発とは何なのか？を改めて考えてみた結果、到達した答えはこうだった
プロトタイピングと呼ばれる開発手法が存在します。
要件定義の段階で、最低限の機能を実装したプロトタイプを作成する事により、実際に作るシステムに必要な業務要件であったり、機能を明確化していくやり方です。当然、プロトタイプは一度作ったら終わり・・・ではなく、作ったプロトタイプ使って評価をして、気が付いていなかった（見えていなかった）要件や、必要と思っていたが実は不要だった要件などを洗い出した上で、プロトタイプに反映して更に評価を繰り返す、何度も反復して要件を明確にしていきます。
「ん？」と思われる方も多いと思います。1980年代に登場した開発モデルです。
そう、この日進月歩と言われるIT業界の中で30年も前の開発モデルの説明をしている訳です。
IDEツールも存在しない時代の手法です。GUIを表示するだけでも膨大なコード量が必要となっていた時代です。
プロトタイピング登場以前は、実際の仕様はドキュメントで表現されていました。当然ワープロも発達していな時代のドキュメントです。
下手をすれば手書きの文章、手書きの絵・・・今よりもっと制約が多い中、暗中模索をしながらシステムの開発を進めていた時代です。
要件定義に参加しているそれぞれの人の脳内に各々バラバラのイメージが描かれていた可能性もあります。
そんな時代に登場したプロトタイピングモデル。
目の前で具現化された画面を実際に動かしながら検討ができるのは、センセーショナルな出来事だったと思います。
それから30年。
ITを取り巻く環境も大きく変化しています。
IDEも発達して画面に関するコーディング量は大幅に激減し、ワープロも発達してドキュメントに図を差し込むのは当たり前です。
要件定義の段階で、それらのイメージを元に議論を何度も行いつつ、仕様を明確にしていくのが現在のスタンダードです。
「ん？」と思ったのは「プロトタイピング」と銘打って、なにか特殊な開発モデルの様に扱われている事に対しての違和感なんだと思います。
当たり前の開発手法になっているとも言えます。
それでも開発は迷走する
「なんだ、昔と違って要件を明確にするのは簡単なんじゃないか」と思うでしょう。
「サクサクッとプロトタイプ作って、イメージ湧くし要件も明確になってあとは作るだけだよね」そう思うでしょう？
しかし、それでも開発は迷走します。
大きく次の2つの理由による所が大きいと考えています。。
システムの死角が増えた
やれる事が増えすぎてUIの部分でも沢山の死角が発生しています。
一覧の表示レイアウトの変更なんて昔は自分で実装しない限りはあり得ない話でしたし、自分で実装しなければならないからこそ必要な時にしか実装しないものでした。所が今は一覧を表示するコントロールに標準でレイアウトを変更するボタンが付いてきます。こういうのを見落としてしまうのです。実際にどう動くか理解できていないので、挙動が不安定にバグになったりするのです。
イメージ化しにくい処理が増えた
イメージ化しにくい部分、例えば業務要件や一括処理などのUIを伴わない処理に関しては、ドキュメントベースで検討せざるを得ない状況になっているのが現状です。また昨今の業務の複雑化も加わりより表現が難しくなっていると言えるでしょう。図としてイメージ化する手法としてUMLやBPNMなどが存在しますが、まだまだ世の中に浸透しておらず、それだけで理解を得るのは難しいものがあります。
GeneXusを利用したプロトタイピング
時代は死角になりやすい部分を減らしつつ、可視化しにくい部分を可視化するプロトタイピングが必要になってきています。
特に業務要件や一括処理の部分などは「簡単に作って動作を試す」というのは従来では難しい事でしたが、自動開発ツールを利用する事により実際の動きに沿った検証が従来よりも短期間で簡単に行える様になりました。これまでイメージしにくかった箇所も実際に動くモノを見る事で具体的なイメージを持てる時代になった訳です。
更にGeneXusを利用する事で、より早い段階で実際に入力したデータを使いまわした、より業務に近い検証が可能になります。
次の記事でもGeneXusを利用した仕様検討のススメを書いております。
また、GeneXusって何？と言う方も、コチラの記事を読んでいただければGeneXusのブランドを理解頂けると思います。
