感情タグBEST3
Posted by ブクログ
「ソフトウェア開発上の問題の多くは技術的というより社会学的なものである」という一文に激しく同意。ソフトウェアには人の働き方の変革を後押しする力があり、AIがコードを書いてくれる時代になったとはいえ、それを作り上げるのは依然人の仕事である。そうなれば社会学的なアプローチに触れないわけにはいかない。
本書は一般論的なHRMを学んだエンジニアリング組織のマネージャーが次に読むべき本として素晴らしい内容にまとまっている。一般論とソフトウェア開発の現実とのちょうど中間地点の程よい抽象度。
日本のソフトウェア開発プロジェクトの現場では、冒頭に挙げた「社会学的」な課題解決アプローチが欧米のそれよりも未発達らしく（訳者あとがきより）、これまで当たり前と思ってきた職場環境のあれこれや、プロジェクト管理上のあれこれが実はアンチパターンだったと知ることができる。
皮肉が効いた文体が特徴的な本書ではあるが、挙げられた数々のアンチパターンに対して同調し「だからうまくいかないんだよなあ」と嘆くだけでは意味がない。では何のため、どこから、どのようにして変えていこうか。という今日明日からの行動に落とし込んでいきたい。
Posted by ブクログ
プロジェクトマネジメントはツール、セオリーも大事なのだが、ここで述べているようなロジスティクス的なこと、人間関係やモチベーション管理の方が大事だろうなぁと改めて思わされた一冊。
Posted by ブクログ
本書籍は，仕事でのソフトウェア開発にまつわる，技術面よりは，それ以外の側面での，様々な事について書いています．読者層は，リーダー級のプログラマや技術職のマネージャ，経営者向けかなと思います．
本書籍は，初版は1987年のようで，33年過ぎた2020年時点では，本書籍で書いていることは，いくつかはテクノロジーが解決できているのもあると思いますが，多くは未解決と思います．
前述のとおり，本書はリーダ，マネージャ，経営者向けかなと思いますが，プログラマが自分自身の職場，または参画している（参画してきた）プロジェクトに，漠然とした疑問を持った時に読むのも良いと思います．
プログラマが，自分の居場所を良くするには，ほんのちょっとした，ささやかなアクションの積み重ねだと思います．
Posted by ブクログ
ほぼ全面的に同意できる内容だった。
・考える暇があったら仕事しろ？
・残業なんかくそくらえ
・早くやれとせかされれば、雑な仕事をするだけで、質の高い仕事はしない
・パーキンソンの法則は、ほぼ確実にあなたの部下には当てはまらない
・プログラマーはただ、仕事をするために身を隠す
・机の前に何時間座っていたかはどうでもいいことで、全神経を集中して仕事に取り組んだ時間が重要
・etc.
これらにピンとくるなら、読んでみて損はないと思う。
驚くべき点は、この本の初版が発行されてから既に30年が経っているという事だ。
もう一つの驚くべき点は、日本では今なお実現している企業はごく少数だという事だ。
一応断っておくと、この本に書かれている内容が古いからではない。
この本を本当に読むべきは、マネージャー層だろう。
Posted by ブクログ
冒頭に書かれている「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と書かれているとおり、人をどう活かすか、どのようにしたら活かせるか、いいチームを育てていくか、などなどについて書かれた本。 初版が1989年に書かれているということだけど、残念ながら今も人を交換可能なパーツとしてとらえ、プロセスで縛ればうまくいくという仕事の進め方をしているところが存在しているのではないかと思う。 中堅ソフトウェアエンジニア+ソフトウェアマネージャは読んでおくべき1冊であると思うけど、読んで何も変わらなければ先は暗闇でしかない。 ということで、とりあえず周りの人には薦めておくことにする。
Posted by ブクログ
二十歳過ぎぐらいの時にサラっと読んだ記憶があるが、その時はまるでピンと来なかった一冊。あれから十年近く経った今読むと、その理解度は（良くも悪くも）格段に上がったのは経験が無駄にはなってないという事だろうか。
本書を読んで最も驚く部分は、最近よく聞かれるホラクラシーだとかリモートワークだとかHRTだとかサーバントリーダーシップみたいな概念がまるっきり全部記載されている事だ。この本は約30年前に原著が出版されており、今回読んだ３版で追加されたのは最後の６部だけなので、持ち出す事例や訳のモダンさは変わったかもしれないが、そのエッセンス自体は変わってない事が伺える。この現実を噛みしめると、ソフトウェア開発の現場というのは釈迦の掌をいつまでもぐるぐる回ってるが如く、中々に進歩できない複雑な社会学なんだなぁと心の底から納得すると同時に激しい虚無感を感じる。
唯一の救いはこのようなソフトウェア開発における社会学の原典と、その派生系であるモダンな事例を伴った派生書が数多くこの世には存在するという事実。
ソフトウェア開発を上手くやりたいマネージャーはこの本を繰り返す読みつつ、現場で実践し、時には（37signals辺りを読んで）モダンな方法を取り入れながら少しづつ、ソフトウエア開発における人類の進歩を実現していくのだろうと感じる。
Posted by ブクログ
【目的】 ソフトウェア開発の問題における社会学的側面に注目し、どのようにマネジメントすべきかの指針を与える。
【収穫】 いかに人のやる気を引き出し、力を発揮してもらうか、ということがマネージャーの果たすべき役割と理解できた。
【概要】 ■プロジェクトにおける問題の本質： 技術的な問題というより、人がに関する問題、すなわち社会学的なものが多くの原因である。
■生産性に関する錯覚： 生産性＝利益÷コスト。コストは、退職者の補充にかかるコストも含まれるべき。長時間残業やプロセスの機械化により生産性を上げたとしても、それで人が退職すれば、実際の生産性は下がる。また、人のやる気やコミュニケーションを無視して、新しい技術的な手法によって生産性が飛躍的に向上するというのは、錯覚である。
■生産性向上に果たす要因： 誰と一緒に働くか、オフィス環境が快適か、チームとして一つにまとまる目標があるか、官僚主義的な手順に縛られていないか、といったこと。
■メソドロジー（方法論）における問題と代替案： 書類の著しい増加、手法の不足、責任観念の欠如、全般的な意欲の低下。作業方法の統一を実現するには、教育研修、ツール導入、ピアレビュー実施などの方法がある。標準化が必要でも、10ページ以下のゆるいガイドラインにすべき。
■マネジメントに必要なこと： 無理な納期や品質削減や権限を振りかざすリーダーシップは彼らの生産性に対して有効な手段ではない。オフィス環境をよくする、目標を一致させる、小さくて簡単な成功を体験させる、信頼する、等によりチームのやる気を引き出すこと。
【感想】 プロジェクトマネジメントのうち、特に人に関わる部分に対して深い洞察が行われている名著。ソフトウェア開発に関わっていれば、必ず理解できる部分があると思われる。
Posted by ブクログ
マネジメントの学習のため購入。
技術よりも大事なものは人で、人格の尊重、相応しいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織作りの大切さを学べてためになった。
Posted by ブクログ
p.5
プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な人間関係の結果である。
p.11
プロジェクトには「触媒」が不可欠。
「触媒」＝不安定な状態にあるPJのまとめ役
p.22
早くやれと急かせれば、雑な仕事をするだけで、質の高い仕事はしない。
仕事を早くするためには、製品の品質と仕事の満足感を犠牲にせざるを得ない。
p.26
エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。
p.40
ソフトウェア開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳密な処理手順に変換するための、人と人とのコミュニケーションである。これは、どんなにソフトウェア開発のライフサイクルを変えようと、絶対に必要な仕事であり、自動化できるはずがない。
p.41
管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。
p.52
意外なことに、残業の真の目的は、仕事の量をこなすことよりも品質向上のためなのだ。（定時の時間帯は仕事に集中できない）
p.166
チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。この目的が満たされたとき、チームのメンバーはずっと効率よく働く。
p.185
最大の成功は「管理」などないかのように、チームがなごやかに一致団結して働いたときである。最良の上司とは、管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人である。
p.195
健全な会社にするための不思議な作用を生み出す戦略的要素
・品質至上主義を作り出す
・満足感を与える打ち上げをたくさん用意する
・エリート感覚を醸成する
・チームに異分子を混ぜることを奨励する
・成功チームを解散させないで保護する
Posted by ブクログ
システム開発をする上で、人の扱い方に特化した内容。共感できる文言が多かった。
おそらく平社員よりも、マネージャーに向けた一冊だが、新人でも読んで考え方を知ることができて良い本だった。
Posted by ブクログ
人人人。をとにかく意識したチームマネジメント、プロジェクトマネジメントの手法、考え方の教本。
システム開発のプロジェクトに特化された部分もあるが、噛み砕いてみるとプロジェクトマネジメントの核を捉えている事がおおい印象でした。
私自身まだ、リーダーとしてマネジメントしているわけではないが、リーダーになる準備、来たときにはまた部分読みを繰り返したいとおもいました。
Posted by ブクログ
メンバの心を掴み、チームをまとめ、生産性を上げるために心に留めておかなければならないことが網羅されている。古典だが折に触れて思い出さなければならない。
Posted by ブクログ
以下、ポイント
マネージャーの役割は、人を働かせるのではなく、働く気にさせること。
精神集中状態、フロー状態になるには15分以上の精神集中過程が必要。電話が鳴る、誰かが話しかける職場では困難。
何カ月、何年の作業時間が、右脳のアハたいけアイデアにより解決する場合がある。音楽は右脳を占拠するので閃きを邪魔する。
人は基準から外れた人を恐れる。だから会社は同じような人を採用する。
チームの誇りはメンバーか成し遂げた成果。服装や髪型は関係しない。
リーダーシップとはサービス。自ら仕事を引き受け、準備をし、メンバーに価値を与える。ユーモアと善意の元に事にあたる。
結束したチームは、一体感がある。楽しい。給与、昇進は関係ない。
チーム殺し、チーム内の競争は互いの育成を不可能にする。何故なら教えた相手に追い抜かれるから。競争させるには、目標管理、表彰、能力評価。
仕事は煩わしいことという常識がある。楽しいならそれは仕事ではない。楽しんで金を貰ってはならない。楽しい場合は仕事らしい仕事、煩わしく、うんざりし、惨めな気持ちになるもの。仕事中に楽しくて笑ってしまうことは後ろめたい。
プロジェクトには触媒が必要。何か優れているわけではないがチームワークを醸成する人。
高品質が最終的にコスト低減をもたらす。
人間は混乱を秩序に変える本性がある。良いマネージャーは混乱を小さく配分する。そして混乱を秩序に変える快感を部下にもたらす。
Posted by ブクログ
備忘録。
部下に大きなプレッシャーをかければ、もっと働くようになる。
→違う。ヤル気をなくすだけだ。
フロー状態に入るのに15分の精神集中課程が必要なため、作業を中断する行為が継続的に発生する場合には、実質的な仕事はできない。
サービスとしてのリーダーシップ
自ら仕事を引き受ける
明らかにその仕事に向いている
あらかじめ必要な準備を済ませ、万全の態勢で仕事に向かう
全員に最大限の価値を与える
ユーモアと明らかな善意のもとに事にあたる
大変興味深い、そして、自分の職場がチーム殺しにあっていることを知る。大きな企業であるがゆえにうまくいかなくなっていることが多いのだろう。ペーパーワークや会議に時間を取られ、上司からの圧は、退職を考えたくなるような理不尽なことがある。
それを変える、あるいは、職場を変えるといったことを考えたときに、それを変える努力をするだけの価値があるのか考えてしまう。
まだまだプロジェクトのプの字を勉強中の私にも、色々思うところがある本でした。古い本にも関わらすです。それだけ、プロジェクトマネジメントが成熟していないのか、あるいは、それを学ぶ機会が無いのか、教育の仕組みが確立していないのか、まだまだ、自分は勉強不足なので、関連した本を読んでいこうと思います！
Posted by ブクログ
ソフトウェア開発のマネジメントにおいて重要なのは、技術よりも人。という話。
そんなの当たり前だろ？おれもそう考えてるぜ。と、大部分のマネージャは言うだろうが、多くの場合それは思い込みだ。
こう考えてみるといい。
この仕事はこの人にしかできないといったことがあった場合、その手順を標準化して、急にその人が抜けても大丈夫なようにしよう。。。って発想になったらもう怪しい。
それじゃ、その人よりも標準化(という名の技術)のほうが価値があるってことになってしまう。そんなことで仕事が運ぶんだったらそりゃラクだけど、実際そうはいかない。その人しかできない仕事なんてものが、そう簡単に標準化なんてできるわけがない。
やるべきなのは、その人を大切にすること。それは組織が個人に依存することになってしまうからマズイって思うかもしれないけど、何しろ人が大事なんだから、それは受け入れるべき現実なのだ。もしその現実から目をそらすというならば、あなたのやっていることは全て「仕事ごっこ」に成り下がる。
代えのいない人なんて、その人自身にとっても不幸なんじゃない？という考えはもちろんあると思う。だが、その人の持つ技術は、彼に敬意となんらかのコストを払った者だけが受け継ぐことができるものだ。
人を大切にする、というのは決して甘やかすということではない。「甘やかす」と「大切にする」は似ているようでぜんぜん違う。人を大切にするためには、誠実さが必要であり、その人に自分の弱みを握らせるということを意味する。だからこそ目を背けたくなるのだが。
そしてもちろん、その前に「大切にするに値する人」を見つけ出してチームに引き入れるという、これまた目を背けたくなるような困難な仕事をこなさなくてはならない。
この本、優しいことが書かれているようで、実はえげつない。
Posted by ブクログ
☆4:協働の力をどのように最大化させるか、の観点でひたすらに「べからず」が述べられている。ソフトウェア業界、プロジェクト型ワークのひとのみならず、チームを率いる人は何かしら気づきが得られるのでは。
これまで、自分が細かいマネジメントしてきたなと反省した。。
何年後かに再読して、またへこもう。
Posted by ブクログ
難しそうなテーマの本の割にはすごく読みやすかった。
オフィス環境について論じられているのが新鮮であった。
個人的にはそこまで重要視していなかったのだけれども、
考えてみると生産性に大きく影響がある要因だと思う。
実際に変革するのが難しい要因だと思うけれども。
Posted by ブクログ
システム開発業界における人・チーム・組織・会社の力学を考察し、プロジェクトを成功させるためのより良い環境や関係作りを提案する古典的名著の第３版。
どの業界でどのような職務についていても、うなずけることばかり。やはり仕事は人間なのだ。
Posted by ブクログ
エンジニア、さらに言えばプログラマの働き方に対する本。プログラマはどう働くべきか、周囲は彼らを活用させるためにどうすればいいのかを説明している。
ものすごく簡単に言えば、互いにコミュニケーションが取れる状態をチーム内に構築する、周囲（マネージャなど）は彼らの邪魔になることはしない（邪魔になること:電話を掛けたり電話対応させたり集中力が途切れるようなこと）などが挙げられている。それと似たようなことが実例とともに繰り返し述べられているのがこの本の主な内容である。実際にはプログラマが成長する際の学習環境についてなども含まれている。
さて、そうするとプログラマが勝手気ままに周囲に対してふるまえるかのように読めてしまうが、そうではなくここでいうプログラマはそれぞれ第一線で活躍できるような技量を持った存在のことであり、ぴよぴよのプログラマが好き勝手に要求していいわけではない。そんなひよこが成長できるような学習環境も提供するのが環境の責務であると述べているのは先述の通りだが、どちらかというとやはり自身で作業・責務の最適な姿が見えるプロフェッショナルなプログラマを対象としている。
そしてそれは書末にある「自由電子」という語に集約される。よい軍隊のように前線で各個人が高い能力でもって判断・連携する組織的な活動というイメージがぴったりあう。
Posted by ブクログ
開発に関わっていて漠然と思っている悩み・課題が、多く言語化されている感覚。
経営陣やビジネス側へはなかなか伝わらない部分だし、現実的に全てこの本の通りにはならないこともあるだろうけど、組織で共通認識されていると物事がスムーズに進む気がする。
Posted by ブクログ
独特の言い回しの文章で、読む人選ぶかもしれません。
プログラマを経ずに、ソフトウェア開発のマネジメントをする人は是非読むべきだと思う。ほかのマネジメント本とは違い、ソフトウェア開発を社会学としてとらえ、現場の問題に即した本となっている。
メモしたい言葉は、「人は期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りにできそうもないことがわかったときに、非難から身を守るために残業するのだ」
Posted by ブクログ
正論なんだけど、他部署を敵に回すようなことも主張しているので、マネージャーは読んで複雑なのでは。これができれば苦労しないと思いそう。ただメンバーに良い結果出す為の環境を整えてあげると、悪い評価の人をリストラしやすくなりそう。結果に対して言い訳する逃げ道がなくなるからね。ドライな感じはするけど欧米企業はそのあたりも見越して働きやすい環境を作っているのかな。
Posted by ブクログ
人材とは替えがきかない、あるいはきかせるために想像以上にコストを要する。生産性を上げるということはどういうことか。
アメリカの例がふんだんに盛り込まれているので必ずしも日本の事情に当てはまらないが、唸るところの多いエッセイ。
