→プロジェクト管理
→開発体制
→コミュニケーション一般 ←管理職についてはこちら
- 一歩間違えれば部下のやる気を奪う「タダ乗り上司」仕事を“任せる”ことと“投げる”ことの決定的な違い 2011.8.31
- (1)「なぜこの仕事を任せるのか」という趣旨説明を行ない、部下への期待を伝える×:ただ「これ、君に任せるから」ではダメ)
- (2)ゴールイメージのすり合わせについてのコミュニケーションを、しっかり行なう(×:ゴールイメージを曖昧のままで任せるのはダメ)
- (3)部下がゴールイメージを握れたら、その後は細かい指図はしない(×:途中であれこれ細かく指図する、あるいはゴールイメージを握っていないにもかかわらず、部下がやった仕事を自分の感覚でひっくり返すのはダメ)
- こんなメンバーがいると危険 2008.9.4
- 業務知識がないPM、設計できないSE、準備せずにヒアリングするSE…記事にするほどの話か?
- できる人間を担当者にしてはいけない 2008.7.16
- 筆者は,Fさんのような人材は思いきってリーダー格として抜擢し,プログラム実装をさせないという方法をとることが多い。抜擢した優秀な人材に対しては「それぞれメンバーの実装した内容をチェックし指導する」ということをミッションとして与えている。この意図は,Fさんのもっている専門性をプロジェクト内部で最大限に発揮するためだ。実際に実装できないリーダーが指摘するのとは異なり,メンバーも指摘を素直に受け入れることができる。開発中のウォークスルーも簡単に実施できる。何より各メンバーの実装スキルをプロジェクトを通して大幅に引き上げることができるからである。
- 二義的な効果として,優秀な人材が自分が担当する実装個所を持っていないことから,より機動的に他のチームへの応援ができる。また,チーム発足当初からリーダー格として位置づけているため「技術的な相談は○○さんに」というメンバーとの関係も築きやすい。これが同格のメンバー間だと,お互いに暗黙のうちにライバル視することになってしまう。PMがそのプロジェクトの中で最も技術的に優れている場合で無い限り,この専門性に関するメンバー間のコンフリクトを解決するのは時間がかかる。
- 常識ではありえないことがまかり通る現場 2008.3.19
- 無断で遅刻しても罪悪感を感じない(当たり前だと思っている)
- 情報が権力の源となるため,伝えるべき情報を誰にも伝えない
- 正当な理由で客に怒られても反省なし。内部の会議では客の悪口で盛り上がる
- 偽装請負の認識が全くない
- 必要なソフトウエア・ライセンスがなく,試用版を使いまわしている
- 悪習は地位や権力があればあるほど,その「まぁいいか」がプロジェクト全体に広まっていき,「気が付いたら,どうしようなもい悪習になっていた」というケースが頻発しています。外部からプロジェクトに参画するとよく分かるのですが,当事者たちはその文化に慣れきっているため,すぐに習慣を改めることはできません。
- 職人をいかす環境づくり 2008.2.6
- 職人が作る成果物は,高品質ですばらしいものです。しかし,顧客から見ると,その一番高い品質の成果物が基準になってしまいがちです。他のメンバーが作る成果物にも,その“職人品質”を求めてきます。
- 開発工程を別々に担当してはいけない 2007.10.23
- 良いチームを育てるには 2007.5.15
- (1)プロジェクトチームの進化プロセスを知る
- プロジェクトチームは次のようなプロセス(段階)で進むのが良いとされている。
- Forming(チーム形成)
- →Storming(嵐の状態)
- →Norming(チーム意識形成)
- →Performing(目的志向の行動)
- →Adjourning(解散)である。
- (2)オープンなコミュニケーションができる土壌を作る
- (3)プロジェクトの進め方について具体的なビジョンを設定する
- (4)リーダーシップを発揮する
エンジニアリングマネジメント/ピープルマネジメント†