Software Quality.com

3.4 お知らせのコーナーに"SEC セミナー in 札幌 受付開始”を掲載

ホーム
What's new
お知らせ
サイト マップ
Softwareを取り巻く状況
用語解説
要求工学
利用品質/人間中心設計
ソフトウェア品質特性
プロトタイプ
レビュー
マネジメント
SW構成管理
books
プロセス改善
独り言・私語
training
reference
当サイトについて
お問い合わせ
★HIT Forum
プロトタイプ(prototype)
プロトタイプはその有効性ゆえに今後の(も)ソフトウェア開発にとって欠かせない道具の一つになると思います。
しかし、便利な道具には棘がある。(?) 誤って使うとかえって問題が出ることにもなりかねません。
プロトタイプを有効に使うためのヒント情報を提供します。

■プロトタイプの目的■
どうしてプロトタイプを作るのでしょうか?
この質問にはっきりと答えられ、その答えがソフトウェア開発シナリオ中の他タスクとつながって有効に機能しなければなりません。
もし論拠が不明確だったり、不適切なシナリオ(話がつながらない)、理想的に見えるが非効率的な作業へのアプローチなどになっているようでしたら、使用しない(させない)方がよいでしょう。場当たり的に使用しても良いことはありません。
戦略的にプロトタイプを作る目的をはっきり定めてから使う必要があります。
一般的なプロトタイプの「目的」は以下のようなものです。
(1)顧客要求明確化(促進)のため=「要求引き出し」のため(の道具)
 画面イメージ(項目設定、場所、色、表示形式、文字の大きさなど)・画面遷移・計算ロジックなど
(2)概要説明のため
 デモンストレーション(デモ)などを通じて、他者に機能概要・操作方法などを説明する
 この結果、(1)につながることもあります。
(3)実現可能性調査のため
 機能を実現する方法・手段をいろいろと試してみる→できる方法、最適解を探る
この他にもプロトタイプをそのまま進化させてソフトウェア全体を構築する手法もあるようですが、ここでは触れません。
※この手法はソフトウェア開発のプロ中のプロの方が使えば効果はあると思いますが、素人や開発言語をそこそこ知っている程度の技術者が使うと「設計なし」で「場当たり的に」ソフトウェアを構築し、「焼きそば配線コードの集合体」のようなシステムが出来上がることうけあいです。
 
■プロトタイプの期待効果■
プロトタイプに期待される主な効果には、以下のものがあります。
・システムのインターフェース部を中心とした顧客要求事項の早期確定
・開発過程における変更要求、手戻り作業の低減
・関係者間でのシステム完成時イメージ、認識の共有
 
■プロトタイピングの実施要件■
・プロトタイピングのポイント、注意事項など要点をあらかじめ認識(できればマスター)している技術者が行う
・プロトタイプを作成するツール・開発言語に秀でていること
(最低2年間以上の該当ツール・開発言語経験者を推奨)
・プロトタイピング対応が開発プロセスに組み込まれ、他作業・工程との連動や成果物が明確になっていること
 
 
■最短距離で(お手軽に)目的を果たせ■
上記のどの目的に使用するかが明確になったら、プロトタイプを構築することになります。
目的が不明確なままプロトタイプを構築することは絶対避けて下さい。手段が目的化することになります。
構築するときに大切なことは、目的に向かって、できるだけ余計なことをせずに、お手軽に作り上げることです。
舞台での「はりぼて」を想像して下さい。表面的には精巧に見えますが、裏に回れば板とついたての骨組みだけ。
目的にあっていれば、裏側を充実させる必要はない。無駄なお金と時間(工数)をかけずに(お手軽に)とっとと作る。
「目的は何か?」にフォーカスして対応して下さい。
 
■プロトタイプの罠に気を付けろ■
うまい話には罠がある・・・・ということでプロトタイプには陥りやすい罠があります。
(1)顧客がプロトタイプを見て、すぐにでも完成するような錯覚を起こす
画面遷移とそこそこの項目設定程度の表面上だけ作り上げた「はりぼてプロトタイプ」を見ただけでも、顧客は「もうできたのか!?」と錯覚することがあります。その先に待っているのは、納期短縮や見積金額への不信感が芽生えられたらたまったものではありません。
このことを十分認識した上でプロトタイプを使うかどうか、いつ見せるのか、誤解がないように事前にしっかり説明しておくなどを決定して下さい。
(2)使い捨てプロトタイプを製品として構築する
一番危険な落とし穴がこれであり、かつよく分かっていない技術者がすぐにはまってしまう
(3)目的以上に充実させる
上記の通りで、目的を果たす以上の機能充実や工数・時間・お金をかけてしまうのを避けなければなりません。
これも良く陥る罠の一つだと思います。
 
