記事一覧
モチベーション3.0を刺激するプラクティスを考えよう(#28)
この記事の初出は、Software Design 2024年7月号です。
新しいプラクティスを試行するハピネスチームビルディングの活動として、筆者のチーム全員で「新しい技術・ツール・プラクティス」を提案して試行することを本連載の第6回(以下リンク先)で紹介しました。
その活動により、これまでの連載で紹介してきた様々なプラクティスが生まれ、チームが主体的に成長し続けるようになりました。
読者の方
会議で主体的に発言してもらえるようにする(#27)
この記事の初出は、Software Design 2024年6月号です。
会議で発言してもらいたいチームの会議で参加者に発言してもらいことはよくあると思います。
今回は、そういう会議でメンバー全員から積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。
参加者から積極的に発言してもらいたい会議は色々ありますが、以下に2つの例を挙げます。
1つめはUXレビューです。
筆者の
マネジメントのやり方や考え方を記事に書こう(#24)
この記事の初出は、Software Design 2024年3月号です。
マネージャーは何の記事を書けばいい?「ハピネスチームビルディング」では、新しい技術・ツール・プラクティスを積極的に試行して、得た知見をアウトプット(技術記事で情報発信)する事を繰り返して、皆で楽しく成長する事を目指しています。
その中でポイントになるのが、記事を書く習慣を身につける事です。
本連載の第10回では、マネージャ
誰に対してもリスペクトの気持ちを持って接する(#23)
この記事の初出は、Software Design 2024年2月号です。
はじめに技術が多様になった現代では、誰に対してもリスペクトの気持ちで接して、自分の知見になる事があったら吸収しようという真摯な姿勢が大切です。
チームメンバー同士でも、いつもお互いにそういうスタンスでコミュニケーションできると、開発も楽しく取り組めるようになると思います。
リスペクトの気持ちで接しようとする際、普段の言葉
報連相に対して毎回感謝を添えてフィードバックする(#22)
この記事の初出は、Software Design 2024年1月号です。
報連相の重要性チームの皆で楽しく円滑に開発をするためには、コミュニケーションとしての基本である報告・連絡・相談(以下、報連相)は重要です。
報連相に問題があると、非効率な方法で仕事を進めたり、間違った方針で成果物をつくったりすることで、手戻りが発生してしまい、開発生産性が低下します。
実際に、過去の筆者のチームでは、報連相
過去を振り返るポエムを書いて、なぜ働くのかを皆に発表する(#21)
この記事の初出は、Software Design 2023年12月号です。
ポエムを書く目的チームのメンバーがお互いのことを理解し合うことは、皆で楽しく開発するために大切な要素です。
前回では、お互いの理解を深めるための施策として、ドラッカー風エクササイズを紹介しました。
今回は過去を振り返るポエムを書いて働くモチベーションについてチームの皆に発表するという方法を紹介します。
この方法は、fu
ドラッガー風エクササイズでお互いの期待を理解する(#20)
この記事の初出は、Software Design 2023年11月号です。
各自の力をより発揮するためにチームの皆で楽しく開発するために必要な要素は色々ありますが、その1つにお互いのことを理解し合うことがあります。
メンバーがお互いに、どんな価値観を持ち、どんな期待をしているかを理解していれば、それを考慮したタスクの割り当てやコミュニケーションを行えて、各自の力をより発揮しながら楽しく開発できる
リモートワークで新人が楽しく成長できるようにする(#19)
この記事の初出は、Software Design 2023年10月号です。
リモートワークでも新人育成はできる?筆者のチームは、リモートワーク中心の開発チームで、新人育成もリモートワーク中心で行っています。
リモートワークにおける新人育成は、コミュニケーション不足になりやすいため、スキルや業務知識を習得しづらい、職場の人間関係になじめないなどのことが起きやすいと思います。
ただ、コミュニケーショ
自分の考えたオリジナルの振り返り手法で楽しい振り返りに(#18)
この記事の初出は、Software Design 2023年9月号です。
振り返りのマンネリ化筆者のチームでは2~4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。
過去の筆者のチームの振り返りは、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事がありました。
その対策を、本連載の第3回「ファシリテーターを皆に任せて
仕事の進め方の良し悪しを見える化して各自が行動を改善(#17)
この記事の初出は、Software Design 2023年8月号です。
はじめにプログラミング開発をチームで行うためには、プログラミングのスキルだけでなく「仕事の進め方」も大事だと思います。
皆さんのチームで、仕事の進め方の問題により、手戻りが発生してしまったことはないでしょうか。
私は過去にそういう経験があります。
私が駆け出しのマネージャーだった頃、チームメンバーは若手が多く、以下のような
皆で楽しく成長するためのペアプロ・モブプロのやり方(後編)(#16)
この記事の初出は、Software Design 2023年7月号です。
はじめに前回に引き続き、私のチームで実践している「メンバーが楽しく成長すること」を重視したペアプログラミングとモブプログラミング(以降、ペアプロ、モブプロ)のやり方を紹介します。
熟練者は発言を促す熟練者と初級者の組み合わせなどでスキルに差がある場合に、スキルの低い側が開発に貢献する発言を思いつかず、あまりしゃべらなくな
皆で楽しく成長するためのペアプロ・モブプロのやり方(前編)(#15)
この記事の初出は、Software Design 2023年6月号です。
はじめに前回と前々回でペアプログラミング(以下、ペアプロ)とモブプログラミング(以下、モブプロ)の魅力を伝えてきました。
そこで今回は、私のチームでのペアプロ・モブプロのやり方を紹介します。
執筆時点での私のペアプロ・モブプロ歴は4年です。
今回紹介するノウハウの特徴は「メンバーが楽しく成長する事」を重視している点です。
レビュー指摘が多い原因がレビュアーにもある事を共有する(#14)
この記事の初出は、Software Design 2023年5月号です。
はじめにみなさんは開発経験が少ないメンバーが作った成果物(ソースコードやドキュメント)に対して、レビューで大量の指摘をした事はないでしょうか。
私は十年以上前、駆け出しのチームリーダーの頃、そういうことが何度もありました。
大量の指摘を修正してもらうという行為は、手戻りであるため、それだけプロジェクトの進捗を遅らせること
モブプログラミングで楽しく開発する(#13)
この記事の初出は、Software Design 2023年4月号です。
モブプログラミングとは楽しいチーム開発をする方法の1つに、モブプログラミング(以下、モブプロ)というものがあります。
モブプロとは、3人以上で1つの画面を見て議論しながら開発することです。
キーボードを操作する1人を「タイピスト」、タイピスト以外のその他すべての人々を「その他のモブ」と呼びます。
モブプロの詳細について