Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

仕事で書いた匠メソッドをCacooに移行した

先日、匠メソッドをCacooで書くととても良いという話をしました。 匠メソッドについてや、Cacooで使うメリットは以下を読んでください。

blog.hirokiky.org

そこで PyQ チームでもCacooを使って匠メソッドをしてみることにしました (もともと、開発当初から2年間ほどAstahを使って匠メソッドを書き続けています)。

チーム全員で使えるので、全員で同期してWebでそのまま閲覧、編集できるメリットはやっぱり大きそうです。 今までAstahを使っていましたが、Cacooを使うとチームで同期してメンテしていける点や、ミーティング中に全員で書き込める点などのメリットがあります。

まだ移行したばかりなので、今後より長い間使っていく中でのメリットやデメリットも伝えられるかなと思います。

Cacoo移行した匠メソッド

以下4つのモデルをCacooに移行しました (モザイク処理をしています)。

ステークホルダーモデル

f:id:hirokiky:20181020132854j:plain

価値分析モデル

f:id:hirokiky:20181020133026j:plain

価値デザインモデル

f:id:hirokiky:20181020132948j:plain

要求分析ツリー

f:id:hirokiky:20181020132534j:plain

おわりに

匠メソッドはメリットがたくさんある手法ですが、図がカオス化しやすかったり、メンテされなくなる問題はあります。

PyQ チームでは継続的にPyQの開発を続けているので、匠メソッドも常に見直して更新しつづける必要があります。 定期的に各ステークホルダーの課題や要求を見直すことで、小さなチームでもより効果的な仕事ができるように取り組んでいます。 継続開発するときこそ匠メソッドの、「お客様やステークホルダーの課題や価値に立ち返る。自分たちのビジョンと突き合わせる」という利点がより重要になると僕は思っています。

それを忘れてしまうと、なぁなぁにくだらないものを作ったり、人に言われるがままに物を作って、時間や労力を浪費してしまいます。 Cacooなどの、Webで同期できてチームメンバー全員で編集できる環境で匠メソッドを書くことで、よりその良さを活かせるのではないでしょうか。 ぜひ、匠メソッドを使っている皆さんはCacooで試してみてください!

Cacooで匠メソッドをやると、Webで同期するし同時編集もできるし良い、という話

何かを開発するとき、いきなりエディターを立ち上げていませんか?

製品、サービスを作るときは要求、要件を分析してまとめてから作るのがオススメです。 そんなときに匠メソッドという要求開発の手法を、僕個人も BeProud の仕事でも使っています。

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠メソッドは製品やサービスを「なぜ作るべきなのか」、「何が求められているのか」という要求を、ニーズとシーズから探る手法です。 匠メソッドについて知りたい人はこの本を読んでみてください。 (僕は少し自分なりに変えて使っている部分もあるので、この記事内の図などが少し違うなというところがあっても気にしないでください)。

匠メソッドをするときのよくある悩み

匠メソッドはツールを限定しません。 なので、テキトウなドローツールや付箋紙などでもできます。 聞くところオススメされているのは Astah というツールを使うことで、 匠メソッドのプラグインなども提供されています

ですが、正直なところ、これらの方法でやる 問題はいくつかあります

  • 紙などでやると、 中長期的にメンテしにくい。デジタル化できない
  • Astahなどでは 同時編集できないファシリテーターが図の編集も常にやる必要があってしんどい (Astahにも同時参照しつつ編集などの機能もあるようですが、匠メソッドのように全員が全員同じモデルを密に編集することはできないと思います)
  • オンラインで同期できない
  • ツールによってLinuxなどで使えないなど 環境依存 or インストールが面倒 だったりする
  • いちいち スクショしないとWikiなどに貼れない

ここで僕は Cacoo をオススメします。 僕は最近作ってる個人プロジェクトで、Cacooで匠メソッドをやってみているんですがかなり良いです。 Cacooは匠メソッドにもかなり有用に使えます。

Cacooで匠メソッドをしよう

Cacooはブラウザーで動作するグラフのドローツールです。 以下の利点があります。

  • 環境に依存しない
  • オンラインで同期できる
  • 同時編集できる

