Life is beautiful: 会社のカルチャー作りの大切さ
University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け
マネジメント改革の工程表 岸良裕司・著 | タイム・コンサルタントの日誌から
機知に溢れた、楽しい本である。正直言うと私は、（「気まぐれ批評集 書評」のページを見てもらえれば分かるとおり）あまりビジネス書のたぐいを読まない。理由の一つは、書評には最初から最後まで全部読み終えた本だけを取り上げることにしているからだ。ビジネス書はしばしば、必要な箇所だけを参照するために買うので、全部を読み通すことがあまりない。さらにもう一つ、たいがいのビジネス書のスタイルが、肌に合わないこともある。理論の説明中心で教科書的になるか、あるいは雑誌記事的な事例と感想の羅列だけで、通るべき芯が通っていないか、どちらかのケースが多い。そしてユーモアが足りない。 さいわいこの本には、軽快なウィットがあふれている。これは著者の資質のあらわれなのだろう。著者の岸良氏夫妻には、昨年秋のシドニーのプロジェクト・マネジメント国際学会ProMAC 2006の席上でお会いしたこともある。察するに岸良氏は、理論
残業という愚行 - 神様なんて信じない僕らのために
まぁ、一言で言うと（望まずにポーズだけでする）残業って愚行ですよね、と。 まだ読んでいる途中だけれど「デッドライン」からの引用。 プレッシャーをかけても思考は速くならない。 残業時間を増やすのは、生産性を落とす方法である。 一時的なプレッシャーや残業は、人々の焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。 管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからないから、または、ほかの方法の難しさにひるんでいるからである。 恐るべき推測：プレッシャーが残業を使うほんとうの理由は、プロジェクトが失敗したときにごまかすためかもしれない。 ただ残業というものに対して、 「全否定」というわけではなくて必要な時、必要なだけやらなければならないことはある。 それは、要するにどうしてもそうしなければならない
The Now Habit (1) 仕事を先送りしてしまうのは、怠惰だからではない | Lif...
英語では「仕事を先送りする」「ぐずぐずしていて手をつけられない」ことを procrastination という、たった一つの単語で言い表せます。わかってはいるけど、どうしても手が付けられないという状態はどこでも同じようにあるものらしいですね。 仕事に手を付けられずにぐずぐずしているときは、誰だってべつに気分がよいわけではないでしょう。むしろ「自分はなんて駄目なんだ」と自分を責める気持ちのほうが強いはずです。 それでは何で私たちは仕事を先送りしてしまうのか。このテーマについて実践的な対処方法を書いた心理学者 Neil Fiore の The Now Habit という本が、43Folders 経由でこれを知って以来、私の愛読書です。 これから５回にわけて、この本についてご紹介しますが、実際には紹介しきれないテクニックや実例が本には満載されていますので、興味のある人はぜひ原書を当たってみてくだ
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトは冒険だ！「仕事を100倍楽しくするプロジェクト攻略本」
薄くて濃い一冊。 プロジェクトを「まわす」にあたり、本当に必要な内容だけを吟味してまとめてある。ある意味、いさぎよい。頁数を水増し→煽り文を追加→ハードカバーにして、2倍の値段で売っているそこらのビジネス本と180度違う。テクニックよりも心得を重視しており、トム・ピーターズのように読んだ側からソノ気にさせる。 プロジェクトは冒険だ、そして、キミは勇者だ。王さまの話を聞き、仲間を集めてパーティーを編成し、レベルアップに勤しみ、最高のクリアを目指す――なんのことはない、昔っからゲーム相手にしてきたことと一緒。 あのときの「ワクワク感覚」そのままに、プロジェクトの現場を捉えなおしてくれる。この視点はありそでなかった。いちいち激しく頷きながら読む。 本書のエッセンスは、デマルコの「マネジメントの4つの本質」に尽きる。「デットライン」に、こうある。 適切な人材を雇用する その人材を適所にあてはめる
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
ITmedia Biz.ID：失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント
失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント：デジタルワークスタイルの視点 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。Appleやはてな、Googleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。 「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します（2月21日の記事参照）。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。 失敗しない
なぜCCPMなのか | ビーイングコンサルティング
プロジェクトの納期を守るための効果的な管理手法「CCPM（クリティカルチェーン・プロジェクトマネジメント）」。 現在プロジェクトの複雑化やサービスの多様化によって、プロジェクト管理の現場ではプロジェクト遅延やコスト増大・品質低下など深刻な問題が発生しています。 それにより、既存のリソースでより高いパフォーマンスを発揮できるCCPMに注目が集まっています。 しかし、CCPMがどのようなものか理解できていない方もいるでしょう。 本記事ではCCPM導入のメリットや導入手順をわかりやすく解説します。 プロジェクト管理に悩んでいる方はぜひ参考にしてください。 導入編：このようなことありませんか？ プロジェクト管理に頭を悩ませる田ヌ田部長ですが、プロジェクトの進捗など現場の状況をきちんと把握できていないため、的確な指示が出せません。 それにより、プロジェクトが納期に間に合わないなど現場では大きな混乱が
TOCメールマガジン:クリティカルチェーン(CCプロジェクト管理講座)
クリティカルチェーン(CCプロジェクト管理講座) １．まずはプロジェクトとは何か考えてみよう「恐ろしい話・・」 日付:2005/04/20 ============================================================ ☆新連載 ＣＣプロジェクト管理講座（１） まずはプロジェクトとは何か考えてみよう「恐ろしい話・・」 ============================================================ メルマガをお読みの皆様 ゴールシステムコンサルティングの西原です。 今回からＴＯＣ/クリティカルチェーン・プロジェクトマネジメントに ついて連載させて頂くことになりました。 連載についてご質問などありましたらご遠慮なくメール頂ければと 思いますのでよろしくお願いします。 さて、これからクリティ
プロジェクトの進め方について - ほぼ日刊イトイ新聞
第30回 プロジェクトの進め方について 詳しく教えて。 前回、開発チームが小さい方が 開発効率が高まるという話をしました。 今回もそれに引き続いて、 プロジェクトの進め方や、生産性の話です。 僕がチームの生産性の向上に 一役買っていると思うやり方というのは、 プロジェクトチームの中で仕事を割り振るとき、 どうやって仕事を割り当てるかという方法です。 とはいっても、蓋を開けてみれば大したことではないので 改めて書くほどのことでもないかもしれませんが、 しかし理にかなった方法だと思うので、 紹介したいと思います。 1番のポイントは、 基本的に誰が何をやるのかを決めるのは、 その仕事をする本人だということです。 マネージャーに 「これをいついつまでにやれ」 と指示されるわけではないのです。 マネージャーやチームリーダーの仕事は、 次にチームが解決しなければならない問題を洗い出し、 テーブルの上に
プロマネ必読！「アポロ13」
「アート・オブ・プロジェクトマネジメント」で強くオススメされてたので読む ―― これはスゴい。ドキュメンタリーとして夢中になって読めるだけでなく、プロジェクトが危機に陥ったときの「べき/ベからず集」しても、ものすごく有効な一冊なり。 どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策…プロジェクトがパニックに瀕したとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる。本書を通じて学んだ危機管理マネジメントは、次のとおり。 プロジェクトが危機的状況のとき、あらゆる手段を使って、自分の感情をコントロールせよ。感情は事実をゆがめ、判断を誤らせ、解決への手段の一つ一つに邪魔をする 「危機」は、すぐに数字にならない。必ずタイムラグが発生している。だから、危険な数値が今出ているということは、既に危機的状況に突入している、ということだ 問題に対処するとき、絶対
チームリーダー日記 : [メモ]1枚紙設計書(特大サイズ)
キノトロープさんのサイト 制作するWebサイトにおけるシステムの流れを表すWebサイトの設計図。 http://www.kinotrope.co.jp/service/output08/index.shtml webサイトの全部の画面遷移を一枚で書ききる。 A0とかのサイズになったりするとか（以前、どこかのサイトに、詳しく書いてあったんだけど、URL失念です）。 とにかく、これが完成すれば全体の70%は完了、とか書いてた気がする。 ----- 日経システム構築、改め、日経Systemsのこの号では、設計書を1枚（特大サイズ）で書いたよ(with 苦労)、という話が載っていた。(A3×n枚だったかも) http://bpstore.nikkeibp.co.jp/mokuji/nos161.html ---- 一枚紙設計書(特大サイズ)の、僕が依然からしているイメージにもっとも近いのは、 go
上流設計 - essence-s
会場が会社の近くだったのもあって、行ってきました「上流設計セミナー」。 またまた、いろいろ刺激になった。 どろくさいケーススタディがおもしろいですねー。 とりあえずキーワード。注釈はあとで。 経営戦略と施策からITへの要求定義への関連づけを見える化 要求が迷子のスキーヤーになる現象に注意 ITが目的のターミナル駅になる現象に注意 カスタムメイドではなくレディーメイドの準備 仕様変更は変更でないかもしれない→はっきりしただけで変更ではない。 そもそも、きっちり決める事できるんだっけ？ Asisならできるかもでも作る意味はない。ToBeの要求をどうしたらいいのか。 結局反復をちゃんとやろうよ。 ユーザーの要求粒度がまちまちなので既存のインフォメーションモデルはなりたたない ユーザーの要求粒度によって判断してはいけない 要件確定時ぬけおちる情報に変更可能性が隠れている 量の絶対値ではなく量の変化
40歳前後の技術者が不足！ そこからITサービス業界の事情を読む
最近、ある証券アナリストの人から、「ITサービス会社の年齢別の人員構成に着目すると、いろんなことが見えてくる」という話を聞いた。特に興味深かったのは、38～42歳の人員に凹みがあるITサービス会社が多く、プロジェクト・マネジャー不足の懸念があるというくだり。では、何故その世代の人員が少ないのか。その話を聞いて、私はピンと来るものがあった。 この世代の技術者が少ない理由を、彼らの新卒採用時にまで遡る必要はあるまい。15年前の1991年が「ダウンサイジング元年」で、オープン系への流れが加速するのはそれ以降の話なので、彼らの採用されたのは、まだ平和な“メインフレームの時代”だ。それよりも直近、ユーザー企業がIT投資額を抑制し、「ITデフレだ、オフショアだ」と騒いでいたころの出来事の影響の方が大きいだろう。 その頃、彼らの年齢はちょうど30歳台後半に収まる。そこで思い出されるのは、ITサービス業界
プロジェクトチームのリーダーに向く人、向かない人 ― ＠IT情報マネジメント
チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています（年功序列主義の会社ではよく見られることです）。これは、リーダーとして特別な素質がないと思われたり、思い込んだ
『技術空洞』を読んで考えたリーダーシップの意味 - R30::マーケティング社会時評
このブログでもこれまで時々ソニーの経営について書いてきたが、ハコフグマン氏のブログで同世代の元ソニー技術者による告発本『技術空洞 Lost Technical Capabilities』が紹介されていたので、さっそく入手して読んでみた。 んでもって、自分が以前の取材などでも得ていた印象とほとんど同じだったので、がっかりといえばがっかり、納得といえば納得。今さらそれ以上書くこともないかなあと思いつつ、とはいえいろいろと思うところもある本だったので、書評でも書こうかと気を取り直してメモ作ったり他に書評しているブログを探したりして徘徊していたら、僕の思ったことと同じことをこれ以上ないくらいに簡潔にまとめたブログを見つけてしまい、書評を書く気が完全に失せた。そこで、今回はこの本を読んで思い浮かんだことについて書いてみたい。 著者の宮崎氏は、こちらのブログでもまとめられているように、技術系ソニー社員
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ringo's Weblog: イベントドリブンGTD
shi3zの日記 - 部下が致命的なミスをするのは全面的に上司の責任