Make組ブログ

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

Pythonのaiohttpでストリーム(aiohttp.web_ws.WebSocketResponse)をPipeする

最近Pythonの非同期処理、asyncioを使ったプログラムを書いています。 今までは非同期だとNode.jsを使っていたんですが、aiohttpや周辺ライブラリーが揃ってきたようなので使っています。

Node.jsの場合、Streamは stream.pipe(other_stream) のようにPipeできるのですが、それをaiohttpの WebSocketResponse でやる方法を書きます。

Server Reference — aiohttp 3.4.4 documentation

asyncioの Streams でも要領は同じなので参考になると思います。

(注意: Pythonのasyncioやaiohttpはまだ新しいものなので、情報が古くなってないか気をつけてください)

Pipeを1回やる(一方通行の)例

1つのストリームから読み込んで、もう片方のストリームに書き込むのは簡単です。

async for msg in ws:
    await to_ws.send_str(msg.data)

WebSocketでアクセスを受け付けて、バックエンドの別のWebSocketにつなぎ込むaiohttpのView関数を考えると、以下のようになります。

from aiohttp import web

routes = web.RouteTableDef()


@routes.post('...')
async def websocket_gateway(request):
    ws = web.WebSocketResponse()
    await ws.prepare(request)

    session = aiohttp.ClientSession()
    to_ws = await session.ws_connect('...')

    async for msg in ws:
        await to_ws.send_str(msg.data)

    await ws.close()
    await to_ws.close()

この場合、サーバー側のWebSocket ws がクローズすると処理が終了します。

他にも書き込み先のWebSocket to_ws が先にクローズした場合の処理や、 msg.data がバイト列の場合に to_ws.send_bytes にする処理なども必要そうです。

相互にPipeする例

上記の例ではWebSocketは一方通行にしか仲介されていません。ここで、 to_ws からの入力も、 ws に返すようにしましょう。 その場合、 2つの非同期処理を同時に実行する必要があります 。 1つの while ループの中で2つのストリームの読み書きをしても、片方が書き込まないと、もう片方の入力が受け取れないようになるので難しいです。 以下のように別々のループをして、それを asyncio.gather するとうまくいきます。

import asyncio

from aiohttp import web
from aiohttp.http import WSMsgType

WS_CLOSE_TYPES = (WSMsgType.CLOSE, WSMsgType.CLOSING, WSMsgType.CLOSED)

routes = web.RouteTableDef()


async def pipe(f, t):
    while not f.closed and not f.closed:
        msg = await f.receive()
        if msg.type in WS_CLOSE_TYPES:
            break

        await t.send_str(msg.data)
    return


@routes.post('...')
async def websocket_gateway(request):
    ws = web.WebSocketResponse()
    await ws.prepare(request)

    session = aiohttp.ClientSession()
    to_ws = await session.ws_connect('...')

    await asyncio.gather(
        pipe(ws, cs),
        pipe(cs, ws)
    )

    await ws.close()
    await to_ws.close()

asyncio.gather を使うことで、2つの処理を同時に実行して、両方が終了するのを待ってくれます。 優秀なやつですが、今回は片方のWebSocketが終わったら両方終了してほしいので、 pipe 関数内に工夫をしています。

pipe 関数の中で async for msg in ws せずに while ループを使っているのは、両方のWebSocketがクローズしていない限り処理を続けるようにするためです。 そうしないと、片方のWebSocketがクローズしてるのに、反対のWebSocketから書き込まれようとしてエラーになるからです。

こんな感じで、 asyncioaiohttp はかなり刺激的で面白いのでぜひ試してみてください。 誰得情報かもしれませんが、 aiohttpasyncio についての情報を出していけたらなと思います。

プログラミングすると「イライラ」する。向いてない?への回答

ふとこの前プログラミングを教えているときに言われたことです。

プログラミングをしていると『イライラ』してしまうんですが。。

「プログラミングをしてイライラしてしまう自分はプログラミングが向いてないんじゃないか」とか、「良くないことなのかな」というニュアンスでの話でした。その心配な気持ちは分かりますが、 プログラミング中はイライラしても大丈夫なので安心してください 。そういうものです。 むしろ、そこまでイライラするほど真剣に取り組める時点でプログラミングに向いてます。

多少イライラするのは普通なので大丈夫

プログラムが動かないとき、サーバーが止まってしまうとき、環境構築がうまくいかないとき、一生懸命に頭を使ってるんで誰でもイライラすると思います。 プログラミングしているときはイライラして大丈夫です 。するものと思ってください。僕はしてます。かなり。

人間も生物なので、小さいところに閉じこもって頭だけを使っているのは異常な状態です。ソワソワとかイライラとかして当然です。 何なら部屋の中を動き回ったり、足を机に乗せたりしたら良いと思います。僕はしょっちゅうしてます。

もちろんストレスフルでシンドいなら休憩しましょう。でも多少「うーん」とか「なんだよー」とか思ったり、「ダルいなー」とか「うおおおおこのやろおおお」とか思うのは当たり前くらいに思って大丈夫です。

そんなことがあってこそ物ができる喜びとか、使って便利になった嬉しさとか、美しいものを作れた自負とか、そういうものをより大切にしたいなと思います。

フローに対する誤解

プログラマーはいっつもハイに楽しくプログラミングしてフロー状態になっていると思われている可能性がありますが、それはないです。

本当にフローな状態に入っているときなんかはイライラせず何時間でも集中できますが、そんなときが来るのは毎日プログラミングしててもホンのたまにです。 頭の中で出来上がりつつも少しチャレンジングな場合はフローになりやすいですが、世の中そうも簡単じゃないので頭を使って悩みます。

もちろん、いつもフローに近づけるように環境を整備したり体調を整えたり準備はしますが、それでもなかなか難しいレアなものだと思います。

羽生さんもイライラしているらしい

プロ棋士羽生善治さんが似たことを言っていたので紹介します。 僕の中では、この言葉を聞いたときに救われた気持ちになったので共有したいです。

以下、将棋中にどうして扇子を「パチパチ」鳴らすのか、についての答え。

将棋を考えてることってかなりイライラすることなんですよ。 こうやってもこうやってもこうやってもうまく行かないっていう状況を考え続けているんで。

そこですごくストレスが溜まるというか、イライラする。 それを扇子にぶつけてるんですよね。

