マーケティングもアジャイルに ~スクラムチームで開発もマーケティングも進めてみた~

Team on Air 開発チームの @okamomo と申します。

スクラムのエッセンスを取り入れたチームでプロダクトの開発を続けて 2 年目に突入しました。チームメンバーは 3 人。開発以外のことも基本的にはすべて 3 人で進めていかなくてはなりません。

MVP が見え始めた頃、テストユーザーを集めるためマーケティング活動を始めました。チームで初めてのマーケティング活動は思った以上に仕事量が多く、属人化しチーム内で不透明になっていきました。どうしたら開発もマーケティングもチームで取り組み続けられるだろう…と悩んでいた中で、開発もマーケティングも一緒にスクラムの中で取り組めないかとチームで思い至りました。

私自身はまだまだマーケティング活動をしている身としては未熟ですが、実際にマーケティング活動に携わっていく中で、マーケティングが開発と密接に関わるものだということを肌で感じています。手探りではありますが、開発もマーケティングも一緒にスクラムの中で取り組んでいくことで私が体験した課題やそれに対しての工夫についてお話できたらと思っています。
 
 

Outline/Structure of the Talk

  • 背景
    • チームの体制
    • スプリントの進め方
    • チームの状況
  • 課題
    • マーケティング活動の管理の難しさ
    • マーケティング活動の共有の難しさ
  • 実践
    • スクラムでのマーケティング活動の取り組み方
  • 実践した上での新たな課題
    • チーム外の影響を受けるタスクの扱い方
    • ストーリーポイントの付け方
  • 課題に対しての工夫
    • 検討中(いろいろ試してみている最中です)

Learning Outcome

スクラムチームで開発と開発以外の領域に対して一緒に取り組んだ際の課題や解決策の共有

Target Audience

スクラムを実践しているチーム、開発をしながらトラクション獲得を目指しているチーム

