長尾高弘のレビュー一覧

SOFT SKILLS ソフトウェア開発者の人生マニュアル 第2版

ジョン・ソンメズ / 長尾高弘 / まつもとゆきひろ

エンジニアのソフトスキルとしては前半3割くらいだが、より広範に人生の教訓を筆者の経験を一例に学ぶことができた。

ただ、筆者の経験や私見に基づく主張が多いので、本末尾のMatzさんの解説を先に読んでおいた方がよい。

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ

ジーン・キム / 榊原彰 / 長尾高弘

■5つの理想
第１の理想－局所性と単純性
第２の理想－集中、フロー、楽しさ
第３の理想－日常業務の改善
第４の理想－心理的安全性
第５の理想－顧客第一

　エンジニアが現実にいる人ではなく、抽象的な存在として”顧客”を考えると、まず正しい結果を生み出せない。

「ソフトウェアのデリバリーでリードタイムが重要だってことは、ニコール・フォースグレン博士とジェズ・ハンブルの研究でわかったことだ。コードデプロイのリードタイム、コードデプロイの頻度、問題解決時間を見れば、ソフトウェアのデリバリー、運用の能力、組織の能力がわかる。そして、これらは社員の燃え尽き、社員の士気、その他さまざまなものと相関してる。」
　単純性が大切なのは、単純じゃなきゃ局所性が得られないからだ。システムを疎結合に保ち、機能のデリバリーをスピードアップしたければ、コードの局所性が必要不可欠になる。局所性が実現されていれば、チームはまわりのチームのことを気にせず、お客さんにとって価値のあるものをすばやく開発、テスト、デプロイできる。組織に局所性があれば、チームの外の人々と話し合って調整しなくても決定を下せる。現場の仕事からかけ離れていて、いい判断を下せる基盤がない権威や委員会なんてもんから承認をもらう必要もなくなる」

「…日常の仕事の改善を重視していかなきゃダメなんだ。日常の仕事以上にそっちに力を入れなきゃならないくらいだ。そこまで徹底して局所性の実現に集中しなきゃ、どんなシステムでも時間とともに劣化し、技術的負債のなかに埋もれちまう。…」

「いろんな定義があるけど、私が気に入っているのはウォード・カンニガムが2003年に作った定義だな。彼は、『技術的負債とは、次の機会に書き換えたいと思うもののことだ。』って言ったんだ。人々が技術的負債と呼んでいるもののなかにはいろんなものがあるけど、たいていはクリーンアップしたいもの、単純にしたいものとか単純さを取り戻したいもののことだね。直せば、自信を持って早く安全にシステムを変更できるようになる部分だ」

「技術的負債になるのは、たとえばプログラマーに早くフィードバックを渡せないビルド、テストシステムがそうだし、この手のシステムが動かなくなったときもそうだ。それから、単純なコンポーネントがコンプレクトになって、莫大な労力をかけたり、大事故のリスクを背負ったりしなきゃ何をしてるのかわからず書き換えることもできないときもそうだね。意思決定プロセスや組織構造に局所性がなくなり、小さな決定を下すために、エスカレーションが必要になる、君たちが罵倒する”官僚主義”もそうだ。

　私はこういったものを全部“複雑性負債”って呼ぶことにしている。これは単なる技術的な問題ではなく、ビジネスの問題だからね。で、こういった負債にはあれとこれのどっちを選ぶかって問題がかならずくっついてくる。新しい機能を作るか、複雑性負債を全部返済するかっていうようにね、機能を作ることのために自分の時間を全部使っちゃうバカがいると、簡単な仕事が難しくなり、実行に時間がかかるようになるのは避けられないな。そして、0から始めようとすると、どんなにがんばっても、どんなに部下がいても、最終的には自分の重みのために潰れるだろうね」


「理想は5つある。第1の理想、局所性と単純性についてはもう言ったね。システムとシステムを作る組織に局所性が与えられるように仕事をデザインしていく必要がある。そして何をするにも単純でなきゃならない。コードのなかであれ、組織のなかであれ、プロセスのなかであれ、内部に複雑さがあるのはだめだ。外部はもう十分複雑なんだよ。だから、自分たちでコントロールできるもののなかに複雑さが持ち込んだら大変なことになっちゃう」

