ナレッジの向かう先

about Knowledge Management and Information Strategy

勉強会やセミナーをやりたいときの大事なポイント (3) :リスクマネジメント編

小さな内内の勉強会や、社内勉強会、テーマ別のセミナー、年に1度のカンファレンス、国際カンファレンス・・・と IT技術勉強会と一言で言っても種類や規模は様々です。
皆さんはこれらのイベントを開催、主催、管理する際に
どのようなリスクを想定しますか?

リスクの定義をおこなう

 内内のイベントは良いとして、社内勉強会をはじめとするセミナー、勉強会、カンファレンスにはそれぞれの立場から見たリスクを定義する必要性があります。
まずは視点から

  • 主催者にとってのリスク
  • 登壇者にとってのリスク
  • 参加者にとってのリスク
  • スポンサーにとってのリスク
  • オーナー(会社、部門)にとってのリスク

があります。

主催者にとってのリスク

 主催者にとってのリスクは、

  • 集客が想定を下回ること
  • 会場が確保できないこと
  • 登壇者が集まらないこと
  • 運営資金が赤字(または黒字)を出してしまうこと
  • 悪意ある売名行為に利用されて参加者に迷惑がかかること
  • ドタキャンを平気でされてしまう問題
  • 運用コストの増大化を招いてしまうこと

あたりが挙がります。

登壇者にとってのリスク

登壇を依頼された側にとってのリスクは、不安要素が中心になります。

  • 自分のスキルが他の登壇者と合わないかもしれないこと
  • 参加者のスキルや視点がわからないこと
  • 登壇時間に対する準備期間のスケジュール
  • 他の登壇者のノリや、会そのもののノリがわからないこと
  • 「何を」「誰に」「なぜ」伝えるのか、といった要件があいまいであること
  • 参加者が、聞き手に徹底してしまうのではないか?という不安
  • 登壇者本人が準備の全てを行わなければならない問題

あたりが主なリスクとして管理する必要性があります。

 

参加者にとってのリスク

イベント情報を見て、参加しようと思ったユーザーにとってのリスクは

  • 聞きたいテーマが内容として触れられるのか分からないこと
  • 登壇者が何者なのかわからないこと
  • 会そのものが、具体的にどの職能のどのくらいのレベルを対象としているのか不明なこと
  • 会そのものが、何をゴールとしているのか、参加することで何が得られるのか不明なこと
  • 資料や動画、レポートがあがるのか不明なこと

と、会そのものがどのような運用体制にあるのか?に焦点があたると考えられます。

スポンサーにとってのリスク

スポンサーにとってのリスクは明確で

  • そもそも広告効果があるのか不明であること
  • 効果の測定法が確立されていないこと
  • 有能な人材獲得のために利用できるのか不明であること
  • ブランディング確立といってどのように利用できるのか不明であること
  • 出資するに値するだけのネームバリューを持っているのか判断がつかないこと
  • 自社のサービス、技術において利用しているなど関係性が深いか否か
  • 先行投資するに値する技術か否かを判断しがたいこと

など、効果に焦点をあてた、リスクが中心となります。

オーナーにとってのリスク

オーナーとは、社内勉強会では部署、企業にあたり
カンファレンスやセミナーでは中心となって動いている主催者が所属する企業、団体を指します。

これらオーナーにとってのリスクは

  • 社員が活動することで悪名、ミスブランディングを被らないか
  • 社員の稼働を下げることに対して得られる効果がいつ来るのか不明なこと
  • 情報共有は大事といっても、どう大事なのか不明なこと
  • 支援(設備、予算、時間、稼働など)をする必要性があること
  • 情報が失われる可能性があること
  • 築かれた人脈、ブランディング、体制が属人的であること

など、運用保守にあたって、組織化すべき項目が中心となりやすいと感じます。

 リスクをタスク化して対処すること

上記は例としてあげましたが、これら異なる視点から挙がるリスクは、
タスク化することによって、どのくらいの規模のどんなイベントになるかという姿が見えてきます。
つまり、リスク対応=優先度の高いタスクになり、
イベントを成立させるためには、最低限何を行わなければならないかが分かることによって、規模と骨子が見える形になります。

例えば、登壇者に対して

  • 「何を」「誰に」「なぜ」伝えるのか、といった要件があいまいであること

これを明確にして登壇依頼を出す際の要件として固めておく必要性があります。
これが固まれば、セッションの流れや構成が見えてきます。

一方で、参加者に対して

  • 会そのものが、具体的にどの職能のどのくらいのレベルを対象としているのか不明なこと
  • 会そのものが、何をゴールとしているのか、参加することで何が得られるのか不明なこと

これを明確にすることによって、イベント自体がどのような性格を持ち、
誰がターゲットなのかが決まることで、半自動的に登壇者にとっての

  • 参加者のスキルや視点がわからないこと

というリスクも対処できる形になります。

対応すべきリスクをリスト化することによって、
それら1つ1つに対処することは、イベントそのものをあいまいな状態から具体化するプロセスに繋がります。

リスクの比較対象はコスト

これまでに挙げたリスクと対処についてですが、
イベントの規模はいくらでも増幅してしまうので、
全てに対処していくと、
そもそものテーマや規模から大きく逸脱した企画になってしまいがちです。

このリスクに対して比較する対象として、コストが判断基準になります。
コストといっても、予算だけではなく人数や、スキル、知識も含まれます。

例えば、参加者にとっての

  • 資料や動画、レポートがあがるのか不明なこと

などは、撮影機材を用意する必要がありますが、同時に撮影時のトラブルや、データの損失時の対応、撮影技術なども要求されます。

動画編集の時間、レポート編集の時間、レポートを行う人のスキルレベルなど、考慮すべき点が多くあります。

動画に関してはベストエフォート、撮影はメディアの方、レポートは自分たちで、といったように役割分担を行うか、あるいは一部対応しないという判断も、コストによって比較判断することも可能です。

主催者として最も回避したいのは、
「○○だろう」
という思い込みや慣れによる安易な判断により、
それぞれ視点の人が持つ期待やリスクを見誤ることで、
イベントそのものを失敗させてしまうことだと感じます。

「たかが無料のイベントにそこまで時間も労力もかけてられない」
「適当にやりたいやつがやればいい」

といった意見は、言葉の表現こそ異なれどもよく耳にしますし、
直接言われたことも多々あります。

しかし、エンジニア同士が時間を割いて集まり、
情報共有、交換を行う場を作る以上は、
業界全体の IT 技術の向上や Webサービス、ITサービスの品質・技術向上に少なからず関与していることと同義であると考えます。

だからこそ、リスクマネジメントは must 事項として取り組んでいきたいと考える次第です。