無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
またSlackでtimesを始めてしまった｜ばんくし
・Slackにおけるtimes文化とは ・一度仕事中のチャット雑談の全てを断ったがまたtimesを立てた話 ・守りたい節度とこれからSlackにおけるtimes文化とは「times」とは、社内チャット等で自分のチャンネルを持ち、短いスパンで発言する社内Twitterのような文化形態である。 私がまだ学生でインターンやアルバイトという形でIT企業に関わって居た頃、彗星の如く現れた以下のブログがきっかけで、Slackを導入していたITベンチャー企業で流行りはじめたと記憶している。 分報、times、timelineなど、様々な呼び方を各社がしているが、要は社内チャットにおけるTwitterである（ここでは最も一般的だと思われるtimesに統一する）。 timesは、カルチャー性とSlackの各機能とが相まって、爆発的に流行った。近年ではTwitterのフォロワー内でも「times文化がない会社
大学の研究室で、ラボ全体で使うつもりで有料のウェブサービスを契約するのがなかなか難しい - 自習室
序文 とあるラボの立ち上げ期にがっつりかかわらせていただき、ちょっとしたシステムアドミンみたいなことをずーっとやっています。 とても特殊な経験をたくさんさせてもらったので、誰の役に立つかはわからないけど気が向いたときにメモとして残しておきたいと思っています。 G Suite for Education はラボ単位でも申し込めて、とてもとても良いよ、って話 GitHub Education もラボ単位で申し込めて、とてもても良いよ、って話 Slack はすげー学割が利くし、最近検索が少しずつ改善してきているので、有料プラン申し込もうぜって話（今日の話と少し関わりがある） esa.io は教育機関で申請すると無料で使えるぞ、って話 大学が包括契約している様々なソフトを見逃すな！って話（c.f. UTokyo MATLAB Campus-Wide License) などなど。けど、良い話より難し
仕事ができる人ほど、できない人に優しく振る舞うのは、マネジメントの定石。
昔、ある会社の営業MTGで、忘れられないやりとりがあった。 少々詳しく描写すると、出席者は以下の通り。 ・役員（部長） ・リーダー ・メンバー 7名のメンバーの能力は各々、高、高、中、中、中、中、低。 二人ぐらい優秀な人物がいて、一人「できない人」が混ざっているイメージだ。 また、役員とリーダーは切れ者で、部下の報告の論理矛盾やダメな点にはすぐに気づく。 さて、こんな状況で来期の「営業計画」について、MTGが開催された。このMTGの議長はリーダーだ。 リーダーはテキパキと議事を進める。 来期の営業部の方針に始まり、具体的な目標設定、個人の役割など、メンバーへの指示も簡潔でわかりやすい。 ここまではなんの問題もなかった。 だが、今年一年を振り返っての営業報告が始まると、雰囲気が変わった。 無理もない。メンバーの一人ひとりが、自分の過去の実績と、これからの具体的行動を発表しているのだから、緊張
他チームの人とうまくやりとりするための心がけ
個人的に大切にしていることを書いていきます。少しSREの話が出てきますが、私がSREチームだから出しているだけで、基本的にSREに関係の無い分野でも使えるはずです。 前提となる心がけまず前提となる心がけについて書きます。 エンジニアは恐いと思われている人は自分と関わりの少ない人のことを恐いと思いがちです。 システムはほとんどの人にとってブラックボックスです。そしてシステムを担当しているエンジニアのことも、ほとんどの人にとって未知の存在です。関わりが少ないからこそ、ほとんどの人にとってエンジニアは恐い存在です。 ビジネスをやっていく上で、エンジニアとのやりとりは非常に重要です。そのエンジニアと他の社員のやりとりがしにくい状況だとお互いにストレスが溜まり、不健全な組織となっていきます。 これを解消する一つの手として、例えばチャンネル名が z- から始まるチャンネルは雑談していいというようなルー
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
コミュニティは2回集まると死ぬ。｜papanda｜note
昔から、さまざまなコミュニティをつくってきた。ただ、どれも長続きはしなかった。結局、今も残っているのは一つだけ。最初は集まってきたみんなもこれから始まることに期待でいっぱい。すごい盛り上がりを見せる。ところが、たいていの場合わずか2回目の集まりを経たところで、もう衰退期に入っていく。3回目には集まる人数が激減する。ここまで2-3ヶ月程度のことだ。コミュニティは2回集まると死ぬ。 長らく、その理由が分からないでいた。どういう工夫をとっても、たいてい死んでしまう。どういう集まりだったとしても。顔ぶれが違っていても。同じ道を辿る。まるで私だけタイムリープを繰り返しているかのように。2回目で死を迎えることになれてしまっているし、特に驚きもしない。ただ無力さだけはいつも感じていた。 ある時、一つの仮説に思い当たった。ヒントはリモートワークだった。仕事として、リモートワークを基本とする日常を送り、組織
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
“文春砲”のかげにSlackあり？ 老舗出版社がSlack導入を決めたワケ【週刊Slack情報局】
Scrapbox SQUARE #3 パネルディスカッション - Scrapbox SQUARE
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
弊社はあいさつがない
暗黙知シェアサービスができるまで
ティール、ホラクラシー、モンテッソーリ教育と自律人材