「第2の理想は集中、フロー、楽しさだ。これはみな日常の仕事で感じるようにしたいことだよ。退屈して自分のためにほかの人が仕事をしてくれるのを待っていないか？全体を見ないで全体のごく小さな一部の開発とだけ考え、デプロイで全体が吹き飛んでいても自分の作業の結果しか見ず、火消し、懲罰、燃え尽きを招いていないか？それとも､小さなバッチ単位、できればひとつの新機能単位でデプロイし、継続的にスピーディなフィードバックを得ているか？これらは、仕事に集中とフロー、挑戦、学習、発見、担当分野のマスター、そして楽しみを生み出す条件だ。

「…第3の理想は、日常業務の改善だ。日常の仕事自体よりも日常の仕事の改善を大切にしなきゃいけない｡そのことを教えてくれるトヨタのアンドンの紐についてよく考えよう。第4の理想は心理的安全性だ。問題の解決のためには問題の予防が必要で、問題の予防のためには率直さが必要だ。そして、あとでどうなるかわからないという怖さがあれば、率直になどなれない。工場では、身体的な安全と同じくらい心理的安全性、つまり安心感も大切なんだよ。そして第5の理想は、顧客第一、つまり機能などがお客さんにとって本当に必要なものかどうかを徹底的に批判的に考え抜くことだ。お客さんがこの機能のためにお金を出す気になるか、それとも自分たちの職場の都合からくる自己満足に過ぎないのかってことさ」


「…
　技術的負債は、納期と同じ日常のことだ。ビジネスの人々は、納期のことはわかっても、技術的負債もあるということをまったく知らないことが多い。技術的負債は、それ自体ではいいことでも悪いことでもない。技術的負債が生まれるのは、日常の仕事のなかでいつも決断を迫られるからだ。長持ちしないことがわかってても、仕事の都合で近道を通ったり、自動テストを省略したり、特定の条件のためにハードコードしたりすることがあるだろう。日常的に、手作業で環境を作ったり手作業でデプロイをしたりといった次善の方法で我慢する場合もあるよな。こういったことが将来の仕事の進捗にどれぐらい大きな影響を与えるかがわかってないと、大きな問題を起こすわけだ」

「…
　これは従者を引っ張るリーダーシップじゃなくて、変身を促すリーダーシップだ。組織のビジョンを理解し、仕事のやり方についての根本的な前提条件を疑うアグレッシブな知性と人の心を動かすコミュニケーション能力を持ち、メンバーの特徴を把握し、支える指導力がなきゃいけない。…」
「…最高の能力を持たなきゃいけない。とことん完璧を追求し、できる限り早くミッションを達成しようという気概を持ち、現状維持に決して満足せず、組織が奉仕する人々をしっかり支えようという熱意を持たなきゃいけない」

　マキシンは、ミーティングの経験から、心理的安全性を実現する条件がいかに薄弱ではかないものかを強く感じるようになった。心理的安全性は、リーダー、同僚の行動、雰囲気、自尊心、過去から引きずっている心の傷といったものによって左右される。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

p.5
プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な人間関係の結果である。

p.11
プロジェクトには「触媒」が不可欠。
「触媒」＝不安定な状態にあるPJのまとめ役

p.22
早くやれと急かせれば、雑な仕事をするだけで、質の高い仕事はしない。
仕事を早くするためには、製品の品質と仕事の満足感を犠牲にせざるを得ない。

p.26
エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。

p.40
ソフトウェア開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳密な処理手順に変換するための、人と人とのコミュニケーションである。これは、どんなにソフトウェア開発のライフサイクルを変えようと、絶対に必要な仕事であり、自動化できるはずがない。

p.41
管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。

p.52
意外なことに、残業の真の目的は、仕事の量をこなすことよりも品質向上のためなのだ。（定時の時間帯は仕事に集中できない）

p.166
チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。この目的が満たされたとき、チームのメンバーはずっと効率よく働く。

p.185
最大の成功は「管理」などないかのように、チームがなごやかに一致団結して働いたときである。最良の上司とは、管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人である。

