開発チームの構築の履歴(No.4)

→プロジェクト管理

一般
エンジニアリングマネジメント/ピープルマネジメント
心理的安全性

一般†

アジャイル開発現場におけるTips：複数チームのチーム名 | 豆蔵デベロッパーサイト 2023.3
- 順序のある名前、個人名はNG

「要員調達」でミスをしないためのポイント | Think IT（シンクイット） 2022.10

Things Strong Developers Do That Drives Their Team Crazy - DEV Community 👩‍💻👨‍💻 2022.10

開発チームにおける生産性とは - Mirai Translate TECH BLOG 2022.10

この振り返り手法のココが良い・ココが悪い❗️(KPT, FDL, 喜怒哀) - Qiita 2022.9

全Qiita民に見てほしい！岡田監督のメッセージ：「自ら考えて動く」チームを育てる、グローバル水準の組織作りのメソッド - Qiita 2022.8

無駄な会議を減らす基本的・具体的な手順 - Qiita 2022.8

「丸投げ」と「任せる」の違い　ー「任された」と感じさせる指示とは？ - Qiita 2022.6

メンバーの当事者意識はリーダーが育てるもの - orangeitems’s diary 2022.1

開発チームメンバーの情報発信を後押しする為にやってみたこと - Qiita 2022.1
- 人に聞かれれば答えるけど自分からは積極的に発信しない人を後押しする為にSlack Appを作ったという話

エンジニアにおける"難しい人"への対処法 - Qiita 2021.1

「ほう・れん・そう」を15分の朝会に置き換える 2011.9.30

一歩間違えれば部下のやる気を奪う「タダ乗り上司」仕事を“任せる”ことと“投げる”ことの決定的な違い 2011.8.31
- （1）「なぜこの仕事を任せるのか」という趣旨説明を行ない、部下への期待を伝える×：ただ「これ、君に任せるから」ではダメ）
- （2）ゴールイメージのすり合わせについてのコミュニケーションを、しっかり行なう（×：ゴールイメージを曖昧のままで任せるのはダメ）
- （3）部下がゴールイメージを握れたら、その後は細かい指図はしない（×：途中であれこれ細かく指図する、あるいはゴールイメージを握っていないにもかかわらず、部下がやった仕事を自分の感覚でひっくり返すのはダメ）

部下のやる気を引き出す！--デキる管理職になるための仕事術 2011.8.3

プロジェクト炎上に恋愛のもつれあり？（1） 2010.1.27

こんなメンバーがいると危険 2008.9.4
- 業務知識がないPM、設計できないSE、準備せずにヒアリングするSE…記事にするほどの話か？

できる人間を担当者にしてはいけない 2008.7.16
- 筆者は，Fさんのような人材は思いきってリーダー格として抜擢し，プログラム実装をさせないという方法をとることが多い。抜擢した優秀な人材に対しては「それぞれメンバーの実装した内容をチェックし指導する」ということをミッションとして与えている。この意図は，Fさんのもっている専門性をプロジェクト内部で最大限に発揮するためだ。実際に実装できないリーダーが指摘するのとは異なり，メンバーも指摘を素直に受け入れることができる。開発中のウォークスルーも簡単に実施できる。何より各メンバーの実装スキルをプロジェクトを通して大幅に引き上げることができるからである。
- 二義的な効果として，優秀な人材が自分が担当する実装個所を持っていないことから，より機動的に他のチームへの応援ができる。また，チーム発足当初からリーダー格として位置づけているため「技術的な相談は○○さんに」というメンバーとの関係も築きやすい。これが同格のメンバー間だと，お互いに暗黙のうちにライバル視することになってしまう。PMがそのプロジェクトの中で最も技術的に優れている場合で無い限り，この専門性に関するメンバー間のコンフリクトを解決するのは時間がかかる。

一見ヒマな予備兵力 2008.7.10

常識ではありえないことがまかり通る現場 2008.3.19
- 無断で遅刻しても罪悪感を感じない（当たり前だと思っている）
- 情報が権力の源となるため，伝えるべき情報を誰にも伝えない
- 正当な理由で客に怒られても反省なし。内部の会議では客の悪口で盛り上がる
- 偽装請負の認識が全くない
- 必要なソフトウエア・ライセンスがなく，試用版を使いまわしている
- 悪習は地位や権力があればあるほど，その「まぁいいか」がプロジェクト全体に広まっていき，「気が付いたら，どうしようなもい悪習になっていた」というケースが頻発しています。外部からプロジェクトに参画するとよく分かるのですが，当事者たちはその文化に慣れきっているため，すぐに習慣を改めることはできません。

職人をいかす環境づくり 2008.2.6
- 職人が作る成果物は，高品質ですばらしいものです。しかし，顧客から見ると，その一番高い品質の成果物が基準になってしまいがちです。他のメンバーが作る成果物にも，その“職人品質”を求めてきます。

開発工程を別々に担当してはいけない 2007.10.23
良いチームを育てるには 2007.5.15
- (1)プロジェクトチームの進化プロセスを知る
  - プロジェクトチームは次のようなプロセス（段階）で進むのが良いとされている。
  - Forming（チーム形成）
  - →Storming（嵐の状態）
  - →Norming（チーム意識形成）
  - →Performing（目的志向の行動）
  - →Adjourning（解散）である。
- (2)オープンなコミュニケーションができる土壌を作る
- (3)プロジェクトの進め方について具体的なビジョンを設定する
- (4)リーダーシップを発揮する

ジョエル・テスト