schedule Submitted 1 year ago

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / Kenta Sasa - THE GENKI 2022 - 「元気」を解き明かす -

    45 Mins
    Talk
    Beginner

    .002.jpeg

    「あの人はなぜいつも元気に見えるんだろう?」
    「あの人はどういう経験を経ていまのスタイルになったんだろうか」
    「あの人の原動力はどこから来ているんだろう」
    「あの人が凹むときはあるんだろうか」

    と思ったことはありませんか?

    プロダクト開発に携わっていると、日々さまざまな壁にぶちあたります。

    考えの合わないチームメンバー、高圧的な上司、非協力的なステークホルダー、お通夜のようなふりかえり、フィードバックのないスプリントレビュー、重厚長大な組織の壁・・・

    思わず「うっ」と歩みを止めたくなってしまうこともあるでしょう。

    一方で、カンファレンスで登壇している人たちを見ていると、たとえどんな壁にぶつかったとしてもへこたれず、考え続け、行動し続けているように見えます。そして人は彼らを指して『元気だよね』と言います。

    ここには、最強の元気しかいない

    スピーカー2人の共通点は、人から『元気だよね』とよく言われることです。
    ところが、本人たちは自分たちのことをとりわけ元気だと自覚しているわけではありません。

    では元気とは何なのでしょうか?
    ここでいう元気とは、性格や活動的である状態を指すものではなく、他者からの相対評価です。

    同じような状況に面しても、人によってまったく違うアウトプット(行動、言葉)になります。このアウトプットを他者が見て、その人のことを元気だと感じているのです。

    つまり、元気に見える人のメンタルモデルを解き明かすことで、元気とは何なのかの答えが見えてくるかもしれません。そして、メンタルモデルは理解することで自分にインストールすることができるかもしれません。

    本セッションでは、スクラム界最強の元気たちが見ている世界を覗いてみる実験をします。最強の元気同士が、お互いにインタビューし合うことでお互いの思考、メンタルモデルを探ります。

    一緒に元気を解き明かしましょう!

  • Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - 受託開発受注のためのちょっとしたコツ 〜「何でもかんでもやります」じゃなく、まずはデモ〜

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    Hololab
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    私が所属しているチームは、結成されてからこれまでの間に経験してきた開発は、受託開発(部署または会社の外から欲しいソフトウェアの要望が来ることから始まる開発)が少なくありませんでした。その要望を出す人たちは、ソフトウェア開発の経験や知識が無い方々が殆どでした。しかし、その人達が予算を持っており、開発を誰に依頼するのかを決める決定権を持っています。そのため、その人達にとって、もちろん開発したプロダクトのユーザーにとって魅力的でなければいけません。そのために我々は最初のデモを重要視しています。常に受注を続けてこられたわけではありませんが、受注につながったのではないかと思える実感を得られるやり方が見えてきたような気がしています。そこで、このセッションでは、そのやり方を直近で携わっているプロジェクトを例に紹介したいと思います。

     

     

  • Kazutaka Matsusaki
    keyboard_arrow_down

    Kazutaka Matsusaki / Ayaka Ikeda - 良い活動を追いかけてたら自然とスクラムになってた

    20 Mins
    Talk
    Beginner

    スクラムマスターのトレーニングを完了した直後にスクラムマスターがハマる罠。
    その一つに、トレーニングで得た知識をそのままチームに適用する!というものがあるのではないでしょうか?
    知識の押し付けですね。

    私も初めてスクラムマスターに挑戦したとき、思いっきり失敗しましたw
    トレーニングでこう教わったからこうなんです!!!
    あぁ、恥ずかしい…

    月日は経ち1年半後、新チームの立ち上げに関わることに。

    初挑戦の失敗と、それまでの経験を活かして取り組むことを心に誓い臨んだチーム作り。どのように取り組んだのでしょう?

    知識の押し付けで失敗した初挑戦。
    それなら、知識は教えない!教えるにしても最小限。

    体験を最大限に活かす!

    開発者にスクラム経験者が1人いたものの、はたして教えるより体験重視の方針で上手くいくのでしょうか?

    チーム開始時点でのスクラムの意識はこれくらい。

    • スクラムのイベントは全部やってみよう
    • スクラムの作成物は全部作ってみよう


    各イベントと各作成物の概要だけ伝えて、いざスタート!

    当然のことながらスタート時点ではイベントをこなすだけ、プロダクトを作るだけ、とりあえずやってみてます!の活動が続きます。

    そんなチームですが、
    チームで良い活動をしていこう!
    良いプロダクトを作っていこう!
    そんな気持ちは持っています。
    ふりかえりも真剣にしています。

    真剣に取り組んでいるので、
    ふりかえりで、課題がどんどん出てくる。
    出てきたものを少しずつ改善していく。
    上辺の改善だけではダメだと気づき、意味を考えるようになる。

    形だけで始めたスクラムが、いつの間にか、

    スクラムの良さに気づき

    チームで取り組んでいる状態に。

     

    本セッションでは、2年間毎日書き留めたチームの活動記録とふりかえりを元に、チームがどう変わっていったのか、チームメンバーの視点を中心にお話します。
    スクラムマスターとしてどう関与していったのか、ちょっぴり入れられればなとも目論んでいます。

  • Tomonari Nakamura ( ikikko )
    keyboard_arrow_down

    Tomonari Nakamura ( ikikko ) - スクラムマスターの頭の中:あのときスクラムマスターは何を考えていたのか?

    45 Mins
    Talk
    Intermediate

    スクラムマスターとして活動されている皆さん。皆さんの中には、自分が話す内容が、チームメンバーにうまく届いていないなあと感じた経験はありませんか?

    スクラムマスターは、他のメンバーと少し違った視点で考えることも多く、前提知識の有無も含めて、なかなか理解・共感を得づらい場面もあります。

    その場合、いきなり本題について話すのではなく、1クッション入れるのが効果的です。本題に至った思考の過程や前提知識を共有する場があると、よりメンバーからの理解や共感を得やすくなります。また、副次的な効果として、共有のために言語化する中で自分の考えを整理でき、後のふりかえりにも流用できるようになります。

    本発表では、チームメンバーにスクラムマスターの頭の中を共有しながら、チーム・プロセスに関する取り組みを推し進めていった例を紹介します。月1ペースでLT発表する場を通じて、「どういう状況下で」「どういう課題を感じていて」「どのような前提を共有しつつ」「どういった取り組みを進めて」「結果どうなったか」を、いくつかのケースに応じてお伝えします。

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - Beyond Budgeting 脱予算経営 ~ Agile 2014 キーノートを再訪する

    45 Mins
    Talk
    Intermediate

    企業運営をアジャイルにする、という文脈でよく語られる、「Beyond Budgeting」(脱予算経営) というのをご存じでしょうか。多くの企業で一般的な年次予算(もしくは半期、四半期)の管理方法を見直して、よりダイナミックに、各現場に任せる形で企業内の資金を運営していこう、という取り組みです。2000年代に北欧の銀行などで取り組まれ、BBRT (Beyond Budgeting Round Table) というコミュニティがその普及啓蒙を担っています。

    毎年米国で行われている Agile Conference では、2014年にImplementing Beyond Budgeting (日本語訳: 脱予算経営への挑戦)著者の Bjarte Bogsnes 氏をクロージングキーノートに招聘して、話を聞いています(講演ビデオ)。彼は企業会計の専門家であり、石油掘削ベンチャーのStatoil社の企業会計に携わっています。その講演では、Statoil社での実践を中心に、アジャイルの時代の経営のイノベーションについて話しています。また、BBRTが公開している、12の原則についても紹介しています。

    私は、2022年8月に、Joe Justice氏のアジャイルハードウェア開発の研修に参加したのですが、テスラ社やSpaceX社が行っている脱予算経営について、紹介してくれました。その際に、日本ではあまり脱予算経営が紹介されていないと感じましたので、本セッションを思い立ちました。予算管理というと、スクラムの現場からはちょっと遠い話と思われるかもしれませんが、「予算を申請する」「苦労して上司を説得する」「上司も苦労して経営陣を説得している」という作業にはほとんどの人が携わっていると思います。このやり方を根本的にシンプルにしましょうという考え方で、私たちの日々の活動について、一考を促すものだと思います。特に小さな企業は、既存の大企業の予算システムマネしてもアジャイルにはなれません。

    本セッションでは、Agile 2014  での Bjarte 氏の講演をなるべくそのまま紹介しながら、必要な補足をしていきます。脱予算経営について、一緒に勉強してみませんか?

     

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano / Ami Shiratori / Atusuke Muratra / Masaharu Tashiro / XiaoQi Zhang - 【やってみた】スクラムチームを超生産的にするためのパタン・ランゲージ

    45 Mins
    Talk
    Beginner

    スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” では、ハイパープロダクティブ(超生産的)チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。

    各パタンの概要はこちらの記事で紹介しました。
    スクラムチームを超生産的にするためのパタン・ランゲージ|天野 祐介 (ama_ch)|note

    筆者の所属するサイボウズでは、当時「フロントエンドリアーキテクチャプロジェクト(通称フロリア)」というフロントエンド刷新プロジェクトを立ち上げたところだったので、こちらのパタン・ランゲージを紹介し、各チームのスクラムマスターと協力してパタンを実践してみました。

    プロジェクトの概要やチーム体制は下記の記事で解説しています。

    本セッションでは、9個のパタンを紹介した後、実践したチームのスクラムマスター達と対話し、複数チームで実践し得られた知見を共有したいと思います。

  • Sae Iidaka
    keyboard_arrow_down

    Sae Iidaka - 新米リーダーのチームビルディングからの学び〜泥臭くて何が悪い〜

    45 Mins
    Talk
    Beginner
    • Teams会議で呼びかけても反応がない・・・!みんな聞いているのかな・・・?
    • こんな調子でチームのパフォーマンスは良くなるのだろうか?
    • 直接会ったことのないメンバー同士がどうしたらポジティブに動けるだろうか?

    皆さんはリモートワーク下でのチームビルディング、どのように乗り越えましたか?
    それぞれの個性が見えづらく、自分の想いも伝えづらい。私は相当苦戦しました。

    申し遅れましたが、現在リクルート様の採用管理サービス「Airワーク 採用管理」の開発チームで
    マネジメント業務をしております、イイダカです!
    昨年度漠然とした課題感を抱えるフロントエンドチームに飛び込み、改善活動を行いました。

    飛び込んだチームは、プロダクトの忙しさやメンバー交代などから、日々メンバーに対して答えを与えがちになり、
    メンバーの主体性を育てることができず、チームのスキルアップに繋げられないという状態から抜け出せなくなっていました。

    そんなチームをなんとか負の連鎖から抜け出し、自走できるチームにしていきたい。
    皆さんだったらどのようにこのチームを変えていきますか?

    トップダウンのやり方もあるでしょう。でも、私は全員に考えを吸収してほしいんです・・・!
    全員にマインドを吸収してもらう選択をとり、同じ目線で協力し合える関係性を築きました。

    私は自身の経験から、チームづくり・改善活動には、メンバーの納得・協力が絶対であると考えております。
    正直に現状を共有し、どういった意図でどういうチームを目指していきたいかを説明し、共通認識を持ってもらうところから始めていきました。
    そこからはまるで小姑のような泥臭行動の連続・・・

    本編ではより詳しく、リーダー依存脱却・新たなチーム文化の醸成にどのように繋げていったか、
    考えたこと・工夫ポイントを交えながら、新米の私だからこそできた泥臭奮闘記をお伝えします!

    皆さんがどこか懐かしい気持ちになり、良い刺激を与えられたら幸いです。

     

  • Miyuki Yamada
    keyboard_arrow_down

    Miyuki Yamada - スクラムから離脱した末端社員のスクラムマスターが社長に「Joy,Inc化しよう」と言ってみた話

    Miyuki Yamada
    Miyuki Yamada
    なし
    BIPROGY株式会社
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムマスターのロールを学び続けることは、スクラムを離れてもこれからの時代に求められるチームビルディングにつながっている

    1. スクラムとの出会いと学び
    2. スクラムは人生そのものと思った翌月にスクラム終了した話
    3. 2年ほどチームと共に育つことを支えたくれた人と言葉
    4. アジャイルジャパンの安田さん講演からの社長に「Joy,Inc化しよう」と言ってみた話
    5. 今~スクラムからは離脱しているけどチームビルディングと所属組織の変容に口出しする末端社員になった話
  • Muneyuki Okamoto
    keyboard_arrow_down

    Muneyuki Okamoto - スクラムのエッセンスを実践してみたら、キャリアと人生の可能性が広がった〜鍵は勇気と出逢いと経験主義にあり〜

    20 Mins
    Talk
    Beginner

    確約・集中・公開・尊敬・勇気、これら5つのスクラムの価値は何もアジャイル開発の現場に留まるわけではございません。スクラムの考えを実践することは、エンジニアであっても非エンジニアであっても、キャリアの形成や人生に大きく寄与する可能性を秘めております。

    非エンジニアであり、人材育成・組織開発に関わる企業の経営者として、自身のキャリアを少しふりかえりながら、スクラムの価値基準がどのように人生に寄与したかをお伝えしたいと思います。

    学びのポイントとして、「勇気を出して自身の目で一次情報として経験する(もちろんオンラインもOK)こと」です。どこかで誰かが話していたことを又聞きしたり評論したりするのではなく、現地・現物を大切にすることで、きっと見えてくる世界があると信じております。

    そして経験したことは、せっかくなのでふりかえってみましょう。ポイントは一人でふりかえる内省だけでなく、仲間と一緒にふりかえってみることです。経験したことを仲間にオープンにすることで、きっと何かフィードバックを得られ、新たな気づきや学びに繋がるはずです!

    本セッションでは、ふりかえって見たらスクラムの価値基準をもとにアレやコレやを個人や組織レベルで実践してきた経験を元に、皆さんのキャリアや人生がほんのちょっとでも豊かになるためのTipsをお伝えしたいと思います。

  • Satoshi Harada
    keyboard_arrow_down

    Satoshi Harada - Back to the basic of Scrum - スクラムの"価値基準"を再考する

    45 Mins
    Talk
    Intermediate

    「スクラムとはどういったものですか?」

    そう聞かれたら、あなたはどう答えますか?

    そのような質問があれば、おおよそ以下のようなスクラムのロールやイベントや成果物をベースに、スクラムの特徴を説明するのではないかと思います。

    • 開発者、プロダクトオーナー、スクラムマスターというロールがあるんだよ
    • スプリントという短い期間で開発を区切って、繰り返していくんだよ
    • プランニング、デイリースクラム、スプリントレビュー、レトロスペクティブといったイベントがあるんだよ
    • プロダクトバックログやスプリントバックログといった成果物があるんだよ

    しかし、スクラムのフレームワークを長年利用していて親しみがある人でも、スクラムの"価値基準"をベースにスクラムを説明しようという人は少ないように見えます。

    スクラムの"価値基準"とは、以下の5つです。

    • 確約(Commitment)
    • 集中(Focus)
    • 公開(Openness)
    • 尊敬(Respect)
    • 勇気(Courage)

    これら5つの価値基準はスクラムガイドでも明示されているのですが、それぞれの内容が何を意味しているのか・なぜスクラムの成功を左右するのかまでは踏み込んで説明されていません。

    しかし、スクラムの"価値基準"はスクラムが成功するかどうかの重要なものであること、そしてスクラムの"価値基準"が具現化できていなければスクラムを支える「透明性」「検査」「適応」がハリボテになりかねないということも、スクラムガイドは示唆しています。

     

    このセッションでは、Back to the basic of Scrum(スクラムの基本に立ち戻る)と称して、スクラムの根幹を支えるスクラムの"価値基準"についてふりかえってみようと思います。

    スクラムガイドでは踏み込んで紹介されていない5つの価値基準ですが、XP(エクストリーム・プログラミング)と組み合わせて考えることで、これらの価値基準が何を意図しているのか・なぜ大事なのか・なぜスクラムの成功に関わるのかが見えてくると考えています。

  • Toshiharu Akimoto
    keyboard_arrow_down

    Toshiharu Akimoto - カルチュラルインテリジェンス(CQ) から価値観の違いを紐解く、人と組織、部署間の関係性の橋かけ

    Toshiharu Akimoto
    Toshiharu Akimoto
    Coach / Catalyst
    Kumu Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    「カルチュラル・インテリジェンス」(CQ)とは、文化の違いを超えて円滑にコミュニケーションを図る能力のことです。文化の違いと聞くと国や宗教のような大きなものを想像しがちですが、組織にも、部署にも、チームにも、そしてひとりひとりの個人にも文化的背景はありますよね?

    知らず知らずに考えたり、当たり前に行動しているその価値観。根幹には、本当はもっと多くの次元の価値観の軸があるのではないでしょうか?

    ここでは手始めにCQで語られるホフステードの6次元モデルを参考に、CQとは何かのざっくりとした説明と、どのように使っていくといいのかをみんなで一緒に考えてみたいと思います。

    https://speakerdeck.com/spring_aki/cq-introduction?slide=2

  • Imai Takaaki
    keyboard_arrow_down

    Imai Takaaki - チームが力を発揮するために!スクラム的な「計画」で実現する高解像度なスプリント

    20 Mins
    Talk
    Intermediate

    「着手したプロダクトバックログアイテムがスプリント中に終わらない!」

    「柔軟さを失わないためにどこまで細かく計画したらいいのかわからない!」

     

    みたいなこと、結構あるんじゃないかと思います。

     

    いざ開発!と着手してみたプロダクトバックログアイテムの検討が不十分で、ステークホルダへの確認がボトルネックになったり、スプリントの後半になってから認識違いが発覚したり。

    そもそもやってみないと絶対に終わるかなんてわからないし、終わらせるために入念な計画を練っても、結局想定外のことが起きて計画通りいかないことがほとんどです。

    もっと悪い場合だと、知らず知らずのうちに計画に囚われて、本当に実現したかったゴールを見失ってしまうなんてこともあるかも・・・。

     

    私たちのチームが過去の開発を積み重ねて現状たどり着いている一つの答えは、「常に計画し続けること」!
    スプリントという限られた時間の中で何かしらの価値を出していくには、チームが自分たちの状況を常に把握して、状況に適応していくことが求められます。
    それはスプリントの中で開発が始まってからも同じです!

     

    「計画し続ける」を実現するための”現状の把握”と"状況への適応"とはどういうことなのか、チームの具体的な取り組みを交えてお話しします!

  • Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka - メンター:チームの外からあなたを助け、組織の持続可能な状態を助けるスクラムマスター

    20 Mins
    Talk
    Intermediate

    RSGT2021 ZuziさんのKEYNOTEから一年半。
    レベル2・3のスクラムマスターとはなんだろう、と
    自分なりに模索しながら組織開発と向き合ってきた。

    その中でも、一年ほど継続してきて、幸いなことに良いフィードバックをいただけている活動がある。
    メンターだ。
    ここでのメンターは、「会社の中で異なる部署・チームの人と、フラットな関係でありながらその人がより活躍できることを応援する役割」と定義する。

    元々は入社された方向けのオンボーディング支援活動として取り入れられたメンター制度だったが、
    さまざまな部署のお相手の方(メンティー)たちと継続的な関係を築けたことによって、大きな変化が生まれている。
    特に感じるのは、1年ほど経つとアジャイルの話ができるようになっていることだ。

    このセッションでは、

    • 「この制度、もっと広まった方がいいですよ!」と言われた
    • 「この時間があるから1年続けられたかもしれません」と言われた
    • 一年前のメモをメンティーさんと眺めてみて「今は少しは成長できたのかな、と感じました」と分かち合うことができた

    といった、スクラムマスターの心を持って業務や役割が異なるチームの外の人とお話しするとどんなことが起こるのか・起きたのかを話す。
    直属の上司との1on1などと異なる点も実体験を元に併せて紹介したい。

    また、目の前の頑張る人を応援したいと願う思いが芽生えた状態で
    PEP TALKに出会った。

    知り合いが開催するようだし面白そうだな、程度の気持ちで参加したセミナーでとてつもなく大きな衝撃を受け、
    実際に自分も研修に通うようになった。

    いざ実践してみると、日は浅いが効果や変化が(メンター以外の場面やメールなども含む)普段のコミュニケーションで感じられているほどである。

    今後のメンターやスクラムマスターの活動をする上で切り離すことができない要素になると確信した
    PEP TALKについても紹介させていただきたい。

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi / Iwao Harada / Kenta Sasa / Tsutomu Yasui - Global Day of Coderetreat 2022 in Sapporo

    105 Mins
    Workshop
    Beginner

    Global Day of Coderetreat は、仕事を離れて、ソフトウェア開発と設計を練習するイベントです。無料で参加できます。美味しいランチとおやつが付いてます。きっと、忘れていたプログラミングの楽しさを思い出す機会となるでしょう。

    自称プログラマーであれば、言語や経験、年齢、性別は問いません。学びを楽しむ気持ちだけは、忘れずに持ってきてください。
  • Youichi Takigawa
    keyboard_arrow_down

    Youichi Takigawa - コミュニティイベント運営のコツ、教えます。秘伝のソースはプロジェクトマネジメントのノウハウを煮詰めて出来ている

    20 Mins
    Talk
    Advanced

    コロナ禍でオンラインイベントという選択肢が新しく増え、主催側も参加者側もより気軽にIT勉強会やコミュニティイベントにタッチできるようになりました。アジャイル界隈においては、本イベント:スクラムフェス札幌に代表されるように全国各地でRSGTの文脈を継いだイベントが開催されるようになってきています。

    イベントの花形は何と言っても登壇者です。壇上に立ち堂々と語る登壇者のその姿は、経験のない人が見るとまるでキラキラと輝いて見えます。いつかあの煌めくステージに立ちたい、と思う人も少なからずいらっしゃるでしょう。

    ですが、イベントは登壇者だけでは成り立ちません。企画段階から地道な準備を続け、当日もこまごまとイベントを滞りなく進められるよう動き回る裏方スタッフ、大きなイベントに限りますが、イベント主旨に共感し決して安くない金額を提供してくださるスポンサー企業、なによりイベントを盛り上げてくれる参加者、それらすべてがイベントを成功させるのには不可欠です。

    今回のセッションでは、あまりフォーカスの当たらないイベントの裏方スタッフのお話をさせていただきます。

    筆者は登壇者としては2012年にDevLOVEというコミュニティで初めて社外登壇を果たしましたが、近年はほとんど登壇はおこなっておりません。一方でイベント運営側は社内の小さな一部署で開催した小さなイベントから現在まで様々なイベント開催を行い続けており、現在まで15年以上のイベント裏方スタッフのキャリア(?)があります。現在も3つのコミュニティのイベント運営スタッフとして携わっており、オンライン・オフライン、定期・不定期に関わらずイベント開催を続けております。そんなことを続けてたせいでうっかりテレビに出ちゃったこともありました。

    前述のように近年コミュニティイベントは増加傾向にあり、それに伴ってイベントの裏方スタッフの必要数も増加しています。また、自身でイベントを立ち上げたいという熱意を持った際に以前より気楽に立ち上げられる環境もが整っていることもあります。自分がコミュニティイベントを主催・運営するという選択肢は以前からもありましたが、より手近にその選択ができるようになった、という状況です。

    そういった状況の中で、これからイベント運営に携わりたい、イベントを主催してみたい、という人に向けて、筆者の経験が役立つのかもな、と思い、今回プロポーザルを出させていただきました。

    イベント運営は予測不可能かと思われるような物事の連続ですが、それらを上手にコントロールして、自身も楽しめるイベントを開催することは可能です。20分という短い発表時間ではありますので、おそらく筆者の持つイベント開催ノウハウの1/10もお伝え出来ないとは思いますが、そのエッセンスだけでもお伝えできれば幸甚です。

     

  • Shigeo Konno
    keyboard_arrow_down

    Shigeo Konno / aki matsuno / Jumpei Ito / ゆうすけ おおひら - Coaching Deep Dive!!

    45 Mins
    Talk
    Beginner

    はじめた動機、バックグラウンド、受けた変容、進度は違えど、
    実際にコーチングを受け続けたものだからこそ話せる体験を時間いっぱい語り尽くします!!
    (順次テーマは受け付けていきたいと思います!)

    テーマ例:

    • コーチングで受けた一番のタフクエスチョンは?
    • 自分が壁を超えたと思った瞬間は?
    • 今でも心に残っている言葉は?
    • 最高のコーチ像は?
    • 毎回、そんなに悩むほどのテーマってあるの?
    • コーチすごい!って思った瞬間

     

help