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

一般†

強い開発チームを作るのに心がけていること | 豆蔵デベロッパーサイト 2023.12

中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン #新人プログラマ応援 - Qiita 2023.12

チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s 2023.10

開発チーム作成ガイドを公開します - Cybozu Inside Out | サイボウズエンジニアのブログ 2023.7

開発チームの組織を設計するときに考えたこと - dely Tech Blog 2023.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

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

一般†

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

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