「プログラマのためのGoogle Cloud Platform入門」は、シンプルで緻密な入門書

「プログラマのためのGoogle Cloud Platform入門」を頂いたので、早速拝読させていただきました。

Google Cloud Platformといえば、全世界に広がったGoogleのデータセンター、ネットワーク、そしてソフトウェア技術をフル活用した、クラウドプラットフォームです。

プラットフォームのスケーラビリティは、技術者がロマンを感じるポイントの一つです。

その技術者のロマンを感じながら、書籍を読み進めました。

この書籍をおすすめしたい人

この書籍をおすすめしたい人は多岐にわたります。

• GCPを速習したい方(学びたいが、時間がない人）
• AWSなど他のクラウドプラットフォームをメインに使っていて、GCPについてはあまり知らない人
• インフラ構築の経験が少ないプログラマー
• クラウド上で、コンテナ環境、マイクロサービスを構築したい人
• GoogleのAI/機械学習のAPIを使ってみたい人
• TensorFlowをスケーラブルな環境で実行したい人
• システム開発のプロジェクトマネージャー・リーダー

書籍の特徴

以下に、私が感じた書籍の特徴を挙げていきます。

クラウド・コンテナ・マイクロサービス・機械学習など、技術トレンドが満載

書籍全体は、以下のような構成になっています。

※目次とは別にまとめなおしています

• 1章 GCPの概要

  • 全体像、GCPのコンセプトの説明
  • アカウント、プロジェクトの作成方法
  • 運用、管理ツールの説明、使用方法

• 2章 GCE（Google Compute Engine）上のWebアプリケーション開発

  • サンプルアプリ：掲示板
  • GCEインスタンス作成
  • Cloud SQL（RDB:MySQL)
  • Cloud Storage（画像データの保存）

• 3章 GCPのインフラ構築

  • Cloud Load Balancingによるロードバランサーの設定
  • Cloud DNSによる独自ドメインの設定

• 4章 GKE(Google Container Engine)によるコンテナ、マイクロサービス

  • サンプルアプリ：オンラインゲームの五目並べ
  • Dockerのマルチコンテナ環境構築
  • マイクロサービスのデプロイ
  • サービス無停止のバージョンアップ（ランダム対戦→AI対戦）

• 5章 機械学習を用いたGAE(Google App Engine)アプリケーション

  • Googleの機械学習と関連サービス説明、APIの呼び出し方法

    • Cloud Vision API：画像認識系API
    • Cloud Translation API：翻訳系API
    • Cloud Speech API：音声ファイルのテキスト化
    • Cloud Natural API：自然言語処理

    • Cloud Machine Learning Engine

      • TensorFlow実行環境
      • 学習済みモデルのAPI化

  • Google App Engine(GAE)説明

    • 概要／機能
    • Cloud DataStore

  • GAEアプリケーションのサンプル

    • 写真アルバムサービス
    • 画像ファイル保存：Cloud Storage
    • 画像タグ付け：Cloud Vision API
    • テキスト翻訳：Cloud Translation API
    • 属性データ保存：Cloud DataStore

  • Cloud Machine Learning Engine による機械学習モデルトレーニング

    • TensorFlowで書いた独自モデル実行
    • MNISTデータセットの手書き数字認識

本書は、クラウドのサーバー環境にとどまらず、マイクロサービス、コンテナ環境、機械学習など、現代のIT技術者なら興味を示す内容が目白押しです。

Googleが次々とリリースしているAI/機械学習系のAPIを紹介するだけでなく、サンプルアプリケーションでしっかり使っているので、読者は活用イメージが湧くことでしょう。

シンプルで分かりやすいサンプルアプリケーション

サンプルアプリケーションがシンプルで、機能やアーキテクチャーをステップバイステップで拡張しているので、つまづかずに理解を進めることができます。

例えば、２章、３章のサンプルは以下のようにすこしずつ拡張させています。

• ステップ１：Webアプリ+SQLite
• ステップ２：Webアプリ+Cloud SQL
• ステップ３：Webアプリ+Cloud SQL＋Cloud Storage
• ステップ４：Webアプリ+Cloud SQL＋Cloud Storage＋Cloud Load Balancing

４章のDocker上で動かすサンプルアプリケーション（五目並べ）も、GitHubで提供されているのでダウンロードし、コンテナ環境のマイクロサービス実行、DevOpsにとって重要なサービス無停止でのアプリケーションバージョンアップ／デプロイをすぐに体験することができます。

基礎技術の丁寧な説明

書籍のサンプル通りに手を動かしてみたものの、裏で何がどのように動作しているのか分からないということになりがちです。

この書籍では、Webアプリケーションやインフラについての基礎技術を、紙面を割き、丁寧に説明しています。これは他の書籍にあまりない特徴です。

以下が説明されている基礎技術です。

• WEBアプリケーションの基礎

• Webアプリケーションとネイティブアプリケーションの違い

• リクエストとレスポンス

• HTTP通信

• データベースの基礎

  • データベースの種類
  • データベース操作言語
  • トランザクション

• サーバー仮想化技術

  • ホスト型仮想化
  • パイパーバイザー型仮想化
  • コンテナ型仮想化

• インフラ環境構築

  • 物理ネットワークと仮想ネットワーク
  • IPアドレス
  • ネットワークの階層と通信プロトコル
  • ファイアウォールとルーター
  • DNSの基礎
  • 負荷分散の基礎
  • 仮想ネットワークの基礎

