タグ

チームとQiitaに関するlatteruのブックマーク (6)

  • 「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita

    こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ?」「どうして?」「つまり?」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク

    「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita
  • 現職と前職で感じたスクラムの違い - Qiita

    はじめに 今の会社に転職してきて2ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました! 現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。 前職 スクラムを導入するまでの背景 前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き方としてはフル出社になります。 チーム構成は以下で、私はメンバーでした。 チーム構成(7名) ディレクター(PM) 1名 リーダー 1名 アーキテクト 1名 メンバー 4名 はじめからスクラムを導入していた訳ではありませんでした。 開発の流れとしては、クリニックスタッフまたは関係者からディレクター(

    現職と前職で感じたスクラムの違い - Qiita
  • 中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita

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

    中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
  • だれかの進捗をうまく把握できないときのフレーズ集 - Qiita

    ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか? → 進行中です/〜をやっています なにか問題はありますか? → とくにないです 〜までに終わりそうですか? → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ

    だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
  • 完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita

    これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ

    完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
  • [和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita

    こちらのReddit投稿 (https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_account_gave_me_stomach_ulcers/) の和訳記事です。番環境でやらかしかった人シリーズが盛り上がっていたので波に乗って(?)Twitterにヤバすぎる恐ろしい話が流れてきたのをすかさず和訳してみました。やらかしちゃった人というよりはやらかされちゃった人目線ですがいずれにせよそこら辺の怪談話よりよっぽど怖いです。 Dropboxのアカウントのせいで胃潰瘍になった。 皆は誰もが触れたがらない、会社を紐やガムやクリップでつなぎとめている「例のアレ」を見つけたことってある?そういうのって往々にして大型連休前の金曜午後4:45に落ちるし、般若のような様相を呈した上司が「このままだと第二のスターリングラード攻防戦が勃発するぞ

    [和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita
  • 1