ビープラウド社長のブログ

株式会社ビープラウドの社長が、日々の思いなどを綴っていきます。

匠の夏祭り2017 まとめ 第4部 匠Method社内活用事例

第4部は、匠Methodの社内活用事例です。

it-takumi.connpass.com

前半は匠ビジネスプレイス篠原さん、後半は匠ビジネスプレイス清水さんでした。

実践 匠Method はじめの一歩~匠BP社員による普段使い事例~

ビジネスを実践するチームの活動をデザインする

登壇者

株式会社匠BusinessPlace 篠原 幸太 氏

内容

  • 不定期に行う活動でモデルを使い分けるコツ
  • チーム(ビジネススタートアップイノベーション事業部)の活動をデザインした事例

進めかた

  • 合宿の進め方をデザインする
  • 話したいこと・全体像/関係性を描く

    • シーズ(どうなりたい)→ニーズ(どうなって欲しい)を描く
    • ニーズの例:リモートワークの在り方、案件の取り回し
  • 個人のキャリアデザインを描く(シーズ)

    • 数年後(3年後)のなりたい自分を描く
    • なりたい自分のストーリーを描く
  • 部門のデザイン(ニーズを描く)

    • ステークホルダーは、価値を感じて欲しいステークホルダー+部員全員(By Name)
    • ByNameの価値(嬉しいこと)は、本人以外が描く

半年前につくったモデルを見直す

  • 過去、現在、未来がテーマ

    • 個人の悩み、阻害要因、解決策(過去)
    • チームの課題、今、何が必要か(現在)
    • 各人が成し遂げたいこと(未来)

まとめ

  • 活動とディスカッションが重要:モデルは手助けしてくれる道具である
  • ディスカッションしたいことに着目。必要に応じてモデルを取捨選択する
  • モデルにこだわらない:活動することで価値が生まれる

    • 活動がよくなるために、モデルを使う
    • モデルを書いて満足しない!
    • モデルを書いて励まし合う(顧客のイノベーションを支援するという事業の性質上、新意識に達したいが達せないジレンマがつきものでストレスがたまるため)

感想

部門の価値分析モデルで、価値を感じて欲しいステークホルダー+部のメンバーをByNameで並べるという手法、そしてそのByNameで書いたメンバーの嬉しいことは他の人が書く、という手法が斬新でした。

普段の生活では、自分の仕事に精一杯になりがちで、他の人が考えていることを考える機会は、思ったより多くありません。お互いに嬉しいことを考えることによって、チーム力や結束力がアップするのではないでしょうか。

また、モデルを書いて成果が出たつもりになり(成功の確信へのステップとして、大事なことではあるのですが)、なかなか行動しないというのもありがちなので「モデルを書いて満足しない」という言葉も、心に強く留めておきたい言葉であると思いました。

プロモーション活動をデザインする

登壇者

株式会社匠BusinessPlace 清水 康平 氏

内容

  • 少ない時間の中で価値を出していく活動・実践のコツ

セミナーのテーマを決める:価値デザインモデル

  • 付箋を使ったディスカッション
  • メモは大切。のちのち宝になることも
  • 先行して活動できることを実施してしまう
  • 価値デザインモデルをつくるのは1.5Hくらいで終わった

ニーズを検討する:価値分析モデル

  • 価値を感じて欲しいステークホルダーをあげる
  • 不参加者(来たいけど来れない)というステークホルダーが出てきた

    • イベントをニコ生放送につながった
  • 新たな価値をうみだす重要な活動にフォーカスする

タスク管理

  • 落とし込んだタスクをBacklogでタスク管理
  • 前回のタスクに加え、今回追加される活動をタスクにする
  • ポイントで進捗を確認
  • 匠Methodのモデルを確認し、つながる価値に着目

    • 価値に応じて実施する活動を取捨選択する

感想

匠ビジネスプレイスの方たちが、匠の夏祭りのために、一生懸命に準備しているのをイベント前から感じていました。

清水さんの発表で、匠の夏祭りの企画段階を見せてもらったことにより、イベントの準備から当日までのストーリーを感じ、さらに参加意識が高まりました。

普通に業務をしていて忙しい上に、並行してイベントの準備をするという場面はよくあります。そのときに、どの活動に力を入れるのか、もしくは何を切り捨てるのかを決める指針に、匠Methodを使っている事例は参考になりました。

