長尾高弘のレビュー一覧
-
Posted by ブクログ
以下、ポイント
マネージャーの役割は、人を働かせるのではなく、働く気にさせること。
精神集中状態、フロー状態になるには15分以上の精神集中過程が必要。電話が鳴る、誰かが話しかける職場では困難。
何カ月、何年の作業時間が、右脳のアハたいけアイデアにより解決する場合がある。音楽は右脳を占拠するので閃きを邪魔する。
人は基準から外れた人を恐れる。だから会社は同じような人を採用する。
チームの誇りはメンバーか成し遂げた成果。服装や髪型は関係しない。
リーダーシップとはサービス。自ら仕事を引き受け、準備をし、メンバーに価値を与える。ユーモアと善意の元に事にあたる。
結束したチームは、一体感がある。楽しい。給与、昇進は関係ない。
チーム殺し、チーム内の競争は互いの育成を不可能にする。何故なら教えた相手に追い抜かれるから。競争させるには、目標管理、表彰、能力評価。
仕事は煩わしいことという常識がある。楽しいならそれは仕事ではない。楽しんで金を貰ってはならない。楽しい場合は仕事らしい仕事、煩わしく、うんざりし、惨めな気持ちになるもの。仕事中に楽しくて笑ってしまうことは後ろめたい。
プロジェクトには触媒が必要。何か優れているわけではないがチームワークを醸成する人。
高品質が最終的にコスト低減をもたらす。
人間は混乱を秩序に変える本性がある。良いマネージャーは混乱を小さく配分する。そして混乱を秩序に変える快感を部下にもたらす。 -
-
Posted by ブクログ
備忘録。
部下に大きなプレッシャーをかければ、もっと働くようになる。
→違う。ヤル気をなくすだけだ。
フロー状態に入るのに15分の精神集中課程が必要なため、作業を中断する行為が継続的に発生する場合には、実質的な仕事はできない。
サービスとしてのリーダーシップ
自ら仕事を引き受ける
明らかにその仕事に向いている
あらかじめ必要な準備を済ませ、万全の態勢で仕事に向かう
全員に最大限の価値を与える
ユーモアと明らかな善意のもとに事にあたる
大変興味深い、そして、自分の職場がチーム殺しにあっていることを知る。大きな企業であるがゆえにうまくいかなくなっていることが多いのだろう。ペーパーワークや会議に時間を取られ、上司からの圧は、退職を考えたくなるような理不尽なことがある。
それを変える、あるいは、職場を変えるといったことを考えたときに、それを変える努力をするだけの価値があるのか考えてしまう。
まだまだプロジェクトのプの字を勉強中の私にも、色々思うところがある本でした。古い本にも関わらすです。それだけ、プロジェクトマネジメントが成熟していないのか、あるいは、それを学ぶ機会が無いのか、教育の仕組みが確立していないのか、まだまだ、自分は勉強不足なので、関連した本を読んでいこうと思います！ -
-
-
-
-
-
Posted by ブクログ
ソフトウェア開発のマネジメントにおいて重要なのは、技術よりも人。という話。
そんなの当たり前だろ？おれもそう考えてるぜ。と、大部分のマネージャは言うだろうが、多くの場合それは思い込みだ。
こう考えてみるといい。
この仕事はこの人にしかできないといったことがあった場合、その手順を標準化して、急にその人が抜けても大丈夫なようにしよう。。。って発想になったらもう怪しい。
それじゃ、その人よりも標準化(という名の技術)のほうが価値があるってことになってしまう。そんなことで仕事が運ぶんだったらそりゃラクだけど、実際そうはいかない。その人しかできない仕事なんてものが、そう簡単に標準化なんてできるわけがない。
やるべきなのは、その人を大切にすること。それは組織が個人に依存することになってしまうからマズイって思うかもしれないけど、何しろ人が大事なんだから、それは受け入れるべき現実なのだ。もしその現実から目をそらすというならば、あなたのやっていることは全て「仕事ごっこ」に成り下がる。
代えのいない人なんて、その人自身にとっても不幸なんじゃない？という考えはもちろんあると思う。だが、その人の持つ技術は、彼に敬意となんらかのコストを払った者だけが受け継ぐことができるものだ。
人を大切にする、というのは決して甘やかすということではない。「甘やかす」と「大切にする」は似ているようでぜんぜん違う。人を大切にするためには、誠実さが必要であり、その人に自分の弱みを握らせるということを意味する。だからこそ目を背けたくなるのだが。
そしてもちろん、その前に「大切にするに値する人」を見つけ出してチームに引き入れるという、これまた目を背けたくなるような困難な仕事をこなさなくてはならない。
この本、優しいことが書かれているようで、実はえげつない。 -
-
-
Posted by ブクログ
IT運用における問題や問題に対する対処、
運用改善、最終的には開発・運用の一体化までを
小説として書いた本。
嫌がらせをされるシーンもあったりと、
実際のIT運用に近い話が多かったような気がする。
おかげで面白く読むことが出来ました。
IT運用から改善を実現するには、
①現状をまずは改善する（小さく改善し、時間を作る）
・運用フローを可視化する
・運用を管理する
・ボトルネックを見つける
・運用フローを見直す
②業務とITの関連を把握する（業務を理解する）
・どんな業務にITが必要なのか
・そもそもどんなことにITを使っているのか
・トラブルが起きて困ることは何か
※個人的には、ココが極めて重要だと感じた。
③開発チームと一体となった組織を作る（クイックな組織）
・開発と運用が繋がる箇所を整理する
・整理した結果、自動化出来る部分を特定する
といった流れになるのだろう。 -
Posted by ブクログ
ザゴールのIT版。
基本的に、システム（ある程度規模がある）開発経験者でなければ、用語の理解や、開発現場の雰囲気の調整に難航しそう。また、加えて登場人物の多さも気になる。
日本のシステム開発従事者も、スキルや契約や何より、DevOpsの先にあるITが何のためにあるのかという視点を主人公率いるユニコーンチームみたいに持てると、本当に素晴らしいことだと思う。システムを守るため、ではなくビジネスを強化、補強、推進するために、DevOpsでIT頑張ろうという話。
devops（以下、抜粋）
ビジネスニーズに即応するということは、ビジネスの変化に応じてITシステムの機能が追加されたり、変更されたりすること。
換言すると、ビジネスの好機に必要とされる機能が提供できないITシステムはお荷物ということになる。
これを解消するために、IT（システム開発）の様々な仕事をミクロな視点で捉えつつ、マクロな視野を得、本当に有用なものにして行く。本書では、開発と運用の一体化を図り、ビジネスニーズへの即応性をより高めるDevOpsを目指す。 -
Posted by ブクログ
IT部門の開発と運用、延いては全社的なビジネスとITの融合を図るまでの過程を本書でも言及されている「ザ・ゴール」のような小説仕立てで描き、コミュニケーションとコラボレーションの推進を訴え、目的の共有と全体最適を啓蒙する。
トラブルに次ぐトラブル、ビジネス側から突きつけられる厳しい要求、正にデスマーチ、そして急転直下の和解とハッピーエンド、ハラハラドキドキしながら読み進めることができた。ただ、主人公のビル・パーマーが辞意を表明したからステーブ（CEO）が謝るまでの四日間での心変わりと謝罪が良く分からなかった。トップと対立したら辞意を表明すれば事態が好転する程、世の中都合よくできてないと思う。
アジャイル・スクラム、リーンスタートアップなど製造業のの方法論をITに展開したものが多い、本書も「ザ・ゴール」のIT的展開だろう、これからのIT業界は製造業に学ぶべきなのだろうか。 -
-
-
-
-
-