Make組ブログ

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

1分で伝えるコツ

f:id:hirokiky:20170814230303p:plain

大人になるほど、短い間に口頭で伝える重要さが増してきている気がします。 仕事の中でも大いにありますが、いろいろなイベントなどでも短い時間で人と話す、伝えるという機会はでてきます。

どうしてもうまく短く伝えられないなぁ、という悩みはあるかと思います。

短い時間、とくに 1分で伝えるコツ を僕なりにまとめておきます。

対象ではないこと

  • 嘘でもいいから話せというような「話術」
  • 社会人の必須スキル的な捉え方や「できないやつはダメ」的な姿勢

こういった姿勢の文にならないようにまとめています。

また、好き勝手話せればいいやという雑談の場合も想定していません。

対象にすること

短い間で伝える必要がある、考えを簡潔にまとめたい、というときに参考にしてください。

  • 1分で話すときのコツ
  • 思考をまとめるコツ
  • 話しながら考えるときのコツ

自分の考えを短く分かりやすく、最小限の労力で伝えられるようになりましょう。

1分間の流れ

1分は一瞬です。以下の順に話しましょう

  1. 要するに、何なのか（5秒）
  2. 意味を一文で（20秒）
  3. 共感できる例を1つ2つ（25秒）
  4. 要点の再掲（10秒）

5秒、20秒、25秒、10秒くらいの配分で、1分は終わります。

1. 要するに、何なのか

1分で何かを話すとき最も重要なのは 要するに、何なのか です。

その1分で伝えたい1つのこと です。何を言いたいのか、どんなものを紹介しているのか、何が面白いのか、伝えたい感情はなんなのか、ということです。必ず1つにします。

例えば

  1. PyQ の魅力は、ブラウザだけで徹底的にPythonを学べることです

のような一言です。

他には「裁定取引とは価格差を使った稼ぎ方です」などです。

ポイントは2点です。

  • 「〜は」、「〜とは」、「〜とは要するに」と先に言ってしまう
  • ある一面を伝えられれば十分と割り切る

「〜とは」と始めることで話のまとまりがつきやすくなります。 話しながら考えるときは、いかに自分の思考を切り落とすかが大事 と僕は思っています。「〜とは」と話始めると、一息の間に話せる内容だけが頭にまとまってきます。

また、 一面を伝えられればそれで良いと割りきりましょう 。ものの性質や魅力は一言では語れません。長々と話して分からないよりも「これだけは持って帰ってほしい」と思うものを1つだけ伝えたほうが良いです。1分では伝えられませんし、1時間かけたところで相手は1つしか覚えてないからです。

「〜とは」で始めて、一文で「〜です」と終わりましょう。思いが大きければ大きいほど「〜で、〜で、〜で」と続けたくなりますが、最良の1つだけを選びましょう。

2. 意味を一文で

「要するに」の後は肉付けする一文を話しましょう。

一文目は結論です。結論だけ言われても納得できませんし、意味や背景が分かりません。その「意味」を次の一文で話します。 例えば前の例に一文足すと、このように説明できます。

  1. PyQ の魅力は、ブラウザだけで徹底的にPythonを学べることです。
  2. もともとプログラミングの障壁になるのは2点で、学習する環境を用意することが大変なことと、入門の内容はできても実務で活かせない・プログラミングを身につけられないことにあるんですね

こうすれば「要するに」の部分であった「PyQの魅力」に意味が肉付けされます。聞いた人は「あぁ、だから必要なんだ」、「うんうん、あるよね」、「そういうことなんだ」という気持ちになるような意味を説明しましょう。 「要するに」が1つにまとまっていれば、話し過ぎない程度に意味を伝えれば良いので一番簡単な部分です。

3. 共感できる例

共感できる例を紹介して具体的なイメージを共有しましょう。

1分間では伝えたいことの0.01％ほどしか伝えられません。より具体的な イメージを共有するための共感できる例は大事 です。 相手への疑問も残しやすい点ですし、話が続けられるなら深堀しやすい点になります。

先の例をさらに膨らませると以下になります。

  1. PyQ の魅力は、ブラウザだけで徹底的にPythonを学べることです。
  2. もともとプログラミングの障壁になるのは2点で、学習する環境を用意することが大変なことと、入門の内容はできても実務で活かせない・プログラミングを身につけられないことにあるんですね。
  3. 例えばPyQはサイトに行って登録しさえすればすぐにプログラミングの学習を開始できるんです。エディターとかプログラミング環境、ターミナルとかはすべてブラウザー越しに使えるんです。あと、PyQのコンテンツはプログラミング言語の入門だけでなくてWebアプリケーションの作り方とか集計スクリプトの作り方、ユニットテストとか設計のお作法まで動かしながら学べるんです。

肉付けされた「意味」が、具体的にどう実現されているのかを紹介できます。

とくに、 相手と自分の間でどれだけのコンテキストが共有されているかが重要になります 。なるべく引っかかる単語を散りばめてイメージを膨らませたいところですが、相手と自分の間で「通じる単語」がズレていては意味がないからです。

これが 共感できる例 です。今回の例ではある程度プログラミングを知っている人に伝えている場合を考えています。「ターミナルがブラウザで動くんだ」といえば、それがどれだけ意味のあることなのかも伝わる相手に、「ターミナル」という具体例をだします。