また「メモは大切、のちのち宝になることも」はファシリテーターとして大事な心構えだと思います。

ちょっとしたアイデアをその場でばっさりと切り捨ててしまうのか、後で使えるかもと思いアイデアをモデルに乗せておくのでは、アイデアを出したメンバーの参加意識が変わってくるからです。

篠原さんと清水さんのセッションは、その前のビジネスの成功事例のセッションから一転して匠ビジネスプレイスでの匠Methodの普段使いの事例でした。

ビジネスの企画以外にも、気軽に普段の仕事から匠Methodを使って、頭を匠脳(大関さんのセッションより)にしていくスタンスは、見習うべき姿勢だと思いました。

なぜなら、これからの時代の人がする日々の仕事は、新しい価値を創り続けることであり、匠Methodは「その仕事は価値を生み出しているのか?」と常に立ち返ることが出来る方法論だからです。

セッション5へ

全体へ

匠Methodの書籍はこちら

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

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

匠の夏祭り2017 まとめ 第3部 コラボレーション事例

第3部は、匠Methodと企業のコラボレーション事例です。

it-takumi.connpass.com

デジタル化の成功率はこうやって上げろ

登壇者

株式会社ユニリタ 戌亥 稔 氏

事業・プロセス

  • デジタル変革=最新のITを使い、企業のビジネスに直接的に利益を産む仕組みを作り出す
  • 最初から投資してもうまくいくかわからない:リーンスタートアップ

デジタル変革の3要素

  • 企業内・企業間とのインフォメーションフロー(血液)
  • インテリジェンスな素早いリアクション(神経)
  • 継続的な学習(生涯学習し続けるシステム)

ビル・ゲイツの書籍:「ビル・ゲイツ@思考スピードの経営」 より

デジタル変革の成功率をあげる方法

  • (1)データの価値を見極める

    • 自社の持つデータで何が出来るか?そのデータを加えると価値が上がるか
    • データの価値分析→価値分析モデルを使用
  • (2) 継続的デリバリー

    • データの再利用をいろんなシーンで確かめる
    • どうすれば、意思決定のスピードを上げられるか
    • 自動化を進めることができないか
    • 可視化ができているか
    • 不足しているデータはないか
    • オープンデータとマージをすれば新しい知見が得られないか
  • (3)継続的な学習

    • システムに学習させることができるデータとは?

匠Methodとユニリタのコラボ

  • 情報流通

    • 匠Methodを使って価値分析をして、ユニリタのプラットフォームで素早くシステムを構築する
  • リアクション

    • アジャイル開発とDevOpsのプラットフォームでシステムを成長させる
  • 継続的な学習

    • 学習できるデータの価値を様座な角度で分析して、加工、プラットフォーム化する

介護☓IT(介護事業者向け) を匠ビジネスプレイスと取り組んでいる

感想

情報流通、リアクション、継続的な学習を循環させて、デジタルの力を増幅させるというアプローチは、インターネット・ITを使ったサービスを企画する時の考え方のひとつとして、思考の道具箱に入れておくと良いと思いました。特にプラットフォームのようなサービスを考える時に使うと良いのではと思いました。

また、匠Methodを使って、データの価値を分析していくというのも、人の行動、そして企業の活動の中から大量のデータが発生する、IoT/ビッグデータ/AIの時代において有用なアプローチです。

「データがあるけど、何かできない?」と目的がないところから、データによって知見を得ようとするアプローチは、コストもかかり、結局なにも結果を得られないリスクが高いアプローチといわれています。

しかし、匠Methodの価値分析モデルを使って、自社で持っているデータの価値を考えてみることは、短時間でリスクなく取り組むことができます。

そして複数のステークホルダー視点でデータについて考えることで、データ活用の新たな視点が得られることが期待できるでしょう。

セッション4へ

全体へ

匠Methodの書籍はこちら

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

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

匠の夏祭り2017 まとめ 第2部 コンサルティング事例

第2部は、匠Methodのコンサルティング事例です。

it-takumi.connpass.com

前半の導入部は匠ビジネスプレイス萩本さん、中盤からは東洋ビジネスエンジニアリング入交さんのお話でした。

匠Methodによるプロダクトデザイン

登壇者

匠ビジネスプレイス 萩本順三 氏

