ちょびろぐ出張版

技術的なアレコレを書くためにたちあげた

Developers Summit 2017 Summer(夏サミ2017)へ参加してきた!

前回から2年ぶりになるけど、「Developers Summit(通称:デブサミ)」へ参加してきました!
この記事は自分の参加したセッションのかんたんな内容まとめとチームへの共有用です。

公式サイトはこちら:
event.shoeisha.jp

今年のテーマ

技術、採用、教育、ユーザーグループといった様々な切り口で、新進気鋭の技術コミュニティや、先進企業の開発環境と企業文化の事例を紹介し、コミュニティドリブンな世界における「エンジニア」「コミュニティ」「企業」の関わり合い、そしてITの行く末を模索します。

公式より引用。

いつもの技術的な内容メインではなく、企業・組織として、または、技術コミュニティのありかたや成長について
そういった各方面の内容がメインでした。

前の記事にも書きましたが、実はちょうど転職する際にチーム作りやマネージメントがしたい!という熱い思いがあったため
今回のこのデブサミ参加は大変有意義なものになると感じていました。

更に、弊社株式会社リブセンスの転職ナビユニットリーダーの海野さんが登壇依頼されたということで、まさにうってつけのイベントでした。

・組織と文化のリファクタリング
http://event.shoeisha.jp/devsumi/20170728/session/1417/

参加したセッション

※主に箇条書きに書いたものにコメント形式で入れていきます。

エンジニアコミュニティを推進する企業文化 ~楽天での5年間のコミュニティ活動・社内勉強会からみえてきたこと~ 川口 恭伸 [楽天]

最初のセッションはこちらを選択。
リブセンスでも社内勉強会が盛んに行われておりますが、他の会社の勉強会ってどうなんだろう?って気になったので。


■農業事業:Ragri
有機野菜を農家と直接コンタクトを取りやり取りする支援サービス
農業が年寄りだらけになってしまったので、サービスを通じて若手の育成をしている

■教育事業:Rakuten Super English
・法人向け
・せっかく社内言語が英語なので活用しようとして結果生まれた

■コードの管理をどうするか

→ 個人に任せるのは限界がある
→ チームで引き継げばいい!
・引き継ぎは次の人達と一緒にやれば良い
→ コードとかは2週間とかでは引き継げないので
一緒に引き継ぎ作業をしてしまおうという話
・育成はどうするか?
→ すくすくスクラムにまずは参加してみた
→ 社内読書会などを開催

しかし、社内では盛り上がらなかったので、逆転の発送世の中を盛り上げてから
社内へ逆に輸入する形
でやろうとしている。

結局、興味がない人たちばかりだったり、世間で話題になっていないと難しいというのはよくわかる。
自分もネット上で話題になってるから使い始めたツールや施策はたくさんある。


楽天に入社してから

アジャイルのすごい人がはいってきた
・社内で教え始めた
・TDD
・4人のチームで頑張り始めた
・ScrumGatheringTokyo

川口さんはアジャイルスクラム界隈では有名らしく(僕はそのへん疎いがすごい人らしい)
色んなイベントや勉強会を開いているらしい。
楽天に入るときに期待度が高い状態で入社したから厳しかったらしいw
まぁ最近転職したばかりなのでその気持ちは少しわかる。


■コミュニティの運営

・上司との関係性をうまく保つ、最悪でも停戦状態
・社内の教育担当や研修担当を巻き込む
・総務担当に良好な関係を築き、迷惑をかけない
・人集めの手段を確立する
・スタッフになってくれる社員を徐々にハントする

コミュニティは「会社としての業務ではない」ため、時間外で行うにしても
それなら他の仕事やれよって言われてしまう可能性は多々ある。
なので、それらを許容してくれる上司、もしくはメンバーが必要であるし、認めていたとしても
仕事に支障が出てはいけないため良好な関係を築いておく必要がある。

■商売とかプロジェクトのコツと大差ない

・人が多いと気持ちいい
・褒められると気持ちいい
・お金が儲かるといい

まぁ普通の感性としてはこうなるっていう話。
とにかく承認欲求的なものが満たされれば仕事もコミュニティもうまくいくよって話。

■コミュニティを稼働させるために

とりあえず動くものを作る
→ コミュニティとして活動できている実績が大事
・会社の会議室は必ず借りる
・月単位のマイルストーン
・宿題を作らない
・議決させる人数をある程度決めておく
・同じ会場で何度もやる
・張り切りすぎてる人を休ませる
・困ったら助けを呼ぶ
・ペアで行動
・ちょっとずつ仲間を増やす
・常連さんを大事にする
・スタッフはもっと大事にする
・ボランティアの満足度を高める
→ スタッフTシャツを作るとか
・スタッフが燃え尽きないカンファレンス

