人間関係は、効率化できない。
ある方に、私が「記事を書いて集客しています。」と言ったら、 「ええー…大変でしょう？」と怪訝な顔で言われた。 「なぜですか？」と聞いたら、 「広告回すほうが、どう考えても効率いいですよ」という。 そのまま投げ返した。 「なぜ広告のほうが効率が良いと言えるのですか。」 「……」 彼は明瞭な答えを持っていなかった。 当然、広告が効果的、というときもあるだろう。 しかし、事情も聞かず、「効率の押し売り」は、ちょっと乱暴だ。 人間関係は効率化できない 働き方改革の影響からか、上のように「自分の考える効率」を押し付けてきたり、「効率こそ正義」との誤った信念を持つ人もいる。 だが、あまり効率効率というと、実は嫌われてしまう。 効率厨 効率厨とは、最短時間でミッション・クエストなどをクリアすることしか考えてないプレイヤーのことである（中略） ガチ勢だけでなくエンジョイ勢にも普通のプレイヤーにも効率重視の
「怒りをセーブできなくなった自分」と折り合いをつけて生きる技術 - いつか電池がきれるまで
anond.hatelabo.jp この増田さん（『はてな匿名ダイアリー』の著者）は病気がきっかけだったそうなのですが、僕は血圧が高いくらいで他に大きな病気もない（はず）なのに、加齢とともにイライラがひどくなり、刹那の怒りを爆発させてしまいそうな自分に困惑しているのです。 fujipon.hatenablog.com 年齢を重ねると、どんどん人間が「丸く」なってくるものなのだと若い頃は思っていたのですが、全然そんなことはなく、博多の街を歩いたり、運転していたりすると、「なんでこんなにみんな自分のことしか考えてないんだよ！」なんてイライラしてばかりです。 先日は、焼肉屋で会計を待っていたら、若い女性のグループが、レジの前に来て金額がレジに出てから、誰の分がいくらだとか相談をしはじめ、10分くらいレジの前でうだうだしていたことに心底ムカついたのです。 なんでレジの前に行ってから、会計のしかたの
グレードイメージ具体化のため昇格理由を公開する
スマートロック開発におけるSLI/SLOを用いた解錠体験の改善 / Improving the unlocking experience using SLI/SLO in smart lock development
マネージャーの視点から見える向こう側の景色｜Kazutaka Irie
「マネジメントなんてやりたくないよ」 そんなふうに言っていたのがほんの数年前のことだったのだけど、いつの間にかマネージャーの人たちをマネジメントするような立場になってしまった。 ちょうど人事考課のフィードバックをする時期になって、他のチームメンバーの人たちを優先した分、マネージャーやリーダーと呼ばれる立場の人たちは後回しになってしまっている。 「私のことは後でいいから他のメンバー達の評価を先に伝えてあげてください」 そんな言葉に甘えながら、遅くなってごめんねと言いながら、マネージャーの人たちのフィードバック面談を今更（更改された年俸やインセンティブ含め、既に人事考課の結果は本人まで開示されているので本当に遅い。ごめんなさい。）やっているわけだけれども、実際に話をしてみるとむしろ彼らの方がよほど悩んでいたり、早めのサポートが必要な状況だったんじゃないかと感じることが多い。 ここから始まる文章
１on１を語る
『1 on 1』の実施は、マネージャーがレバレッジを効かすための機会をつくり、部下にとっては自身をより成長させて自立に繋げられるヒントを得られる機会をつくることができる。今回のポッドキャストエピソードは、スタートアップ向けの人事コンサルを専門にされている金田さんと一緒に『1 on 1』について様々なことを語りました。 【サマリー】 1on1の目的はアウトプット/成果にレバレッジをかけること（単なる悩み相談ではない） 1 on 1のはじめ方 意識すべきこと 頻度と時間の目安は、隔週で30～60分（実施する曜日も時間帯もちゃんと考慮すべき） 1on1の流れ：①仕事の進捗確認→②フィードバックセッション→③目標と評価の確認 心理的安全をつくるためにメンバーがマネージャーへフィードバックする（フィードバックは問題点・改善点を伝えるだけではない、まずは良いことから伝える） KPTフレームワークについ
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
エンジニア個人が自主的に成長するように促す - エンジニア組織の自律的成長 - 人間とウェブの未来
この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。 僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。 しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアメンター制度の効果的な運用を目指して/improve-mentor-system
開発組織マネジメントのコツ - Speaker Deck