はじめに 私のチームでは、数週間に1度のタイミングで、チームの皆で過去の出来事を振り返って、良かった点や改善点を挙げてチームを改善していく活動を「振り返り」と呼んで実施しています。 今回は、データをもとに振り返りをする方法の紹介です。 前提として、振り返りについて以前に2つの記事を公開していますので、よろしければ参照ください。 チームの皆が積極的に発言する楽しい振り返りにする方法として「ファシリテーターを皆に任せて楽しい振り返りに」という記事を以下で公開しています。 また、そのように全員が積極的に発言する振り返りができるようになっても、だんだんマンネリ化することがあるため、それを防止する施策として、「自分の考えたオリジナルの振り返り手法で楽しい振り返りに」という記事を以下で公開しています。 振り返りのためのデータ計測 前の章で紹介した振り返りのやり方をすれば、チームの皆が積極的に発言する楽

はじめに 今回は、チームのメンバーでお互いの価値観を共有することに適した「ワーキングアグリーメント」という手法を紹介します。 ワーキングアグリーメントとは ワーキングアグリーメント（Working Agreement）とは、チームメンバーが共同作業を行う上での基本的なルールや約束事を明文化したものです。 ワーキングアグリーメントは、チームメンバー全員で話し合って作成することが多いです。 例えば、「会議には遅刻しない」「作成した成果物は翌稼働日までにレビューしてもらう」など、具体的なルールを決めることで、日々の業務を円滑にします。 また、各メンバーがどのような価値観や期待を持っているのかが共有されるので、お互いの理解を深める効果もあります。 チームが発足して間もない時期で、まだチーム内のルールが整備されていない時なんかは、特に効果的だと思います。 詳しくは以下の記事を参照ください。 ワーキン

はじめに モチベーション 3.0 とは、内発的動機づけで行動することです。 詳しくは書籍『モチベーション3.0 持続する「やる気!」をいかに引き出すか』、講談社、ダニエル・ピンク著 を参照ください。 私が今まで「ハピネスチームビルディング」の連載記事で紹介してきたような「皆で楽しく成長するためのプラクティス」を新しく考えてやってみようとする場合に、モチベーション3.0はとても参考になったので、その考え方を紹介します。 モチベーション 3.0 とは モチベーションとは、人が行動を起こすための動機付けのことを指します。これは、モチベーション1.0、2.0、3.0という3つの段階に分けられます。 モチベーション1.0は、生理的な欲求を満たすための「生理的動機付け」です。生存を目的とする最も原始的な欲求です。 次に、モチベーション2.0は、外的な報酬と罰を中心に構築された「外発的動機付け」です。

はじめに チームのメンバー皆に意見を出してもらいたいような会議をすることはよくあると思います。 本稿は、そういう時に積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。 チームの皆に意見を出してもらいたい会議とは いろいろあると思いますが、以下に2つの例を挙げます。 UXレビュー 私のチームでは、開発中のプロダクトに対する改善点を皆で挙げるという活動を行っています。 チーム内では「UXレビュー」と呼んでいます。 具体的には、開発メンバーが開発中のプロダクトを実際にユーザーがよく使うユースケースでどんな体験をするのかをデモしながら説明し、それに対して他メンバーが気付いた改善点を挙げるという活動です。 人によって感じ方が異なるため、複数人で実施して、各自が感じたことを積極的に意見してもらった方が多様な観点での改善が期待できます。 設計レビュー 複数人で開発するプロダクトに対

はじめに 数年前、私は社外のコミュニティに参加する前は以下の状態でした。 技術記事の投稿経験なし 社外での勉強会の参加経験なし 社外での発表経験なし そんな私が、コミュニティに参加した後は、人生が劇的に変わり、エンジニアとして楽しく成長できるようになりました。 現在の私は「ハピネスチームビルディング」というテーマで Software Design というIT月刊誌で連載していますが、そうなったのもコミュニティに参加していたからです。 本稿では、コミュニティに参加することで、楽しく成長しやすくなる話を書きます。 楽しく成長するために刺激し合う仲間は重要 ITエンジニアが成長するために「記事を書く」などの発信活動は有効と言われています。 その発信活動のモチベーションを高めるために、刺激し合える仲間をたくさん作りたいと思っても、自分の会社の文化が発信活動に積極的でないなどで、身近な仲間を作りづら

