リスト：ソフトウェア開発チームビルディング を表示しています。（全 10 件）

IT業界の混乱は、形式的なプロジェクトマネジメント手法や開発技術では乗り切れない。そこには、人間力のあるリーダーが必要である。本書には、「才能」としてのリーダーではなく、彼が現場での「悩み」から後天的に得た「技術」、そして「勇気」のエキスが生の言葉で書かれている。
（平鍋 / 2006-03-25）

理論や知識を紹介した本ではありません。現場でリーダーはどう行動するか、を筆者の経験等から、語った本です。個人的には、かなり参考になったり、勇気づけられたりしました。
内容としては、リーダーの心がけ、リーダーの仕事、どのようにプロジェクトを進めると良いか、課題や進捗などの管理方法、ミーティングの方法、トラブルへの対処、メンバーのモチベーションなどです。具体的に、手順や注意点、実践の上でのポイントが述べられています。
あまり読む／聞いたことがないユニークな点もあり、本当に実践から生まれてきたような印象の本でした。
筆者は、ソフトウエア開発のプロジェクトリーダをされている方みたいですが、本書の内容は、「ソフトウエア開発」に限定されずプロジェクトに普遍的な内容を持つ本であったと思います。
かなり平易に書いてあり、読みやすかったです。読んで損はない、と思いました。（lemonerika / 2006-07-12）

現場リーダーとは、３つの価値観を持ち、３つの仕事をこなす人。
プロジェクトが円滑に流れるようにする、プロジェクトを管理するのではなく、ファシリテートするための技術が書かれています。
「技術」というと小手先のテクニックを想像しがちですが、人に重点を置いたプロジェクトファシリテーションの心構えとして参考になりました。（iceman41 / 2006-04-16）

「内側から見た富士通「成果主義」の崩壊」で明らかになったように、
結果だけを見る成果主義では2割の上位層は成果が伸びるものの
大多数の8割の社員はやる気を失ってしまう。
その結果、会社全体のパフォーマンスは落ちていく。
その次の理論としてこの本は「行動科学マネジメント」を紹介している。
行動科学に基づいた理論なので言われてみたら至極まともで
「結果でなく有意義な行動に対してポジティブなご褒美を即時にそして
確実に与えることが重要」というのがポイントである。
ただ本の半分を理論の良さをアピールことに割かれており、一生懸命
アピールするぐらいだったら具体例を数多く載せておいて欲しかった。
この本だけで実践に移すのは難しいというのが感想である。（どこかのSE / 2008-01-15）

平易な表現で、具体例をちりばめながら、非常に理解しやすく書かれています。従業員の動機付けの観点から見た、成果主義や賞与の弱点もさらっと看破しており、おおっと思わされました。
ただ、他のマネジメント本と同様、結局、自分の組織にあてはめてどこまで実践できるか、リーダーの実行力が問われる一冊でしょう。
それにしても、この種のマネジメントをいつまで経ってもアメリカから取り入れなければならない日本の環境に寂しさを感じます。（chi / 2007-12-30）

行動分析を元に優秀以外の社員のパフォーマンスを上げるための本
とてもわかりやすいし，組織のみならずセルフマネジメントにも使える．
主張は，まるで”馬の鼻先ににんじんをぶら下げろ”の世界だが
多くのこの手の本が成果についてマネジメントしているのに対し
この本では行動をマネジメントする．
またマイクロマネジメントとの違い，マネジメントの役割も
明確に記載されており，使いやすいと考える．（親カッパ / 2007-12-07）

『｢依存する人」を｢変化を起こす人」にどう育てるか』の著者である内田氏からの推薦本。
マネジメントにかかわる人は是非とも石田氏の著書を一冊は読んで欲しいと言われました。
そんな内田氏が絶賛する石田氏の最新作が内田氏が最も推薦するダイヤモンド社から出たとなれば買わない理由はありません。
実際に読んでみると科学的であり、それゆえにプロセスが明確であるため実践しやすいです。
私のようにマネージャーとしての経験が浅い人間には特に心強い一冊です。
壁にぶつかるたびに今後も繰り返し読みたいと感じさせる内容でした。
もちろんベテランのマネージャークラスの人たちにもお勧めです。
ダイヤモンド社のビジネス書は本当に外れが少ないと改めて感じさせる一冊でもあります。
（産業保健師 / 2007-11-17）