プロフェッショナル 仕事の流儀 シーズン1 14. file:020 直感は経験で磨く 棋士 羽生善治

プライムにも動画があるのでぜひプライム会員になって見てください http://amzn.asia/d/crRgSRR

羽生さんみたいなプロ棋士でもやっぱり「ああでもないこうでもない」と考えるとイライラするそうです。 もちろん節度はありますが、そういうものと思って大丈夫ですよ、という話でした。

むしろ、イライラしてからが本番です。そのイライラの波に乗るなり、一旦鎮めるなり、もうやめて寝るなり、うまい扱い方をぜひ身につけてください。

DjangoGirlsTokyo 4 でコーチをしました #djangogirls

DjangoGirls Tokyo #4 でコーチをしてきました。 私がコーチをするのは 第1回目 以来です。

djangogirls.org

進め方としては、 Django Girls Tutorial というチュートリアルを参加者の方が進めて学んで、コーチがサポートします。 このチュートリアルはかなり分かりやすい内容で、プログラミング初心者の人でもWebアプリ(ブログ)を作りながら学べるようになっています。 オススメです

さらに、今回のイベントでは参加者の方2,3人あたりコーチが1人ついて、とても手厚く学べる環境だったと思います。

プログラミングやWebアプリ開発を学びたい!という女性の方はぜひ参加してみてください

DjangoGirlsは逆差別なのではないか、への答えの発表もあり良かった

ランチの間は、自由参加で短い5分程度の発表を行いました。 その中でこの発表の内容がとても良かったので共有します。

「女性向け」とするとそれは逆の差別なのではないか、という疑問はあるけど、「気持ちは分かるが、そうではないよ」という内容の発表でした。 現状、プログラマーの人口としては男性が多いです。ですので格差是正のためにこの活動が大切であり、究極なくなれば良いというのは正しいということです。

私もこの考えに共感しますし、運営の体制もバッチリなので、DjangoGirlsにはなるべく協力したいなと改めて思いました。 ぜひ、 コーチとして協力してくれる人も増えてくれると嬉しい なと思います。

他、写真

こちらに素敵なアルバムがあるので、見てみてください。

photos.app.goo.gl

Pythonのtyping.Tupleで可変長のタプルとしてアノテーションする

mypy使っていますか?私は最近プロジェクトにも入れて使っています。

ですが typing.Tuple の扱いがうまく分かっていなくて、こんなプログラムを書いていました。

# 悪い例
import typing


my_tuple: typing.Tuple[str] = ()

my_tuple = ('mymodule.myfunc', 'mymodule.myfunc2')

このプログラムを mypy で型チェックするとこんなエラーがでます。

$ mypy ./tuple.py
tuple.py:4: error: Incompatible types in assignment (expression has type "Tuple[]", variable has type "Tuple[str]")
tuple.py:6: error: Incompatible types in assignment (expression has type "Tuple[str, str]", variable has type "Tuple[str]")

Tupleアノテーションは固定長で使うように想定されているようです。

例えば Tuple[str, int, int, int] のようにして、 ('名前', 1991, 11, 5) のような値を入れる使い方でしょうか。 ちょうど、 NamedTuple に近い印象で、1つの「何か」を1つのタプルで表すような使い方です。

可変長のタプルでアノテーションする

可変長のタプルをアノテーションするには Tuple[str, ...] のようにEllipsis ... を使って明示します

# 良い例
import typing


my_tuple: typing.Tuple[str, ...] = ()

my_tuple = ('mymodule.myfunc', 'mymodule.myfunc2')

typing — Support for type hints — Python 3.7.1 documentation

これでうまく動作します。

例えば以下のようにテンプレートになる基底クラスで、期待する設定値のアノテーションをしておくこともできます。

class MyBase:
    SOME_FIELDS: typing.ClassVar[typing.Tuple[str, ...]] = ()

typing.List はもともと可変長の値でチェックできますが、タプルのときは typing.Tuple[str, ...] のようにEllipsisを書くと可変長と解釈されます。

27歳になりました

今日で27歳になりました

人生とか語り出すなんて、 Break out! 五億年先でいい

「BREAK OUT!」 相川七瀬 より

NANASE AIKAWA BEST ALBUM

NANASE AIKAWA BEST ALBUM "ROCK or DIE"

PyQ とか nullbooks.io とか色々他のものとか、これからも面白いもの作ってくからよろしくね。

作りたいWebアプリのアイディアを迷走せずに作る方法。まず、エディターを閉じることから始めよう

何かを作りたいときは、エディターをいきなり起動してはいけません。 エディターを閉じて、まずはイメージをまとめることに集中しましょう。

なぜこの文章が必要か

なぜ何かを作る前にイメージをまとめる必要があるのでしょうか? 頭の中には完璧な作りたいもののイメージがあることでしょう。 であれば今すぐにでもプログラミングを始めるのが賢明なように思えます。

ですがそうしてはいけません。理由は「作りたいもののイメージは単なる幻想だから です」。

頭のなかにあるイメージはとても素晴らしいものですが、多くの場合は曖昧で、触れられない、価値を検証できないものです。 それを一旦書き出して、まとめていく方法を知っておきましょう。 まとめていく中で作るものがより明確になり、自分でも気づかない価値を発見できます。

  • 作るものをまとめて検証することで、作り始めた後の手戻りを防ぎます
  • 作るものをまとめて明確にすることで、作り始めた後に迷子になるのを防ぎます
  • 作るものをまとめて作業を見積もることで、最小のコストで最大の成果を得られるものから作り始められます

実際には作ってみるまでは価値は分かりません。ですが、何かを作るのはとても高コストです。 本当に天才的な人であれば全てを頭の中でまとめられるかもしれませんが、人は持っている手札で戦うしかありません。

イメージをまとめて検証することで、コストを小さく、精度を比較的高く価値を検証したうえでプログラミングができるようになります。

この考え方を通して、僕はShodoというWebサービスを作りました。

shodo.ink

前提として作るもの

作るもののまとめかた、モックアップの書き方や設計の仕方を、何の実例もなく説明するのは不可能です。 この文章ではWebアプリケーションとしてのECサイトを作りながらノウハウを伝えます。

