タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
効果的な 1 on 1 ミーティングのためにマネージャができること
2016 年に逝去した、元 Intel CEO の Andy Grove による High Output Management の日本語訳が復刊され、さらに Hard Things の Ben Horowitz の序文がついたことで、改めてスタートアップ界隈でも 1 on 1 (ワンオンワン) ミーティングの効果が注目され、各社や各人の 1 on 1 のノウハウが共有されるのではないかと期待しています。 Y Combinator の Sam Altman はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
Facebook製。プログラマー向けのプロジェクト管理·Phabricator MOONGIFT
PhabricatorはFacebookが開発しているプロジェクト管理です。ソースコードレビュー、バグトラッキングなど開発者フレンドリーな機能が数多くあります。 企業においてGitHubをソースコードリポジトリ/プロジェクト管理に使っているケースも増えてきていますが、大規模な企業では難しいケースも多いでしょう。そこで紹介したいのがFacebookで開発されているPhabricatorです。 最初にログインを求められます。 ついでユーザ名を入力します。 ダッシュボードです。 チケットの詳細画面です。 ソースコードレビュー。 もちろんコードハイライター付き。 リポジトリビューワー。 コミットログ。 画像付きでディスカッションもできます。 Wiki。 IRCのチャンネルリスト。 PhabricatorではGit/Subversion/Mercurialをサポートしています。また、OSはWindo
ドラクエXはこうして作られた、大規模ゲーム開発におけるマネージメント方法
ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ ということで、CEDEC 2012ではドラゴンクエストXの世界観を支えるサーバシステムはどのように構成されているのか、ということが講演されましたが、さらにドラゴンクエストという人気作品を制作する上でどのようなマネージメントが行われたのか、ということについても、スクウェア・エニックス開発部所属の荒木竜馬さんが大規模開発ならではの問題やそれを解決するための工夫について語ってくれています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/BM/C12_P0003.html 荒木竜馬： 今日はドラゴンクエストの話ということで、朝早くからたくさんの人にお集ま
リソース不足によるプロジェクト崩壊を防ぐ--役割を兼務するメンバーの士気を保つには
わたしは今、顧客と興味深いやりとりをしている真っ最中なのだが、他の顧客や組織も同じ問題で苦しんでいるのかと気になった。この顧客のところでは、開発者として契約したスタッフメンバーが、（リソース不足と人員削減のあおりで）テスターとビジネスアナリスト（BA）を兼ね、時にはプロジェクトマネージャー（PM）の役割も果たすことを求められている。この状況で起きる困難には、リソース管理の難しさ、役割の混乱、スキルの不一致、士気ややる気の低下、そしてビジネス上の成果を上げることの難しさも含まれる。 では、これらの困難についてもう少し詳しく見てみよう。 開発者として投入されたチームメンバーや契約業者がBAやPMの役割も果たさなくてはならない場合、リソースプールの状態を理解したり、管理したりするのが難しくなる。例えば、ある開発者は、ビジネスの分析やプロジェクト管理、テストにどれだけの時間を割いたのだろうか？事業
小さなエンジニアリングチームを成功させるための6つの秘密
By Tayrawr Fortune 世界最大級のインターネット通信販売・ネットオークション企業であるeBayのエクスペリエンス担当副社長を務めるHugh E. Williamsさんは、「小さなエンジニアリングチームを運営することは楽しい」と語ります。技術に親しむことができ、プログラムコードを書く組織のそばにいることができ、実際的な問題に取り組むことができるからだそうです。そして、この小さなチームを運営するためには6つの秘密があるのだと語っています。 6 secrets for successful small teams | Hugh E. Williams http://hughewilliams.com/2012/06/05/6-secrets-for-successful-small-teams/ 1.手本を見せる Williams氏によると、小さなチームのリーダーになった人間が失
ダメなチームはリーダーの責任!? チーム内に漂うイヤな空気を察知せよ | 経営 | マイコミジャーナル
最近読んだ本に「毎日新しい自分になることが成功への近道」と書かれてあった。わかるような気がする。また、こうも書かれてあった。仕事がある程度できるようになると、それ以上の高みを目指さすに「流して」仕事をするようになりがちであるが、それは「破滅への第一歩なのだ」と。 あなたがもし上司なら、部下が退屈そうに仕事をしたり、ルーチンワークでうんざりしたりという兆候は、いち早く気づいて対処しなければいけない。これを放置すると、チームが停滞ムードに包まれ、創造的な仕事ができなくなるからだ。 Management Excellenceというサイトに「単調さと停滞がはびこっているにちがいない7つの兆候(原題: 7 Signs that Monotony and Routine Have Taken Over)」として、リーダーがどうしたらチームの単調さと停滞を察知することができるかについてのヒントが紹介され
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
