開発チームの構築

→プロジェクト管理

• 1on1.md 2019.10

• 「ほう・れん・そう」を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. 「廊下での使い勝手テスト」を行っているか？ 

• デッドライン
  • プレッシャーをかけられても思考は速くならない
  • 会議は、重要ではない人物が出席しなくても心配ないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである
  • わたしは、自分が主催するミーティングでは必ず、

    * 議事予定表（日時、場所、議題一覧）をメールで事前共有
    * ミーティング前に、ホワイトボードの端に議題一覧を書いておく（終わったらチェック印）
    * 開始の呪文「今から皆さんの時間を○○分使って、まず□□、次に△△… を決めます」で始める

    を実践している。また、上記の条件を一つも満たさない会議には出席しない（あるいは退席する）ようにしている。