匠Methodの特徴・効果

  • 6つのシンプルなモデル
  • モデルが心をどう刺激するかを考える
  • 動機力をUPするためのモデルである
  • 価値は感じるもの(論理的なものではない)
  • 匠Methodのビジョン:みんなの嬉しいを創り出す
  • 嬉しいを演出しないとステークホルダーがビジネスモデルに参加してくれない

    • 価値のバランスが大事
  • プロジェクトの目的は自分たちの下心

  • 価値を考えているうちに、やってるうちに目が輝いてくる。他の会社のことまで考えているので

新製品企画での活用事例

登壇者

  • 東洋ビジネスエンジニアリング 入交俊行氏

匠Method導入の経緯

  • XXX(製品名)を超える次世代mcFrame(自社のERPパッケージ)を4人で作れという経営陣からの指示
  • プロジェクトのコードネームは「Chariot」
  • 新技術検証とモック作成、競合製品調査、社内インタビューを続ける日々
  • イベントで、セカンドファクトリーのブースに行った時に萩本さんを紹介された
  • 方法論大嫌いだが、匠Methodをやってみた
  • 匠Methodの以下の点が良さそうと思った

    • 点在知識(ノウハウ)をつなげる
    • 思考のトレーサビリティが取れる
    • 短サイクルでPDCAサイクルが回せる

匠Method史上最悪の生徒

  • 立ちはだかった高い壁(その1)

    • 現意識が中心でなかなか新意識が出てこない
    • 今までできなかったことを実現したい(=ERPで実現したいこと)との思いの強さがギャップの原因

    • 萩本さんのFacebook「ビジネス慣習という呪いは、なかなか解けないと痛感したセッション」

    • まずは未来の製造業の姿を描くことに変更→良い方向に向かい始めた
  • 立ちはだかった高い壁(その2)

    • ポエマー不在、デザイナー不在(理系集団の悲哀)
    • 価値デザインモデルで要素は出るが、言葉としてまとまらず、いつまで経っても言葉が空白

    • プロジェクトのコードネーム「Chariot」にIoTが入っている→ERPから脱出し、IoTをやろうという新意識になれた

  • 立ちはだかった高い壁(その3)

    • 制御不能となった要求分析ツリーの作成作業

      • 作成過程で次々と噴出したやりたいこと
      • 出来は悪いがメンバーの思いが詰まった要求分析ツリー。いつかきっと役に立つはずと残した

経営陣への企画プレゼン

  • ビジョン:全世界のマーケットニーズに即応するための変革を支援する
  • マイクロサービス型ERP+IoT&BigData
  • 2020年に向けての目標

  • 20以上のサービスを提供する

  • 世界20か国以上で利用
  • カテゴリトップ製品(サービス)を創出

→ 一発OK!

製品リリースと成果

  • 6か月という短期間でリリース(IoTプラットフォームはSORACOMを使用)
  • IoTコンテストの審査委員一押しツールに選定→会社の株価大幅上昇
  • リリース後1年で6か国に導入
  • 明日からできる簡単IoT(2時間で導入できる)で顧客に喜ばれた
  • 社内表彰でNo.1獲得

匠Methodを導入した効果

  • モデルをもとにした明確な判断基準を持てた

    • 外部の声をシャットアウト
  • 顧客中心のアプローチができるようになった

    • 共通言語が「お客さんのために」や「顧客の価値」になった
  • 市場ニーズの変化に対応しやすくなった  

    • 要求分析ツリーの中のここをやろう、こことここがつながるというトレースができるようになった
  • 巨大な要求分析ツリーをつくったが、メンバー共通の知識ベースができた

匠Methodに望むこと

  • 匠Methodブートキャンプ

    • リーダークラスが揃うと俺のやり方を通そうとする
    • 匠Methodの型にはめてほしい
  • ポエマー養成講座、デザイナー養成講座

    • エレベータートーク:30秒でシンプルに説明し伝わるように表現する
    • 理系は30秒でとなると、内容を変えずに倍速で話そうとする(NG)
    • 的確な言葉でシンプルな言葉づくりができるように
  • 数値目標アプローチ

    • 匠MethodのValue Metrics に取り組んでいる委員会があって進めている(萩本さん)

感想

