最近ではゲームやアプリなどの配布バージョンとして、Alpha版やBeta版といった呼び名が広く知られるようになりました。利用者としては正式リリース前に先行体験できるなどのメリットがあり、リリース前の不完全なバージョンであったとしても、多くの人がその状態のソフトウェアを歓迎し、利用しています。
IT業界では、ソフトウェアを制作する過程において、公開する・しないに関わらずAlpha版やBeta版といったバージョンが制作されます。これらはプロジェクトの進捗を管理する上で必要なもので、基本的にはいずれも一般の人に利用してもらうために用意しているものではありません。
今回は、Alpha版やBeta版のように、IT業界のプロジェクトで作成される中間成果物についてまとめています。それぞれがどういったタイミングで何のために作られているのかは、IT業界で実際に製作に関わっている人以外はあまり知る機会がないかもしれませんが、知っておけば、ゲームなどのBeta版などが制作会社にとってどういった役割を持ったものかを把握できるようにもなりますので、是非参考にしてみてください。
IT業界のプロジェクト管理とマイルストーン
IT業界内でソフトウェア制作を進める場合、案件ごとに人員や予算などを編成したプロジェクト単位で進めるのが一般的です。
IT業界のプロジェクト管理方法は企業によっても様々で、同じ企業内でもプロジェクトの管理者によっても異なった進め方がされることもあります。制作するソフトウェアの種類など、条件によって変わる場合もあります。
今回紹介するプロジェクト管理やマイルストーン(中間目標)についても、広い意味では共通して使われる言葉であっても、企業によって若干扱いが異なる場合があります。特に一般の認識と異なる扱いをする場合には、その違いについてはプロジェクトの全体会議などで周知されます。
ソフトウェア制作のプロジェクトでは、プロジェクトマネージャーまたはプロジェクトリーダーといった人がスケジュールやマイルストーンの設定を行います。マネージャーとリーダーの違いは「人事的な権限を持っているかどうかの違い」と説明されることが多いですが、実際の現場は比較的混同して使われています。広義では「プロジェクト全体の責任者」という認識で間違いないです。
プロジェクトマネージャーは、制作するソフトウェアの全体スケジュールや予算、参加するスタッフの編成など、プロジェクトの進行に必要なありとあらゆることを決定して手配します。
Alpha版やBeta版というのは、ソフトウェア制作のプロジェクトにおけるマイルストーン(中間目標)とも呼ばれ、それぞれ対応した中間成果物を作成するのが一般的です。
今回扱うのは製造～テストの制作工程のみ
IT業界でのソフトウェア制作には、多くの人が様々な形で関わりながら進められていきます。
IT業界のソフトウェア制作がプロジェクトごとに管理されて進められていることは有名なため、勘違いしてしまう人がいるかもしれませんが、IT企業内でプロジェクト化されるのは「制作工程」とも呼ばれる部分だけです。ここでいう「制作工程」というのは、プログラミングなどでソフトウェアを実際に製造する製造工程と、製造されたソフトウェアのテストを行うテスト(評価)工程を指しています。
ですが、実際にはプロジェクト化される前から作成するソフトウェアに関して動いている人たちもいれば、完成してリリースした後に動く部署もあり、そういった部分は同じソフトウェアであってもプロジェクト化されなかったり、別のプロジェクトとして扱われたりします。具体的には、営業部や企画部などの「事前準備」だったり、保守や運営を行う部署の「事後対応」といった部分は、ソフトウェアの制作プロジェクトとは別扱いである事が多いです。
今回の記事では、そういった前後の部分を除いた「制作プロジェクト」内でのマイルストーンやそれに伴う成果物について解説していきます。
マイルストーンごとの成果物
Alpha版やBeta版のような、プロジェクトのマイルストーンでは必ず成果物をまとめます。
成果物の作成というと抽象的に聞こえますが、要は「プログラムをビルドして実行できる状態にまとめる」ということです。ビルドが必要ないWebアプリケーションなどでは、所定のWebサーバーなどにデプロイ(配置)することを指します。
IT業界におけるこの中間成果物は非常に重要で、次の制作工程ではこの中間成果物を中心に作業を進めることになります。
プロジェクトマネージャーは、マイルストーン前後の工程がスムーズに進行できるように、適切なタイミングに中間成果物の作成スケジュールを組む必要があります。プロジェクトに参加しているスタッフは、全体スケジュール以上に直近のマイルストーンを意識して、何があっても絶対にスケジュールを死守するように努めます。もしもこれが制作できなかった場合、その後ろの工程に控えている膨大な予定が狂ってしまい、プロジェクト全体に非常に大きなダメージを与えることになります。
プロジェクトマネージャは、そういった不測の事態が起きた場合の対処も行います。いきなり全体に大問題が発生することを防ぐためにも、各マイルストーンで中間成果物を作成し、諸問題を早い段階で可視化して対処することは重要です。
Alpha版とは
一般的にゲームやアプリなどでAlpha版と聞くと、利用者目線では「粗削りバージョン」くらいの認識ではないでしょうか。雰囲気やニュアンスは近いものがありますが、IT業界では明確な定義があります。
ソフトウェア制作においてAlpha版とは、「全ての機能が実装されてテストが開始できる状態」を指します。「未テスト」状態のソフトウェアなので「粗削り」には違いありません。
Alpha版は全機能実装バージョン
Alpha版は「製作途中バージョン」と勘違いをされることが多いですが、基本的には「全機能実装バージョン」が大前提です。
Alpha版の役割は、「テストを開始すること」にあります。
ソフトウェア制作のテストには様々な方法がありますが、基本的には「製作途中」のバージョンはテスト対象には成り得ません。プログラム作業中にも動作確認・テストは行いますが、これは製造工程におけるテストであって、ここでいう「テスト工程」とは意味合いが異なります。
一般的にテスト工程では、テストや評価をする専門のチームや人員が割り当てられ、独自のスケジュールに沿って順番にソフトウェアのテストを実施します。そのため、各担当者に「評価対象のソフトウェア」を配布する必要があります。これが実際のAlpha版であり、全ての機能のテストを行うためには全機能が実装されている必要があります。
テストの結果報告には、必ず「実行したバージョン」を明記することになります。プログラムが異なっていると同じ問題を再現することができないことがあるため、バージョンの管理はとても重要です。Alpha版に未実装項目があると、テスト作業中に別バージョンに移行しなければならなくなります。そうすると、テスト済みの項目の挙動が変わってしまう可能性があるため、基本的には「やり直し」となってしまいます。
テスト工程の無駄をなくすためにも、Alpha版は必ず全機能が実装されたものである必要があります。
制作工程の中間付近に設定される
プロジェクトマネージャーにもよりますが、Alpha版はプロジェクト制作工程の中間付近にスケジュールが組まれることが多いです。
IT業界以外の人は、「全機能の実装がスケジュールの半分なのか」と驚くかもしれませんが、ソフトウェアの制作は、実装を終えた後に同じくらい評価期間が必要になります。一般的に「バグ」として知られるソフトウェアの不具合を、リリース前に全て洗い出して修正する必要があるためです。これはソフトウェアに限らず、製造業であればどの業界も似た様な傾向があるでしょう。
私たちが日常的に使っているソフトウェアですが、IT業界内でのテストは驚くほどに細かな項目まで確認をしています。
一例を挙げるとすると、名前などを入力する項目があった場合、最も単純な「一般的な名前」の入力だけでなく、「英語や記号が含まれている場合」「空っぽの場合」「ものすごく長い文章などが入れられた場合」など、ありとあらゆるパターンをテストします。当然複数の入力項目があれば、それらすべてに同じようなテストを実施します。実装方法にもよりますが、場合によっては組み合わせテストが必要な事もあり、そういった場合は乗算となって恐ろしい量のテスト項目となることもあります。
テスト工程には、設計には知識と経験が、実施には人数と時間が必要とされます。
Alpha版よりも前のマイルストーン
Alpha版は、ソフトウェア制作工程の中で最初のマイルストーンであることが多いですが、プロジェクトによってはそれよりも前にマイルストーンを設けることがあります。Alpha版よりも前のマイルストーンということは、機能実装がすべて終わっていない「未完成品」ということになります。
ここでは、Alpha版よりも前に設けられるマイルストーンにどのようなものがあるか、代表的な物を紹介しています。
Pre-Alpha版
Pre-Alpha版というのは、名前の通りAlpha版のPre(前)のバージョンです。Alpha版が全機能実装なのに対し、Pre-Alpha版では一部の機能が実装されていない状態となります。
全ての機能が実装されるよりも前に、大きな機能についてあらかじめの確認や一部の評価を行う必要がある場合に設けられることがあるマイルストーンで、プロジェクトマネージャーの判断と各担当部署の合意で実施されます。
機能が完全に分離できる場合に、部分的な評価を開始することでスケジュールの圧縮を図ったり、本格的な評価が開始される前に大きな問題を洗っておくことで、その後の評価工程の安定化をするという目的等で設けられます。小さなプロジェクトの場合は直接Alpha版で確認するため、Pre-Alpha版のマイルストーンが設けられないことも多いです。
大規模なプロジェクトの場合、Pre-Alpha版が複数回設けられることもあり、その場合はPre-Alpha1, Pre-Alpha2といった呼称が用いられることがあります。それぞれのマイルストーンでは、確認する項目(実装される機能)が定められており、開発と評価の担当が連携して作業を進めます。この場合、開発側の実装方法が非常に重要となり、「完全に切り分ける」実装をすることで評価の重複作業を回避しなければなりません。それが難しい場合は、評価担当と詳細な擦り合わせを行うことで、評価項目の調整を行ったり、Pre-Alpha版を断念するといった判断がされることになります。
プロジェクトマネージャーの経験から「切り分け可能」と考えていても、プログラマーがそれに「応じることができない」こともあり、Pre-Alpha版のようなマイルストーンは、プログラマーの評価の分かれ道の一つともいえるでしょう。
Sample版
Sample版は、Pre-Alpha版と似た内容ですが名称が異なります。主に制作担当者以外に状況を確認してもらうために設けられるマイルストーンです。
画面や機能などの大筋(仕様設計)に誤りがない事を、早い段階で確認してもらうことを目的として、プロジェクトマネージャーと発注者(企業)との間で儲けられるマイルストーンです。発案はプロジェクトマネージャー側である事が多く、要求仕様や要件定義で「危険」と判断されたものに対して、「念のため現物で確認を取る」ために提案します。
仕様書や設計書といったドキュメントにまとめている段階で、プロジェクトマネージャーやシステムエンジニアが「危険」と判断する内容については、あらかじめ指摘をして改善を行いますが、それでも先方の強い希望で「危うい」内容のまま進めざるを得ないといった状況は起こります。そういった場合には、「そうは言ったけど本当にこれでよいのか」と確認をすることで、「最期のどんでん返し」を防止し、双方の合意・納得を早めに引き出すことにSample版のマイルストーンは役に立ちます。
提供する場合には、「実装されていない項目」を明確に伝えますが、その上で更に「不安にさせない状態」とする必要があるため、場合によっては「画面遷移できなくする等の特別な処置」が施されます。こういった点でも制作部署間でのやり取りであるPre-Alpha版とは扱いが異なることもあり、Sample版のような一般的に分かりやすい名前で提供されることが多いですが、企業やプロジェクトによっては違う名前で呼称されることもあるでしょう。
Beta版とは
ゲームやアプリケーションなどで、一般の人向けに「Beta版」というバージョンが配布されることがあります。そのため、Beta版はAlpha版よりも広く認知されているバージョンのようにも感じます。
Beta版は、プログラムの製作からテストまで全ての工程が完了し、開発・製造の部署から外部へ成果物を出す準備が整った状態で、「評価完了バージョン」と言えます。
Beta版について調べると、「リリース前にユーザーに体験してもらうためのバージョン」と説明されていることが多いですが、利用者に体験してもらわない(公開しない)Beta版の方が圧倒的に多いため、その説明は適切ではないと感じています。一般の認識とIT業界での認識は異なっていますので注意しましょう。
つまり、ゲームなどがBeta版として提供されている場合は、予定していた「テストは完了している」状態で、基本的には完成品とは遜色のないものです。Release版として一般公開されるのは、プログラム以外のデータをリリース用のデータに差し替えるなど、「営業的な処置が施された」ものとなります。
Beta版のマイルストーンは、制作プロジェクトの中ではいよいよ最後という時期に設定されます。その後の作業は納品物をまとめたり、販売促進系の営業活動などになるため、制作プロジェクトとしては役目を終えるためです。ただし、不測の事態(バグの発覚など)のための保険としての予備日程が設けられたり、受託開発の場合は先方の「受け入れ試験」への対応日程がある場合もあります。
評価完了してないBeta版 – Open BetaやClosed Beta
Beta版は、「テスト工程が完了した」バージョンですが、一般向けには違ったニュアンスに使われることもあります。
Open Beta TestとかClosed Betaといった言葉を聞いたことがあるでしょうか。これらはBeta版であるにもかかわらず「テスト」を行う目的で配布されるものです。
ソフトウェアのテストは、基本的には企業側の設備と人員をもって実施されるものですが、インターネットを介して提供されるサービスなどの場合、実際に利用される状態を再現して確認することが困難なテスト項目がいくつか出てきます。代表的な物は「インフラ」で、ネットワークの回線やサーバーの負荷耐性などは、一般の人からの実際のアクセスがないと非常に評価が難しいのです。
そのため、実際のサービスの提供を開始する前に、限定的な公開(Closed Beta)や、テスト的な一般公開(Open Beta Test)といった形で、利用者にテストに参加してもらう形式がとられます。
余談ではありますが、IT業界の名誉のためにも少し補足しておくと、インフラの耐久テストなども可能な限りIT企業内では行われています。人員を1万人集めて同時アクセスというのは実現が難しいですが、疑似的に通信を同程度発生させての負荷・耐久試験というものは実施されたりもします。しかし、様々な回線・経路から同時多発的に発生する実際の通信とは条件が異なるため、問題を完璧に洗い出すことが難しいというのが現状なのです。これは通信内容が複雑なものほど顕著で、自動的な負荷・耐久試験では「複数の回線から特定の操作が同時に行われた場合」のような限定的な障害を取りこぼしてしまう危険性があります。高い品質のソフトウェアを提供するために、可能な限りの手段を講じているのがOpen/ClosedなBeta Testという訳です。
Beta版よりも後のマイルストーン
Beta版以降は、Releaseに向けて営業活動が活発化します。
一般向けのソフトウェア(BtoC)の場合、店頭デモやプロモーション用のプレイ動画公開などが行われるようにもなります。最近ではストリーマーの人などに協力してもらっての先行体験などが実施されることもあるようです。逆に企業向けのソフトウェア(BtoB)の場合は、納品用のドキュメント整備や印刷物・メディア(CD/DVD)準備などが行われるのが一般的です。
Beta版のマイルストーン以降は、基本的には「テストしない」ため、当然プログラムの更新は行われないのですが、プロジェクトの進行上の中間成果物を作成するマイルストーンが設けられることがありますので、代表的な物を紹介しておきます。
Beta2, Beta3…
残念ながら、十分に品質に気を付けて制作したものであったとしても、リリース準備に入ったプログラムに欠陥(バグなど)が発覚するということは起こり得ます。特に、多くの人の目に触れている店頭や配信者の先行体験中に問題が発生してしまうと、売り上げに影響する様な大惨事になりかねません。これはプロジェクトに携わっている人たちの背筋が凍るような事態で、プロジェクトマネージャーは急いで対処の段取りを整えます。
修正方法・影響範囲と評価方法などを細かく確認した後、必要な期間を算出し、Beta版の修正バージョンであるBeta2版のマイルストーンを設定します。更に問題が発覚すると、Beta3,4と番号が上がっていくことになるでしょう。基本的には「例外的な措置」で、プロジェクト全体としては望ましくない状態です。
不具合対応以外では、リリース前の段階になって軽微な「仕様変更」が発生することも珍しくありません。社長の鶴の一声で微調整が必要となることもありえます。そういった場合にも例外的な措置としてBeta2のようなバージョンを制作することがあります。大規模なプロジェクトの場合は品質を担保する事などを理由に「対応しない」という判断がとられる場合が多いですが、小規模なプロジェクトの場合は臨機応変な対応をすることで「顧客満足度を高める」という判断がされることもあります。
RC(Release Candidate)版
Beta版後には営業的なデータの差し替えなどは行われますが、基本的には「プログラムの修正を伴わない」のが大原則です。外部リソースの差し替えなどがあっても、プログラム内に含まれるデータやリソースの更新はご法度です。配布するプログラムを更新するとなると、影響範囲の洗い出しや再評価項目の確認など、余計な手間が増えてしまうためです。
営業的なデータの準備が整った後で、既に作成されたプログラムと合わせてRC(アールシー)版が作られることがあります。
これはRelease Candidate(リリース候補)の頭文字から名付けられていて、まさにリリースするためのバージョンです。プログラム単体ではなく、配布用のインストーラーや圧縮されたパッケージになることが多いです。RC版を実際に公開・リリースするとRelease版として扱われるようになりますが、Release前に差し替えが発生したりすると、RC2,RC3,…と不毛な連番バージョンが生み出されてしまうことになるでしょう。
このマイルストーンを超える頃には、制作チームが解体されて各担当者は別プロジェクトに参加し始めているくらいで、「プロジェクトの終了」と位置付けてもよいマイルストーンです。
品質で透けて見えるプロジェクトの体制
Alpha版やBeta版の位置づけが分かっていれば、IT業界の業務の流れを経験したことがなくても、その品質からプロジェクト進行の体制や人員の能力が透けて見えてくるようになります。
例えばBeta版と銘打ってリリースされた製品が、酷い品質であった場合、残念ながらそのプロジェクトの体制は健全とは言えないでしょう。スケジュールなのか、構成スタッフなのかは、悪い品質の状態にもよりますが、どこかしらに問題を抱えていると考えられます。
Alpha版の名前でリリースされた製品は、不具合が出て当然のバージョンです。逆にそれでよい品質であった場合、製作陣営の中でも特にプログラマーなどのエンジニアが非常に優秀であることが伺えます。
悪質な企業やプロジェクトの場合、テスト工程のコストを抑えるために、早めに一般に中間成果物をリリースすることで、品質向上の作業量を利用者に肩代わりさせようとすることもあります。対価はソフトウェアや企業の評判ということになりますが、テスト体制が十分確保できない場合などに選択されることがあります。
こういった悪質な状態のソフトウェアは、Alpha版やBeta版といったマイルストーンを超えた後も、本質的な体制や予算の問題がクリアになることは少なく、大幅な品質の向上は期待できないでしょう。一度こういった低品質のスパイラルに入ってしまうと、腐った土台の上に建てた建築物のように、IT業界のプロジェクトも立て直しが非常に困難になってしまいます。
IT業界のプロジェクト管理者は不足している
パソコンやスマートフォンが爆発的に普及したことに伴って、現在IT業界を希望する若い人たちも多いようで、多くの新しい人材がIT業界で活躍するようになっています。
一方で、IT業界内でのプロジェクト管理や仕様設計をする技術者は、日本国内では不足した状況が続いています。プロジェクトマネージャーやシステムエンジニアという言葉は広く認識されていても、実際にその業務を行える技術者は多くありません。技術文書を読んだりプログラムを作るだけでは習得することが難しい、仕様の折衝やスケジュールの調整といった能力が要求されるため、一朝一夕での育成が難しいことに起因しているともいえるでしょう。
現在IT業界で活躍しているエンジニアの方で、プロジェクトの管理に興味のある方は、是非挑戦してみましょう。特に経験が重視される傾向が強いこういった役割を得るチャンスが巡ってきたのであれば、率先してチャレンジすることで将来きっと役に立つ貴重な経験を得られると共に、高い報酬を得る事にも繋がるでしょう。
コメント