本書において注目するのは「結果」を引き起こす「行動」です。
石田淳さんの行動科学マネジメントとは、「普通の人」や「できない人」を「できる人」にするために、「できる人」の行動をみんなが実践できるようにするマネジメントです。
手順としては、できる人の「行動を分解」し、結果に繋がる行動を「チェックシート」にし、チェックシートに従った行動を取れたら「ポイントカード」にポイントをつけます。
この手順を説明するために、行動を分解するときに用いるMORSの法則、行動を強化するためのリインフォースメント、目的行動結果の因果関係を考えるABCモデル、結果が行動に与える影響の評価方法としてPST分析を紹介しています。
簡単に書くと、よい結果に結びつく行動をしたら、すぐにその人が望むようなことを与えるとその行動を多く取るようになり、よい結果を継続して出せるようになるということです。
普段はあまり意識しないかもしれませんが、実際に理論として紹介されると、普段から自分の行動に当てはまると思うことが多々あってうなずけます。
また、実際に行なうときに気をつけることとして、「ピンポイント」「メジャーメント」「フィードバック」「リインフォースメント」「評価」の5点についても書かれており、上司の方々は実践しやすいのではないでしょうか。
動物行動学は問題行動の治療や犬のしつけなどに使われています。
行動分析は動物行動学を元にされており、人も動物の一種なことを考えると、とても理にかなった方法です。
自分をできる人にするためにも使えるため、一読の価値ありです。（幸福論者 / 2007-12-31）

「自分は完璧でありたい」と思う人は多いけど､
完璧な人にお目にかかることなど､滅多にないものです。
人間には一人ひとり個性が違う以上､長所も短所もあります。
｢会社」というのは､凸凹のある人間同士が集まって､
お互いの凸凹を補い合って､何とか完璧な仕事を目指そうとして
試行錯誤する所だと思います。
で､職場の上司や部下の凸凹が､この本を参考にすると、よくわかりました。
そして､自分自身の長所短所も見えてきました。
いろんな個性の人と組織仕事をしている人にとっては､
必ず考えたり悩んだりするはずのポイントばかりなので､
「入社したての時に読んでおけば､〝転ばぬ先の杖〟になって､
よかったろうなぁ」とも思いました。
悪い読み方をすると､上司や部下を裁く気持ちになって､
心が乱れるかも知れません。
しかし､謙虚に自分自身を振り返るような視点で読んでみるとどうなるか。
私の場合､読書後､不思議と､気持ちに余裕が持てて､
軽やかな気持ちで仕事ができました。（st-victory / 2003-11-14）

これまで読んできた、この手の本は、多くの場合、人を批判したり、組織に対する不満を述べて、高圧的に持論を展開して終わるというものが多かったが、この本は、個性や問題を見極めて、状況をどのように改善するかという建設的な内容だと思う。
もちろん、理想の上司や部下についてこの本が述べていることが唯一の正解ではないが、他の人というより自分の状況を正直に見つめ、成長していく上での一つの資料として参考にできる本だと思う。
漫画も非常に楽しく、この本を魅力的にしている。（steady / 2004-02-02）

どの業界でもきっと「この業界ってなんか変じゃない」ということはあるのでしょうが、それにしてもコンピューター業界におけるＳＥといわれる人たちの生態は不可思議なものはないのではないでしょうか。
面白いんだけれど、笑ってばかりではいられないシチュエーションが満載です。（ニャンゴロ / 2005-05-30）

ひじょおおおおおおに面白い本
IT業界でコンピューターのことちんぷんかんぷんな奥さん(夫・彼氏彼女も可)におすすめ．
それなりにありがちな日常ケースをネタで楽しく読めます．（elf2000 / 2005-02-26）

