危機対応覚え書き - レジデント初期研修用資料
ファーストサーバーの事故対応や、そのユーザーである「前代未聞空前絶後の無限地獄に叩きこまれた」「阿鼻叫喚のハンバーガーヒルを駆け抜けたサーバ管理者」の方々の、いろんなつぶやきを読んで考えたこと。 口をひとつに 危機対応を行う際には、判断に専念するリーダー役と、発表やコミュニケーションに専念するネゴシエーターと、できれば別々に、それぞれ専属の誰かを置いたほうがいい。 危機の当初は情報が錯綜するし、危機に対応する側も、あるいはその危機から被害を被った側も、様々な「当事者」が情報を発信する。危機に対応する側は、恐ろしく忙しいことになっているにせよ、この情報を放置してしまうと、2ちゃんねるあたりに「現場の声」が匿名で掲載され、ニュースになって収拾がつかなくなってしまう。 佐々淳行の本では、危機対応のリーダーを決定したら、「まずは緘口令をしけ」と説く。記者の人たちが何を聞いても、「命令」がそこにあれ
redmineで案件を回したいんですよ!! - お前の血は何色だ!! 4
redmine さんでどうやったら綺麗にプロジェクトとが回るか考えてみた。 やりたい要件。 ・五月雨式に案件が降ってくるのが困る。 ・その修正は、ただの思いつきなのか、戦略なのか明確にしたい。 ・修正点や活動の記録がほしい。 ・できれば、ソース管理とかと連動してくれたらいいな。 ・運用フェーズも、新規大型リリースフェーズも、インフラアラートもすべてできないと嫌だ。 ・エスカレーションするんだってばさ!! ・複雑奇っ怪なワークフローは No Thank you サブプロジェクトかトラッカーか 例えば、企画と開発とデザインとサポートがあったとして、こいつらは、サブプロジェクトにするべきかどうか。 ほげほげプロジェクト +企画サブプロジェクト +開発サブプロジェクト +デザインサブプロジェクト +サポートサブプロジェクトor ほげほげプロジェクト トラッカーに 企画,開発,デザイン,サポートを作
無差別に技術をついばむ鳥ネタつつき121 - プロフェッショナルな叱り方
前回、叱り方は難しいと書いたので、叱り方について書きます。色々な職業の人を観察したところ、尊敬されるプロフェッショナルは皆、非常に叱り方が上手い事に気付きました。そのプロフェショナルな叱り方から非常に多くの事を学べます。 プロフェッショナルな人達の叱り方は様々ですが、共通した要素があります。それは、人格否定をせずに問題について考えさせる事です。叱り方が下手な人は、無闇に怒鳴ったり、ネチネチと説教したりします。しかし、そんなネガティブな叱り方をするとマイナス効果しか生まれません。人間関係を壊し、相手が委縮する事によりさらなる失敗が生まれるだけです。そんな状態でよい仕事が出来る筈がなく、ネガティブな叱り方をする人は、チームの生産性を低下させてしまいます。でも、下手な叱り方をしたい人は稀です。なぜそんな下手な叱り方になってしまうのでしょうか？ 私が分析したところ、叱り方のうまさは焦点に合わせ方に
『「アドバイザー」と「実行する人」』
世の中、いろいろ間違ったことを言う人はいるが 将来起業したいと思っているならまずはコンサルティングを 経験した方がよい、などと学生にアドバイスする人は とりわけ的外れな人だと思う。 参謀キャリアと事業リーダーキャリア、どちらを目指すべきとか 言っているのではない。どちらも面白いと思う。ただ、両者は 極端に異なる。 私はマッキンゼーに１０年以上在籍し、ひとさまの事業に 「べきだ」を連発してアドバイスするうちに、自分もやれば できる錯覚に陥って起業し、とんでもない失敗をフルコースで やらかして４年間も赤字をぶっこいた。 起業してから８年以上たつが、今日まで一日たりとも迷いや 怯えのない日などない。自分の未熟さとの戦いがずっと 続いている。 そんな私の言うことだから、信じて良いのか悪いのか、 ビミョーかも知れないけど、 起業や事業リーダーのキャリアを目指すなら コンサルティングには近づかない方が
The Drucker Exercise
Forming a team is always awkward at first. You are all new to each other, nobody knows what anyone likes or dislikes, and you are all in the same boat trying to figure out how you can all work together. Instead of letting people stumble upon how you operate tell them upfront! You can do this in a clear focused way using what I like to call The Drucker Exercise. The Drucker Exercise The Drucker Exe
パーソナルPM一問一答
「パーソナルPM」という言葉を見聞きされたことがあるでしょうか。個人の活動にプロジェクトマネジメント（PM）のノウハウや手法を適用するものです。 この定義に対して、次々に疑問が出てくるのではないでしょうか。「組織の手法を個人に適用できるのか」「具体的に何をするのか」「面倒ではないのか」「効果はあるのか」などなど。 そうした疑問に答えるべく、パーソナルPMを研究してきたプロフェッショナルの手による「一問一答」をお届けします。 一問一答の筆者は、プロジェクトマネジメント学会パーソナルPM研究会のメンバーです。この研究会はIT、エレクトロニクス、金融などの分野でPMの実務経験を持つプロフェッショナル、あるいは個人のPMに強い興味をもつ有志で構成されています。 パーソナルPM研究会は3月に、入門書『PM術を徹底活用！ONでもOFFでもパーソナルプロジェクトマネジメント』を出版しました。今回公開する
アジャイル開発手法「SCRUM」の真実
スクラム（SCRUM）という開発手法がある。一時期雑誌をにぎわせたさまざまなアジャイル開発手法群のうちの1つである。日本国内で実際の導入事例はないが、米国では提唱者のケン・シュエイバー（Ken Schwaber）氏によって着実に導入実績を積み重ねているという。今回公開する「スクラムワークショップ体験記」は、筆者2名が日本人として初めて認定スクラムマスターを授与されたワークショップの様子を報告したものである。 米国のソフトウェア開発業界における独立系コンサルタントの躍進とアジャイル開発手法群の台頭という現象は切っても切り離せないものだ。このことは、XP（eXtreme Programming）の提唱者であるケント・ベック（Kent Beck）氏をはじめ、ソフトウェア開発手法に関する分野の“カリスマ”が日本のソフトウェア開発業界に紹介されたことからも記憶に新しい。米国のこのような動きは日本にも
「10分でスクラム」、アジャイル開発の「スクラム」に興味がわいた方へ
今週は、野中郁次郎氏とジェフ・サザーランド氏というアジャイル開発手法「スクラム」の生みの親2人が基調講演を行った歴史的イベント「Innovation Sprint 2011」のレポートを2本公開し、たくさんの方に記事を読んでもらうことができました。 スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） この記事きっかけに「スクラム」に興味を持ったという読者もおられたようで、そんな方のために（かどうかは分かりませんが：-）、「Innovation Sprint 2011」の実行委員長だった川口恭伸氏が「10分でスクラム」というスライドを公開しました。
PMBOK - Wikipedia
PMBOK（Project Management Body of Knowledge、頭字語として「ピンボック」と読まれることがある）は、「プロジェクトマネジメント知識体系ガイド」（英語: A Guide to the Project Management Body of Knowledge、略称： PMBOK Guide、PMBOKガイド）の略語である。PMBOKガイドは、プロジェクトマネジメント協会 (PMI) が発行している。 概要[編集] プロジェクトマネジメントの知識を体系化したものである。第6版までは10の知識エリアと5つのプロセス群から定義されているものであり、第7版からは12の原則と8つのパフォーマンス・ドメインから定義されている。また、ソフトウェア開発のプロジェクト管理において必要な知識体系である。 PMBOKガイドは、国際的に標準とされているプロジェクトマネジメントの知
NBonline （日経ビジネスオンライン） - 宮田秀明の「経営の設計学」
このコラムについて 経営には「論理」が必要である。論理を積み重ねた理系思考がイノベーションを育む。技術力を最大限に生かし、プロジェクトをまとめ上げ、新しいビジネスを創造する。「理系の経営学」を提唱する東京大学の宮田秀明教授が理系の視点による経営の要諦を語る。 記事一覧 記事一覧 2012年3月30日 最終回：「経営の設計学」と歩んだ6年間 私を支えた愛車たち 「経営の設計学」がついに最終回を迎えた。6年にわたる連載を振り返りつつ、終生の友であるクルマについて談義する。ハチロクの設計思想には同意できなかった。現在のお気に入りはメルセデスベンツの「SLK350... 2012年3月23日 戦わなかったのか？ 戦い方を間違えたのか？ 絆だけで被災地の復興は成功しない 「先生のおっしゃることはよく分かります。でも私たちには力がありません」。かつて、造船業界の経営者たちは、戦うことをやめてしまった。
本質を学ぶ：経営とIT新潮流
Copyright (C) 1995-2008 Nikkei Business Publications, Inc. All rights reserved. このページに掲載されている記事・写真・図表などの無断転載を禁じます。著作権は日経BP社，またはその情報提供者に帰属します。 掲載している情報は，記事執筆時点のものです。
リコー遠藤副社長が指南！間違いだらけの業務改革
経営効率を高めるうえで、業務改革は不可欠です。ところが、業務改革が長続きせず途中でとん挫したり、期待以上の成果が出なかったりと、あまりうまくいっていない企業が多いのも事実です。 そこで、数々の業務改革を手掛け、成果を上げてきたリコー取締役副社長執行役員の遠藤紘一さんに、うまくいかない根本的な原因を明らかにして、成功するための処方せんを提示していただきます。 このコラムは、日経情報ストラテジー2008年7月号から同12月号まで6回に渡って連載していただいた「リコー遠藤副社長が現場リーダーに指南 間違いだらけの業務改革」を転載したものです。日経情報ストラテジーの連載時には、読者から好評を博しました。 業務改革にまつわる本質的な問題点と解決策を具体的な事例によって分かりやすく説明しているので、とても参考になります。業務改革に関する間違った見方が修正され、成果に直結する新たな気づきが得られると思い
Painless Functional Specifications – Part 1: Why Bother?
I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新任PMがついやってしまうNG集 インデックス － ＠IT自分戦略研究所
Redmine.JP — Redmine日本語情報サイト
