感情タグBEST3
Posted by ブクログ
タイトルが現場のエンジニアからは当たり前であることから伝わるように、ソフトウェア開発の現場向けというよりも、そこに発注する方に向けた内容と言えます。
その文脈において開発に対して想像していることと、実際に発生する内容との違いが明確になっており、かつシンプルにまとまっています。
Posted by ブクログ
経営層に向けたソフトウェア開発の特性とビジネスとのギャップに関する書籍。というか、Devと事業側という構図がある限りどういった組織でも発生しうる問題であり、対象範囲はとても広いと感じた。協働を目指していくにあたり広くお勧めしたい一冊。ボリュームが程よくとても読みやすい点も良。
Posted by ブクログ
ページは少なく図なども無いが、内容としてはソフトウェア開発で陥りがちな誤った意思決定を指摘した堅実な本だと思った。
パーキンソンの第一法則とブルックスの法則は必ず念頭に置くべき法則と思う。
特にブルックスの法則に関しては、同じ過ちを繰り返す企業が多いので要注意だ(ソフトウェア人材を〇〇人補充、みたいなやつ)
また、工程を分けても生産性は上がらないというのもなかなか面白い意見だと思う。ウォーターフォールモデルで作る限り、全ての工程は相互に作用し合っている。工程間でエンジニア力に差があるとそこに引っ張られて生産性が上がらなくなる、という話だった。
Posted by ブクログ
本書は、サブタイトルに「変化を抱擁せよ」とある通り、変化が起きる前提でどのような姿勢で向き合うかエンジニア誰もが感じる部分を言語化している。
以下は、気になった文章のメモ
・ある一点の完成を目指すことは逆に言えば一度だけ完成すればいいということになる。そうなると、完成後のことより完成させることに力学が働く。
・プログラムは現実の理解の上に成り立つ
・プログラムを書く仕事で求められるのは抽象化能力
・一時的な妥協は永遠の負債になる
・シンプル化する。借金を返済し続ける
・目の前の生産性を上げるのか。それとも、生産性を上げる仕組みを作るのか。
・大きな機能の見積もりは、あくまでも見通しである
・不確実な未来を、少しずつ確実なものにしていく
・ソフトウェアを作ると言うことは新規事業の創出や研究開発のようなもの。レシピを作る仕事に手を動かすだけの人は不要
・プログラムは最も低い品質に引っ張られる
Posted by ブクログ
＜本のタイトル＞
人が増えても速くならない ～変化を抱擁せよ～
＜本の紹介＞
・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない
＜何が書いてあったか（誰でも書ける）＞
・システムは使い始めてから改善が始まる。リリースはスタート地点に過ぎない
ー想定外の新しい要望が出てくる
ー使い始めたらかえって生産性が落ちてしまったとかもありえる
ーユーザーが増えると負荷が高まってパフォーマンスが落ちる
ー法律が改正されて業務フローの変更を余儀なくされる
・ソフトウェアは精緻なジェンガみたいなもの。
行き当たりばったりの改修ではどんどん複雑になり、混乱の極みにやがて陥る
「とにかくシンプルに作ること」と「少しずつ作って手を加え続けること」が大切。
・システムは完成を目指すものではなく、事業とともに改善を続けるもの
また「依頼して作ってもらうもの」ではなく、「協同して一緒に作るもの」である。
・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
ソフトウェアを育てると同時に、開発チームも同時に育てることで、
持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。
＜そこから何を学んだか（自分自身のオリジナルの意見）＞
・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
ソフトウェアを育てると同時に、開発チームも同時に育てることで、
持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。
＜それをどう活かすか（アウトプットによる実践経験の蓄積）＞
信頼関係や心理的安全性だけではまだ十分ではなく、
開発哲学やポリシーというのを明文化する動きも必要と感じた。
Posted by ブクログ
人が増えても速くならない ～変化を抱擁せよ～
株式会社ソニックガーデンの創業者である倉貫義人 氏の著書です。
ソフトウェアエンジニアの常識は、非ソフトウェアエンジニアの方には全然理解されていません。結果、プロジェクトを進める上で共通認識を持つことができずに難航することはあるあるだと思います。
この本は著者の経験に基づき、非ソフトウェアエンジニアの方にもソフトウェアの特性、本質を理解してもらえるように解説した内容になっています。
経験の浅いエンジニアにもおすすめです。
【本書で学べること・考えること】
- プロジェクトとプロダクトの違い
- 開発速度に関する、人やお金の考え方
- 生産性の考え方
- 品質（外から見える品質、内部品質）
- プレッシャーと生産性
- 正確な見積り
- 小さく、シンプルに作るメリット
- ソフトウェアの分業と生産性
読んでみての感想です。
量も少なく、内容も平易なのがハードルが低くて良いです。
私自身、仕事で非エンジニアの方と見積りや仕様などの調整も行いますが、ソフトウェアの内部構造的な問題点を伝えるのに苦慮します。
本書は、非エンジニアの方にもわかりやすく書かれていて、ソフトウェアの本質や特徴を理解してもらう一助になると思います。
また、経験の浅いエンジニアにも理解の一助になります。
今後、この本の説明をベースに非エンジニアの方にわかりやすく説明していきたいと考えています。
Posted by ブクログ
ソフトウェアエンジニアリングの仕事について、ありがちな誤解やアンチパパターンを経営者や事業責任者にも分かるように説明されている。特に生産性やモチベーションを悪気なく下げてしまうケースに言及されており、思うように開発が進まなかったり、人材の流出に悩んでいるなら本書を学ぶと良いだろう。
全体的に表現が平易でわかりやすく、ページ数が少ないので負担なく読める。著者の倉貫さんの本は毎回読みやすくなっているが、その中でも本書は特に読みやすくなっている。
書いてある内容はエンジニア目線で共感できるものが多い。また、逆に多くのエンジニアができていないことへの言及もある。エンジニア以外の人にぜひ読んでもらいたいし、エンジニアも読んで態度を改めるべきだと思う。「そのやり方、誰も幸せにならないからやめませんか？」という対話をしていこう。
Posted by ブクログ
かなり凄い本
この著者の方は何冊か本を出版しており、それの最新作
内容がかなりシンプルかつ濃厚で、時間があまり取れない人でも読めるようになっている
Posted by ブクログ
令和の「人月の神話」。
意図的に平易な表現が使われ、ページも少なく、30分あれば一通り読み切れるサイズ感。
エンジニア経験者なら「何を当たり前のことを」というような内容で、コンパクトにまとめたがゆえの語り落としもある(スクール出たてのエンジニアが戦力にならないとしたら、彼らはどう育てるの？とか、急かすと将来に影響があるのはわかるがビジネス的に守らなければいけない日程とはどう向き合うの？とか)。けれども、そんなハンデを背負いつつも「届きやすさ」に勇気を持ってふりきった本書に心から敬意を表する。
Posted by ブクログ
読みながら感じたのは、すごく頑張って平易な表現を貫いていて感服すると同時に、強調するが故にちょっと言い切り過ぎかなと思う部分もあった。エンジニアが詰められた時にうまく返せたり、そもそもうまいこと説明するのに役立ちそうなので、エンジニアじゃない人の感想が知りたい。
Posted by ブクログ
システム開発を進める上での「啓蒙書」である。
人が増えても速くならない、というタイトルが既に真理を述べている。遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけになりかねない。人を増やすことで、教育コストやコミュニケーションコストが嵩むし、タスクを分解するにも限度がある。マネジメントの難易度も高まる。
ソフトウェアのプログラミングにおいては、人数と生産性に必ずしも短期的には相関関係がない。工程を分離するよりも、できるなら、1人の人間が一気通貫で担当する方が、動的なソフトウェアを維持しながら変更していくには都合が良い。
そう考えると、既にいる人たちの生産性を上げることの方が有効な場合がある。高い生産性を出せるような環境の用意やクラウドの性能の増強など。給料や受注金額を上げ、そのプロジェクトに関わる少数に振り分ける方が、人を増やして、一人当たりの取り分を減らすよりもよほど有効だと思う事は多々ある。しかし、組織は特例を作りたがらず組織の慣習に従うのが常だ。既得権化させたくないし、他者からも同様な要求を受けかねないからだ。インセンティブ制度は、事程左様に難しい。
プログラムは単純に手を動かすだけでは開発できず、プログラムを書く仕事で求められるのは抽象化能力である。「近い未来は解像度高く、遠い未来は曖昧なまま」。肌感覚で分かっていた事を言葉にしてくれたような本だ。
Posted by ブクログ
エンジニアの考え方や事情をただ記述するような、いい意味でで思っていたような本ではなかった。エンジニアをマネジメントする場合の考え方を示してくれる良き本でした。
Posted by ブクログ
システム開発がプロジェクトからプロダクト中心に変わると、関わる人たちの関係性も変わることになります。これまでの完成を目指したシステム開発であれば、「システムを依頼する人たち」と「システムを開発する人たち」という形で分かれていました。しかし、社外に限らず社内であっても受発注のような関係では、変化に柔軟に適応していくシステムは手に入りません。動かし始めてから、次々と直したいところが出てきても、その度に発注するように依頼することになってしまうからです。プロダクトという共通の成果物と、目指す共通の目標を持つことで、システムは「依頼して作ってもらうもの」から「協働して一緒に作るもの」に変わります。そして、システムは完成を目指すものでなく、事業と共に改善を続けるものになるのです。成長し続けるために、変化に適応できるソフトウェアの作り方と考え方を身につけましょう。
■なぜ正確な見積もりが出せないのか
・詳細までの仕様を把握しきれなかった
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある
事業側と開発側が受発注の関係ではなく、共通のゴールを目指す同じチームとして協働の関係を築くためには、システムを作ることだけを目的とした体制やマネジメントをしないことです。あくまで事業や活動があり、その成長や成果のためにシステムを作るとするのです。
そのためには、まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。エンジニアではない人間からすると、エンジニアたちが何をしているのかわからないため、きちんと頑張っているのかどうか不安になるわけです。しかし、ある程度の頻度で、作るべきサイズを小さくすれば、進んでいるかどうかは確認できます。
大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。ソフトウェアは動いてこそ価値があり、使ってこそ直したい箇所が見つかるからです。
そして、何度も打席に立ち、自分たちのプロセスや取り組み方に学びを得ることで、ソフトウェア自体の不確実さは解消されないにせよ、進め方のノウハウが溜まることで成功確率を上げていくことができます。同じチームで、小さなプロジェクトに何度も挑戦していくことで、チームビルディングも進むでしょう。
Posted by ブクログ
アジャイルの考えを平易かつ簡潔に説明した本。アジャイルの勉強を始めたばかりの自分にとっては、これまでの学びを別の表現で復習できた。
◾️覚えておきたい標語
近い未来は解像度を高く、遠い未来は曖昧なまま
◾️見積もり
・見積もり精度を高めるために、どこまでも詳細に考えていくとしたら、それはもはやそれは設計である。つまり、限りなく正確な見積もりは、実際にやってみることでしか出せない。
・大きな機能の見積もりは、あくまで見通しである。1〜2週間の期間であれば、どれくらいの進捗を出すことができるのかを、高めの精度で見積もることができる。
◾️本書のテーマ外だけど覚えておきたいこと
・コードレビューは属人性の排除に有効。優れたエンジニアに指摘してもらうことで品質の向上が見込め、かつ、良いプログラムの書き方を学ぶことができる。
・週に一度、1時間を「ふりかえり」の時間にして、仕事を通じて経験したことを抽象化、言語化する。これを学びとして、次の仕事に活かす。
Posted by ブクログ
他の一般的な業務では通用することでも、システム開発では通用しないことがまとめられている。システムをわかってない上層部にどう言えば伝わるのか？参考にしたくて読んだ。
手伝いを入れると生産性が下がるってのは、自分が言いたかったことをちゃんと言ってくれた感じ。育成と生産性向上の両立は、システム開発では難しすぎる。システムを知ってるはずのシステム開発会社のマネージャでもこういうことをわかってない人は多いと思う。
Posted by ブクログ
ソフトウェア開発におけるよくある勘違いについて、実際の開発での難しさを説明している。ソフトウェア開発に対して完全に素人レベルのユーザーや管理職であれば得るものがあると思う。自分としてはそういう人たちがどんな勘違いをにているのか知ることで役に立つかと思ったが、あるあるネタ中心なのであまり参考にならなかった。