開発チームのクオリティを測るテスト

  1. ソース管理システムを使っているか？
  2. １オペレーションでビルドを行えるか？
  3. 毎日ビルドを行うか？
  4. 障害票データベースを持っているか？
  5. 新しいコードを書くまえにバグを修正するか？
  6. 更新可能なスケジュール表を持っているか？
  7. 仕様書を持っているか？
  8. プログラマは静かな労働環境にあるか？
  9. 買える範囲で一番良い開発ツールを使っているか？
 10. テスト担当者はいるか？
 11. プログラマを採用するときにコードを書かせるか？
 12. 「廊下での使い勝手テスト」を行っているか？

デッドライン
- プレッシャーをかけられても思考は速くならない
- 会議は、重要ではない人物が出席しなくても心配ないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである
- わたしは、自分が主催するミーティングでは必ず、
```
* 議事予定表（日時、場所、議題一覧）をメールで事前共有
* ミーティング前に、ホワイトボードの端に議題一覧を書いておく（終わったらチェック印）
* 開始の呪文「今から皆さんの時間を○○分使って、まず□□、次に△△… を決めます」で始める
```
  を実践している。また、上記の条件を一つも満たさない会議には出席しない（あるいは退席する）ようにしている。

↑

エンジニアリングマネジメント/ピープルマネジメント†

エンジニアのオンボーディングでフル活用している社内交流制度 | Wedding Park CREATORS Blog 2022.12

ワールドカップとGoogleから学ぶ、多様性と共に磨く、いい雰囲気づくりエンジニアリング - Qiita 2022.12

エンジニア組織向上のために行ってきた施策と振り返り - Qiita 2022.11

7年の体験から書く技術組織のマネジメント（前編） - エス・エム・エスエンジニアテックブログ 2022.10

Ryuzee氏に学ぶ『エンジニアリングマネージャーのしごと』 #Forkwell_Library | DevelopersIO 2022.9

エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita 2021.12

1on1.md 2019.10

↑

心理的安全性†

｢心理的安全性の格差｣が組織に与える重大リスク | リーダーシップ・教養・資格・スキル | 東洋経済オンライン | 社会をよくする経済ニュース 2023.1

組織の力学【心理的安全性シリーズ 2/3】 - Qiita 2023.1
- 集団浅慮に陥る原因
- 1.集団凝集性が高い
- 2.外部情報が入らず閉鎖的な状態である
- 3.リーダーや専門家の存在など特定の人の知識や権力が強い
- 4.集団が過度のストレスにさらされる
- 5.決定することに参加者の利害が発生する

何故、率直な発言が出来ないのか？【心理的安全性シリーズ 1/3】 - Qiita 2023.1
- 高い成果を上げるチームは、ミスが少ないという仮説を検証した所、
- 有能なチーム程、ミスを多くしているという事がわかった。
- 有能なチーム程、ミスが多いのは、何故か分析した所、実は、有能なチームは、ミスが多いのではなく、ミスの報告数が多かった。
- 率直に発言が出来るようなチームだから、高い成果を出せるという事を発見した。
- (逆を言うと、「率直な発言が出来ない」と言う事が業務にマイナスの影響を与えていると言う事である。)

心理的安全性の構造デブサミ2019夏 structure of psychological safety 2019

「きっかけ」しか与えない上司のもとで、挑戦は増えていかない　心理的安全なチームをつくる「お返し言葉」の重要性 - ログミーBiz 2022.9
- 「なんでできなかったの？」とか「なんでこうなったの？」という「Why？」の質問
- 「なんで終わってないの？」→「止まっていることってなんですか？」
- 「前にも言ったよね…」
- 「こんなこと言いたくないんだけど…」
- 「仕事なんだからそんなこと考えないでやるんだよ」
- 相手がまだ話している途中でも、「それはさ、こうすればいいんじゃない？」みたいな感じで、良かれと思ってアドバイスし始めてしまいます。「アドバイスの誘惑」
  - 「ちょっと思ったことを言ってみてもいいですか？」

心理的安全のためにマネジャーがきょうからできる7つの習慣 - Qiita 2022.6
- 対等に話す
- 腕組み・足組みしない
- 上機嫌でいる
- 失敗談を話す
- 「私は聞いていない」と言わない
- 部下の変えられない部分を受け入れる
- 会議中に部下を認める

心理的安全性の作り方とは？用語の解説から高め方ま…｜Udemy メディア 2022.6

炎上を招く「気付いているのに沈黙する現場」が生まれる理由　今「心理的安全性」が注目される2つの側面 - ログミーBiz 2022.5

「心理的安全性」を真剣に考えていたら出川イングリッシュにたどり着いた - Qiita 2022.3
- 「対人関係のリスクを取っても安全だという共通の信念」。なんか小難しいけどさあ、英会話はもとより、ソフトウェア開発におけるチームビルディングでも、失敗を報酬に変換できるレベルで自分自身に美味しい価値として利用する勇気と、失敗をむしろ加点として、称賛して、面白がれる仕組みがあるといいんだろうな

心理的安全性とは――「ぬるま湯」ではない、おさえておくべき意味を解説 - 『日本の人事部』
- 米Googleが2012年から行ってきた「プロジェクト・アリストテレス」という生産性向上計画が関係しています。Googleは本プロジェクトの中で自社の数百にも及ぶチームを分析の対象として、どのようなチームがより生産性が高い働き方をしているのか調査をしました。
- その結果、チームメンバーの能力や働き方によって生産性が左右されるのではなく、他者への心遣いや、どのような気づきも安心して発言できるという心理的な要素が、生産性に影響していることがわかりました。

開発チームの構築 の履歴(No.4)

一般†

エンジニアリングマネジメント/ピープルマネジメント†

心理的安全性†

開発チームの構築の履歴(No.4)