ECサイト(ショッピングサイト)には以下のような機能が考えられます。 今回のECサイトでは、お昼ご飯用のお弁当を購入して届けてもらうようなWebアプリケーションを考えます。

  • 商品を見る
  • カートに入れる
  • 商品を買う

お弁当を実際に販売するのはサービス事業者でなく、「〜〜弁当」のような実店舗を想定します。 サービス運営者は各店舗にお弁当を登録してもらい、ユーザーが購入するとサービス事業者の配送スタッフが運送します。

この文章ではブラウザーから利用するWebアプリケーションを元に説明しますが、他のスマートフォンサービスやバックエンドのAPIサーバなどにも役に立つ知識になります。 他にも、設計やソフトウェアを作る考え方やプロセスを学んでおけば、スクレイピング処理やバッチ処理を作る場合にも活用できます。 もちろん自分で作るだけでなく、他の人に頼まれて何かを作る場合にも活用できるよう書かれています。

ものを作るには流れが大切

何か新しいものを作るのはとても高度な技術です。 以下のような悩みはだれしもあるかとは思います。

  • 何かを作りたいけど何から始めれば良いか分からない
  • 人にタスクを依頼されて機能の追加はできても、自分で1から作るのは難しい
  • 作り始めてもすぐに目的がブレて迷子になってしまう

大切なのは ものを作る流れを知ること です。

  • イメージや用語、価値を書き出す
  • システム構成やモデルなど大局的な設計をする
  • アプリケーション、プログラムを設計する
  • プログラムを作る、育てていく
  • プログラムをテスト、レビューする

すぐにプログラムを書こうとするのはやめましょう。 今は エディターを閉じましょう。ターミナルを閉じましょう。技術調査をやめましょう。 気持ちや技術先行で作り始めても、迷子になったり大きな手戻りが発生するので無駄になってしまいます。 遠回りしているように感じますが、大きな手戻りが発生したり価値そのものを見失うリスクに比べれば小さいと考えましょう。

たとえば、以下のような手戻りや無駄な実装は往々にして発生します。

  • ソーシャルログインでTwitter, GitHub, Google, Amazonに対応させようとした
    • 実装に1ヶ月かかったけど、サービスのメインになる機能はまだ1つもできていない
    • 使う人は限られているので、ソーシャルログインは不要だった
  • スマホアプリとWebサービス両対応で作ろうとした
    • 最初に扱う商品の購買層は日中の会社員などなので、最初はWebだけで十分だった
  • 商品のレコメンドやオススメを、協調フィルタリングディープラーニングでやろうとした
    • 最初のリリースをしたときには商品の数や種類が少ないので、サイト運営者が選んだ「月間のオススメ商品」を表示すれば十分だった
  • 同じ商品でも色、サイズ違いが選べる機能と作ろうとした
    • 最初に扱う商品には色、サイズ違いがある商品はほとんどなかった
    • 色、サイズ違いがあっても数種類なので別の商品として扱えば十分だった

プロセスよりも大切なもの

この文章では設計という流れ(プロセス)を説明して、もの作りの実践に役立つ方法を説明しています。 ですが、プロセスだけでは不十分です。プロセスは手助けやサポートをするものであり本質ではありません。 もの作りを繰り返すことで磨かれるスキルや、作る中で考えていくことが一番大切なことです。 この文章では何かを作る手助けになるプロセスを説明しますが、実際にやって学んだ経験(スキル、中身、コンテンツ)こそが大切だと覚えておいてください。

何を実現したいかを明確にしよう

手戻りや無駄な実装を回避するために、まず実現したいものを 文章に書き出して明確にしましょう 。 作りたいものは何かを考えましょう。使い手の痛み、悩みに共感して、それを 解決する価値を検証しましょう

この文章では 価値 というものは「実現されることで実現されることでうれしくなる、豊かになること」、 「実現されることで楽になる、痛みが解消されること」と考えています。

実現したいものを書き出す方法

文章に書き出すにも、その観点がないと書き出すのは難しいことと思います。 価値問診票 というものを考えてみましたので、下の質問に答えながら作りたいものが解決する課題、価値を掘り下げていきましょう。

質問1. どんな痛みを解決するもの?

これから作りたいものは、どんな問題や痛みを解消するものですか? 本質的な解決すべき課題や満たすべき要望を明確にしない限り、その解決策(Webアプリケーションなど)を作っても無駄になってしまうのでとても大切です。

例:

  • 仕事に集中していたいのにお昼ごはんを食べる必要がある
  • ランチのためにでかけるのがめんどう
  • 食べるものを決めるのもめんどう
  • 毎日同じ場所で食べるには飽きてしまった

要望や痛みの本質には、人間の本質的な欲求や怠惰、不安があります。 解決する要望、痛みの中に、以下のような人間の本質を見出しましょう。

  • めんどうである
    • 買いに行くのがめんどう
    • 人と話すのが億劫だ
  • 不安
    • 自分がいつ事故にあって働けなるか分からない不安
    • 自分のスキルが5年後にも通用するか分からない不安
  • (時間、お金を)無駄にしたくない
    • チームメンバに効率的に仕事をして欲しい気持ち
    • せっかくお金をかけて海外旅行に行くのに台なしにしたくない気持ち
  • 強くなりたい、自分を磨きたい
    • より効率的に仕事をしたい
    • いつまでも若々しくありたい
  • 共有したい、自分を知ってほしい
    • 自分が食べているものが美味しいと知ってほしい
    • 自分の悩みや言葉を単に聞いてくれる人が欲しい

この文章を読んでいる方には、自分が成長して自分でアプリケーションを作れるようになりたい気持ちや、 手戻りに発生する無駄な時間をなくしたいという気持ち、チームメンバを育てて仕事をこなしてほしい気持ちがあるかもしれません。

質問2. 痛みの大きさや頻度は?

「要望」、「痛み」と言ったときに、その 程度 はどれほどのものでしょうか。 たしかに要望があるかもしれませんが、それがあまりにも些細な場合は解決する意味はありません。

  • 要望や痛みの 大きさ は?
    • 麻酔が必要:とても欲しい / 死ぬほどの痛みがある
    • 頭痛薬が欲しい:強く欲しい / つらいくらいの痛み
    • ビタミン剤を取ろうかな:あればうれしい / 気になる程度
  • 要望や痛みの 頻度 はどのくらい?
    • 毎日
    • 毎週
    • 毎月

