倉貫義人のレビュー一覧

「納品」をなくせばうまくいく

自分はシステム開発など、全く門外漢ですが、とても、共感できる内容。
自分が働きたいのはこんな仕組みの会社だなと感じました。

スッキリとして読みやすいのに、とても整理された文章も印象的。会社の内容と同時に、こちらもスッキリしてムダがない。そして、芯がしっかりしています。

この理念というか考え方は、今後、日本の中小企業が皆見習うべき部分だと思います。

「納品」をなくせばうまくいく

システムの受託開発を長くやっていると、顧客と開発者との間に意識のギャップを感じることが時々あります。システムの完成させるという目標は一致しているはずなのに、その先の最終ゴールの捉え方が致命的に異なるのです。
こうしたギャップは、システムを使ってビジネスを拡大したり作業を改善することをゴールと捉える側（顧客）と、システムを完成させること自体をゴールとする側（開発者）の立ち位置の違いから考えると、当然なのかも知れません。
このようなジレンマを抱えながらシステムの受託開発をやってきた私のモヤモヤを、本書は多少なりとも晴らしてくれたような気がします。

システム開発側（特にエンジニア）はとかくシステムを作ることだけに目が向きがちですが、「ソフトウェアは使い続けることではじめて価値が出る」「なぜそのソフトウェアが必要なのか」等々を常に念頭に置いて顧客と接することで、顧客からの信頼を勝ち取ることにも繋がるのではないでしょうか。
特にソフトウェアは出来上がるまで目に見えない分、使ってみることで顧客が本当に必要とするものが分かることが多々あります。そういった意味でも「納品のないソフトウェア開発」のスタイルは、本当に必要なものだけ作ることが実現できる分、余計なコストがかからず顧客にとっても嬉しいはずです。
一方エンジニアにとっても、顧客からのフィードバックを受けやすく、やりがいのあるやり方であると言えるでしょう。

本書にも書かれているとおり、「納品のないソフトウェア開発」はサービスを提供する会社やスタートアップ企業と相性が良いようです。一方で、少数精鋭のエンジニアで臨む分、大規模な基幹システムには向かないような気がします。
ただ、たとえ大規模システムであっても、顧客と開発者の連携やワークレビューなど「納品のないソフトウェア開発」のやり方を応用することで、従来のプロセスを見直すヒントになるのではないかと感じています。

「納品」をなくせばうまくいく

（納品のない受託開発とは？）……本当に必要な機能を本当に必要な順番に、少しずつ開発をしていくことが大事になります。一度に「作りきる」のではなく、少しずつ作っていくために、私たちは月額定額制で「納品をしない受託開発」をすることにしました。
（格安航空会社はなぜ成立するのか？）……・使用する飛行機の機種を統一することで整備費やパイロットの訓練費を削減したこと。・搭乗手続きのオンライン化などITを活用した自動化・乗務員が機内の清掃などを行い一人何役もこなすことによる人件費の削減です。
（「バグはゼロ」ではなく、すぐに直せること？）……「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しのよいプログラムを書くことで何があってもすぐに直せることに重点をおくのです。

「納品」をなくせばうまくいく

株式会社ソニックガーデンで実際に行われている
「納品のない受託開発」という新たな開発スタイルに関して、
・どんなものか説明
・どのような利点があるか
・既存の受託開発の問題点
・自社の枠に留まらない「納品のない受託開発」の展望
などについてまとめてあります。

従来のウォーターフォール・人月見積もりなど問題点の多くある
業界では、未だにそういった状況を抜けだせていない現場が多い。

アジャイルな手法を導入してみるものの失敗したりしている現場もあるが、
非効率な商慣習の縛りをそのままにアジャイルの手法を導入しているため、
うまくいかなかったり・・・。

そんなケースが多い中、「納品のない受託開発」では顧客との取引方法を
根本的に変え・取引相手も開発スタイルに適した相手に絞ることで、
アジャイル・スクラムなど有効とされる開発手法を徹底的に導入して
システム開発会社・エンジニア・顧客全てがWin✕Winになります。

紹介されている各トピックは、勉強熱心なエンジニアの方ならどこかで
聞いたことのある内容が多いと思います。
しかし、色々と既存の制約に縛られがちな日本の受託システム開発において、
これらのトピックを有効活用し、実運用に活かせるように適用する方法を考え、
実際に事業を回していることにこそ、この手法の価値があるのだと思います。

システム開発に関わるものであれば、
読んで何かしらを得られる良書だと思います。

「納品」をなくせばうまくいく

