5分間ワークショップの舞台裏を公開！
昨日、こちらのイベントにLT(5分)枠で参加させていただきました！
運営の方々を始めとしたみなさん、ありがとうございました！
さて、その5分間のLTで無謀にもワークショップをやっちゃいました！
おかげさまでいくつか反響もいただきました。
5分でワークショップはすごすぎる #sdevtalks
— 岡 花太郎 (@hanataro_ym) 2019年1月22日
はちさんのLTワークショップやべえ。すごい。 #sdevtalks
— Yoshiki Iida / CrowdWorks Inc. (@ysk_118) 2019年1月22日
それにしても話すの巧すぎん？ #sdevtalks
— すぱこー＠エオルゼア新住人 (@SpicyCoffee66) 2019年1月22日
ということで、このLTをやるに至った舞台裏をまとめてみようと思います。
思いつき
- LT(5分)でワークショップってできるんだろうか？という疑問から挑戦
- テーマは「採用」なので、きっと「どうマッチングするか」という話が多いと想定
- 一方で「面接などに来てくれた人がいかに普段のパフォーマンスを発揮してもらえるか」も重要なので、これを伝えたい
- ここ最近、新卒インターンシップで行なったアイスブレイクが自分なりにかなりしっくり来ていた。
- 上記よりアイスブレイクの重要性をテーマに決定
- フレームとして1分sprint×4 ＋バッファを想定
・1sprint目:導入
・2sprint目:ワーク1
・3sprint目:ワーク2
・4sprint目:ふりかえり、定着
資料作成
- ワークショップの内容が「タイムボックスを区切ることが重要」という側面があったので、フラッシュスライド形式でファシリ側もスピード感を出すことを想定
- 5分間でパッパッと変わって行くので難しい単語や専門用語は極力排除。瞬時に理解できるような構成に
- 導入は時間を出来るだけ短いので自己紹介は写真中心
- 「他にも知りたい！」と思ってもらえた後のアクションを提示するために次回のイベントへの誘導で締める
- ちなみにできて資料がこちらです。
www.slideshare.net
場づくり、実践
- 内容的に場が温まってるほど成功するので、登壇順番は後ろ目に(いつもはトップバッターが好きだけど！)
- 一番重要。冷めきった空気だとお見合いになってしまうので一言目から空気を変える勢いで明るく
- 突然始めるとみんなワタワタするので、PCを接続しながら「これからワークショップやりますよ！机の上倒したりこぼさないように準備してくださいね！」と予告
- 準備してもらってる様子を見ながら温度感を確認
- 「え？なになに？」と言いながら笑顔が多く、協力してくれそうな雰囲気を察する(ひとえに運営の方とそれまでの登壇者の方々の場づくりの賜物)
- 導入からちょくちょくふざける。笑いを取りに行く(これはわりと好き)
- ワークの説明は簡潔に。
- 徐々に声のトーンとボルテージを上げて「いよいよやるぞ！」感を演出
- ワーク開始！一気にコミュニケーションが加速。場の声量も最大に。いい感じ。
- ワーク1の終了と同時にリアクションを見る。笑顔が多く良さそう
- そのままテンションが冷めないようにこちらのボルテージを最高潮に持っていき、2つ目のワークに流れで突入
- テンション上がって「スタート！」って言いながら指を鳴らしてた気がするw
- ワーク終了！それなりに盛り上がっていて、登壇スペースから近い人を探す(ワーク中に目星をつけておく)
- 「どんなチーム名になりました？」と聞く。ここまで来たらもう何が出てもだいたい面白い。そういう空気ができてる
- 最後にふりかえり。「ふりかえり」という言葉を今回はあえて使わず、「解説」とした。その方がイメージに合ってたのとワークは終わったと理解し、聞き入りやすいかなと判断
- 解説は冷静に、みんながうなづけるようにアイコンタクトを積極的に
- １つの行動ごとにその意味を解説。
- 自身でも実践してもらいやすいように、ハードルが低いことをアピール
- 最後に宣伝をして、興味を持ってくれた方を引き入れる。そして次のアクションへとつなげてもらう道しるべとする
最後に
こんな感じで考えた内容をワークショップとしてやらせていただきましたが、自分なりにもかなり楽しくできました！
もし、
- うちでもやってほしい！
- 他の話も聞きたい！
などあったらお気軽にお声がけください！
そして、直近ではここでお話しする機会をいただきました！
こちらにも是非お越しください！
書評：「プラットフォーム革命 ~経済を支配するビジネスモデルは、どう機能し、どう作られるのか~」
今日はプロダクトマネージメント寄りの書評です。
読んだ本はこちら！
プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか
- 作者: アレックス・モザド,ニコラス・L・ジョンソン,藤原朝子
- 出版社/メーカー: 英治出版
- 発売日: 2018/02/07
- メディア: 単行本
- この商品を含むブログ (2件) を見る
なぜ読んだか
この本はとある勉強会でいただいたものでした。 日常のプロダクトマネージメントの業務の中で、 「どうプロダクトをグロースさせていくのか」「顧客体験を最大するにはどうするべきか」といった点の参考になればと読んでみました。
サンプル集であり、教科書である。
この本の中では実在する有名なプラットフォームで
"どんなことが起こったのか" "どう生まれたのか" "なぜ生まれたのか"
といった部分と
"なぜこのプラットフォームは死んだのか" "ターニングポイントはなんだったのか"
といった観点も触れられています。
その為、ベストプラクティスだけではなく、アンチパターンも学べます。
プロローグ「燃えるプラットフォーム」
この書籍の序文から紹介します。
2011年2月、ノキアは難題にぶつかっていた
いきなり、課題にぶつかったノキアのお話です。前述の通り、この本では成功、失敗の両方がサンプルとして描かれています。 この章ではこれまでのインフラやハードウェア産業とプラットフォーム事業の明確な違いと
「その立ち位置を変える舵取りをした企業」 「その道にとどまることを選択した企業」
の軌跡を1つの例を基に紹介しています。
1~4章 プラットフォームビジネスとは何か、プラットフォームビジネスが経済を成長させている理由
1章では
- ビジネスモデルの歴史
- プラットフォームにおける消費者とプロデューサーの関係性
- 商品の流れと情報の流れ
- プラットフォームの定義と例
- プラットフォームの構造
- マッチング意思
などに触れています。
これらの背景から、プラットフォームには「交換型」と「メーカー型」の二つの方式があり、自分のプラットフォームがどちらに適しているのかを理解することで、コア取引と4つの基本設計に通づると語っています。
2章では一転、20世紀における企業論と価値について振り返っています。
それを踏まえた企業の本質、コンピューターが市場に与えた影響などについて解説しています。
そして、このころの考え方はもはや時代遅れになっていると言っています。 その理由は今までのビジネスのスピード感に比べてプラットフォームビジネスは急激であり、急速であることであるということに由来しており、そのトレンドはもうしばらく続くことです。
3章では、プラットフォームビジネスには限界費用がないこと。それにはベンチャーキャピタルの存在が寄与しているといいます。 そしてプラットフォームは"成長ができる"だけでなく、"成長しなければならない"そのスケールかを最大限に活用することが必要です。
そのため、ほとんどのプラットフォームは成功/失敗の二極化すると解説しています。
4章ではそれらの成功に当たる「プラットフォームの支配」を"現代の独占"と定義しています。 そのためにはビジネスモデル、市場の拡大、競争的な独占という表現で"現代の独占"が意味するものを解説しています。
5~8章 プラットフォームビジネスの仕組みと現代の独占企業への道のり
5章からは現代の独占企業へ成長するための方法や仕組みに触れています。 まずはそんな企業をどうデザインするか。そのためには
- 創造する
- 結びつける
- 消費する
- 対価を支払う
という「コア取引をいかにシンプルに提供するか」とその重要性を説いています。
そして6章ではそのコア取引を実現するためのプラットフォームの4つのコア機能について解説しています。 4つのコア機能とは
- オーディエンス構築
- マッチメーキング
- 中核的ツールとサービスの提供
- ルールと基準の設定
です。その方法と具体例を基に7章では、
"プラットフォーム運営者ではなく、生まれたネットワークやコミュニティーに仕事を任せる"
というプラットフォームビジネスならではの重要な観点について解説しています。
最後の8章ではここまで解説してきたプラットフォームたちを基に
「あなたならどうしますか？」「こんなチャンスがありますよ？」
といった自身のプラットフォームを構築することに対するヒントをくれています。
ここまで理解してきたプラットフォームビジネスをどう体現するかのはじめの1歩といったところでしょうか。
どんな人にオススメか
ここまで述べてきたようにこの本では
「サンプルを交えてプラットフォームの理解をし、自身のプラットフォームを構築する」
といったことがまとめられています。
そのため、この本は
- プラットフォームビジネスに興味があり理解を深めたい
- 自身で立ち上げたい
- プラットフォーム開発にアサインされた
- これからのビジネスモデルを学びたい
といったライト層から実務者まで幅広く学べるものだと思います。
ぜひ、手にとってプラットフォームについての理解を深める教科書として活用することをお勧めします。
プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか
- 作者: アレックス・モザド,ニコラス・L・ジョンソン,藤原朝子
- 出版社/メーカー: 英治出版
- 発売日: 2018/02/07
- メディア: 単行本
- この商品を含むブログ (2件) を見る
プロダクトを成功に導くための発注者の責務
今日はプロダクト開発における発注者について私の考えをまとめていこうと思います。
発注者って誰？
まず、この記事で指す"発注者"と言う言葉について定義しておきます。
一番意図している人としては"プロダクト開発におけるステークホルダー(組織)の現場担当者"といったところでしょうか。 つまり、下記のような人ではありません。
- 発注作業の事務的な手続きを行う担当者
- お財布を握っているステークホルダー(組織)の偉い人
- 依頼があり、開発を行うチームとそのPM
また、発注という言葉も定義しておきます。
プロダクト開発の手段として「社内開発」「外注開発」と二つあると思います。 もちろん細かく分けると「SESで自社に来て貰う」とか「パートナー企業と協業で」などありますが、大別すると上記2種類かなと思ってます。
この記事で指す"発注"とは上記どちらにおいても発生していると思っています。
具体的には
「"新しいサービスを立ち上げたい人"が"開発を担当する人(チーム)"に開発を依頼(一緒に行う場合も含む)を行う行為」
と定義したいと思います。
この記事を書く理由
というわけで内容に入っていこうと思いますが、 そもそも、"なぜこの記事を書くのか"についてお話ししておこうと思います。
私はサービス会社のエンジニア組織に所属しています。
私の所属する企業では"現場"と呼ばれるオペレーションを担当している部署や"営業"と呼ばれるセールスとマーケティングを行なっている部署があらゆるドメイン知識を持って日々のBtoBサービスの提供を行なっています。
そこに"技術"と呼ばれる区分の3つに大別され、"技術"という区分には"メンテナンス"、"基幹のインフラやIT整備"、"社内外向けサービス開発"の3種類の部署が存在します。
私が所属するのは"社内外向けサービス開発"を担当する部署で10名超が属しています。 主な業務としてはプロダクトの要件定義、開発、運用保守を行なっており、現在は40程度のプロダクトがアクティブな状態です。
これらの開発はリソースやサービスの性質、スケジュールに応じて"内製"と"外注"を選択しています。
私のポジションは主にプロダクトマネージメント、プロジェクトマネージメント、インフラ、セールスエンジニアを各プロダクトで担当しています。
内製の場合は複数人の開発者でチームを組成します。
一方で、外注の場合は開発の部署としてはほぼ一人で動きます。
エンジニア1名 + ドメイン知識を持つ非エンジニア(現場や営業)複数名 でプロジェクトを組成し、プロジェクトを開始します。
その過程の中で成功するプロジェクトと失敗するプロジェクトに、ある一定の"発注者が押さえないといけないステップ"が見えて来ました。 もちろん、弊社だけの理由であったり、私の考えが甘いことも多くあるのでお手柔らかに読んで欲しいものですが、自分の備忘録と一つの仮説という意味でまとめます。
また、その背景にあるものとして、"いくら優秀なエンジニアやPMがいても発注者次第でプロジェクトは失敗する"とも感じています。
プロジェクトの始めにやるべきこと
まずはプロジェクトの立ち上げに関してです。
プロジェクト立ち上げのきっかけは「自らの企画が通る」パターンや「指名を受けてプロジェクトメンバーになる」といった方法があると思います。 そして、自分以外のプロジェクトメンバーに関しても「自ら指名する」「すでに決まっている」というパターンがあると思います。
どちらにしろ、発注サイドのプロジェクトメンバーは少なくともこのような条件が必要だと思っています。
- 現状のフローを熟知している
- 解決したい課題を認識している
- プロジェクトに当てる時間を捻出できる
これら全ての条件を備えている人がいれば、申し分ないと思いますが、プロジェクトのスタート時は"個々人がどれか1つ以上の要素を満たしている"という状況で良いと思っています。そして、"プロジェクトメンバー全員が集まると上記3要素を満たしている"という状態になっていれば、プロジェクトメンバーの選定は成功だと私は思います。
よく
- プロジェクトに前向きで、やる気がある人
- コミュニケーション能力に長けている人
といった条件がマストと言われていたりもしますが、私はそうは思いません。
というか、全員がこれを満たすのは無理な場合がほとんどだと思います。
そもそも、ドメイン知識が豊富な人は忙しいものです。そんな状態でよくわからないプロジェクトにアサインされたら、最初はやる気が起きないのも当然だと思います。 さらに、現状の課題が「属人化、ブラックボックス化」というのもよく聞きます。 正直、積極的でコミュニケーション能力が高い人だったら、プロジェクト化する前にそんな状態を解決していることもあるのでは？と思ってしまいます。
一方で、「全然参加できない、コミュニケーションが取れない人とプロジェクトを進めてもうまくいくわけないじゃないか」と思うかもしれません。
その通りです。 あくまで、"プロジェクト開始時は"この状態で良いと思っています。
つまり、プロジェクトを進めていく中でこのような状態を変えていくことが必要です。
なので私は始めに「チームビルディング」と「プロジェクトの方向性を整える」ということをやります。
ただの人の群れをチームにする
チームビルディングでは「どんな価値観を持っているのか」「メンバーに対してどんな期待をしているのか」を可視化することにフォーカスします。
具体的には 「価値観ババ抜き」でチームメンバーの価値観を可視化します。
※ 価値観ババ抜きについては過去記事にて。 passionate-po.hatenablog.com
それぞれがどんな価値観を持っているかが見えてくると初めて一緒に仕事をする相手でも"目の前に座っている人がどんな人なのか"が少し見えてきます。
その後は「ドラッガー風エクササイズ」を行います。
※ ドラッガー風エクササイズについてはギルドワークス中村洋さんの記事を引用させていただきます。
チームメンバーの期待をあわせる「ドラッカー風エクササイズ」 | DevTab - 成長しつづけるデベロッパーのための情報タブロイド
これでプロジェクトにおけるお互いの期待をすり合わせます。 この2つのワークについては必ずどんな手を使ってでもチームメンバー全員に参加してもらいます。
ここに参加しないひとが出ると文化祭や体育祭に欠席した学生のように共通の経験がなくなり、その後のプロジェクトに大きな悪影響を及ぼします。
不思議なもので、上記2つのワークはしばらく経っても随所でプロジェクトメンバーの話題に上がります。そのため、それについていけないと仲間外れ感からプロジェクトに対するモチベーションが落ちるだけでなく、周りのメンバーもその人が何を考えているのかさっぱりわからなくなってしまい、孤立していきます。
そのプロジェクトは何者かを考える
次にプロジェクトそのものを紐解きます。というより、この段階では「なんとなくこれがあった方がいいからプロジェクト化したよ」みたいな状態の場合もあるので、プロジェクトの存在意義をチームで固めていきます。
これももちろん全員で行います。
具体的には「インセプションデッキ」を作ります。
※ インセプションデッキについては過去記事にて
インセプションデッキの中では特に
- 我々はなぜここにいるのか
- エレベーターピッチ
- やらないことリスト
- 夜も眠れない問題
を重視します。 プロジェクトメンバーとして集まった個々人がプロジェクトへのアサインを受けた時点で少なくとも自分なりの方向性やあるべき姿を考えます。 ただそれは必ずと言っていいほどズレています。
にも関わらず「みんな同じことを思っているはずだ」と考えていることが多いです。 そのため、方向性を揃えるためにも必ずこれをやることをお勧めします。騙されたと思ってやってみてください。
そのあとはエンジニアと非エンジニアでタスクを分けることが多いです。
非エンジニアチームには現状のフローをフローチャートにまとめてもらいます。 この時の基準は「(ドメイン知識のない)新入社員がこの仕事を理解するために必要なレベルで」というイメージです。 これが後の開発チームの業務理解につながる重要な資料になります。
そしてエンジニア(主に私一人ですが)はRFPを書きます。 機能要件については足繁く現場に通い、キーパーソンに聞きながら書きます。 そして一番重要なのが"その作業を実際に見せてもらう"ことです。
これがかなり重要です。
というのも、実際のオペレーターは当たり前になってしまっている作業もフラットな目線で見ると「なぜ？」という点が多くあります。 そこをとにかく拾い、質問をし、そうしなくてはいけない理由を明確にします。
これにより、現状のフローの課題の解決手段とフロー改善における制約をリストアップできます。
これをもとに機能要件をまとめます。 機能要件がまとまったらチームでレビューをします。
ここは時間がかかります。なぜなら、現場のオペレーターはフローがガラッと変わることに対する想像力が必要になるからです。 そのため、確認フェーズでは図や表を使ってあらゆる手段でイメージを伝えます。
そして並行して非機能要件(性能要件含む)、セキュリティー要件、運用保守要件、プロジェクト管理要件など残りの部分をまとめます。
これらはどちらかというと技術的な側面を中心に進めるので、スラスラと書けると思います。
例えば、開発言語やフレームワークの指定やセキュリティー要件は組織のルールや自分なりの閾値があるのでスラスラ書けます。 プロジェクトの進め方、会議体、ツールの指定なども同様でしょう。
とにかく細かく書きます。そしてその要件がどのくらいマストなのかも書きます。 よく使う言葉としては
- 〇〇とすること。
- 〇〇だと望ましい。
- 〇〇について提案を求む。
などを使ったりしています。
RFPが完成したあとは、いよいよ開発チーム候補の選定です。
まずは内製か外注かですが、これは
- リソース状況
- スケジュール
- スキル
などの状況で判断します。内製となればあとは開発チームを組成し、実際の開発に入っていきますが、この部分は多く語られているので、今回は割愛します。
外注の選定基準についても上記と同様ですが、それに加え、
- 自身が一緒に仕事をしたい人、会社
- 開発手法や技術レベル
という側面でいくつか知り合いの方々に当たったり、周りの人に聞いて紹介してもらったりしてます。
だいたい3~4社くらいに絞り、お声がけさせていただきます。
プロジェクトのビジョンを伝える
さて、お声がけさせていただいた開発チーム候補には
を行います。
RFPのみを配って説明をするパターンが多いと思いますが、私はそれだけでは不十分だと思います。 そもそも「外注先なので、細かいビジネスについて共有する必要はない。下請けだ！」と思っている方がいたら、私は全力で反対します。
なぜなら、自社のビジネスを一緒に作るパートナーとなってもらうチームです。 そのため、「どういうビジネスなのか。サービスなのか」、「どういう業界なのか」を理解した上で開発を進めていく必要があります。
そして、開発パートナーとなるチームにも期待したいこととして、
- ビジネスやサービスの成長を意識した提案
- 時にはこちらからの機能要件にも疑問をぶつけてもらう
といったことをお願いします。そして、それができることも選定の基準とさせてもらっています。
開発チームの選定
いよいよもって、提案をいただく流れになります。 提案については公平を期すため、提出期限、提案時間は同じにしています。
そして、選定方法は定量的な方法で行なっています。
具体的には比較表を作ります。 比較表では
- RFPに記載した各項目を1行ごとに記載
- 各項目に重みをつける
- 各社の提案に対しての評価を行う(3点：要望を超える提案、2点：要件通りの提案、1点：要件を一部実現する提案、0点：要件を全く満たしていない提案)
- 各評価に重みを掛け合わせる
- 総合点で比較
という手順で評価を行います。 これをもって開発パートナーとなるチームを選定します。
偉い人に納得してお財布を開いてもらうための責務
さて、プロジェクトチームで一緒に働きたい開発パートナーを選定したら、お財布や稟議のお話です。 お財布を握る偉いひとは「このプロジェクトがうまくいくのか」を心配しています。
その心配を安心に変えることもプロジェクトメンバーの責務です。 実は、そのための材料はこの時点で揃っているのです。
私はここまでに用意したアウトプットとして
を提出します。
そして、そのサマリーの説明をすることで、発注根拠を説明します。 こうして、公平な基準で根拠をもって選定したことを理解してもらい、気持ちよく発注をしてもらいます。
これにて、開発プロジェクトはスタートラインに立ちました。 いよいよスタートです。
開発のキックオフ
さて、開発パートナーも決まり、開発プロジェクトのスタートです。 まずはキックオフですが、私はここで主に下記を行います。
- 発注側のメンバーと役割の紹介
- 開発側のメンバーと役割の紹介
- プロジェクトビジョンの確認
- スケジュールと進め方の擦り合わせ
表向きはこんな感じです。 そして、できればこのキックオフを夕方めに設定します。 その理由は御察しの通り、そのまま懇親会に突入させるためです。
これが実はかなり重要です。
初めて一緒に仕事をする相手に対してこれからお互いがオブラートに包まず、本心を言い合わなくてはなりません。 そのためには心理的な距離感を縮めることが必要です。
これは現時点の私の解なので最適解が他にあるかもしれませんが、 まずは全員で飲みに行きます。
そして、雑談をし、お互いのバックボーンを知り、距離感を縮めつつ、尊敬の念を持てるようにします。
とにかくフランクに、とにかく仲良くなることを重視します。 お互い楽しく仕事をし、良いプロダクトを作るために"チームとプロダクトに愛着と期待"を感じてもらいます。
開発サイクルの管理
さて、無事にキックオフができたら、いよいよ開発です。 開発中の具体的なプラクティスや方法論はたくさん出回っており、かつもっと詳しい方も多いので、今回は割愛したいと思います。 いずれ私の考えも記事にしていこうと思います。
ただ、私の立ち居振る舞いとしては
- 開発PMと同じレベルで仕様を理解する
- 要件定義に思いっきり口出しをする。時にアドバイスをする
- 全てのやりとりを把握する
といったことを徹底します。
「あくまで発注者だから開発チームに全部任せないと内政を変わらない。外注する意味がないじゃないか。」という声があるかもしれません。
ただ、やはり自分たちのサービス、プロダクトへの責任を持つということ、また緊急時の対応判断を即座にできることを考えると私はこのスタイルが必要だと考えています。
プロジェクトの終了
プロジェクトも終盤、クロージングについてです。 そのタイミングでは運用開始を想定する必要があります。
具体的には
- ユーザー教育
- 拡販
- 広報
- 運用保守
などを検討する必要があります。 この時にプロジェクトメンバーにお願いすることがあります。 それは
「プロジェクトメンバー以外のユーザーがプロダクトにポジティブな印象を持つように接すること」
です。プロジェクトメンバー以外のユーザーは「新しいやり方だ自分の仕事の仕方を変えようとしている。めんどくさい。」 という印象から始まることが多いです。
そんなユーザーをプロダクトのファンにするのもプロジェクトメンバーの仕事です。 そのため、いかにポジティブな印象を持ってもらい、利用を促進するかがポイントになります。
次のフェーズに向けての準備
そしてプロジェクトが終了。チームも解散になります。 その前には必ず、「ふりかえり」をすることにしています。
これは、「プロダクトの今後の成長」「プロジェクトメンバーの成長」の2つの側面で非常に重要です。
プロダクトについては、次のフェーズに進むために一歩立ち止まって、改めてプロジェクトを俯瞰してみることで学びを得ることを目的にします。
プロジェクトメンバーについては、このプロジェクトにおける進め方、自分の立ち居振る舞いからの学びや次のプロジェクト、働き方についての気づきを持ってもらえると成功だと考えます。 そしてそれらをできるだけポジティブな形で終えること。それが開発プロジェクトに不慣れな現場や営業のプロジェクトメンバーの自信とプロダクトへの愛情へと変わります。
と、ここまでで「みんなの期待に応えるプロダクト」と「プロジェクトから学びを得て成長したメンバー」が揃っていることが私なりのプロジェクトの成功だと感じています。
まとめ
というわけで少々長くなってしまいましたが、私の思う発注者の責務を書いてきました。 改めてまとめると
- プロジェクトメンバーがお互いの価値観と自分への期待を知り、チームとなること
- プロジェクトの方向性、ビジョンを全員が共有すること
- 開発パートナーは下請けではない。未来を共に創るチームの一員と理解すること
- 細かいところまで定義する。ビジョンやビジネスも共有する
- 心理的距離を縮める。本音を言い合える仲になる
- プロジェクトメンバー以外にも自信を持ってプロダクトを伝える
- 「みんなの期待に応えるプロダクト」と「プロジェクトから学びを得て成長したメンバー」をゴールとする
といった点を私は重視しています。
「いやいや、この要素が足りないだろ」「これは違うだろ」という声もあると思います。 ぜひ、私もより一層学んでいきたいと思っていますので、是非ともコメントやSNSなどでご意見やご感想をいただければと思います。
2018年のふりかえりと2019年の挑戦
2018年も残りわずかとなりました。 ここで自分のふりかえりと、今見えている来年の挑戦について書いていこうと思います。
主に2018年はわたしの中で"働き方を大きく変えた年"でした。 昨年までのわたしは典型的なサラリーマンというか、
朝から仕事をし、終わらなかった仕事はダラダラと残業をしてかたずけ、自分の精神を摩耗させていながらも、自分の成長の鈍化に恐れを感じているような状態でした。
2018年は大きな出会いと衝撃が次から次へと訪れ、本業以外でのチャネルができ、そこでの活動やそれに伴う自分の成長を大きく感じた年でした。
特に大きな下記についてまずは振り返っていきたいと思います。
- プロダクトマネージャーとしてのお仕事。
- カイゼン・ジャーニー、DevLOVEとの出逢い
- スクラムとカイゼンを根付かせた話
- The Agile Guildでの新たな試みを行う仲間たち
- ブログメンターをしてもらいました！
- 結婚しました。
プロダクトマネージャーとしてのお仕事。
これは本業の話ですね。2018年1月から新たなプロダクト開発を行っていました。自社のVOD関連事業の現場効率化を行うプラットフォームで、自社内のみならず、顧客にもプロダクトのユーザーとして参加してもらうことで今までの受発注やプロセス管理の工程をカイゼンするプラットフォームです。
というわけで、プロジェクトメンバーは開発職はわたし一人。あとはVODの現場のリーダー職数人でのプロジェクトチームで、外部の開発パートナーと協力して進めたプロジェクトでした。
このプロジェクトは二つの挑戦をしました。
スクラム開発に関しては2017年10月くらいから興味を持ち、ジワジワと調べていました。そのため、開発パートナーの選定も「スクラムで行うこと」を前提に探しました。 もう一つの観点として、私の立場は外部のパートナーとの開発以外に内製開発も担当しています。そのため、自社の自チームでの内製開発にもスクラムを取り入れるために自信が学びたいという側面も多くありました。
そのため、私自身も
- Scrum Alliece認定プロダクトオーナーの取得
- ベトナムでのチームビルディングへの参加
などを中心に自身の知識を伸ばすこともしてきました。
はじめてのオフショア開発のため、ベトナムでのチームビルディングへの参加は多くの学びがありました。
「初めてスクラム開発を行うチームがどのように学び、どのように成長していくのか」 という観点で今後自身がが社内アジャイルコーチとして立ち居振舞うにあたり、どう動けばいいのかを見て学ばせてもらいました。
また、プロダクト開発という観点においても、拙い英語でではありますが、
- このプロダクトがどんなものなのか
- 配信市場はどういう状況なのか
- どんな課題を解決するのか
といったものを自分の言葉で自分の表現で、チームに話せたことがとても有益だったと感じています。 また、実際に顔を見て話せたこと。一緒に飲めたこと。ベトナムのカラオケで肩を組んで歌えたこと(Michel Jacksonとか)。中にはFacebookで友達になるメンバーもできたくらい仲良くなれたことはとても受発注の関係を超えたチームとしてスタートが切れたとても良い要因となりました。
ベトナムから帰り、実際のチームでのプロジェクト運営においてもいくつかの取り組み行いました。
今回のようなDevOpsそのものの案件は会社の性質上、割と多いものの、エンジニアと非エンジニアの組織の温度差や知識の差を埋めることができす、チームになり切れないパターンが多くありました。
そのため、チームビルディングは丁寧に行いました。 具体的には
- プロジェクト開始時に全員でインセプションデッキを作成
- 開発プロジェクトとマーケティングプロジェクトの両方を組成
- チームメンバーの増減時にインセプションデッキをリファクタリング
- スクラムとは？アジャイルとはという説明と共通理解の場の設置
- 節目でのふりかえり
プロダクト自体はこれからユーザー獲得フェーズに入ります。 B to Bサービスのため、母数は少ないものの、業界のデファクトスタンダードになるべく、1月からもいろんな施策を打っていこうと思っています。
カイゼン・ジャーニー、DevLOVEとの出逢い
前述の通り、昨年後半からスクラムの勉強を進めてきたわけですが、そんな折、2018年2月に今の私を作った大きな出来事がありました。
それは、 Developers Summit 2018の 市谷さん、新井さんの講演、そしてカイゼン・ジャーニーです。
DevSumi自体は毎年いってはいるものの、あくまで技術的な知識を得るためのものという位置付けで考えていました。 その中で偶然、「アジャイル・スクラム」という文脈でセッションを選んでいたところであったのがお二人のセッションでした。
その講演が私にとってはとても新鮮で、何より心を大きく揺さぶられました。
技術論という面よりも
といったまさしく「会社で誰もやったことがないこと」を一人で進めることが多い自分の状況とその話が重なりすぎていて、まさに灯台のようにその先の私の道をてらし、燃料を注いでもらっているような気持ちでした。
後にも先にも講演を聴きながら今すぐにでもアクションを起こしたいと思ったのはこの講演だけだった気がします。
講演後の私はカイゼン・ジャーニーを購入し、足早に「スピーカーズラウンジ」に行きました。 この時が市谷さん、新井さんとの初めての出会いです。
まさかこの1ヶ月後に「週に2~3回もこのお二人と一緒に活動したり打合せをしたり、飲んだりする」ことになるとは思いもしませんでした・・・。
そして目黒雅叙園を離れた翌日。 土曜日ながら、動かずにはいられず、いくつかの新しい試みを始めました。
まずはTwitterとこのブログの開設です。
それまではほぼほぼ、インプットばっかりだった自分を変えるため、また、自分の中での目標としている
「映像業界の働き方を変える」
ということの実現のためには、アウトプットの必要性を感じたことがいちばんの要因です。 そして、数ヶ月ご、数年後に自らが登壇して話しているビジョンが思い浮かび、そのためのログを残すこと、その機会をもらうためにはアウトプットを絶やさないことが必要だと感じました。
その時の投稿がこちら。
退路を絶って本気で頑張るために新規アカウント開設！
— はち (@PassionateHachi) 2018年2月18日
よろしくお願いいたします。
そんなこんなでアウトプットを続けていると奇跡のような展開が待っていました。
そして・・・
今思うと、断ることもできました。 そして、今までの自分だったら断っていたのかもと。
ただ、自分の活動にドライブをかけるために。なにより、「映像業界をチームで働く業界に変える」という目標に近づくためにと考えると自然とここに力を注げるようになりました。
それから、DevLOVEの運営としていろんなイベントの企画や登壇、ワークショップもやりました。 例えば・・・
ナビタイムさんの会場でこんな話をしたり・・・
www.slideshare.net
価値観ババ抜きのワークショップをやったり・・・(1月に第2回やります！)
ビブリオバトルやったり・・・
中でも反響が大きかったのは私なりの新卒社員の育て方についてでした。
www.slideshare.net
ふとした2月の出逢いから、ここまで成長できたのは他でもないこの活動があったからだと思います。
そして、この活動は私個人のものから、社内での活動へも繋がりました。
スクラムとカイゼンを根付かせた話
さて、上記のような社外でのコミュニティー活動や出逢いは何も自分の個人活動のみに還元されているわけではありません。 この経験が本業の自分の部署のみならず、他部署への貢献につながったことも今年の大きな収穫でした。
まずは、社内スクラム勉強会の開催です。
毎週月曜日に1.5時間もらい、スクラムについての勉強会を全6回で行いました。 この勉強会の特徴は、
- スクラムや開発に関わるのはエンジニアだけじゃないので営業も参加。
- 決して開発に特化した方法論にはしない
- 毎回座学とワークの2部構成
という点です。
- 座学だけだと飽きてしまう。
- エンジニア向けだと難しくなってしまう。
- プロダクトを育てるのはエンジニアだけじゃない
という点からこのような構成にしました。
ワークの内容としては
- マシュマロチャレンジ
- デリゲーションポーカー
- プランニングポーカー
- ドラッガー風エクササイズ
- 価値観ババ抜き
などを行いました。
その様子がこんな感じでした。
そして、この勉強会で終わらせてしまうと、あくまで部署内に留まってしまいます。
そのため、社内ナレッジシェアツールに「なぜ、このようなことが必要か」と方法を少しずつ書いていきました。
また、この勉強会を機に「まずは何かやってみよう！」という空気を作ることができました。
そこで部署で始まったのが、Daily Scrumとふりかえりです。
Daily Scrumでは
- 昨日やったこと
- 今日やること
- 困っていること
を中心に構成し、最後にはファイブフィンガーで気持ちを可視化しました。
ふりかえりは KPT-Aの方式をとり、 それまでに行われていた部署の定例会議のやり方を改善しました。
運営をして１ヶ月。 この活動が起動に乗ったと感じたもののこれによりどう感じているかのフィードバックのもらい方とチームのモチベーションを上げる方法を考えたいと思い、もう一つのワークを始めました。
これは月間MVPという名前で
1か月間の「ありがとう！」と思う行動を「誰 to 誰さん。〇〇してくれてありがとう」という形式で付箋に書き出し、 みんなの前で顔を見て感謝を伝えます。そして、全て出揃った中から、最も素晴らしいものに1人1票、シールでドット投票するというものです。
これはとても効果が大きく、
翌週のふりかえりのKeepに
「MVPもらったことでモチベーションが振り切ってます！！」と書いてくれるメンバーがいたり、 「朝会のおかげで、体調不良や困りごとが言いやすい雰囲気でとても嬉しいです。」
という言葉をもらいました。
このような私の部署でのカイゼンも社内ナレッジシェアに書き込むこと、それを社内SNSに発信することを始めました。 すると、私の活動は次第に口コミで広がり・・・
- 「ぜひ教えてくれ！」
- 「うちでもやってくれ！」
- 「相談がある！」
と他の部署か声がかかるようになりました。
そこから生まれたのが、「こそ勉Lab.」という社内勉強会です。
この活動は主に休日、有志で集まって行う勉強会として立ち上げ、これまで半年で5回の開催ができました。
今では運営メンバーも10人を超え、来年1発目のイベントは自社のみならず、親会社やグループ会社まで活動が広がることが決まりました。 じわじわとではありますが、こういった形で業界に勉強会の流れを根付かせることができそうな雰囲気が出てきました。
また、業務においてもカイゼンの流れを大きく変えるきっかけがありました。 それはヴァル研究所さんへの見学です。
これはひとえに新井さんとの出会いがなければ生まれなかった経験で、自分の部署以外に活動が広がった大きなトリガーになりました。
見学は半年間待ってやっと順番が回ってきた上に限定10人ということもあり、この機会は絶対に逃せないものでした。 そのため、私は人選に力を注ぎました。
まずは、1人目のメンバーとして巻き込んだのが社長です。
ある日、社長室のドアをノックし、(エレベーターピッチ並みの)プレゼンを行い、社長の理解を得ることができました。 そして、社長と一緒に残りのメンバーの人選を行いました。
その結果、納会でしか集まれないような自社のエースを集めることができました。 具体的には・・・
映画、TV(2拠点)、VOD、業務管理、総務、CM、R&Dのマネージャー陣。
弊社のアベンジャーズのような存在です。
そのおかげで、各部署で強粘着の付箋やカンバンが日常の風景になり始めてきました。
来年はさらにまだ届いていない部門へこの波をたどり着かせること、そして、より高次元で社内改善が進むようにしていこうと思います。
The Agile Guildでの新たな試みを行う仲間たち
そして私のもう一つの活動が The Agile Guildです。
ここには、本業とは別に
- 自分の能力で試したい
- 世の中の課題を解決したい
- 貢献したい
- 能力を伸ばしたい
と純粋に思っている人々が平日の日中、夜、休日問わず、自分の時間をつぎ込んで集まっています。
そこには会社や組合などのしがらみから解放され、純粋に世界を変えようとしている人たちが100人以上存在します。 主に私はこの組織で
自分にも会社にも足りないと思っている「仮説検証」の分野で関わらせていただいています。
ここでの活動は企業に属していたら当然になってしまっている常識を良い意味で考慮しなくていい状況や、政治や大人の事業に引っ張られることなく、開発の力で課題を解決していくことができる環境が整い始めています。
ここでの活動はいつも私に新しい視点と側面をもたらしてくれており、ワクワク感と「できないことなんて実はあまりない」ということを思わせてくれています。
ブログメンターをしてもらいました！
10月より、カックさんにブログメンターをしていただきました。 おかげで、ブログを書くことの習慣化や記事以外のコンテンツの有効性などたくさんのことを教わりました。
前述の通り、私の目標を達成するためにはアウトプットは1,2を争う重要な取り組みです。 私の中で次のステージに進むために必要な、モチベーションの源泉に命の水を湧かせることができそうです。
結婚しました。
今年の出来事の最後は結婚です。 今年の6月に2年付き合った彼女と結婚しました。
このブログはきっと嫁は見ないだろうと思うので、照れ臭いことも書いていこうかと。
彼女は「ピアノを弾くこと」を生業としている人です。 そのため、プロとしてのものの見方や感性、考え方を持っていて、日々刺激を受けています。
そのため、いろんな部分でぶつかることは出てきつつも、そういった気持ちのぶつけ合いができる状況と最後には仲直りができる環境にとても心理的安全性を感じています。
ご存知の通り、夜の打合せやイベントなどで平日はほぼ毎日外食。そして夜も終電前後の私に対しても、それを許してくれるどころか、笑いに変えつつ、心配をしてくれる姿は感謝をしても仕切れません。
彼女と過ごす毎日がなければ、私自身のモチベーションは保てないし、前に進めないと日々感じています。
2019年、新たな挑戦。
2018年はこれらの活動から社会人7年目にして、最も濃厚な日々を送れました。 特に、平日の夜、休日時間の使い方が変わったことにより、1日の時間が24時間から48時間くらいに増えた感覚が強いです。 逆に言うと、今までの私の生活は24時間をフルに使えておらず、"時間"と言う限られた資源を無駄遣いしていたと痛感しています。
そして来年はこれらを加速度的にドライブをかけることのみならず、新たな出逢いが見えてきました。 最後にその4つのチャネルについて紹介してこの長文記事を終わろうと思います。
1/26(土) Backlog World 2019
まずは、2019年最初の登壇が決まりました。nulabさんのBacklogのユーザーグループであるjbugさん主催のBacklog world 2019です。
こちらの公募セッションに申し込んだところ、大変ありがたいことに6枠の公募セッション枠の一つに選んでいただきました。
ここで私がお話ししようと思っているのは、
そのため、プロジェクト管理ツールの導入とタスクの可視化を目的にこの半年で行った10の取り組みについてです。 2018年の私の活動は数々の方々との出会いに支えられたものであり、私自身は何の特殊な人間でもありません。
私の取り組みを惜しみなくお伝えし、DevSumiで私が勇気付けられ、1歩を踏み出せたように、聞いてくださる方が1歩踏み出せるような方法とマインドセットについてお話ししようと思います。
メディアエンジニア勉強会
そして同じく1月に始めようと考えているのが"映像業界のエンジニア向け勉強会の定期実施"です。 映像業界は数年前まではビデオ信号や放送機器の技術と言うIT業界とは全く別の技術が必要な業界でした。
近年ではこれだけではなく、ネットワーク速度の普及により、IT業界と変わらない技術が必要となってきました。
一方で、扱っているデータの容量は数TB~数PBが当たり前であり、放送機器との連携が必須です。
そのため、IT技術のみ持っているエンジニアも、映像技術のみ持っているエンジニアもまるで歯が立ちません。
しかしながら、閉塞された環境の中、お互いに知識を共有する場が限定的なのが事実です。 また、映像に参入し始めたIT企業が勉強会の場を提供しても「だれ？」と言う状態で誰も集まらない業界でもあります。
そんな状況を打破するためには業界のリーディングカンパニーが旗を振ることしか方法はなく、そのポジションは自社であり、私が切り開くべきだと自負しています。
そのため、来年の活動の主軸のひとつとして力を入れようと思っています。
ファシリテーション塾
そして、もう一つがまだ未確定ではありますが、"ファシリテーション塾"です。 これは私のスキルの向上、場づくりに対する理解と体現をより確実なものにするために個人の活動として参加を申し込んだものです。
プロダクト、プロジェクト、チームなど、人が集まるところにはファシリテーションが必要です。 それは「会の議事を進行する」ことではなく「場を作り、デザインすること」だと思っています。
そういった観点では自分はその時のメンバーによって精度がマチマチになっていたり、苦手意識を持ってしまうこともあります。 そんな自分のスキルを上げるためと言う点が動機の一つです。
もう一つの動機は、「ファシリテーターのための場づくり」です。
ファシリテーターは意図して自分がなる場合と、いつの間にか自分がやらざるを得ない場合があると感じています。
と言うのは社内会議など然り、
どうしたらいいのか分からないけど、言い出した手前、もしくは指名された手前、自分が進行しなくてはいけない
と言う状況です。
こういった状況でファシリテーションをしている場をよく見かけることもあり、そんな状況を生み出さないためにも ファシリテーションの重要性や必要な考え方などを伝えることができればと思っています。
そのため、ファシリテーターをサポートできるスキルやマインドセットを得たいと考えています。
最後に
ふとFacebookを見直してみました。 今年友達になった方が合計で125人でした。
日々感じるのは私の成長と新たな挑戦ができるのはいろんな方との出会いのおかげだと思っています。
みなさんからの応援であったり、機会をもらったり、声をかけていただくことがなければ、自分の目標は何一つ達成できていないと思います。
2019年はより一層の貢献ができるよう速度を上げていこうと思います。
私の活動や行動、言動に何かしら感じていただけたら、ぜひお声かけいただきたいです。 いろんな機械に対し、120%で答えられるように頑張っていきます。
来年も引き続き、よろしくお願いします！
【読書感想】初めてのカスタマージャーニーマップワークショップ
さて、今日は書評エントリーです。
今回はこの本。
はじめてのカスタマージャーニーマップワークショップ(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で動いてたら、そのスナップショットから作成してみるとはじめやすいかも。
