Help us understand the problem. What is going on with this article?

GUIアプリのバージョニングに関する考察

はじめに

バージョニングといえばセマンティックバージョニングが有名ですが、ライブラリ向け(CLI)のため、GUIアプリケーションのバージョニングに関してはそぐわない部分もあります。そこでどうやって擦り合わせていくか、どのような課題があるかを整理、考察していきたいと思います。
またバージョンとエディションは違うものとして書きますのでご注意下さい。バージョンは垂直関係、エディションは並列関係として扱います。

アプリケーションならではの考慮事項

  • 開発者だけでなく、(宣伝やユーザーサポートの都合上)ユーザーもある程度認識する
    • このためコード(機能)ではなく、UXが基準となりやすい
    • 特にゲーム系ではコード(機能)が増えなくてもUXが変化する余地が大きい(大規模なバランス調整/シナリオ、イラスト、音楽の追加等)ので、機能単位によるバージョニングに拘ると感覚と合わなくなる。
  • ソフトタイトルとしてメジャーバージョンが使われることが多いが、あくまで別のものとして扱う
    • この違いを利用して、別タイトル化によるバージョンリセットという手法が存在する
  • セマンティックバージョニングで重視されるAPIという概念が弱い(ない)
    • 他のアプリから利用されることは前提としていないorサブの機能である

方針

開発者の都合を優先するが、ある程度まではユーザーにも配慮してバージョニングを行う。ユーザーおよび(会社の場合)営業事務サイド-開発サイド間で混乱するため、双方で二重のバージョニングはできるだけ行わない。
営業、宣伝の際はマイナーバージョン(2ケタ目),パッチバージョン(3ケタ目)の省略を許可する。あるいは大規模な場合はバージョンとは関係ないサブタイトル愛称(開発コード名等/例:MacOS 10.14 "Mojave")を用いたブランディングも検討する。
ただしこの場合も「~版」「~エディション」という表記は並列関係にある版(例:日本語版、英語版/iOS版,Android版等)を出した時に混乱するのでなるべく避ける。……まぁ実際には「スペシャルエディション」とかよく見ますし、おまけ付きレベルだと仰々しいサブタイトルつけられないんですが……。:sweat_smile:
あと開発者以外はセマンティックバージョニングも、バージョンとエディションの違いも詳しく知らないので、法人等の場合はざっくりでいいので周知するよう務める。

メジャーバージョン

  1. (ユーザー/プログラマー以外の視点)ユーザーの体験(UX)が大きく変わる場合に上げる
  2. (プログラマー視点)コア機能の追加、もしくはサブ機能が複数追加され、UXが大きく変化する場合に上げる

アプリはAPIの概念が弱いので、メジャーバージョンを上げるとするならばこういうケースが妥当かと思われます。特に大事なのが1.で、UIとUXの結びつきを考えれば大幅なUI変更でもメジャーバージョンを上げる理由になりうると考えます。
またメジャーバージョンが変わるような大きな変更の場合、アプリ的にはソフトタイトルの変更(=別タイトル化)、およびバージョンのリセットを行う節目でもあるので、検討します。ただしサポート期間等の兼ね合いで2タイトルを並走せざるを得ないこともあり、かえって混乱する可能性もあります。慎重に判断しましょう。

マイナーバージョン

  1. (ユーザー/プログラマー以外の視点)ユーザーの体験(UX)がそこそこ変わる場合に上げる
  2. (プログラマー視点)サブ機能を追加した場合に上げる

ここが擦り合わせの中心地であり、困難な場所ですね。特に人によって「機能」の粒度が違うことが難しさの原因だと思います。今テキストではコアとサブというざっくりとした区切りでうやむやにしてますけど、どこに区分があるのか、あとはその機能が更に小さな機能の集合体なのかとか。

パッチバージョン

パッチバージョンに関してはセマンティックバージョニングの考え方をそのまま適用して構わないと思います。調整、修正レベルですね。

課題点

開発者視点とユーザー視点で極端に食い違い、バージョニングをつけること自体が困難な場合がある。 例えば開発言語の変更とか大規模なリファクタリングを行い、機能はほぼそのまま(下手すりゃ劣化)なのに内部で走ってるコードは全然違う場合ですね。10年単位でやってるとこういうケースってあるんですよねぇ……。内部的にはver1.5→ver2なんだけどユーザー的にはver1.5→ver1.4みたいな:sob: 後、ネットワーク越しの連携周りを始めとして、ユーザーの目に触れにくい部分も差が出やすいですね。

後書き

すんません、まとめきれなくてとっちらかりすぎです:scream: 機能基準かUX基準かみたいな話は書きながら思いついて整理していったんですが、まだまだ混同しちゃってるのでクリアにしたいですね……。あと運用も考慮にいれて書こうとしたんですが、これもミクロな視点とマクロな視点が入り混じってしまってるので整理する必要があります。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away