納品に追われ、終わったら別の顧客（案件）という流れにいる身としては、全く対極で刺激的な内容。お客さんと、月額に対する成果の価値観に差がでないか？など気になる点もあるけど、うまくできれば顧客との関係や働き方、やりがいなどプラスの面も多そう。

ザッソウ 結果を出すチームの習慣

新しいことを生み出していく仕事の場合、各メンバーの些細な気づきを発信できる場は重要。心理的安全性の高く、ザッソウの生えるような職場であることが大切だと思った。

自分の弱みも見せながら、同僚に話しかけていく姿勢を持ちたい。

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

見事に受託開発の問題点を示している。
素晴らしい本だった。

* 人を増やしたからといって、速く作れるわけではない
* 正確な見積もりを求めたら、見積もりが膨らんでしまう
* 一度に大きく作ろうとするほど、結局は損をしてしまう

第1章
完成しても、終わりではない
システムは使い始めてから改善が始まる
システムが動き始めてからの修正を難しくする原因
①行きあたりばったりで改修を加えてしまう。ソフトウェアは精緻なジェンガみたいなもの
②一度きりの完成を目指してしまう
プロジェクトからプロダクトの考え方に変える
協働して一緒に作るもの

第2章
人を増やしても速く作れるわけでない
エンジニアの行っているプログラミングは、家の設計士のやっている仕事になる、とても頭を使う仕事なので、増やしたからといっても生産性が上がるわけではない

「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
『人月の神話』「ブルックスの法則」
遅れる３つの理由
①あとから入った人の情報や知識のキャッチアップと、その人たちへの教育にコストがかかる
②関わる人数が増えると、メンバー同士でのコミュニケーションにかかる時間が増えてしまう
③タスクを分解するにも限度がある
この問題解決には2つの方法（金の弾丸）
①高い生産性を出せるような環境を用意する
②クラウドに移管したうえで、クラウドの性能を増強する

速く作れるチームは作れる

第3章
たくさん作っても生産性が高いとは言えない
あらゆる状況を考慮するのに時間がかかる
その機能がなぜ必要なのか、事業にとってどういう意味があるのかが、伝わると効果的
影響範囲に気をつけて、重複をなくすことも仕事
同じソフトウェアを複数人で同時改修するのは非効率
プログラムは、どれだけ書いたのかの量ではなく、中身の質こそ大事
機能も少ないシンプルなものでいた方が良い

第4章
人に依存せず同じ品質で作ることはできない
ソフトウェアは、すべてが一品モノ
属人化を解決し、中身の品質を担保するためには、コードレビューが良い

第5章
プレッシャーをかけても生産性は上がらない
一時的な妥協は、永遠の負債になる（技術的負債）、対策としては少し作っては、シンプルな状態を維持できるように手を加え続けること
バージョンアップは動作確認が必要なので相当なコストがかかる
動作確認の自動テストは最初のコストがかかるが、後々いい
週に一度、1時間は「ふりかえり」の時間を取って、仕事のやり方やプロセスを見直すのがオススメ

第6章
見積もりを求めるほどに絶望感は増す
ソフトウェアを開発するのに、どれくらいの時間がかかるのかをざっくり知りたいという、事業側の気軽な発言が、エンジニアにとってはとてつもなく難しいことだとは知られていません
ざっくりの見積もりだと外れてしまうのは、次のようなケース
・詳細までの仕様を把握しきれなかった
動かしてみてはじめて必要な機能がわかることがあります
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある

エンジニアにしてみると、見積もりは"約束"に近い感覚があるため、かんたんには出したくない
そこからバッファを積まざるをえない、そしてマネージャーはさらに根拠なくバッファを積む、「パーキンソンの第1法則」

見積もりと約束が"受発注"の関係を作ってしまう
システムはマイナスからのスタート
システムは、事業や活動が内包している一部
システム開発で目指したい姿は、事業や活動のミッションを達成するための"協働"の関係
システムを作ることだけを目的とした体制やマネジメントをしないこと
まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。
ポイントは、「機能ありきで期間を見積もる」のではなく、「期間ありきで機能を見積もる」ことです。限られた人員と期間の中で、できる範囲で動くシステムを作っていくこと。それを、エンジニアだけで進めるのではなく、事業側の役割を持った人間も含めたチームとして確認して進めていくことです。
チームとなることで、「何を作るのか」を決めてからエンジニアに依頼するのではなく、「何を実現したいのか」から相談することになります。
開発したシステムは順次使い始め、フィードバックを得て改善していく

