Make組ブログ

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

Pythonでできることは?何が作れるの?その疑問に答える本がPythonエンジニアファーストブック

f:id:hirokiky:20170929114020j:plain:w500

こんにちは、埼玉のジャックニコルソンです。 シャイニングのつもりがよくあるYouTuberっぽくなった画像がこちらです。

さて、Pythonエンジニアファーストブックが発売されました!

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

どんな本なの?と聞かれることがありますので、紹介します。

Pythonでできることは何?何か作ったこと、ありますか?

そんなことありますよね。僕もWebばかりだったので、つい1、2年前までPythonでのデータ分析は触ったことすらありませんでした。

一通りPythonでできること、作れるものを知っておきたくはないですか?

  • Pythonで何ができるかだいたい分かっている 。できないことも分かっている。
  • データ分析Webアプリの作り方スクレイピングのやり方 など一通り知っていて、作ってみて動かしたことがある。

そうなれる本があります。 それが、Pythonエンジニアファーストブックです。

他の言語を知ってる人向けの本です

プログラミング自体全く全然分からない方、ごめんなさい 。この本は他のプログラミング言語をほんの少しでも知ってる人に向けた本です。

ですので、言語の説明やライブラリーのインストール方法などは必要最低限に絞っています。 逆に言うと、他言語を少しでも知っている、PCに慣れている人には簡潔で分かりやすい内容になっています。

そして、データ分析スクレイピングWebアプリ開発Pythonでのオススメ開発環境 などたくさんの内容が盛り込まれています。 もちろん、PythonのトレンドやPythonの基礎、インストールや導入方法、プログラミング開発の基本なども網羅されています。

初心者の人には説明が不十分の場合があるかもしれません。ですがその代わりに、この一冊でPythonの広い広い世界をぎゅっとまとめて体験できます。

(プログラミング自体分からない方が一通りPythonを勉強したいときは PyQ をオススメします)

自分で各ライブラリーを調べる必要がありません

この本にはPythonの基本はもちろん

  • Git
  • Pycharm
  • Sphinx
  • Pandas
  • JupyterNotebook
  • BeautifulSoup
  • Requests
  • Scrapy
  • Django

などが盛りだくさんで登場します。

もしそれらすべてを知ろうと思うと、インストール方法はもちろん、基本的な使い方やチュートリアルを調べるのは大変だとは思いませんか。 公式サイトやQiitaやブログを色々調べて、「これが良さそうかなぁ」という情報を探すのも大変です。

このPythonエンジニアファーストブックなら、それら すべてのインストール方法や基本的な使い方、実際の作り方が網羅されています

調査の時間で長いと1、2時間かかったりします。Pythonエンジニアファーストブック1冊分で、合計で10時間ほどの調査時間を短縮できるんじゃないでしょうか。

もちろん、この本を中心に分からない点は調べていただく必要があります。 ですが基本的な使い方をマスターしたうえで学んでいただくので、間違いなくその時間も短くて済みます。

スクレイピング、データ分析、Webアプリを作りながら学べます

さらに、本の中で一気通貫して 「レゴのサイトから情報を取って解析、Webで表示する」という課題を実際に作りながら学べます

プログラミングを学んでも身についていないということがありませんか? 作りながら学べて、しかも一通り抑えておきたい分野の内容を身につけられたらすごいですよね。

Pythonエンジニアファーストブックなら実際に作りながら学べる ので、Pythonやライブラリーの要点を抑えつつシッカリ身につけられます。 また、勉強のために自分で課題設定をしたりアプリを設計する必要もありません。

さらになんと、 すべてのソースコードGitHubで公開されています 。 正直これだけを参考にプログラムを読み進めてもかなり勉強になるんじゃないでしょうか。

github.com

もちろん本を買って勉強すれば効果や効率は高くなります。

未来のハッカーにもぜひ、体験いただけると嬉しいです。

要らない人には要らない本でしょう

言ってしまうと、Pythonでのスクレイピング、データ分析、Webについてよく知っている人には必要ない本でしょう。 また、全くのプログラミング初心者という方には厳しい内容だと思います。

ですので「ぜひどんな人でも買ってください」とはあんまり思いません。

ですが、 他のプログラミング言語をやってPythonに興味がある人 や、 Pythonを知っているけど知らない分野を体験したい人 にはオススメしたい一冊です。