さらに具体例が良いと疑問を持ってもらいやすくなります。例えば「ターミナル？OSは何なんだろう」や「ターミナルを自由に使えて運営は大丈夫なのか？どこまで制限があるんだろう」などの疑問がでてきます。 1分で伝えられることは1つです。なるべく共感できる具体例をあげておいて、時間があるときや質問時間に話が繋がりやすくしておくのが良いです。

具体例はお互いのイメージを共有して、想像を働かせられるのが大事です。 お互いのコンテキストを理解して紹介することが大事になります。

4. 要するに何かの再掲

要するに何かの再掲とは、「意味」と「要するに何か」をもう一度話すことです。

具体例を通して話す人も聞く相手も言いたいことを納得できましたが、ここでもう一度話の頭に戻って話をまとめます。 これがないと結論がボヤケる雑談になってしまうので、戻ることは大事です。時間や体力に余裕があれば「意味」を振り返ってもいいですが、「要するに何か」をもう一度言うだけでも相手の記憶に残る話にできます。

  1. PyQ の魅力は、ブラウザだけで徹底的にPythonを学べることです。
  2. もともとプログラミングの障壁になるのは2点で、学習する環境を用意することが大変なことと、入門の内容はできても実務で活かせない・プログラミングを身につけられないことにあるんですね。
  3. 例えばPyQはWebサービスに登録しさえすればすぐにプログラミングの学習を開始できるんです。エディターとかプログラミング環境、ターミナルとかがすべてブラウザー越しに使えるんです。あと、PyQのコンテンツはプログラミング言語の入門だけでなくてWebアプリケーションの作り方とか集計スクリプトの作り方、ユニットテストとか設計のお作法まで動かしながら学べるんです。
  4. なので、プログラミング学習の障壁になる、環境の用意、実務で活かせないってことをPyQは解決できるんです。だからPyQで学ぶ意味があるんです。他にないPyQの魅力は、ブラウザだけで徹底的にPythonを学べることなんです。

話のスジが通っていること、繋がりがあることを意識して結論にもっていきましょう。

とくに最後の一言が曖昧になると、話として言いたいことを覚えてもらえません。 要するに何か〜から意味、具体例をうまく話せていれば、繋がりは保証されているので大丈夫です。

さてこれでPyQを紹介する1分になります。 ぜひ1分で読んでみてください （脳内で読んでも良いので、時間を測ってみることが大事です）。

話しやすくなるコツとしては3つ

  • 抑揚をつけること
  • 助詞は言い間違えても飛ばしても気にしないこと
  • 口語的に伝えること

こうしたほうが話しやすくなります。

まとめ

  • 一言目には「要するに、何か」を伝える
  • 二言目には「要するに」の意味を肉付けする
  • 三言目には共感できる具体例をあげる
  • 最後に「要するに」を再掲して締める

このメソッドを意識しておけば、1分という短い時間でも人に伝えたいことを伝えられると思います。 どうしても短く話せない。どれだけ話しても相手に伝わってる気がしないというときに、思考をまとめるコツ、話しながら考えるときの補助ツールとして参考にしてもらえると嬉しいです。

短く簡潔に、最小限の労力で伝えたいことを伝えられるようになりましょう。

最後に、素晴らしい本から1つ引用しておきます。

文章力のある人を雇う。

マーケターでもセールスマンでも、デザイナーでもプログラマーでも、文章力は大きな要素となる。 文章がはっきりしているということは、考え方がはっきりしているということである。 文章家は、コミュニケーションのコツもわかっている

小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)

小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)

それでもうまくいかないときは

推定ですが、方法や思考法でなく心理的な部分が大きいと思います。

以下のように割り切って考えるのをオススメします

  • 1分ですべては伝えられないと諦める
  • 正確さより相手に伝わることが大事だと考える

まず自分の爆発する思いは0.01％しか伝えられないと諦めましょう。

どれだけ素敵な気持ちや思いがあっても、ある時間内に伝えられることは限界があります。 いっぱい喋ると話の軸がブレてしまいますし、たぶん相手は1つ2つのことしか覚えられないです。

細かいニュアンスや、表現しきれない思いはいっそのこと捨てましょう。 難しい単語も諦めましょう。たまに「べき等性」のような言葉をどうしても思い出したくなってしまいますが、すぐ諦めて「何回実行しても同じ結果になる」とか平易な言葉で言いましょう。

安心してほしいのが、短い間で要点を伝えられた場合、相手も質問を重ねてくれる可能性が高くなるということです（元の話を理解できないと質問もできないからですね）。その質問を貰えれば、さらに「はい。～とは～です」から続ければ良いわけです（時間が許すのであれば）。

とにかく頭がフリーズしないように、なるべく簡単に考えましょう。口を動かしながら考えて、相手に一つ一つ要点を伝えましょう。

（もちろん雑談のように好きに思いを話せれば良いという場合は、こんなこと気にせず好きに話したほうが楽しいですね）

このメソッドの使い道

1分間で何かを話したいときに、筋道として意識する程度にすると良いと思います。

厳密に一文であるかどうかなどは気にする必要はないです、時間配分や、話の持って行き方として気にしておくと良いかなーくらいです。

