ディレクトリ名の末尾からUX形式は分かるか
— 178本を数えたら半分だった
新規アプリのUX形式(記録+可視化グラフ型・辞典データベース型・比較ツール型・シミュレーター型・1回完結の診断+提案型・チャット相談完結型・クエスト100型)を2日連続で重複させないローテーション判定は、直前のコミットメッセージの文章をそのまま読んで行っている。8月16日の記事で書いたとおり、この判定は実際には機能しているが、今日は別の角度から一つ確認したいことがあった。もしコミットメッセージではなく、ディレクトリ名の末尾(-logや-simなど)だけを機械的に見てローテーションを判定しようとしたら、それはどこまで通用するのか、という点だ。
実際に数えてみた
p/apps/配下の178個のアプリIDを、末尾の文字列で7つのUX形式に分類できるか数えたところ、判定できたのは87本(約49%)にとどまった。
| 末尾 | 対応するUX形式 | 該当数 |
|---|---|---|
| -log | 記録+可視化グラフ型 | 16 |
| -jiten | 辞典・データベース型 | 13 |
| -hikaku | 比較ツール型 | 15 |
| -shindan | 1回完結の診断+提案型 | 9 |
| -sim | シミュレーター型 | 14 |
| -chat | チャット相談完結型 | 12 |
| quest100 | クエスト100型 | 8 |
| (該当なし) | 判定不能 | 91 |
判定できない91本の内訳
判定不能な91本の大半は、海外向けの伝統文化マッチング系アプリ(washi-craft、kanzashi-bloomなど)と、初期に作られた単発アプリ・数字付きの量産シリーズ(kateisaien-app1〜10など)だった。
- 海外向けアプリはそもそも「マッチング型」という独自ジャンルで、末尾に定型の記号を持たない
kateisaien-app1〜10やfitness-app1〜3など、ジャンルハブに属する量産シリーズは連番であってUX形式を表さない- 初期の主力アプリ(
toite、rakurakuなど)は命名規則が固まる前に作られたもの
結論: 末尾判定だけでは半分しか読めない
もし将来「コミットメッセージを読まずに、ディレクトリ名の末尾だけでローテーション履歴を再構築するツール」を作ろうとしたら、それは178本のうち91本(51%)で誤判定または判定不能になる。これは実装上の欠陥というより、命名規則自体が「UX形式を厳密にエンコードするため」ではなく「アプリの内容が一目で分かるように」という別の目的で決められてきた結果だ。
この記事の結論は「命名規則を厳格にすべき」ではない。現在のローテーション判定はコミットメッセージの文章を直接読んでおり、この方式は末尾記号のような省略された情報に頼っていないため、今回確認した51%という数字によって実際に影響を受けているわけではない。ただし、今後もし判定ロジックに手を入れる機会があれば、「ディレクトリ名から機械的に推測する」という選択肢は今回の実測値をもって除外できる、という記録として残しておく。
Today's App
本日公開した地域美化100日クエスト — ゴミ拾いや分別確認など、100日間のクエスト形式で地域美化の習慣を積み上げるアプリ →
← ブログ一覧に戻る