「ランチを選ぶのがめんどう」という痛み1つであれば頻度は毎日ですが、大きさは「あればうれしい」程度です。 ただ「外に行くのもめんどう」や「オフィス近くの食事は飽きてしまった」のような痛みを併せることで解決する価値がでてきます。

たとえば「確定申告をしないといけない、できないしめんどうだ」という悩みは「かなりつらい痛み」という大きさですが、頻度は毎年1回しかありません。 ですが、「日々の経理処理がめんどう」、「レシートを管理しきれない」のような悩みがあるのではないか?と考えれば、軽微であれ日々の痛みとしてもどうじに解決できそうです。

痛みの大きさと頻度を考えることで、どれだけ作りたいものに価値があるのかを考え直せます。 また「満たせていない空白」に注目することで新たな価値に気づけます。

質問3. だれの要望、痛み?

要望や痛みの本質、程度を見極める中で だれの悩みなのか の像が徐々に浮かび上がってくるでしょう。 その「お客様」を次に明確にして書いておきましょう。 いちばん大切なのは、 使う人の要望、痛みに共感すること です。ありありとその人が使う姿、ストーリーが想像できるのが大切です。

理想的には 具体的に一番喜びそうな一人 が思いつけば一番です。さらに言うと自分や自分たちの組織であれば最良です。 なぜなら、作る人自身が使う人の要望、悩み、痛み、ストーリーに強く強く共感できるからです。

  • 「同僚の中村さんはいつもお昼ご飯の食べる場所を決め兼ねている。仕事も忙しそうだし集中できるようにしてあげたい(=> 何か良い解決策を用意してあげられないか?)」
  • 「取引先のチームリーダーの鈴木さんは、いつもとてもお忙しそうだ。こんな悩みありそうで大変そうだ(=> こんなものを作れば助けられるのではないか?)」

もし具体的な一人が分からない場合にも、どんな人がどういう場合に困るのかを調べたり、聞いたりすると良いでしょう。 たとえばSNSで調べてみたり、知り合いに悩みを聞いてみると良いかもしれません。

  • 仕事に忙しいエンジニアの人、年齢は20〜40歳
  • チームリーダーの人。チームのスキルアップをしたいが、教育の文化や自学自習する習慣も組織で教えていきたい

だいたいの年齢やWeb、スマートフォンにどれくらい慣れ親しんでいる人かもわかると、今後の機能やユーザーインターフェースを決める際の助けになります

  • Web画面を使ったときに理解できるか
  • 普段はPCを使うのか、スマートフォンを使うのか
  • 支払いの方法は何が良いか
    • 個人のクレジットカードを持っているか
    • 請求書のやり取りのほうが良いのか

なぜ書き出すのか

なぜ作る意味があるのかを書き出しておく理由は2つあります

  • 思考を書き出すことで曖昧な理解が明確になる
  • 中心的な価値に集中して作れるようになる
    • 無駄な作業、コストをなくす
    • 手戻りを防ぐ
  • 最小で最大の価値がある「初期リリース」を見極めやすくなる

この文章では価値問診票という書き方を提案しましたが、作りたいもの、実現したい価値を書き出す方法であれば他にどんなものでも構いません。 以外にも、以下の方法を使って製品、ビジネスや戦略の価値を検証できます。

書き出しておかないと「自分の都合の良いようにビジョンを進むべき道を変えてしまう」おそれがあります。 たとえば「この新しい技術を使ってみたい」という気持ちが、「ユーザーさんはこういう機能が欲しいのではないか」と都合の良いように解釈を捻じ曲げてしまうことはよくあります。 使う人の課題や痛みに定期的に立ち返るようにしましょう。使う人が求めていない機能や仕様を、作り手の都合で作ってはいけません。

「今使っているちゃぶ台だと仕事中に腰が痛くなってしまう」という課題を解決しようとしていたのに、「昇降機能付きスタンディングデスク」や「天然杉製のデスク」が欲しくなったりすることはだれしもあると思います。 デスクチェアーの「リクライニング機能があるかないか」、「ロッキング機能があるかないか」、「色は何色が良いか」といった本質的でない検討事項に人はすぐ陥ってしまいます。 そうならないように、自分の抱えている課題、求めている机の寸法、置く場所の広さ(制約条件)や値段(コスト)を忘れないように書き出そう、というのがこの価値問診票の意味です。

お弁当ECサイトの価値は何だ

この観点で、この文章で「作りたい」ランチ用のECサイトの価値問診票をまとめてました。

  • どんな痛みを解決するもの?
    • 仕事に集中していたいのにお昼ごはんを食べる必要がある(仕事をより効果的なものにしたい)
    • ランチのためにでかけるのがめんどう(外に出る、人に会う、オーダーをして会計をするのがめんどう)
    • 食べるものを決めるのもめんどう
    • 毎日同じ場所で食べるには飽きてしまった
  • 痛みの大きさや頻度は?
    • 大きさ:あればうれしい(4つ)
    • 頻度:毎日(4つ)
  • だれの要望、悩み?
    • 同僚のエンジニアの中村さん
    • 著者自身の悩み
    • 仕事に熱心に取り組む人
    • 出かけたり店員の人と話すのが少し億劫に感じる人
    • ランチには800円から1200円ほど使う人
    • 年齢は20〜40歳ほど
    • 仕事ではPCを使っていて、PCを使って注文する
    • 個人のクレジットカードは十分に持っている

問診票に答える中で、ストーリーや必要そうな機能、要件がボンヤリと見えて来ました。 痛みとしては小さいですが、日々の何気ない手間を排除することが製品の価値になりそうです。 単にお弁当を売るECサイトでなく、「仕事に集中していたい」や「出歩いたり店員の人と話すのが億劫」という気持ちがあることに気づけました。

次に、どういったものを作るかを問診票の下に追記しましょう。 あとで画面モックアップを作る際に役立ちます。

  • Webアプリケーションで作ると良いだろう
    • サイト上でランチを注文すると30分程度で届けるもの
  • 人と話さなくて済むようにしたい
    • お金はWeb上から支払える