これはもともと論文や評論で使える書き方です。僕が書いたのは、それを「1分間で伝える」ためにまとめ直した内容とも言えます。 なので、ブログを書くときや何かスライドを作るときにも使える方法だと思います。実際この記事自体がだいたいそういう書き方になっていると思います。

この話をしたかった理由

社内の読書会をしているときに重要さに気づいたからです。

先日のブログで「BeProudの社内読書会でReadForActionという方法で読書会をしている」と書きました。 このReadForActionでは、担当した質問や要点に2分という限られた時間で話す必要があります。

blog.hirokiky.org

回を重ねるごとに、自分も参加メンバーもエレベーターピッチのコツを掴んできていたように思います。 とくに、 時間の決められた短い間で話すことで自分の思考や知見が凝縮される イメージがあります。 この短い時間で話すコツは、思考をまとめるコツとしても重要なのではないか？個人に左右されずにポイントをおさえて練習できるのでは？とおもったことにあります。

また、匠メソッドでのまとめをエレベーターピッチで話せるようにしておくというのも面白いです。 短い間で話すことは、自分の思考力やまとめ力も上がるんじゃないでしょうか。

shacho.beproud.jp

ちなみにトップの画像ははるおさんが撮ってくれたやつです https://twitter.com/haru860/status/778444491648700417

1分で伝えるコツ、もう一度まとめ

  • 一言目には「要するに、何か」を伝える
  • 二言目には「要するに」の意味を肉付けする
  • 三言目には共感できる具体例をあげる
  • 最後に「要するに」を再掲して締める

「0から1の発想術」は0から1を発想するコツを教えてくれる本

製品開発

f:id:hirokiky:20170804210047p:plain

何か作りたい、生み出したいという気持ちはあるのにアイディアや発想が湧いてこないことがあると思います。

もっと発想が湧いてきたらいいのに、がむしゃらな思いつきじゃなくて効果的な発想ができたらいいのにと、私もよく悩んでいます。

もちろん本や手法に頼っただけで良いアイディアが湧いてくるわけではありません。 ビジネスや製品、サービスに関するノウハウ、本には、怪しい商売やうさんくさい方法論が多いのも事実です。

ですが1つの参考として、この本を知っておくのは損ではないと思います。

一個人が新しい何かを生み出していく時代

「0から1の発想術」という本を読んでみました。

この本は大前研一さんという人の本で、以下の主張のもと、0から1を生み出す助けになる11個の発想術が書かれています。

「これからの時代は好景気ってだけで食えるわけじゃない」

「一個人が新しい何かを生み出していく時代だ」

「0から1を創造する力が必要」

「0から1」の発想術

「0から1」の発想術

発想のコツ集として読める本

この本は平たく言うと「発想のコツ集」とも言える本です。 ポイントは3点です。

1. 何かを生み出すときに必要な考え方を教えてくれる

単に技や手法、思考法でなく基本的な「新しい価値を生み出す」という考え方も書かれていました。

基礎編1の「戦略的自由度」の話では

  • お客さまの価値を第一に考えること
  • 第二に今ある方法（軸）以外を考えること
  • 最後にその軸に沿った方法を考えること

が大切であると説かれています。

他にも基礎編4「固定費に対する貢献」、5「デジタル大陸時代の発想」、9「RTOCS」、11「構想」は、新しいものを生み出す上での基本的な考え方が説かれている印象でした。

このあたりの内容は匠メソッドや匠シンクにも通じるものがあると感じました。 何か製品やサービス、価値を生み出す際の基本になる考え方には普遍的で共通なものがあると感じます。

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

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

2. 発想に使える技集

また、 「こういう発想は使えるよ」 というような思考の切り口を紹介してくれている本でもあります。

基礎編3の「ニューコンビネーション」では既存の2製品、概念を組み合わせることで新しい発想を持とうという考え方が紹介されています。

例としては「携帯電話」と「ネットオークション」を合わせた「モバオク」などです

基礎編2「アービトラージ」、6「早送りの発想」、7「空いているものを有効利用する発想」、8「中間地点の発想」、10「すべてが意味することは何」は、発想術、思考の切り口として具体的な方法が紹介されています。

この考え方を元に、日常生活する中で発想してみるだけでも何かアイディアが湧いてきそうな気持ちになります。

3. 実践していく中での考え方と問題への対処法、ヒント

実際の例をあげての物語的な部分は強いですが、各事例から成功や失敗の原因が紹介されていました。

2017/08/07追記

さらに読み込んで、この「実践編」は11の発想術で発想できないときの発想術や基本になる考え方が書かれていると分かりました。

とくに「実践1. 感情移入」からは 自分自身がビジネスに惚れ込んで感情移入すれば発想は湧いてくる というメッセージが読み取れて、とても納得できました。

こう発想してみようという切り口やコツを知れる本

この本は「自由な発想を持っていこうよ」「こう考えれば良いんだよ」というようなメッセージを感じます。何か生み出そうとするときの自由さや発想の切り口を教えてくれます。

またその習慣をつけて、トレーニングしていくことで発想できるようになっていこう、という内容でした。 「このチャートを埋めていけばアイディアがでる」のような本ではなく、発想の切り口を与えてくれる本という印象です。

