Make組ブログ

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

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）

Django Web中級シリーズ WSGI

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

blog.hirokiky.org

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

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

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

gunicorn やuWSGI、 waitress といった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.py や urls.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 Vue.js JavaScript

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

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-family と content を指定して <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サーバーまで

Python WSGI Web中級シリーズ

まえがき

このブログ記事は、ある大きなドキュメントの一部のために書いています。 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 という名前のファイルを作って、ファイルに上記の関数を書いているとします。 gunicorn を pip でインストールすると、ターミナルからサーバーを起動できます （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の宿屋は「必要な無駄」 だと思います。 無駄だけど気持ちとして必要 な場合があるということですね。

宝探しと仏像彫刻と、ものづくり

考え

あなたが何かを作るとき、どういうイメージでものを作っていますか？

日経なんかを読んでいるとスタートアップが買収されたとか不祥事をおこしたとか事業撤退、転換したという話を毎日読めます （僕は日経とかそういうニュースは好きで読んでいます）。

そういう話題の中にある「ソフトウェア開発」や「起業」はみんな「宝探し」をしてるんじゃないか？と思いました。 買収する人も買収される会社も、何かを作る人も売る人も、みんな宝探しをしてるように感じることがあります。 でも僕がしたいのは、仏像彫刻とか、そういう別なものなイメージだなと思った。今日はそんな話です。

（単なる気持ちになったという話なので、何の知見もありません。また、誰かや何か、何かしらの主義や思想を否定する文ではありません）

ここでいう「宝探し」とは何でしょうか。僕の単なるイメージなんですが、大きな砂山かゴミの山があって、人間がその中に飛び込んだり掘り進んだりして、お宝を物色するイメージです。 あれでもない、これでもないと手に持つものを取っ替え引っ替えしつつ、いつか巡り合う最高の価値あるものを探しているように思います。 ソフトウェア開発、投資、起業、どの文脈でも構いませんが、「宝探し」的な「ものづくり」をしている人がいるなと感じています。 ゴールドラッシュに例えられがちなのも、そういうイメージが一致しているからなんじゃないかなと思っています。

それもワクワクするし、僕も「かっこいいな」と思いますが、僕がやりたいことは実は少し違うんじゃないかな、と思ったんです。 もっと僕のしたいものづくりは、仏像彫刻とか、旋盤の切削加工のようでありたいということです。 他に近いイメージは建築とか、旋盤とか、陶芸とか、盆栽のイメージです。 このイメージは何かを漠然とした中から探し当てるのでなくて、すでにある何かから目的のものを削り出したり整えていくイメージです。 カッコつけるなら魂を込めていくと言っても良いかもしれません。 このイメージに沿って考えると、この「ものづくり」の思想は1つのものを作るのにはかなりの時間がかかるだろうと思います。 何か対外的な正解を見つけるのなくて、内側にある何かを求める作業になります。内から出る良さというか、にじみ出るすごさみたいなものを作る作業です。

宝探しと彫刻、どちらが「正しい」のかは僕は分かりません。ただ僕は彫刻のようなものづくりをしていたいです。 正直に言うと、「数週間で作ったこのサービスが何万ユーザー獲得！」みたいな話を聞くと残念な気持ちになります。 製品の良さやユーザーさんへの価値を掘り下げれてないように思えるからです（もちろん、短期間で本当に良いものを作ってる人もたくさんいます）。

もちろん早期のフィードバックを得ることは何より大事ですが、自分たちですら納得のいっていないものを多くの人に届けていいのでしょうか （知り合いとか、よほど興味のある人には良いと思います）。 とても良い才能を持ってる人が、アテンションを集めるためや、早々に売り切るために人生を無駄にしているように思えてしまいます。 本質は製品であったり、使って本当に喜んでくれる人の近くにあるんじゃないでしょうか、と僕は思っています。

スタートアップとか起業の本を読むと、「宝探し」が良いという話が多いように思えます。 ですがそうでない本もあって、例えばリーンスタートアップは僕が読んだ印象では彫刻家よりな発想に感じました。 リーンアナリティクスも、拡大の前にエンゲージメントに注力するよう説いていますし、そっちの解釈で僕は勝手に共感しています。

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

起業の科学という本もリーンスタートアップの影響を強く受けている本で、ピボットするべきかどうかの判断について書かれています。 そのなかで「やりきっていないピボット（UX改善や機能の磨き込みをやらずにピボットしてしまうこと）」は良くないと具体的に書かれています。

[asin:4822259757:detail]

この「磨き込み」という表現が好きで、この部分以外も含めて良い本だと思います。

PyQ も作りはじめて2、3年くらいになりますが、ようやっと自分的にも納得がいき始めたラインです（まだまだ納得できていません）。 PileMd も単純なノートアプリのわりに、構想から足掛け1年以上、余暇で作り続けていた記憶があります。 正直、まだ僕の作った（作っている）ものは「こいつはマジすげぇな」と僕がドップリ心酔できるレベルに至っていないと自分で思っています。 もちろんマジですげぇ製品たちですし、人に十二分に価値を届けられるものだと思っているので、公開したり、サービスとして売っています。 ただ、木橋ミュージアムやマツダロードスター、スタジオピクセルの洞窟物語やCELESTEみたいなものには、まだ至れていないなと自分で思っているという意味です。

いつになったら作れるのか不安にすらなります。

kkaa.co.jp

www.mazda.co.jp

store.steampowered.com

store.steampowered.com

最近行った、建築の日本展という美術展もとても良かった。そういった工芸的な芸術性や、簡素な中にある深みとこだわりを感じれて良かったです。

www.mori.art.museum

僕は自分の作りたい製品があって、Webサービスや自分のものを作り続けていますが、人によって「サービス開発」や「起業」というものに思うものは違うんだなと最近よく思います。 「Webサービス開発者どうし」、「クリエイターどうし」、仲良くやっていきましょうとも言いますが、僕は人がそれぞれ見てるものは全く違うと思います。

僕はたぶん、「スタートアップ」になりたいわけじゃないのだなと最近思います。すごく憧れますし、かっこいいとずっと思っていますが。 僕は単に、良いものづくりをして、それを使ってもらいたいだけなのかなと思います。 高専で旋盤を回していたときから、このMake組ブログを作ったときからずっと、単に自分の作りたい良いものを作って誰かの役に立てば良いなと思ってるだけなんでしょうね。

そんなことを考えていた、PyConJP明けの休暇でした。