Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
corpengr_slack_event#2_LT4_10/25
Search
みともり
October 25, 2019
Technology
1
380
corpengr_slack_event#2_LT4_10/25
みともり
October 25, 2019
Tweet
Share
More Decks by みともり
See All by みともり
cejobchange_3rd_visasq
mitomori
0
49
Other Decks in Technology
See All in Technology
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
1
1.2k
MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT
muit
1
2.3k
rubygem開発で鍛える設計力
joker1007
3
280
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
160
CursorによるPMO業務の代替 / Automating PMO Tasks with Cursor
motoyoshi_kakaku
2
820
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
1
1.1k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
2
3k
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
150
AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法
kazzpapa3
3
620
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 完全版 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming - Expanded
tomzoh
4
3.4k
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
1.9k
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.6k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
GraphQLとの向き合い方2022年版
quramy
49
14k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Optimizing for Happiness
mojombo
379
70k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Agile that works and the tools we love
rasmusluckow
329
21k
Navigating Team Friction
lara
187
15k
Done Done
chrislema
184
16k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Transcript
Slackを 整えてみた みともり@VisasQ inc.
名前:みともり Javaエンジニア→インフラエンジニア→情シス 今はスタートアップ企業(株式会社ビザスク)で一人 目情シスで入社して1年半くらい。 エンジニアリング以外での課題解決が得意。 趣味はF1観戦と息子と遊ぶこと。 自己紹介 Twitter : mit0k5
Facebook : keigo.mitomori
ビザスクについて 「世界中の知見をつなぐ」というビジョ ンの元、ビジネス知見に特化した日本 最大級のスキルシェアプラットフォー ムを運営するスタートアップです 1時間からのインタビューをマッチング するサービス 等を展開しています
ビザスクではSlack使ってます ほぼ導入した当初のルールのまま!! もうすぐここ Slack導入 採用予定数
放置していたらこんな問題が 重要な周知と雑談が混ざっている 盛り上がらないまま廃れていくチャンネルがある 誰がどのチャンネルによくいるのか分からない... チャンネル名にとりあえず「#chat-◯◯◯」とつける このチャンネルはその話題を話す場所じゃない」と怒られる
初期メンバーに聞いてみる 私「今のSlack使いづらくないですか?」 社員「今の状態に慣れてるし、変えたら慣れるまでのコ ストがかかるじゃん。しばらく今のままでいいんじゃな い?」 私「なるほど...」
いや、ちょっと待てよ
最近入社した人は?
最近入社したメンバーに 聞いてみる 私「Slackって使いづらくないですか?」 社員「今まで使ったこと無かったので、こういうものだと 思って使ってますが...」 私「なるほど...ではこんな感じになったら便利だと思いま せんか?」 社員「それいいですね!そうして欲しいです!」
声が上がらないだけで改善で きることはいっぱいある
“ 入社直後というのは、ただでさえ慣れない環 境にストレスのかかる時期 少しでもSlackを快適に利用できるようにし て、爆速で立ち上がって(売上に貢献して)も らいたい!
ということで
具体的にヒアリングしてみた ①チャンネル名が分かりづらい ②重要な発言を見逃す ③気軽に発言しづらい
なんとかしよう
チャンネル名が分かりづらい 原因 解決策 誰でもチャンネル作成OKなので、名 前に規則性がない 命名規則を決める
主な命名規則 「チャンネル名の命名規則」という文化が浸透していないので、 まずは緩めでスタート #biz-XXXX 事業部門関連 #dev-XXXX プロダクト開発関連 #team-XXXX チーム内コミュニケーション用 #rq-XXXX
問い合わせ系(requestの略) #times-XXXX 分報(個人用の通知を流している人が多い ) #log-XXXX 各種履歴をひたすら流す用
でもみんな命名規則守るの?
もちろん守らない人はいます そこで...
新規チャンネルを通知するようにして、 全て情シスでチェック
重要なチャンネルの発言を 見落とす 原因 解決策 他のチャンネルと混ざって忙しい時に 既読をつけてしまう 重要チャンネルには数字のプレ フィックスを付ける
→プロダクトのバグや障害を報告 →全社員への重要な周知 →インシデントの報告 →全社員へのライトな周知 →社外のこんな人を探してます →伝言用 →プロダクトのリリース情報 →事業数値のレポートが自動投稿 →日報 →経営陣のディスカッション
→出欠連絡 →誰に聞けばいいかわからないことを質問 急に大きく変更すると分かり辛いと思い 可能な限り以前のチャンネル名を踏襲 する方針を採ったので、名前に統一性 がない部分があります (syukketsuとか)
気軽に発言しづらい 原因 解決策 暗黙の了解が多い ルールやガイドラインを明文化する
ガイドライン (絶対守る必要はないけど、これ通り に使うと快適になるよ、というもの ) ※ルールが多すぎても形骸化してし まうため
ルール(一部抜粋) (可能な限り守ってもらう )
その他にも
Slackハンズオンを開催
Slackの全チャンネル一覧を用意 (自動更新)
便利な機能について情報発信 ワークフロービルダーを早速使ってみる
どうなったか
もう一度ヒアリングしてみた 「別にチャンネル名変えなくてもいいじゃん」て思ってたけど前より分 かりやすくなったね どのチャンネルに投稿するべきか迷わなくなった 参加しなくてもよいチャンネルが分かりやすくなって集中できるように なった ワークフロービルダー自分のチームでも使いたい!Slackっていろん なことできるんだね
概ね好評
とは言え課題はまだまだある • 検索難しい • カスタムレスポンスが邪魔 • 表示名がカオス • SlackAppを活用できていない •
メールを統合したいなー
そして、学びも
学び① 課題は自分から取りに行かないと分からな いことが多い 不便に思っても我慢しちゃう人が多い ... 普段からのコミュニケーションが大事
学び② 一度で完璧を求めない 漏れが無い命名規則を考えていたら膨大な数になった (守られるわけがない ) プレッシャーにもなるので「うまくいかなかったらまた変えればいっか」くらいで OK
学び③ 情シスの熱意が大事 よく使うツールの使い方が変わるのはちょっと、という人も →熱意で押し切ると反対されない 作業的には面白くないのでモチベーションが上がりにくい
まとめ スタートアップはビジネスの成長のための施 策に目が行きがちだけど 仕組みづくりも大事
まとめ でもやっぱり プログラミングしたい 自動化とかしたいよー そのためにまずは仕組みづくりを頑張る!
おわり