何かを生み出そうとすればするほど頭の中はこんがらがって、狭い視野や市場で考えてしまいがちです。 そういったときに、この本を読んで「立ち返った」自由な発想で新しい製品、サービスを考えるのが良いのではないでしょうか。

社内読書会で読んで良かった本

この本をBeProud社内で読書会 BPRA をして読み進めました。

www.facebook.com

参加者内で議論できたり、共通認識が作れたりと、単に本以外の学びが多かったです。

もともと1人でこの本を読んでいたときは「なんか微妙だなぁ」「それくらい僕も知ってるよ」という斜に構えた読み方になっていましたが、話し合ったり人の説明を聞く中で「あぁ、そういうメッセージなんだな」と深い理解に至れたかなと思います。

ReadForActionが良いのは本の良し悪しに関係なく、興味ある、学びたい分野についてを本をキッカケに共有できることにあると思います。 今回は読書会より前に読んだときに本から深く学べなかっただけに、参加者メンバーの言葉を通して強く学べて良かったなと思います。 BeProud社内読書会BPRAについて興味ある方は以下の記事を読んでみてください。

本好きな会社〜読書会による組織学習 - ビープラウド社長のブログ

合わせて読むと良さそうな本

この本はビジネスになる構想や発想を出していこうという、「戦略的な」「ビジネスな」視点が多い本でした （2017/08/07追記 この本の中でも実践編1 感情移入などはそういった視点が強い部分です）。

実際に製品やサービスを作る中では「関わる人の嬉しいを考えよう」のような、ハートな部分も深堀されている本も読んでみると良いかもしれません。 前述の 匠メソッド や MarketingForDelopers という本をオススメしたいです。

devmarketing.xyz

僕はユーザーの方やお客様への共感を持ったり、何とか助けになりたいという気持ちもとても大事だと考えています。

0から1の発想術から学べたこと

とはいえ 新しいものを作って世の中を良くしていこう、こう考えてみれば発想は湧いてくるんじゃないかな、という本として読んで良かった なと思います。

何か新しいものを作りたい、発想を持ちたい、煮詰まった頭をリセットして考え直したいという方にはオススメしたい一冊です 。

今後、僕たちとしてどう活かせるか

2017/08/07追記

読書会参加者のメンバーと「この本を読んで、今後どう活かせるか」という議論をしました。

BeProudという会社として新しい価値を提供するときの発想に活かせるか、今ある事業の中でもっと何か価値を提供できないかと議論しました。

また、ビジネスや企画に関する本も製品やサービスが生まれるロードマップの中に位置づけて捉えられるのではないかと話していました。 ロードマップの中で考えることで他の人に知見を共有する場合や、自分が何かを考えている時にどのレイヤーで思考しているかを考えられそうです。

ゲイン、ペインや悩み、不満 => アイディア => 企画、モデリング、分析、プロトタイプ => 設計、開発 => 運用、サポート、展開

僕達の製品である PyQ をより良くする発想や、悩みを解決できる製品、サービスづくりに今後も取り組んでいきたいと思います。 良いものを作って、世の中をもっと便利に楽しくしていきたいです。

「0から1」の発想術

「0から1」の発想術

ヒヨッコの僕たちはこうして新規プロダクトPyQを企画・開発・販売しました

ヒヨッコの僕たちはこうして新規プロダクトPyQを企画・開発・販売しました

f:id:hirokiky:20170807211628p:plain

今日、4月12日は何の日でしょうか？ 久々に晴れて気持ちが良かった日？それももちろんそうですが違います。

今日は PyQ の正式リリースの日です！

こんにちは。@hirokikyです。 これはヒヨッコだった僕が、僕たちが1年で勉強した、製品の企画、開発、価格戦略、マーケティング戦略の話です。 チームのみんなで勉強して奮闘した1年でした。

自信過剰のヒヨッコ、ky

僕は自信たっぷりでしたが、ヒヨッコでした。 僕は今までも自分で PileMd を作ったり、 PythonとDjangoでお仕事してきたりと自分と製品づくりには結構自身がありました。

でも

  • 「ホントウに人が欲しい価値あるものを作る」
  • 「何かを作ってお金をいただいて、そのお金でもっといいものを作る」
  • 「作ったものを求める人に届ける」

ということはできませんでした。今思えば。 エンジニアとして自信があっても、ホントウに求められる製品を作る方法とか、値段の付け方とか、宣伝の仕方とか分からなかったです。

たぶん、これができる人はすごいと思います。できたら起業しろって、そういうレベルですね。

正直分からない。。。どこで学べば良いのかも分からない。。。 実際「新規の事業を企画して開発して売る」まで一気通貫でできる機会って少ないんですよね （そりゃ毎日何かがリリースされてたらチョット忙しいですよね）。

で、僕は全くその辺を知らなかったんですが1年 PyQ_ を通して学んだことを書きたいなと思います。 数人の少ないチームのみんなで勉強しながらここまでやってきました。大変でしたがチームも、会社自体も成長できたと思います。 （これからもみんなでやっていこうな！）

今日、リリース時のテンションで書いてるので、雑筆なのは許してください。

製品の企画！どんな価値を提供するの？

さて「新しいビジネスをやるぞ！」と意気込んでも何を作るんでしょう。 とりあえずで「ブルーオーシャンを狙った」自分でもよく分からない物を作ったことある人は僕だけじゃないはずです。ありますよね？

