チームトポロジーという本が言いたいことをざっくり知る。 特に、4つのチームタイプ、3つのインタラクションモードについて知り、今後のチーム間コミュニケーションに活かす。
![やさしいチームトポロジー](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2c032fc9657112385f153a009b39470fa0152f4/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F695fe09212b84ea0b5ee957fe797d331%2Fslide_0.jpg%3F27726792)
チームトポロジーという本が言いたいことをざっくり知る。 特に、4つのチームタイプ、3つのインタラクションモードについて知り、今後のチーム間コミュニケーションに活かす。
1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか? スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ その コメント GitLab Handbookで面白かったもの@コミュニケーション編 GitLabのリモート統括責任者が語る 日本企業が「まずやるべきこと」 を読んだ。主題はGitLab社の https://about.gitlab.com/handbook/ である。 2022.02追記 GitLabで学んだ最高の働き方 Developers Summit 2022-02-18 2022.01追記 リモートワークのいま学びたい、GitLab Handbook非同期コミュニケーションのススメ - Qiita Handbook要点 「GitLab社ではリモートワークの中でも生産性高く働
「君は、物怖じせずに意見を言えるところが素晴らしいよね」 インターンしていた職場で言われたことがある。当時にしてはTwitterのフォロワーが多く、取材もしてもらったりしていた学生の私は、だれかに対して意見を述べることに人よりも慣れていた。 それからも、フラットで自由な会社に入り、1年目から自分の意見を求められる環境に身を置いていた。「ただの『決めてください』というレポートはナンセンス。自分は沢山調べてこういう選択肢があると発見し、その中でコレが良いと思いますがどうですか?と聞いてほしい」という上司の発言をどこかの記事で見かけたことがある。若いからという理由だけで誰かに黙らされた記憶も勿論ない。 "若いうちから、発言を許される"こと自体が羨ましがられるどこか奇妙な世の中で、「自分の意見がないと、仕事は進まない」と学べる会社にいることは私の幸運だと今も思う。 ただ最近思うのが「"はっきり意見
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
マネジャーにできること 「辞めたい」と相談された場合はラッキーですが、そうでなくても常日頃からエンジニアの「辞めたい気持ち」が蓄積しないようケアをすることがマネジャーには求められます。 蓄積させないために、蓄積したものを取り除くために、マネジャーができることを考えてみましょう。 マネジャーのミッションはメンバーの給料を上げること 仕事上の不満や理不尽は現場によってまちまちですから、一般的な答えはありません。しかし、マネジャーとして最も重要なこと、すなわち「メンバーの給料を上げる」ことをミッションとして肝に銘じてさえいれば、行動指針はおのずと見えてくるのではないでしょうか。 関連記事 エンジニアに「退職の自由」はあるのか? 主要エンジニアが退職したからゲームのリリース日が大幅に遅れた。訴えてやる!――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回
開発チームのチームリーダーやってたときってどんなこと考えながらやってた?って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く