後半は駆け足だったのであまり記憶に無いのだが、要はスモールスタートでとにかくコミュニティを動かしてみること。
自社で運営することが大事で必ず同じ会場にしておくことが大事、いつもそこで開いているという環境が当たり前になると人も行きやすくなる。
そして最初のお客さんだった人がだんだん常連となり、その人がいずれはコミュニティを運営する側になっていくのを期待し大事にする。
スタッフについては意欲高い人がいることが多いがその人が頑張りすぎてしまうこともあるため、休ませることが大事。

オーラの泉エフェクト

すごいものがどうしたら普通になるのか?
→ 自分たち以外(他社)がやっていればそれが世間的な普遍になるので浸透しているはず

要は「他社がやっているからきっといいものなんだろう!」的なこと。
世間がやっていればそれは普及されており取り残されたらやばい感を出す。


Yahoo! JAPANのコミュニティが生み出す価値 善積 正伍 [ヤフー]

2セッション目はYahoo!の社内でのコミュニティについて。

■コミュニティの目的

・採用
自社のエンジニアを知ってもらうことで会社の魅力を伝えていく
・成長
2008年頃はLAMP環境だった
PC、ガラケーメイン
2017年
PC、iOS,AndroidスマホWeb、スマートウォッチ
スマホアプリは多機能化になってきている
スマホWweb
SPA、PWA(プログレッシブWebアプリケーション)

やはりコミュニティを社内で形成することの目的は「良い人材の採用」と「社内の文化、サービスの成長」をさせたいという思いがある。
特に採用については、自社内のエンジニアや文化を知ってもらうとそれが他社の優秀なエンジニアに広がり良い採用に繋がるはず。

またサービス成長については、最初はよくあるLAMP環境だったが時代が代わり、多様性、多機能化が進んで複雑になっている。
これらも社内での勉強会や社外コミュニティへの支援によって問題の解決が出来てきた。

幾つものアプローチがあるので、多様性が大きくなってきており
価値のあるプロダクトが提供出来ないのでは?
社外コミュニティへの参加支援
・課題が解決するとは限らない
・規模の大きいイベントに偏りがち
・行く人と行かない人のギャップが生まれる
→ 社内的に温度感の差が生まれてしまう
バーティカルに領域を跨ぎにくい

社内で勉強会を開く理由やメリットとして、上記のような内容があがっていた。
たしかに前の会社でも、現在の自社でも勉強会に参加しない(したいけど忙しい、興味がない、よくわからないから)人は一定数いる。
別に悪いことではないし、個人の自由だが行く人と行かない人では知識の差や経験の差は出てくる。
そうなると温度感の差が出てしまい、チームとしてあまりよろしくない。
なので、社内で運用することで参加はしないにしても情報の共有や知識は学べるのがよい。


■企業がコミュニティを形成するのはどうか

・課題を解決することを目的にする
同じ課題をかかえている企業同士で連携することが大事
共有しやすい

事業の変化についていけるアプリ設計
デザインとKPI
多様な出面に対応出来るAPI設計

・課題を解決する場として定着させる
勉強することを目的ではなく、社内での課題を解決する場として利用してもらう

モチベーションを維持しやすい
持ち帰って事業に活かしやすい
組織の壁を払うことが出来る

エンジニアやデザイナーの課題が組織の中では解決しにくいので
外の場で解決出来る場所を提供するのが大事

バーティカルな領域をまたげるようにする
全体をまたいでフォローする組織を形成する
→ 別の領域で抱えている課題を解決できる可能性がある
→ 他の職種の抱えている問題を案外解決出来ることもある
イベント運営をまたいだメンバーで行う

・実現する上で乗り越えたこと
とにかくOPENに開催する
→ 入りにくい環境ではなく誰でも参加出来るようにする
小さな成果をとにかく拡散する
→ 大規模な事例だけでなく、些細なことでも共有することでマッチする人を増やす
ときにはハードルをさげにいく

・課題を解決するコミュニティでうまれたもの
デザイナーがグロースハックをはじめる
導入するツールの意思決定
小さいチーム施策を大きなチームが導入

かなりメモしたので雑多になりましたが、Yahooがコミュニティの支援をしている理由として
上記のような感じでお話されていました。

