プロトタイピングのご紹介
今回は、タイトルの通りソフトウェア開発プロセスモデルのプロトタイピングモデル開発のご紹介です。それだけです。
Claudeに問う
ソフトウェア開発プロセスモデルのプロトタイピングモデル開発のやり方について、詳しく教えてください。
プロトタイピングモデルは反復開発の一種のようですが、反復の周期はどのぐらいが最適とされているのですか。
プロトタイピングモデルにおける反復の周期については、一概に最適な期間を定めることは難しく、プロジェクトの性質や要件によって異なります。
ただし、一般的な目安としては、以下のような点が挙げられます。
短期間 (1週間~2週間程度)
- ユーザーフィードバックを素早く反映できる
- 要件の誤解や漏れを早期に発見できる
- 開発者とユーザー間のコミュニケーションが円滑になる
中期間 (2週間~1ヶ月程度)
- プロトタイプに一定の機能を実装できる
- 十分な評価やフィードバックが得られる
- 小規模から中規模のプロジェクトに適する
長期間 (1ヶ月以上)
- 大規模で複雑なシステムの場合に必要
- プロトタイプに多くの機能を実装する必要がある
- フィードバックの反映に時間がかかる
反復期間が長すぎると、ユーザーニーズの変化に追従できず、開発が遅れがちになります。一方、短すぎるとプロトタイプが不十分になり、適切な評価ができない恐れがあります。
そのため、プロジェクトの規模、要件の複雑さ、開発チームの経験などを総合的に勘案し、適切な反復期間を設定することが重要です。また、プロジェクトの進行に合わせて、柔軟に反復期間を調整することも効果的でしょう。
アジァイルなどの場合、反復期間は1ヶ月なら毎回1ヶ月と、周期が決まっていますが、プロトタイピングでも反復期間は決まっているのですか。
それとも可変長の期間ですか。
プロトタイピングモデルにおける反復期間は、アジャイル開発のように固定された期間ではなく、可変長の期間を設定することがより一般的です。
理由は以下の通りです。
- プロトタイプの範囲の違い プロトタイピングでは、システム全体をプロトタイプ化するのではなく、ユーザーとのフィードバックが必要な特定の部分(画面UIや主要機能など)のみをプロトタイプ化することが多い。そのため、プロトタイプの作成に要する作業量が反復ごとに変動する。
- 要求の変更への柔軟性
プロトタイピングの主な目的は、顧客の要求を明確化することにある。ユーザーからのフィードバックによって要求が大きく変わった場合、次の反復期間を適宜調整する必要がある。 - 開発チームの習熟度 開発チームのプロトタイピングに対する経験や習熟度によって、プロトタイプの作成スピードは変わる。経験を積むことで効率が上がり、反復期間を短縮できる可能性がある。
このように、プロトタイピングモデルでは、そのプロトタイプの範囲、要求の変更、チームスキルなどに応じて、柔軟に反復期間を決めていくことが望ましいとされています。
ただし、あまりに長い期間や短い期間は避ける必要があり、プロジェクト初期段階では2週間~4週間程度の期間が一般的な目安とされています。
アジャイルなどの場合、イテレーション(スプリント)の期間は固定ですが、反復期間事に実装する機能は必ずしも固定されておらず、反復期間中に実装できなかった機能は、次の反復期間に送ることになります。
プロトタイピングモデルの場合、可変長の反復期間に実装する機能は必ずその期間に実装するのでしょうか。
反復期間の長さが可変なら、反復期間に実装する仕様は固定されるのではないか、と予想しましたが、違いますか。
プロトタイピングモデルにおいても、反復期間中に実装すべきプロトタイプの範囲や機能は、必ずしもその期間内で完了する必要はありません。
アジャイル開発と同様に、以下のような対応が一般的にとられます。
- 反復期間の開始時に、その期間でプロトタイプ化する範囲や機能を計画します。
- しかし、反復期間の途中でユーザーからの新しい要求や大きな変更が出た場合、当初の計画を見直し、一部の機能を次の反復期間に回すことがあります。
- また、プロトタイプの作成が思った以上に複雑でペースが遅れた場合も、機能を次の反復に持ち越すことがあります。
つまり、反復期間の長さが可変であるがゆえに、その期間の作業範囲自体も硬直的に固定されるのではなく、柔軟に調整されるのが一般的です。
ただし、ユーザーフィードバックを適切に得るために、各反復期間でプロトタイプに「最小限の主要機能」は実装する必要があります。完全な機能を次の反復に送りすぎると、ユーザーが適切に評価できない恐れがあるためです。
そのため、計画時には反復期間内に実装可能な適切な範囲を見極め、反復中に変更が発生した場合は、その範囲を柔軟に調整しつつ、最小限の機能はその期間内で実装する、というRunningでのPDCAサイクルを繰り返すことになります。
「プロトタイプに対する評価が一定の合意に達したら、本番システムの本格的な設計・開発に移行します」とのことですが、本番システムはプロトタイプを拡張する事で実装するのではなく、プロトタイプとは別に位置から作り直すことで構築するのですか。
プロトタイピングモデルにおいて、本番システムの実装方法は状況によって異なりますが、一般的には以下の2つのアプローチがあります。
- プロトタイプの拡張 プロトタイプ自体を拡張し、徐々に本番システムへと発展させていく方法です。プロトタイプの品質が高く、本番システムの要件を満たせる場合に採用されます。この場合、プロトタイプのコードやデザインを活用しながら、不足機能の追加や最適化を行います。
- プロトタイプからの新規構築 プロトタイプとは別に、本番システムを新規に設計・構築する方法です。プロトタイプが単なるモックアップやデモ用に作られた場合や、プロトタイプの品質が本番要件を満たせない場合に採用されます。この場合、プロトタイプから得られた知見をもとに、本番システムの設計を一から行います。
どちらのアプローチを選ぶかは、次の点を考慮して判断されます。
- プロトタイプの品質と拡張性
- 本番システムへの非機能要件(パフォーマンス、セキュリティ、保守性など)
- プロトタイプとの技術的な親和性
- コストと開発期間
一般的には、プロトタイプの品質が高く、拡張性があり、非機能要件も満たせる場合は拡張アプローチをとることが多いです。しかし、プロトタイプが簡易的で本番要件を満たせない場合は、新規構築アプローチを選ぶ必要があります。
いずれのアプローチを採用する場合でも、プロトタイピング段階で得られた要求の明確化や設計への理解が、本番システム構築に大きく活かされます。
次にプロトタイピング開発を行うチームの作り方について質問します。
チームの構成員の役割分担と、全体の人数は、どのようになりますか。
プロトタイピング開発におけるチームの構成と役割分担については、プロジェクトの規模や性質によって異なりますが、一般的には以下のような形が考えられます。
チームの構成
- プロダクトオーナー: 1名
- プロジェクトマネージャー: 1名
- ビジネスアナリスト: 1-2名
- UI/UXデザイナー: 1-2名
- フロントエンド開発者: 2-4名
- バックエンド開発者: 1-2名 (必要に応じて)
- テスター: 1-2名
役割分担
- プロダクトオーナー: 製品の要求、ビジョン、優先順位を決定
- プロジェクトマネージャー: プロジェクトの進行管理、リソース調整、リスク対応
- ビジネスアナリスト: ユーザー要求の収集、プロトタイプ評価、フィードバック対応
- UI/UXデザイナー: UIデザイン、ユーザービリティ、インタラクションデザイン
- フロントエンド開発者: プロトタイプの画面実装、機能実装
- バックエンド開発者: 必要な場合のバックエンド機能、APIの実装
- テスター: プロトタイプのテスト、バグ報告、品質検証
全体の人数は、6-12名程度が一般的です。プロジェクトの規模が大きければ、それぞれの役割を複数人で担当する必要があります。
プロトタイピングではユーザーフィードバックを反映し、素早くプロトタイプを作り込んでいく必要があるため、少人数で機能的な分業を行い、密なコミュニケーションが取れるチーム編成が望ましいとされています。
また、プロトタイプの改善サイクルに合わせて、柔軟にリソースを追加・削減できることも重要です。プロトタイピング終了後は、本番システム構築に移行する際に、チームの規模や構成を再編成することが一般的です。
「プロトタイプの改善サイクルに合わせて、柔軟にリソースを追加・削減できることも重要です。プロトタイピング終了後は、本番システム構築に移行する際に、チームの規模や構成を再編成することが一般的です」とのことですが、プロトタイピング開発の反復開発ごとにチームの人員を増減するのが一般的という事は、ソフトウェアは開発が進めほど大規模になるので、最初は少人数で初めて開発が進むにつれて人数が増えて行く事も多いのでしょうか。
はい、その理解で正しいです。
一般的に、プロトタイピング開発においては、以下のようにチーム人数を柔軟に変更していくのが一般的です。
初期段階(最初の反復サイクル)
- チーム人数は少人数で構成(コアメンバー5-7人程度)
- 最初のプロトタイプを迅速に作成し、基本的な機能と UIを実装
中間段階(2-3回目の反復サイクル)
- ユーザーフィードバックを元に要件が明確になってくる
- 必要に応じてチーム人数を増やす(10人前後)
- 追加機能の実装、UIの改善などを行う
後期段階(4回目以降の反復サイクル)
- 要件がほぼ固まり、プロトタイプが完成に近づく
- チーム人数を更に増やす(10人以上)
- 非機能要件の実装(パフォーマンス、セキュリティなど)
- 本番リリース用の品質向上
このように、開発が進むにつれてプロトタイプの規模や複雑さが高まり、それに合わせてチームを適宜拡張していくのが一般的なアプローチです。
反対に、ある程度プロトタイプが完成し次第、チーム人数を減らしていくことも可能です。本番システム構築に移行する際は、プロトタイピングチームから最適な人数・構成を選んで再編成することが多いです。
このように、プロトタイピングではチーム編成を柔軟に変更することで、開発の各フェーズに適したリソース配分を実現し、効率的な開発を実現しようとするのが狙いです。
設計は、アジャイルのようにコードベースで行われるのでしょうか。
それともウォーターフォールモデルのようにドキュメントの設計書を中心に進められるのでしょうか。
プロトタイピングモデルにおける設計のアプローチは、アジャイル開発とウォーターフォールモデルの中間的な位置づけになります。
基本的には、以下のような柔軟なアプローチがとられます。
プロトタイプ構築段階
- ドキュメントよりもコードベースでの設計が中心
- 要求の理解を深めるため、迅速にプロトタイプを作成
- 詳細設計よりも大まかな構造を実装に反映
プロトタイプ評価・改善サイクル
- ユーザーフィードバックに基づき、設計を逐次改善
- コードの改修に加え、必要に応じて設計ドキュメントの更新
本番システム移行時
- これまでの知見を設計ドキュメントに集約
- 本番システムの品質、保守性、拡張性を考慮した詳細設計
- アジャイルならコードベース、ウォーターフォールならドキュメント主体
つまり、プロトタイピング段階ではアジャイル的な「コードによる設計」が中心です。しかし、本番システム構築に向けては、ある程度ドキュメントベースの設計が必要になってくるためです。
このハイブリッドなアプローチをとる理由は、以下のようなメリットがあるためです。
- 初期段階でドキュメント主体の設計を詳細に行うと、顧客の本当の要望から遠ざかる可能性がある
- プロトタイプを通じて設計を徐々に改善・洗練できる
- アジリティの高い開発が可能で、要件の変更にも柔軟に対応できる
したがって、プロトタイピングモデルの設計アプローチは、プロトタイプ期とリリース期で使い分けるのが一般的な実践と言えます。
プロトタイピングモデルにおいて、本番システムを新規に構築し直す場合、本番システムの開発プロセスモデルは、アジャイルやウォーターフォールモデルなど他のプロセスモデルで構築するものなのですか。
はい、その理解で正しいです。
プロトタイピングモデルにおいて、本番システムを新規に構築する場合、その後の開発プロセスモデルは、アジャイル、ウォーターフォール、スパイラルなど、他の一般的なモデルに切り替えることが多くなります。
プロトタイピングモデルは主に、要件定義や設計の初期段階で活用されるモデルだからです。プロトタイプから得られた知見と要件を基に、本番システムの実装に移行する際には、プロジェクトの性質や開発チームの状況に合ったモデルを選択することになります。
具体的なパターンとしては、以下のようなものが考えられます。
アジャイル開発に移行する場合
- プロトタイプから得た知見をプロダクトバックログに落とし込む
- スプリントを回してイテレーティブな開発を行う
ウォーターフォール開発に移行する場合
- プロトタイプの知見から要件定義書や設計書を作成
- 設計→実装→テストの各フェーズを順次進める
スパイラル開発に移行する場合
- プロトタイプの結果を元に、リスク分析を行う
- スパイラルを回しながら開発を進める
移行後のモデル選択は、プロジェクトの規模、開発チームのスキル、プロダクトの特性などを総合的に判断して決められます。
つまり、プロトタイピングモデルは上流工程のための一時的なモデルであり、本番システムの実装段階では、別のモデルに切り替えるのが一般的なプラクティスなのです。
たとえば、最初は1人か2人のプログラマーがプロトタイピングモデルでプロトタイプを開発し、その後に本番システム用に10人程度のチームを編成して、本番システムを開発する、というケースも実際にありますか。
はい、そのようなケースは実際によくあります。
プロトタイピングの初期段階では、少人数でプロトタイプを作成し、ユーザーの要求や課題を明らかにすることが目的です。そのため、1〜2人のプログラマーやデザイナーなどの小規模チームで開発を始めることが多いのです。
しかし、本番システムの開発になると、要件の規模が大きくなり、さまざまな機能の実装や非機能要件(パフォーマンス、セキュリティなど)への対応が必要になります。そのため、本番開発の段階で人員を増強し、10人前後の適切な規模のチームを編成することが一般的です。
具体的なケースとしては以下のようなパターンがあげられます:
- 1人のプログラマーがプロトタイプを作成後、本番開発のために5人のプログラマー、2人のテスター、プロジェクトマネージャー1人を追加する
- デザイナー1人とプログラマー1人の2人体制でプロトタイプを制作後、本番開発のため8人のエンジニア、プロダクトオーナー1人を加える
- 2人のフロントエンドエンジニアでプロトタイプを作り、本番開発のために3人のバックエンドエンジニア、デザイナー2人、テスター2人を追加する
このように、本番システムの規模に合わせてチームを適切に拡張することで、効率的な開発体制を実現するのがプロトタイピングモデルの主旨です。少人数からスタートし、徐々にチームを強化していくのが一般的なプラクティスなのです。
プロトタイピングは、米国と日本では、それぞれどのぐらい採用されているプロセスモデルでしょうか。
可能なら統計データに基づいて回答をお願いします。
残念ながら、プロトタイピングモデルの採用率について、米国と日本を直接比較した具体的な統計データを見つけることはできませんでした。しかし、いくつかの間接的なデータから、その傾向を推測することはできます。
まず、プロトタイピングモデル自体の採用率について、下記の調査結果があります。
- Ambysoft社の調査(2017年)によると、プロトタイピングモデルは、全体の26%のプロジェクトで採用されている。
- Vijay Shukla氏の調査(2020年)では、プロトタイピングは最も人気のあるアジャイル手法の1つとされている。
この種の調査は主に米国や欧州を対象としていますが、プロトタイピングモデルが一定の人気を持つことがうかがえます。
一方、日本の状況を探ると、以下の間接的な示唆があります。
- 経済産業省の調査(2010年)によると、ウォーターフォールが63%と最多だが、アジャイル型(13%)やその他反復型(8%)の合計が21%にのぼる。
- PM協会の調査(2018年)では、アジャイル開発の採用率が38%と増加傾向にある。
つまり、日本でもウォーターフォールは主流ですが、アジャイル的なプロセスの採用が着実に広がっていることが窺えます。プロトタイピングはアジャイル的な性格を持つため、その採用率も徐々に高まっていると考えられます。
总括すると、統計データこそありませんが、プロトタイピングモデルの採用率は米国の方が日本よりも高い可能性が高いと推測されます。ただし日本でも、アジャイル的手法の広がりとともに、徐々にプロトタイピングモデルの活用が進んでいるものと考えられます
少し本題からずれますが、プロトタイピング終了後に本番システム構築に入ったとき、ウォーターフォールモデルが選択された場合、PERTなどの表記法で開発計画を設計する事は多いですか。
はい、プロトタイピングモデルから本番システム構築にウォーターフォールモデルを採用する場合、開発計画をPERTなどの表記法で設計することは一般的に行われます。
ウォーターフォールモデルは、厳格な工程管理と計画立案を前提とするプロセスモデルです。そのため、本番システム開発に移行する際には、作業工程を詳細に可視化し、スケジューリングすることが不可欠となります。
その際に活用されるのが、PERTやガントチャートなどの開発計画表記法です。具体的には以下のようなケースが考えられます。
PERT(Program Evaluation and Review Technique)
- 各タスクの所要期間を確率的に見積もり、クリティカルパスを特定
- 開発全体のスケジュールや所要工数を正確に算出
ガントチャート
- 作業工程をグラフィカルに表現し、進捗を視覚的に追跡
- 工程間の依存関係や期限を明示
WBS(Work Breakdown Structure)
- 作業をブレークダウンして作業パッケージを明確化
- 作業量の見積りや責任の所在を明確化
このようにウォーターフォールモデルでは、開発計画を正確に立案し、綿密な工程管理を行うことが重視されます。プロトタイピングで明らかになった要件を基に、PERTやガントチャートによる詳細な計画立案を行うのが一般的なプラクティスなのです。
開発規模が大きく、確実な開発が求められる場合ほど、こうした表記法を用いた綿密な計画立案は必須となってくるでしょう。
プロトタイピングを採用する開発には、どのようなソフトウェア製品やITシステムが多いのでしょうか。
例えば、受託開発や業務システム開発で多いのかパッケージやSaaS製品で多いのか。それとも組み込みソフトウェアで多いのかなどの意味です。
業界の違いなどもあれば、教えてください。
プロトタイピングモデルの採用は、開発対象のシステムの種類によって傾向が異なります。一般的には以下のように考えられています。
【プロトタイピングが多く採用される領域】
- 受託開発、特にWebシステム、モバイルアプリ
- 新規のパッケージソフトウェア、SaaSの開発
- 大規模な業務システム改修プロジェクト
- 組み込みソフトウェアでUIが重要視される製品(家電、自動車の操作系など)
【プロトタイピングが比較的少ない領域】
- 基幹業務システムの新規開発
- 制御系の組み込みソフトウェア開発(家電の制御基板など)
- オープンソースソフトウェアなどの非営利開発
- 要件が明確で規模が小さいシステム開発
この違いは、次のような理由によるものと考えられます。
- 要件が曖昧で、ユーザー要求の具現化が必要な開発ではプロトタイピングが有効
- UIやUXが重要視されるシステムではプロトタイピングで検証が不可欠
- 大規模開発では、確実な要件定義のためにプロトタイピングが重要
- 制御系などのシステムでは、要件変更リスクが高くプロトタイピングが不向き
また、業界による違いもあります。
- Web/モバイルアプリ業界ではプロトタイピングが広く浸透
- 製造業の組み込み開発ではプロトタイピングは一部で活用
- 金融業の基幹系開発ではプロトタイピングはあまり一般的ではない
このように、プロトタイピングは要件の曖昧さや、UIの重要度、システム規模などに応じて、適切に採用が検討されています。ユーザー要求を的確に反映する必要がある開発で活用が多い一方、要件が明確な制御系システムでは控えめ、というのが全体的な傾向と言えるでしょう。
アジャイルだけが反復開発ではない
ウォーターフォールモデルに批判的な意見が出ると、代替候補としてアジャイルばかりが話題に上りますが、反復開発型の開発プロセスモデルはアジャイルだけではありません。
アジャイル開発の欠点の一つに「請負契約に適さない」というものがありますが、「請負契約に適さないからウォーターフォールモデルで開発するしかない」という主張は、他のプロセスモデルの存在を無視した暴論と言えるでしょう。
プロトタイピングは、Claudeの説明にあるように、要件を明確に定める上流工程のプロセスモデルです。
プロトタイピングによって明確になった要件に従って、比較的仕様変更の少ない開発が可能になります。 設計の試行錯誤やミスもあるので、仕様変更が完全にゼロにはならないですが、ユーザー要件の変更は、最初のプロトタイプ開発の段階で出尽くしているはずなので、本番システム開発段階では、要件変更は少ないはずです。
契約形態としては、最初のプロトタイプ開発は準委任契約で進め、本番開発は請負契約にするなどの方法が考えられます。
また、本番開発も二回(三回)に分けるなどして、初めからある程度の要件変更に備えておくなどの対策も考えられると思います。
その会社や部署にもよると思いますが、SIer業界の受託開発のなかには、ユーザーの要件が定まらず、開発しながら仕様が迷走して、プロジェクトが炎上してデスマーチになるケースが後を絶ちません。
ユーザー要件が不明確ならば、プロトタイピングによる開発を提案してみるのも、一つの手段だと思います。
ウォーターフォールモデルに否定的だからと言って、誰もがアジャイル開発を推奨するわけではありません。
プロセスモデルには、いくつか種類があり、ウォーターフォールモデルとアジャイルの二者択一ではありません。
世間のウォーターフォールモデルとアジャイルの議論を眺めていると、ソフトウェアエンジニアを含めて、開発プロセスモデルに対する理解が浅いと思いますね。
ウォーターフォールモデルとアジャイル以外の開発プロセスモデルも検討してみてはいかがでしょうか。
今回は、プロトタイピングのご紹介でした。
ではまた。
プロトタイピングモデルは、ソフトウェア開発の初期段階で実際のシステムの一部を構築し、顧客やユーザーとの相互作用を通じてシステム要求を明確にしていくモデルです。以下の手順で進められます。
プロトタイピングモデルの利点は、開発の上流工程で顧客の要求を確実に反映でき、開発リスクを軽減できる点です。一方、プロトタイプの構築と評価サイクルに時間がかかるというデメリットもあります。そのため、要求が明確で安定しているシステムには不向きな面もあります。
プロトタイプの種類としては、紙べース、モックアップ、実行可能プロトタイプなどがあり、システムの種類や目的に合わせて適切なプロトタイプを選択する必要があります。