「個人と組織」についてリクナビNEXTジャーナル様へ寄稿しました！ - プロジェクトマネジメントの話とか
こんにちは！id:wiz7です。この度、リクナビNEXTジャーナル様へ寄稿いたしました。 アンタ誰！？という方はコチラのプロフィールへどうぞ。 今回は、組織・チームで仕事をする上で必ず発生する「担当割とチームプレー」がテーマです。仕事や組織の形というものはケースバイケースで、一概に「分業はこうあるべき」とは言えないものだとは思いますが、僭越ながら、つたない経験を元に「いまのぼくがかんがえたさいきょうのりそうのそしき」について書いてみました。 当ブログにおける全ての記事の根底にあるのは、「どうしたら少しでも楽しくお仕事・生活できるかな？」の一点です。今回の記事も同様です。 日々仕事している中で、「そういや、男子校みたいなブログで（男子校に在籍したことがないのでわかりませんが……何となく）、あんなこと言ってたな……チョット試してみようかな」などと、少しでもお役に立てましたらブロガー冥利に尽きま
「それ俺の仕事じゃないし…」分業が、あなたとチームを破壊する！？ - リクナビNEXTジャーナル
Photo by JD Hancock こんにちは！はてなブログ「プロジェクトマネジメントの話とか」管理人のwiz7と申します。普段はWebサービス関連の仕事をしています。 僕はプログラム開発から企画寄りの仕事まで、様々な工程を経験してきたのですが、今日は僕がいろいろ見てきた中で考えた、仕事の「担当分担」と「組織のあり方」について書いてみようと思います。 ■ 分業が組織を作り、分業が組織を壊す チーム・組織内の指揮系統を明確化して、担当割りを決めることは、業務を遂行する上でとても重要なことです。 これがないと、みんなが「あ、やべ、このタスクは誰かがやると思っていた……」と、完全放置され宙に浮いてしまったり、逆に、必死に仕上げた仕事を、実は他のメンバーが既にやっていた……「マジかーい！早く言ってよ！（あ、俺もか？）」などという状況に陥りかねません。 組織の統制が取れず、各メンバーもどこに向か
プロジェクトマネジメントの話とか
お久しぶりです。wiz7です。あまりにも久々の更新のため、当ブログを購読登録している方々は「えっ？あんた誰？」とお思いでしょうが、とにかく僕です。僕だって！ 少し思うところがあり、ブログを再開することにしました。今後は心理学を独自のマネジメント論やライフハックと融合させ、現場で検証して得た知見をシェアできれば、などと考えています。考えただけで、予定は未定。 さて、春が来ましたね。新社会人に向けたメッセージがTwitterをはじめネット上で飛び交っていますが、その多くが「働くことはこの上ない、大変な苦行だ！」という前提に基づいたネタだったりします。 それは、ある側面から見れば紛れもない事実でしょう。なので僕は「少しでも楽に、楽しくするには？」などといった怪文書を書き続けているのですが、今回の記事も、その延長線上にあるものになります。 この激動の時代の中で、ちょっとした工夫からの、自由と安心を
コード行数に代わるうまい指標はないものか - UXエンジニアになりたい人のブログ
photo by mutednarayan 超先進企業にお勤めされているスーパープログラマは例外として、それ以外の職業開発者にとって、コード行数という指標は開発業務において大きな位置を占めていると思う。コード行数予測をもとに工期や人員算出をしたり、コード行数をもとにテスト件数や欠陥密度などを測ったり、etcetc。。。 だが、これがどうもよろしくない。コード行数は大まかには見積もり（つまり予測）に使われることと、結果指標に使われることがあるが、どちらにもよろしくない。端的に言えば、予測の段階では「そんな細かいことまでわからない」し、結果の段階では「そんな曖昧なもので正確な評価が行えない」からだ。 見積もりコード行数 そもそも、見積もりを行う時点では仕様と概要アーキテクチャくらいしか決まってないことが多く、この時点で「コードが何行になるか」なんて誰にもわかるわけがない。にも関わらず、（そして
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ
ウォーターフォール開発とアジャイルの本質 - プロマネブログ 以下、３部作の２本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 前回と今回のシリーズはカテゴリ プロジェクトマネジメント論にまとめてます。 単一の開発手法の限界からハイブリッド方式へ 前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。 ウォーターフォール開発（以下WF）であれば、形式知化。 アジャイル開発であれば、フォーカス分割。 これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。 とはいえ、ハイブリ
あなたがリーダーになったら最初に考えること。 - プロジェクトマネジメントの話とか
前回記事 みんなが嫌う「朝会」がプロジェクトマネジメントで大切な理由。 - プロジェクトマネジメントの話とか にて、プロジェクトチーム内の多くのメンバは、基本的に自己中心的で、自分にアサインされた仕事・タスクさえ着実にこなしていれば「チームがどうなろうが知ったことではない！自分の責任じゃないし！」と考えている、と書きました。 では、マネージャー・リーダーはメンバに対して、どう対応したらよいのでしょうか？ スポンサーリンク そもそも、人の価値観を無理やり変えることは難しい まだ脳ミソが柔らかい幼児・小学生ならともかく、数十年生きてきたメンバの考え方を無理に矯正することは難しい。 人はそう簡単に変わらない、という前提に立つ必要があるんですよね。 特に派遣・業務委託などの形で「他社に常駐して作業」していて、チームに貢献して結果を残したとしても、自社の上司からの評価を得られにくい環境にいる場合、「
見積もり根拠の提示方法その巧拙で信頼度が変わる
前回まで、ユーザー企業がソリューションプロバイダの提案書を評価する7つのポイントを紹介してきた。最終回の今回は、特に見積もり根拠の書き方について、その問題点を指摘すると共に、ユーザー企業がどのような視点で見積書を評価しているかを紹介したい。 前回（第5回）、「コストの妥当性」の説明の中でも述べたが、提案書上ではソフト開発の見積もりに関しては総額でしか示されないことが多く、ほとんどの場合、その見積もり根拠は全く示されない。 特に、要件定義工程の前の見積もりでは不明な点が多く、細かな計算式までを提示するのは、ソリューションプロバイダにとってリスクが高い。また、ユーザー企業の業種や業務に対する知識の有無が、その精度を左右することは否めない。しかし、要件をユーザー企業に何度も確認し詰めていくことによって、その精度を高め、競合他社に差をつけることが可能になるはずである。 さらに工程が進み、基本（概要
タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない
さる8月、翔泳社主催の「PM Conference 2008」に招かれて講演をした。テーマはプロジェクト・コントロールの技法論で、私が長い間、エンジニアリング業界とIT業界の二足のわらじを履いてきた経験から、両者の比較を論じたものだった。最近のIT業界における「プロジェクト・マネジメント」の認識の普及進展はめざましいものがある。これに対して、エンジニアリング業界は過去10年以上、EVMSの徹底化以外とくに主立った進歩はない。にもかかわらず、両者の違いはいまだ歴然としたものがあり、それはとくにプロジェクト・コントロールの基本であるWBSやコントロール・リストなどの使い方で明瞭だ、というのが論旨だった。 ところで、この講演の中で、「工程表のガントチャートをExcelで書いてはいけない」と強調した点が、どうも多くの聴衆の注意を引いたらしい。終わってからのアンケートでも、そこに関する感想が少なくな
InfoQ: 複数のアジャイルチームでのバージョン管理
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント（イテレーション）だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図（壁張り用） この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの3+1のポイント | リブセンス
7462