きたみりゅうじさんの「ＳＥのフシギな生態」は知人に勧められて読みました。マンガと文章が妙な味を出していて、２００３年に発売されたＳＥ本のなかでは、トップクラスの面白さでした。
その第２弾なのですが、少しパワーダウンしたのか、それともネタ切れなのか・・、面白さが減った感じがします。
読者も、第２弾ということで、より面白いものを期待していたせいかもしれませんが。。
とはいうものの、他のＳＥ本に比べるとやはり面白い。なによりマンガ付きなのがよい（それもヘタウマ）。
ぜひぜひ、違う切り口の第３弾の発売を期待してしまいます。（izuminoa / 2003-12-10）

長年、ソフト開発現場で大活躍された職人技術者の筆者の話は実に共感が持てる。私も業界の当事者の一人だが"人月換算"で商取引がされるシステム開発ビジネスほど実態の無い業種はこの世には無いと思う。技術者の能力の個人差・開発案件の不安定要素、外注丸投げ依存体質と原因はいろいろだろうが。
このIT業界に関わる経営者から末端のプログラマまで読む価値のある一冊だ。（ / ）

良い本でした。
我が社でも、みんな管理職志向が強いですね。やっぱりプログラマ30歳引退説なんていうのがありましたから（最近は40歳引退説のようです）。でも管理職は面白くなさそうだし、かといって企画、仕様、上司の言うとおりに設計するのもつまらないです。この本を読むと、自分が自立的プログラマになって、やってやろう！という気になりますね。上司が営業、生産からの都合に合わせて作った仕様と日程で、毎日毎日残業残業で設計するのが馬鹿らしくなってくる。時間がないからチェックも疎かで評価に渡し、バグがいっぱいでて修正に時間が掛かりまくり。フローチェックと称して後でソースをチェックしても、全部見切れるはずもなし。製品化後にバグが発見されれば設計者のせいにされる。無理な日程でつくらせる上司の責任だろ！そんな上司なんかに、私は成りたくない。
トップダウンなんか蹴っ飛ばせ！（ / ）

年の割には、この業界での経験がちょっと少なめの私ですが、日頃思っていることを代弁してもらったという感じです。
同じ業界に身をおくものとしては、非常に読みやすい内容で、一気に読んでしまいました。
でも、この本に書かれているような思いやプラクティスは、システム開発に限らず、あらゆる「現場」で奔走する人々に共通するものだと思います。
例の「事件は会議室で起きてるんじゃない…」のフレーズにも似た、世の中のあらゆることに通じる内容がこの本の奥にあると感じます。
ちょっと大袈裟ですが…すべての「現場」の人々が主役になれたら、どんなに住みごこちのいい世界になるんだろうか？そのためにも、みんなが精進して「主役」たるスキルを身に付けていこうと改めて感じました。（kobaやん / 2004-09-06）

ソフトウェア工学などではプログラムの自動化などが謡われる事があっても実現には程遠いのが実情だと認識を持っています。そうするとやはりプログラマという役割が必要になってくるのです。
そのプログラマという役割についてもっと主役・重要視してもよいのではないかと提案しているこの本。ただの機械でよいのならばそれでいいのでしょうが、プロジェクトを成功に導くために必要な役割もプログラマにはあるということを再認識。
ＳＥとはプログラマとはと考えるときに、新しい視点で見ることが出来る。（ニャンゴロ / 2005-06-08）

「プログラマ主役型プロジェクト」の必要性からはじまり、そのようなプロジェクトにおける、プログラマの仕事の仕方や役割（言われたとおり、作るだけじゃだめだ！）や持つべき判断基準、価値観、ＳＥさんやマネジメントの役割等について述べた本です。
なぜ、プロジェクトは失敗するのか、情報システムの品質や納期をあげるには？システム開発プロジェクトの組織のあり方、チームのあり方、プロジェクトマネジメントのあり方、スケジュール管理、等多くの問、そして「プログラマ主役型プロジェクト」からの解（の候補）を、あげている本です。
清く正しいプログラマになるための本ですが、ＳＥさんやマネジメントを担う人にも、改めて「奥深い問題」を考えさせてくれる本でした。（lemonerika / 2004-10-21）