クラウドプラットフォーム技術の進展により、サーバー、ネットワーク周りのインフラ系技術者の仕事と、プログラマーの仕事の垣根が低くなり、インフラ環境をプログラマーが担当する場面がここ数年で増えました。

インフラ環境を構築した経験がないプログラマーの方は、この基礎技術の説明を読みながら、本書のサンプルを動かしてみることで、インフラ環境への理解を深めてみると良いでしょう。

図・イラスト、表が豊富に使われ、アーキテクチャーを理解しやすい

わかりやすい図やイラストが要所要所で使われているので、直感的に理解することが出来て、理解の迷子にならないように手助けしてくれています。

クラウド技術は、複数の技術要素が連携して動作するので、アーキテクチャーを頭に入れながら理解する必要があります。そのアーキテクチャーをわかりやすい図で表現してくれていて、とても助かりました。

実績ある著者が執筆

書籍は、内容もさることながら、誰が書いたかということが重要です。

技術の入門書は数多く世の中にありますが、著者のバックグランドでその書籍の深み、価値は変わってきます。

著者の阿佐志保さんは、わかりやすいと定評のプログラマのためのDockerの教科書、Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門を執筆されています。

技術書籍執筆者の登竜門といわれているWINGSプロジェクトで鍛えられ、磨かれたのでしょう*1、特に第４章「コンテナ実行環境で、マイクロサービスを体験しよう」は、よくまとまっていて、この章だけでも、この書籍を買う価値はあると思える内容でした。

また共著者・監修の中井悦司さんは、Google のCloud Solutions Architectをされていて、弊社の社内読書会でも使わせていただいた、ITエンジニアのための機械学習理論入門や、TensorFlowで学ぶディープラーニング入門などを執筆されていて、クラウド技術、機械学習については、第一人者といえるでしょう。

この２人の共著であれば、この書籍のレベルの高さは納得がいきます。

まとめ

GCPの全体像の把握や、GCP習得が短時間で済むように、書籍全体の構成やサンプルアプリケーションの構成・内容がシンプルで緻密に良く練られている印象を受けました。

著者が、構成や内容を練るのに時間を使ってくれている分、読者はGCPを学ぶ時間を節約できることでしょう。

時間は一番貴重な資源なので、とても有り難いことです。

また、スケーラブルなWebサービス環境、コンテナ環境を使ったマイクロサービス、GAE、AI/機械学習というように、Google のクラウド技術全体を網羅しているので、GCPを活用する際のインデックスとしても使える書籍であると感じました。

この書籍で、GCPについてのインデックスを頭の中に構築し、あとは実践やWeb上のドキュメントを読むことによって知識を肉付けしていけばよいでしょう。

書籍内の説明を読みながらサンプルを試していけば、4時間〜8時間で、GCP上のWebアプリケーション実行、インフラの設定から、マイクロサービス、GAE、GoogleのAI/機械学習のAPIを体験できるのではないでしょうか。

仕事の業務時間で言えば半日〜１日なので、新人研修等の教科書・参考書としても使えそうです。

GCPをこれから学ぼうという方におすすめの一冊です。

プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで

*1:私も2004年からWINGSプロジェクトに参画し、2010年頃まで技術記事を書かせていただき、主催の山田祥寛さん、山田奈美さんには執筆記事を何度もレビューしていただきました（2007年にWINGSプロジェクトについて書いたブログ記事）。ここ６、７年は忘年会にしか参加していませんが。。

匠道場2017年6月開催まとめ

6月22日(木)に、匠道場*1 に参加してきました。

有益な話も出ましたので、後で振り返れるよう、まとめておきます。

• 時間順ではなく、内容別にまとめています。
• 赤字は新たに得た知見です

匠メソッドは、connpass、PyQの企画や、お客様の開発の最初のフェーズなど、さまざまな場面で実践活用させてもらっています。

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

全体構成

• 前半

  • 「匠メソッドを仕事で有効に活用するために、匠メソッドを極める」 匠メソッド開発者の萩本順三さん（道場師範）

※近いテーマで開催された匠塾の以下の講演資料が7/16に公開されました。

2017 07-12 要求を見える化しよう！（関西匠塾にて） from Hagimoto Junzo

• 後半

  • 萩本師範、師範代（ISR山崎さん、匠BP篠原さん、NTTコムウェア濱井さん、ビープラウド佐藤）を交えての質問・回答

匠メソッド概要

• 匠メソッドは６種類の主要なモデルで構成されている

  • 価値分析デザインモデル
  • 価値デザインモデル
  • 要求分析ツリー
  • ビジネスコンテストフロー（AsIs)
  • ビジネスコンテストフロー（ToBe）
  • ゴール記述モデル

• 価値分析モデル、価値デザインモデル、要求分析ツリーがシームレスで、行き来できるのが大きな特徴

• 価値→戦略→活動と落とし込むという考え方が、他にはない特徴的な考え方

  • 人はやりたいこと、やるべきことから考える。匠メソッドは価値から考える
  • やりたいことを踏まえた上で価値から考える
  • なぜ価値から考えるようにしたか？ → 頭を慣習から解き放つため

