どんよりマンネリした振り返りが、皆が主体的に発言してマンネリ化しないようになったプラクティス - Qiita
1. はじめに 私のチームでは2～4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。 ただ、チームの振り返りにて、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事はないでしょうか？ 過去の私のチームはそうでした。 それを改善し、全員が発言しまくる振り返りができるようになっても、だんだん振り返りがマンネリ化してしまう事はないでしょうか？ 過去の私のチームはそうでした。 また、チームに問題がなく順調すぎて、振り返りで挙がる改善アクションが些細なものになってしまう事はないでしょうか？ 過去の私のチームはそうでした。 本稿は、その状態から脱却し、皆が主体的に発言するマンネリ化しない振り返りを実施し、新しいチャレンジをたくさんするようになったプラクティスを紹介します。 なお、前提として以降で紹介する振り返りはすべてリモート
私たちは心理的安全性を誤解していたかもしれない。 - Qiita
はじめに 最近、新入社員の方が毎月のように入社されていて、うちの部署もにぎわってきたなーと感じています。 やっぱり、人が増えてくるといろんな方がいてコミュニケーションの大切さを実感しています。 うちの部署では、事業部で大切にしていることの一つに心理的安全性があるので、それについて考えてみたいと思います。 心理的安全性とは？ 心理的安全性とは何でしょうか？ググってみると 「心理的安全性とは、職場で誰に何を言っても、人間関係が壊れることなく、罰を受ける心配もない状態のこと。」と出てきます。 これだけだと抽象的で、よくわかりませんね そこで心理的安全性を提唱したエイミー・C・エドモンドソン先生の「恐れのない組織」を読んでみました。 本書では様々なケーススタディから組織での心理的安全性について書かれています。 心理的安全性の高い組織はどういうものかざっくり要約すると 「このままではまずいのでは？」
要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita
はじめに タイトルの主張が少し強いですが、以下の本を読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元の本では具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか？」 明確化 曖昧な表現を明確にする 例：「うまくできない」→「納期に間に合わない」 論理性チェック A
継続される1on1のコツ、話す内容例と1on1の目的について【2022年版】 - Qiita
本記事ではSIerに所属する著者が3年間にわたり、私たちのグループで実践している「1on1」の内容を紹介します（グループの業務内容は主にAI系の自社製品開発です）。 ・1on1をこれから始める方 ・1on1の取り組みを検討をされている方 ・1on1を実施しており、さらに改善を検討されている上司側の方 ・1on1を実施してもらっているが、なんだかしっくりきていない部下側の方 こうした方々にとって、何らか参考となれば幸いです。 とくにIT系の企業や職種では1on1を開催しているところも多いと思います。 新人プログラマの方にとっても、1on1を実施する側がどのようなことを考えて実施しているのか、ひとつの例として参考にいただければ幸いです。 （なおQiitaでは現在、新人プログラマ応援 - みんなで新人を育てよう！企画も開催中です） 私が自分の頭を整理するために記事化しましたが、非常に長い文章にな
良い質問をして自己成長に繋げるためのあれこれ - Qiita
質問に関することで悩む若手エンジニアは多い 「ちゃんと調べてから質問した？」 「今日の進捗は？ない？ずっと同じ場所で悩んでいたの？？」 「わからないところあったらすぐ質問してね？」 「すみません。どうして欲しいのかわからないです」 他にもいろいろあると思いますが、 上記の様なことを言われているうちに質問することへの心理的障壁が上がってしまい、 質問する行為自体が悩みの種になってしまうことも多いです。 自身のキャリアのキャリア初期に「こうするとうまくいった」・「こうしておけばよかった」 また、エンジニアキャリアをスタートしたばかりの人をサポートする様になって「こうすればうまくいくんじゃない？」と アドバイスする機会もあったので、今回は質問という話題に絞って、残しておきたい。 カテゴリ分けするともっと見やすくなるかもしれないが、思いついたエピソードや事柄を羅列する形にしたいと思います。 稚拙な
みんな話すのが苦手 - Qiita
デッサンも プログラミングも 必修じゃなくていいので 打ち合わせとか議論の訓練を必修にしてほしい 社会に出て感じたのは大人数がいる場で話すのが下手な人が多いなーという事。 それによって無駄な打ち合わせ・議論がたくさん見受けられる。 下手な人のケース 一人で延々話し続ける 割とよく居るパターンの人 考えながら話してるのか要点がまとまってない。 コメントのような関係ない部分まで話す。 なので、話が長い割に何言ってんのか良く判んない。 伝わらない・理解されていない 話した本人以外 ？？？ 状態にする人 伝わってないからもう一回話すが、 同じことを話すのでやっぱり伝わらない。 時間と酸素が浪費されてゆく 流れをぶった切る 自分が言いたい内容だけを言いたいので、発言できる隙を見つけては言いたいことだけ言う。 無理やり議題をそっちに移行させようとするので、進行している人がちゃんと制御しないと尻切れトン
【新人教育】新人エンジニアに意識してほしい15個のこと - Qiita
はじめに Qiitaが新人プログラマ応援イベント中ということなので、新人エンジニアに意識してほしいことをまとめてみました。 １．「意見」と「事実」を混合しない 会話の中に「意見」と「事実」が混合することで、なんの根拠もない「意見（推論）」が「事実」であるかのように伝わってしまう危険性があります。 この「意見」と「事実」の混合が相手の勘違いや確認の手間を生み出します。 個人的にですが、エンジニアは特に意見や推論を説明することが多い業種だと思っています。 そんなエンジニアだからこそ、予期せぬトラブルに直結する恐れがある「意見」と「事実」の混合には特に気をつけた方が良いです。 こんな会話を経験したことのある人もいるのではないでしょうか？ 【ケース】 障害対応について、新人が先輩に報告する際の会話。 ※「先輩感じ悪いな」と思うかもしれませんがご了承ください。わかりやすくするためです。 ======
新人エンジニアに1年間で身につけて欲しい能力 - Qiita
2020年は初めて本格的に新人エンジニアのOJT1に取り組んだ年でした。 自身の振り返りも兼ねて、OJTの際に感じた新人エンジニアに1年間で身につけて欲しい能力を記載しようと思います。 前提 あなたは誰？ （2020年当時）6年目のサーバーサイドエンジニアで、普段はPHP(Laravel)で自社サービスを開発しています。 OJTの内容は？ プログラミング未経験の新人エンジニア4名にOJTを行いました。入社後三ヶ月間は外部機関でプログラミング研修を実施し、その後の三ヶ月間は私がOJTを担当しました。 OJT期間中、新人には自社サービス開発の実装〜結合試験を行なってもらいました。具体的には以下の流れで業務を行ってもらいました。 コロナ禍のため、最初の一ヶ月は出社、二ヶ月間はリモート、という状況でのOJTでした。 本題 三ヶ月間で新人エンジニアのOJTを実施し、身につけて欲しいと感じた能力を以下
理不尽なムチャぶりを全力で回避したいエンジニアのためのサバイバル術 - Qiita
システム開発に携わっていると、大なり小なり理不尽なムチャぶりを食らうことがあります。 「しわ寄せはいつもエンジニアにくる。。。」と内心憤っている方も少なくないでしょう。 私自身はどちらかというとムチャぶりをお願いしてきた側の人間で、申し訳ない気持ちでいっぱいです。 ただ、一方でこういったムチャぶりを事前に回避し、必ず平和に着地させるすごいエンジニアの方々も数多く見てきました。 なので、今回は「もう二度と理不尽なムチャぶりは食らいたくない」と強く願うエンジニアの皆さんに向けて、平穏な日常を暮らしていく明日から使えるサバイバル術をご紹介します！ そもそも、なぜムチャぶりを食らうのか まず、なぜエンジニアばかりが理不尽な目に合いやすいのか。それには構造的な問題があります。 上の図は、ユーザーに商品を提供するまでの工程（バリューチェーンと言います）を表した一例ですが、ここでは開発が一番先頭に位置し
エンジニアの「雑談」の効能を考える - Qiita
はじめに COVID-19の影響によりリモート化が急速に進んだエンジニアの世界。 リモート化によって移動時間が減ったり、打ち合わせや仕事の切り替えがスムーズになったり、と多くの恩恵はあるものの、失ったものもあるはずです。 その一つが、雑談です。 リモート環境では、これまでのように、手を休めている人を見かけてから声をかけに行ったり、ランチの際に他愛もない話をしたり、ということがしにくくなっています。多くの現場で、完全になくなったわけではないものの、確実に減っているのが雑談です。 そんな雑談について、「エンジニアが雑談をすることによる効能」をNRI bitLabsのチームで雑談しながら考えてみました。 本記事は、以下の構成になっています。 雑談のフレームを使い分ける 雑談のチャネル 前半は雑談のパターンを紹介し、後半は実際に私が使っているチャネルを紹介しています。 何か、お役に立つ情報があれば
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
