こんにちは。
今回は前回紹介したSlackの使い方に続いて、エンジニアならではの使い方や意識していることなど、スタテクのエンジニアから聞いてきました！
この春からエンジニアになったみなさんも、これからエンジニアになりたい人も、すでにエンジニアのみなさんも参考にしてみてくださいね。
（画像はhttps://slack.com/intl/ja-jp/enterpriseより引用）
スタテクのエンジニアは普段からtimesを積極的に活用している人が多いです。理由や活用方法を聞いてみました。
＜エンジニアA＞
自分もそうですが、役職のないメンバーが新しい挑戦をしたいとき、いきなりやるのは難しいと思っています。
普段からtimesで発信していくことで「どうしてそれをやりたいのか」「目的とメリットをどう考えているか」「熱量はどのくらいなのか」というのを周りに伝えることができで、新しい挑戦をし易い環境を作っていけると考えていますね。
今やっているプロジェクトなども、もっと関連の業務を伸ばしていきたかったり、社内協力を得られればと思っているのでよく呟くようにしています。
＜エンジニアB＞
エンジニアというのはクリエイティブな仕事なので、仕事以外の時間での思いつきも必要だと思っています。
そのため、業務時間以外で思いついたことや突発的なアドバイスをメモという感じでtimesに呟くようにしていますね。
プライベートな時間ということで割り切って放置してしまうのはもったいないので、そういう場面で気軽にtimesを活用しています。
timesを備忘録や、考え方の整理の場として活用しているエンジニアが多い印象でした。
業務時間外でも気軽に投稿しやすいのは、モバイルも充実しているSlackならではという印象ですね。
前回の記事でもリマインダーの使い方を記載しましたが、エンジニアのみなさんがどのように使っているのかも聞いてきました。
＜エンジニアC＞
仕事でやっている細々したことを忘れないように、どんなに小さいことでもSlackのリマインダーでリマインドするようにしています。最終的に何もしないという判断をすることもありますが、とりあえず掛け値なしに何でもリマインドです。
その日のうちにリマインダーが残っていない状態にするために、終わらなかった仕事は翌日や来週などに再リマインドするようにしています。
最近は使い分けがめんどくさくなってきてプライベートなこともリマインドしちゃっています（笑）
＜エンジニアB＞
timesとも関連していますが、思いついたことをリマインダーでメモしたりもしています。
なにか作業しているときに思いついたことだとしても、一度手を止めてリマインダーをセットしていますね。
「詰まっていた部分を解決できそうなアイデア」や「こんなの良いかも？というアイデア」など、後で思い出せるレベルでゆるくメモをリマインドしたり、参考リンクをリマインドするようにしています。もちろん忘れていたタスクがあればその場でリマインドするようにしています。
リマインダーを活用することで、タスクの整理を行っているんですね。
アナログなメモではなく。Slackのリマインダーを活用するのはエンジニアらしい側面とも言えるかもしれません。
Slackの機能だけではなく、そもそものSlackの活用方法はどのように行っているのでしょうか？使い方や意識していることなどを聞いてきました。
＜エンジニアA＞
特にtimesの発信の話になりますが、人から見られてもいい文章でアウトプットすることで言語化の練習をしています。
エンジニアの業務は、専門的かつ属人化してしまいがちで、自分だけが理解しているという状況になりがちです。自分の頭の中をアウトプットすることで、他人に理解してもらいやすいですし、コミュニケーション力が養われると考えています。
自分は異業種からエンジニアへ転職したので、「自分の頭の中身を、相手の頭の中で再構築してもらえるように伝える」という練習として、Slackにアウトプットすることを心がけています。
＜エンジニアB＞
意識しているのは「自分が常にバリューを出していたい」というところですね。
timesの活用も自分の発言を見てもらって、自分自身を知ってもらうというところから来ています。
普段どんな仕事をしているのか？どんな悩みや課題を持っているのか？どんな仕事や相談ならお願いできるのか？など分かってもらうことで始まる仕事も多いので。
あとは、情報のやり取りは皆が見ることができるパブリックなチャンネルで、メンションして連絡するようにしています。直接関係ない人の目に入ることで、アドバイスやフィードバックを得られることもあるからです。また、これによって社内のSlack運用について理解も深まると考えています。
情報の共有という場面一つとっても、Slackを活用することで社内のコミュニケーションを図れるんですね。
最後に、Slackで気をつけている点を聞いてきました。
＜エンジニアC＞
メッセージを受け取った相手の認知負荷を下げ、できるだけ読みやすいようにスタイルを活用しています。例えば箇条書きなどですね。
特に項目が多い場合は、箇条書きにすることで「4-aの件について」という形でリファレンスしやすいので、よく活用しています。これはプログラミングでも行っている、情報の構造化や正規化の練習にもなるので重要な思考だと思います。
あとは色分けやリンク、コードブロックなどを活用して見やすくしています。
＜エンジニアA＞
共有を多くすることで、リーダーのマネジメントコストが下がるようにしています。
チームメンバーが何をしているのか、どういう状態なのかをいうのを把握するのは、マネージメント業務の中でも負担が大きいと考えているので、なるべくさまざまな場面で情報を共有するようにしていますね。
timesだと更新することで、チーム間の連携も取りやすくなると思いますし、結果的にチームの総合力も上がると思っています。
みなさんありがとうございました！
エンジニアならではという部分もありましたが、非エンジニアとしても参考になるものが多く、心がけると社内でのコミュニケーションが円滑になりそうだと感じました。
ぜひ皆さんも実践してみてくださいね。