萩本さんのセッションの「匠Methodのビジョンは、みんなの嬉しいを創り出す」という言葉は、記憶に残りました。匠Methodを使ったファシリテートの場面で「みんなの嬉しいを創り出すのが匠Methodなんです。他の人にも共感して、その人の嬉しいことを考えてください」というように使えそうな言葉です。

東洋ビジネスエンジニアリング 入交さんのセッションでは、いままでの思考慣習からなかなか抜け出せない理系チームが、ふとしたきっかけから新意識になり、糸口をつかみ、突破口を開き、新規サービスを成功させるストーリーに引き込まれました。

入交さんの話からは、萩本さんを信じて、忍耐強く考える、自分たちなりにやってみるという、やり抜く力=GRIT(グリット)が伝わってきました。

プロジェクトでは、直線的に成功するということはなく、不安に包まれたり、ものごとがうまくいかない瞬間は必ず訪れます。

そのようなマイナスの局面でうまく行くと信じ、忍耐強く粘れるか、平常通りに行動できるか、それがプロジェクトが成功するか、しないかを分ける分岐点であるといえるでしょう。

匠Methodのモデルは、そのような場面で羅針盤の役割を果たし、モデルに立ち返ることで自分たちを見失うのを防いでくれるでしょう。

プロジェクトを成功させるために大事なことと、プロジェクトにおいて匠Methodのモデルが果たす役割を再認識できたセッションでした。

セッション3へ

全体へ

匠Methodの書籍はこちら

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

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

匠の夏祭り2017〜第1部 イノベーション事例

第1部は、匠Methodによるイノベーション事例です。

it-takumi.connpass.com

食を通じた新たな価値創造・地方活性化へ向けて

登壇者

  • 株式会社セカンドファクトリー 代表取締役 CEO & CVO
  • ブエナピンタ株式会社 代表取締役CEO & CVO
  • 大関 興治(KOJI OZEKI)氏

テーマ

  • IoTプラットフォームによる、生産サイドと消費サイドをつないだビジネスイノベーションの成功事例
  • QOOPa Premium Market、THE NARUTO BASE、地産地食レストラン「FARM to TABLE」

ビジネスモデル

  • 生産サイド(農業、畜産業、水産業、加工業者)には、加工・商品開発の提案・コンサルティング
  • 消費サイド(飲食店、フードコード、ホテル&リゾート、加工業者)商品開発の提案・コンサルティング
  • 幅広い共創プラットフォーム:Stock(デポ)、Kitchen(加工)、Store(販売)、小ロット契約農地

会社、サービス立ち上げ

  • もともと情熱ブルドーザーと言われるほど感性で走る会社だった。それに論理的に可視化される匠Methodを導入
  • セカンドファクトリーというIT企業で地方に行っても「IT企業が何しに来た」と思われるだけなので、新たにブエナピンタという会社をつくった
  • ブエナピンタの立ち上げ企画も匠Methodで。クイックに立ち上がった
  • SI風に進めていたら、やってたら2年位かかるところを、匠Methodを活用し、半年でカットオーバー

匠Method導入以前で起きた問題

  • QOOPa(クーパ)を開発・リリース
  • 飲食業の人にヒアリング→要件定義→開発→賞も取れた→顧客も増えた→行けるのではと思った
  • イノベーションを起こしたはずなのに、収益化できない!
  • 同じジャンルに多くの製品がある→営業力で勝つしかなくなる→別の差別化が必要

  • IT視点でイノベーションを起こそうとしたが結果に結びつかない。

レストランオーナー・そして徳島へ

  • 海の家やレストランオーナーをやってわかったこと

    • 従事者の減少
    • 食材の入手の難しさ
    • オペレーションコストの増加
  • ITだけでは片付けられない課題が結構ある→徳島へ

  • 徳島に行ってわかったこと

    • 生産物が余ってる
  • ICT/IoTを活かせば、解決を同時進行できるのでは

    • ものが売れない
    • 規格外品をどうしたらいいかわからない
    • せっかく作ったものを廃棄しなければならない
    • なにを作ったら売れるのかがわからない
    • 加齢で体がしんどい
    • 後継者がいない
  • 農家の立場・レストランの立場になってCX(カスタマーエクスペリエンス)駆動で考えてみる→匠Methodで企画

FARM TO TABLEで解決すること

  • 産地直送ビジネスモデルだけでは難しい課題を解決する
  • 中小外食からみた場合:シェアードのセントラルキッチン
  • 中小生産者から見たトライアル六次産業化施設

