今日で27歳になりました
人生とか語り出すなんて、 Break out! 五億年先でいい
「BREAK OUT!」 相川七瀬 より
NANASE AIKAWA BEST ALBUM "ROCK or DIE"
- アーティスト: 相川七瀬
- 出版社/メーカー: motorod
- 発売日: 2013/09/04
- メディア: MP3 ダウンロード
- この商品を含むブログを見る
PyQ とか nullbooks.io とか色々他のものとか、これからも面白いもの作ってくからよろしくね。
今日で27歳になりました
人生とか語り出すなんて、 Break out! 五億年先でいい
「BREAK OUT!」 相川七瀬 より
NANASE AIKAWA BEST ALBUM "ROCK or DIE"
PyQ とか nullbooks.io とか色々他のものとか、これからも面白いもの作ってくからよろしくね。
何かを作りたいときは、エディターをいきなり起動してはいけません。 エディターを閉じて、まずはイメージをまとめることに集中しましょう。
なぜ何かを作る前にイメージをまとめる必要があるのでしょうか? 頭の中には完璧な作りたいもののイメージがあることでしょう。 であれば今すぐにでもプログラミングを始めるのが賢明なように思えます。
ですがそうしてはいけません。理由は「作りたいもののイメージは単なる幻想だから です」。
頭のなかにあるイメージはとても素晴らしいものですが、多くの場合は曖昧で、触れられない、価値を検証できないものです。 それを一旦書き出して、まとめていく方法を知っておきましょう。 まとめていく中で作るものがより明確になり、自分でも気づかない価値を発見できます。
実際には作ってみるまでは価値は分かりません。ですが、何かを作るのはとても高コストです。 本当に天才的な人であれば全てを頭の中でまとめられるかもしれませんが、人は持っている手札で戦うしかありません。
イメージをまとめて検証することで、コストを小さく、精度を比較的高く価値を検証したうえでプログラミングができるようになります。
この考え方を通して、僕はShodoというWebサービスを作りました。
作るもののまとめかた、モックアップの書き方や設計の仕方を、何の実例もなく説明するのは不可能です。 この文章ではWebアプリケーションとしてのECサイトを作りながらノウハウを伝えます。
ECサイト(ショッピングサイト)には以下のような機能が考えられます。 今回のECサイトでは、お昼ご飯用のお弁当を購入して届けてもらうようなWebアプリケーションを考えます。
お弁当を実際に販売するのはサービス事業者でなく、「〜〜弁当」のような実店舗を想定します。 サービス運営者は各店舗にお弁当を登録してもらい、ユーザーが購入するとサービス事業者の配送スタッフが運送します。
この文章ではブラウザーから利用するWebアプリケーションを元に説明しますが、他のスマートフォンサービスやバックエンドのAPIサーバなどにも役に立つ知識になります。 他にも、設計やソフトウェアを作る考え方やプロセスを学んでおけば、スクレイピング処理やバッチ処理を作る場合にも活用できます。 もちろん自分で作るだけでなく、他の人に頼まれて何かを作る場合にも活用できるよう書かれています。
何か新しいものを作るのはとても高度な技術です。 以下のような悩みはだれしもあるかとは思います。
大切なのは ものを作る流れを知ること です。
すぐにプログラムを書こうとするのはやめましょう。 今は エディターを閉じましょう。ターミナルを閉じましょう。技術調査をやめましょう。 気持ちや技術先行で作り始めても、迷子になったり大きな手戻りが発生するので無駄になってしまいます。 遠回りしているように感じますが、大きな手戻りが発生したり価値そのものを見失うリスクに比べれば小さいと考えましょう。
たとえば、以下のような手戻りや無駄な実装は往々にして発生します。
この文章では設計という流れ(プロセス)を説明して、もの作りの実践に役立つ方法を説明しています。 ですが、プロセスだけでは不十分です。プロセスは手助けやサポートをするものであり本質ではありません。 もの作りを繰り返すことで磨かれるスキルや、作る中で考えていくことが一番大切なことです。 この文章では何かを作る手助けになるプロセスを説明しますが、実際にやって学んだ経験(スキル、中身、コンテンツ)こそが大切だと覚えておいてください。
手戻りや無駄な実装を回避するために、まず実現したいものを 文章に書き出して明確にしましょう 。 作りたいものは何かを考えましょう。使い手の痛み、悩みに共感して、それを 解決する価値を検証しましょう 。
この文章では 価値 というものは「実現されることで実現されることでうれしくなる、豊かになること」、 「実現されることで楽になる、痛みが解消されること」と考えています。
文章に書き出すにも、その観点がないと書き出すのは難しいことと思います。 価値問診票 というものを考えてみましたので、下の質問に答えながら作りたいものが解決する課題、価値を掘り下げていきましょう。
これから作りたいものは、どんな問題や痛みを解消するものですか? 本質的な解決すべき課題や満たすべき要望を明確にしない限り、その解決策(Webアプリケーションなど)を作っても無駄になってしまうのでとても大切です。
例:
要望や痛みの本質には、人間の本質的な欲求や怠惰、不安があります。 解決する要望、痛みの中に、以下のような人間の本質を見出しましょう。
この文章を読んでいる方には、自分が成長して自分でアプリケーションを作れるようになりたい気持ちや、 手戻りに発生する無駄な時間をなくしたいという気持ち、チームメンバを育てて仕事をこなしてほしい気持ちがあるかもしれません。
「要望」、「痛み」と言ったときに、その 程度 はどれほどのものでしょうか。 たしかに要望があるかもしれませんが、それがあまりにも些細な場合は解決する意味はありません。
「ランチを選ぶのがめんどう」という痛み1つであれば頻度は毎日ですが、大きさは「あればうれしい」程度です。 ただ「外に行くのもめんどう」や「オフィス近くの食事は飽きてしまった」のような痛みを併せることで解決する価値がでてきます。
たとえば「確定申告をしないといけない、できないしめんどうだ」という悩みは「かなりつらい痛み」という大きさですが、頻度は毎年1回しかありません。 ですが、「日々の経理処理がめんどう」、「レシートを管理しきれない」のような悩みがあるのではないか?と考えれば、軽微であれ日々の痛みとしてもどうじに解決できそうです。
痛みの大きさと頻度を考えることで、どれだけ作りたいものに価値があるのかを考え直せます。 また「満たせていない空白」に注目することで新たな価値に気づけます。
要望や痛みの本質、程度を見極める中で だれの悩みなのか の像が徐々に浮かび上がってくるでしょう。 その「お客様」を次に明確にして書いておきましょう。 いちばん大切なのは、 使う人の要望、痛みに共感すること です。ありありとその人が使う姿、ストーリーが想像できるのが大切です。
理想的には 具体的に一番喜びそうな一人 が思いつけば一番です。さらに言うと自分や自分たちの組織であれば最良です。 なぜなら、作る人自身が使う人の要望、悩み、痛み、ストーリーに強く強く共感できるからです。
もし具体的な一人が分からない場合にも、どんな人がどういう場合に困るのかを調べたり、聞いたりすると良いでしょう。 たとえばSNSで調べてみたり、知り合いに悩みを聞いてみると良いかもしれません。
だいたいの年齢やWeb、スマートフォンにどれくらい慣れ親しんでいる人かもわかると、今後の機能やユーザーインターフェースを決める際の助けになります
なぜ作る意味があるのかを書き出しておく理由は2つあります
この文章では価値問診票という書き方を提案しましたが、作りたいもの、実現したい価値を書き出す方法であれば他にどんなものでも構いません。 以外にも、以下の方法を使って製品、ビジネスや戦略の価値を検証できます。
ストーリーとしての競争戦略 優れた戦略の条件 (Hitotsubashi Business Review Books)
書き出しておかないと「自分の都合の良いようにビジョンを進むべき道を変えてしまう」おそれがあります。 たとえば「この新しい技術を使ってみたい」という気持ちが、「ユーザーさんはこういう機能が欲しいのではないか」と都合の良いように解釈を捻じ曲げてしまうことはよくあります。 使う人の課題や痛みに定期的に立ち返るようにしましょう。使う人が求めていない機能や仕様を、作り手の都合で作ってはいけません。
「今使っているちゃぶ台だと仕事中に腰が痛くなってしまう」という課題を解決しようとしていたのに、「昇降機能付きスタンディングデスク」や「天然杉製のデスク」が欲しくなったりすることはだれしもあると思います。 デスクチェアーの「リクライニング機能があるかないか」、「ロッキング機能があるかないか」、「色は何色が良いか」といった本質的でない検討事項に人はすぐ陥ってしまいます。 そうならないように、自分の抱えている課題、求めている机の寸法、置く場所の広さ(制約条件)や値段(コスト)を忘れないように書き出そう、というのがこの価値問診票の意味です。
この観点で、この文章で「作りたい」ランチ用のECサイトの価値問診票をまとめてました。
問診票に答える中で、ストーリーや必要そうな機能、要件がボンヤリと見えて来ました。 痛みとしては小さいですが、日々の何気ない手間を排除することが製品の価値になりそうです。 単にお弁当を売るECサイトでなく、「仕事に集中していたい」や「出歩いたり店員の人と話すのが億劫」という気持ちがあることに気づけました。
次に、どういったものを作るかを問診票の下に追記しましょう。 あとで画面モックアップを作る際に役立ちます。
また、実現するためにビジネス、業務上必要なことも決めておきましょう。
やらなくて良いことを明確にしておくことで、将来的に作る必要のある画面や処理の数を大幅に減らせます。
作るべきものが見えてきました。ここで他に似たサービスやシステムを調査しましょう。 競合の分析を細かくしたり、張り合う必要はありません。 他サービスの提供価値とメインの顧客層から自分のアプリケーション、サービスの立ち位置を見直すために調査します。 また、ユーザーインターフェースやビジネスの仕組み、支払い方法の工夫などを学べます。
以下の方法で調査するのが良いでしょう
一見似たものがあっても、提供する価値やターゲットになる人が違えば新しい価値になるので過敏にならないようにしましょう。 日中の忙しいエンジニア(オフィスでランチに1人〜数人)をターゲットに考えているのであれば、宅配ピザ(夕食に自宅で複数人)は競合と考える必要はありません。
競合や似たシステムの分析から始めてしまうと自分たちの作りたいものがブレてしまいます。 まずは価値問診票を通して、実現したいものが何かを先に書き出しておきましょう。
今回のお弁当ECサイトではAmazon、出前館やUberEats、近所のコンビニなどが似たサービスとなります。 ですが、安易に「Amazonのあの機能を作ろう」と考えてはいけません。あくまで参考に学ぶために調査しておきましょう。 (Amazonにはあの機能があるのだから作ろう、作らなくてはダメだと考えないこと)。
たとえ自分一人で作っている場合でも、書き出すことはとても大切です。 書き出す過程で『明確になっていない空白』に注目することが大切です 。
まずは1時間、時間を取って書いてみましょう! 将来的に何度も振り返って、書き直して良いです。安心してまずは実際に書き出しましょう。 繰り返すうちに上手になっていくので、模擬的にでも実際にやってみるのが良いでしょう。
本質的な要望、痛みを見出しすことで、これから作るもの、そして 作る必要のないもの を見極める材料を準備しました。 これから作るものそのもの、作る機能、用語の選択に至るまで、常にここで明確にした課題を意識して、判断の根拠にしましょう。
文章には限界があります。 「百聞は一見にしかず」や「一枚の写真は1000語にも匹敵する(a picture paints a thousand words)」のような ことわざにもあるように、絵に描き出すことで作りたいもののイメージや、システムの流れを俯瞰できます。 必要な仕様や機能、データなどを洗い出す(考え出す)ためにも絵に描き出すのはとても効果的です。
Webアプリケーションの場合、実際に使ったときの使い心地がアプリケーション自体の質としてとても重要になります。 単に色味やフォントの質という意味でなく、入力のしやすさや表示される情報の量や質、遷移のわかり易さが使い心地を左右します。
そのためには実際に作って触ってみるしか検証する方法はありません。 ですがWebアプリケーションを開発するのはコストが大きいです。開発せずに確認するために 画面モックアップ を作りましょう。
画面モックアップは、各画面の表示されている要素や遷移、配置をかんたんに描き出した絵のことです。
単純に「使い心地」を検証するためだけでない点が重要です。 モックアップを通して仕様や機能を明確にすることが大切と考えましょう。
この文章では画面モックアップ(やモックアップ)と呼びますが、「スケッチ」や「ワイヤーフレーム」とも呼ばれます (描く絵の細かさによって呼び方を変える場合がありますが、ここでは扱いません)。
色や、細かい文言は描かなくて良いので、以下のような絵を描きます。 絵は白黒を基本として、各画面に必要な要素、おおまかな配置や遷移に注目して描きます。
絵を描くには紙にペンで書いても良いですし、BalsamiqMockupのようなツールを使っても良いです。 上記の例ではBalsamiqMokupを使っています。
ビジュアルに こだわれない ツールを使うほうが良いでしょう。 色味や細かいボタンのデザインにこだわるのは現時点では不要です (ボタンや画面そのものがなくなる可能性が十分にあるからです)。
モックアップに描こうと言われても何をどれくらいの深さで描けば良いかは分からないでしょう。 ここでは、「仕様としての意味を含めた」モックアップを描く際のポイントをお伝えします。
このポイントは、モックアップに今まさに描き出す、描いている間に気をつけるポイントです。
落書きやメモ程度の完成度にしてはいけません。 アイディアを描き出してみるためには良いですが、その状態で「画面仕様」としてはいけません。 将来的に画面仕様が変わることは大いにありますが、現時点で考えられる仕様を描きだして、曖昧さがないようにしておきましょう。
きちんと描き出さない問題点は、 「まだ完成していないだろう」と頭で考えてしまうこと にあります。 絵が未完成だと「まだ曖昧な部分があるな」と分かっていながら、その仕様を曖昧なままにしてしまいます。 曖昧なまま進めてしまうと、後になって大規模な集計が必要になったり別のテーブルやミドルウェアが必要になる恐れがあります。
たとえば以下のような絵では必要な要素が十分に見えてきません。
頭の中には他にも描き出すべき仕様や、考慮の足りていない部分があるはずです。
画面を描くときはそのWebサービスたらしめる画面から描きましょう。
概ね作りたいWebサービス(やアプリ)の中で思いつく画面の順に描きだせば良いでしょう。 それは、想定する使い手のストーリーに関わる画面だからです。
トップ画面を見る => 商品一覧を見る => 商品を選ぶ => カートに入れる => 支払いをする
ECサイトであればユーザーのプロフィール設定やパスワード設定画面は優先度が低い画面です。 モックアップとして描く順番は後でも良いですし、画面が必要になるまで書かなくても問題にはなりにくいでしょう。 価値検証としての重要度も低いですし、後に必要な重要な仕様が潜んでる可能性も低いからです (開発の初期段階に自分で動作を確認するときにも、ユーザー登録画面やユーザーのパスワード設定画面はなくても良いでしょう。 手動でデータベースを操作したり、Webフレームワークの持つ管理画面からデータを作成すれば十分だからです)。
モックアップに情報を描き足していくときには、描かれている部分ではなく 描かれていない空白 に注目しましょう。 そこに足りない情報が、明確にすべき情報です。
たとえば「何かの一覧」があるのであれば以下のようなことが疑えます。
画面上の空白
仕様上の曖昧な言葉
定石で考えて足りない仕様
描かれている部分よりも、描かれていない部分に注目して仕様を明確にしていくことが重要です。 もし検討した末に「表示しなくて良い」と判断したのであれば、メモ書きとして経緯を書き残しておきましょう。 また同じ検討を避けるために残す意味があります。
「画面仕様」として重要なポイントは以下の3つだけです。
この3つに注目して各画面を描くようにしましょう。 入力と表示、遷移に注目することで、以下の仕様が明確になります。
以下のような観点を持って画面モックアップを描くと良いでしょう。
もちろん画面上の配置や、どの要素を強調表示するかどうかも大事ですが、 ユーザー体験やストーリーを元にしたWebアプリの価値を把握できるレベルであれば十分でしょう。
モックアップは表示する情報や使い心地を検討するだけでなく、仕様書としての意味合いがとても強いです。 ここで、描き出したモックアップから仕様を読み取る方法をお伝えします。
ただモックアップを描くだけでなく、そのモックアップから後に必要な仕様を読み取ることが大切です このような観点を持つことで画面モックアップは「単なる画面の下書き」でなく、未来に必要な仕様や設計の青写真と捉えられます。
ECサイトのトップページから、後々に必要になるモデル、ミドルウェアや集計処理を読み解きましょう。
まず、概念として、どのような「もの」があるかをおおまかに捉えてみましょう。
それぞれのモデルに、どのような属性があるのかもモックアップから読み取れます。 細かくER図などに書き出すのは後で良いので、ここではどんなモデルがあるのかのみ見ておきましょう。
次に、画面内にある要素や単語の意味を深く考えていきます。 現状では機能の一覧や、実装の細かな点まで考慮する必要はありませんが、 ある程度必要になる処理を想定しておくことで、複雑すぎる処理が潜んでないかなどを考えておきましょう。
この時点で要件を満たすために必要なモデルやミドルウェア、集計があまりに複雑すぎると気づくことがあるでしょう。 そういった仕様が潜んでいないかを気を付けて(実装をある程度想像しながら)モックアップを精読することにもモックアップに描き出す意味があります。
使う人の要望、痛みの大きさや頻度(それを解消するための仕様の重要度)を考えて、そのまま作るか、代替案を考えるか、仕様をなくすかを考えましょう。 「とても頑張った割にはだれも嬉しくない」ものよりも、本質的な価値にもっとも近い仕事に注力するためによく読むことが大切です。
各画面にどんな人がこのページにアクセスするのかを明確にしておきましょう。 アクセスできる人の量によってどのくらい高速にレスポンスするのかが変わってきます。
また、アクセスの権限管理がどれくらい複雑かをおおまかに知っておけます。 あとでモデル(テーブル)の設計をする際に、ユーザーアカウントに関するテーブルを設計する際の参考になるでしょう。
何かを作るうえで、コストと締切りは無視できません。 仕事でプログラムする際にはもちろんコストと締切りは存在しますが、仮に自分ひとりで趣味のWebサービスを作る場合にもコストと締切りは存在します。
締切りというと嫌な印象がありますが、モチベーションを保つうえでとても大切です。 途方もなく大きなものを闇雲に作るより、マイルストーンを立てて順に小さく作っていくほうがモチベーションを保てます。
今までモックアップを書き出す中で、製品に必要そうな機能を洗い出してきました。 ですが、それら すべての機能が最初のリリースに必要というわけではありません 。 リリースをして自分で作ってみたり反響を得たりしながら、設計や仕様自体を柔軟に変更しましょう。
最小の製品はどうやって見つければ良いのでしょうか? 価値問診票を見ながら 最初に要らない 機能を決めましょう。 ECサイトが解決する痛みには以下のようなものがありました。
- 仕事に集中していたいのにお昼ごはんを食べる必要がある(仕事をより効果的なものにしたい)
- ランチのためにでかけるのがめんどう(外に出る、人に会う、オーダーをして会計をするのがめんどう)
- 食べるものを決めるのもめんどう
- 毎日同じ場所で食べるには飽きてしまった
解決したい問題を見ると、まず「オンラインでお昼ご飯が買えること」ができればOKだとわかります。 どの機能を優先すべきかを考える際は、以下のような観点で考えます。
リリース当初不要なものはなくす
商品の一覧ページ
以下の機能は初期リリースには不要と考えました
ただし、一見不要そうに思えても使い勝手やビジョンに大きく影響する機能は作る必要があります。 今回であれば「めんどうさ」をなくすためのWebサービスなので、最小の製品でありつつ使う手間は最低限になるようにしたいです。
なので「クレジットカードでの支払いをなくして、まずは現金で配達員に支払えば良い」とは限りません。 現金を扱うようにすることで、配達員のお金の処理や、販売店への支払いの業務設計が必要になることも考えられます。 その手間が自動化できることを考えてもクレジットカード決済は必須の機能でしょう。
初期のリリースする機能のモックアップができれば以下を考え直しましょう
今後作りたい機能などについては詳細にモックアップを作らなくても良いでしょう。 はじめにリリースをしたあとに、フィードバックを受けながら次にリリースするマイルストーンを決めていけば十分です。 モックアップは一直線に完成までを作る必要はありません。 実現したい価値やリリース時期、システムの制約などを考慮しながら、行き来させながら作っていきましょう。
ここまでの話は「画面設計をしよう」という話とも言えます。
設計とは何かを実現するために事前に決めるための計画、図、仕様のことです。 どのようなものを作るのか、何を作るのかを明確にするために書き出されます。
最終的には(ソフトウェアなので)プログラムのソースコードが分かりやすい成果物になります。 完成品としてのシステムやWebアプリケーションが実現したいものです。
ですがいきなり最終的な成果物を作ろうとすると迷子になってしまいます。 たとえば大阪から(行ったことのない)東京に行くために、何も計画せず、考えずに車を発進させるようなものです。 人間味のあるドラマは生まれるかもしれませんが。
その最終的な成果物、価値の実現のために、より抽象的で高い視点から計画していくことが設計です。 「どんなものを作るのか」、「どういう画面なのか」や「どういう構造で作るのか」を決めていきます。 使う人にとっての価値(良さ)を高めることや、保守性、可読性、安定性を高めること、手戻りを少なく完成させることなどを高めることが設計の目的です。
設計は最初から100%の正解を求めてはいけません。作りながら徐々に変えていって問題ありません。 ですが、今の設計(計画)が「何%くらい確かなものか」(確度)は意識しておきましょう。 次の段階(より具体的な作業)に進んで問題ない(将来的な手戻りが少ない)レベルの設計を常にするようにしましょう。
「設計」という言葉を聞くとき、以下の2つの場合があります。
表面的に「設計」というプロセスが目に見えなくても、作業者の中で設計のプロレスが行われているはずです。
何かを作りたいと思いついたときは、すぐにエディターを起動するのはやめましょう。 まず自分が作りたいものを書き出して、その価値を検証しましょう。 大局的な視点から徐々に詳細に降りていくことで、将来的な手戻りや迷走を避けられます。
なにか作りたいものはありますか?まずはそのイメージを膨らませて、何が欲しいかを明確にしましょう。 その「手触り」の中に本質があります。
もし参考になった人はぜひ、僕の作ったShodoというWebサービスも覗いてみてください。
またTwitterもやっていますのでぜひフォローお願いします!
先日、匠メソッドをCacooで書くととても良いという話をしました。 匠メソッドについてや、Cacooで使うメリットは以下を読んでください。
そこで PyQ チームでもCacooを使って匠メソッドをしてみることにしました (もともと、開発当初から2年間ほどAstahを使って匠メソッドを書き続けています)。
チーム全員で使えるので、全員で同期してWebでそのまま閲覧、編集できるメリットはやっぱり大きそうです。 今までAstahを使っていましたが、Cacooを使うとチームで同期してメンテしていける点や、ミーティング中に全員で書き込める点などのメリットがあります。
まだ移行したばかりなので、今後より長い間使っていく中でのメリットやデメリットも伝えられるかなと思います。
以下4つのモデルをCacooに移行しました (モザイク処理をしています)。
匠メソッドはメリットがたくさんある手法ですが、図がカオス化しやすかったり、メンテされなくなる問題はあります。
PyQ チームでは継続的にPyQの開発を続けているので、匠メソッドも常に見直して更新しつづける必要があります。 定期的に各ステークホルダーの課題や要求を見直すことで、小さなチームでもより効果的な仕事ができるように取り組んでいます。 継続開発するときこそ匠メソッドの、「お客様やステークホルダーの課題や価値に立ち返る。自分たちのビジョンと突き合わせる」という利点がより重要になると僕は思っています。
それを忘れてしまうと、なぁなぁにくだらないものを作ったり、人に言われるがままに物を作って、時間や労力を浪費してしまいます。 Cacooなどの、Webで同期できてチームメンバー全員で編集できる環境で匠メソッドを書くことで、よりその良さを活かせるのではないでしょうか。 ぜひ、匠メソッドを使っている皆さんはCacooで試してみてください!
何かを開発するとき、いきなりエディターを立ち上げていませんか?
製品、サービスを作るときは要求、要件を分析してまとめてから作るのがオススメです。 そんなときに匠メソッドという要求開発の手法を、僕個人も BeProud の仕事でも使っています。
匠Method: 〜新たな価値観でプロジェクトをデザインするために〜
匠メソッドは製品やサービスを「なぜ作るべきなのか」、「何が求められているのか」という要求を、ニーズとシーズから探る手法です。 匠メソッドについて知りたい人はこの本を読んでみてください。 (僕は少し自分なりに変えて使っている部分もあるので、この記事内の図などが少し違うなというところがあっても気にしないでください)。
匠メソッドはツールを限定しません。 なので、テキトウなドローツールや付箋紙などでもできます。 聞くところオススメされているのは Astah というツールを使うことで、 匠メソッドのプラグインなども提供されています 。
ですが、正直なところ、これらの方法でやる 問題はいくつかあります
ここで僕は Cacoo をオススメします。 僕は最近作ってる個人プロジェクトで、Cacooで匠メソッドをやってみているんですがかなり良いです。 Cacooは匠メソッドにもかなり有用に使えます。
Cacooはブラウザーで動作するグラフのドローツールです。 以下の利点があります。
これは最of高と言わざるを得ません。 匠メソッドは複数人で共有して書いたり、中長期に渡ってメンテしつつ閲覧、編集することに意味があります。 ですので、誰でも常に見て、編集できることはすごく大切です (ただCacooの同時編集は、個人的に2ブラウザーで試した程度なので、何人もの人がオンライン越しに編集して匠メソッドがうまくいくかは分かりません)。
主に僕は「ステークホルダモデル」、「価値分析モデル」、「価値デザインモデル」と「要求分析ツリー」の4つを使います。 Cacooで4つの図をテンプレート的に書いてみたので見てみてください (仕事の内容が入っているものは見せられないので、テンプレートとして使っている図をお見せします)。
Cacooの図としても以下のリンクで共有しています。 閲覧のみは誰でもできるようにしています。
https://cacoo.com/diagrams/abZdFWFFiP3PYqED/C2575
テンプレートとして共有するのはどうすれば良いのか分からないですが。
この要求分析ツリーなどは新しいCacooのUIで書いています。 新しいCacooを使うと匠メソッドが書きやすくなる良い点がたくさんあります
また全体的にとても使いやすくなりましたし、軽快に動作してとても良いです。
匠メソッドをやっているけど Web同期できない 、 同時編集できない 、 ファイル形式を気にせずWebで編集、共有したい という悩みがある人は、 ぜひCacooでやってみるのが良いと思います。
僕もまだ手探りで試しているところなので、同時編集してみてうまく回ったかや、大規模なモデルでも動作したかなど教えてください。
匠メソッドはとても有効な手法ですが、書捨てで忘れてしまっては意味がありません。 プロジェクトのメンバーが原点に立ち返りながら、中長期的にみんなでメンテできるようにしていきましょう。
前の記事ではWSGIアプリケーションをWSGIサーバー(gunicorn)で起動する方法を説明しました。 ここではgunicornを使って、Python製WebフレームワークでできたWebアプリケーションを起動しましょう。
DjangoやFlaskなどのWebフレームワークを使っているとき、開発時にもサーバーを起動して動作確認をしていると思います。
例えばDjangoであれば python manage.py runserver
というコマンドでサーバーを起動できます。
なぜこのサーバーを使わずにgunicornを使うのでしょうか?
理由は簡単に言うと、動作が速いからです。
gunicorn やuWSGI、 waitress といったWSGIサーバーは速く、 安定して動作することを考慮して作られています (何をもって「速い」と言うのかは別の機会に詳しく解説できればと思います)。
なので、一般に公開して多くの人に使ってもらうサーバーなどでは、専用のWSGIサーバーを使うほうが良いです。 「本番環境ではgunicornなど別のWSGIサーバーを使う」と、プラクティスとして覚えておくと良いでしょう。
gunicornのインストールは、その他のPythonパッケージのように pip
でインストールできます
(ここではpipの詳細や、Pythonの仮想環境を使う方法については説明しません)。
$ pip install gunicorn
gunicornをインストールすると gunicorn
というコマンドが使えるようになります。
WSGIアプリケーションを起動するには、この gunicorn
コマンドを使って起動します。
以下の例では wsgi.py
ファイル内の application
というWSGIアプリケーションを起動しています。
$ gunicorn wsgi:application
ファイル中のWSGIアプリケーションの名前が application
の場合、以下のように名前を省略できます。
$ gunicorn wsgi
どんなPython製のWebフレームワークを使う際にも「WSGIアプリケーションがどこにあるのか」を知っていれば、 gunicornなどWSGIサーバーを使って簡単に起動できます。
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のプロジェクトディレクトリー内で以下のように実行します
(ここで言うプロジェクトディレクトリーは 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_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に指定できるオプションの中でよく使うものを説明します。
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
アイコンフォントを使って li
要素の list-style
をカッコよくします。
li要素の list-style
でアイコンフォントを一覧の頭に表示するには、以下のように擬似要素を使ってできます。
この例では Material Icons
アイコンフォントを使っています。
ul { list-style: none; li { &:before { font-family: 'Material Icons' sans-serif; content: 'check_circle'; } }
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'; } }
キレイにまとまりました。 やったー。