・自社内だけで解決出来ない問題も、他社と照らし合わせると解決できることもある点
・勉強するだけでは意味がなく、事業の問題解決に役立てることを主とすると良い
・大きな解決ばかりが取り上げられがちだが、小さな解決のほうが役に立つこともあるのでもっと拡散するべき
・チームを跨いで職種に限らず、異なる職種の問題点を他の職種が解決できることもある

こういった部分がコミュニティを運営していく中で役に立った実績ということらしいです。
リブセンスでも異なる事業部での問題点は実は見えにくいこともあり、もっとオープンに困っていることをあげて
それぞれの事業部で解決したことや、解決出来なかったから助けて欲しいことを共有するといいのかなーと考えています。

個人というよりは事業部として、会社としての取り組みの目線でお話いただいたのでこのセッションはかなり良かった。


Deep Dive into JavaScript Community 古川 陽介 [リクルートテクノロジーズ]

NodeJSコミュニティの偉い人。
東京Node学園とか運営開催している。

元々はサーバーサイドエンジニアだったが飽きてしまい
UIよりのJS楽しそうってことで始めたらしい

付箋をリアルタイムで共有するアプリ
リアルタイムビデオチャット
子供の笑顔の瞬間を逃さないIoTアプリ
→ 顔の位置を特定し、口の位置が半月型になったらスクショしている
→ intel edison
UML図をかんたんに作成するアプリ

IoTアプリは発想が面白く、ちょっとした機材とコードだけで実現可能なのでいい施策だなと思った。
Nodeでチャットアプリは僕も作ったことがあるのでこのへんは共感することが多かった。

Javascriptコミュニティに入ったきっかけ
いちからわけわからないのをやるのは辛かった
だから誰かと一緒にやりたいと思った

すごくよくわかる、正直Ruby(RubyOnRails)はさっぱりわからんので
どこかで誰かと一緒にやりたいと思っている…

■東京Node学園祭

コミュニティは刺激になるし、振り落とされないよう頑張ろうと思える
自分もコミュニティに関わりたくなってくる、恩返ししたい的な

好きなことをやっていても継続するにはまた別の力が必要
→ それがコミュニティであった

コミュニティに参加する意義として、自分の今の力を知ることが出来るし、一緒に仲間が増えてくると
だんだん助けてもらったことへ貢献したくなってくる。
ですよねーわかります。
プログラム書くのは楽しいけど、誰かと新しい情報を共有することで維持しやすいというのもあるあるだった。

■コミュニティをより良くしていくために
徐々に変えていこうという気持ちでやっている

2014
受け継いだときは今まで通り安定して運営しようとしていた

2015
Node.jsを世界的なコミュニティとつなげていくつもりでやっていた
海外スピーカーが増えた、半分くらい
世界的な有名なJS仕様を決めていた人を呼んでみた

2016
もっとインタラクティブにするために色々な仕掛けを打ち出していった
Nodeディスカッションといった相互にコミュニケーションが取れるイベントを実施していた
初心者が躓きやすい箇所を知りたい、初心者は技術を学びたい

引き継ぎをされたらしく、頑張ってよくいこうとしている流れが見えた。
しかし海外へいってスピーチしたり、著名なエンジニアを日本へ招いたりとかなりアクティブな活動で素直に感嘆した。
僕は英語話せないのでそれだけでもすごいのだが、定期的に開催して毎回満員というのもさすがとしか。

■コミュニティの成熟と最近の問題点

最近はGithubのissueなどで気楽にコミュニティが出来あがっている
ML時代は専門家しか話をしてはいけない雰囲気だった

世界とつながるためには、自分も世界に発信するようにしよう

世界的な人と知り合いになって学園祭に呼ぶ
日本のコミュニティとつながっておく

JS初心者を成長させていきたい
Node学園付属小学校
→ 元の学園が成熟しすぎており、初心者歓迎向けのコミュニティを作った
・Node女学園の開催
→ 女性だけが参加できるコミュニティ

最初は誰もが初心者だから受け入れやすかったが、次第に古参などが増えてきて、当たり前が多くなってくると新参は入りにくい。
めっちゃわかる内容だった、結構そういうコミュニティは多い。

そして男性が多いコミュニティなので女性を取り込みたいという思いから、女性向けのイベントをやっているらしい。
たしかRubyかどこかもやってた気がする。