p.195
健全な会社にするための不思議な作用を生み出す戦略的要素
・品質至上主義を作り出す
・満足感を与える打ち上げをたくさん用意する
・エリート感覚を醸成する
・チームに異分子を混ぜることを奨励する
・成功チームを解散させないで保護する

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

システム開発をする上で、人の扱い方に特化した内容。共感できる文言が多かった。
おそらく平社員よりも、マネージャーに向けた一冊だが、新人でも読んで考え方を知ることができて良い本だった。

DevOps教科書

レン・バス / インゴ・ウェーバー / リーミン・チュー / 長尾高弘

2016年出版（原書はもっと古い）なだけあり、コンテナアプリケーションの開発で盛り上がっている現在では、内容が少し古い
ただ、考え方の原理原則は転用が効くので、そこはしっかりと学ぶべき

世界でもっとも強力な9のアルゴリズム

ジョン・マコーミック / 長尾高弘

非常にわかりやすく読みやすい文章でアルゴリズムの面白いポイントを説明してくれる。
内容は時が経っても薄れず、本質的な面白さがいつまででも伝わる書き方になっていると思う。

マイクロサービスパターン［実践的システムデザインのためのコード解説］

Chris Richardson / 長尾高弘 / 樽澤広亨

結構楽しく読めた。
内容的には、ベーシックなレベルでマイクロサービスについてなんとなく基礎は勉強した人がそれをいざ実装やプロジェクトへの適用に落としていく際に、知識を集約・整理するのに使えるような内容という感じ。
同期的な処理ばかり書いていたけど、これを読んで非同期にも取り組まないといけないと思わされた。

実装の例やGitHubに公開されているソースコードの例は正直活用がしづらくて、時々言及するくらいならもう少しIDDDとかくらいには完全な形での公開が望ましいとは思ったけれど、それでも文中のコードでだいぶイメージを掴みやすくしてくれていたので良かったと思う。

上の方に小さく書かれているけど、
Microservices patterns with example in Javaということで、Java開発者、特にSpringに馴染みのある人は旨みをより得られやすいと思う。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

人人人。をとにかく意識したチームマネジメント、プロジェクトマネジメントの手法、考え方の教本。

システム開発のプロジェクトに特化された部分もあるが、噛み砕いてみるとプロジェクトマネジメントの核を捉えている事がおおい印象でした。

私自身まだ、リーダーとしてマネジメントしているわけではないが、リーダーになる準備、来たときにはまた部分読みを繰り返したいとおもいました。

The DevOps 逆転だ！ 究極の継続的デリバリー

ジーン・キム / ケビン・ベア / ジョージ・スパッフォード / 長尾高弘 / 榊原彰

システム開発プロセスの課題を、工場の見学によって俯瞰して洞察を得て、マネジメントに活かしていく物語。タイトル通りのDevOpsの文脈としてだけでなく、普段の業務プロセスのどこに無駄があるのか、それに対する解決のアプローチは製造業からヒントを得られることが多そうだと気付いた。アジャイルやスクラムを学ぶのもいいだろうけど、この本の学びを深めるために次はトヨタ・ウェイやザ・ゴールを手に取ろうと思う。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

メンバの心を掴み、チームをまとめ、生産性を上げるために心に留めておかなければならないことが網羅されている。古典だが折に触れて思い出さなければならない。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

マーク・パール / 長尾高弘 / 及部敬雄

リソース効率とフロー効率のくだりがよかった。これが考えられているか否かでその開発組織の質がわかる気がする

テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上

ジェームズ・A・ウィテカー / ジェーソン・アーボン / ジェフ・キャローロ / 長尾高弘

「3.2.1 テストプランの立案」が本質的でとても良かった。

ただ、ところどころにあるインタビューとかは若干読みやすさを損なう方向に行っている気はする。

この邦訳の刊行が2013年、原著は2012年なので、今現在のG社はもっとずっと先を行っているのだろうなぁ、と思う。SWE と SET は同じものになっていく、と最後に書かれているけどもうそうなっているのかも。

The DevOps 逆転だ！ 究極の継続的デリバリー

ジーン・キム / ケビン・ベア / ジョージ・スパッフォード / 長尾高弘 / 榊原彰