まずは、何をつくるかを決めましょう。どうやって？

PyQではまずharuさんの思いから始まりました。平たく言うと 「技術の底上げをしたい。多くの人はプログラミングとかの技術に興味があるし今後も人が増えるけどできない。人材の紹介とかパイの取り合いはやってるけどパイを増やすことができていない」 という思いから始まります。

でもそれだけだと何にもならないですよね。これを育てていかないといけません。

僕は1年前にこの企画に入ります。それまでは同僚のかめちゃんが1人でプロトタイプとかを作って、haruさんshinさんと模索している段階でした。 入ったときは今の PyQ_ の原型もほぼなくて、SQLを学ぶプラットフォームだったりしました。 僕が入る中で「この製品はいけてないな」とかエラそうなことを言います。 そこで僕もプロトタイプに入って、コンテナー技術でうまく学習プラットフォームを提供する仕組みを作ります。

でもやっぱり何か違う。 何をつくるかってどうやって決めるんでしょう？

そこで4人（haru, shin, kameko, 僕ky）で企画から練り直すことになりました。 一旦みんなで本を読んで、ひたすらそれを元に僕たちのストーリーは何かと話しました。

ここで、参考になる本をお伝えします。

この本では事業のストーリーを練って価値あるものにしていこうということが書かれています。 この中でPyQというものが見えてきました

  • Pythonを使うこと。Pythonを徹底的に学べること
  • BeProudの知見を最大限盛り込むこと
  • BeProudの他事業（研修事業など）と連携すること
  • オンラインで学べること

が大まかに見えてきます。ストーリーも浮かび上がってきます。 おぉ、これはすごいぞと。

そこからさらに踏み込んで、ステークホルダーの人々、そこにある要求、提供できる価値を見える化していきました。 その方法には匠メソッドという方法を使っています。

匠メソッドは「ステークホルダーは誰か、私たちは何か、で、提供できる価値は何か？」を図に書きながら掘り起こす手法です。 これで、チームで合意を形成しつつ、ぶれない「製品の価値」を定義できます。

これは今BeProudの会社としても、例えば受託でお仕事いただくときもお客さまにとっての価値は何かを見つけるために使っていたりします。 PyQでもこの匠メソッドを使って「使う人、関わる人に取っての価値は何か？」を徹底的に徹底的に掘り下げました。

このプロセスはスピード感はありましたが、延べで1,2ヶ月ほど時間を使っていた記憶です。 でもそのおかげで、全く的はずれな製品に注力することなく価値ある PyQ_ を作れたと思っています。

開発と製品を良くしていく方法

Webアプリ、フロントエンド、インフラ、デザイン、HTML、CSSなどなどの開発は全部僕がやっています。 ので、基本的には僕が「ガッ」と作って皆んなに見てもらってヤイヤイ言い合って、ときにユーザーさんの価値に立ち返って製品を育ててきました。

問題やカリキュラムについてはkamekoが主導して頑張ってくれました。

ここで良かったことをあげます:

  • とにかく速くあげて速くフィードバック貰った
  • 朝会で認識を共有してオンラインで言えないことを言う
  • ベータユーザーさんやアルバイトでお願いしたモニターさん、社員のフィードバックを徹底的に反映する

というスタイルを取っていました。

製品の動き、UXについてもそうですし、問題文の構成や学ばせる手順などもすべてゼロから作る必要があります。 とにかく計画してみて作ってみて、自分たちで使ってみてというのを繰り返していたように思います。

ホントウに、この段階から使ってくれた方のおかげて今の PyQ_ があると思います。 でも大事なのは「フィードバックを真に受けずに作る人間が責任持って価値を提供する」ことだと思います。

ときに、使う人自身が見えてない価値を提供するのが作り手だと思うので、 使う人にはチョット申し訳ないですが、たまに真意だけ受け取って内容をスルーしたりもしました。

大事なのは常に、ユーザーさんにとっての価値を提供することだと思います。

で、いくらでどうやって売るの

おそらくこれがエンジニア的に最大にして最強の壁だと思います。 自社サービスの会社で働こうが、受託の仕事をしようが、自分で値段を決めて自分で広めて使ってもらう機会はなかなかないと思います。

僕も多少はあれど、ガッツリ製品として売っていくことは初めてだったので分からないことだらけでした。 えぇ、もちろんチーム全員としてそうですね。チーム全員、どうすりゃええねんと。

ここでharuoさんが良い本と学習教材、勉強方法はどうかな？やってみない？と提案してくれました。 1つ、学習方法はRead For Actionという方法でチームで本から学んでみよう。 2つ、価格については各自持ち寄った価格に関する本を使ってReadForActionしよう。 3つ、販売については神田昌典氏まわりの本やWeb教材から学んでみよう。

ということでした

この本は参考になりました。

この辺の内容を参考にしつつ、チームでとにかく議論して決めました。 この頃にはLPや広告画像のデザインしてくれたmarippeも加わりなかなかホットなチームでした。

さて、価格において、販売において重要なのは何でしょうか。

色々学んだ中で考えるとやっぱり「お客さんに提供される価値はなんだろう」に尽きると思います。 お客さんに提供される価値から価格を考えたり、提供される価値・喜んでくれる人に対して知ってもらう。ということです。