1. はじめに 私はハピネスチームビルディングというテーマで発信していて、その中では、「記事を書いてアウトプットすると成長しやすい」というものがあります。 ただ、記事投稿を継続することは、なかなかハードルが高いので、それをマネージャーやリーダーがサポートする方法の詳細を以下の記事に書いていますので、よろしければ参照ください。 エンジニアが記事を書くことの有効性は、様々な人が言及していて、エンジニアが成長するために、とても有効なことを間違いありません。 だから、マネージャーの方々の中には、「うちのチームのエンジニアにも、記事投稿を継続することで成長して欲しい」と思っている人は多くいると思います。 実際、今まで私に対して「どうすれば、エンジニアが記事を書くようになりますか？」と質問してくださった方々が何人もいます。 そういう人に対しては、上記の記事の内容を紹介するのですが、その中で違和感を感じ

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

はじめに チームの皆で、働くモチベーションに対して過去を振り返ったポエムを書いて発表してみたら、なかなか良い自己開示になって、お互いの理解度が上がり、心理的安全性が高まりました。 とてもお勧めの手法なので、私のチームで実施した方法を紹介します。 元ネタは、実践「最高のアジャイルチーム」を作る方法 という記事で紹介されている方法です。 上記の記事の「ポエムの重要性」という章には、以下のように書いてあり、それを実践してみました。 「なんで今この会社にこのポジションで働いているんだっけ？」ということを小学校ぐらいからの掘り起こしてみんなで書いてるんですよ。「大学行ってこういう勉強しました。こういう経路で今のポジションに就きました」みたいなことを感情や理由を含めて、書いていくと、人の価値観がすごいわかるんですよね。 これを書くのすごい時間がかかって、コストかかるんですけど、非常に重要です。なぜかと

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

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

1. はじめに 本稿は、ペアプログラミングとモブプログラミング（以降、ペアプロ・モブプロと表記）について、私のチームでのガイドラインを紹介します。執筆時点でのペアプロ・モブプロ歴は4年です。 私のチームは若手が多く、「ハピネスチームビルディング」という皆が主体的に楽しく成長しながら開発するという取り組みをしているため、「メンバーが楽しく成長する事」を重視している点が、普通のやり方と少し異なります。 ハピネスチームビルディングの詳細は、ITエンジニア向け月刊誌「Software Design」で連載してますので、そのWeb公開版の以下を参照ください。 ハピネスチームビルディング連載記事一覧 ペアプロ・モブプロは、楽しく成長するために、とても有効な手段なので、この記事が少しでもその役に立てば幸いです。 なお、ペアプロとモププロは異なる特性がありますが、この記事では共通のガイドラインを説明する便

誰でも始められる！発信活動を継続しながら楽しく成長する方法(Microsoft Build 2022)初心者初心者向け教育コミュニティ新人プログラマ応援 1. はじめに スキルアップには発信活動が良いと言われていますが、3年前の私(38歳)は、技術記事を書いた事も社外発表した事もありませんでした。 そんな私が発信活動を始めたことで人生が劇的に変わりました。 その前の十年以上より、発信活動を始めてからの3年間の方が圧倒的に成長できました。 発信活動をきっかけに、Developers Summit 2020 KANSAI でベストスピーカー賞1位、Software Designで連載執筆、Microsoft Build 2022で発表などの機会をいただきました。 その中で様々なエンジニアと楽しく交流したり、多くの人から感謝されたりなど、人生が楽しくなりました。 本稿では、楽しく成長するために、

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

1. はじめに 私のチームは2019年までは、同じフロアでチーム4人が集まって、ペアプログラミング/モブプログラミング中心で開発し、チームで情報を共有しながらお互いに助言し合って開発していました。 アジャイル開発のチームとして、わりと良い感じにコミュニケーションを取りながら開発できていたと思います。 しかし2020年に、コロナの影響で、突然チーム全員がリモートワークに変わり、それは崩壊しました。 チーム全員がリモートワークの初心者のため、リモートワーク初日は大変な事になりました。 今まで同じフロアで気軽に声をかけあっていましたが、それができなくなり、初日は「楽しくない」開発でした。 翌朝に、皆で初日の感想を話し合った結果、全員が疲労感と孤独感を感じており、今までの楽しかった開発が、一変してしまいました。 こんな状態で、この先、リモートワークを続けていけるのか、皆、とても不安を感じていました

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

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