【読書感想】初めてのカスタマージャーニーマップワークショップ
さて、今日は書評エントリーです。
今回はこの本。
はじめてのカスタマージャーニーマップワークショップ(MarkeZine BOOKS) 「顧客視点」で考えるビジネスの課題と可能性
- 作者: 加藤希尊
- 出版社/メーカー: 翔泳社
- 発売日: 2018/09/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
さくさくと読める良い本でした。
きっかけ
今回この本を手に取ったのは自分が携わるプロダクトのディスカバリーチームに相当するマーケティングチームを立ち上げ、先日イベント出展を終えました。 プロダクトのMVPも完成、ローンチし、これから顧客にアプローチするフェーズに入った今、マーケティングチームの仲間と、顧客の課題をどう乗り越えていくかという視点で、考えを整理したいと思っていました。その手法として、カスタマージャーニーマップのワークショップを実践しようとしたところでこの書籍に出会いました。
チームのこれまで
私たちのマーケティングチームはこれまで、
などの施策を打ってきましたが、これからが実際のユーザー獲得ということで、そんな状態にうってつけと思いました。
本の内容について
この書籍はワークショップのファシリテーターに寄り添った書籍です。 というのも、カスタマージャーニーマップとは何かというところから入り、実際のワークショップをどうやって行うのか。 過去の先人たちの成功例やサンプルが載っているため、自分ごととして吸収できる書籍です。
ワークショップは社内外とわず、色々やってきた中で、ワークショップの組み立て方に関して、書籍から学ぶのは私の中で新鮮で、とても吸収できる部分が多いものでした。 普段はネットで実践者のブログや登壇資料を複数見て自分の中でイメージして組み立てるという方法で挑んでいます。 しかし、これだけまとまっていて体型的に学べる書籍があれば、自信を持って実践できると感じました。
最後に
というわけで、この本は読むだけではまだ終わりじゃありません。 いざ実践して初めて手に取った意味がある書籍です。実践した暁には技法紹介エントリーをここに認めようと思います。
ぜひ、皆さんも手に取って実践してください。
はじめてのカスタマージャーニーマップワークショップ(MarkeZine BOOKS) 「顧客視点」で考えるビジネスの課題と可能性
- 作者: 加藤希尊
- 出版社/メーカー: 翔泳社
- 発売日: 2018/09/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Scrum Fest Osaka 2019にプロポーザルを出しました !
先日、Scrum Fest Osaka 2019にプロポーザルを出しました。
今回はここで話したいと思っているお話のサマリーをまとめようと思います。
ちなみにこの記事はDevLOVE Advent Calenderの19日目の記事です。
この記事をよんで「聞いてみたい」と思ったら、ログイン & Likeをお願いします。 Likeの数が話せるか否かが決まる要素の一つなので！
私は何者か。プロポーザルの背景。
まず、「私は何者か」からお話しすると、"映像業界をチームで働く業界に変えたい"と思って日々活動しています。 そのきっかけはやはり働き方改革です。
映像業界のみならず、多くの業界が長時間労働が解決できないでいる状況の中、電通の事件により、加速度的に進む世の流れと法案により、 対策を取れずに働くことをストップせざるを得なくなりました。
そのため、長時間労働を基準として考えていた生活がままならなくなり、離職していく人々が格段に増えました。 ただでさえ、職人の世界。腕に職をつけ、指名を受けるとそのお客さんごと独立していく世界。
それが加速していくとどうなるでしょう？ 今まで成り立っていた事業は衰退し、属人化されていた仕事がその人がいなくなることでどうしたらいいのかわからなくなる。 それがこの1年くらいの様子です。
やめていく人々も口々に
「この会社は好きだけど、この業界は好きだけど、急にこうなっては生活できないので・・・」
と離れていきます。
そしてその様子は在籍者へのしわ寄せとなり、モチベーションも低下していきます。 まさに負のサイクルです。
経営者でなければ対処はできないのか？
この状況を打開するために私にできることはないのか。 そこでエンジニアの私の中で思い立ったのが、
『アジャイルやスクラムはエンジニアにしか必要ないものだろうか？適用できないものだろうか？』
という疑問です。
みなさんご存知の通り、スクラムガイドには
「検査」「適応」「透明性」がうたわれています。
これはエンジニアだけでなく、営業、企画、人事、総務、製造など業界や所属に関わらず必要ではないでしょうか？
むしろ、Githubを見れば、誰がどのコードをいつ書いたのか、そしてそれがレビューされている状態のエンジニアの方が、すでに"透明性"を持った働き方をしており、抵抗も少ないのではないでしょうか？
そう思い、私はいろんなことを始めました。
全てこの半年で行いました。
あなたにも必要では？
私の半年でやってきたこれらの活動は特殊な状況でのみ必要なことでしょうか？
そこで質問です。 『あなたのチームやプロジェクトはステイクホルダー含めて、全てエンジニアで組成されているのでしょうか？』
そのため、プロポーザルで挙げたセッションでは、
- 「チーム全員がプロジェクトの進め方を理解する」
- 「仕事に透明性を持たせる」
- 「カイゼンのサイクルを適応する」
といった3点を習慣にするために私が行ったこと、そこから得た学び、明日皆さんが始められるポイントなどをお話しできればと思います。
私のマインドを作った「DevLOVE」
このようなマインドに私がなったのは2月にDevLOVEに深く触れることになったからです。
DevLOVEではゴリゴリの技術からチームビルディングやゲーミフィケーションまで内容は多岐にわたっています。
それはなぜなら、この３つのコンセプトを基に活動されているからです。
- 開発の楽しさを発見しよう。広げよう。
- 開発の現場を前進させよう。
- 自分から越境しよう。
私は運営としても関わっていますが、これからもたくさんの現場と、その現場で１歩踏み出そうとしている人たちの居場所となるようなイベントができればいいと思っています。
今後もイベント情報はでメンバーになり、キャッチアップしてください。
最後に
私の目標は、「映像業界の多くの人に私の取り組みを伝えたい。悩んでいる人と一緒に解決をしたい。」という点です。 そのため、ぜひ多くの場でお話しさせていただきたいです。
改めて、この記事をよんで「聞いてみたい」と思ったら、ログイン & Likeをお願いします。 Likeの数が話せるか否かが決まる要素の一つなので！
よろしくお願いします。
【AWS再入門】5分でわかるRDS
さて、前回から始めたAWS再入門シリーズ。 今回は業務でもAuroraの理解が再度必要になったのでAmazon RDSについてです。
ちなみにEC2はこちら
Amazon RDSとは
Amazon RDS でマルチ AZ データベースインスタンスの停止および起動が可能に
対応エンジン
制限事項(Oracle Databaseの場合)
- バージョンが限定される
- キャパシティに上限がある
- OSログインやファイルシステムへのアクセスはできない
- IPアドレスは固定できないRAC,ASM,DataGuard,RMANなどは使えない
- 個別パッチは適用できない
マルチAZデプロイメント(Multi-AZ)
- 複数のAvailability ZoneにMasterとSlaveのインスタンスを配置
- MasterとSlaveは同期される
- Masterのインスタンスやハードウェアの障害があった場合、自動でSlaveがMasterに昇格(フェイルオーバー)される
- 手動リブートによる強制フェイルオーバーも可能
リードレプリカ
- レプリカDBを作成し、読み取り処理をスケールアウト可能
- リードレプリカは5台(Auroraは15台)まで増設可能
- マルチAZとの併用、クロスリージョン対応が可能
- Masterと異なるインスタンスサイズやストレージも設定可能
- スタンドアローンの DBインスタンスに昇格も可能
- MySQL,MariaDB,PostgreSQL,Auroraに対応
インスタンスタイプ
- EC2と同様 vCPU、メモリ、EBS最適化、ネットワークの組合せで決まる。
- ストレージタイプは下記3タイプ
- 汎用SSD
- プロビジョンドIOPS
- Magnetic
- ストレージサイズは16TBまで(MySQL,Oracle,MariaDB,PostgreSQL)
スナップショット
- 日時でデフォルトでスナップショットとトランザクションログが自動でS3に保存される。
- 保存期間は最大35日分
- 自動スナップショットはインスタンス削除時に削除される
- 上記とは別に手動でスナップショットは任意で取得可能。削除も自由
- スナップショットを元にインスタンスを立ち上げることが可能(リストア)
- リージョン間、アカウント間でコピー可能
- スナップショット実行時にI/Oが一時停止する(マルチAZの時は気にしなくてOK)
メンテナンスウインドウ
- 数ヶ月に一度発生するメンテナンスのタイミングを何曜日の何時に実行して欲しいのかユーザーが指定する
- 指定した時間帯の中で数分間実行される(詳細な時間は内容による)
暗号化
- DBインスタンス、自動バックアップ、リードレプリカ、スナップショットを暗号化可能
- データアクセスと復号の認証は透過的に処理するので気にしなくて良い
- AWS KMSで鍵管理が可能
- 対応しているインスタンスタイプは限定される
- インスタンス作成時のみ設定可能
Amazon Aurora
- Amazonがクラウド時代向けに再設計したDB
- MySQL5.6、5.7互換
- MySQLのエコシステムをそのまま活用可能
- 多くの3rd Party監視ツールを利用可能
- 3つのAZの6つのディスクに書き込まれる - 2つのディスクに障害が起きてもread/writeが可能 - 3つのディスク障害が起きてもreadが可能
- キャッシュとログがプロセスから分離されているので、再起動をしてもキャッシュが残る
- AES-256で暗号化
- KMSを利用したキー管理が可能
- SSDを利用したシームレスにスケールするストレージ
- リードレプリカもマスタと同じストレージを参照
- 増分を継続的にS3にバックアップ
- 64TBまでシームレスに拡張するストレージ
- 自動で際ストライピング、ミラー修復、ホットスポット管理、暗号化
- リードレプリカが存在する場合、1分程度でフェイルオーバー
- クラスタ(WriterとReaderのセット)で常にWriterを示すEndpointが存在する
- 各ノードそれぞれにEndpointを持っている
- そのため、フェイルオーバ発生時はノードの昇格が行われ、クラスタEndpointのさし先が変わる
- Adaptive Thread Pool：アクティブなスレッドに複数コネクションがはられている。スレッド数は動的に変わる
- MySQLのSnapshotから作成可能
料金モデル
Aurora以外
- DBインスタンス($/時間) - 1時間単位で利用可能 - ライセンス込み or BYOL - DBエンジン、インスタンスタイプ、 Multi-AZなどで料金が変わる
- ストレージ($/GB/月) - ストレージ容量、I/Oリクエスト数 - バックアップストレージ容量($/GB/月)
- データ転送 - 別のリージョンへのデータ通信($/GB) - インターネットへのデータ通信($/GB)
Aurora
- DBインスタンス($/時間) - 1時間単位で利用可能 - MySQL互換 or PostgreSQL互換 - DBエンジン、インスタンスタイプ、 Multi-AZなどで料金が変わる
- ストレージ($/GB/月) - ストレージ容量、I/Oリクエスト数 - バックアップストレージ容量($/GB/月)
- データ転送 - 別のリージョンへのデータ通信($/GB) - インターネットへのデータ通信($/GB)
2つの価格モデル
まとめと私の思うポイント(あくまでテスト対策)
- パフォーマンスを考えるとAuroraを採用するのが解
- ただ、考え方の根本が異なるので、理解を深めてチューニングしないとパフォーマンスがイマイチなことも
- デフォルトのパラメータグループで最適サイズのインスタンスを選ぶことから始める。
- うまくいかなかったらパラメータグループをいじってみるのが良いかも
- クエリの同時実行数やテーブルサイズが大きい時に有効と言われているが、そこまでこだわらず、基本的にAuroraで良い気もしている
- 複数のサーバにシャーディングしている場合、1つのAuroraにまとめると良さそう(内部的には一つではないので)
- 現在がMySQLで動いてたら、そのスナップショットから作成してみるとはじめやすいかも。
【コラム】本業がフルフルの中で時間を作るための工夫
今回は
The Agile Guild(TAG) Advent Calendar 2018 7日目の記事として書いてみました。
突然ですが、みなさん忙しいですか？
そりゃそうですよね。 私も週5で8時間 + 残業 で勤務をしているのでとてもわかります。
ただ、そんな中でも本業以外のコミュニティー活動、複業、趣味の時間をつくるために私がやっていることをつらつらと書いていこうかと思います。
なぜ、自分の時間を使ってまで活動をするのか
私は主に本業の他に The Agile Guildに7月に、DevLOVEというコミュニティーに3月に参加させていただいています。
そもそも、それまでの私は毎日9:30に出勤し、タスクに追われて22時まで時にはテッペンまで働くことも厭わないようなスタイルでした。 ただ、2018年2月のDevSumiでのある講演を聞いてから私の生活は一変しました。
ちなみにそれについてまとめた記事がこちら。
このブログを始めるきっかけにもなりました。
どんな衝撃を受けたかというと・・・
- 毎日悶々としている中で背中を押してくれた
- 今の自分の状況を打開するヒントがあった
という点です。ここでいくつか気づきを得ました。 それは
- 社内では初めてのことをやっていても外の世界にはすごい人がいっぱいいる！
- 自分にできることは社外にもあるのではないか？
- 同じ志を持った同志は社外にもいるかもしれない。
そこから、カクカクシカジカありまして・・・DevLOVEにJoinしました。 ※ ここにまとめてます。
www.slideshare.netここで思ったのが、
やってみよう！と思うのは誰でもできる。しかし、やらない理由 > やる理由になる人がほとんどではないか？
という疑問です。 例えば、本業以外にやりたいことがあっても、やらない理由はたくさん思いつきます。
- 疲れるし・・・
- 遊びたいし・・・
- 家族がいるし・・・
- 嫁がいるし・・・
- 子供がいるし・・・
- 会社がダメって言うし・・・
- 自分レベルがわからないし・・・
- 本業忙しいし・・・
- 時間ないし・・・
などなど。ただ、そこで諦めていたら、次のステージに進む速度は本業で得られる成長スピードでしかないかなと私は思いました。 そして、本業では得られないスキルを社外の人は持っているかもしれないと。
私にとってそれは「仮説検証」というものでした。
私とTAGと
私は本業でエンジニアとして働いています。 主な業務は、PM、PO、スクラムマスター、AWSエンジニア、セールスエンジニアといった感じで1000人規模の企業においてエンジニア10人弱のチームで37のプロダクトを作っています。 そのため、プロダクトマネージメントという観点で当然ながら顧客に対するマーケティングも行います。 しかし、私の所属する企業では、「マーケティング = 営業の仕事。PMは開発のみに携わる」という文化が根付いていました。 そのため、いくら外部の方とお話ししたり本を読んだりして得た知識で説得を試みてもどことない「顧客のことは営業の方が分かっている」という空気に押し出されて、正しいことができない状況にありました。
しかし、案の定、マーケティングはうまくいかず、手塩をかけて育てたプロダクトは何回も沈んでいきました。 私はもうそんな思いはしたくない。しかし、自分の力不足は否めない。
そこで、直談判し、TAGにおける仮説検証業務にくわえさせてもらいました。
そのため、私におけるTAGの活動は
- 複業で小遣いを稼ぐ
- 自分の実力を確かめる
でもなく、
- 自分が成長する
- TAGにも貢献したい
- それを本業や業界にも還元する
- そして、自分にしかできない形で社会に貢献したい
という側面が強いです。
複業との向き合い方
と私の複業との向き合い方を書いてきましたが、 複業をどう考えるかは人それぞれだと思います。
- 空いた時間でお金を稼ぎたい
- 自分のスキルを活かしたい
- 自分のスキルを伸ばしたい
- 人脈を作りたい
- 世の中を良くしたい
どれもありだと思います。 間違っていないと思います。
では、そのために使う時間は本当に残されていないのでしょうか？
時間を作る工夫
では、具体的に私が時間を作る些細な工夫についてです。
- 行きの電車：調べ物や読書に使う
- 業務中の移動時間：メールやSlackのどうでも言い返しは全てこの時間でしか行わない
- 業務後：積極的に打合せや勉強会を入れて体を慣れさせtる
- 帰りの電車：1日の振り返りと帰宅後のアジェンダを脳内で組み立て
- 帰宅後：入浴後に必ず1時間は確保。ここでブログを書いたり、仕事をしたり。
- 入浴中：アイディア出しの時間に使う
- 就寝直前：読書で頭を休ませ、眠気を誘う
正直全て大したことがないです。ただ、こんな大したことがない方法で時間は作れます。気持ちさえあれば！
改めて・・・
そのために使う時間は本当に残されていないのでしょうか？ やらない理由 > やる理由 になってませんか？
もし、一歩踏み出そうと思った方は、こちらから門を叩いてみてください。
【読書感想】スクラム現場ガイド ~スクラムを始めてみたけどうまくいかない時に読む本~
今日はXP祭りの登壇時にいただいたこの本。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
ちょうど私自身がステークホルダーとしてスクラムでプロジェクトがひと段落し、来月からProduct Ornerとしてのプロジェクトを始めるうえで、読んでとても良かったと実感しました。
この本の読んで良かった点や感じた3つのことをまとめていきます。
各ポイントを網羅した各テーマ
この書籍は30章の章立てがされています。それぞれは10~15ページで構成されていて、サクサクと読めるもの内容です。 そしてこの各章も準備から実践、緊急対応、上級者向けとステップをおいて書かれており、基礎から応用まで順を追って学ぶことができます。 特に終盤は受託企業としての契約方法やプロジェクトコストの見積もりなど他のスクラム導入書ではなかなか得られないアドバイスが含まれています。
イメージしやすいストーリーと解説
というわけで、各章、満遍なく押さえてられています。一方で、章の中の構成もストレートでわかりやすい構成になっています。 まずは想像しやすいようなストーリー形式でシチュエーションを想像させ、そのストーリーの解説を挟み、最後には実践した際の実践の鍵という構成です。 この構成のおかげでストーリーを読みながら、実践をイメージし、自分の場合の難易度やどう実践しようかを考えている間に解説でストーリーでわかりにくいところをさらに紐解き、難しいと感じている部分のヒントを左もらえる構成で、実践がうずうずなるような印象です。
自分が実践し、成功するための鍵
先述の通り、各賞の最後には"成功の鍵"というページがあり、ここで実践に向けたアドバイスが書かれています。 ただ、この書籍自体が訳書ということで、アメリカ文化と日本文化のギャップは多少感じますが、実際の自分ごと感をしっかり与えてくれるだけでなく、自分への問いを自然に生まれるものでした。
今後のこの書籍との向き合い方
この書籍はある意味、百科事典のような付き合い方もできるかなと感じました。 実際に自分が壁にぶつかった時に逆引きして課題を乗り越えたり、向き合うことに使えると思いました。
そのため、会社のデスクの脇にいつでも手に取れるようにおいておきたい一冊です。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
【AWS再入門】5分でわかるEC2
AWS Solution Architectをとってもうすぐ早2年。 更新をするにあたり、最新情報をおさらいしようと思います。なので、それに合わせて自分の"学び直したこと"と"気になったこと"をこのブログにも書いていこうかと思います。今日は最初にして最大の情報量になるだろうAmazon EC2です。
Amazon EC2とは
- Amazon Elastic Compute Cloudの略称
- AWSのクラウド上で稼動する仮想サーバー
- そのそれぞれをインスタンスと呼ぶ(仮想サーバーなので、1台と呼ぶのは気持ち悪い。物理的には1つのH/W内に複数インスタンスが動いているので)
- 任意のリージョン、アベイラビリティーゾーンで稼動
- WebブラウザからAWSマネージメントコンソール経由、API、CLI経由での操作が可能
リージョンとは？
- いわゆる国、エリアの概念
- 複数データセンターの集合体
- 2018年現在 18のリージョンと1つのローカルリージョンが存在
- ローカルリージョンとは機能や性能が制限されているリージョン(ちなみに大阪)
- ローカルリージョンを除くリージョンは2つ以上のアベイラビリティーゾーンで構成されている
- リージョン間は高速ネットワークが構築されている
アベイラビリティーゾーン(AZ)
- リージョン内に複数存在する
- 地理、電源、ネットワーク、空調などを互いに影響を受けないレベルで別れたデータセンター群の単位 (よくデータセンターそのものと表現する人もいるが厳密には複数あるらしいのでデータセンター"群")
- リージョン内での災害対策の地理冗長などを目的に複数AZにインスタンスを立ててを組み合わせて利用することが多い
EC2の物理基盤
EC2インスタンスの種類
- インスタンスファミリー + 世代 . インスタンスサイズ という記法で表現 ex) c5.large
- インスタンスファミリー：何に最適かしているか
- 世代：文字通り世代。
- インスタンスサイズ：バーチャルCPU、メモリ、RAM、ネットワークスペックの大小
- インスタンスファミリーと現行の世代は以下 - T2：汎用(開発環境など向け) - M5：汎用(小中規模のDBなど) - C5：コンピュート最適化 - D2：ストレージ最適化(Big Dataなど) - H1：ストレージ最適化(同じくBig Dataなど) - I3：ストレージ最適化(NoSQL DWHなど) - R4；メモリ最適化(ハイパフォーマンスDB) - X1e：メモリ最適化(インメモリDB) - G3：アクセラレーテッド(3Dレンダリング) - P3：アクセラレーテッド(機械学習) - F1：アクセラレーテッド(ゲノム解析)
- 通常は低負荷だが稀にスパイクするサービスのためにT2 unlimitedというオプション機能がある
物理ホストの占有
- ハードウェア占有インスタンス/ EC2 Dedigated Hostの2択
- どちらも専用の物理サーバでインスタンスを起動
- EC2 Dedicated Hostはハードウェア単位のBYOL(ライセンス持ち込み)が可能
- ただしハードウェア自体の直アクセスは両方できない
- そこで第3の選択肢「AWS EC" BareMetal」がプレビュー中
- ハードウェアへのダイレクトアクセスを提供する新しいEC2インスタンスのシリーズ
EC2の機能
- Key pair：EC2は公開鍵認証でアクセスをする。そのための公開鍵と秘密鍵の組み合わせ
- Security Group：インスタンス単位のFirewall機能
- Elastic IP：インスタンスにアタッチできる固定のパブリックIPアドレス
- Elastic Network Interfaces (ENI)：EC2をホストするVPC(Virtual Private Cloud)内の仮想ネットワークインタフェース
- 拡張ネットワーキング：各インスタンスの通信性能を最適化する機能
- Cluster Placement Groups：各インスタンスをグループ化してインスタンス間のネットワーク通信を最適化する機能
- Auto recovery：何らかの原因でインスタンスが落ちた場合に自動復旧させるオプション(起動時の実行コマンドも仕込める)
EC2のストレージ
- 「インスタンスストアボリューム」と「Elastic Block Store(EBS)」の２種類
- インスタンスストア：インスタンスに密結合されたストレージ領域(停止/起動で中身が削除される揮発性メモリ)
- EBS：着脱可能なブロックストレージ(停止/起動で中身が削除されない)
Amazon Machine Image
- インスタンスのイメージを取得して保存する機能。
- AMIを取得してインスタンスを削除しても、AMIからインスタンスをシド作成すればイメージを元にインスタンスを作成できる
- AWS本家だけでなくサードパーティーからも提供されている
インスタンスのライフサイクル
- 起動/停止/削除の３パターン
- 起動(Start)：文字通り実行。Stoped→Runningにステータスが変わる
- 停止 (Stop)：停止状態。Running→Stopedにステータスが変わる
- 削除(Terminate)：削除状態。インスタンス自体を破棄しているので、二度と同じインスタンスは立てられなくなる。
EC2の費用
- 起動時間の1秒単位で課金
- インスタンスの種類によって単価が分かる
- 購入オプションごとにも金額が変わる
購入オプション
- 以下の5種類
- オンデマンドインスタンス：初期費用無し、従量課金
- リザーブドインスタンス：1年間または３年間、常に利用可能なキャパシティ予約により、最大75%の割引
- スポットインスタンス：未使用キャパシティを時価で提供、最大90%の大幅な割引で利用可能。ベットした金額を上回る入札があれば強制終了される
- 専用ホスト(Dedicated Hosts)：インスタンス実行用物理ホストの単位で支払い。
- ハードウェア専有インスタンス( Dedicated Instance)：シングルテナントのため丸々かかる
まとめと私の思うポイント(あくまでテスト対策)
【コラム】RSGT2019で話したかったこと！
来たる2019年1月、毎年恒例となりました、Regional Scrum Gathering Tokyo2019が開催されます。
このイベントのセッションは10月に公募がなされていて、計80を超える応募の中から約30のセッションが行われます。 私も下記の2つを応募してみました！
残念ながら、両方とも採択されるに至らなかったのですが、今回はこの講演でどんな話をしたかったのか、整理してみようと思います。
序文に抱いた思い
今回はまず序文にこんなことを書きました。
"チームで仕事をする"という場面において、気心の知れた仲間や同じ価値観を持った仲間のみとチームを組成できる機会はそうそうありません。
むしろ、自分と異なるスキルや価値観を持つ人や初対面でのチーム組成も少なくありません。
そして、プロダクトを生み出すにあたり、エンジニアのみではなく、企画職、営業職など文化の異なるメンバーが集まることも当然必要になります。
一方で、「スクラム」「アジャイル」といった流儀を営業や企画職にうまく伝え、一緒に進めていくのも一苦労。
言葉の違うチームにおいて、お互いを知りながら、チームを形成するために私が行った「営業、エンジニア合同のスクラム勉強会」についてワークショップ設計時の工夫、そこでの学びをお話しします。
また、初めてでも同じように組織にチームビルディングのワークショップを行っていただけるようなポイントについても紐解いていきます。
これは私が携わっているプロジェクトでのモヤモヤから生まれたものです。 私の所属する会社はソフトウェア、ハードウェア、ネットワークエンジニアが全体の約1%です。 そのため、プロダクトに関しても複数を同時にこなし、チームも2,3人がメッシュ状に絡まなくてはならない、スクラムでいうとアンチパターンに相当する状態で、ビジネスの規模や需要を考えるとここは仕方ない状態です。
一方でチームとしては気心の知れたメンバーとのやりとりを基本としてはいますが、チームビルディングやカイゼン、ふりかえりを重んじる空気には育ちました。 開発チームとしてはそんな状態ではありますが、複数あるプロジェクトにおいては各部署や外部の顧客などステークホルダー異なり、また複数存在するパターンが多くあります。 そのため、PdMに相当する人間が調整を進めていきます。 ただし、発話する言葉の種類や観ている世界が異なることですれ違いやお見合い状態が多く発生しています。 特にそれはメンバーと外部の顧客というよりも
開発チーム - 担当営業 - 外部顧客
という構図の中で
開発チーム - 担当営業
によく起こります。中には 開発チームと外部顧客は意思疎通ができているのに、担当営業との方向が揃わないこともあります。 具体的には
外部顧客「(優先順位は高くないから)もし可能であればお願いしたい」 開発チーム「根本の設計思想に影響するので、代替案としてこれはどうか？」 外部顧客「OK！」
担当営業「いやいや、顧客が最もやりたかったのはそれじゃないから、叶えないと！」
といったことが起こります。
これはどうして起こるのか？私はいろいろ調べてみました。
あらゆるアジャイルやスクラムの書籍や勉強会に参加してもなかなか見つからない。
一つ見えてきたのはそれぞれの役割で
- 評価者が違う
- ゴールが違う
- 価値観が違う
- 嬉しいポイントが違う
と言った点が大きいということ。ただし、これは当たり前ではありつつも解決策に直接結びつくものではありません。 そんな中で出会ったのが、Jeff Patton氏のCSPO(スクラムアライアンス認定プロダクトオーナー)研修で出会った "ディスカバリーチーム"という考えでした。
ディスカバリーチームという考え方
ディスカバリーチームとは開発チームのみならず、営業、企画、アナリスト、デザイナーなども含めたチームでプロダクトを開発する前にインタビューやプロトタイプを活用した仮説検証を行うことで「本当に必要なものだけを作ることに専念する」という考え方です。
この考え方に感銘を受けた私はそこからいろいろと仮説検証を学ばせていただいています。
では、ディスカバリーチームを組めばそれでいいのか？
私はそうではないと思います。
というのも、開発チームで新しいプロジェクトにのぞむ時に
という行動は開発チームはおろかプロジェクトに関わる全員が行うべきではないでしょうか？
そう、それはアジャイルやスクラムを知っていようがいなかろうが。
"アジャイル"、"スクラム"は開発チームだけのものではない。
ただ、いきなりそんなことを言って「なんだそりゃ？」となるのも当然です。 なので、私は営業と企画を交えたスクラム勉強会を開催しました。
内容は全6回で座学半分、ワークショップ半分というで
- アジャイルって何？スクラムって何？
- POとは？SMとは？チームとは？
- 相対見積もりとは？ベロシティーとは？
- 各種セレモニーの意味と内容とは？
- 心理的安全性の高いチームとは？
- プロジェクト、プロダクトのゴールとは？
と言った話をしました。
そんな私の取り組みの中からの気づきや「まだ始められてないけど、どうしたらいいのか？」と言った方々に伝えられればと思って申し込んでみたのが今回の内容でした。
今回は残念ながら採択されませんでしたが、もしご興味がある方がいれば、DevLOVEなど他の場で是非お話しさせていただければと思います。
