はじめに
当方フリーランスエンジニアで、現在転職(再就職)の予定は一切ありませんが、かなりたくさんの現場を経験した中で**「Slackの活用方針は、その会社の技術への向き合い方を(ある程度)反映する」**ってことが見えてきました。
もし今後僕が転職活動(再就職活動)をするなら「御社はどのようにSlackを活用していますか？」は必ず訊きます。絶対です。
例えば「高級な椅子やキーボードが支給されるか」っていうのも気になるところですが、それは転職面談だと聞きにくいですよね？
それに比べると、"Slackの活用レベル" は訊きやすくて、かつ明確に色々な情報を教えてくれるな、と。
注意点
ここから便宜上Slack活用をレベルごとに分けて書いていきますが、例えば必ずしも**「レベル2までしかSlackを活用していなければ、会社全体の技術水準はレベル2にすぎない」っていうことは無いっていうことをご理解ください。
正確に言うならば「レベル3以上を当然のように使いこなしていれば、新しい技術の導入や業務の改善、DevOpsの活性化に対する感度が高い」 = 「技術者にとって居心地のいい会社である」可能性が高い**、というそれだけの話です。あくまでも可能性の世界で、断言するようなものではありません。
Slackを高水準に使いこなしていれば社内全体でかなり高度に技術の知見や意思がストックされている可能性は高い一方、レベル3以降は大規模な会社になればなるほど全社単位で導入しにくいものです。それはよく理解しております。web系かSIerかでもまた変わりますしね。SIerでレベル3以降の全社的導入は相当厳しいかも。
この記事はむしろ、インフラ担当の方などに**「こういうところを整えておけば技術者にとって『居心地のいい会社』に見える」**というような目線で見て頂けると嬉しいです。
プロジェクト単位でもレベル3以降導入できるだけで全然違いますし。
ただしレベル０、テメーはダメだ。
ここからレベルごとに記載します
レベル0：チャットツール？ 導入してません。社内連絡はメールです。
そんな会社あらへんやろ……
……それがあるねん。
信じられないことにあるねん。
結論から言います。
想像を絶するヤバさだと思ってください。
それは**「エンジニアリングにおいて社内コミュニケーションの円滑化なんて全然重要ではない」** と宣言しているに他ならないからです。
信じられないことに、「社内コミュニケーションの活性化」を叫びながら社内での雑談を咎め、情報共有の円滑化に微塵も興味を示さない会社は存在します。
まぁこれだけボロクソ言えるの、かつて僕が正社員として入っていた会社がそうだったからなんですけどね。最近改善されたそうなので愛を込めてボロクソに言ってます。※
※その会社とはまだ仲良く交流は続いています。
実際のところ、大半の技術会社はレベル1以降だと思います。
レベル1：コミュニケーションツールとして使っていて、プロジェクトごとにチャンネルを用意しています。
普通です。特に言うことはありません。
レベル2:全体雑談用チャンネルと、プロジェクト単位雑談用チャンネルを用意しています。また技術用チャンネルも別途あります。
別にチャンネル構成は必ずしもこの通りでなくてもよいのですが、要するに
- 『チャンネルの構築・運用』が重要であると理解していること
- 雑談用チャンネルでアイスブレイクすることが大事であると理解していること
- 技術用チャンネルで新規技術のスピーディな共有ができるようになっていること
大事なのは1と2で、3はあればなお良い、というところでしょうか。
１はもちろん大事なのですが、2はそれと同じくらい大事です。
「３の方が大事じゃないの？」と思った方がいるかもしれませんが、個人的には2の方が圧倒的に大事だと思っています。
何故か？
２があると、Slackへの投稿のハードルが一気に下がるのです。
「Slackへの投稿のハードルが低すぎて、余計なことまで投稿してしまう」ことと「Slackへの投稿のハードルが高く、気楽に投稿できない」こと。どちらが業務上のネックになるでしょうか。
僕は圧倒的に後者の方が有害であると考えます。
第一、前者は雑談用チャンネルが存在することで抑止できますし、個々人の問題なのでどうとでも対応できます。
「チャットツールで気軽に発信できない」は、会社の雰囲気や個人のパフォーマンスにも繋がる一大事です。技術者も人なので感情が仕事に影響するのは当然ですし、「誰も気軽に(Slack上にせよ)発言できない」ような会社で居心地の悪さを感じても不思議ではないでしょう。
それが雑談用チャンネルひとつあるだけで抑止できるのならば、非常に安い投資ではないでしょうか。
安いどころか無料です。
レベル3：Gitのホスティングサービスと完全連携
さて、ここからは「コミュニケーションツール」としての枠組みを超え、**「開発ツール」あるいは「DevOpsツール」**の枠組みとなってきます。
レベル3以降は入れ替わりがあるかもしれません。レベル4だけ導入してたりとか。
ただ、レベル3以降は一つ導入するとどんどん導入が増えていく領域なので、あまり上下関係を意識せずお読みいただけますと幸いです。
さて、便宜上レベル3に位置づけた「Gitホスティングサービスと完全連携」ですが、端的に言ってこれは**「プルリク駆動レビュー文化」がどれだけ根付いているか**の指標になります。
これは滅茶苦茶技術者にとって重要です。
これがあるかないかで、技術者の少なくともプログラミング領域の成長曲線は天地の差が生まれます。
Gitのリモートサーバ側のアクションは色々ありますが、例えばpushされた、mergeされた、プルリク発生、レビュワーに指定された(これは今大体のホスティングサービスにある機能ですね)、コードにコメントされた、承認された……
これら、可能なら全部Slackに連携しちゃいましょう、という発想が正しいと僕は考えています。
例えばbitbucketなんかではSlackで個々人のアカウントとも連携できて、レビュワーとして指定された際に通知が来るような仕組みがあったりします。
これがないと、プルリクエスト時に逐一別メッセージでレビュワーに「お願い」することになりますよね？
もう一度強調します。「お願い」することになるんです。
これって無駄な業務じゃないですか？
Gitにおける全てのアクションが、開発者への周知を兼ねている。
ここまでくると無敵です。開発速度はぐっと上がります。
レベル4：CI・CDと完全連携
ここからは色々端折って書きます。というのも、これ以降は「DevOpsツール」として……つまり開発そのものよりも「運用」に近づいていくからです。開発者には無用、あるいは開発者がガッツリ運用を兼ねざるを得ない自社開発のweb系企業以外無用、という可能性もあります。
ただ、わかりやすい例で言えば……
例えばGitのホスティングサービスとCircleCIなどのツールを連携して、push後にビルドやテストコードを走らせるということはよくやっていると思います。
それらがコケたときに開発者に通知されたら、速やかに開発者は対策を打てますよね。※
※pre-commit使えばええやん、というご意見もあるとは思いますが、それはそれとして。
参考文献はこちら：Python製のツールpre-commitでGitのpre-commit hookを楽々管理！！
本来は手元でテストもビルドも完璧にしてpushするのがベストなのですが、色々な理由でそう上手く行かなかったりします。
そんなときSlackが「ナイスアシスト」してくれるわけです。
レベル5：あらゆるものをSlackと完全連携し、あらゆることを通知してもらう
もうここまでくるとほぼ完全に運用レベルの話になってきますが、おそらくレベル4まで導入している企業であれば**「あらゆるものはslackに連携できるやんけ」という発想になり始めます。**
代表的なところでIFTTT。Twitterの口コミを集めたりできますね。
これはマーケティングに役立つだけではなく、例えば自社プロダクトなら不満やバグの早期発見にも繋がります。
それからAWSでもSlackと連携できるサービスが増えているようです。
AWSのメンテナンス情報をSlackに通知する
これは王道ですね。可用性の向上にダイレクトに繋がります。
(追記) レベル6：無限の可能性
この記事では「通知してもらう」ことに主眼を置いていましたが、コメントで別アプローチを2つ頂いたので追記いたします。
一つは「分報」、エンジニア向けのSlack版Twitterでリアルタイム情報共有しちゃおうっていう発想です。
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう
PHP関連記事でQiitaでも有名な@suinさんの記事です。
Twitter依存になりやすいエンジニアが始めるとちょっと危険？ スピーディな情報共有って意味では究極形態かもしれませんね。試してみたい。
他にも、「ピザのオーダーをSlackでお願いする」。
「外部連携した上で、通知する」という発想です。なんらかの通知をこちらから能動的かつ任意のタイミングでする必要がある現場……結構限られてくるとは思うのですが、そういう現場では結構実用的かも。
botにお任せして定時処理でslackから何かしらが送られる、っていう仕組みは結構幅広い現場で使えるかもです。チャンネル分けておけば記録もガーッと残りますし。
仕事中にピザを食べるのはほどほどに！
そろそろまとめます。
終わりに
レベル3以降はメールでも実現できますが、メールだと「多くなりすぎる」という弊害が出ます。受信ボックスをどう分けるかは個人に依存するので、そこで属人性が生まれてしまいます。
Slackだとチャンネルごとに通知を分ければいいだけなので、「大事なメールが他の通知で埋もれる」という問題は上手くやれば発生せず、属人性もありません。
たかがチャットツール、されどチャットツールです。
業務の改善にこれほど低コストで高い効果をもたらしてくれるものはそうそう存在しないと思ってます。
チャットツールをコミュニケーションツールとして終わらせるのはもったいない。SlackはDevOpsの中心に位置づけられる超強力なツールです。
レベル0をこき下ろしましたが、もしレベル0の企業内で読まれている方がいらっしゃれば……特にその企業が「自称技術会社」であるならば、繰り返しますが**「想像を絶するヤバさ」**であると思ったほうが良いかもしれません。
**「コストが低く、手っ取り早く大きな改善ができる、みんな使ってる技術(ツール)」**をサクッと導入しない会社で、「革新的な技術」なんて導入も運用もできるわけがないんです。
技術なんて究極的にはツールの集積ですから。
もしレベル0の企業が今後チャットツールを導入するならば、他のチャットツールではなくやっぱりSlackがおすすめです。Slackはデファクトスタンダード化しているため、各種クラウドサービスとの連携が豊富です。レベル3以降の導入を検討するのであれば、他のチャットツールよりも圧倒的な優位性があるのでSlackをおすすめいたします。
レベル1以降の会社であればここに列挙したことは「今後、比較的手早く導入できて効果も大きい」ものも多々あると思いますので、ぜひとも導入をご検討ください。お役に立ちましたら光栄です。
ではまた。