前の版?全く違う本です

実は、この本は「Pythonエンジニア養成読本」という本を元に書かれた本です。購入いただいた方もいるかもしれません。 「同じ内容なら要らないかな」と思われるかもしれません。

ですがそれは違います。

こんな内容を学べます。

  • 1章 Pythonの動向
    • 最新のトレンドにアップデート
  • 2章 最低限知っておきたいPython言語の基本
    • 最新のPython3.6にアップデート。インストール方法も修正、言語の内容も追加修正
  • 3章 開発環境とチーム開発
    • 最新に各種アップデート。最新の仮想環境の作成方法など、ハマりどころも回避しています
  • 4章 スクレイピング
    • 完全書きおろし
    • 課題設定から アプリケーションまで新規に作っています
    • スクレイピングとは?」から学べます
  • 5章 PyData入門ガイド
    • 新規の課題に合わせて大幅修正、アップデート
    • 実際に4章で取得したデータからデータ分析を学べます
    • 販売されているレゴのデータから、ピース数と値段の回帰を求めたりできて面白いです!
  • 6章 Webアプリケーション開発
    • *完全書きおろし
    • 以前あったものはすべて捨てて、今回の課題に合わせてDjangoで書き直された大作です
    • Djangoアプリの設計から、DBの設計まで作っています
    • 取得したレゴデータを取り込んで、管理できるWebアプリを作れるようになります
    • 著者間のレビューで相当議論したので、かなり ノウハウが詰まったDjangoアプリと内容 になったと思います

内容からコンセプトなど全く新しい本となっています。

前回の「Pythonエンジニア養成読本」は、ムック本として全体をつまみ食いする雑誌的な面がありましたが、今回のPythonエンジニアファーストブックは本の体裁として大きく生まれ変わりました。

この本のお話をいただいとき、「本の改訂」という名目だったので気軽にやるかーと参加させていただきましたが、新しい本を作りあげる話だとは思いませんでした。。大変でした。。。w

300ページを超える厚みです

300ページを超える、けっこうな厚みのある本です。 Pandas、Scrapy、Djangoを学ぶ内容についても、実際の課題に取り組みながらプログラムを作る濃い内容になっています。

f:id:hirokiky:20170929102522j:plain