・ITの4種類の仕事―ビジネスプロジェクト、IT運用プロジェクト、プログラム変更、予定外の仕事。技術的負債を放置しておくと、予定外の仕事しかできなくなる
・（過度なセキュリティを追求する担当者に対して）会社にとって最大のリスクは、監査所見を解決できないことではない。会社が生き残れないことだ
・「お前はボブではなく、俺の下にいるこを忘れるなよ。この体制で働けないなら、お前をすぐクビにする必要がある」
・「人は、終わりなく続くホラー映画のように、自分には結果を変える力がないと思うと、不満をためてありがたみを感じなくなる。そのことが人間としての自分の価値を傷つけないわけがない。そういう状況を変えなければならないんだ」

世界でもっとも強力な9のアルゴリズム

ジョン・マコーミック / 長尾高弘

現在のコンピュータ社会を支えるキーアルゴリズムを９つピックアップし、身近な例もしくはアナロジーを使って解説する。この方法方法が見事で、素人にも理解でき、玄人にも満足できる内容となっている。

CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

ジョン・ソンメズ / 長尾高弘 / まつもとゆきひろ

キャリア組み立てについて意識することが少なかったのですが，改めていろいろな人の影響を受けたりして考える際のフレームワークになってくれる一冊でした．

The Art of Computer Programming Volume 2 Seminumerical Algorithms Third Edition 日本語版

DonaldE.Knuth / 有澤誠 / 和田英一 / 斎藤博昭 / 長尾高弘 / 松井祥悟 / 松井孝雄 / 山内斉

[Noritan]

内容は、間違いなし

ひとまず、持っているべき本でしょう。

ただ、筑紫フォントでないと、文字化けするようです。
ipad内蔵フォントでは、文字化けする記号がありました。

Effective Ruby

PeterJ.Jones / 長尾高弘 / arton

大切な考え方が多い。rubyのオブジェクト指向を学んだ。メタプログラミング等まだ読み残した部分が多い。

Effective Ruby

PeterJ.Jones / 長尾高弘 / arton

Rubyの深いところを掘り下げて書いてくれている本。
Rubyを触って1〜2年目くらいの人が読むと良いかも知れない本。
諸々役に立ちそうな話が多い一方（実際に使っているものも多く見かける）、さすがにそれ誰もやってないだろうという話や、時間経過とともに今となっては正しく無さそうな箇所も散見される。
一読の価値はあると思うものの、読みながら自分でも試してみて判断したほうが良い。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

以下、ポイント
マネージャーの役割は、人を働かせるのではなく、働く気にさせること。
精神集中状態、フロー状態になるには15分以上の精神集中過程が必要。電話が鳴る、誰かが話しかける職場では困難。
何カ月、何年の作業時間が、右脳のアハたいけアイデアにより解決する場合がある。音楽は右脳を占拠するので閃きを邪魔する。
人は基準から外れた人を恐れる。だから会社は同じような人を採用する。
チームの誇りはメンバーか成し遂げた成果。服装や髪型は関係しない。
リーダーシップとはサービス。自ら仕事を引き受け、準備をし、メンバーに価値を与える。ユーモアと善意の元に事にあたる。
結束したチームは、一体感がある。楽しい。給与、昇進は関係ない。
チーム殺し、チーム内の競争は互いの育成を不可能にする。何故なら教えた相手に追い抜かれるから。競争させるには、目標管理、表彰、能力評価。
仕事は煩わしいことという常識がある。楽しいならそれは仕事ではない。楽しんで金を貰ってはならない。楽しい場合は仕事らしい仕事、煩わしく、うんざりし、惨めな気持ちになるもの。仕事中に楽しくて笑ってしまうことは後ろめたい。
プロジェクトには触媒が必要。何か優れているわけではないがチームワークを醸成する人。
高品質が最終的にコスト低減をもたらす。
人間は混乱を秩序に変える本性がある。良いマネージャーは混乱を小さく配分する。そして混乱を秩序に変える快感を部下にもたらす。

世界でもっとも強力な9のアルゴリズム

ジョン・マコーミック / 長尾高弘

アルゴリズムの存在自体は知っていただけど、どのようにそれが機能しているかは知らなかったので、ためになった。