最近ではゲームやアプリなどの配布バージョンとして、アルファ版やベータ版といった呼び名が広く知られるようになりました。利用者としては正式リリース前に先行体験できるなどのメリットがあり、リリース前の不完全なバージョンであったとしても、多くの人がその状態のソフトウェアを歓迎し、利用しています。
「アルファ版」や「ベータ版」は、一般のユーザーが製品をリリース前に先行体験することが出来るという点では同じですが、ソフトウェアの状態としては大きな違いがあります。今回は、アルファ版・ベータ版の違いと共に、その他のバージョン(マイルストーン)についても紹介します。
アルファ版とベータ版
IT業界では、ソフトウェアを制作する過程において、一般に公開する・しないに関わらずアルファ版(Alpha版)やベータ版(Beta版)といったバージョンが制作されます。
これらはプロジェクトの進捗を管理する上で必要なもので、いずれも基本的には一般の人に利用してもらうために用意しているものではありませんが、様々な目的の基に、一般ユーザーに公開するアルファ版やベータ版を作成することがあります。
アルファ版やベータ版は「マイルストーン」
マイルストーンとは、プロジェクト進行における「中間目標」や「区切り」を指す言葉で、IT業界では頻繁に使われます。
アルファ版やベータ版というバージョンは、ITプロジェクトのマイルストーンの名前です。
マイルストーンの種類は、他には以下のようなものがあります。
- 要件定義完了
- 外部設計完了
- プロトタイプ版作成など
マイルストーンの目的と中間成果物
マイルストーンでは、何らかの「中間成果物」を作成することが多く、作成物はプロジェクトの進行フェーズによって異なります。要件定義や設計では「設計書」などのドキュメントを、プロトタイプ版やアルファ版のような制作が進行している場合は「プログラム」を含めた成果物をまとめます。
アルファ版とベータ版の違い
一般のユーザーが目にする機会が多い「アルファ版」と「ベータ版」は、ITプロジェクトのマイルストーンとしては大きな違いがあります。
| マイルストーン | 意味 |
|---|---|
| アルファ版 | 実装完了バージョン |
| ベータ版 | 評価(テスト)完了バージョン |
それぞれについて詳しく確認してみましょう。
アルファ版は「全機能実装」バージョン
アルファ版は「製作途中バージョン」と勘違いをされることが多いですが、基本的には「全機能実装バージョン」が大前提です。
アルファ版のマイルストーンの目的は、「テスト工程を開始すること」にあります。
ソフトウェア制作のテストには様々な方法がありますが、基本的には「製作途中」のバージョンはテスト対象には成り得ません。プログラム作業中にも動作確認・テストは行いますが、これは製造工程におけるテストであって、ここでいう「テスト工程」とは意味合いが異なります。
アルファ版を使って行われる「テスト工程」
一般的にテスト工程では、テストや評価をする専門のチームや人員が割り当てられ、独自のスケジュールに沿って順番にソフトウェアのテストを実施します。そのため、各担当者に「評価対象のソフトウェア」を配布する必要があります。これが実際のアルファ版であり、全ての機能のテストを行うためには全機能が実装されている必要があります。
テスト工程で実施したテストの結果報告には、必ず「実行したバージョン」を明記することになります。プログラムが異なっていると同じ問題を再現することができないことがあるため、バージョンの管理はとても重要です。
未実装の含まれたアルファ版の危険性
アルファ版に未実装項目があると、テスト作業中に別バージョンに移行しなければならなくなります。そうすると、テスト済みの項目の挙動が変わってしまう可能性があるため、基本的には「やり直し」となってしまいます。これはプロジェクト全体の大幅な遅れを引き起こすため、制作チームはアルファ版のマイルストーンまでに必ず全ての機能を実装しなければなりません。
修正バージョンを作成する場合には、影響範囲の扱いは責任者を交えて慎重に話し合います。再テスト範囲を、スケジュールや人員と照らし合わせながら調整する必要があるからです。
ベータ版は「評価完了」バージョン
ベータ版は、プログラムの製作から評価(テスト)まで全ての工程が完了し、開発・製造の部署から外部へ成果物を出す準備が整った状態であり、「評価完了バージョン」と言えます。
ベータ版についてネットなどで調べると、「リリース前にユーザーに体験してもらうためのバージョン」と説明されていることが多いですが、利用者に体験してもらわない(公開しない)ベータ版の方が圧倒的に多いため、その説明は適切とは言えないでしょう。
ゲームなどがベータ版として提供されている場合は、予定していた「テストは完了している」状態で、基本的には完成品とは遜色のないものです。
ベータ版とリリース版の違い
リリース版(Release版)として一般公開されるのは、プログラム以外のデータをリリース用のデータに差し替えるなど、「営業的な処置が施された」ものとなります。
具体的には画像データなどのリソース差し替えやインストーラーの調整、ダウンロードページの準備などが行われます。ソフトウェアの構成にもよりますが、実行プログラムはベータ版と同じものであることも多いです。
ベータ版のマイルストーンは、制作プロジェクトの中ではいよいよ最後という時期に設定されます。その後の作業は納品物をまとめたり、販売促進系の営業活動などになるため、制作プロジェクトとしては役目を終えるためです。
ただし、不測の事態(バグの発覚など)のための保険としての予備日程が設けられたり、受託開発の場合は先方の「受け入れ試験」への対応日程がある場合もあります。
アルファ版・ベータ版以外のマイルストーン
IT業界のプロジェクト管理では、「アルファ版」や「ベータ版」以外のマイルストーンを設けることは珍しくありません。特に、複雑なものや大規模なソフトウェアの制作進行の場合は、最終的な日程(納期や公開日)を厳守するためにも、中間チェックポイントは重要になります。
ここでは、アルファ版やベータ版以外にどのようなマイルストーンが設けられているのかを紹介します。
アルファ版よりも前のマイルストーン
Alpha版は、ソフトウェア制作工程の中で最初のマイルストーンであることが多いですが、プロジェクトによってはそれよりも前にマイルストーンを設けることがあります。Alpha版よりも前のマイルストーンということは、機能実装がすべて終わっていない「未完成品」ということになります。
一部機能の実装バージョン – Pre-Alpha版
Pre-Alpha版というのは、名前の通りAlpha版のPre(前)のバージョンです。アルファ版が全機能実装なのに対し、Pre-Alpha版では一部の機能が実装されていない状態となります。
全ての機能が実装されるよりも前に、「大きな機能についての事前確認や一部の評価を行う必要がある場合」に設けられることがあるマイルストーンで、プロジェクトマネージャーの判断と各担当部署の合意で実施されます。
機能が完全に分離できる場合に、部分的な評価を開始することでスケジュールの圧縮を図ったり、本格的な評価が開始される前に大きな問題を洗っておくことで、その後の評価工程の安定化をするという目的等で設けられます。小さなプロジェクトの場合は直接アルファ版で確認するため、Pre-Alpha版のマイルストーンが設けられないことも多いです。
エンジニアの技量が問われるPre-Alpha版
大規模なプロジェクトの場合、Pre-Alpha版が複数回設けられることもあり、その場合はPre-Alpha1, Pre-Alpha2といった呼称が用いられることがあります。それぞれのマイルストーンでは、確認する項目(実装される機能)が定められており、開発と評価の担当が連携して作業を進めます。
この場合、開発を行うエンジニアの実装方法が非常に重要となります。「完全に切り分ける」実装をすることで評価の重複作業を回避しなければなりません。
実装の切り分けが難しい場合は、評価担当と詳細な擦り合わせを行うことで、評価項目の調整を行ったり、Pre-Alpha版を断念するといった判断がされることになります。
評価しないPre-Alpha版もある
評価担当が評価作業を行わないPre-Alpha版というものもありえます。
重要な機能の実装を先行して「完全に終わらせる」という目的意識をプロジェクトマネージャーと開発責任者で共有し、期日を設定すると、その日がPre-Alpha版という名目になることもあります。
マイルストーンにPre-Alpha版のような名前を付けず、○○実装版のような中間成果物を生成するだけということもあるでしょう。この辺りは企業やプロジェクトマネージャーの方針や進め方に完全に依存する部分です。
状況を確認するバージョン – Sample版
Sample版は、Pre-Alpha版と似た内容ですが名称が異なります。主に制作担当者以外に状況を確認してもらうために設けられるマイルストーンです。
Sample版は、画面や機能などの大筋(仕様設計)に誤りがない事を、早い段階で確認してもらうことを目的として、プロジェクトマネージャーと発注者(企業)との間で儲けられるマイルストーンです。
発案はプロジェクトマネージャー側である事が多く、要求仕様や要件定義で「危険」と判断されたものに対して、「念のため現物で確認を取る」ために提案します。
Sample版はプロジェクトマネージャの危険予測
仕様書や設計書といったドキュメントにまとめている段階で、プロジェクトマネージャーやシステムエンジニアが「危険」と判断する内容については、あらかじめ指摘をして改善を行いますが、それでも先方の強い希望で「危うい」内容のまま進めざるを得ないといった状況は起こります。
Sample版のマイルストーンによって、「そうは言ったけど本当にこれでよいのか」と確認をすることができ、「最後のどんでん返し」を防止することに役立ちます。
Sample版のマイルストーンは、プロジェクトマネージャーやシステムエンジニアといった上流工程のエンジニアたちの危険予測のスキルによって設けられているといえます。
Sample版とPre-Alpha版の違い
Sample版を提供する場合には、「実装されていない項目」を明確に伝えますが、その上で更に「不安にさせない状態」とする必要があるため、場合によっては「画面遷移できなくする等の特別な処置」が施されることも多いです。
こういった配慮があるという点でも制作部署間でのやり取りであるPre-Alpha版とは異なり、マイルストーンとしてはSample版のような一般的に分かりやすい名前で設定されることが多いですが、企業やプロジェクトによっては違う名前で呼称されることもあるでしょう。
オープンベータ・クローズドベータって何？
ベータ版は、「テスト工程が完了した」バージョンですが、オープンベータ(Open Beta)やクローズドベータ(Closed Beta)と呼ばれるバージョンは、ベータ版であるにも関わらず「テスト」を行う目的で配布されるものです。
オープンベータやクローズドベータと呼ばれるバージョンは、IT企業内で評価(テスト)が難しい項目のテストを実施するために、一般のユーザーたちの協力を受けながら、様々な項目について確認を行うバージョンです。
ソフトウェアのテストは、基本的には企業側の設備と人員をもって実施されるものですが、インターネットを介して提供されるサービスなどの場合、実際に利用される状態を再現して確認することが困難なテスト項目がいくつか出てきます。
実際のサービスの提供を開始する前に、限定的な公開(Closed Beta)や、テスト的な一般公開(Open Beta)といった形で、利用者にテストに参加してもらう形式がとられます。
オープンベータやクローズドベータの目的
代表的な物は「インフラ」で、ネットワークの回線やサーバーの負荷耐性などは、一般の人からの実際のアクセスがないと非常に評価が難しいのです。また、ゲームソフトなどでは、ユーザーの声などを参考にしながらゲーム内のバランスなどを最終調整するといったことも行われます。
余談ではありますが、IT業界の名誉のためにも少し補足しておくと、インフラの耐久テストなども可能な限りIT企業内では行われています。人員を1万人集めて同時アクセスというのは実現が難しいですが、疑似的に通信を同程度発生させての負荷・耐久試験というものは実施されたりもします。しかし、様々な回線・経路から同時多発的に発生する実際の通信とは条件が異なるため、問題を完璧に洗い出すことが難しいというのが現状です。
これは通信内容が複雑なものほど顕著で、自動的な負荷・耐久試験では「複数の回線から特定の操作が同時に行われた場合」のような限定的な障害を取りこぼしてしまう危険性があります。高い品質のソフトウェアを提供するために、可能な限りの手段を講じているのがOpen/ClosedなBeta Testという訳です。
アルファ版やベータ版の品質で分かる事
アルファ版やベータ版の意味が分かっていれば、IT業界の業務の流れを経験したことがなくても、ソフトウェアの品質からプロジェクト進行の体制や人員の能力が透けて見えてくるようになります。
例えばベータ版と銘打ってリリースされた製品が、酷い品質であった場合、残念ながらそのプロジェクトの体制は健全とは言えないでしょう。評価(テスト)が終わっているのにバグだらけという状態であれば、スケジュールなのか構成スタッフなのか、どこかしらに問題を抱えていると考えられます。
アルファ版の名前でリリースされた製品は、不具合が出て当然のバージョンです。逆にそれでよい品質であった場合、製作陣営の中でも特にプログラマーなどのエンジニアが非常に優秀であることが伺えます。
酷い品質のアルファ版・ベータ版の意味
企業やプロジェクトによっては、テスト工程のコストを抑えるために、早めに一般向けに中間成果物(Beta版など)をリリースすることで、品質向上の作業量を利用者に肩代わりさせようとすることがあります。
酷い品質のアルファ版やベータ版を公開した場合、その対価はソフトウェアや企業の評判ということになりますが、テスト体制が十分確保できない場合などに仕方なく選択されます。
こういった悪質な状態のソフトウェアは、アルファ版やベータ版といったマイルストーンを超えた後も、本質的な体制や予算の問題がクリアになることは少なく、その後の大幅な品質の向上は期待できないでしょう。一度こういった低品質のスパイラルに入ってしまうと、腐った土台の上に建てた建築物のように、IT業界のプロジェクトも立て直しが非常に困難になってしまいます。
一般向けに提供されるアルファ版やベータ版を触った際には、ただ先行体験を喜ぶだけでなく、ソフトウェアの品質を確認して、正式リリース版を購入するかどうかも含めて真剣に見定めるようにするとよいでしょう。
コメント