また、実現するためにビジネス、業務上必要なことも決めておきましょう。

  • たとえば近所のお弁当を売っている飲食店のお弁当を売る
    • サービス提供者がお弁当を作る必要はなくなる
    • お弁当の更新などは飲食店に入力してもらう
  • 配達は自分たちで行なう

やらなくて良いことを明確にしておくことで、将来的に作る必要のある画面や処理の数を大幅に減らせます。

作りたいものに似たサービス、システムを調査しよう

作るべきものが見えてきました。ここで他に似たサービスやシステムを調査しましょう。 競合の分析を細かくしたり、張り合う必要はありません。 他サービスの提供価値とメインの顧客層から自分のアプリケーション、サービスの立ち位置を見直すために調査します。 また、ユーザーインターフェースやビジネスの仕組み、支払い方法の工夫などを学べます。

以下の方法で調査するのが良いでしょう

  • Googleで似たサービスがあるか検索する
  • GitHubオープンソースのアプリケーションとしてあるか調べる
  • 社内で聞いて過去に似た事例がないか調べる

一見似たものがあっても、提供する価値やターゲットになる人が違えば新しい価値になるので過敏にならないようにしましょう。 日中の忙しいエンジニア(オフィスでランチに1人〜数人)をターゲットに考えているのであれば、宅配ピザ(夕食に自宅で複数人)は競合と考える必要はありません。

競合や似たシステムの分析から始めてしまうと自分たちの作りたいものがブレてしまいます。 まずは価値問診票を通して、実現したいものが何かを先に書き出しておきましょう。

今回のお弁当ECサイトではAmazon出前館やUberEats、近所のコンビニなどが似たサービスとなります。 ですが、安易に「Amazonのあの機能を作ろう」と考えてはいけません。あくまで参考に学ぶために調査しておきましょう。 (Amazonにはあの機能があるのだから作ろう、作らなくてはダメだと考えないこと)。

何を実現したいかを明確にできましたか?

たとえ自分一人で作っている場合でも、書き出すことはとても大切です。 書き出す過程で『明確になっていない空白』に注目することが大切です 。

まずは1時間、時間を取って書いてみましょう! 将来的に何度も振り返って、書き直して良いです。安心してまずは実際に書き出しましょう。 繰り返すうちに上手になっていくので、模擬的にでも実際にやってみるのが良いでしょう。

本質的な要望、痛みを見出しすことで、これから作るもの、そして 作る必要のないもの を見極める材料を準備しました。 これから作るものそのもの、作る機能、用語の選択に至るまで、常にここで明確にした課題を意識して、判断の根拠にしましょう。

絵に描き出すことがすべての始まり

文章には限界があります。 「百聞は一見にしかず」や「一枚の写真は1000語にも匹敵する(a picture paints a thousand words)」のような ことわざにもあるように、絵に描き出すことで作りたいもののイメージや、システムの流れを俯瞰できます。 必要な仕様や機能、データなどを洗い出す(考え出す)ためにも絵に描き出すのはとても効果的です。

画面モックアップを書いてイメージを膨らませよう

Webアプリケーションの場合、実際に使ったときの使い心地がアプリケーション自体の質としてとても重要になります。 単に色味やフォントの質という意味でなく、入力のしやすさや表示される情報の量や質、遷移のわかり易さが使い心地を左右します。

そのためには実際に作って触ってみるしか検証する方法はありません。 ですがWebアプリケーションを開発するのはコストが大きいです。開発せずに確認するために 画面モックアップ を作りましょう。

画面モックアップは、各画面の表示されている要素や遷移、配置をかんたんに描き出した絵のことです。

  • 入力する情報、遷移、表示される情報から使い心地を確認する
  • 画面の仕様書としてまとめて、Webアプリケーションの仕様、用語、必要な機能やデータを洗い出す

単純に「使い心地」を検証するためだけでない点が重要です。 モックアップを通して仕様や機能を明確にすることが大切と考えましょう。

この文章では画面モックアップ(やモックアップ)と呼びますが、「スケッチ」や「ワイヤーフレーム」とも呼ばれます (描く絵の細かさによって呼び方を変える場合がありますが、ここでは扱いません)。

色や、細かい文言は描かなくて良いので、以下のような絵を描きます。 絵は白黒を基本として、各画面に必要な要素、おおまかな配置や遷移に注目して描きます。

f:id:hirokiky:20181102155827p:plain

f:id:hirokiky:20181102155839p:plain

絵を描くには紙にペンで書いても良いですし、BalsamiqMockupのようなツールを使っても良いです。 上記の例ではBalsamiqMokupを使っています。

ビジュアルに こだわれない ツールを使うほうが良いでしょう。 色味や細かいボタンのデザインにこだわるのは現時点では不要です (ボタンや画面そのものがなくなる可能性が十分にあるからです)。

モックアップに描き出すときのポイント

モックアップに描こうと言われても何をどれくらいの深さで描けば良いかは分からないでしょう。 ここでは、「仕様としての意味を含めた」モックアップを描く際のポイントをお伝えします。

このポイントは、モックアップに今まさに描き出す、描いている間に気をつけるポイントです。

落書きでなくちゃんと完成させよう

落書きやメモ程度の完成度にしてはいけません。 アイディアを描き出してみるためには良いですが、その状態で「画面仕様」としてはいけません。 将来的に画面仕様が変わることは大いにありますが、現時点で考えられる仕様を描きだして、曖昧さがないようにしておきましょう。

きちんと描き出さない問題点は、 「まだ完成していないだろう」と頭で考えてしまうこと にあります。 絵が未完成だと「まだ曖昧な部分があるな」と分かっていながら、その仕様を曖昧なままにしてしまいます。 曖昧なまま進めてしまうと、後になって大規模な集計が必要になったり別のテーブルやミドルウェアが必要になる恐れがあります。

たとえば以下のような絵では必要な要素が十分に見えてきません。

f:id:hirokiky:20181102155725p:plain

