Twitterでのつぶやきの半分以上は組織づくりやマネジメント関連なんですがどこかにまとめたこともなかったので整理の意味も含めて書いていきたいと思います。これが正解だ！なんて言えるわけもなく、個人的な経験をもとに書いていきますので後日読んでくださった方々と語らう場が設けられたら幸せだなと思っています。ですから温かい目と心で読んでくださると幸いです。 マネジメントの基本理念マネジメントの基本理念は「成功したらメンバーのおかげ、失敗したらマネージャーの責任」これに尽きると思います。基本的な役割はメンバーが保有している能力の総和を超える成果を出すことだと考えていますがそのためには上記の理念が欠かせないと思っています。 もちろん組織によって役割はそれぞれだと思いますが、ことベンチャーにおいてはとくに「成果を出すこと」と「人材を育てること」の両軸が必要であり、両立する難易度が極めて高いのですがそれで
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
ネットツールを使って共創しよう、そのために情報共有をしたいなぁと考えたときに、自分がまず最初に思いつくツールはメーリングリスト（ML）です。 レスポンスのスピード感、受送信端末を選ばない、主体的にスレッド（同一タイトルのメールのまとまり）管理ができるという点では、今でも一番の使い勝手だと思います。 会社のドメインもGoogleAppsで運用しているので、ブラウザで簡単に情報整理ができるGmailだと、MLを使った情報共有は最強の環境だと思います。 ただし、メール端末が普及し多くの人のレスポンス速度が上がってくると、今度はそのスピードが早すぎることに問題があるのではないかと感じるようになりました。 特にそれは軽快なツールであるMLに顕著で、参加者全員がメールを土台とした情報共有のスピード感を、仕事の経験値として持っている人たちが集まっていれば問題を感じませんが、そこに携帯メールをポツポツ打つ
「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。
システム開発プロジェクトにおいて何かを決める際、PM（プロジェクトマネジャー）が「みんなで決めよう」と言うようでは問題である。古来より和を重んじる日本人的な発言と言えばそれまでだが、それではうまくいかないのがプロジェクトの持つ独特の性質である。 みんなで決めることにこだわったAさん Aさんは情報システム部門の経験年数が10年になる中堅社員である。彼の上司Yさんは業務部門の現場叩き上げのベテラン社員で、数年前に情報システム部門へ異動してきた。長年少しのミスが大事故につながる現場で過ごしてきたYさんは、常々情報システム部門の仕事の仕方に疑問を抱いていた。そんなYさんに、Aさんはなかなかなじめずにいた。Yさんに対するAさんの思いは「少し厳しすぎるよ。みんな仲間なんだから楽しくやらないと」というものだった。 Aさんが、ある社内システムの開発プロジェクトでPMを任されたときの話である。そのプロジェク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