しかも、Scrapyで取得したデータをPandasで操作したり、Djangoで表示したりと章の間で課題が一貫しているのでかなり楽しめる内容です。 また、本の中にあるプログラムはすべてGitHub公開されていますので、このプログラムを読むだけで十分勉強になるような内容です(もちろん、本を買って読めばさらに効果的かつ時短になります

300ページという厚みは、今、僕の家の中で探したものだと「サーバ/インフラを支える技術」と同じくらいの大きさ、厚さです (上の写真がそれです。サーバ/インフラを支える技術は昔僕がお世話になった本です)。

内容の十分さを感じてもらえるのではないでしょうか。

Kindle版で、今すぐ始められます

Pythonエンジニアファーストブックには Kindle版もあります

今すぐこの下のリンクから購入いただければ、今すぐ、Pythonの世界を歩み始められます。

他のプログラミング言語は知っているのにPythonは知らない、Pythonは知っているけど分野が限られてしまっているなという方、ぜひ、Pythonエンジニアファーストブックで作りながらPythonの広い世界を体験してください

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

Pythonって便利で楽しいな、こんなものも作れるんだ、と感じてもらえると嬉しいです。

PyConJP2017で発表したり、PyQのブース出展したり、本のサイン会をしました

IMG_4090

9月8日から10日にPyConJPに参加して、発表したり、PyQのブース出店したり、チュートリアル講師したり、本を売ったりと色々やりました。

pycon.jp

発表

PyConJPで発表するのはこれで6回目で、2012年から毎年Djangoについての発表をさせてもらっています。

今年の発表はとくに、かなり気合をいれて準備、練習をしました。 というのも、今年はプロポーザルもとても多くて、発表の枠も例年より少なく、発表がかなり狭き門だったからです。

発表の内容は、Djangoでアプリケーションを作る時の認可についてです。 パーミッション関連のハンドル方法やライブラリーの紹介をしています。

僕が作ったdjango-keeperというライブラリーの紹介もしています。 https://github.com/hirokiky/django-keeper/

資料はこちらです。

発表中の写真も撮っていただきました。 ありがとうございます!

IMG_4300

時間としてはまるまる10日くらいはドップリ使って事前準備、資料準備、発表の練習をしていました。 仕事もあり執筆もあり大変な中でしたが、発表の質はイベントの質とも言えるほどだと思いますので頑張りました。 当日は部屋いっぱい(100,200人くらい?)の方に聞きにきていただいて嬉しかったです。 発表のあとで、パーミッションなどについても色々話せて僕自身学びがありました。

ブース出展

PyQ のPRのためにブースを出展していました。

この日のために新しく機械学習、Pandas、Web APIスクレイピングを学習できるコンテンツをドンドンと追加しています。 またJupyterNotebookを実際に動かして学べるようにもしていました。

ここ半年はかなりハイペースに開発やコンテンツ充実をしていましたし、トラブルなどもあって体力的にも精神的にもかなり疲れましたが、ブースでお客様に喜んで貰えたり、すごい!勉強したい!と言っていただいてとても嬉しかったです。

9月8日のチュートリアルでもPyQを使ってのチュートリアルBeProudとして提供しましたが、そこでもチュートリアル自体とPyQがご好評で嬉しかったです。

あと、カレーメシ先輩に内部の話をしていて、これはすごいと褒めてもらったのも嬉しかったです。

最後まで諦めずに、投げ出さずに頑張って良かったです。

これからもPyQ をもっと良いものにして、より多くの人がPythonのプログラミングを身につけられる、仕事にできるお手伝いができればと思います。

pyq.jp

本のサイン会

著者として関わった「Pythonエンジニアファーストブック」のサイン会も開きました。

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

かなりの盛況で、たくさんサインしました。 来てくださった方、買ってくださった方ありがとうございました!

ぜひ、Pythonでこんなこともできるんだなぁと知ってもらえると嬉しいです。 私は2章を担当しています。フィードバックなどあればお気軽に教えてください。

この本もまた一苦労ありましたが、レビューを何度も繰り返して、率直な意見を交わしてかなり良い本になったと思います。 初稿からの怒涛のレビューは本当に著者みんなでがんばれたなぁと思います。 これも、最後までちゃんと良い仕事ができて良かったです。

f:id:hirokiky:20170910200021j:plain

またPythonエンジニアファーストブックの読書会の企画もしておりますので、開催する際はぜひ参加いただければと思います。

あと、一緒にサイン会をやっていたJupyter実践入門を買ってサインをもらいました!

f:id:hirokiky:20170910200028j:plain

商品はこちら。

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

楽しかった様子

あとはPartyで色々お話できて楽しかったです。

Keithと僕。 1,2年ぶりにPyConJPに来てくれて、久々にお会いできました。

f:id:hirokiky:20170910200008j:plain

肉を食べるaodagさん

エッシャー感のあるaodagさん

PSFボードのYounggunとaodagさんと僕。

f:id:hirokiky:20170910201219j:plain

Justusと僕。楽しそう。

f:id:hirokiky:20170910200038j:plain

本当にイベントでも楽しかったです。 今回はBreakの時間が多かったのか多くの人と話せたのがとても良かったです。

まとめ

PyQ や僕の発表や本がお役に立てれば嬉しいです。 ですがとにかく、今年は本当に疲れきってしまったので少し休みをとりたいなと思います。

またどこかでお会いしましょう!

DjangoでDB非依存に権限管理できるライブラリーdjango-keeperを作りました

f:id:hirokiky:20170903164740p:plain

Djangoで権限管理ってどうやっていますか?

Django自体が持つGroupやPermissionはイマイチ業務では使えないというのが実際のところなのではと思います。

そんな悩みを解決するために django-keeper というライブラリーを作りました。

こんな悩みに:

  • DBで権限を管理したくない
  • 権限を見通しの良いリストやマッピングで定義したい
  • ModelやUserに依存しない グローバルで汎用的な権限も扱いたい
  • ViewやTemplateでも使いたい

django-keeperって?

以下のようにACL(AccessControlList)というメソッドによって「権限」を決定します。

from django.conf import settings
from keeper.security import Allow
from keeper.operators import Everyone, Authenticated, IsUser


class Issue(models.Model):
    author = models.ForeignKey(settings.AUTH_USER_MODEL)
    ...

    def __acl__(self):
        return [
            (Allow, Everyone, 'view'),
            (Allow, Authenticated, 'add_comment'),
            (Allow, IsUser(self.author), 'edit'),
        ]

これで、以下のような権限を決定します。

  • すべてのリクエストには "view" 権限
  • 認証ユーザーには "add_comment" 権限
  • この Issueauthor で認証している場合は "edit" 権限

というように __acl__ メソッドによって、リクエストがこのモデルに持つ権限を決められます。

Viewで使おう

以下のようにViewで使います。

  • @keeper デコレーターを適用
  • 第一引数: 必要な権限
  • model=引数: Viewの対象のモデル
  • mapper=引数: モデルを取得する上限を返す関数
    • 引数: View関数と同じ引数
    • 戻り値: objects.get(id=issue_id) のようにキーワード引数として渡す辞書
from keeper.views import keeper


# Model Permissions
@keeper(
    'view',
    model=Issue,
    mapper=lambda request, issue_id: {'id': issue_id},
)
def issue_detail(request, issue_id):
    request.k_context  # 取得したModelが取れます。
    ...

これで @keeper が自動で Issueインスタンスを取得して、リクエストが "view" 権限を持つかをチェックします。 権限が無い場合は403となります(@keeperon_fail= 引数で権限が無い場合の挙動も変更できます)。

また、 request.k_context@keeper が取得したオブジェクトが取れます。

Operator

ACLに設定した Authenticated などはOperatorというもので、リクエストがこの条件を満たすときに権限を追加したりできます。

例えば、リクエストが認証済みの場合 "view" を付与。

    (Allow, Authenticated, "view"),

このOperatorというものは keeper.operators 内にいくつかあります。

自作のOperator

自作する場合も簡単で、Operatorは単に Callable[[HttpRequest], bool] なのですぐ作れます。

例えばIPアドレスからのアクセスかどうかを判定するOperatorはこうなります。

class IsIP:
    def __init__(self, ip):
        self.ip = ip
        
    def __call__(self, request):
        return request.META.get('REMOTE_ADDR') == self.ip

この自作OperatorもACL内で使えます。 自社のIPアドレスからアクセスした場合に強い権限を与えるようにしておくなどできそうです。

MY_IP = "..."

class Issue(models.Model):
    def __acl__(self):
        return [
            (Allow, Everyone, 'view'),
            (Allow, IsIP(MY_IP), 'edit'),
        ]

このように django-keeper はUserに依存しない条件(今回はIPアドレス)なども使って権限の管理ができます。 また、Operatorという形で「リクエストが何者かを判別する処理」と「権限」を分離できるので変更に強いですし、見通しも良いです。

他にも

django-keeper は他にも

  • モデルに依存しないグローバルな権限を扱えます
  • テンプレート内でも has_permission という条件を使えます
  • 権限のないリクエストの場合の処理を変更できます
  • 権限のDenyも設定できます

詳しくは以下から見てみてください。

PyConJP2017で発表します

来る PyConJP 2017 でも django-keeper を交えた発表をします。

発表の内容:

  • Djangoでの権限管理をする定石
  • 検討したライブラリー
  • django-keeperの紹介

をします。 以下の日程ですのでぜひ来てください。

要注意

django-keeper はまだベータというレベルのライブラリーです。

本番環境にガッツリ導入するというのは避けたほうがいいです

導入する場合は、権限チェック周りのテストをちゃんと書くことをオススメします。 ちょっと使ってみて、不備があったり足りない機能があれば教えてください。 まだ自分としても「実験段階」、「こんなものがあったらいいなぁ」という段階なので、何かあれば教えてください PyConJPのパーティーなどで権限周りの定石や悩みを共有できたら良いなぁとも思っています。

おわりに

まだまだ作っている段階のライブラリーですが、僕自身が仕事をしていて欲しかったものを考えて作っています。 他にも良い方法や機能の提案、バグ報告や他オススメのライブラリーがあればぜひ教えてください。

できれば、ぜひPyConJP 2017でお会いしましょう。

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 を作ったり、 PythonDjangoでお仕事してきたりと自分と製品づくりには結構自身がありました。

でも

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

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

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

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

で、僕は全くその辺を知らなかったんですが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).