「納品」をなくせばうまくいく
ソニックガーデンでは月額定額の顧問型サービス「納品のない受託開発」を提供

第7章
一度に大きく作れば得に見えて損をする
ソフトウェア開発において、大規模なプロジェクトにすることのメリットは「ない」と断言しても過言ではありません。
ソフトウェア開発はギャンブルのようなもの、
大きく賭けると大きく失敗する
ソフトウェア開発のプロジェクトは、不確実さとの戦いでもあります。“プロジェクト”と言いつつも、ソフトウェア開発は製造ではなく、試行錯誤が不可久な研究開発に近いため、予算と期間の中でまちがいなく進むことを管理するスタイルのマネジメントは向いていません。
小さくすれば不確実さを下げられる
大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。
小さく作って、大きく育てられるのがソフトウェアだが、ソフトウェアの特性を活かした作り方や体制で開発していないと難しいとなる
少しずつ確信を持ちながら少しずつ進めていくのは、新規事業や業務改善において欠かすことのできないアプローチになります。
作ろうとする機能の範囲を限定し、技術や仕様で不明確な部分を無くすと見積もりが正しくなりやすい。そして仕様を明確にすると言って設計書を用意する必要はない。そもそも、仕様を把握する人間とプログラミングする人間は同一人物であるべきなのです。
優先順位を決めてスコープを狭め、不確実性を下げた状態で作り出し進めていく

第8章
工程を分業にしても、効率化につながらない
ソフトウェアを作るということは、新規事業の創出や、研究開発のようなものです。
ソフトウェア開発には雑用がないし、1～2ヶ月ほど現場にいたからといって慣れてできるようになる仕事もありません。

おわりに
「変化に対して管理やコントロールをしようとするのではなく、あるがまま受け入れつつ柔軟につきあっていくこと」が著者の主張

「納品」をなくせばうまくいく

アジャイルのスクラムとほぼ同義ではあったので、ある程度知っていることは多かった

とはいえ、顧客にも分かりやすい言葉で噛み砕いて書かれているので、これは発注者こそ読むべき一冊だと思う
また、昨今受託ビジネスはコンサル寄りに移っております、まさに納品という形ではなく顧客のビジネスを共創していくことが求められているので、時代は変わりつつあると実感できる

ザッソウ 結果を出すチームの習慣

雑談してこまめに相談できるとよし

×人間関係が希薄、助け合いが起きない、チームで相談できない、チームで働く意義が感じられない、弱みを見せることができない、新しいことに挑戦しない

今の組織は駄目な点が全部当てはまっていた…

ザッソウ 結果を出すチームの習慣

・チームで働くことで、自分の強みを生かすことができるのと同時に、仲間の弱い部分を自分の強みで補いあえるからこそ、より大きな成果を出すことができるのです。
・効率化だけを求めるチームでは、すぐに成果が出ないような意見を出しにくくする「同町圧力」が発生します。なるべく多数派に巻かれておく方がもめることもないので、平和に過ごしたい多くの人にとっては「意見なんか出さなくていい」となってしまうのです。
・生産性の高いチームの共通点
1.心理的安全性（たとえミスしても非難されない）
2.相互信頼（仕事を最後までやり切ってくれる）
3.構造と明確さ（有効な意思決定プロセスがある）
4.仕事の意味（自分自身にとっても意義がある）
5.インパクト（どう貢献しているか理解している）
・テディベア効果：自分勝手に話しているうちに自己解決すること
・とりわけ再現性の低い仕事において重要なのは、共同化と呼ばれる暗黙知のまま共有していくプロセスです。創造性を求めると属人性が高まることは仕方ないとして、「どうやって個人の持つ暗黙知を共有していくのか」「どうやって形式知に落とし込めない経験則や学びを伝えるのか」これらについて考えなければなりません
・チームワークの7つの段階
　レベル7 : 新しい価値を共に生み出す　Create new Value
　レベル6 : 協力する　Deal with conflicts
　レベル5 : 相談する　Consult across domains
　レベル4 : 共通のゴールを持つ　Share a common goal
　レベル3 : 理解する　Understand one another
　レベル2 : 話をする　Share casual conversations
　レベル1 : 知っている　Know each other
・タックマンモデル：形成期（フォーミング）→混乱期（ストーミング）→統一期（ノーミング）→機能期（パフォーミング）
・ストーミングは一時的に生産性が下がるが、徹底的にすり合わせて超える
・YWT : やってきたこと、わかったこと、次にやること
・相談を受ける側は軽やかに、悩むことなく受け止めて話しを聞いてあげると、それが相手の行動を促すことにつながります
・出来上がりの良しあしの前に、まずは仕事をしたこと、確認できるところまで持ってきたことを認めるべき

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