■プロトタイプの罠に陥らないための対策例■
【対策例1】
できるだけ「はりぼて」「紙芝居的」で、かつ「開発言語を使用しない手段によるプロトタイプ作成」とする。
プロトタイプは実際に開発する言語でなければ作れないわけではありませんので。
ただし、この手法は実現可能性調査目的以外のときに有効になります。
この対策例の応用に「ペーパープロトタイプ」の活用があります。

【対策例2】
作成する前に(事前に)今回のプロトタイプの対象領域とどこまで作成するかについての方針や評価項目を明確にしてから対応する
 
 
■プロトタイプの種類■
プロトタイプは、大きく分けると2つの種類に分かれます。

[垂直プロトタイプ]
-システムのある狭い領域を対象として深く作りこんだもの
-主な目的
   狙った領域における機能詳細の確認
-事例:1画面内の動作・表示形式、処理結果を含めた操作性、表示内容の正確性などの確認

[水平プロトタイプ]
-システムの広い領域を対象として浅く作りこんだもの
-主な目的
   大枠の流れ、システム全体イメージの確認
-事例:画面遷移の確認
 
■プロトタイプは進行に合わせて作成せよ■
プロトタイプの実装の程度は、目的・段階に合わせて変えることをおすすめします。
例えば、基本・構想段階で作成するプロトタイプ(システムの概要を把握するためのプロトタイプ)は概要レベルの詳細度にとどめておくべきです。
この時点であまり詳細な事項を実装してしまうと、本来の目的である概要レベルの確認よりも、この時点ではどうでもよい些細な事項に目を奪われ、目的を果たすことが難しくなります。さらに、その詳細事項を見てしまったために、(その時点ではどうでもよさそうな)他の詳細な要求事項が提示されることも多いと思われます。
詳細設計時点でのプロトタイプで概要レベルの域を脱さないプロトタイプを提示しても効果がないのは言わずもがなです。
■プロトタイプは目的を果たしたら廃棄せよ■
プロトタイプのことを説明した技術的な書籍、情報処理試験関連解説書などには「使い捨てプロトタイプ」と「製品化するプロトタイプ」のような説明が見られます。もちろんそのようなモノがあることは認識しておくべきですし、否定はしませんが、特に後者は注意が必要です。

Capers Jones氏によれば、
「使い捨てプロトタイプ」「タイムボックス型プロトタイプ」は要求定義の増大を押さえる効果的な欠陥予防アプローチとして役立つが、「進化型プロトタイプ」は残念ながらソフトウェア品質に関しては問題となることがある。(書籍「ソフトウェア品質のガイドライン」より)

ということで、いつもの通り「実績データ」によってこのことを説明しています。

「使い捨て」は主に要求引き出し、「タイムボックス型」は実現可能性調査を目的としますが、その結果を使って「設計」を行うことになります。
そして設計終了後にはあらためてソフトウェア構築を行う。つまりプロトタイプは「廃棄する」ことになります。

「せっかく作ったのだから、棄てるなんて。効率的な開発にならないじゃないか!」という方がいますが、そのような方の中には「設計を蔑ろにして作業を行うくせのある人」も含まれているように思います。
そのような方は「手抜き」をしたい口実に「プロトタイプを使う」ということです。
「目的以上、設計未満(中途半端)なプロトタイプ」は「その場しのぎ」でしかありません。
目先の効率性を追求すれば、ソフトウェア品質に悪い影響を与え、結局高くつくことをお忘れなく。
私のお奨めは、「腕利き技術者だけの組織以外の場合は、目的を果たしたらプロトタイプを廃棄せよ。」です。
ソフトウェア開発言語を熟知し、最適なソフトウェアを構築することが可能な優秀な技術者であれば、進化型を使用することが可能、ということになると思います