僕の総括的に、NodeJSはかなり可能性を秘めていると思うし、今後関わっていきたいと考えています。
リアルタイムでの通信処理や並列処理では大変面白くて、すぐに動作するのも良い。
ただ開発環境を整えたり、バージョンごとの争いが結構あるので落ち着いてきた頃合いの今がいいタイミングかなと思ってました。
会社でも何か使えそうな気がするので試せそうなら導入していきたい。



IoTアプリの開発スピードが10倍に!素早く異常検知を実現するConnexon 城取 祐司 [東京エレクトロンデバイス]

正直、最初に書いておきますが素晴らしい内容ではあるのですがあまり今回の議題には合ってない気がしました。
このセッションを選択してしまった自分が悪いのですが、自社サービスの説明と事例なので面白いテーマではあるのですが
あまり具体的に書いても仕方ないのでかんたんにメモだけ載せます。

IoT向けノンプログラミングConnexon
→ 8月1日Βリリース予定

データフローの部分をドラッグ・アンド・ドロップのみで作成可能
独自のプログラミング処理もpipe出来る
全ての操作はWebから可能
データフローをコンポーネント単位で構築し、バイナリファイルをビルド出来る
→ ビルドが独自性がある

Connectionコアファイルがexe形式
設定ファイルはjson形式
=Connectionアプリ
アーキテクチャごとにビルド先を変えることが出来る
フロー以外はjsonだけでパラメータ変更などが可能

コンポーネント
データフローに必要な処理を切り出したもの
入力→処理→出力

Node-Redとの差
IBMのツール、10万人くらいコミュニティにいる
動作環境の差はConnecxonのほうがバイナリなのでどこでも動くのは大きい

サービス自体はいいものだったです。
Connexonはプログラムしなくても処理をまとめたコンポーネントを繋ぐだけで一連の処理が出来る実行ファイルを用意できる。
さらにOS種別問わずに実行ファイルを作成出来るため、Webだけで完結して各種サーバーへログを送るとかそういったことも出来る。
IoTで使う事例もあり、工場系の会社の異常検知システムに導入すれば使えそうっていう感じでした。


LINE BOT SDK の開発とサポートから学ぶコミュニティ運営の勘所 長谷部 良輔 [LINE]

リブセンスの登壇枠と同時間帯の競合。

本当はうちのリーダーと内山さんの発表が聞きたかったのですが、スライドを見せてもらえるだろし、どうせなら違うセッション内容を聞いて共有したほうがいいだろうってことで、こちらを選びました。


内容としてはLINE BOT APISDK含)の使い方やそのコミュニティについて。
前半は完全に個人的な興味と自社で導入できるかなーっていう選定のために聞いてました。

LINEMessageAPIとLINE BOT SDK
5分で作れるBOT
LINE BOTコミュニティ

bot & new the world

LINE Notify LINE MessagingAPI
jsonで届く、Webフック

サーバーからMessageAPIを呼び出し
PushAPI (for multi Cast API) 課金が必要
botから送りたい
ReplyAPI(無料)
→ ユーザーからbotへ返信したものに対して返したいもの

developers.line.me

・PushAPI
AccessTokenを利用する
jsonを送ればよい
to:group or roomidなどで指定出来る
messages:jsonの配列
一回のAPIで5通まで送信出来る

・ReplyAPI
Webhook内にリプライトークンが入っているのでそちらを利用すれば
該当のメッセージに返信が出来る

リプライトークンには時間の限定がる
30秒ほどしか利用できない
返信は1回しか利用出来ない

・リプライできるメッセージ種別
Text
Image
Video
Audio
Location
Sticker スタンプのこと(予めLINEが提供しているものしか送れない)
Imagemap 画像内のタップリンク設定されたもの
Buttons Templte カバー画像+ボタンを並べられる
ConfirmTemplte 選択肢のあるもの
Carouseltemplete buttonsを複数設定できる
TempleteActions タップしたときのアクションを指定出来る

・メッセージ受信
ユーザーアプリ → LINEPlatform → 運用しているサーバー側
フォローイベントも受け取れる
ブロックイベントも受け取れる
JOINイベント(グループ)
Leaveイベント(脱退)
PostBackイベント(ユーザーがリンクや画像などをクリックした動作)
Beaconイベント(Beaconの近くにきたら自動で動作する)

SignatureValidation
botのurlを不正にさせないような仕組み
devdocs.line.me

LINE BOT SDK
PHP,java,python,perl,golang

たしかに去年発表されたときは微妙な気がしていたけど、実際にこうやって見せてもらうとかんたんに出来るようになっているし、LINEは利用者が多いだけに大変面白い仕組みだと思う。
このへんは技術的な興味と話だけなので割愛。
実際にコード書いて試したら記事を書きたい。

