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

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

it-takumi.connpass.com

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

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

登壇者

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

匠Methodの特徴・効果

• 6つのシンプルなモデル
• モデルが心をどう刺激するかを考える
• 動機力をUPするためのモデルである
• 価値は感じるもの（論理的なものではない）
• 匠Methodのビジョン：みんなの嬉しいを創り出す

• 嬉しいを演出しないとステークホルダーがビジネスモデルに参加してくれない

  • 価値のバランスが大事

• プロジェクトの目的は自分たちの下心

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

新製品企画での活用事例

登壇者

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

匠Method導入の経緯

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

• 匠Methodの以下の点が良さそうと思った

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

匠Method史上最悪の生徒

• 立ちはだかった高い壁（その１）

  • 現意識が中心でなかなか新意識が出てこない

  • 今までできなかったことを実現したい(=ERPで実現したいこと）との思いの強さがギャップの原因

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

  • まずは未来の製造業の姿を描くことに変更→良い方向に向かい始めた

• 立ちはだかった高い壁（その２）

  • ポエマー不在、デザイナー不在（理系集団の悲哀）

  • 価値デザインモデルで要素は出るが、言葉としてまとまらず、いつまで経っても言葉が空白

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

• 立ちはだかった高い壁（その３）

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

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

経営陣への企画プレゼン

• ビジョン：全世界のマーケットニーズに即応するための変革を支援する
• マイクロサービス型ERP＋IoT&BigData

• 2020年に向けての目標

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

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

→ 一発OK！

製品リリースと成果

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

匠Methodを導入した効果

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

  • 外部の声をシャットアウト

• 顧客中心のアプローチができるようになった

  • 共通言語が「お客さんのために」や「顧客の価値」になった

• 市場ニーズの変化に対応しやすくなった 　

  • 要求分析ツリーの中のここをやろう、こことここがつながるというトレースができるようになった

• 巨大な要求分析ツリーをつくったが、メンバー共通の知識ベースができた

匠Methodに望むこと

• 匠Methodブートキャンプ

  • リーダークラスが揃うと俺のやり方を通そうとする
  • 匠Methodの型にはめてほしい

• ポエマー養成講座、デザイナー養成講座

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

• 数値目標アプローチ

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

感想

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

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

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

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

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

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

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

セッション3へ

全体へ

匠Methodの書籍はこちら

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

匠の夏祭り2017〜第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風に進めていたら、やってたら２年位かかるところを、匠Methodを活用し、半年でカットオーバー

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

• QOOPa（クーパ）を開発・リリース
• 飲食業の人にヒアリング→要件定義→開発→賞も取れた→顧客も増えた→行けるのではと思った
• イノベーションを起こしたはずなのに、収益化できない！

• 同じジャンルに多くの製品がある→営業力で勝つしかなくなる→別の差別化が必要

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

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

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

  • 従事者の減少
  • 食材の入手の難しさ
  • オペレーションコストの増加

• ITだけでは片付けられない課題が結構ある→徳島へ

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

  • 生産物が余ってる

• ICT/IoTを活かせば、解決を同時進行できるのでは

  • ものが売れない
  • 規格外品をどうしたらいいかわからない
  • せっかく作ったものを廃棄しなければならない
  • なにを作ったら売れるのかがわからない
  • 加齢で体がしんどい
  • 後継者がいない

• 農家の立場・レストランの立場になってCX（カスタマーエクスペリエンス）駆動で考えてみる→匠Methodで企画

FARM TO TABLEで解決すること

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

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

• （１）首都圏＋食材産地直送モデル

  • 賃金が高くなる
  • 大きな物流拠点が必要になる

• （２）首都圏＋食材産地即加工モデル

  • 調理スキル依存型経営から脱却できる可能性
  • 食材費を下げて、賃金を上げることが出来る

  • 産地の加工は以下の４つで請ける

    • 素材加工
    • 複数素材加工
    • 指定調味加工
    • 完全加工

• （３）食材産地即加工++ モデル（鳴門方式）

  • 農家の収益拡大（おいしいのに捨てているものを使う）
  • スープストックのような経営スタイル(調理師が店にいない）を中小外食で採用可能
  • 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: 〜新たな価値観でプロジェクトをデザインするために〜

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

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

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

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

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

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

恋愛 x 匠メソッド from Haruo Sato

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

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

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

匠メソッドを導入したらサイトのサクセスが10倍になった話〜connpassの事例その他 from Haruo Sato

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

Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ！) from Haruo Sato

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

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

要求開発アライアンス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のデータセンター、ネットワーク、そしてソフトウェア技術をフル活用した、クラウドプラットフォームです。

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

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

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

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

• 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開催レポート