• 論理思考（要求分析ツリー）で考えたものを感性（価値デザインモデル、価値分析モデル）で叩け

  • 最終的には、頭のなかで論理と感性を行ったり来たりできるようになる
  • 感性で叩くためには「嬉しい」という感情に立ち返る。ステークホルダーに共感する。その人にとって嬉しいかどうか想像力が問われる

• メモ：「感性で叩く」には、実行しようとしていることが、自分達がワクワクすることか？という問いかけも必要。

価値分析モデル

• ステークホルダーを巻き込むストーリーを記述する
• 価値→目的、目的→価値 と洗練させる

• シチェーション＋手段＋嬉しい言葉で、価値を記述する

• Q.なぜ、価値の記述をストーリー的に表現するのか？

  → A. 人が価値をイメージしやすいのはストーリーだから

• Q.なぜ価値記述の中に手段を入れるのか？

  → A. 企画内容の検証のため

• Q.価値記述に具体的な手段を入れるのは、手段志向にいきなり走ってしまうことになるのでは

  → A.手段のアイデアは、仮置きしておけばよい。分かっているものは先に出せ（出ないより良い）

  • 価値記述は手段を書き、手段を抽象化して目的にする
  • 逆に抽象的過ぎる業務要求は、要素分解して複数の業務要求を抽出する
  • 業務要求の変更にしたがい、価値記述も変更する

• 目的と手段を行ったり来たりして、洗練させる（※萩本さんの資料が図になっていてわかりやすい）

  • 価値の具体的イメージ化のためのHowの手探り（価値、目的、手段）
  • そもそも何が目的か？という本質面での抽象化（手段→目的）
  • 本質から見た際の具体的手段の再検討と手段要素の分解（価値、目的→手段）

価値デザインモデル

• ビジョン=実現すべき未来の姿
• コンセプト=ビジョンに近づくために重要とする３つの構想（大目標）
• 内向けの価値デザインモデル（業務改善、プロダクト開発など）、外向けの価値デザインモデル（営業・販売）
• 内向けの価値デザインモデル：コンセプトの２つは組織の外向け、１つは組織の内向け

• コンセプトの3つのうち２つを組織の外向けにするのは、社員に外を意識させるため

• 意味

  • 「説明」と言い換えても良い
  • プロダクトや、プロジェクト全体を説明する
  • 各コンセプトの説明のために使っても良い。例えば、「はやい」「やすい」「うまい」というコンセプトの場合、「はやいとは〜」「やすいとは〜」「うまいとは〜」というように説明文を書く

• コンセプトの性質：戦略ベースのコンセプト、コンセプトベースのコンセプト

  • ※このあたり、私はまだ理解ができていません

  • 「第７章 匠Methodで商店街の風呂屋を復活させる」「要求分析ツリーのたたき台をつくる」(kindle:1461/2274)に説明がある（以下の戦略ベースとコンセプトベースの説明は匠メソッドの書籍からの引用）

  • 戦略ベース

    • プロジェクトで最も重要なことを３つ挙げようといったトップダウン的発想。
    • 業務改革や作業改善などプロジェクトのコンセプトを考える時に活用されるアプローチ

  • コンセプトベース

    • プロジェクトにとって非常に重要なアイデアにスポットを当てて、ボトムアップ的にコンセプトを導き出す。
    • 製品企画や特徴のあるサービス（ビジネスモデル）の企画のコンセプトを考えるときに活用されるアプローチ
    • 導き出されたコンセプトは、戦略要求の一部分、あるいは下位の業務要求といったように局所的に位置づけられる

• ストーリー

  • ビジョンを実現していくストーリーを書く

  • Q.先にロードマップを決めてしまうことになってしまわないか。戦略が決まってからストーリーを決める方が良いのでは

    → A.それでも良い。仮にでも置いておいて、あとで戻ってくる。行ったり来たりすることによって洗練させる

  • ストーリーは柔軟に使える。価値が実現するシーンをストーリーとして書いても良い

要求分析ツリー

• 思考のレイヤリング

  • 思考のレイヤリングができると、企画力が高まり、議論がスピーディーになる