本題はこっち。
結局、LINE BOT作ったはいいがどうやって使ってもらうのかということで
コミュニティやイベント施策をした結果の話。

API公開は好評だったが、コミュニティからの反応
ドキュメントが意味不明
APIが使いづらい
マジックナンバーが多すぎた

4/7 TRIALリリース
4/11 SDK提供を決定
4/15 正式なSDKリリース
一週間程度で実装

LINE BOTコミュニティ
LINE BOT AWARDS
賞金1000万
815作品
最終は24作品

LINE BOT Caravan
学生向け対象の異ベンチ

ハッカソン・ハンズオン
平日、土日にハッカソンをやっていた
チューターとしてエンジニアを派遣

施策絵から得られたこと
・使っている開発者と接する機会
・フィードバックをたくさんもらえた
・社員ではわかりにくいところがわかった

フィードバックから解決したこと
・一斉送信ができなかった
→ ので、multicastCallAPIで対応した
・グループチャットのときにuser_idが取れない問題
→ 規約の問題で取れなかった
→ botを利用するときに同意画面を出した
・UIや説明文がわかりにくかったものを指摘してもらった
SSLで困っていた
→ Let'sEncryptも対応可能にした
・プログラミング最初として使われることが多かった
→ herokuだとSSLが設定不要なのでおすすめ

・サポートをどうするのか
→ 企業は専門チームがいる
→ githubのissueで対応している

問題
APIごとにリポジトリがあるため同じ質問を検索しにくい
・LINE BOT/faqみたいな専用のリポジトリを作った
・要望などもここに書くようにお願いした

作っておしまいではなくコミュニティの反応を見るのが大事
フィードバックをきちんともらうのが大事

LINE BOT Caravanという学生向けイベントや、ハッカソンをやって知名度を広めた事例。
また、コミュニティが複雑化してしまったのでサポートが大変なため、Githubのissueにまとめたのも面白い。
いちいち問い合わせ対応していたら時間も人も足りないので、コミュニティ自体で解決してもらうというアプローチ。

また、APIを公開して使いにくい部分や駄目出しをされたことでより洗練されたことで
結果的にサービスとしても向上したということ。

もしうちがやれるなら企業求人情報をAPI提供とか・・・?駄目かw
でも問い合わせにたいしてLINEBOTの仕組みをいれて求人を届けたり、チャットで反応するのは面白いかもなとは思った。


eurekaの普遍的に優秀な人材として成長し続けるための組織づくり 金子 慎太郎 [エウレカ]/梶原 成親 [エウレカ]


ぶっちゃけ、Yahoo!と、エウレカのスピーチが今回の聞いた中では一番良かった。
というか、エウレカの登壇については色々物申したい。

まず開始が10分近く遅れたうえに、最初の人の会社の成り立ちとか経緯が長すぎて、本当の聞きたい後半のCTO?の方の話が全く聞けなかった。
正直ショックでした。

実際に会場でアジェンダを見た時、これは今の自分達に役立つという気持ちが強かったのでおしすぎる。
周りの席からもありえねーとか、もったいないという声が多く聞こえた。

エウレカとは
pairs
couples
エウレカ組織
エウレカの文化

行動規範やフェアな評価指標の明確化
評価面談

行動規範と事業を定期面談でフィードバック
事業の意思決定を行動規範をベースに考える

ということで結構有名な、恋愛婚活向けアプリやサービスを提供している会社さん。
またエンジニアの評価面談や行動規範についても語っていたけど長すぎた。


後半の5分~10分以内の内容駆け出しまとめ。

全てのチームが自己組織化されたチーム

チーム自身でスキルを獲得できる方法がある

・タックマンモデル
チームの状態を知る
形成期
混乱期
統一期
機能期

統一期までを急ぐ

タックマンモデルという有名なモデルロールがあり、それを元に組織を運用。
最初はわちゃわちゃやっているが、だんだん統一化されていき、その後は一気にグロースアップする。
当たり前の内容ではあるのだが、その統一期になるまでにどうやって急ぐのかという話。

メンバーの価値観や相互理解を増やすためには

ドラッカー風ワークショップ
期待のすりあわせ
それぞれが期待することを共有する

自分は何が得意なのか
自分はどうやって貢献するのか
自分が大切に思う価値は何か
チームメンバーは自分にどんな成果を期待していると思うか

自己認識のすりあわせ
他者の期待を理解する

