投稿元:
レビューを見る
6年ぶりに前線に復帰したので、初心に戻ってITプロジェクトマネジメントの再学習の第二弾。結局のところ、モノを作るのは人なので「人を大事にしよう=Peopleware」ということです。アメリカで書かれた古い本ですが、現代のITプロジェクトにも適用できるヒントがたくさんあります。
続きはこちら↓
https://flying-bookjunkie.blogspot.com/2019/04/blog-post_24.html
Amazon↓
https://amzn.to/2Uvax6D
投稿元:
レビューを見る
感想は以下
http://masterka.seesaa.net/article/458055044.html
投稿元:
レビューを見る
独特の言い回しの文章で、読む人選ぶかもしれません。
プログラマを経ずに、ソフトウェア開発のマネジメントをする人は是非読むべきだと思う。ほかのマネジメント本とは違い、ソフトウェア開発を社会学としてとらえ、現場の問題に即した本となっている。
メモしたい言葉は、「人は期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りにできそうもないことがわかったときに、非難から身を守るために残業するのだ」
投稿元:
レビューを見る
冒頭に書かれている「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と書かれているとおり、人をどう活かすか、どのようにしたら活かせるか、いいチームを育てていくか、などなどについて書かれた本。 初版が1989年に書かれているということだけど、残念ながら今も人を交換可能なパーツとしてとらえ、プロセスで縛ればうまくいくという仕事の進め方をしているところが存在しているのではないかと思う。 中堅ソフトウェアエンジニア+ソフトウェアマネージャは読んでおくべき1冊であると思うけど、読んで何も変わらなければ先は暗闇でしかない。 ということで、とりあえず周りの人には薦めておくことにする。
投稿元:
レビューを見る
PMのバイブル、デマルコ本
あんまおもん無かった、冗長だし。
とはいえバイブルらしいので、経験が増すごとに読んだ時のおもろさが増すのかもしれない。
投稿元:
レビューを見る
メンバの心を掴み、チームをまとめ、生産性を上げるために心に留めておかなければならないことが網羅されている。古典だが折に触れて思い出さなければならない。
投稿元:
レビューを見る
ほぼ全面的に同意できる内容だった。
・考える暇があったら仕事しろ?
・残業なんかくそくらえ
・早くやれとせかされれば、雑な仕事をするだけで、質の高い仕事はしない
・パーキンソンの法則は、ほぼ確実にあなたの部下には当てはまらない
・プログラマーはただ、仕事をするために身を隠す
・机の前に何時間座っていたかはどうでもいいことで、全神経を集中して仕事に取り組んだ時間が重要
・etc.
これらにピンとくるなら、読んでみて損はないと思う。
驚くべき点は、この本の初版が発行されてから既に30年が経っているという事だ。
もう一つの驚くべき点は、日本では今なお実現している企業はごく少数だという事だ。
一応断っておくと、この本に書かれている内容が古いからではない。
この本を本当に読むべきは、マネージャー層だろう。
投稿元:
レビューを見る
本書籍は,仕事でのソフトウェア開発にまつわる,技術面よりは,それ以外の側面での,様々な事について書いています.読者層は,リーダー級のプログラマや技術職のマネージャ,経営者向けかなと思います.
本書籍は,初版は1987年のようで,33年過ぎた2020年時点では,本書籍で書いていることは,いくつかはテクノロジーが解決できているのもあると思いますが,多くは未解決と思います.
前述のとおり,本書はリーダ,マネージャ,経営者向けかなと思いますが,プログラマが自分自身の職場,または参画している(参画してきた)プロジェクトに,漠然とした疑問を持った時に読むのも良いと思います.
プログラマが,自分の居場所を良くするには,ほんのちょっとした,ささやかなアクションの積み重ねだと思います.
投稿元:
レビューを見る
人人人。をとにかく意識したチームマネジメント、プロジェクトマネジメントの手法、考え方の教本。
システム開発のプロジェクトに特化された部分もあるが、噛み砕いてみるとプロジェクトマネジメントの核を捉えている事がおおい印象でした。
私自身まだ、リーダーとしてマネジメントしているわけではないが、リーダーになる準備、来たときにはまた部分読みを繰り返したいとおもいました。
投稿元:
レビューを見る
開発に関わっていて漠然と思っている悩み・課題が、多く言語化されている感覚。
経営陣やビジネス側へはなかなか伝わらない部分だし、現実的に全てこの本の通りにはならないこともあるだろうけど、組織で共通認識されていると物事がスムーズに進む気がする。
投稿元:
レビューを見る
システム開発をする上で、人の扱い方に特化した内容。共感できる文言が多かった。
おそらく平社員よりも、マネージャーに向けた一冊だが、新人でも読んで考え方を知ることができて良い本だった。
投稿元:
レビューを見る
p.5
プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な人間関係の結果である。
p.11
プロジェクトには「触媒」が不可欠。
「触媒」=不安定な状態にあるPJのまとめ役
p.22
早くやれと急かせれば、雑な仕事をするだけで、質の高い仕事はしない。
仕事を早くするためには、製品の品質と仕事の満足感を犠牲にせざるを得ない。
p.26
エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。
p.40
ソフトウェア開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳密な処理手順に変換するための、人と人とのコミュニケーションである。これは、どんなにソフトウェア開発のライフサイクルを変えようと、絶対に必要な仕事であり、自動化できるはずがない。
p.41
管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。
p.52
意外なことに、残業の真の目的は、仕事の量をこなすことよりも品質向上のためなのだ。(定時の時間帯は仕事に集中できない)
p.166
チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。この目的が満たされたとき、チームのメンバーはずっと効率よく働く。
p.185
最大の成功は「管理」などないかのように、チームがなごやかに一致団結して働いたときである。最良の上司とは、管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人である。
p.195
健全な会社にするための不思議な作用を生み出す戦略的要素
・品質至上主義を作り出す
・満足感を与える打ち上げをたくさん用意する
・エリート感覚を醸成する
・チームに異分子を混ぜることを奨励する
・成功チームを解散させないで保護する
投稿元:
レビューを見る
エンジニア、さらに言えばプログラマの働き方に対する本。プログラマはどう働くべきか、周囲は彼らを活用させるためにどうすればいいのかを説明している。
ものすごく簡単に言えば、互いにコミュニケーションが取れる状態をチーム内に構築する、周囲(マネージャなど)は彼らの邪魔になることはしない(邪魔になること:電話を掛けたり電話対応させたり集中力が途切れるようなこと)などが挙げられている。それと似たようなことが実例とともに繰り返し述べられているのがこの本の主な内容である。実際にはプログラマが成長する際の学習環境についてなども含まれている。
さて、そうするとプログラマが勝手気ままに周囲に対してふるまえるかのように読めてしまうが、そうではなくここでいうプログラマはそれぞれ第一線で活躍できるような技量を持った存在のことであり、ぴよぴよのプログラマが好き勝手に要求していいわけではない。そんなひよこが成長できるような学習環境も提供するのが環境の責務であると述べているのは先述の通りだが、どちらかというとやはり自身で作業・責務の最適な姿が見えるプロフェッショナルなプログラマを対象としている。
そしてそれは書末にある「自由電子」という語に集約される。よい軍隊のように前線で各個人が高い能力でもって判断・連携する組織的な活動というイメージがぴったりあう。
投稿元:
レビューを見る
プロジェクトマネジメントはツール、セオリーも大事なのだが、ここで述べているようなロジスティクス的なこと、人間関係やモチベーション管理の方が大事だろうなぁと改めて思わされた一冊。
投稿元:
レビューを見る
マネジメントの学習のため購入。
技術よりも大事なものは人で、人格の尊重、相応しいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織作りの大切さを学べてためになった。