- Amazon.co.jp ・電子書籍 (112ページ)
感想・レビュー・書評
-
「変化に対して管理やコントロールをしようとするのではなく、あるがまま受け入れつつ柔軟につきあっていくこと」 とはどういうことなのかを簡単にまとめた一冊。
- ITエンジニアってなんで締切いつも曖昧なの?
- 分担すれば速くなるんじゃないの?
- 人を増やしたのになぜ遅くなるの?
ソフトウェアエンジニアリングと他の工学でどのように特徴が違うのかがわかる。
具体的なHOWなどはないので、どちらかというとITエンジニア以外がソフトウェアエンジニアリングに対する認識をどう持ったほうがよいかを知れる一冊になっている。詳細をみるコメント0件をすべて表示 -
ソフトウェア技術者、あるいはソフトウェア開発プロジェクトの内側ではある程度の常識ととらえている、開発遅延、納期遅延に対して増員は解決策にならない、ということをソフトウェア開発のことを知らないビジネスパーソーンに向けて書いた本。
初めてアプリケーションやサービスを発注する立場に立った人が、トラブルが起きた時に持つような疑問に対しての回答になる本。同じ手続きを多数行う事務処理や、多数の同一製品を作る製造業のような発想での解決策はソフトウェア開発ではむしろマイナスに作用するよ、という警告ともいえる。
帯に書かれたような疑問を持った人に対しては有効な本だと思う。 -
エンジニアの自分からすると、とても共感できる内容だった。エンジニア経験のないPMやビジネス側の人たちにも読んでもらいソフトウェア開発に対する共通認識を持てるようにしたい。ただ、読んでもらうのも難しいと思うので、自分の言葉でこの本の内容を説明できるようになりたい。
-
P31 銀の弾丸はないが、金の弾丸なら有効な時がある
P35 チームの哲学や文化が揃っていることが大事
大小とわず組織にいるとどうしてもリスク回避・管理などの要因がでてきてしまいます、事業環境が変化しているのに、古いルールが運用されているなど、そのためにクリエイティビティが損なわれるような状況も多々あります、本書を読んで打開の糸口となるヒントがあったかもしれません。 -
ソフトウェア開発の世界ではそこそこ当たり前になっている人月の神話をわかりやすく書き下してくれている。サッと読めるのはよい。
見積もりでなく見通しというフレーズはよかった -
非ITの人に向けてITの仕事を説明するという意図で書かれたとのこと。ごく真っ当なことが書かれており、まさに管理職、経営者に読んで欲しい本となっている。とはいえ、そういう人はあまりこの本を読まないだろうし読んでもあまりピンとこないかもしれない。
そもそも、ふつうの会社の普通の仕事の進め方はこの本に書かれたこととマッチしない。経営者が考え方を変え予算の取り方を変えベンダーとの契約を変え、アレを変えコレを変えしないといけない。
さらには自社が変わっても、自前で内製できる体制を作るのも採用・育成とも無理ゲーでありベンダーに頼めば、またそこでSIerの人月商売に巻き込まれる。。 -
見積もりと約束が「受発注」の関係を作ってしまう
-
システムを発注する側が知っておくべきことが簡潔明瞭に記述されている。
「技術的負債」 -
ページ数が少なく端的に書いてたこともあり、
すぐに読み終わった。
書かれてる内容はその通りだと思った反面、
そうならないようにするのはなかなか難しい。
とはいえ、観点として持っておき、
当事者になったときに誤った判断をしないよう、
自分自身に対して注意喚起出来れば良いと思った。
【勉強になったこと】
・行き当たりばったりで改修したり、
継続して開発することを意識せずに開発するから
保守開発工数がかさんでしまう。
・タスクを分解するよりやったほうが早いし、
分解しきれないタスクも多い。
未経験者や有識者じゃないメンバーを追加しても
上手く回らないのは上記理由から。
ある程度の塊でタスク依頼が出来ないと、
人を足したところでその人が暇になるだけ。
・ソフトウェアの内面を美しく保つことが、
継続開発のしやすさにつながる。