デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
ssig33.com - エンジニアならこれ読んどいた方がいいみたいな本
失敗学 (図解雑学) 賢者は歴史に学び、愚者は経験に学ぶという。その仮定が正しい場合、人類の知能はそこまで広く分布しているわけではないので人類はだいたいみんな歴史からは学べないということになる。 正直自分の実感としても他人の失敗事例から学べたということは少なく(歴史から学ばない態度)、人は自分の失敗から学ぶしかないのではないかと思う。ただまあ他の技術者が事故にどのように対処したかとか、対処に失敗したかとか、歴史から学べた稀有な事例は何かといったことを読むのは楽しい。 爆笑問題のハインリッヒの法則―世の中すべて300対29対1の法則で動いている (祥伝社黄金文庫) ハインリッヒの事故防止の研究とは何の関係もないけど、爆笑問題カーボーイが一番面白かったころの本。今読んでも面白い。 Web業界 受注契約の教科書 Textbook for Business Contracts in the Web
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とその対策について※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。 「自分が開発すればこのくらいでできる」問題上司「この間言ってたプロジェクトの見積もりできた？」 マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」 デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」 プログラマ「PHP未経験なんだけど大丈夫かなあ…」 .... 略 .... 上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」 マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたん
トラブル原因分析を、責任追及の場にしてはいけない | タイム・コンサルタントの日誌から
新製品の出荷を2ヶ月後に控え、新しい製造ラインの試運転前調整に入っていたある日、工務部門の担当者であるあなたのところに、ライン設置工事を請け負っていたエンジニアリング会社のプロマネから、とんでもない知らせが舞い込んできた。その会社の技術者が機械の操作ミスをしたらしく、製造機械の一部が破損してしまったというのだ。さっそく現場に飛んでいって様子を見てみる。残念ながら機械カバーがねじ曲がり、内部もダメージを受けている。幸い、人がけがをするようなタイプの破損ではないので、労働災害はなかったが、明らかに修理・再製作が必要だ。 エンジ会社のプロマネは装置のメーカー技術者を呼んで調べさせたが、いったんラインから取り外して、自社の工場に持ち帰る必要があるという。まずいことに、その装置はラインの中核近くにあり、周囲の機械設備をとりはずさないと動かせない。あなたは搬出と再製作にどれくらい時間がかかりそうかたず
あなたは、どう考えるの？ | タイム・コンサルタントの日誌から
「佐藤さん、すみません、ちょっとご相談があるんですが・・」 若手社員が机の前にやってきて、顔を上げたわたしに、いいにくそうな声でぼそっときり出した。わたしが、ITリッチなプロジェクトをやっていた時代のことだ。 －－なあに？ 何か、いい話かな？ 「いえ、あの・・。例の中間在庫ロットなんですが、どうしようかと悩んでいまして。」 －－そこは新しいコード体系を使おうって、先週の打合せで決めたじゃないか。 「そうなんですが、注文書のシステムで、ちょっと困ったことが見つかりまして。あのままでは、番号がかち合ってしまう可能性があると分かったんです。」 彼は仕様書の該当箇所をわたしに見せて、問題を詳しく説明する。なるほど、先週の打合せでは、この点を見落としていたらしい。 －－つまり、このまま進めば、ユーザに運用を変えてもらって、少しだけ手間が増えるのを我慢してもらうか、さもなければシステムの設計変更をする
稼働率100%をねらってはいけない | タイム・コンサルタントの日誌から
多くの製造業においては、工場の稼働率が、重要な管理指標として今も使われている。3週間前のエントリ「原価の秘密 － なぜ、黒字案件だけを選別受注すると赤字に陥るのか 」（2014/07/06）でも説明したように、製品の個別原価を計算する際、材料費や労務費などの他に、製造機械の使用時間に応じた費用を含めるのが普通だ。その製品の加工作業で、製造機械が何時間必要だったかをベースに、機械のコストをチャージする。いわば“機械の使用料”だ。 個別の機械1時間あたりの使用料単価を『機械賃率』と呼ぶが、これは各機械の年間の維持費用（減価償却費等）を、年間の実稼働時間で割って計算する。機械の遊んでいる時間が多いほど、実稼働時間は減るから、同じ作業をしていても原価が上がる、というのがふつうの会計の仕組みだ。だから、製造業では稼働率を上げるべく、あれこれと努力するという訳である。 そして、前回のエントリを読まれた
プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ（ロンドン金融街）全体の投下コストは、総額5億ポンドに上っていた。証券取引所のＰ・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
コンサルタントはこうして組織をぐちゃぐちゃにする『申し訳ない、御社をつぶしたのは私です。』
「嘘つきは経済学者の始まり」という諺があるが、コンサルタントも入れるべき。 中の人として働いたことがあるので、その手法は分かってる（まとめ:[そろそろコンサルタントについて一言いっておくか]）。だから本書は、徹頭徹尾、黒い笑いが止まらない。騙される幹部が悪いのだが、振り回される社員はたまったものではない。ファームであれジコケーハツであれ、理論武装を「外」に求める人は、予習しておこう。あるいは、コンサルティングを「説得の技術」と捉え、逆にそこから学ぼう。 本書は、マジシャンが種明かしするようなもの。コンサルタントの方法論である「適応戦略」や「最適化プロセス」「業績管理システム」は、役に立たないどころか、悪影響にもなると暴きたてる。著者は経営コンサル業界で30年も働いて、いいかげんこの「お芝居」にウンザリして、懺悔の名を借りた曝露本を出したという。その具体例が生々しい＆おぞましい＆あるある。
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
オーケストラの指揮者かジャズ・バンドのリーダーか － プロジェクト・マネジメントの４つの類型を知る | タイム・コンサルタントの日誌から
前回、「プロジェクト・マネジメントの教育について」（2014-01-27）で、“PM教育の第1ステップは、自分たちが持つべきPM能力がどんなものかを考える”ことだと書いた。あるべき姿が決まらなければ、成長の道筋も決まらないからだ。当然のことである。 ところが、自分の組織に必要な『PM能力』というものに関して、どうも誤解が多いようだ。世の中にあるPM標準、たとえばPMBOK Guide (R)や、それに準拠した資格であるPMP（Project Management Professional）の習得が、「あるべき姿」だと想定している人も多い。あるいは、英国発のPRINCE2や、日本のP2Mでもいいが、これら標準書を教科書のように思い込み、その教科書に自分の現実の方をあわせようとする。これは、プロジェクト・マネジメントの標準化活動がもたらした副作用かな、と感じる。 わたし自身もPMPの資格を持っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織マネジメントのコツ - Speaker Deck