頭の中には他にも描き出すべき仕様や、考慮の足りていない部分があるはずです。

  • この画面にはどこから遷移するのでしょうか?
  • どこに遷移できるのでしょうか?
    • 見たところリンクは見当たりません
    • 「タイトル1」をリンクにするのであれば、リンクとわかるように色を変えるか、下線を引くと良いでしょう (専用のツールであれば「リンク」の設定も可能です
  • ブラウザーやアプリ全体の枠は描くようにしましょう
    • この絵が画面全体なのか、一部分なのかが分かりません
    • ナビゲーションバーやサイドバーが付く想定であれば、形だけでも描いておくと良いでしょう
  • 表示されている3つの要素は、どういった条件でフィルタリングされた要素なのでしょうか?
    • 「今月のオススメ弁当」など見出しを書くと、仕様が明確になりますしユーザーの方にも親切です

一番コアになる画面に注力しよう

画面を描くときはそのWebサービスたらしめる画面から描きましょう。

概ね作りたいWebサービス(やアプリ)の中で思いつく画面の順に描きだせば良いでしょう。 それは、想定する使い手のストーリーに関わる画面だからです。

トップ画面を見る => 商品一覧を見る => 商品を選ぶ => カートに入れる => 支払いをする

  • トップページ
  • 一覧ページ
  • 商品のページ
  • カート
  • 支払い

ECサイトであればユーザーのプロフィール設定やパスワード設定画面は優先度が低い画面です。 モックアップとして描く順番は後でも良いですし、画面が必要になるまで書かなくても問題にはなりにくいでしょう。 価値検証としての重要度も低いですし、後に必要な重要な仕様が潜んでる可能性も低いからです (開発の初期段階に自分で動作を確認するときにも、ユーザー登録画面やユーザーのパスワード設定画面はなくても良いでしょう。 手動でデータベースを操作したり、Webフレームワークの持つ管理画面からデータを作成すれば十分だからです)。

「描かれていない空白」に注目して情報を追加する

モックアップに情報を描き足していくときには、描かれている部分ではなく 描かれていない空白 に注目しましょう。 そこに足りない情報が、明確にすべき情報です。

たとえば「何かの一覧」があるのであれば以下のようなことが疑えます。

f:id:hirokiky:20181102155743p:plain

  • 画面上の空白

    • 他に求められる情報はあるか(表示する必要のない情報はあるか)
  • 仕様上の曖昧な言葉

    • 「一覧」とは何なのか
  • 定石で考えて足りない仕様

    • 一覧画面であれば検索、表示順、条件での絞り込み、ページネーションや「もっと見る」リンクが考えられます
    • 不要であればなくても良いですが、発想の糸口として考えてみましょう
    • 他のWebサービスやアプリを参考にして、一般的にどのようなUIがあるのかを定石として知っておくと良いでしょう

描かれている部分よりも、描かれていない部分に注目して仕様を明確にしていくことが重要です。 もし検討した末に「表示しなくて良い」と判断したのであれば、メモ書きとして経緯を書き残しておきましょう。 また同じ検討を避けるために残す意味があります。

すべては入力、遷移、表示の3つで決まる

「画面仕様」として重要なポイントは以下の3つだけです。

  • 入力
    • 「この画面ではどんな入力をするのだろう」
  • 遷移
    • 「この画面にはどこから来て、どこに行くのだろう」
  • 表示
    • 「この画面ではどんな情報が表示される(表示しなくて良い)のだろう」

この3つに注目して各画面を描くようにしましょう。 入力と表示、遷移に注目することで、以下の仕様が明確になります。

  • ユーザーのストーリー、価値にあう画面ができているか
  • どんなデータが仕様上必要か

以下のような観点を持って画面モックアップを描くと良いでしょう。

  • 入力
    • どの画面で必要な情報を入力するのか
      • 商品を「カートに入れる」ときに「数量」を指定するのでしょうか
      • 使いやすさを考えると数量は「カート画面」で入力できれば十分かもしれません。
      • ユーザーは商品のレビューをいつ、どの画面から入力するのでしょうか(別の画面が必要かもしれない)。
    • どんな方法で、どんな型のデータを入力するか
      • テキスト入力なのか、選択式にするのかなど入力の種類を決めます
      • データは数値なのか、文字列なのか、日付なのか決めます
    • ボタンにはどんな種類があるか考える
      • ボタンは「ユーザーがデータを変更する」ときのアクションになるので重要です
      • 「カートに入れる」ボタンだけでしょうか、「商品をお気に入りにする」という仕様も必要だったかもしれません
  • 遷移
    • どの画面から、どの画面にユーザーが移るのか
    • ユーザーが始めてそのWebサービスを使うとき、どこでその画面の存在を知るのか
      • 重要なページであればナビゲーションバーにリンクがあったほうが良いでしょう
      • 何度もクリックしないと行き着けないページはだれも使わなくなります
    • ボタンを押すとどこに移動するのか
      • リンクだけでなくボタンをクリックしたときも画面を遷移できます
      • 「カートに入れる」ボタンを押したときには「カート画面」に移動するのでしょうか?それともそのページのままでしょうか
  • 情報
    • 画面に必要な情報のみ表示する
      • 一覧画面では不用意に多くの情報は表示すべきではありません
      • 一覧画面で商品の説明文や、商品の大きさなどは表示しなくて良いでしょう
    • 「詳細画面」から必要なメタデータを明確にする
      • 詳細画面で表示する情報を考えることで、必要になるデータを洗い出せます
      • たとえば食品であればアレルギー情報は表示すべきでしょう
    • 表示されるデータはどこで入力されたものか
      • 「ユーザーの住所」や「レビュー」などの情報はどこで入力されたものでしょうか
      • もし別途画面が必要であれば、だれが、いつ(どんなストーリーで)、どの画面から入力するのかを考えて描きましょう
    • 「タイトル」や「本文」の他に、値段や販売個数、セール、タグやカテゴリーなどを表示するか
      • 「定石」から足りない要素を発想すると良いでしょう
    • どんな「日」の記録が必要か
      • 「公開日」、「編集日」、「作成日」など何かが起こった日付を表示する必要はあるでしょうか (編集されないデータであれば「編集日」をもつ必要はありません)

もちろん画面上の配置や、どの要素を強調表示するかどうかも大事ですが、 ユーザー体験やストーリーを元にしたWebアプリの価値を把握できるレベルであれば十分でしょう。

モックアップから仕様を読み解いてみよう

モックアップは表示する情報や使い心地を検討するだけでなく、仕様書としての意味合いがとても強いです。 ここで、描き出したモックアップから仕様を読み取る方法をお伝えします。

ただモックアップを描くだけでなく、そのモックアップから後に必要な仕様を読み取ることが大切です このような観点を持つことで画面モックアップは「単なる画面の下書き」でなく、未来に必要な仕様や設計の青写真と捉えられます。

  • どのようなデータ(テーブル、モデル)が必要か
  • 各画面を表示するために、どうデータを取得する必要があるか
  • キャッシュや集計する処理が必要か

ECサイトのトップページから、後々に必要になるモデル、ミドルウェアや集計処理を読み解きましょう。

f:id:hirokiky:20181102155800p:plain

まず、概念として、どのような「もの」があるかをおおまかに捉えてみましょう。

  • 商品
    • 画像の「のり弁当」など
    • 販売されているお弁当そのもの
  • 販売業者
    • 画像の「BeProud弁当」など
    • お弁当を実際に作って売っている店舗
  • ユーザー
    • サービスにログインして購入するユーザー

それぞれのモデルに、どのような属性があるのかもモックアップから読み取れます。 細かくER図などに書き出すのは後で良いので、ここではどんなモデルがあるのかのみ見ておきましょう。

次に、画面内にある要素や単語の意味を深く考えていきます。 現状では機能の一覧や、実装の細かな点まで考慮する必要はありませんが、 ある程度必要になる処理を想定しておくことで、複雑すぎる処理が潜んでないかなどを考えておきましょう。

  • 「お弁当の検索」:お弁当の検索とは、お弁当のどの情報をから検索するのか?
    • 現段階では「お弁当の名前」と「お店の名前」からのみ検索する
    • 検索はデータベースのLIKE検索で十分だろう
  • 「お届先住所」
    • ユーザーはいつお届け先住所を入力するのだろう?
    • 複数登録できて、よく使う住所を1つ設定しておけると良いだろうか?
  • 「配達時間の目安」
    • 何を元に配送時間は算出されているのか?
    • 店舗の住所とユーザーの「お届け先住所」から算出しているのだろうか?
    • 算出はプログラム上ですべきか、地理情報の扱えるデータベースですべきか
    • 地理的な距離だけでなくメニューの準備にかかる時間も加算すべきか
  • 「配達の早い順」
    • 店舗の住所とお届け先の住所からプログラムで計算するのであれば、データベースでのソートは不可能
    • 地理情報の扱えるデータベースを使って、2点間の距離を算出、距離からおおまかな時間を算出できればソートはできるだろう
  • 「評価」
    • 「評価」は1〜5点で付けられるものだろう
    • 表示されている「評価」は、商品ごとの今までのレビューの平均を算出したものだろう
    • 商品を表示するときに、商品ごとのレビューの平均をデータベースで毎度計算するのは遅いかもしれない
  • 「評価の高い順」
    • 商品のレビューの平均を計算して並べ替えするのは時間がかかりそう
    • 商品ごとの「平均評価」を5分ごとや10分ごとに算出して別途管理するのもありかもしれない
    • 「評価の高い順」を表示するとして、ユーザーの「お届け先住所」からあまりにも配達に時間が商品を表示して意味があるのか
  • 「画像」
    • 画像のサイズは4対3で固定するのか、自由なサイズを受け付けるのか? (切り取るのであれば、画像を扱うPythonJavaScriptのライブラリーを知っておく必要がある)
    • 画像はどこに保存するべきか。CDNを通して配信するべきか (未ログインユーザーもアクセスする負荷の大きい画面であればCDNは必要だろう)

この時点で要件を満たすために必要なモデルやミドルウェア、集計があまりに複雑すぎると気づくことがあるでしょう。 そういった仕様が潜んでいないかを気を付けて(実装をある程度想像しながら)モックアップを精読することにもモックアップに描き出す意味があります。

使う人の要望、痛みの大きさや頻度(それを解消するための仕様の重要度)を考えて、そのまま作るか、代替案を考えるか、仕様をなくすかを考えましょう。 「とても頑張った割にはだれも嬉しくない」ものよりも、本質的な価値にもっとも近い仕事に注力するためによく読むことが大切です。

アクセスする人の量と処理の重さを見積もる

各画面にどんな人がこのページにアクセスするのかを明確にしておきましょう。 アクセスできる人の量によってどのくらい高速にレスポンスするのかが変わってきます。

  • 未ログインユーザーもアクセスできる
    • アクセスする人数は少なくない(サービスが成長すれば、秒間数百リクエストのアクセスは十分考えられる)
    • キャッシュやCDNなどが必要になる
  • ログインユーザーのみアクセスできる
    • 初期であれば10〜数100ユーザー、成長していけば数1000〜数万ユーザーは考えられる
    • 全ユーザー数のうち、アクティブユーザーが5%〜20%と考えると、トップ画面のおおまかな負荷などが考慮できます
  • 店舗管理者やシステム管理者などの一部のユーザーのみアクセスできる
    • 管理者向けの画面は、負荷は大きくなりにくいです
    • 管理者向けのレポートや集計データの表示などをする場合は、アクセス数は少なくても処理としては重い処理になるでしょう

また、アクセスの権限管理がどれくらい複雑かをおおまかに知っておけます。 あとでモデル(テーブル)の設計をする際に、ユーザーアカウントに関するテーブルを設計する際の参考になるでしょう。

最初にどこから作るかを決めよう

何かを作るうえで、コストと締切りは無視できません。 仕事でプログラムする際にはもちろんコストと締切りは存在しますが、仮に自分ひとりで趣味のWebサービスを作る場合にもコストと締切りは存在します。

  • コスト
    • 自分自身の時間
    • 労力、体力
    • 作り続けるモチベーション
  • 締切り
    • 飽きてやめてしまう
    • 似たサービスがローンチされてしまう

締切りというと嫌な印象がありますが、モチベーションを保つうえでとても大切です。 途方もなく大きなものを闇雲に作るより、マイルストーンを立てて順に小さく作っていくほうがモチベーションを保てます。

最小の完成形を見つける

今までモックアップを書き出す中で、製品に必要そうな機能を洗い出してきました。 ですが、それら すべての機能が最初のリリースに必要というわけではありません 。 リリースをして自分で作ってみたり反響を得たりしながら、設計や仕様自体を柔軟に変更しましょう。

最小の製品はどうやって見つければ良いのでしょうか? 価値問診票を見ながら 最初に要らない 機能を決めましょう。 ECサイトが解決する痛みには以下のようなものがありました。

  • 仕事に集中していたいのにお昼ごはんを食べる必要がある(仕事をより効果的なものにしたい)
  • ランチのためにでかけるのがめんどう(外に出る、人に会う、オーダーをして会計をするのがめんどう)
  • 食べるものを決めるのもめんどう
  • 毎日同じ場所で食べるには飽きてしまった

解決したい問題を見ると、まず「オンラインでお昼ご飯が買えること」ができればOKだとわかります。 どの機能を優先すべきかを考える際は、以下のような観点で考えます。

  • 一番中心になる課題から解決する
    • その製品・サービスたらしめる機能
    • 利用頻度の多い、ユーザーのだれしもが使う機能
  • リリース当初不要なものはなくす

    • 商品の数(データ量)も少ないので高度な検索や並べ替えは不要だろう
    • ユーザーアカウントは管理者が手動で作って知人に配布すれば十分だろう たとえば、以下の機能は必須としました。
  • 商品の一覧ページ

  • 商品の詳細ページ
  • 配送先住所の設定
  • 配送時間の見積もり機能
    • 初期リリースは住所間の直線距離からおおまかに算出する
  • カート機能
  • 商品の注文機能
    • 同じ店舗の商品しか購入できないようにする
  • 購入履歴ページ
  • 売店、商品の管理機能

以下の機能は初期リリースには不要と考えました

  • 今月のオススメ商品機能
  • よく買うお弁当機能
  • レビュー機能
  • レビューの評価値の集計機能
  • ユーザー作成機能
  • 商品の検索、並べ替え機能
  • 成分表記、アレルギー表記

ただし、一見不要そうに思えても使い勝手やビジョンに大きく影響する機能は作る必要があります。 今回であれば「めんどうさ」をなくすためのWebサービスなので、最小の製品でありつつ使う手間は最低限になるようにしたいです。

なので「クレジットカードでの支払いをなくして、まずは現金で配達員に支払えば良い」とは限りません。 現金を扱うようにすることで、配達員のお金の処理や、販売店への支払いの業務設計が必要になることも考えられます。 その手間が自動化できることを考えてもクレジットカード決済は必須の機能でしょう。

ストーリーが満たせるかレビューする

初期のリリースする機能のモックアップができれば以下を考え直しましょう

  • Webサービスとして価値が実現できるか
  • 使う人のストーリーを実現する画面の遷移、ボタンが揃っているか
  • 使う人が触った瞬間に「求めていた価値」を感じられるか
    • 私には難しい、私にはあわない、私のモノじゃないと思われないか
  • 使う人にとって使いやすいか、使いこなせるか
    • 年齢やWeb、スマートフォンへどれくらい慣れているか
    • ユーザー層によっては「ハンバーガーアイコン」をみて「メニュー」の意味とは伝わらない場合がある
  • どういった流れで使い手は、その使い方を会得するのか
    • 画面を見るだけで使い方を想像できるか
    • 既存の他のサービスやアプリから機能や意味を想像できるか
    • 今までと大きく違う場合は、注釈やチュートリアルがあったほうが良いかもしれない

今後作りたい機能などについては詳細にモックアップを作らなくても良いでしょう。 はじめにリリースをしたあとに、フィードバックを受けながら次にリリースするマイルストーンを決めていけば十分です。 モックアップは一直線に完成までを作る必要はありません。 実現したい価値やリリース時期、システムの制約などを考慮しながら、行き来させながら作っていきましょう。

設計とは何か、どれくらいするものなのか

ここまでの話は「画面設計をしよう」という話とも言えます。

設計とは何かを実現するために事前に決めるための計画、図、仕様のことです。 どのようなものを作るのか、何を作るのかを明確にするために書き出されます。

最終的には(ソフトウェアなので)プログラムのソースコードが分かりやすい成果物になります。 完成品としてのシステムやWebアプリケーションが実現したいものです。

ですがいきなり最終的な成果物を作ろうとすると迷子になってしまいます。 たとえば大阪から(行ったことのない)東京に行くために、何も計画せず、考えずに車を発進させるようなものです。 人間味のあるドラマは生まれるかもしれませんが。

その最終的な成果物、価値の実現のために、より抽象的で高い視点から計画していくことが設計です。 「どんなものを作るのか」、「どういう画面なのか」や「どういう構造で作るのか」を決めていきます。 使う人にとっての価値(良さ)を高めることや、保守性、可読性、安定性を高めること、手戻りを少なく完成させることなどを高めることが設計の目的です。

設計は最初から100%の正解を求めてはいけません。作りながら徐々に変えていって問題ありません。 ですが、今の設計(計画)が「何%くらい確かなものか」(確度)は意識しておきましょう。 次の段階(より具体的な作業)に進んで問題ない(将来的な手戻りが少ない)レベルの設計を常にするようにしましょう。

プロセスとしての設計と構造としての設計

「設計」という言葉を聞くとき、以下の2つの場合があります。

  1. プロセスとしての設計
    • 計画や大枠の構造把握のために図や仕様をまとめるプロセスや成果物
    • 具体的なプロセスに進むのが早すぎる場合に「設計が足りない」という言葉を使う場合はこちらの意味
  2. 構造としての設計
    • 抽象的な構造やデータ間の関連、プログラムやテストの構造や作り
    • 保守性や安定性が高いという意味で「良い設計」という言葉を使う場合はこちらの意味

表面的に「設計」というプロセスが目に見えなくても、作業者の中で設計のプロレスが行われているはずです。

まとめ

何かを作りたいと思いついたときは、すぐにエディターを起動するのはやめましょう。 まず自分が作りたいものを書き出して、その価値を検証しましょう。 大局的な視点から徐々に詳細に降りていくことで、将来的な手戻りや迷走を避けられます。

なにか作りたいものはありますか?まずはそのイメージを膨らませて、何が欲しいかを明確にしましょう。 その「手触り」の中に本質があります。

もし参考になった人はぜひ、僕の作ったShodoというWebサービスも覗いてみてください。

shodo.ink

またTwitterもやっていますのでぜひフォローお願いします!

twitter.com

他のオススメ記事

blog.hirokiky.org

blog.hirokiky.org

blog.hirokiky.org

仕事で書いた匠メソッドを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で試してみてください!