タグ

あとで読むとManagementに関するt28atenaのブックマーク (16)

  • 無能な同僚と働くということ。 - WETな備忘録

    君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、

    無能な同僚と働くということ。 - WETな備忘録
  • チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019

    DMやPrivate Channelを使うな、といっても意味がないから、 なんでDMを使ってしまうのかをまず考える、 そこからPublic channelの使い方を考えましょう みたいな話 https://eof-github.github.io/eof2019/ Read less

    チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
  • 自分最適化したメンタルマネジメント手法|やおっち (Coachat🐢)

    これまで7年間会社を経営してきた中で、身につけなければ死んでしまうと思ったスキルはプロダクトマネジメントでも資金調達でも採用でもなく、自身のメンタルマネジメントだった。四六時中さまざまな種類の問題が頭を悩ませ続ける中、それでも自分が決めて動かなければ何も変わらないというシーンに晒され、その時に一過性の感情によって変な判断をしないように色々な方法を試してきた。その中でいくつかは大きな効果を感じて定着したのと、最近はメンタルマネジメントや心理、精神自体に興味が出てきたので(手段の目的化)自分の中で最適化したやり方を書いておく。令和だしね。 苦闘は失敗ではないが、失敗を起こさせる。特にあなたが弱っているときにはそうだ。弱っているときは必ず。 - HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか 自重筋トレ:週3日(+能動的ストレッチ週3日)「筋トレは気分転換にとても良いらしい

    自分最適化したメンタルマネジメント手法|やおっち (Coachat🐢)
  • トライ&エラーの積み重ねで、会社に最適化したテレワーク制度を作る。日本航空のワークスタイル変革

    2010年の経営破綻からV字回復を果たした日航空。その背景にあったさまざまな改革の一つが、「従業員のワークスタイル変革」です。2014年からテレワークを含む働き方改革に取り組み、その成果は生産性向上、時間外・休日労働時間の減少、育児休職明け復職率の増加など、さまざまな形で実を結びつつあります。 その取り組みの特徴は「小さく始め、大きく育てる」こと。最初は利用制限を設けたトライアルからスタートし、試行錯誤を繰り返しながら少しずつ制度の枠を広げていきました。それにより、日航空に最適化された、真に価値のあるテレワークの制度が醸成されていったといいます。 その取り組みについて、日航空人財戦略部ワークスタイル変革推進グループの東原祥匡アシスタントマネジャーに伺いました。 働き方の新常識「アフターコロナにおける企業のテレワーク」 働き方改革が推進される中で流行した新型コロナウイルスの影響で「テレ

    トライ&エラーの積み重ねで、会社に最適化したテレワーク制度を作る。日本航空のワークスタイル変革
  • 心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein

    心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein

    心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
  • 8 Engineering Leadership Roles Explained - CoderHood

    Like most industries, tech doesn’t have a standard for roles and titles, even in the area of engineering leadership. However, some patterns can be found replicated in most software companies. I’ve discussed the technical side of this equation in Software Engineering Job Titles Explained and 19 Types of Developers Explained. In this post, I am focusing on engineering leadership roles and what they

    8 Engineering Leadership Roles Explained - CoderHood
  • 非アジャイルマニフェスト - kawaguti’s diary

    アジャイルやってないんですよね」「うちアジャイルじゃなくって」っていう話をたまに聞くんですけど、「アジャイルじゃない」って、どういうことかなぁ、と思ったりします。 アジャイルアジャイルマニフェストで定義された言葉なので、その内容をみて、そうなっていない、というのが「アジャイルやってない」ということなのかな? agilemanifesto.org 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 これをひっく

    非アジャイルマニフェスト - kawaguti’s diary
  • ファン・ダン・ラーン(FDL)ふりかえりボード - Qiita

    ふりかえりで使える手法としてKPTやYWTなどがありますが、新しくファン・ダン・ラーン(Fun/Done/Learn)というアプローチを作ったので紹介します。チームがやったことを、Fun、Done(またはDeliver)、Learnという3つの軸とその重複で見直します。上の図のように、Fun、Done(Deliver)、Learnのを重ね合わせた図をボード上に書いて、そこに分類していきます。 この図を見れば、経験のあるファシリテーターやスクラムマスターなら自分なりのやり方が思いつくのではないでしょうか。ぜひ自由に使ってみてください。以下では、私たちが実際に試してみた方法を紹介します。 まずホワイトボードや模造紙に、上のFun/Done/Learnの図を描く。重なり合う領域が狭くなりすぎないよう気をつけること メンバー1人ひとりで、やったことを付箋に書き出す 付箋の内容を共有して会話しながら

    ファン・ダン・ラーン(FDL)ふりかえりボード - Qiita
  • 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita

    はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容

    心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita
  • マンパワーは足し算では動かない|深津 貴之 (fladdict)

    動画そのものはネタ動画だ。が、人的リソースの運用ミスを、端的に表現している。 一人で素早くできる作業が、共同作業になった瞬間にグダグダになる。いくつかの条件がそろうと、マンパワーの追加は生産性に貢献しなくなる。 ・状況が刻々と変化し、リアルタイムのチューニングが必要になる ・作業者の間で、多くのインタラクションが発生する ・インタラクションそのものの時間コストが大きい ・インタラクションが不定期に発生する ・動作の始動や停止に時間がかかる高速道路の渋滞、役所のたらい回し、伝言ゲームなどが典型的な例だろう。 逆に、マンパワーの増員でスケールする分野はどうだろうか。作業者が完全に分業するケース、インタラクションが周期的に起こるケースが多い。 ・作業者の作業が独立している ・インタラクションの時間コストが小さい ・インタラクションが周期的パターンで発生するこちらは工場のコンベア作業、椀子そば、

    マンパワーは足し算では動かない|深津 貴之 (fladdict)
  • エンジニアを育てる環境と、コミュニティのありかたについて - blog.8-p.info

    エンジニアを育てるはなしが、たぶん以下の Takuto Kihira さんの tweet をきっかけに盛り上がっていた。 昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました?自分で育ったでしょ?だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。とかPCとか。 私の立場は、Dai MIKURUBE さんの tweet に近い。 エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする 私自身も大学で情報工学を学ぶまえに多少はプ

  • デスマーチが起きる理由 - 3つの指標

    鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ? スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ

    デスマーチが起きる理由 - 3つの指標
  • ソニー株式会社を退職しました

    表題の通り、数年勤めたソニー株式会社を退職しました。 個別具体の退職理由はいろいろあってそれらは後述しますが、退職を決めた基的な理由は、個人的なキャリアパスの設計と会社の方針のミスマッチ、労働観のミスマッチ、技術投資の考え方のミスマッチの三点に集約できると思っています。 キャリアパスの設計と会社の方針のミスマッチ私はソニーでソフトウェアエンジニアとして働いていました。 ソフトウェアエンジニア(を目指す人間)にとってソニーと言えば、"自由闊達な理想工場"、エンジニアが自由に活躍できる会社、日のメーカーなのにソフトウェアもちゃんとつくれる会社、などのイメージがあるかと思います。私もそう思っていました。 実際会社は説明会などでそういった説明をしましたし、そういったイメージを前提に私はソニーを選び、「エンジニアとしてプロフェッショナルになる。品質が高く、お客の求める体験を作り出せる人間になる」

    ソニー株式会社を退職しました
  • エンジニアに必要なスキルは - まなめはうす

    エンジニアにとって最も大切なことは、お腹が出ていないこと。 と、15年前に私の見ていたサイト界隈で決着がついたのですが、エンジニアである私が必要だなと思うスキルって自分の中では時折変わっているので並べてみます。 可読性の高さ プログラムを書く仕事に就いたこともあって、一番大切なことは可読性の高さだと上司に面接で熱く語ったのは良い思い出です。技術屋でない上司はちんぷんかんぷんのようでしたが、バグを出さないためには、誰が見ても読みやすいコードを書くことによりバグも見つけやすくなるし、そこまで気遣いができればバグを残すことはなくなると思ってました。 この難しさは、自分にとって読みやすいというだけでなく、誰が見ても読みやすいということです。そのために、個性を取り除いていく作業を良くしたものです。 丁寧であること プログラムを書いたり、レビューをするようになったり、繰り返しているうちに次第に思うよう

    エンジニアに必要なスキルは - まなめはうす
  • 数字「だけ」追い続けるリーダーはチームを壊す | サイボウズ式

    マネジメント 新しいチームのあり方を探求 就活 就活生必見!サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める! サイボウズ式編集部より:著名ブロガーによるチームワークや働き方に関するコラム「ブロガーズ・コラム」。今回は、日野瑛太郎さんが考える「チームが数値を追うこと以外にも大切にしなければならないこと」について。 チームが成果を出し続けるためには、「数字を追う」ことが必要不可欠です。定量的な数値目標(たとえば売り上げやユーザー数、ユーザー継続率など)を設定し、日々その目標に到達するためにPDCAサイクルを回し続けないことに

    数字「だけ」追い続けるリーダーはチームを壊す | サイボウズ式
  • プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から

    中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか?」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに

    プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
  • 1