What We Learned About Management in 2015, in 25 Charts and Graphics
What We Learned About Management in 2015, in 25 Charts and Graphics
What We Learned About Management in 2015, in 25 Charts and Graphics
The charmed dot-com life of Jeff Bezos - Apr. 15, 2008
(Fortune Magazine) -- The helicopter was out of control and Jeff Bezos, the dotcom billionaire who founded Amazon, was pretty sure he was about to die. He was pinioned in the front passenger seat as the pilot frantically tried to thread the cherry-red copter through a field of trees. Bezos had been flying around the boondocks of West Texas to scout out a site for Blue Origin, a space tourism ventu
学び続ける組織
ネット生保のビジネスを説明すると、よく聞かれる質問が、「どうやって差別化していくのか？」というもの。 色々な答えの切り口はあるのだが、最終的には「どこよりもいい人材を集めて、誰よりもいっぱい頭を使い、誰よりも早く走り続けること」としかないのではないかと考えている。 例えば、ネットで本屋をやるというビジネスは、誰しも思いついただろうし、実際に何100ものネット書店が立ち上がった。だが、最後まで勝ち続けたのはアマゾンのみ。彼らが買った理由は、何かの秘策があったというよりは、ロジスティクス周りのオペレーションをきっちりやり、レコメンデーションエンジン他、フロントの部分をどこよりも使い勝手よく改善し続けたからではないか。 コンビニ業界でセブンイレブンが圧倒的な強さを誇るのも、これまた秘策があるというよりは、地道にコツコツやりながら、一つ一つの基本をどんどんブラッシュアップしていき、どこよりも早いス
ビジネスリサーチの心得
6．ビジネス分析フレームワークを学ぶ ビジネス分析フレームワークの学習と使い方 ビジネス分析 フレームワークや 経営学 の学習をどうビジネスリサーチに役立てるか、その考え方と留意点について解説します。… 2021.05.08 2021.05.09 115 view 3．ビジネスリサーチの報告書作成 ファクト、ファクト、ファクト〜事実に基づくこと 「What's Your Story?」という提案や提言がないレポートは意味がない、ということがよく言われますが、ビジネスリサーチの報告書は、内容の8〜9割は ファクト … 2021.01.19 2021.05.16 303 view 4．インプリケーションと提言 リサーチを通じて気付いたことは？公開情報から点と点を結ぶイン… インサイダー情報はそのままでは役に立たない！？ビジネスリサーチの依頼の中で、「業界の空気感はどうなっているか？」「この技術
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文（その10）
PMのミッションは、プロジェクトを完遂させることだ←アタリマエなことなのだが、そのために何をしなければならないか、という話題になると多様な方法論に割れる。ここでは、本書から学んだものごとを成し遂げるための2つの方法を考察する。 ■ものごとを成し遂げる方法1 ―― どのように、成し遂げるのか? 優先順位付けによってものごとが成し遂げられる。 プロジェクトマネジメントで最も忌避すべきことは、誤った作業にリソースを費やすこと。プロジェクトの目標や、作業の優先順位が混乱すると、進捗に遅れが生じ、最重要なリソース、すなわち時間が無駄に費やされることになる。いま、何をしなければいけないか、「その作業の重要度」について全員が同じ認識をもっていないと成功はおぼつかない。 では、この「重要度」は何によって決定されるのか? その作業に「重要」とラベルを貼っただけでは何の意味も無い。怒り狂った顧客のキメ台詞「全
「アート・オブ・プロジェクトマネジメント」読書感想文（その9）
問題が起きたとき、その人の真価は試される。しかも、プロジェクトに問題はつきものだから、いつも試練の日々といってもいい。 わたしの場合、カッと頭に血が上って、あとは血がたぎる限り情熱的に（感情的に、とも言う）問題に取り組む。本当は最後のセリフ「できない理由を聞いているのはなく、どうすればできるかを教えて欲しいのです」を真っ先に言い出す。とにかく関係者全員を集めて（電話会議に呼び出して）話をさせれば打開策が出るはずだと駆けずり回る。 後知恵なんだけど、↑は全部誤り。分かっててもやってしまう。ここでは11章「問題発生時に行うこと」で知った「わたしが」身に付けておくべきことを考察する。 ■問題発生時に行うべき8つの手順 手順1：気を落ち着かせる 手順2：プロジェクトに関係のある問題を評価する 手順3：もう一度、気を落ち着かせる 手順4：適切な人材を会議室に呼ぶ 手順5：選択肢を探求
「アート・オブ・プロジェクトマネジメント」読書感想文（その8）
本書に書いてあることは本質的なものばかり。自分で気づいて実現できているものは「何をあたりまえな」と感じるかもしれない。そうでないものは、「分かっちゃいるけど、できていない」と思うだろう。 ここでは、わたしにとって苦手な「分かっちゃいるけど、できていない」コミュニケーションと人間関係について述べた9章、10章の感想を書く。 ■歩き回るマネジメント 仕事ができる人は雑談が上手い、と言われるが、わたしがそれを納得するのにずいぶん時間がかかった、大損だと思う。技術力があるとか、プレゼンが上手だとか、確かに大切なものはあるけれど、イザというとき頼りになる人は、必ずといっていいほど雑談が上手い。プロジェクトがトラブルやプレッシャーにさらされるとき、肩書が無意味になるとき、皆の中心にいる人は、最も長く全員と雑談した人であるはず。その人がPMでないならば、PMは最も大切な仕事 ―― コミュニケーションを怠
「アート・オブ・プロジェクトマネジメント」読書感想文（その7）
第8章「優れた意思決定の行い方」で響いたことをまとめる。 ■意思決定の重要度を決める 何かの決定をしなければならないとき、わたしのツールは2つある。 ・緊急度と重要度マトリックス[参照] ・メリットとデメリット表（D.カーネギー「道は開ける」で知った） 言い換えると、この2つしかない。すべきことを重要度と緊急度の軸にあわせて位置付けを行い、相対的に重み付けするやりマトリックスと、あることを実行する/しないを決定する際、そのメリットとデメリットを左右に並べて評価する表の、2つ。無いよりはずっとマシだけど、いかんせん心もとない。 本書ではもっと本質的に考え、「意思決定の際の重要度は、何を評価基準にすればよいか」という問題に対し、「7つの問いかけ」の形で答えている。先の「優れたPMは質問の達人」と一緒。ただし、問いかける先が自分であることがミソ。 この意思決定の中心にはどういった問題があるの
「アート・オブ・プロジェクトマネジメント」読書感想文（その6）
■仕様書など書く必要がないと信じているプログラマ 第7章「優れた仕様書の記述」は、こんな一文から始まる―― 「私は昔、仕様書など書く必要がないと信じているプログラマと議論したことがあります」―― 議論の顛末は予想通り。おそらく、このblogを読んでいる全員がこの話をしたことがあるに違いない。各人がどういう結論を持っていようとも、本章から新たな気づきが得られるはずだ。 なぜなら、「優れた仕様書とは何か?」について徹底的に考え・実践してきたことが記されているから。目の前の仕事にとって仕様書が必須/邪魔の話をしているのではなく、もっと本質的なことが書いてある。コードから仕様書を生成するツールとか、仕様書を書く上でのテクニック集といったものは、無い。根っこの部分「そもそもプロジェクトにおける仕様書の目的は?」とか「仕様書によってできること/できないことは何か?」について非常に明解に応えている。 で
「アート・オブ・プロジェクトマネジメント」読書感想文（その5）
■優れたPMは質問の達人 筆者は「優れた質問は優れたアイディアを惹きつける」という。では、優れた質問とは何か? ここでは5章で紹介される、アイディアを生み出す方法から、「質問」に焦点を絞って考察する。 焦点合わせの質問 創造的な質問 修辞的な質問 まず「焦点合わせの質問」から。プロジェクトのどんなフェーズであろうとも、質問者が誰であろうとも、最もパワフルな質問がある。わたし自身、ミーティングで必ずする質問。自問も含めると、一日に何回、この質問をすることやら。その「質問」は、反転表示で以下に記す。ドラッグの前に、ちょっと考えてみて欲しい↓ 解決しようとしているのは、どのような問題なのだろうか? 仕様書の記法について議論しているときも、不具合の正体を見極めようとしているときも、「問題の本質を定義しなおす」行為は、ホウレンソウ並に基本動作となっている。ものすごく重要なので、わたしの手帳の第一ペー
「アート・オブ・プロジェクトマネジメント」読書感想文（その4）
いまamazonを見たら在庫切れでやんの、ちょっと意地悪な気分になる。 本書のどのページにもヒントがある。PMな人も、リーダーな人も、ファシリテーターな人も、名前が違うだけで目的はいっしょ。読めば、あちこちに「それ知ってる・ジョーシキ」もしくは「言われて気づいた目からウロコ」のいずれかが埋まっていることだろう。 ■シンプルにすると、本質が見える これをスゴい本だと感心だけでなく、かなり気に入っている。なぜなら、著者の考え方がものすごくシンプルだから。ひょっとすると、"rule#1 : Be Simple!"という標語が壁に大書きされているのかも、と思うぐらい。 どれぐらいシンプルに考えているか、次の例で確かめてほしい。 スケジュールを極限まで簡素化してみると、どのようなプロジェクトでも、その実施期間は、設計、実装、テスティングという3つの工程に分類できます（p.30） 極限までシンプルにし
Chaos by design - October 2, 2006
Take the case of Sheryl Sandberg, a 37-year-old vice president whose fiefdom includes the company's automated advertising system. Sandberg recently committed an error that cost Google several million dollars -- "Bad decision, moved too quickly, no controls in place, wasted some money," is all she'll say about it -- and when she realized the magnitude of her mistake, she walked across the street to
Life is beautiful: Googleの強さはStructured Chaosにあり
今週号のFortuneの特集記事（原文へのリンク）は、"Chaos by Design"というGoogleのマネージメントスタイルに関する記事。GoogleのBusiness Operationの上級副社長は、Shona Brownという元マッキンゼーの女性。1998年にCompeting on the Edge: Strategy as Structured Chaosという本を書き、イノベーションを起こすには、会社を「カオス状態」と「きちんと構造化された状態」の間の "structured chaos"(構造化されたカオス)と呼ぶ状態に置くのが一番良いと説いたのだが、Googleが今ある状態はまさにそれ、というのがこの記事の論点だ。 今考えてみると、Microsoftも、９０年代の前半から中盤の、Windows95、IE3.0、IE4.0を出した時期は、まさに"Structured C
わたしが知らないスゴ本は、きっとあなたが読んでいる
なぜ自分が自分の形を留めていられるかというと、自分を知る誰かがいるから。 誰も自分を知らない場所へ旅するのもいい。そもそも誰一人いない場所を旅するのもいい。だが、いつかは放浪をやめてこの世界のどこかに落ち着かなければならない。さもないと人という存在と疎遠になり最後には自分自身にとってさえ他人になってしまう。 誰かを撮った写真は、近しい人間の心のなかでしか価値を持たないのと同じように、人の心も別の人間の心の中でしか価値を持たず、その人の思い出は、思い出したときにのみ存在するだけであって、思い出す人がいなくなれば、消え去るほかない。 人生は思い出だ、そして思い出が消えれば無になる。だから人は思い出を物語ろうとする―――コーマック・マッカーシーの『越境』を読んでいる間、そんな声が通底音のようにずっと響いていた。 マッカーシーの代表作ともいえる国境三部作（ボーダー・トリロジー）の第二作がこれだ。第
「アート・オブ・プロジェクトマネジメント」読書感想文（その2）
これは、いわゆるHow to本ではない。プログラミングやテストと同様に、「こんなときは」→「こうする」なんて一問一答形式で答えられるような代物ではない。著者が、マイクロソフトInternet Explorerの開発プロジェクトで直面した問題と、それにどう取り組んできたかが書いてある。まさに宝の山。 ■PMにとっての最重要ツール プロジェクトは常に一度きりのもので、過去に類似プロジェクトはあっても、同じものは無い。やるたびに変化する不思議のダンジョンのようなものに、どのように取り組んでいけばよいのか ―― 誰もがブチあたるこの難題に対し、著者はとてもシンプルな方法で考える。同様に、本書を著す際に、この方法を適用している。つまり、 1. 「重要な話題」に、焦点をあてる 2. 「重要な順」に、実行する この方法・順番で本書は構成されている。重要な話題から順を追って説明されている。なんだあたりまえ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.mug.gr.jp/mwmguide/column/odajima.html
An interview with Google's CEO Eric Schmidt - McKinsey Quarterly - Strategy - Innovation
isologue - by 磯崎哲也事務所 - 電通(さん)とWeb2.0時代
プロジェクトの「補助線」
