タグ

bookとmanagementに関するscorelessdrawのブックマーク (10)

  • 「プロジェクト・ブック」はスゴ本

    建築デザイナー向けだが、システム屋のわたしにも効果大のスゴ書は、建築タイポロジーの解説ではないし、建築デザイン・テクニック集でもない。仮に書が建築デザインについての形式論・類型論だったなら、わたしにとって、何の役にも立たないだろう。 しかし、デザイナーとしての才能やテクニックに関係なく、つくるキモチに焦点を当てている。たとえば、場のつくりかた、発意の仕方、他者との共有方法を理解することで、どういう瞬間にプロジェクトが「まわって」いるかを感じとれる。いちいち具体的で、かつ、そのままITプロジェクトにハマる。 デザインプロジェクトに効く63のキーワードと、現場の会話ログを追いかけるうちに、プロジェクトを「まわす」のに建築もシステムも大差なく見えてくる。つくる「モノ」は違えども、つくる「コト」は同じなのだから。 ■1 場所をつくる 大きなテーブル、広い壁、ライブラリー、気持ちのいい椅子

    「プロジェクト・ブック」はスゴ本
  • 404 Blog Not Found:It's all up to you - 書評 - あなたはマネージャーに向いていない

    2007年12月04日03:00 カテゴリ書評/画評/品評 It's all up to you - 書評 - あなたはマネージャーに向いていない 日実業出版社第一編集部佐藤様より献お礼。 あなたはマネージャーに向いていない 津田陽一 私が著者に感謝したい点が二点ある。 一つは、書を著してくれとこと。 もう一つは、著者が私の上司ではなかったこと。 書「あなたはマネージャーに向いていない」は、経営コンサルタントである著者が、「マネージャー向きでない」人々を10のタイプに分類し、その傾向と対策を述べたもの。 目次 はじめに 得意技はモグラ叩き - 「発生主義型」トラブルシューター 机上の空論芸術家 - 「理想主義型」プランナー 能力賞味期限切れ - 「悲劇の主人公」ナルシスト いつも一過性 - 「熱烈感動型」ドリーマー 段取りベタすぎ - 「抱え込み型」カーペンター 流血勝負し - 「

    404 Blog Not Found:It's all up to you - 書評 - あなたはマネージャーに向いていない
  • 人と人をつなぐ技法「チームビルディング」

    「チームはできるものではなく、つくるもの」。この視点はありがたい。チームをまとめる立場なら、この視点+技法は必須。プロジェクトチームから町内会まで使える。 好むと好まざるとにかかわらず、社畜でいるかぎり、三十路も後半になると、一匹オオカミでいさせてくれない。「面倒みてやれ」という暗黙のメッセージとともに、何人か付けられる。たいていは、数回の毎朝ミーティングでチームらしくなってくる。 これが10人、20人のプロジェクトチームになると話が違ってくる。さらに、「思惑」「肩書」パラメータが追加されると厄介だ。以前のわたしは、アイスブレイクをいくつかと、赤ちょうちんぐらいしか知らなかった。仕事を通じてチームは形成されるものだと思っていた。 ところが、書では、チームをつくる方法があるという。短期間で活性化したチームとして機能させるためのメソッドが紹介されている。[アジャイルレトロスペクティブズ]がチ

    人と人をつなぐ技法「チームビルディング」
  • 「アジャイルレトロスペクティブズ」書評 -- 社員食堂配膳モデルからヴァイキング食べ放題モデルへ - アンカテ

    仕事というものを、社員堂の日替わり定のように、ひとつの同じメニューが全員に配膳されるようなイメージでとらえている人が多い。これを、ヴァイキングのように、テーブルに次々と並べられていく作業を、それぞれがべたい所から好きなようにべていくモデルに変えていくことが必要だと思う。 多様化する社会にこれから入っていく人が、自分の仕事を選択する場合にもこのイメージが有効だと思うが、ソフトウエア開発という職種では、その内部においても、仕事がヴァイキングのモデルのように進むようになりつつある。一つのシステムを開発する為に必要なスキルは、非常に多様なものになっていて、メンバーの持つスキルが分散してそれぞれが得意分野に対応していくことが必要になっている。 定を残さずべるには、好き嫌いが無いことが仕事に就く条件になるが、ヴァイキングでは、何かしらの得意分野を持っている個性的な人が集まらないと戦力になら

    「アジャイルレトロスペクティブズ」書評 -- 社員食堂配膳モデルからヴァイキング食べ放題モデルへ - アンカテ
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 見えない仕事がイノベーションを起こす「シャドーワーク」

    「シャドーワーク」について、豊富な実践例+網羅的な考察をした一冊。ヒット商品やイノベーションの陰には「シャドーワーク」が必ず存在する。ルーティーンワークからの変革なんてありえないし、創造的な価値は管理者の目の届かないところから生まれる。これはわたしのような兵隊ではなく、人事部の将校クラスが肝に命じておくべき。 「シャドーワーク」とは、通常業務から外れた、個人の自主的な意志と裁量で創造的に編み出した仕事のこと。仕事そのものへ結びつかないまでにしても、その準備活動も含まれる。いわゆる「やってみなはれ」「渦は自分で起こせ」というやつ。 たとえば、日産の例。新型マーチのコンセプトづくりにあたり、設計開発ラインの「外」で「こっそり」人を集め、意見を出し合う。あるいは、リコーの場合。GR DIGITALの専用Blogを提供するにあたり、「業務外で」「手弁当で」組織横断的に立ち上げる。仕事として「決まっ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 見えない仕事がイノベーションを起こす「シャドーワーク」
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: チームリーダーは「アジャイルレトロスペクティブズ」から盗め

    「なんで、こんな非効率なやり方なんだ?」この疑問、よくあるどころか毎日だ。 たとえば、情報がうまく共有されていないとか、ある人がボトルネックになっているとか。不平を言うと「じゃぁオマエがやれ」と押し付けられるので、最近では不言実行で最適化を図っている[参考]。 あるいは、評論家になっていっぱしのクチをきくが、現場を変える努力も勇気もないくせにブログで薀蓄たれ流す。ネット弁慶カッコワルイ(誰とはいわんが、わたしも含まれるので自戒)。 たしかに、「前と同じやり方」で仕事は回るが、「やり方」が改善されないまま。成果物はレビューされるが、仕事のプロセスはレビューされない。かくして非効率性は引き継がれ、不満は澱のように溜まってゆく。 こいつをなんとかする試みが、「アジャイルレトロスペクティブズ」。舌噛みそうな名前で、サブタイトルの「『ふりかえり』の手引き」というほうがピッタリだね。 つまり、プロジェ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: チームリーダーは「アジャイルレトロスペクティブズ」から盗め
  • Life is beautiful: 図解、イノベーションのジレンマ

    私がマイクロソフトをやめるキッカケを作ったのが、「イノベーションのジレンマ」というだということは、以前にも書いた。IT業界でビジネスをしている限り、大きな会社にいようと、小さなベンチャー企業にいようと、このに書いてあることを日々意識しながら仕事をするかどうかは大きな違いを生むはずだ。 このブログでも何度も引用しながら、一度もちゃんと解説を書いたことがなかったことに気が付いたので、今日のエントリーは、このに書かれているコンセプトの解説。 そう思っていつもの様に書き始めたのだが、文字だけではとても伝えにくいコンセプトだ。しかし、図解と言えばパワポ、というのもありきたりすぎるので、会社の廊下にあるホワイトボードに手書きで描いた図を、携帯電話で撮影したものを使うことにした。通りがかった社員にも見てもらえるので、一石二鳥である。 上の図は、このに書かれたコンセプトを一般化したもの。ブルーのラ

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉

    あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、このは思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだはそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
  • 満足せる豚。眠たげなポチ。:すごい会議のための最高の手引書 『この「聞く技術」で道は開ける』

    「すごい会議」を購入した人にはぜひ一度読んでほしい。「すごい会議」の公式副読はおそらく「すごい考え方」なのだろうけど、このもぜひ加えてほしい。すごい会議はこの TIME TO THINK をプロジェクトの推進で使うためにフレームワーク化したものだと言えるから。 問題の正しい対処の仕方を知っていて、一人で実践する分にはうまく行くのに、皆にそれをやってもらおうとした途端にうまくいかなかった経験はないだろうか? たとえばプログラムでもいい。セオリーとしてどのようにすべきか、きっとあなたは知っている。ファウラーのリファクタリングも読んだし、デマルコのデッドラインも読んだ。もちろん達人プログラマーだって読んだし、デザパタだって読んでいる。コードコンプリートもライティング ソリッドコードも読んだんだ。楽々ERDレッスンも読んだ。何をすべきかは知っている。 ところが、それを組織でやろうとしたときに

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 欠陥上司が部下を殺す

    上司に恵まれなかったら「オー人事」は古いか… 今じゃ上司次第で部下が死ぬ。冒頭、冗談ぬきの事例が紹介される。「むごい」というしかない。仕事を続けるのにソコまでしなきゃならんのか、と言いたくなる。だけど、追いつめられた人はそこまで考えがおよばない。 「心の病」が増加しているという。成果主義への移行、派遣社員・正社員の責務差、IT偏重の業務、組織のフラット化による若年管理職… など、要因はいくらでも思いつく。ストレス社会は今に始まったことではない。にもかかわらず、特に最近、急上昇している原因は上司にある、と筆者は断ずる。「こんな上司が部下を追いつめる」は、部下を生かすも殺すも上司次第という。これは同意。しかし、そろそろ課長クラスを担うようになるバブル入社組をヤリ玉に上げるのはカワイソス(´・ω・`) 「こんな上司」とあるが、どんな上司が部下を追いつめるのだろうか? 部下は使い棄て、育てるつも

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 欠陥上司が部下を殺す
  • 1