山浦恒央のレビュー一覧
-
Posted by ブクログ
「ソフトウェア開発上の問題の多くは技術的というより社会学的なものである」という一文に激しく同意。ソフトウェアには人の働き方の変革を後押しする力があり、AIがコードを書いてくれる時代になったとはいえ、それを作り上げるのは依然人の仕事である。そうなれば社会学的なアプローチに触れないわけにはいかない。
本書は一般論的なHRMを学んだエンジニアリング組織のマネージャーが次に読むべき本として素晴らしい内容にまとまっている。一般論とソフトウェア開発の現実とのちょうど中間地点の程よい抽象度。
日本のソフトウェア開発プロジェクトの現場では、冒頭に挙げた「社会学的」な課題解決アプローチが欧米のそれよりも未発達ら -
-
Posted by ブクログ
本書籍は，仕事でのソフトウェア開発にまつわる，技術面よりは，それ以外の側面での，様々な事について書いています．読者層は，リーダー級のプログラマや技術職のマネージャ，経営者向けかなと思います．
本書籍は，初版は1987年のようで，33年過ぎた2020年時点では，本書籍で書いていることは，いくつかはテクノロジーが解決できているのもあると思いますが，多くは未解決と思います．
前述のとおり，本書はリーダ，マネージャ，経営者向けかなと思いますが，プログラマが自分自身の職場，または参画している（参画してきた）プロジェクトに，漠然とした疑問を持った時に読むのも良いと思います．
プログラマが，自分の居場所を良 -
Posted by ブクログ
ほぼ全面的に同意できる内容だった。
・考える暇があったら仕事しろ？
・残業なんかくそくらえ
・早くやれとせかされれば、雑な仕事をするだけで、質の高い仕事はしない
・パーキンソンの法則は、ほぼ確実にあなたの部下には当てはまらない
・プログラマーはただ、仕事をするために身を隠す
・机の前に何時間座っていたかはどうでもいいことで、全神経を集中して仕事に取り組んだ時間が重要
・etc.
これらにピンとくるなら、読んでみて損はないと思う。
驚くべき点は、この本の初版が発行されてから既に30年が経っているという事だ。
もう一つの驚くべき点は、日本では今なお実現している企業はごく少数だという事だ。
一応 -
Posted by ブクログ
冒頭に書かれている「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と書かれているとおり、人をどう活かすか、どのようにしたら活かせるか、いいチームを育てていくか、などなどについて書かれた本。 初版が1989年に書かれているということだけど、残念ながら今も人を交換可能なパーツとしてとらえ、プロセスで縛ればうまくいくという仕事の進め方をしているところが存在しているのではないかと思う。 中堅ソフトウェアエンジニア+ソフトウェアマネージャは読んでおくべき1冊であると思うけど、読んで何も変わらなければ先は暗闇でしかない。 ということで、とりあえず周りの人には薦めてお
-
Posted by ブクログ
二十歳過ぎぐらいの時にサラっと読んだ記憶があるが、その時はまるでピンと来なかった一冊。あれから十年近く経った今読むと、その理解度は（良くも悪くも）格段に上がったのは経験が無駄にはなってないという事だろうか。
本書を読んで最も驚く部分は、最近よく聞かれるホラクラシーだとかリモートワークだとかHRTだとかサーバントリーダーシップみたいな概念がまるっきり全部記載されている事だ。この本は約30年前に原著が出版されており、今回読んだ３版で追加されたのは最後の６部だけなので、持ち出す事例や訳のモダンさは変わったかもしれないが、そのエッセンス自体は変わってない事が伺える。この現実を噛みしめると、ソフトウェア -
Posted by ブクログ
【目的】 ソフトウェア開発の問題における社会学的側面に注目し、どのようにマネジメントすべきかの指針を与える。
【収穫】 いかに人のやる気を引き出し、力を発揮してもらうか、ということがマネージャーの果たすべき役割と理解できた。
【概要】 ■プロジェクトにおける問題の本質： 技術的な問題というより、人がに関する問題、すなわち社会学的なものが多くの原因である。
■生産性に関する錯覚： 生産性＝利益÷コスト。コストは、退職者の補充にかかるコストも含まれるべき。長時間残業やプロセスの機械化により生産性を上げたとしても、それで人が退職すれば、実際の生産性は下がる。また、人のやる気やコミュニケーションを -
Posted by ブクログ
ネタバレ書いていることは事実をある視点で記述しているのだと思います。
解決策は、それぞれの現場で違うので、自分達で考えるしかありません。
現場の感触としては、能力のある人間にやる気を与えて仕事をした結果を、
どうお金に変えるかの手腕が経営者や営業にあるかだと思っています。
そういう手腕のある人でも、手腕があるが故に、仕事量が１０倍、１００倍になったときに、対応方法を誤ることがあるように思います。
万能の解決策はないということではないでしょうか。
少なくとも、
１ 有能な技術者を組織する（やる気にさせる）
２ お金を支払う顧客を捜してくる
の２つができれば、大丈夫なのではないで -
Posted by ブクログ
現在、デスマーチ案件に関わっているので、なにかしらのヒントを求めて買ってみた。
この本を読んでわかったことは、デスマーチはたまたま発生するのではなく、ほぼ恒常的に発生するということ。そ
今までは、管理者の管理能力不足だけがデスマーチ発生の原因と思っていたけど、プロジェクトの内部や外部を問わず、政治的な要因が大きく関わっているのがわかった。
本書では、デスマーチ発生に至るまでの過程を分析し原因を解き明かしている。そして、デスマーチに対して、どう接していけばいいかを説明している。
デスマーチ解決法という内容ではないが、共感できる部分が多い。
この本で、おおよその原因を知っておけば、デスマーチ -
-
Posted by ブクログ
p.5
プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な人間関係の結果である。
p.11
プロジェクトには「触媒」が不可欠。
「触媒」＝不安定な状態にあるPJのまとめ役
p.22
早くやれと急かせれば、雑な仕事をするだけで、質の高い仕事はしない。
仕事を早くするためには、製品の品質と仕事の満足感を犠牲にせざるを得ない。
p.26
エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。
p.40
ソフトウェア開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳密な処理手順に変換するための、人と人とのコミュニケーションである。これは -
-
-
-
Posted by ブクログ
以下、ポイント
マネージャーの役割は、人を働かせるのではなく、働く気にさせること。
精神集中状態、フロー状態になるには15分以上の精神集中過程が必要。電話が鳴る、誰かが話しかける職場では困難。
何カ月、何年の作業時間が、右脳のアハたいけアイデアにより解決する場合がある。音楽は右脳を占拠するので閃きを邪魔する。
人は基準から外れた人を恐れる。だから会社は同じような人を採用する。
チームの誇りはメンバーか成し遂げた成果。服装や髪型は関係しない。
リーダーシップとはサービス。自ら仕事を引き受け、準備をし、メンバーに価値を与える。ユーモアと善意の元に事にあたる。
結束したチームは、一体感がある。楽しい -
Posted by ブクログ
備忘録。
部下に大きなプレッシャーをかければ、もっと働くようになる。
→違う。ヤル気をなくすだけだ。
フロー状態に入るのに15分の精神集中課程が必要なため、作業を中断する行為が継続的に発生する場合には、実質的な仕事はできない。
サービスとしてのリーダーシップ
自ら仕事を引き受ける
明らかにその仕事に向いている
あらかじめ必要な準備を済ませ、万全の態勢で仕事に向かう
全員に最大限の価値を与える
ユーモアと明らかな善意のもとに事にあたる
大変興味深い、そして、自分の職場がチーム殺しにあっていることを知る。大きな企業であるがゆえにうまくいかなくなっていることが多いのだろう。ペーパーワークや -
Posted by ブクログ
ソフトウェア開発のマネジメントにおいて重要なのは、技術よりも人。という話。
そんなの当たり前だろ？おれもそう考えてるぜ。と、大部分のマネージャは言うだろうが、多くの場合それは思い込みだ。
こう考えてみるといい。
この仕事はこの人にしかできないといったことがあった場合、その手順を標準化して、急にその人が抜けても大丈夫なようにしよう。。。って発想になったらもう怪しい。
それじゃ、その人よりも標準化(という名の技術)のほうが価値があるってことになってしまう。そんなことで仕事が運ぶんだったらそりゃラクだけど、実際そうはいかない。その人しかできない仕事なんてものが、そう簡単に標準化なんてできるわ -
-
-