人が増えても速くならない ～変化を抱擁せよ～

投稿元：

レビューを見る

ソフトウェアエンジニアリングの仕事について、ありがちな誤解やアンチパパターンを経営者や事業責任者にも分かるように説明されている。特に生産性やモチベーションを悪気なく下げてしまうケースに言及されており、思うように開発が進まなかったり、人材の流出に悩んでいるなら本書を学ぶと良いだろう。
全体的に表現が平易でわかりやすく、ページ数が少ないので負担なく読める。著者の倉貫さんの本は毎回読みやすくなっているが、その中でも本書は特に読みやすくなっている。
書いてある内容はエンジニア目線で共感できるものが多い。また、逆に多くのエンジニアができていないことへの言及もある。エンジニア以外の人にぜひ読んでもらいたいし、エンジニアも読んで態度を改めるべきだと思う。「そのやり方、誰も幸せにならないからやめませんか？」という対話をしていこう。

投稿元：

レビューを見る

人が増えたら速くならない、はまだ理解できるが、内容紹介には、「えー、そんなことないのでは？」と思うことが多い。どれだけ納得させられる内容なのか読んでみたい

#人が増えても速くならない
#倉貫義人
23/6/10出版

#読書好きな人と繋がりたい
#読書
#本好き
#読みたい本

https://amzn.to/43PiOWV

投稿元：

レビューを見る

読みながら感じたのは、すごく頑張って平易な表現を貫いていて感服すると同時に、強調するが故にちょっと言い切り過ぎかなと思う部分もあった。エンジニアが詰められた時にうまく返せたり、そもそもうまいこと説明するのに役立ちそうなので、エンジニアじゃない人の感想が知りたい。

投稿元：

レビューを見る

令和の「人月の神話」。
意図的に平易な表現が使われ、ページも少なく、30分あれば一通り読み切れるサイズ感。
エンジニア経験者なら「何を当たり前のことを」というような内容で、コンパクトにまとめたがゆえの語り落としもある(スクール出たてのエンジニアが戦力にならないとしたら、彼らはどう育てるの？とか、急かすと将来に影響があるのはわかるがビジネス的に守らなければいけない日程とはどう向き合うの？とか)。けれども、そんなハンデを背負いつつも「届きやすさ」に勇気を持ってふりきった本書に心から敬意を表する。

投稿元：

レビューを見る

ソフトウェア開発のプロジェクトにおいて、エンジニア以外のイメージとの乖離について書かれた本。
思ったよりページ数少なくてビックリした(136ページ)。ただ、その分読みやすいし、ページ数少ないからといって稚拙かというとそんなことはない。短いページ数で、うまくまとまっていたように思う。

本当、悪い例の話が、直近で自分が関わっていたプロジェクトについて書かれてるんじゃないかと思った。
行き当たりばったりで改修だとか、「ビジネス的には仕方ない」というようなことを言われるとか。
コミュニケーションコストとか、分かってない人も多いしね…。期限が迫ってるから新しく人をいれようという社員にたいして、「コミュニケーションコストがかかる」というと、「コミュニケーションは大事だよ」なんて言われたり(大事なのが分かってるから、その分コストがかかるって言ってるんだよと…)。

ただ、人のことばかり言えるわけでもなく、テストを手動でやってしまうというのは自分も反省しなくてはいけないことだと思う。テストコードを書くようにしようとは思ってるものの、なかなか手が出せない…。

プログラムは、コンピュータを動かすための指示書だから、プログラミングは製造ではなく設計に近いという考え方は、なるほどと思った。
自分も製造のイメージだけど、確かにそういわれたら設計なような気はする。
そういう意味で、設計する人がプログラミングするのが一番いいのだろうなぁ。
少しはうちの会社にもこういう考えを浸透していきたい。

投稿元：

レビューを見る

かなり凄い本
この著者の方は何冊か本を出版しており、それの最新作
内容がかなりシンプルかつ濃厚で、時間があまり取れない人でも読めるようになっている

投稿元：

レビューを見る

システム屋さんがおすすめしてくれた本です。
簡単な言葉で説明してくれているので、システム屋さんがどんな想いで仕事をしているのかがわかりました。
これから社内へシステムを導入する予定の製造業で働く方におすすめの1冊です。

投稿元：

レビューを見る

他の一般的な業務では通用することでも、システム開発では通用しないことがまとめられている。システムをわかってない上層部にどう言えば伝わるのか？参考にしたくて読んだ。
手伝いを入れると生産性が下がるってのは、自分が言いたかったことをちゃんと言ってくれた感じ。育成と生産性向上の両立は、システム開発では難しすぎる。システムを知ってるはずのシステム開発会社のマネージャでもこういうことをわかってない人は多いと思う。

