タグ

ブックマーク / qiita.com/kojimadev (9)

  • 中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita

    1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり

    中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
    peketamin
    peketamin 2023/12/04
  • リモートワークで新人が楽しく効率的に成長できたプラクティス - Qiita

    はじめに 私のチームは、リモートワーク中心の開発チームです。 そのチームに新人が配属された時に、私のチームで行っている新人育成のプラクティスのうち、比較的ユニーク(だと思っている)プラクティスを抜粋して紹介します。 少しでも参考になれば幸いです。 リモートワークの知見を説明 新人に対して、チームで行っているリモートワークを快適に行うための知見を紹介しています。 特に、「今から通話いいですか」をすっ飛ばしてビデオ通話を開始する文化であることを共有します。 詳細は以下を参照ください。 インセプションデッキの説明 インセプションデッキとは、プロダクトづくりに関わるメンバーが各々の意見を持ち寄って共通認識をつくり出すための大事な質問に対してメンバー皆で議論して決めた回答です。 詳細は以下を参照ください。 インセプションデッキ | Agile Studio 私のチームでは、以下のテンプレートを利用し

    リモートワークで新人が楽しく効率的に成長できたプラクティス - Qiita
    peketamin
    peketamin 2023/07/27
  • 後輩に対して [君付け]→[呼び捨て+命令口調]→[さん付け+敬語] に変えて学んだこと - Qiita

    はじめに 同じチームの後輩に対して、名前を呼び捨てにするか君付けするか、敬語を使うか使わないか、様々な考え方があると思います。 私の場合は、呼び方や敬語の有無を変えた経験があり、そこから学んだことを紹介します。 最初は君付けだったが 私は最初、同じチームの後輩を「小島くん」のように君付けで呼んでいました。 当時の私は、社会人という意識が低く、会社の後輩に対して学生時代の部活の後輩と同じ感覚で話しかけていました。 しかし、ある時、転機がありました。 上司からすると、私は後輩に甘くて厳しさが足りないところがあったのでしょう。 後輩を呼び捨てするように助言されました。 (※10年前の話で、今ほどリーダーシップの理論も広まっていなかった頃の話です) 学生時代からずっと後輩のことを呼び捨てしたことのなかった自分にとって、それは物凄く抵抗がありました。 しかし、私は後輩に対してもっと厳しく指導すること

    後輩に対して [君付け]→[呼び捨て+命令口調]→[さん付け+敬語] に変えて学んだこと - Qiita
    peketamin
    peketamin 2023/06/15
  • 30代後半になって初めて発信活動を始めたら人生が変わった話 - Qiita

    はじめに 2年半前の私は、IT系の会社に勤めている30代後半の平凡なサラリーマンでした。 その時点では、社外での発表経験なし、社外での勉強会の参加経験なし、技術記事の投稿経験なしでした。 そんな私が発信活動を始めたことで人生が変わりました。 今は凄く楽しいエンジニアライフになり、以下のような事が起きました。 複数のITエンジニア向けコミュニティに所属して楽しく交流 「Serverless LT初心者向け」というコミュニティを立ち上げて運営 Developers Summit 2020 KANSAI でベストスピーカー賞1位を受賞 ITエンジニア向けの月刊誌「Software Design」で連載記事を執筆 すべては発信活動を始めた事がきっかけでした。 発信活動を始めると素敵な事がいっぱいあると知ってもらう事で、発信活動を始めるきっかけになれば幸いです。 (長いので要点を知りたい人は太字のみ

    30代後半になって初めて発信活動を始めたら人生が変わった話 - Qiita
    peketamin
    peketamin 2022/03/09
  • レビューで大量の指摘をして大きな手戻りを発生させた原因はレビューアの私にあった - Qiita

    はじめに 私は十年近く前、レビューで大量の指摘を登録することが何度かありました。 当然、大量の指摘修正をしてもらうという行為は、手戻りであり、それだけプロジェクトの進捗を遅らせることになりました。 とても恥ずかしい話ですが、当時の私は、レビューで大量の指摘で手戻る原因が、レビューイにあると思い込んでいました(当にごめんなさい)。 しかし、今、振り返ってみると、手戻りの原因はレビューアである私にあったと思います。 そのような恥ずかしい自分の行動を戒めるために、どれだけ当時の自分が残念だったのかを紹介します。 要するに反省文のようなものです。 今回対象とするレビューの前提条件 今回紹介するレビューは、以下の条件を満たすものでした。 レビュー対象の成果物は、以下のいずれか。 外部仕様書 設計書 テスト仕様書 ソースコード レビューイは、レビュー対象成果物を作成した経験が浅い(数回の経験)。 レ

    レビューで大量の指摘をして大きな手戻りを発生させた原因はレビューアの私にあった - Qiita
    peketamin
    peketamin 2021/04/21
  • 1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita

    1. はじめに 稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。 稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。 なお、稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。 発表資料と発表動画はコチラ 2. 施策の効果 私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。 あまり積極的に今のやり方を変えようと思っていないチーム メンバーは、中堅(私)が1名と入社2年目と3年目の3人(後に新人が配属して途中から4名に) 全員、技術記事を書いたことがない 全員、社外の勉強会などのイベントに参加したことがない 全員、開発知識は、業務で教え

    1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita
    peketamin
    peketamin 2020/08/28
  • 仕事の進め方の良し悪しを見える化したら、各自が自分で行動を改善してくれた話 - Qiita

    はじめに プログラミングの仕事を効率的に行うためには、プログラミングの知識だけでなく、仕事の進め方も大事と思います。 10年近く前、私のプロジェクト(C#での開発業務)は自分も含めて若手が多く、次のような「仕事の進め方」の問題が多々有りました。 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。 レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。 そこで、当時の私はプロジェクトメンバーの仕事の進め方を改善する方法を考えました。一般的には「問題を見える化」することで問題が改善されると言われています。逆に言うと、問題は見えないままでは改善されません。 つまり、各自の仕事の進め方の良し悪しを見える化が必要でした。従って、仕事の進め方の良し悪しを測るチェックシートを作成し、その評価結

    仕事の進め方の良し悪しを見える化したら、各自が自分で行動を改善してくれた話 - Qiita
  • 毎朝15分の勉強会で若手の設計力がメキメキアップした話 - Qiita

    1. はじめに 稿は、私のプロジェクト(ベテラン1人、開発経験が半年未満の若手2名)で実施している「アウトプット勉強会」の実施方法を紹介します。 この勉強会を実施してから若手の設計・実装スキルがメキメキアップしました。私は過去に新人8人くらいの育成に携わりましたが、これが一番効果的だと思います。 なお、「アウトプット勉強会」の形式は、「書籍編」と「設計・実装編」の2種類がありますが、稿では「設計・実装編」を説明します。「書籍編」の形式については、以下の記事を参照ください。 毎朝15分の勉強会で若手の行動が驚くほど改善した話 稿は、以下の方々が対象です。 若手を育成するために設計する機会を与えたいが、なかなか与えられないリーダー層 → 業務と並行して勉強会を実施するといいと思います。 設計がやりたいけど業務でその機会が与えてもらえない若手 → 上司の手間は毎朝15分だけなので、頼めばや

    毎朝15分の勉強会で若手の設計力がメキメキアップした話 - Qiita
    peketamin
    peketamin 2019/07/03
  • 新人時代に読めば良かったと後悔するほど感謝した技術書4冊 - Qiita

    はじめに この記事は、成り上がりたくて必死に読んだ感謝の技術書6冊を真似した記事です。 稿では、開発経験10年以上の私が、新人の頃に読めば良かったと後悔するほど感謝した技術書を紹介します。 私がこれらのを読んだのは、入社して数年経ってからですが、もっと早く読んでおけば、もっとうまく仕事ができたのにと思いました。以下に、各書籍の概要と、後悔するほど感謝した理由を記します。 感謝の技術書① 『報・連・相の技術がみるみる上達する!』 恥ずかしながら私はこのを読むまでは、報告・相談される相手がどういうタイミングでどういう詳細度で報告・相談して欲しいかということを考えたことがありませんでした。 上司に「報・連・相をしっかりやりなさい」と言われても、その「しっかりやる方法」というのが、それまではよく分かっていませんでした。それが、このを読んで、自分がどれだけ「自分位の考え方」でコミュニケーシ

    新人時代に読めば良かったと後悔するほど感謝した技術書4冊 - Qiita
  • 1