本書は、サブタイトルに「変化を抱擁せよ」とある通り、変化が起きる前提でどのような姿勢で向き合うかエンジニア誰もが感じる部分を言語化している。

以下は、気になった文章のメモ

・ある一点の完成を目指すことは逆に言えば一度だけ完成すればいいということになる。そうなると、完成後のことより完成させることに力学が働く。
・プログラムは現実の理解の上に成り立つ
・プログラムを書く仕事で求められるのは抽象化能力
・一時的な妥協は永遠の負債になる
・シンプル化する。借金を返済し続ける
・目の前の生産性を上げるのか。それとも、生産性を上げる仕組みを作るのか。
・大きな機能の見積もりは、あくまでも見通しである
・不確実な未来を、少しずつ確実なものにしていく
・ソフトウェアを作ると言うことは新規事業の創出や研究開発のようなもの。レシピを作る仕事に手を動かすだけの人は不要
・プログラムは最も低い品質に引っ張られる

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

＜本のタイトル＞
人が増えても速くならない　～変化を抱擁せよ～

＜本の紹介＞
・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない

＜何が書いてあったか（誰でも書ける）＞
・システムは使い始めてから改善が始まる。リリースはスタート地点に過ぎない
　ー想定外の新しい要望が出てくる
　ー使い始めたらかえって生産性が落ちてしまったとかもありえる
　ーユーザーが増えると負荷が高まってパフォーマンスが落ちる
　ー法律が改正されて業務フローの変更を余儀なくされる

・ソフトウェアは精緻なジェンガみたいなもの。
　行き当たりばったりの改修ではどんどん複雑になり、混乱の極みにやがて陥る
　「とにかくシンプルに作ること」と「少しずつ作って手を加え続けること」が大切。

・システムは完成を目指すものではなく、事業とともに改善を続けるもの
　また「依頼して作ってもらうもの」ではなく、「協同して一緒に作るもの」である。

・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
　そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
　ソフトウェアを育てると同時に、開発チームも同時に育てることで、
　持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。

＜そこから何を学んだか（自分自身のオリジナルの意見）＞
・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
　そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
　ソフトウェアを育てると同時に、開発チームも同時に育てることで、
　持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。

＜それをどう活かすか（アウトプットによる実践経験の蓄積）＞
信頼関係や心理的安全性だけではまだ十分ではなく、
開発哲学やポリシーというのを明文化する動きも必要と感じた。

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

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

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

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

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

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

読んでみての感想です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「納品」をなくせばうまくいく

「納品のない受託開発」というソニックガーデンのビジネスモデルについて、効果・仕組み・向き不向き・事例などについて、従来型の一括請負の問題点の指摘とともに説明されている。

「納品のない受託開発」は合理的で素晴らしい仕組みだと思うが、本書でも注意喚起されているとおり万能ではなく、また、実現のための前提が難しいものになっている。
たとえば、エンジニアや会社のスキルやモチベーションの要求水準が高いこと、顧客側の作業や体制への要求も比較的高いこと、システムの会社や規模に制約があること、など。
つまり、ソニックガーデンやそれに類するレベルの高さが要求されるため、誰でも容易に真似できるわけではないという点は留意したい。

本書は昔買ってから時々つまみ食いのように読むだけで積んだままになっていたが、唐突に読みたい気持ちが高まってきたので読んだ。
スピードを重視して4章と7章は流し読みした。

35ページ
納品があるから見積りが必要で、逆算して人月を使わなくてはいけないし、バッファが入って高くなる。さらに、現実的でない要件定義をしなければいけないし、開発と運用の切れ目ができて担当者が変わると、その引き継ぎコストがかかるなど、一つもよいことがありません。
→わかる。そういうものだと割り切っている。

37ページ
毎月の決まった金額の中で、「できる範囲」で精一杯の「開発と運用」を行います。ソフトウェアの開発と運用を分けることなく一体的に担い、その他にもソフトウェアに関わるあらゆる問題について対応します。
→よい答えではあるけど、担当者のハードルが高い。高いスキルとモチベーションが必要になる。