→メインの本の名前「プロマネはなぜチームを壊すのか」について
　期待して読み進めると肩透かしをくらいます．．
　ま、これは、刺激的な題名をつけざるを得ないという
　何かしらの背景があったと、納得するとしましょう．．
→書いてある内容は、副題の「ヒューマンスキル」の方
　．．ただし、こちらの方も、プロマネ個人のヒューマンスキル
　というよりは、プロジェクトに携わる人々全員のヒューマンスキルが
　メインという感じ．．
　プロマネがプロジェクトを成功させるためには、
　自分だけでなく、他人のヒューマンスキルも高める必要があるという
　ことなのでしょうか．．
→本の題名に、いちいちこだわらない読者が、
　こんな思いで手にとった本なら、役立つかもしれません．．
　「プロジェクトにおけるヒューマンスキルっていう漠然としたものを、
　　とにかくかいつまんで、平易な言葉で、順を追って説明してほしーなー」
っていう読者に．．
→以下の鋭い分析は、評価したいと思います
　奇数人数で、動的な性格が強いチームを作る（Ｐ４１）
　３種類の信頼「個人的信頼、専門的信頼、構造的信頼」（Ｐ６８）
　「本物」と「優秀」なプロマネの違い（Ｐ１２５）（よこはま　こうたろう / 2007-03-28）

チームビルディングに参考になればと思い購入したが、コミュニケーションの重要性を説くだけでそれ以外の話題はなかった。唯一の話題であるコミュニケーションについても当たり前のことしか書かれておらず残念であった。（tank / 2009-06-13）

プロジェクトマネジメントにおいて必要なヒューマンスキルの部分について、豊富な心理学の知見と経験を織り交ぜながら分かり易く解説されている良書です。プロマネの分野で、このテーマに真正面から取り組んでいる本は、少なくとも日本では類書がほとんど無いのではないでしょうか？
内容については、特に以下の議論が印象的でした。
・結果責任の本当の意味：「結果は重要だが、プロジェクトが終了してから分かる未来のことであり、結果を出すために今できる正しい判断や行動をとることがプロマネの真の責任」という趣旨の議論は非常に明快で、有益なものだと思いました。
・チームの適正人数について：「なぜ奇数が好ましいか」など、大変興味深い議論でした。
・「優秀なプロマネより、本物のプロマネ」：本書のメッセージが集約されているような言葉です。
・巻末付録・現場の生の声（モチベーションが上がった言葉、下がった言葉）：思わず笑ってしまうような言葉や、自省を感じるような言葉などが多く、示唆に富みます。（namaeta / 2007-04-06）

プロジェクトマネージャの持つヒューマンスキルが、いかにプロジェクトの
成否に影響するかが如実に表されており、どのようなプロジェクトマネージャに
なるべきかを書いた良著であると思う。
中でも、”モチベーションを上げる/下げる言動”についての、現場の
生の声や、実際起こりそうなシチュエーションでのケース問題は参考になった。（プロマネー / 2007-03-23）

“人にまつわるマネジメント”と言う言葉が印象的であった。プロジェクトに拘わらず仕事においては、詰まるところ、人との関わりを無視しては成り立たない。リーダーであれば尚更のこと、この“人にまつわる”遣り繰りが仕事の成否を決めるものとの感を強くした。この本ではいろいろ示唆するところ多く、人間系へのマネジメントのヒント集として大いに役立つ。いい本である。（よれよれの新宿のプロマネ / 2007-03-23）

仕事上で部下や後輩を指導するうえでの実践的なテクニックが書かれており，かなり参考になる。発問の四つのパターンというのは特に面白かった。自分は学校の教員なのだが，授業の仕方，学生指導の仕方という点からみても参照度の高い内容だった。筆者の実体験からくる「こぼれ話」にはニヤっとさせられるものが多く，面白い。おすすめ。（たけやん / 2006-03-25）