・頑張って欲しい場所の意思疎通が出来る
・モチベーションのすりあわせ
・自分の古い舞に自身がもてる

ここ!ここが聞きたかったー…(´・ω・`)
一応書籍に基いているらしいので、それを読めばいいのだがやはり噛み砕いて実践している人の話は参考になるので、お聞きしたかったぞい。

今のチームについて僕もこれは思っていたことで、結局、経験が浅いメンバーは不安点やどうしていきたいのか?といった将来への要望とかビジョンが見えにくい事が多い。
なので、他人と話すことで「自分を知ってもらう」ことで得意なことがわかるし、「あれ、この人にこれ任せられるじゃん?」とかそういった気付きも出てくるはず。
職種だけでエンジニアなら○○が得意だろうっていう決めつけは危険。

これは本気で一度、社内でうまい施策として導入してみたい。

インセプションデッキ
アジャイルサムライを読むといい

結論;
共通認識を増やすためには会話を増やす
対話して合意することで共通認識が生まれる

チームの問題を自分ごととして捉えることが出来るようになる
自己組織化されたチームだと全て自分の問題として考えることが出来るようになる

振り返り会
妨害リスト

否定的な意見ではなく事実をもとに考える

妨害リストとは
チームの行動を妨害しているものを洗い出す
きちんと問題と向き合うことができる

チームのパフォーマンスを改善することを自分ごととして捉えることが出来る
共通認識をとろう、全体最適化しよう

自己組織化されたチームがユーザーに価値を届けることが出来るようになる

まぁ当たり前すぎるけど、もっとチーム内でコミュニケーション取ろうよってことですね。
アジャイルサムライについては有名な著書なので課題図書として読んでおきます(`・ω・´)ゞ

個人ごとの目標(技術面、与えられたタスクなど)はあるが、それとは別にチームとしての共通の認識を持たせる。
共通の認識っていうのは、課題であったり、問題点であったりする。
これらを話し合いによって認識させあうことで、自己組織として最小値の組織が出来上がるので、まずは自分の事として解決を試みるようになるはず。
という内容。

特に、業務や個人・チームでの目標を達成するために妨害となっている人・もの・事象などをあげていくことで、
どうしたらそれらを除外し最適化されたパフォーマンスで仕事が出来るようになるのか考えることが大事。

具体例は聞けなかったのだが、今のチームで当てはめて考えてみると・・・

・リニューアルしたことで一旦落ち着いたメンバーの意欲を再度燃え上がらせるにはどうするか
・目下の課題はなんなのか?(売上なのかユーザー登録数なのか、企業の求人掲載数なのか)
・チームメンバーの業務や役割について思っていることや、困っていること、助け合いたいこと
・サービスを躍進させるため、ユーザーへ最適なサービスを提供するためにはどうするのか

こういったことを上記のドラッカー風ワークショップと合わせて開くことで見えてくるかもしれない。
すでに実践しているかもしれないが、末端の社員には伝わっていない気がするので、会社を成長促進するためにもこれらの話し合いはしてみてもいいのかなと思う。


総括

自分で記事を書いておいてなんだが、基本引用として貼り付けてしまったのでとても見づらい内容になってしまった。
イベントとしては個人的には70点くらいの満足度でした。

ただ、今回のイベントは本当に参加してよかったと思える内容で、前半に書きましたがまさに自分が今後やろうと思っていた施策について、右も左もわからないような状態からのスタートだったので、まずはこういった事例を参考に自分たちのチームにあうフォーマットに落とし込み試してみたいと考えています。
頭悪いんであまり難しい単語や言葉は意味がわからないのですが、少しずつ理解して、自分なりに適用していければいいかなと。


組織として、事業部が変わったり、一緒に働くメンバーがころころ変わるのは新しい風が入るという意味ではたまにはありですが、長くサービスを続けていく上ではデメリットも大きく、特にチームという単位で見ると少数精鋭な部署ですので局所的には最大パフォーマンスは出ますが長期的に見るとお互いを知る機会が少ないと齟齬が発生したり問題が起きやすく感じます。

これらを早急に解決するためには今回学んだ手法を取り入れて、解決に向けて動き出すのがいいのかなと考えています。
まぁたかが2ヶ月程度の新人が例のごとくでかい面して「ドラッカーが~」とか言ってもアレなのでもう少し違うアプローチになるとは思いますがw


と、こんなところで、今回の夏サミは大変楽しいイベントでした。
登壇者のみなさんありがとうございました&お疲れ様でした!


では。