これは最of高と言わざるを得ません。 匠メソッドは複数人で共有して書いたり、中長期に渡ってメンテしつつ閲覧、編集することに意味があります。 ですので、誰でも常に見て、編集できることはすごく大切です (ただCacooの同時編集は、個人的に2ブラウザーで試した程度なので、何人もの人がオンライン越しに編集して匠メソッドがうまくいくかは分かりません)。

主に僕は「ステークホルダモデル」、「価値分析モデル」、「価値デザインモデル」と「要求分析ツリー」の4つを使います。 Cacooで4つの図をテンプレート的に書いてみたので見てみてください (仕事の内容が入っているものは見せられないので、テンプレートとして使っている図をお見せします)。

ステークホルダモデル

f:id:hirokiky:20181014152420p:plain

価値分析モデル

f:id:hirokiky:20181014152431p:plain

価値デザインモデル

f:id:hirokiky:20181014152442p:plain

要求分析ツリー

f:id:hirokiky:20181014152455p:plain

Cacooで共有

Cacooの図としても以下のリンクで共有しています。 閲覧のみは誰でもできるようにしています。

https://cacoo.com/diagrams/abZdFWFFiP3PYqED/C2575

テンプレートとして共有するのはどうすれば良いのか分からないですが。

新Cacooはとても良い

この要求分析ツリーなどは新しいCacooのUIで書いています。 新しいCacooを使うと匠メソッドが書きやすくなる良い点がたくさんあります

  • Styleという色味のプリセットがあるので、(要求などに使う)四角形などの背景色、文字色などを一発で指定できて便利
  • 指定済みのStyleを別のオブジェクトに適応できるので、価値分析モデルの「目的」からステークホルダーの要求にスタイルをコピーするとき便利

また全体的にとても使いやすくなりましたし、軽快に動作してとても良いです。

まとめ

匠メソッドをやっているけど Web同期できない同時編集できないファイル形式を気にせずWebで編集、共有したい という悩みがある人は、 ぜひCacooでやってみるのが良いと思います。

僕もまだ手探りで試しているところなので、同時編集してみてうまく回ったかや、大規模なモデルでも動作したかなど教えてください。

匠メソッドはとても有効な手法ですが、書捨てで忘れてしまっては意味がありません。 プロジェクトのメンバーが原点に立ち返りながら、中長期的にみんなでメンテできるようにしていきましょう。

gunicornでPython製Webアプリケーションを動作させよう(DjangoとFlask)

前の記事ではWSGIアプリケーションをWSGIサーバー(gunicorn)で起動する方法を説明しました。 ここではgunicornを使って、Python製WebフレームワークでできたWebアプリケーションを起動しましょう。

blog.hirokiky.org

なぜgunicornなどのWSGIサーバーを使うのか

DjangoやFlaskなどのWebフレームワークを使っているとき、開発時にもサーバーを起動して動作確認をしていると思います。 例えばDjangoであれば python manage.py runserver というコマンドでサーバーを起動できます。 なぜこのサーバーを使わずにgunicornを使うのでしょうか?

理由は簡単に言うと、動作が速いからです。

gunicornuWSGIwaitress といったWSGIサーバーは速く、 安定して動作することを考慮して作られています (何をもって「速い」と言うのかは別の機会に詳しく解説できればと思います)。

なので、一般に公開して多くの人に使ってもらうサーバーなどでは、専用のWSGIサーバーを使うほうが良いです。 「本番環境ではgunicornなど別のWSGIサーバーを使う」と、プラクティスとして覚えておくと良いでしょう。

gunicornのインストール

gunicornのインストールは、その他のPythonパッケージのように pip でインストールできます (ここではpipの詳細や、Pythonの仮想環境を使う方法については説明しません)。

$ pip install gunicorn

gunicornでWSGIアプリケーションを起動する

gunicornをインストールすると gunicorn というコマンドが使えるようになります。 WSGIアプリケーションを起動するには、この gunicorn コマンドを使って起動します。 以下の例では wsgi.py ファイル内の application というWSGIアプリケーションを起動しています。

$ gunicorn wsgi:application

ファイル中のWSGIアプリケーションの名前が application の場合、以下のように名前を省略できます。

$ gunicorn wsgi

どんなPython製のWebフレームワークを使う際にも「WSGIアプリケーションがどこにあるのか」を知っていれば、 gunicornなどWSGIサーバーを使って簡単に起動できます。