後輩指導に悩んでいた自分にぴったりでした。
仕事覚えが悪い後輩指導に悩んでいました。
●「自分でほとんど調べず、すぐに質問してくる」
●「何回も同じことを聞いてくる」
●「何を質問しているか要点を得ない」
●「分りました」と言ったのに、とんでもない勘違いをして、何も理解していない
こんな後輩を持って、イライラしっぱなしでした。
それなりに社会経験積んでいるはずのいい大人が、
人に言われるまでメモ用のノートさえ持っていない有り様。
新卒の新人の方がまだましと思えることが度々。
まさに「まったく使えない後輩」でした。
正直、いない方が余計な仕事も増えず、
精神的にもイライラせずに良いくらい。
この本はそんな自分にぴったりでした。
当の後輩は一向に使えないままですが、
この本の通り実践していると、「教え方が丁寧」「面倒見が良い」と
自分に対する上司や周りの評価が変わってきました。
当初の目的とは全く違ってしまいましたが、自分にはかなり為になりました。
さっそく、残りの２冊も注文しました。
「はじめての後輩指導―知っておきたい育て方30のルール」
「速効!SEのためのコミュニケーション実践塾」（Ryo / 2008-02-11）

著者の素晴らしい人格のようなものを感じることができた本でした。こういう人が上司で、アクノレッジメントされたら、嬉しいかも。私もそんな人になりたいな、という意欲がわくと同時に、でも、私を取り巻くすべての人に対して、こうあり続けるのは大きなチャレンジであるような気がします。
基本的にはこの本の主題に対してまっすぐ取り組んで自分を高める方向に成長しながらも、昨年読んだ「ほめたくない部下をほめる技術」で、現実的なところをカバーしながら、本年も仕事がんばります。任せるもアクノレッジメントということなので、まずはそこに挑戦しようかな。
（mika / 2010-01-07）

優秀なコーチかどうかを見分けるコツ。
それは、コーチングで一番大切で、一番重要なことが、
本当に分かっているのかどうかである。
「褒（ほ）める」事と、「煽（おだ）てる」事は違う。
「叱（しか）る」事と、「怒（おこ）る」事は違う。
この用語の定義が身に付いて分かっているのかが、
良いコーチであるかどうかの最大のポイントだと思う。
更に、コーチとしてのスタンスを付け加えるなら･･･
人は成功は約束されていないかもしれないが、
努力することで成長は約束されている。
成長する為の、多くの失敗する権利を奪わないようにする。
この「スタンス＝人間力」もコーチの重要なスキルである。
同書は、この重要なポイントから軸がいささかもぶれていない。
コーチングを学ぶ人には是非とも読んでいただきたい良書です。
世には「褒めるな」という本もありますが、
言っていることは「煽てるな」ということ。
鈴木氏の「褒める」と共通しているのは言うまでもない事です。
是非、ご一読下さい。
（手帳の達人 / 2005-11-22）

部下は誉めて育てるべき、と最近言われるようになった。しかしやみくもに誉めても、こちらも気恥ずかしいし、相手にも効果はないだろう。しかしこの本を読み、自分の「誉め方」がいかに貧しいものであるかを知った。
この本にはあらゆる場面での「誉め方」「認め方」が具体的に説明されている。人を誉めるか誉めないかは、性格で決まるのではなく、その人が誉め方のバリエーションをどのくらい持っているかによるのだと感じた。（ / ）

　「ほめ上手」と「叱り上手」は、自動車のアクセルとブレーキのような関係で、どちらか一方だけではうまく機能しないが、基本は「前に進む ＝ ほめる」ことの方だと思う。鈴木氏自身は、まだ若いが、自身の体験談の中から、心に伝わる「ほめ方、認め方、関わり方」のヒントを提供している。特に、著者自身が、米国の刑務所で囚人をカウンセリングしていた時のエピソードなど、じーんと胸にくるものがあった。
　相手によって、何がほめ言葉になるかが変わってくるという指摘はまさにその通りで、ほめ上手は「ほめ方のレパートリーが広い人」であることがよくわかる。そして、ほめ上手とは、小手先のテクニックではなく、むしろ相手の存在そのものをどれだけ深く受け止めているかという心構えなのだろう。
　企業の管理職やプロのコーチ、教育者はもちろん、子を持つ親・保護者にも、広くおすすめしたい１冊である。（hhh / 2002-06-09）