原価やリソースの費用、稼働時間を元に価格を計算するのでなくて、お客さんに提供される価値を元に値段を決める。 これは大変なことですが、大事な考え方だと思います。

そもそも、お客さんに提供される価値が自分たちに見えていないと価格も決めれないってことですね。

売っていく方法

大々的にPRすればそれで良いでしょうか？ Twitterで拡散すればそれでOKでしょうか？

違いますよね。すぐ話題が終わってしまいますし、知り合いがチョット知ってくれて終わりになっちゃいます。

結局、僕もそれまでのチームもコンフォートゾーンから出れてなかった気がします。 自分たちの知り合いや、身近な人しか想像できない狭い世界ですね。

そうじゃなくて、ホントに必要としてくれる人に会って、話して、その人達に使ってもらいたいです。 もちろん知り合いの方にも使っていただいてますし、農婦の方とかもいらっしゃって、今までの自分とは違う世界に来たなと思います。

話が長いので詳しくは割愛します。

神田昌典氏の講座もどうぞ http://www.cp.almacreations.jp/digital/

まとめ

自社で新規の事業を企画、開発、販売するなかで感じたことは

  1. 作れ！
  2. 学べ！
  3. 自分とチームのセンスを信じろ

ですね。

とにかく作らないと見えない。とにかくリリースしないと分からない。それが新規の事業です。ゼロからイチを作ることだと思います。 本だけ読んでエラそうな顔してた僕が言うんだから間違いないです。やれば苦労がイッパイあります。苦労しかない！？ そしてとにかくリリースしましょう。リリースされてないコードはゴミです。リリースされて、人に使われて物語は始まります。

あとは今の自分にないものを積極的に学ぶことですね。 うさんくさいオッサンだろうが、マーケッターだろうが営業だろうがマッキンゼーだろうが、僕らにとってはその分野の師匠です。 新鮮な、謙虚な気持ちで弟子入りしましょう。

あと、最後にはやっぱり僕たちの力を信じるしか無いです。 ものを作る間、ホントウに価値があるかなどホントウに気を病みます（僕もメンタルはタフな自信がありましたが逆食と神経性胃炎になりました）。 大事なのは自分のセンスを、自分たちチームを信じることです。最終的には「自分たちが何をするか」です。誰に言われるかでなく。 自分たちの製品、価値、お客さんに責務を持って「調整するのでなく決める」ことが大事です。

以上、他にも勉強になった本は大量にありますし書きたいこともイッパイあります。 まずは、リリースしたテンションで書いてみました。

チームで活動してくれたharuoさん、shinさん、kameちゃん、marippe、esuji氏、shimizukawa先生、john、お疲れ！! ベータユーザーの方、モニターの方、社員の皆さん、協力してくれた人ありがとう。

PyQ_ の物語はまだ始まったばかりだ！（プリンセス・ハオ）

Build, Minify, Merge TypeScript by webassets

Build, Minify, Merge TypeScript by webassets

Today, I introduce webassets to build TypeScript, minify each generated JavaScript, and merge it.

webassets is a media manager written in Python to merge JS, compress JS/CSS, uglifying, and so on. and It also provide the way to coraborate with a veriety of WebFrameworks.

But in this post, you can learn way to build, minify, merge JavaScript from commandline interface by webassets:

Install

First, install webassets and I’ll write config file for the buliding as YAML file. so you also need webassets with PyYAML.

pip install webassets
pip install PyYAML

now you might get webassets==0.9, PyYAML==3.11.

And to minify JavaScripts, install jsmin.

pip install jsmin

Python requiremests are them. And ofcause TypeScript is necessary to bulid them.

npm install -g typescript

now you’d better to check ‘tsc’ command.

OK. let’s make it.

Configuation for building

Now let’s write the configuration file. You can put ‘webassets.yml’ file you want. In this post, I won’t show you how to write it step by step. But I’ll show you a case and it’s sample file, and then, describe each meanings of it.

The case is for building a JavaScript file to a web application. It requires three external libraries (jquery, knockout, and underscore) and files I wrote are written in TypeScript. So you need to compile ts files and merge all of them and also minfy it. The number of TypeScript files is 7, 4 difinition file and 3 application files The config file of this case will be like this:

directory: ./karmaid/static
debug: False
bundles:
  js-karmaid:
    contents:
      - js/lib/jquery-2.1.0.js
      - js/lib/knockout-3.1.0.js
      - js/lib/underscore-1.6.0.js
      - contents:
        - js/app/config.d.ts
        - js/lib/jquery.d.ts
        - js/lib/knockout.d.ts
        - js/lib/underscore.d.ts
        - js/app/api.ts
        - js/app/ko_flushvalue.ts
        - js/karmaid.ts
        filters: typescript
    filters: jsmin
    output: js/karmaid.js

  • directory: : it means the root directory http://webassets.readthedocs.org/en/latest/environment.html#webassets.env.Environment.directory

  • debug: : you can switch it by own enviroments http://webassets.readthedocs.org/en/latest/environment.html#webassets.env.Environment.debug

  • bundles: : you can put own ‘bundles’ under it. Each bundles are corresponding to each output files. so If you want to create JS file for Top page of your application, you may create js_top bundle and write config to merge or minify some Javascript files. In this case only ‘js-karmaid’ is appearing.

  • contents: : the output file will be constructed by each elements of this list. Own elements will be automatically merged and the file written in ‘output’ will be generated. And it can discribe ‘nested bundle’ in it. In this case, each typescript files are in js-karmaid bundle which means these ts files will be builded before minifying and merging each JavaScript files.

  • filters: : Specify to minify, build, uglify and so on.

    -   jsmin is for minifying JavaScript by 'jsmin'
    <https://pypi.python.org/pypi/jsmin>