Flask製Webアプリケーションを起動する

FlaskでWebアプリケーションを作った場合、 app = Flask(...)インスタンス化した app 自体がWSGIアプリケーションです。 例えば myapp.py というファイル内に app という名前でFlaskアプリケーションがある場合、以下のように gunicorn で起動できます。

$ gunicorn myapp:app

Standalone WSGI Containers — Flask Documentation (1.0.x)

Django製Webアプリケーションをgunicornで起動する

Djangoで作ったWebアプリケーションをgunicornで起動するには、Djangoのプロジェクトディレクトリー内で以下のように実行します (ここで言うプロジェクトディレクトリーは manage.py ファイルがあるディレクトリーの意味です)。

$ gunicorn myproject.wsgi

myproject というのは django-admin startproject ... で決めたプロジェクト名です。 DjangoでWebアプリケーションを作ると、 myproject/wsgi.py というファイル内が自動で作成されます。 この wsgi.py ファイル内の application という値(呼び出し可能オブジェクト)がWSGIアプリケーションです。 この wsgi.py は、 settings.pyurls.py があるディレクトリー内にあります。

How to use Django with Gunicorn | Django ドキュメント | Django

python manage.py runserver コマンドも、この wsgi.py の application を使って起動しています)

Djangoの設定ファイル(settings)を切り替える

起動する際にDjangoの設定ファイル(settings)を切り替えるには、環境変数 DJANGO_SETTINGS_MODULE を指定します。 以下の例では myproject/settings/production.py という設定ファイルを使っています。

$ gunicorn --env DJANGO_SETTINGS_MODULE=myproject.settings.production myproject.wsgi

Djangoの場合、このようにして環境ごと(ローカル環境、本番環境ごと)に設定ファイルを用意して切り替えられます。 この例ではgunicornの --env オプションで指定していますが、環境変数に直接設定しても問題ありません。

まとめ

前回の記事 ではWSGIとは何かと説明しました。 今回はFlask、DjangoなどのメジャーなPython製Webフレームワークをgunicornという本番環境でも使えるWSGIサーバーで起動しました。

次は、gunicornに指定できるオプションの中でよく使うものを説明します。

他のおすすめ記事

blog.hirokiky.org

Spacemacsでvue-modeかつflycheckする

emacs(Spacemacs)+ vueファイルをずっと模索している。

というのもjs2-modeがmmm-modeに対応しないので、JSを書くときにjs-modeで不便だったりする。 web-modeを使っても似たようなものなので、なんとかしたいこの頃。

模索中の設定

.spacemacs に以下追加。

dotspacemacs-additional-packages '(
    vue-mode
    lsp-ui
    lsp-vue
    company-lsp
)

user-configに以下追加

