Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
5
Help us understand the problem. What are the problem?
@u83unlimited

GUIアプリのバージョニングについてとりとめもなく考える

はじめに

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

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

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

方針

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

メジャーバージョン

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

GUIアプリはAPIの概念が弱いので、メジャーバージョンを上げるとするならばこういうケースが妥当かと思われます。特に大事なのが1.で、UIとUXの結びつきを考えれば大幅なUI変更でもメジャーバージョンを上げる理由になりうると考えます。
また有料GUIアプリの場合は「メジャーバージョンが上がる=別のアプリになった」として捉え独立させるという手段が存在することに注意が必要です。「有料アプリ ver2」じゃなくて「有料アプリ2 ver1」みたいな感じですね。

マイナーバージョン

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

ここが擦り合わせの中心地であり、困難な場所ですね。特に人によって「機能」の粒度と重要度(=UXの変更具合)が違うことが難しさの原因だと思います。
例えば「SNS連携機能」とか「クラウドバックアップ機能」を後付けで入れるとするじゃないですか。開発側からしたら機能が増えてるし工数もかかると思うので、マイナーバージョンを上げたくなりますが、ユーザーからすればアプリの本質にそれほど影響を及ぼさない、便利機能が増えたぐらいの扱いなので、マイナーバージョンを上げられると大仰に感じられる……みたいな感じですね。

パッチバージョン

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

課題点

開発者視点とユーザー視点で極端に食い違い、バージョニングをつけること自体が困難な場合

例えば開発言語の変更とか大規模なリファクタリングを行い、機能はほぼそのまま(下手すりゃ劣化)なのに内部で走ってるコードは全然違う場合ですね。10年単位でやってるとこういうケースってあるんですよねぇ……。内部的にはver1.5→ver2なんだけどユーザー的にはver1.5→ver1.4みたいな:sob:
この場合、開発サイドのバージョン管理上ではリファクタリング後のアプリを別に独立させる手もあります。しかし開発以外の営業事務やユーザーサイドからしたら当然同じアプリとして認識されるので、二重バージョニング待ったなしですね。

メンテナンスで使用モジュールのメジャーバージョンアップした場合

これも迷いますね。アプリ自体は特に機能増えたりしてないけど、セキュリティとかバグを気にして使用モジュール/フレームワークのメジャーバージョンを上げた場合、パッチバージョンアップ扱いはおかしくない?みたいな感覚があります。個人的には大型モジュールやフレームワークならマイナーバージョンアップ扱いの方がいいのかな~という感じですね。感覚ベースは良くないと思うのですが、線引きが難しいです。

後書き

約2年ぶりぐらいに書き直しました。前の時は本気でまとめきれてなかったんですが、多少はまとまったかな……。
アプリ開発をやってて自分自身この値でいいのかと迷うこともあり、また開発以外の層とのコミュニケーションコストが気になることもあって、何とかならんのかと考えてきました。しかし関わる人数が多くなるにつれ、立場も知識も違いすぎて、誰もが納得いく統一したバージョンの数字を出すのが不可能になっていくと今は考えています。そして二重バージョニングとかタイトル層に染み出す形で対処するのが現実的なんだろうなと思っています。
ただ開発とそれ以外で呼称が違うと、コミュニケーションコストや事務ミスに繋がることを、当事者全員が理解して擦り合わせる努力はした方がいいのではないか……と理想論を語って〆とさせていただきます。

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
5
Help us understand the problem. What are the problem?