52ページ
エンジニアを採用してインソーシング（内製）することの難しさと、一括請負でアウトソーシングする要件定義の難しさの両方に困った会社が、要件定義をしなくてもよい「納品のない受託開発」を求めているというわけです。
→たしかにこのシチュエーションなら非常にマッチすると思う。実際問題としてエンジニアの採用は採用側がエンジニアであったとしても難しいし、要件定義をするにもエンジニアリングのノウハウがなければ成功率は低いだろう（まぐれで成功することもあるとは思う）。

71ページ
実際にこのビジネスモデルには、それを遂行する上での課題や注意点が多くあります。その中で時間をかけて経験を積み、ノウハウを得ていくことでしか、うまく進める方法はないと思います。
→これもわかる。容易ではないし、これを実行できているソニックガーデンはすごい。

99ページ
事業の設計段階はもとより、開発段階での毎週の打合せの際に必ずお願いするのは、打合せの場に顧客の事業責任者に同席してもらうことです。
→ハードルが高い。巷でアジャイルのマネごとをしてもうまくいかないときにありがちな原因のひとつ。開発会社だけががんばって取り組んでも、同じタイミングに顧客側が同じくらいがんばって取り組めなければうまくいかない。開発会社は顧客の理解を得て誘導しなければいけないし、顧客は理解した上でついていかなければいけない。

102ページ
たとえば、毎週の打合せや動作確認も、顧客からすればそれなりの時間と手間を取られることになります。
→99ページの件と同じくハードルが高い。

147ページ
これに対して、「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しの良いプログラムを書くようにすることで、何かあってもすぐに治せることに重点を置くのです。
→素晴らしい。この考え方は納品のない受託開発に限らず、通常の開発であっても適用するべきだと思う。

158ページ
それだけの幅広いスキルを備えたエンジニアはなかなかいないのでは、と思われるでしょう。たしかに誰にでもできる仕事ではないと思いますが、私はそもそもソフトウェア開発とは、誰にでもできるものではないと思っています。
→ハードルが高い。しかし書いていることはごもっともである。

170ページ
日本語の資料を残さない代わりに、プログラムの読みやすさには徹底的にこだわっています。
→素晴らしい。巷のシステム開発では、ドキュメントは書かず、プログラムも難解で読みづらい状態になっているというケースが少なくない。ドキュメントを書かないこと自体は問題ではないが、その分、保守性を担保できるような手立てを用意して責任を取るのがプロの仕事である。

180ページ
私の言うプログラマーとは、「納品のない受託開発」で求められるような、企画の段階から考えて、画面のデザインや仕組みの設計ができて、それを自らプログラミングし、クラウドでの運用まで、ソフトウェア・エンジニアリングに関わるすべての工程をこなせる人のことを指しています。
→ハードルが高い。必要な仕事であってもそこは自分のスコープ外だからやりません・知りません、という態度をとって見向きもしないような人間ではいけない。

189ページ
これは、テクニック（T）、インテリジェンス（I）、パーソナリティ（P）、スピード（S）の4つの頭文字を合わせたもので、この4つの視点は、私たちが優れたエンジニアを選抜する際に考えていることにそのまま当てはまります。
→使えそう。マネしてみようと思った。

196ページ
進行としては、KPTのKとPを、レビューされる側（＝レビューイ）がまず一人で出します。出揃った段階で、レビューする側（＝レビューア）とともに内容の確認をします。
→KPT自体は元々知っていたしやったこともあったけど、ワークレビューとして使う点や、K・Pをレビューイだけで書き出す点は理解できていなかった。

199ページ
社内規則（ルール）を明文化して社員を縛るよりも、ワークレビューを通じて、良識（コモンセンス）を共有することで社員を育てるという感覚を大切にしています。
→素晴らしい。実現性・有効性のあるオンボーディングの方法に悩んだことがあったので、今後はマネしようと思った。

200ページ
「ワークレビュー」は採用の際にも使えます。
→素晴らしい。目から鱗でした。これもマネしたい。

210ページ
90年代に登場したJavaは、最初はおもちゃのようだと思われていました。
→このエピソードは例え話なので本題ではないのだけど、この事実を知らなくて驚きがあった。たしかに冗長で過小評価されるのも理解できるし、その後のWindows・GUIの普及とJavaの躍進はむしろ過大評価かもしれないけど。

215ページ
もちろん、セルフマネジメントができているということが前提であって、真面目な性格であることも重要でしょう。そして、そういう社員だけを採用しているからこそできるのです。
→何回書いたかわからないけどハードルが高い。

229ページ
よく講演などでは「心はプログラマー、仕事は経営者」と自己紹介をしたりしています。
→よい。これも参考にしたい。心はユーザー、体はエンジニア、仕事はマネージャー。