生産地と消費を結びつけるモデル

  • (1)首都圏+食材産地直送モデル

    • 賃金が高くなる
    • 大きな物流拠点が必要になる
  • (2)首都圏+食材産地即加工モデル

    • 調理スキル依存型経営から脱却できる可能性
    • 食材費を下げて、賃金を上げることが出来る
    • 産地の加工は以下の4つで請ける

      • 素材加工
      • 複数素材加工
      • 指定調味加工
      • 完全加工
  • (3)食材産地即加工++ モデル(鳴門方式)

    • 農家の収益拡大(おいしいのに捨てているものを使う)
    • スープストックのような経営スタイル(調理師が店にいない)を中小外食で採用可能
    • ITと加工技術の組み合わせで極小キッチンで高品質なメニュー展開も可能に
    • 都心で、シェフがいらない。冷凍の技術の発展のため
  • 生産技術/ ICT・IOT/ 加工技術/冷凍技術/物流のフル活用

  • 生まれた価値

    • 生産物で捨てるものがなくなった
    • 地元に雇用が生まれた
    • 美味しくなった
  • 同じモデルを鳴門以外の地域にも横展開できる

こたつモデルの効果

  • 匠Method導入以前

    • システム屋としての視点☓飲食店の視点☓生産者としての視点
    • それぞれの視点・気持ちは大事だが、それぞれが分断されていた
  • 匠Method導入以後

    • システム屋、飲食店、生産者がひとつのチームになり、利害一致ポイントを抽出
    • チーミングとファシリーテートで想いが共有された

匠Methodによって生まれた現意識と新意識

  • IoTによる農地管理

    • 現意識:栽培管理のため
    • 新意識:マーケットにトレーサビリティデータとして提供
  • 循環農業

    • 現意識:堆肥を生産に活かす
    • 新意識:マーケットが欲しがっているオーガニック堆肥使用の新ブランド野菜をつくる
  • スマホの使用

    • 現意識:生産者用の専用アプリを自ら開発→使ってもらえなかった
    • 新意識:LINE(チャットボット)をインターフェースにした→70%使ってもらえるようになった

匠Method導入によってできたこと

技術起点イノベーション(当初のQOOPa)を、ユーザー起点イノベーション(QOOPa Premium Market、THE NARUTO BASE、FARM to TABLE)に変えることができた

  • コメント

    技術を元にしたソリューション提供(当初のQOOPa)は、技術起点のアプローチ(=Howからの突き上げ)であり問題ではない。ソリューションのアイデアを顧客・ステークホルダー視点から検証していないことが問題であった。

まとめ

  • 匠Method導入のタイミングは早ければ早いほどよい
  • 導入のキーマンを明確にし、本気で巻き込むチームビルディング
  • 匠Methodを難しく捉えない

    • ビジネスメソッドであって論語のようなものである
  • 大事なのはみんなで匠脳になること  

    • 日頃の生活の中で自然に意識できるように
  • 農家もITも関係ない。つくりたいのは笑顔。笑顔なき価値創造なんてありえない

  • コンセプトの共有に時間をかけろ
  • Break The bias
  • 成果を出したければ「想いを紡げ!」

感想

システム屋視点のソリューションが行き詰まったところから、匠Methodを活用して、農業生産者、飲食業の幅広い視点を獲得して、周りを巻き込みながら、ソリューションを広げていくところに、ビジネスのストーリーを感じました。

「嬉しい」かどうかを感じるだけでなく、その解決策は、ステークホルダーが笑顔になるのか、満面の笑みなのかをイメージしてみると、さらに共感力が増し、その後の巻き込み力が増していくのだと学ぶことが出来ました。

巻き込み力をつけていきたい私には、とても参考になる事例でした。

セッション2へ

全体へ

匠Methodの書籍はこちら

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

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

2017年1〜6月 登壇イベント/発表資料まとめ

2017年も半分が終わりました。

1〜6月 上半期に登壇した、イベントや勉強会で発表したスライドをまとめておきます。

Community Manager Summit 2017 :2017/1/23(月)

匠女子会 :2017/2/8(水)

Developers Summit 2017 :2017/2/16(木)

某大手SIer 社内勉強会 :2017/3/7(火)