• 「結果」を達成するための「施策」を戦略要求の目的レベルに書く（結果を書くのではない）

  • 「売上向上」は結果なのでNG
  • 「若手層の売上向上」はOK(かもしれない。プロジェクトによる）

• 手段から目的を抽出する、業務要求の抽出ステップ（※萩本さんの資料が図になっていてわかりやすい）

  • 1.具体的な手段を考える
  • 2.手段を目的として抽象化
  • 3.目的と手段がつながらないとき、手段を抽象化して業務要求をつくりだす
  • 4.新たな手段が生まれる

• 例：会員にメールを送りたい（具体的な手段）→会員とのコミュニケーション活性化（目的）→会員に連絡したい（手段の抽象化）→会員にアプリでPUSH通知（新たな手段）

プロジェクトライフサイクル

• プロジェクトが進むごとに、価値が変化し、コンセプトが進化する（ビジョンは変わらない）
• プロジェクトでは、ゴール/リソース/スコープ のバランスを重視

最後に〜匠メソッドを学ぶことによって得たスキル

ビジネスや仕事で、時間は最も貴重な資源です。

ミーティングが長い、話が長い、話がまとまらない会社やチームは、アクションする時間が徐々に削られて、成果を出しにくくなります。

私は匠メソッドを学び始めてから、仕事の話をまとめるのが早くなったと感じています。

仕事上の会話で「思考のレイヤリング」を常に意識しながら話をしているためです。

思考のレイヤリングによって、価値の話をしているのか、ビジョンの話をしているのか、目的の話をしているのか、業務の話をしているのか、手段の話をしているのか、計画の話をしているのかを、瞬時に整理ができるようになったのです。

それにより、話が逸れた場合は戻すことができたり、各レイヤーで検討が不足していることがあれば、そこを集中的に話すということによって、ビジネスの話を全体を漏れなく、スピーディーにまとめられるようになりました。

「思考のレイヤリング」は匠メソッドを学んだことによって得たスキルの一例にすぎません。匠メソッドを学ぶことによって、他にもさまざまなスキルや視点を身につけることができます（いずれまとめたいと思います）。

仕事のスキルをさらに伸ばしたい方は、匠メソッドを学ぶと良いでしょう。

匠の夏祭り

匠の夏祭りという匠メソッドをテーマにしたイベントが開催されます。

匠メソッドを活用し、成果を出している方々の発表がメインテーマです。（※私は2015年、2016年と登壇させていただきましたが、今年は参加のみでお休みです）

弊社の西川もパネルディスカッションに登壇させていただきます。

匠メソッドに興味がある方は、参加されてみてはいかがでしょうか。

connpass.com

*1:匠メソッドを学ぶための集まりで、現在では匠メソッドのライセンスを購入している企業の人のみ参加できます（以前は紹介があれば参加できましたが、参加者が増えたためにそのようになりました）。

Developers Summit 2017 Winter に登壇しました。

3か月前になりますが、Developers Summit 2017（2017年2月16日、17日開催） に、connpass運営として登壇したので、資料をブログにもアップしておきます。

connpassの戦略決定〜チームで取り組んだ価値のデザイン from Haruo Sato

デブサミでの登壇は、1年ぶりでした。（2016年のブログ）

昨年(2016年2月18日)のスライド

エンジニアコミュニティで組織は動き出す from Haruo Sato

概要

セッションは、DoorkeeperのPaul McMahonさん、ATNDの仲井さん、dots(現TECH PLAY)の小沢さん、と４人のリレーセッションでした。

event.shoeisha.jp

また、このセッションを企画したdotstudioの菅原のびすけさんも冒頭で挨拶してくれました。

企画の発端

2年前のBPStudy#94に、のびすけさんが来てくれました（初対面）。

その懇親会で、のびすけさんが「イベントサイトの運営者を集めてみんなで話すイベントをやりたい」とおっしゃってましたが、そのアイデアが、このセッションでカタチになりました。

のびすけさんとの対談

のびすけさんとは、connpass運営者と、connpassのヘビーユーザーというかたちで対談をし、codezineにも2016年12月に記事が掲載されました。

codezine.jp

話す内容の決定

1月12日の夜に翔泳社にてミーティング（翔泳社鍋島さん、ATND仲井さん、Doorkeeper Paulさん、わたしが現地参加。のびすけさんはリモートから参加）。

アイデア出しから始まりました。

その結果、以下のようにして話す内容を決めることになりました。

1. 翔泳社の鍋島さん、のびすけさんから登壇者に質問
2. 登壇者が回答
3. 鍋島さん、のびすけさんが回答内容から、話してほしい内容を登壇者に伝える

その結果、以下のようなお題をいただきました。

「誰に向けてどんな価値を届けるか？Webサービスにおける匠メソッドの実践」 →誰をユーザーとし、誰がユーザーでないと決めた時の話と絡めて匠メソッドのWebサービスにおける実践事例の話を聞きたい

当日

セッションは13:05〜でしたが、10:00には現地に入り、控室で資料の最終チェック。

昼には豪華なお弁当をいただき準備万端。30分ほど前に案内され、セッション会場に向かいました。

セッション会場裏で、４人の登壇者で話す順番を決め、私は２番目に。

DoorkeeperのPaulさんが話した後、わたしの番になりました。

10分弱の持ち時間でしたが、昨年話していたこともあり、落ち着いて話すことができました。

匠メソッドの知名度アップにも、一役買えたかなとおもいます。

ただ、残り1分を会場の方に教えていただいたときに、自分はまだ２分あると思って話していたので、焦りましたが。

話す時間は、数分の余裕を持っておいた方がよいということでしょう。

そして、デブサミイベントのもうひとつの目的。

BPStudyの登壇者発掘です。

控室で、ヴァル研究所 新井剛さんのナンパに成功し、5月のBPStudy#117 で登壇していただきました。

また、デブサミ関係者の打ち上げでは、リクルートジョブズ西村直人さんとお話しし（西村さんは以前に面識があったのでナンパではない）、6月のBPStudy#118 でお話頂く予定となっています。

感想

朝10時に会場に着きましたが、その時点で、ものすごい数の参加者（登録3500人だとか)で、昨年よりもさらに勢いを感じました。

また、会場が目黒雅叙園ということもあり豪華で厳かで、またスタッフの方々にはとても丁寧に対応して頂き、VIPな気持ちになれました（笑）。

そして、Develpers Summit 2017 Summer(2017年7月28日開催) にも登壇させていただけることになりました。

event.shoeisha.jp

「コミュニティを長く続ける秘訣」というテーマで、のびすけさん、Co-Edoの田中さん、そして私のリレーセッションです。

http://event.shoeisha.jp/devsumi/20170728/session/1427/event.shoeisha.jp

発表には全力を尽くしたいとおもいます。