私は中間管理職なので、そういうビジネスの現場での
指南書として、興味深く読むことができた。
ただ、本自体は、
上司が部下にという狭いシチュエーションだけに留まらない。
人は誰でも褒められたい。認められたい。
という普遍的なテーマが語られているため、
対人という意味で、あらゆるシーンに活用できる書だと思う。
自信を喪失しているすべての日本人に、おすすめの一冊です。（ / ）

「25周年記念版」ということで、著者が25年前に著したことに対する著者自身のコメントが興味深い本である。
内容以前に次のような点が残念に思う。
・プログラミング言語の文、数式等が例として文面に出てくるにもｋかかわらず、縦組みであることに不自然さを感じる。
・文の前後を繰り返して読まないと、意味が解釈できない表現が多い。（訳に問題があるのか、もともと難しい文章なのかは不明）
・値段の割りに漫画本のような紙の質で、印刷も安っぽい。
プログラミングやソフトウェア開発に関する事項を本書とは違った観点で考えるために、次のような本も合わせて読まないと、場合によっては、ソフトウェア開発過程で行う事が間違った方向に導かれ、ソフトウェアの生産性や品質が低下する可能性もあるので注意が必要ではなかろうか。
「ピープルウエア 第2版」
「ソフトウエア開発 55の真実と10のウソ」
「ソフトウエア開発プロフェッショナル」（ / ）

この春の思い掛けない贈り物！
具体例は, FORTRAN や PL/I, COBOL だが, 今でも通用する内容であり、代わりとなる文献も見付からない. むしろ, 最近の若いプログラマーにとって, このようなことを考える余裕は, ますます不足するような状況にあると思う.
「Java なら」「C++ なら」「Perl なら」「Python なら」という翻訳をしながら, 先輩が後輩といっしょに読んだりしてはいかがだろうか.（shibaten / 2005-02-27）

この本の歴史的価値については言うまでもないぐらい有名な本の25周年記念版。最初
に出た内容をリライトするのではなく、25年たって振り返ってみたコメントを各章に
追記した形式で出版されたもの。
正直、ワインバーグ本の中ではそれほどよいとは思っていないが、ワインバーグのそ
の後の問題意識のすべての端緒がこの本にあるといってよい。エゴに対する洞察、
ＮＬＰやＸＰにつながる内容など、その問題設定の確かさはさすがかと。（エパメイノンダス / 2007-04-04）

プログラミング開発者だけでなく、その関係者にも読んでもらいです。
そして少しでもプログラマの心理を理解したいただきたいです。
プログラマを志し、自分の適性を知りたい方にもお勧めします。
多少ともきれい好き、少しばかりの謙虚さが必要なようですよ。
プログラマの方、いつも仕事に勉強と大変だと思います。
本書を通して自分の心理と照らし合わせてみてはいかがでしょうか？
自分を見つめなおす良い機会になりました。（なか / 2007-02-05）

開発時の管理ツールを作成するという小規模分散プロジェクトにRUP(Rational Unified Process）を適用した事例を紹介したものです。RUPなら知っているよ、という人は不要でしょう。最近はOpenUPというものもありますのでRUPは知らないけど、UPは興味がある、という方は一度読んでもよいのではないかと思います。
「ソフトウェア開発の課題１　ソフトウェア開発の持つべき文化」と内容が若干重複するところがあるかもしれません（私は重複しているなと感じました）。（Turtle / 2007-02-07）

CMM, PSPでも解決しな問題を、チームでお互いにうまくやっていくことについて抽出したもの。
CMM,PSPでうまくいかない場合に、まず、ここから取り組むとよいかもしれない。（kaizen / 2008-05-12）