-   typescript is for building TypeScript and generating
    JavaScript files. If you use external libraries you also
    need specify difinitely files
    <https://github.com/borisyankov/DefinitelyTyped>

You can learn about all of filters provided by
[webassets](https://pypi.python.org/pypi/webassets/0.9)
<http://webassets.readthedocs.org/en/latest/builtin_filters.html>

Run command

After making the config. Run the command to build:

webassets -c webassets.yml build

Then you can get own JavaScript files to correspond to each bundles. In abeve example, you can get ‘karmaid.js’ file.

If you want to generate one JS, run it:

webassets -c webassets.yml build <bundle name>

it’s over.

Why webassets

Because I wanted to try it. You know, you can choice fanstatic or grunt too.

And I want to use it with Pyramid and Python3, but now, pyramid_webassets on PyPI isn’t support Python3. This supporting will be finished soon (https://github.com/sontek/pyramid_webassets/issues/23).

Python mini Hack-a-thon 雪山合宿 2014 に行ってきた

Python mini Hack-a-thon 雪山合宿 2014 に行ってきた

Python mini Hack-a-thon 雪山合宿 2014

今回3回目の参加になる､Python mini hack-a-thonの合宿版です｡ スキーはせずに引きこもって開発してました｡

開発したもの:

genaa 0.4リリース

genaa というASCII Art生成ツールの最新版です｡ 日本語など､1文字で2幅以上持つ文字列に対応しました｡ @nakamuray さんがフォークして開発しててくれたので取り込ませてもらいました｡

invokeにプルリク

invoke はローカルでのコマンドをまとめるようなツールで､Pythonで書けるmakeみたいなものです｡ 実行できるタスクの一覧を ‘invoke –list’ で取れるんですが､ その際に各タスクの説明のサマリを表示するようにする対応をしていました｡ まだ反応がないのでどうなるかわかんないですが｡

遊んだテーブルゲーム

  • Love Letter: さっくり楽しめる&導入も簡単な割によくできてる印象｡
  • 犯人は踊る: かなり面白かった｡犯人は誰なのかと推理していく感じがよかった｡
  • Dungean of Mandom: あんまり掴めなかった｡

提供は @kiris さんより｡

New year's python meme 2013

New year’s python meme 2013

Today is the final day of 2013, time to write New year’s python meme. This is the last year’s one:

1. What’s the coolest Python application, framework or library you have discovered in 2013 ?

Kaa is the coolest application. This is a CUI editor written in Python3.3. It is easy to use and useful, so I changed to use it on a routine basis. The development of kaa is very active, a new version is available almost everyday. Check out the version history.

I’m checking a Webframe work named morepath, too.

2. What new programming technique did you learn in 2013 ?

I learned how to distribute packages, creating libraries and Web frameworks. And learned the basics of Python, HTTP and WSGI. Last year, I didn’t know about them. just I created own Web applications using some frameworks. I aimed to learn them, written in 2012’s python meme. All of things I created and contributed are available on next section.

3. Which open source project did you contribute to the most in 2012 ? What did you do ?

May be Django. This year I joined one of django authors.

Or, Uiro framework.

And I created many libraries this year:

I also contributed existed projects:

4. Which Python blog or website did you read the most in 2013 ?

In Japanese:

5. What are the three top things you want to learn in 2014 ?

  1. English:

Next year, I will join to EuroPython2014. This will be the first time to join another country’s event. I will learn about English in order to enjoy this event much more. I listen to VOA Leaning English these days.

  1. How to keep developing and improving one project:

This year I created many packages, but almost of them are left alone. And I learned that the first release is not so important. To create effective and useful software, it is necessary to keep creating and improving.

  1. Not only Web. I’ve learned about Web programming for about 2 years:

This year, I will try to create something not relating Web. For the first step, now I’m creating genaa, a command line tool.

6. What is the top software, application or library you wish someone would write in 2014 ?

genaa is.

And some Web applications or libraries for Pyramid, not only Django.

I learned many things in 2013. I wish I would write more interesting things in 2014. Have a good holiday.

Pythonでバウンドインナークラスを使う (Python Advent Calendar 2013 最終日)

Pythonでバウンドインナークラスを使う (Python Advent Calendar 2013 最終日)

Python Advent Calendar 2013 25日目のブログ記事です｡

Python Advent Calendarでは例年最終日にはゲストをお迎えして記事を書いてもらっています｡今年は Python 3.4 のリリースマネージャーである Larry Hastings さんに書いていただきました｡

Larry, thank you very much for your posting to this Python Advent Calendar!

ここでは日本語訳を書いていきたいと思います!

Pythonでバウンドインナークラスを使う

Python において､関数をクラス中に定義した際にはある魔法が起こります｡ クラスのインスタンスを通して関数にアクセスした場合単なる関数が得られるわけではありません｡ 代わりに新しいオブジェクト「メソッド (method)」と呼ばれるものが返ります｡ 概念的にはこの関数はインスタンスに「バウンド/束縛 (bound)」されています｡ 実際にメソッドを呼んだ際にはそのインスタンスが関数の第一引数に自動的に 渡されます｡別の位置引数 (potitional argument)は1つ後ろに追いやられます｡

しかしこの魔法は関数にしか有効ではありません｡クラスについて考えてみましょう｡ Pythonでは､あるクラス C を別のクラス D 内に定義した際に､この C を 「インナークラス (inner class)」と呼びます (「ネステッドクラス (nested class)」かもしれません)｡ D のインスタンスを通して C にアクセスした場合､ さきほどのような魔法はおこらず､単に C が返されます｡ C を呼び出したとしても C.__init__ への引数は変わりません｡

インナークラスが Python で使われることは稀です｡なぜでしょうか｡ それをする実用的な利点が無いからです｡ Python のスコープルールによって面倒が生じます (後述)｡

それでも私は Python でインナークラスをよく使います｡ 概念的に他のクラス内にあるべきクラスの場合です｡ 大抵の場合インナークラスはアウタークラスに “バウンド” されて欲しいものです｡ しかしこのように､手動でする必要があります:

class D:
    class C:
        def __init__(self, outer):
            self.outer = outer
d = D()
c = d.C(outer)

関数がするように､インナークラスも “バウンド” されると良さそうです｡ アウタークラスが自動的にインナークラスの __init__ に渡されると良さそうです｡

でもこれって Python でできることなんでしょうか? 数年前､ Stack Overflow で聞いてみました:

http://stackoverflow.com/questions/2278426/inner-classes-how-can-i-get-the-outer-class-object-at-construction-time

返答には驚きました｡それが不可能というだけでなく､意味がないと言うからです｡ その後に Alex Martelli が､それは可能だと教えてくれました｡ その解法には心底驚かされましたよ!彼の解法はクラスデコレーターを使って､ クラスを「ディスクリプター (descriptor)」にするというものでした｡ これは関数がメソッドになるのと全く同じメカニズムです｡実に素晴らしい!

Alexの許可を得て､私はこれを「レシピ」として､ Python Cookbookに投稿しました:

http://code.activestate.com/recipes/577070-bound-inner-classes/

このアプローチには何度も手直しをしました｡今ではちゃんと動作しますよ! そして…そうなんです､このレシピは Python 2 と 3 両方で変更なしに動作します｡

このバウンドインナークラス (bound inner class) のことは本当に気に入っていますし､ 可能であればどこでも使います｡バウンドインナークラスを人に教えたときの 一番よくあるフィードバックは 「それのユースケースは?」ですが､ 私の回答はこうです「メソッド呼び出しのユースケースは?」 私が思うに､この2つは全く同じ質問です｡そしてバウンドインナークラスは メソッドと同じくらい便利なものであるとオススメしておきます｡ もしかしたらそれ以上かもしれません!

もちろん､クラスは関数よりも複雑なものです｡つまりはバウンドインナークラスは メソッドよりも複雑です｡例えば継承と2レベル以上のネストとなるとちょっと ややこしいことになります｡ こんな場合でもバウンドインナークラスが実用的で､理解しやくなるよう 考えてみました｡どう動作するかを少し理解して､いくつか単純なルールに従う 必要があります｡これについては､上記の「レシピ」にすべて記載されています｡

ぜひ皆さんのコードでもバウンドインナークラスを使ってみてください!

なぜインナークラスが不便になり得るかを疑問に思ってるかもしれませんね｡ 以下について考えてみてください:

class D:
    value = 5
    class C:
        value2 = value * 5

このコードは動作しません､ value について NameError を送出します｡ C のコード中では value が見えないのです｡ D のどのメンバーも見えません｡ C が見えるすべてのメンバーはグローバルとビルドインです｡ (残念ながら nonlocal キーワードもここでは助けになりません｡ これはネストした関数でのみ有効で､クラス本体はネストした関数のようには 振る舞いません)

ここで､コードをこんな感じに変えてみましょう:

class D:
    value = 5
    class C:
        value2 = D.value * 5

悲しいことに､これもまた動作しません｡ D はまだ存在しないからです｡技術的には､ D は “まだバウンドされていません"｡ このコードは D についての NameError を送出します｡

唯一動作するのは､ルックアップをランタイムで行うことです:

class D:
    value = 5
    class C:
        def __init__(self):
            self.value2 = D.value * 5

言い換えると､コンパイルタイムにおいてネストしたクラスは アウタークラスのどのメンバーにもアクセスできないということです｡

追伸､クリスマスを楽しむ日本の読者の皆様へ｡ 私が皆さんに教えてあげたいのは､実際にはアメリカ人は KFC をクリスマスに食べないということです!これは日本の KFC が創りだしたマーケティング上のギミックなのです｡アメリカ人は家族でのディナーを盛大に行うものですが､伝統的なメインコースというものはありません｡

以上です｡

Larryさん､ありがとうございました!

(なおフッターにあるCC-BYの表記はこの記事においては有効ではありません｡ The above expression about CC-BY is not available at this entry.)