投稿元：

レビューを見る

非エンジニアの経営層、事業部長レイヤーの方々に是非読んで頂きたい一冊だ！例えがとてもわかりやすく、1時間程度でサクッと読めてよかった！

投稿元：

レビューを見る

文字数も少ないし、平易な言葉で書かれてるのでさくさく読めた
それでいてなるほどそういうことが起こっていたのねとわかりやすい

私は開発側で、作って欲しいものの依頼が来た時に「どういう用途/シーンで使うのか？」とかを最初のきっかけから知りたかったんだけどなんでかその質問の時に毎度座りが悪いというか、「なんでそんなとこまで聞くん…？」感を相手から感じていた、が、見積もりむずいの章で「受発注の関係になりがち」というのを聞いて合点がいった
おそらくビズ側は作ってもらう分、せめて仕様は固めていこうと決めてきてるのに、それにもしかしたらケチをつけられてるというか「この仕様じゃ足らんかったんか？」という気持ちになってたのかもしれない

円滑な開発にはエンジニアとビズの協働が大事とあり、そのためには「前提やきっかけから開発者も知ることが必要」と伝え続けること、1〜2週間など細かい単位で成果物進捗を見せることが必要な模様
どうも作り出すと「これも付いてるときっと驚かれるゾ」と作り込んでしまうところがあるのでそんな個人的なサプライズ欲は封印してちまちま見せていけるようにしようと肝に銘じる

投稿元：

レビューを見る

非エンジニア向けだけれども、事業側とのコミュニケーションをかんがえる上でもヒントになるような卓越した言語化

投稿元：

レビューを見る

ページは少なく図なども無いが、内容としてはソフトウェア開発で陥りがちな誤った意思決定を指摘した堅実な本だと思った。
パーキンソンの第一法則とブルックスの法則は必ず念頭に置くべき法則と思う。
特にブルックスの法則に関しては、同じ過ちを繰り返す企業が多いので要注意だ(ソフトウェア人材を〇〇人補充、みたいなやつ)
また、工程を分けても生産性は上がらないというのもなかなか面白い意見だと思う。ウォーターフォールモデルで作る限り、全ての工程は相互に作用し合っている。工程間でエンジニア力に差があるとそこに引っ張られて生産性が上がらなくなる、という話だった。

投稿元：

レビューを見る

人が増えても速くならない ～変化を抱擁せよ～

株式会社ソニックガーデンの創業者である倉貫義人 氏の著書です。

ソフトウェアエンジニアの常識は、非ソフトウェアエンジニアの方には全然理解されていません。結果、プロジェクトを進める上で共通認識を持つことができずに難航することはあるあるだと思います。
この本は著者の経験に基づき、非ソフトウェアエンジニアの方にもソフトウェアの特性、本質を理解してもらえるように解説した内容になっています。

経験の浅いエンジニアにもおすすめです。

【本書で学べること・考えること】
- プロジェクトとプロダクトの違い
- 開発速度に関する、人やお金の考え方
- 生産性の考え方
- 品質（外から見える品質、内部品質）
- プレッシャーと生産性
- 正確な見積り
- 小さく、シンプルに作るメリット
- ソフトウェアの分業と生産性

読んでみての感想です。

量も少なく、内容も平易なのがハードルが低くて良いです。

私自身、仕事で非エンジニアの方と見積りや仕様などの調整も行いますが、ソフトウェアの内部構造的な問題点を伝えるのに苦慮します。
本書は、非エンジニアの方にもわかりやすく書かれていて、ソフトウェアの本質や特徴を理解してもらう一助になると思います。
また、経験の浅いエンジニアにも理解の一助になります。

今後、この本の説明をベースに非エンジニアの方にわかりやすく説明していきたいと考えています。

投稿元：

レビューを見る

エンジニア視点の仕事の効率化。
業務内容に合わせて効率化を考えないとまさに「船頭多くして船山に登る」になってしまいますね。

投稿元：

レビューを見る

ソフトウェア開発におけるよくある勘違いについて、実際の開発での難しさを説明している。ソフトウェア開発に対して完全に素人レベルのユーザーや管理職であれば得るものがあると思う。自分としてはそういう人たちがどんな勘違いをにているのか知ることで役に立つかと思ったが、あるあるネタ中心なのであまり参考にならなかった。