すごいコミュニティとは

5か月ほど経ってしまいましたが、コミュニティマネージャーサミット2017（1月23日開催）で、connpass 運営の立場から、ライトニングトーク(LT)をさせていただいたので、ブログにあげておきます。

connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017 from Haruo Sato

市川さんからの登壇依頼

Social Companyの市川さんから2016年の12月下旬に、1月のコミュニティマネージャーサミット2017で、「Connpassの利用状況・データから読み解くXXX」のような話をしませんかと、Facebookメッセージでお話をいただきました。

私は、依頼されたらあまり断らない主義（あまりにムリなのは考えますが）なので「担当させていただきます」と即答しました。

とはいえ、何を話したら良いのか。。

すごいコミュニティとは

２週間ほど考え「connpass上のすごいコミュニティ」をデータをもとに紹介することに決めました。

では「すごいコミュニティ」とは、どのようなコミュニティか。

イベントの開催回数が多いだけでは、小さな開催を繰り返しているコミュニティが上位に来てしまいます。

またイベントの参加人数は多いが、開催が少ないコミュニティを活発に活動していると考えてよいかというのもありました。

それらを考慮して、以下の条件をクリアしているものを「すごいコミュニティ」としました。

• 対象期間：2016年1月〜2017年1月末までの13か月
• 規定打席数：13か月間で、13回以上イベントを開催していること
• 打席数：イベント開催数
• 安打数：参加人数50人以上のイベントの数
• 打率：参加人数50人以上のイベントの数(安打数) ÷ イベント開催数(打席数）

「すごいコミュニティ」= 打率の高いコミュニティ(打率 .350以上) ということです。

特に私がこだわったのは、13ヶ月で13回以上開催という継続性の面(規定打席）です。

2回や3回の開催なら人気のテーマを設定し、著名な人を連れてくれば、何とか人を集められます。

データをみても、全体の４分の１のコミュニティが、1回は50人を集めた開催をしていました。

しかし、その後、同じように続けられるコミュニティは、ぐっと割合が減ってきます。

1か月ごとに開催していたのが、2か月開き、気づけば半年開いてしまい、開催の心理的ハードルがあがり、開催できなくなるということになりがちなのがコミュニティの運営といえるでしょう。

このように、コミュニティ・マネージャーは続ける力が求められるので、その方々の運営コストが少しでも減り、助けになる機能をconnpassに追加していきたいです。

データの分析

データを分析するのに、開発チームに、re:dash を、connpassのDBにつないでもらいました。

そして、SQLを打ちデータを抽出→本番のデータをブラウザでみて正しいか検証いうことを何度も繰り返しました。

直前の土日は、このデータ抽出・検証と、資料作りにかかりきりでしたが、集中し、楽しい作業でした。

この分析データをプロットしたのが、以下の図です。

BPStudyは打率.307

ちなみに、私が主催しているBPStudyは、打席数13、安打数4 で、打率.307 で惜しくも入賞ならず（赤い四角の枠の左下あたりに位置しています）。

BPStudyが、打率の高いコミュニティに仲間入りできるように精進したいと思います。

6月のBPStudyはこちらです → BPStudy#118〜開発チームはどのように変化するべきか

お声がけいただいた、Social Company 市川さんによる開催報告は以下です。

コミュニティマネージャーサミット2017開催レポート

本好きな会社〜読書会による組織学習

ビープラウドでは、BPRA（BeProud Read for Action）という名の、社内読書会を開催しています。

今日は、読書会を始めた背景・経緯・狙いなどについて書きたいと思います。

今まで開催したテーマ

社内読書会は2016年12月から始めましたが、テーマにした書籍は以下のとおりです。

本物のデータ分析力が身に付く本(日経BPムック)

ITエンジニアのための機械学習理論入門

情報推薦システム入門 -理論と実践-

深層学習 Deep Learning

Python機械学習プログラミング 達人データサイエンティストによる理論と実践 impress top gearシリーズ

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

ビジネスモデル・ジェネレーション ビジネスモデル設計書

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

最強のコピーライティングバイブル――伝説の名著3部作が1冊に凝縮! 国内成功100事例付き

マッキンゼー プライシング (The McKinsey anthology)

スマート・プライシング 利益を生み出す新価格戦略

良い値決め　悪い値決め　―きちんと儲けるためのプライシング戦略

価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?

社内読書会（BPRA）を始めるまでの経緯

BPStudyで発表

私は、2015年9月のBPStudy#97 で「世界に価値を創り出すエンジニアの技術」というテーマで、話をしました。

BPStudy#97 世界に価値を創り出すエンジニアの技術 from Haruo Sato

話の趣旨としては、以下のとおりです。

• これからの時代のエンジニアは、価値を企画するところから価値を届けるまでの一気通貫のスキル、技術、視点を持ち、仕事をする必要がある
• つまりそれは、企画、開発、マーケティング・販売の視点を持ちながら仕事をすることである

このような仕事をするには、技術だけではなく、ビジネスにまつわる知識も必要となってきます。

またこのような視点で仕事ができれば、やりがいも大きくなります。

継続的に技術・知識・スキルを習得する必要性

現代社会は、新しい技術や考え方が、次々と生まれる時代です。

そのような時代で働くひとたちは、技術、知識、スキルを１度身につけて終わりではなく、必要に応じて新しい技術、知識、スキルを学習、習得し、使いこなしていく必要があります。

まさにP.F.ドラッカーのいう「知識労働者の時代」と言えるでしょう。

組織学習の必要性

では、どのように新しい技術やスキル、知識を身につけていけばよいのでしょうか。

まず、個人のモチベーションに依存し、書籍を配ったり、勉強しておいてと伝えても、勉強する人としない人というように、ばらつきが出てしまうでしょう。またひとりで学習を続ける場合、モチベーションの維持・継続が難しいところです。

そのような理由から、組織として、チーム学習・組織学習を進める必要があります。

社外研修を数日受けるのも良いでしょうが、身につけるべきスキル・知識のための適切な研修があるとも限りません（あとお高い可能性も）。

それでは、組織・チームとして、知識習得、スキル習得をどのような方法で進めたら良いのか？

わたしは、どのように組織学習を進めていくのかという課題に対しての答えを見つけられずにいました。

Read For Actionとの出会い

BPStudy#97 の発表から1年経過した2016年10月。

たまたま手にした「あなたの会社が最速で変わる７つの戦略」を読み、ビビッと来ました。

あなたの会社が最速で変わる7つの戦略

具体的には、第４章「Read For Actionによるイノベーターの育成〜読書会を通した組織学習によってイノベーションが生まれる土壌を耕す」。

そこには、NTTアドバンステクノロジ(NTT-AT)という会社で「Read For Action」という読書会を通した組織学習をしている事例が紹介されていました。

NTT-ATの使命は、NTT研究所の研究成果を受け取って商品化すること。

それを受けて必要なマーケティングを行い、適性なビジネスモデルをつくってお客様のところに届けること。

それにも関わらず、マーケティングが出来ていない状況だったそうです。

それは、技術者の割合が大きい会社で、皆がビジネスモデルやマーケティングの知識を持っていないことが背景にありました。

その状況を変えるため、三宅泰世さん（現NTT-AT Chief Marketing Officer）が、「Read For Action」という読書会の手法を使い、ビジネスモデル、マーケティング、プレゼンテーションのスキルを皆で、短時間で習得し組織に展開したとのことです。

「これはビープラウドにも使える手法だ」

そう直感し、三宅さんにお会いしたいと思い、ネットを検索しました。

すると偶然にも1か月後の2016年11月3日に、三宅さん主催の読書会（対象書籍「あなたの会社が最速で変わる７つの戦略」）が開催されることが分かりました。私は迷わず参加申込みをしました。

読書会当日

読書会は、ワークショップ形式で、複数のテーブルに分かれて始まりました。

読書会は、以下のように進みました。

• 自分のビジネスをビジネスモデルキャンバス(BMC)に記述する
• 「あなたの会社が最速で変わる７つの戦略」に載っている7つのビジネスモデルを加えることにより、BMCを掘り下げる
• 自分のビジネスモデルのイノベーションの可能性を検討する

私はPyQ をテーマに取り組みましたが、皆とわいわいと話しながら、そして頭をフル回転させながら、時間密度の濃い読書会が進行する素晴しさを体感できました。

私は、Read For Actionの読書会の進め方をさらに知るべく、リーディングファシリテーター認定の講座を受講することにしました。

リーディング・ファシリテーター養成講座を受講

三宅さんの読書会の17日後、11/20(日)（10:00〜18:00）のリーディングファシリテーター養成講座に、私は参加を申し込みました。

Read For Actionのファシリテーションの方法は、人間心理や脳科学に基づいた設計がされていて、丸１日の講座でしたが、飽きることなくあっという間に終わりました。

講座には、他にも全国や海外（韓国）から10人くらいの人が参加していて、読書会を体験しつつ、読書会のファシリテートの方法や考え方を楽しみながら学ぶことができました。

異業種共創ワークショップに参加

私は、リーディングファシリテーター養成講座に行くだけでは飽き足らず、翌年(2017年)に開催が予定されていた、三宅泰世さん、山本伸さん、大久保祐子さんが主催する「異業種共創ワークショップ」にも参加を申し込みました。

このワークショップは全６回で、以下のように書籍を中心として構成されていました。（時間はいずれも、14:00～17:00）

1月6日(金) START INNOVATION！

START INNOVATION ! with this visual toolkit.〔スタート・イノベーション! 〕―ビジネスイノベーションをはじめるための 実践ビジュアルガイド&思考ツールキット

1月20日(金) ビジネスモデルＹＯＵ

ビジネスモデルYOU

2月3日(金) ストーリー思考

ストーリー思考---「フューチャーマッピング」で隠れた才能が目覚める

2月17日(金)　ビジネスモデルジェネレーション、バリュープロポジションデザイン

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

ビジネスモデル・ジェネレーション ビジネスモデル設計書

3月10日(金) 稼ぐ言葉の法則、最強のコピーライティングバイブル

稼ぐ言葉の法則――「新・PASONAの法則」と売れる公式41

最強のコピーライティングバイブル――伝説の名著3部作が1冊に凝縮! 国内成功100事例付き

3月17日(金) ザ・プレゼンテーション、スライドロジー

ザ・プレゼンテーション

slide:ology[スライドロジ―]―プレゼンテーション、ビジュアルの革新

ワークショップ６回の全体の流れは以下のとおりです。

①イノベーションを開始する（START INNOVATION！）

↓

②自分の強みを見つけ出し、取り組むべきビジネスを見つける（ビジネスモデルＹＯＵ、ストーリー思考）

↓

③ビジネスモデルを確立する（ビジネスモデルジェネレーション、バリュープロポジションデザイン）

↓

④マーケティング（稼ぐ言葉の法則、最強のコピーライティングバイブル）

↓

⑤販売（ザ・プレゼンテーション、スライドロジー）

このワークショップには、以下の目的で参加しました。

• PyQの販売開始を控えていた時期で、PyQのプロモーションのための知識を得る
• Read For Actionによる読書会を体感し、読書会の社内展開に活かす

全６回に参加し、新たな自分も発見することができ、スピーディーな読書会ファシリテーションを体感できました。

PyQチームへの展開

2017年4月に、PyQを販売開始するにあたり、価格を決めたり、ランディングページや広告のキャッチコピーを決める必要がありました。

それらを決めるために、チームで読書会を開催しました。内容は以下のスライドで。

BPStudy#116(PyQ開発秘話) from Haruo Sato

コミュニケーションの場としての読書会

私が経営者として考えていることや、仕事に対する考えなどを、ビープラウドの人たちに直接話すことができる機会は限られています。

読書会には、書籍をきっかけとして、自分の考えを押し付けがましくなく、フラットに話すことが出来るというメリットあります。

また、逆にメンバーの考え方を聞いたり、教えてもらったりなどする場合もあります。

そのように読書会は、各人の知識と知識が結びつき、新たな知識やアイデアが創造される場としても期待ができます。

これから

ビープラウドには、本が好きで学習意欲が高いメンバーが集っていますので、読書会の方法は馴染みやすいと思っています。

読書会により組織学習を進め、技術、スキルの習得、コミュニケーションの活発化、そしてビジネスとしての成果につなげて行きたいとおもいます。

※「Read For Action」については、以下の書籍が詳しいです。

バカになるほど、本を読め!

電話に出なくて良い会社

「会社に電話がかかって来たら、電話に出ましょう」

ほとんどの人が、言われ続けて来ていることとおもいます。

電話が仕事に及ぼすデメリット

電話が会社にかかってくると、さまざまな問題が生まれる可能性があります。

• 不在時にメモのやりとりや連絡が社内で必要になり、時間を取られる
• 集中していた作業が中断される
• 不要な飛び込み営業電話の対応（電話の取次、断りの会話）に時間を取られてしまう

また、電話を仕事で使うのが習慣になると、以下のような問題が発生します。

• 電話が最優先となり、自分の仕事が中断される
• 電話がかかってこないか、常に気にしている必要がある
• 電話に出れなかった場合に、かけなおす必要がある。出なかった場合にまたかけるなどがタイミングを合わせる同期コストが必要
• お客さんから思いつき、またはまとまってない状態で電話で要件を伝えられてしまう。メモを残して送信しておかないと、言った言わない問題になることもある

このようなデメリットを無くすために私は会社をつくったときから、携帯電話を含めて、電話を仕事で使わないように、会社の仕事をつくってきました。

そのために、以下のようなことをやって来ました。

• Slackなどのクラウドツールでなるべくお客さんとやりとりするようにする
• 話したい時は、Hangoutなどのビデオ通話ミーティングか直接のミーティングを設定する
• 電話に出れなかったらメールで「お電話いただきましたが要件は何でしょうか」と返し、メールでのやりとりに移行する
• 電話に出ない（わざとではなく、気づいてないだけですが）。この人は電話に出ない人という烙印を押してもらう

この結果、現在ではお客さんからほとんど電話はかかってこない状態になりました。

電話代行サービス、電話秘書サービスの導入

しかし、会社にはお客さんだけではなく、さまざまな電話がかかってきます。

かかってくる電話の内容を分析したところ、半分以上が会社に不必要な営業電話であることがわかりました。

そこで、去年の11月からビジネスアシストの電話代行サービス、電話秘書サービスを導入しました。

https://www.biz-assist.co.jp/

このサービスは、以下のようなことをやってくれます

• 電話をまず受けてくれる（電話番号は今までのまま）
• ホワイトリスト（取引先やパートナーなど）に基いて、電話を転送してくれる。営業電話は体良く断ってくれる
• かかってきた電話のログをメールで送ってくれる

このサービスを導入した結果、一日に会社にかかってくる電話が4〜5件中のうち、半分になりました。

その結果、以下のようなメリットを得られました。

• 電話で作業が中断される回数が減り、また営業電話の取次、取次判断や、断るための会話など、電話に取られる時間が減り、本質的な仕事に時間を使えるようになった
• ログがメールで残るので、電話メモなど社内連絡のやり取りコストが減った
• お客様が電話をかけたが、誰も出なかったということが無くなった

月額18,600円ですが、社内ではかなり好評なので費用対効果は生まれていると思います。

電話に出ないルール

また、このサービスを導入した上で、さらに以下のルールを追加しました。

「電話がなっても電話にでなくてよい（電話担当の事務の人以外）」

電話がかかってくる内容を分析したところ、以下のような状況でした。

• お客さんはほとんどかかって来ない
• 税理士、弁護士、社会保険労務士の顧問の人たち(頻度も少なく、急ぎということはない）
• 社員からの急な電話（事故にあったなど）

結論としては、緊急の電話がかかってくるのはイレギュラーケースであり、必要であれば後でかけ直せば良く、そこに電話対応コストをかけるのはもったいないということで、電話にでなくて良いということになりました。

これによって、電話担当の人がいないときに「誰が電話に出るんだ」という空気の読み合いが不要となりました。

ちなみに、電話代行サービス、電話秘書サービスの導入や、電話に出なくて良いというルールの導入は私が決めたことではなく、BPカイゼンという社内の改善活動からつくられたルールです。

ついでに、これを機会に電話の音も最小にしました。電話に気づく必要が無いので。

今後

今後ですが、顧客だけではなく、税理士、弁護士、社会保険労務士のひとたちも、可能な限りチャットの世界に巻き込み、電話を少しでも減らしていこうと思います。

わずかな改善かもしれませんが、塵も積もれば山となる改善と感じています。

これからも、会社で仕事をしている人が集中でき、成果を生み出せる環境をつくっていければと思います。

成長・進歩する人の思考

「いままでに自分を成長させるために一番役立った言葉は？」

と質問されたら「言い訳は進歩の敵」と私は答えるでしょう。

これは、私が24歳のときに読んだ野村克也氏の著書「勝者の資格」に書かれていた言葉です。

ノムダス 勝者の資格

この言葉を知って以来、私は仕事をするときに言い訳が浮かんで来たら、ぐっと飲み込むようにしていました。

では、なぜ「言い訳が進歩の敵」になるのでしょうか。

たとえば、システムで障害が発生した場合を例にします。以下の原因は全て事実だとします。

システム障害の原因

• 作業していたときに、体調が悪くて頭が回らなかった
• XXさんがXXXをやってくれなかった
• 障害があった箇所は、つくりが複雑で修正が大変

言い訳をする人

上記の事実に対して言い訳を言葉にして、青字のように考えたとします。

• 「作業していたときに、体調が悪くて頭が回らなかったんです」

  体調が悪かったせいで、自分のスキルが無い訳ではない。

• 「XXさんがXXXをやってくれなかったんです。」

  作業しなかったのは自分ではないから関係ない。自分は作業漏れするような抜けた人ではない。

• 「障害があった箇所は、つくりが複雑で修正が大変なんです」

  誰がやってもミスしがちな箇所で、自分のスキルが劣っているわけではない。

言い訳をしない人

言い訳をしない人は、以下のように考えたとします。

• 作業していたときに、体調が悪くて頭が回らなかった

  • そもそも体調が悪くなる普段の生活に問題はないだろうか？
  • →体調を良くするための対策を考えよう

• XXさんがXXXをやってくれなかった

  • 自分にもできることはなかったか？
  • →これからは全体に目を配り、関係者には早めにリマインドしよう

• 障害があった箇所は、つくりが複雑で修正が大変

  • もう少し慎重に作業を進められたのでは？
  • → 該当箇所を詳しく知っている人にレビューしてもらおう

言い訳をする人と、言い訳をしない人で生まれる違い

言い訳をする人と、言い訳をしない人の違いはなんでしょうか。

• 言い訳をする人

  • 外部の事実を把握しただけで、自分に目が向いていない

• 言い訳をしない人

  • 外部の事実を把握した上で、自分に目が向いている

そして、以下のような違いを生み出します。

• 言い訳をする人（=自分に目が向かない人)

  • →自分を振り返り、改善すべきことに思い至らない
  • →進歩しない

• 言い訳をしない人(=自分に目が向けられる人)

  • →自分を振り返り、改善すべきことに思い至る
  • →思考や行動を改善する
  • →進歩する

自分にとってネガティブなことが起きた時に、自分に目を向け、振り返ることが出来る人は、それを糧に進歩できる人といえるでしょう。

このことから、成長・進歩したかったら「言い訳をしない」ことを習慣にすると良いのではないでしょうか。

罪悪感に注意

「自分に目を向ける」ときに注意があります。

それは、罪悪感を持たないようにするということです。罪悪感を持つと進歩が止まります。

罪悪感を持たず進歩できる人と、罪悪感を持ち進歩できない人の違いはなんでしょうか。

• 罪悪感を持たず進歩できる人

  • 未来を見ている
  • 過去は反省しつつも、やってしまったことは仕方ないと良い意味での割り切りをしている
  • 今より進歩した未来を見ているので、行動の活力が湧く
  • 行動し、進歩する

• 罪悪感を持ち、進歩できない人

  • 過去を見ている
  • 過去もしくは今の自分を責めている
  • 過去を見ているので、未来への行動活力が湧きにくい
  • 行動しないので進歩しない

まとめ

進歩・成長できるひとは以下のような思考ができるひとでしょう。

• ステップ1：自分にとってネガティブなことが起こる
• ステップ2：事実を把握する
• ステップ3：過去・今の自分に目を向け、自分の改善点をみつける

• ステップ4：未来の自分に目を向け、行動する

  • 「過去は変えられない」と良い意味で割り切るマインドを持つ
  • ※ もし他の人に迷惑をかけた人としたら、間違っても「過去は変えられない」と言葉にしてはいけません

経営者・リーダーとして

会社では、さまざまなことが起こります。

• 「それは社員がやったこと」
• 「私が知らないところで、知らないうちに被害が広がっていた」
• 「なぜ、そんなことをするんだ」

と言いたくなるようなことが起こるかもしれません。

「会社で起こることはすべて自分の責任」と考え、自分を成長・進歩させていこうとおもいます。