(require 'vue-mode)
  (add-to-list 'vue-mode-hook #'smartparens-mode)

(require 'lsp-ui)
  (require 'lsp-vue)
  (add-hook 'vue-mode-hook #'lsp-vue-mmm-enable)
  (with-eval-after-load 'lsp-ui
    (require 'lsp-ui-flycheck))

(require 'company-lsp)
  (push 'company-lsp company-backends)

グローバルにインストール

$ sudo npm install -g vue-language-server

HTMLのli要素でアイコンフォントを使って、かつ改行時にインデントを揃えるCSS

アイコンフォントを使って li 要素の list-style をカッコよくします。 li要素の list-style でアイコンフォントを一覧の頭に表示するには、以下のように擬似要素を使ってできます。 この例では Material Icons アイコンフォントを使っています。

ul {
    list-style: none;

    li {
        &:before {
            font-family: 'Material Icons' sans-serif;
            content: 'check_circle';
    }
}

f:id:hirokiky:20181003100502p:plain

font-familycontent を指定して <i class="material-icons">check_circle</i> と同じように表示させられました。

でもこうすると、改行のときに文字がアイコンの左側に行ってしまいます。

ささいなことですが、こういうところを手抜きすると一気にダサくなるので調子したいです。 以下のように li 要素にスタイルを追加するとうまくインデントします。

ul {
    list-style: none;

    li {
        text-indent: -1em;
        padding-left: 1em;

        &:before {
            font-family: 'Material Icons' sans-serif;
            content: 'check_circle';
    }
}

f:id:hirokiky:20181003100512p:plain

キレイにまとまりました。 やったー。

WSGIアプリケーションとは?WebフレームワークからWSGIサーバーまで

まえがき

このブログ記事は、ある大きなドキュメントの一部のために書いています。 WSGIを説明している記事やドキュメント、本はたくさんあるので、このブログ記事で新しく説明されることはありません。

本文

PythonのWebアプリケーションは WSGI という仕様に則って開発されています。 WSGIに則って作られたWebアプリケーション(WSGIアプリケーション)は、WSGIの仕様に則ったサーバー(WSGIサーバー)上で動作させられます。

例えばPython製WebフレームワークのDjangoやFlaskはWSGIの仕様に則っています。 これらのWebフレームワークで作ったWebアプリケーションは、WSGIサーバーで動作させられます。 メジャーなPython製のWebフレームワークはWSGIアプリケーションとして作られているので、WSGIを意識する機会は少ないでしょう。

WSGIで動作するWebフレームワーク:

https://wsgi.readthedocs.io/en/latest/frameworks.html

WSGIサーバー:

https://wsgi.readthedocs.io/en/latest/servers.html

WSGIについて詳しくは wsgi.org を読むと良いでしょう。

http://wsgi.org/

極論、WSGIは気にしなくて良い

極論を言い切ってしまえば、WSGはWebフレームワークやサーバーの開発者のためのものです (もちろんピュアWSGIでWebアプリケーションを開発することもできます)。

単に「Webアプリケーションを作りたいな」という人は、そこまで深く知る必要はありません。 以下の1つだけを覚えておくと良いでしょう

  • WSGIサーバーを使えば、Python製のWebフレームワークで作ったアプリケーションを動かせる

ですが、簡単にでも役割や仕組みを知っておけばエラーに遭遇したとき理解が早くなるでしょう。 WSGIサーバーのドキュメントを読む際などにも混乱することが減りますので、簡単にここで説明します。

WSGIアプリケーションを作ってみよう

WSGIという仕様」というと難しいように感じられますが、とても簡単な仕様です。 例えば以下のPythonの関数はWSGIアプリケーションです。

def my_wsgi_app(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    body = "Method was {env['REQUEST_METHOD']}".format(env=environ)
    return [body.encode('utf-8')]

「本当にこれがWebアプリケーション?」というような関数ですが、WSGIアプリケーションです。 この関数を動作させて、ブラウザーでアクセスすると以下のように画面に表示されます。

f:id:hirokiky:20180930182908p:plain

関数の意味は何でしょうか。 それぞれ関数の引数と戻り値は以下のような仕様になっています。

  • environ: HTTPリクエストの情報(ヘッダーの値など)
  • start_response: HTTPレスポンスのコード、返すヘッダーを指定して呼び出すための関数
  • 戻り値: HTTPのボディーになるバイト型のイテラブル

この仕様を満たす関数を作れば、それはWSGIアプリケーションです。 WSGIアプリケーションはWSGIサーバーで動作させられます。 試しにこの関数を gunicorn というWSGIサーバーで動かしましょう。

my_wsgi.py という名前のファイルを作って、ファイルに上記の関数を書いているとします。 gunicornpip でインストールすると、ターミナルからサーバーを起動できます (gunicornのインストール方法などは他で説明します)。

$ gunicorn my_wsgi:wsgi_app

この my_wsgi:wsgi_app という引数は、 my_wsgi.py ファイル内の wsgi_app というWSGIアプリケーションを起動しろという意味です。 ここでブラウザーから http://127.0.0.1:8000/ にアクセスすると、画面には Method was GET と先程のように表示されます。

フレームワークWSGI

DjangoやFlaskのようなWebフレームワークは、ユーザーの書いたView関数やURLのディスパッチャーを読み込んで、呼び出し可能オブジェクトを作ります。 呼び出し可能オブジェクトとは foo() のように呼び出せるオブジェクトで、先程の wsg_app 関数も呼び出し可能オブジェクトです。

この呼び出し可能オブジェクトが、WSGIアプリケーションです。WSGIサーバーはこのWSGIアプリケーションを読み込んで、ブラウザーなどにHTTPを通して結果を返します。

  • ブラウザー: HTTPでサーバーと通信する
  • WSGIサーバー: HTTPの解釈、WSGIアプリケーションを呼び出し、結果をHTTPで返すサーバー
  • WSGIアプリケーション: 上記仕様でHTTPの内容を返すPythonの呼び出し可能オブジェクト
  • Python)Webフレームワーク: Viewなど一部の処理を書くだけでWebアプリケーションが作れるPythonパッケージ
    • ユーザーの書いたViewなどを読み込んで、WSGIアプリケーションとして動作する

このように、WSGIという仕様でPython製Webアプリケーションは作られています。 Python製のWebフレームワークでWebアプリケーションを作ったときは、WSGIサーバーで動作させれば良いと覚えておきましょう。

他のオススメ記事

blog.hirokiky.org

「RPGの宿屋」は必要ない?

今日は、このツイートが良い疑問を投げてるなぁと思ったので、僕の考えをまとめました。

たしかに、記号化したRPGの宿屋の必要性は考える余地はあると思います。

でも価値要素は無いと言い切れるのでしょうか?僕はそう思いません。 このブログ記事では「RPGの宿屋にも意味はある」という立場のもと、なぜそう考えるかを話します (あくまでその立場として書いているということなので、争ってやるという気持ちはありません)。

僕は、 RPGの宿屋の価値要素は「分かりやすい安堵感」 だと思います。

今回の話の元のツイートは、疑問を投げかけるという意味ですごく良いと思っています。 でも、ゲームの楽しみとかワクワク感とか「ドップリ浸かる感覚」とかは、機能的に「こうだからこう」というもの以上の何かが大切なんじゃないかな?と思っています。 それは 楽しむための「嘘のリアル」をどれだけ出すか ということだと思います。 安堵感や帰ってきた感覚を演出できる「RPGの宿屋」はそのために意味がある と思っています。

今回の話では、「宿屋にこういった機能を持たしているゲームもあるので、意味がある」というような、機能よりの話はしません。

僕とゲームについて(読み飛ばし可)

(この節は僕がゲーム好きだよと主張してるだけなので、読み飛ばして良いです)

僕は生まれてからずっとゲームが大好きです。仕事ではゲームに関わったことはない、ただのゲーマーです。 今はSwitchとXBOX ONEのゲームをよくやっています。FPSからRPG、縦横シューティングからパズルまで何でもやります。 TGM(ARIKAテトリス)の基盤も持っています。

最近良かったゲームは CELESTE です。これはまじでやったほうが良いですよ。 あと、この1ヶ月くらいで買ったゲームはマリオパーティの最新作(まだプレイはできない)とか、NiER Automataとか、ドラクエ10とか、ケロブラスター(Switch版)とかですかね。

大切な無駄があるという話

さて本題です。

僕はゲームはその中に存在しているときの気持ちとか、動きの手触りがすごい大事だと思っています。 ゲームをする中で「ドップリ浸かっている感じ」や「ワクワク感」は、単純な機能とか効率とかじゃない要素から生まれると思っています。

RPGの宿屋はたしかになくても良い

先のツイートでは「RPGの宿は不要では」と疑問を投げかけています。 この疑問はすごく面白いと思うし、主張はもっともだなと思います。

意図を汲み取ると、ゲーム内の街の中でわざわざ宿屋に行く必要性はあるのか?ということで、平たい話が「ドラクエの宿屋」をイメージしているのかなと思いました。

宿に歩いて行って回復する。確かに面倒くさくもあります。 「街に入ると自動回復するのはどうか」と提案されていますが、僕が拡大解釈するなら、例えば街に入った瞬間に一瞬ブラックアウトして「休まったよ」という表現すると良いかもしれませんね。

RPGの宿屋は、気持ちとして必要

でも僕は、プレイヤーが戦いから離れて「気持ちを落ち着ける」ために、宿屋とか自宅とかが必要なんじゃないかと思います。 プレイヤーが「帰る場所」、「安心する場所」と認識しやすい場所が必要 だと思います。

もちろん「街に入ると回復案」でも、帰る場所の意図は演出できますが、より分かりやすく直感的な「帰る場所」が大切だと思います。

例えば「宿」、「家」、「ベッド」、これは論理じゃなくて感覚の話です。 感覚的に、人間は「そこに行けば休まる」と知ってるからです。

それを日常生活で知っているからこそ、ゲーム内でもそれを求めるし、あれば気持ちの安心できる場所として機能すると思います。 そして、その場所に一回帰れるからこそ「よし、また戦おう!」と強く思えるんじゃないかなと思います。 (「いや、街で自動回復でも慣れれば安心感でるんじゃね?」という意見にも同意しますし、試す価値は大いにありそうです)。

つまり 「街に入ると回復」は「無駄は少ないけど表現は弱い」 ものになると思います。 「宿屋で回復」は「無駄はあるけど表現は分かりやすい」 ものになると思います。

無駄なリアリティは無駄

「熱砂で金属の防具が熱くなることを気にするプレイヤーはいない」と元のツイートにありましたが、その通りで、当たり前だと思います。

面白くもないリアリティは要らないから です。この要素はゲーム的に全く面白くもないし、気持ち的にも面倒くさいだけなので要らないと思います。 「リアリティ」を勘違いしたゲームにありがちですが、 楽しみとか、気持ち的なプラスにならない「リアリティのある」要素は無駄でしかない と思います。

ゲームは 「楽しめる嘘」、「楽しむために出すリアリティ」というのが大切 だと思います。逆に、不要な表現は排除すべきです。 例えば TF2 というTPSは、被弾したときのダメージ判定が頭でも足でも同じです。 これは「リアリティがない」ですが、このゲームのカジュアルさや「楽しみ」のためには不要だった要素ということです。

「宿屋」や「自宅」は帰る場所として分かりやすい要素だなと僕は思います。 もちろんこれも、ゲームのコンセプトや演出したい感覚に沿えば、排除しても良い要素だと思います。

RPGの宿屋は要らない」話は、「一旦どこかに帰って落ち着きたい」という感覚をどう満たすのかという話に行き着くのかもしれません。

現状を見直すべきゲームも多分にある

ゲームによっては街の設計を見直したほうが良い場合や、宿屋とか回復のシステムそのものを見直したほうが良いものもあります。

ReCoreにおける自宅は、安堵感もさほど無いし、回復もシステム的過ぎて面白味にかけていました。 ドラクエ10 の街の設計は導線を見直したほうが良いと思いますし、どのゲームにも常に改善の余地はあります (ReCoreはゲームとしての改善点は他にも多分にありますが)。

ともかく、「RPGの宿屋」だけでなく「機能性以外の気持ち」とか「プレイヤーと暗黙的に共有できる気持ち」とかは大切だと思います。

機能以外に実は求めているもの

例えばゲーム内で「馬」に乗りたいのは、移動速度をあげるためだけじゃありません。 「馬に乗って平原を走りたい」という、プレイヤーの根源的な気持ちがあると思います。純粋な「馬に乗る」ことに対する憧れみたいなのがあると思います。

他にもゲーム内で「自宅」を買いたいと思うのも、ゲームの世界の中で、自分の安堵できる空間が欲しいという気持ちが大きいと思います。 「回復するため」や「物を置く場所のため」だけじゃない理由があるはずです。 Skyrimとかで家買ってカスタマイズするの、僕はすごい好きなんですよね。家を持っているという所有欲も満たせます。

確かにゲーム内での機能も求めてるんだけど、そこにある「気持ち的な、それ以上」を本質的には求めているんだと思います。

なので、 直感的に「疲れたからベッドで寝たい」という気持ちに答える表現は大事にしたほうが良いと思います 。 街に入って自動回復したら、どんな気持ちになるんでしょうか。僕は、ちょっと冷めると思いますし、あんまり休んだ感がせずゲームにルーチン作業を感じてしまいそうです。 ぶっちゃけドラクエの宿も、カウンターで話すだけでブラックアウトして回復するのでイマイチ だと思います。

まとめ

ゲームなんて、そもそもやってること自体が無駄です。

なので「RPGの宿屋」は、たしかに無駄な場合とか改善の余地がある場合もありますが、それ自体がもたらす「分かりやすさ」とか、「安心感」とか、「帰った感」とか、「あぁ、宿に行ったから休んだのね」っていう気持ちの共有は必要だと思います。 「戦闘で疲れたときに、気持ち的にも帰りたくなる場所」としての役割が明確になるんだと思います。

RPGの宿屋は「必要な無駄」 だと思います。 無駄だけど気持ちとして必要 な場合があるということですね。