Baseball Play Study 2017春(BPStudy#115) :2017/3/28(水)

BPStudy#116 :2017/4/24(月)

要求開発アライアンス5月定例会 パネル:2017/5/30(火)

redajp.connpass.com 匠の要求開発里帰り 討論会「価値主導によるビジネス最前線で活用するメソッドや開発手法の効果と進化の方向性」にパネラーとして登壇

匠道場 6月開催 Q&A:2017/6/22(木)

shacho.beproud.jp

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

「プログラマのための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を紹介するだけでなく、サンプルアプリケーションでしっかり使っているので、読者は活用イメージが湧くことでしょう。

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

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

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

  • ステップ1:Webアプリ+SQLite
  • ステップ2:Webアプリ+Cloud SQL
  • ステップ3:Webアプリ+Cloud SQL+Cloud Storage
  • ステップ4:Webアプリ+Cloud SQL+Cloud Storage+Cloud Load Balancing

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

基礎技術の丁寧な説明

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

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

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

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

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

  • リクエストとレスポンス
  • HTTP通信

  • データベースの基礎

    • データベースの種類
    • データベース操作言語
    • トランザクション
  • サーバー仮想化技術

    • ホスト型仮想化
    • パイパーバイザー型仮想化
    • コンテナ型仮想化
  • インフラ環境構築

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

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

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

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

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

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

実績ある著者が執筆

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全体構成

  • 前半

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

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

  • 後半

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

匠メソッド概要

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

    • 価値分析デザインモデル
    • 価値デザインモデル
    • 要求分析ツリー
    • ビジネスコンテストフロー(AsIs)
    • ビジネスコンテストフロー(ToBe)
    • ゴール記述モデル
  • 価値分析モデル、価値デザインモデル、要求分析ツリーがシームレスで、行き来できるのが大きな特徴

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

    • 人はやりたいこと、やるべきことから考える。匠メソッドは価値から考える
    • やりたいことを踏まえた上で価値から考える
    • なぜ価値から考えるようにしたか? → 頭を慣習から解き放つため
  • 論理思考(要求分析ツリー)で考えたものを感性(価値デザインモデル、価値分析モデル)で叩け

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

価値分析モデル

  • ステークホルダーを巻き込むストーリーを記述する
  • 価値→目的、目的→価値 と洗練させる
  • シチェーション+手段+嬉しい言葉で、価値を記述する

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

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

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

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

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

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

    • 価値記述は手段を書き、手段を抽象化して目的にする
    • 逆に抽象的過ぎる業務要求は、要素分解して複数の業務要求を抽出する
    • 業務要求の変更にしたがい、価値記述も変更する
  • 目的と手段を行ったり来たりして、洗練させる(※萩本さんの資料が図になっていてわかりやすい)

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

価値デザインモデル

  • ビジョン=実現すべき未来の姿
  • コンセプト=ビジョンに近づくために重要とする3つの構想(大目標)
  • 内向けの価値デザインモデル(業務改善、プロダクト開発など)、外向けの価値デザインモデル(営業・販売)
  • 内向けの価値デザインモデル:コンセプトの2つは組織の外向け、1つは組織の内向け
  • コンセプトの3つのうち2つを組織の外向けにするのは、社員に外を意識させるため

  • 意味

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

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

    • 戦略ベース

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

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

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

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

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

要求分析ツリー

  • 思考のレイヤリング

    • 思考のレイヤリングができると、企画力が高まり、議論がスピーディーになる
  • 「結果」を達成するための「施策」を戦略要求の目的レベルに書く(結果を書くのではない)

    • 「売上向上」は結果なのでNG
    • 「若手層の売上向上」はOK(かもしれない。プロジェクトによる)
  • 手段から目的を抽出する、業務要求の抽出ステップ(※萩本さんの資料が図になっていてわかりやすい)

    • 1.具体的な手段を考える
    • 2.手段を目的として抽象化
    • 3.目的と手段がつながらないとき、手段を抽象化して業務要求をつくりだす
    • 4.新たな手段が生まれる
  • 例:会員にメールを送りたい(具体的な手段)→会員とのコミュニケーション活性化(目的)→会員に連絡したい(手段の抽象化)→会員にアプリでPUSH通知(新たな手段)

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

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

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

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

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

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

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

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

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

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

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

匠の夏祭り

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

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

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

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

connpass.com

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