長尾高弘のレビュー一覧

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

    Posted by ブクログ

    万人向けの人生の説明書という感じ。
    章構成がキャリア、セルフマーケティング、学習、生産性、資産形成、フィットネス、マインドセットとなっており、いずれも平易かつ説得力のある内容となっている。
    自己啓発本の側面もあるため、名言や著者の半生記も多い。具体的に書かれているやるべき内容をやれば確実に良い効果があることは分かるが、試みるかはまた別の問題。
    ここまで生き方について体系的にまとまった本は貴重。たまに読み返したい。

    0
    2023年02月01日
  • ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

    Posted by ブクログ

    マネジメントの学習のため購入。
    技術よりも大事なものは人で、人格の尊重、相応しいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織作りの大切さを学べてためになった。

    0
    2022年09月13日
  • SOFT SKILLS ソフトウェア開発者の人生マニュアル 第2版

    Posted by ブクログ

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

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

    0
    2022年08月28日
  • The DevOps 勝利をつかめ! 技術的負債を一掃せよ

    Posted by ブクログ

    ■5つの理想
    第1の理想-局所性と単純性
    第2の理想-集中、フロー、楽しさ
    第3の理想-日常業務の改善
    第4の理想-心理的安全性
    第5の理想-顧客第一

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

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

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

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

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

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


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

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

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


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

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

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

    0
    2022年01月22日
  • ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

    Posted by ブクログ

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

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

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

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

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

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

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

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

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

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

    0
    2021年07月04日
  • ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

    Posted by ブクログ

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

    0
    2021年05月10日
  • DevOps教科書

    Posted by ブクログ

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

    0
    2021年01月31日
  • 世界でもっとも強力な9のアルゴリズム

    Posted by ブクログ

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

    0
    2020年12月23日
  • マイクロサービスパターン[実践的システムデザインのためのコード解説]

    Posted by ブクログ

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

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

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

    0
    2020年09月20日
  • ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

    Posted by ブクログ

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

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

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

    0
    2020年08月02日
  • The DevOps 逆転だ! 究極の継続的デリバリー

    Posted by ブクログ

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

    0
    2020年07月11日
  • ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

    Posted by ブクログ

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

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

    Posted by ブクログ

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

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

    Posted by ブクログ

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

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

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

    0
    2019年01月20日
  • The DevOps 逆転だ! 究極の継続的デリバリー

    Posted by ブクログ

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

    0
    2018年11月04日
  • 世界でもっとも強力な9のアルゴリズム

    Posted by ブクログ

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

    1
    2018年10月23日
  • CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

    Posted by ブクログ

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

    0
    2018年12月17日
  • The Art of Computer Programming Volume 2 Seminumerical Algorithms Third Edition 日本語版

    購入済み

    内容は、間違いなし

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

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

    0
    2017年10月17日
  • Effective Ruby

    Posted by ブクログ

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

    0
    2017年02月13日
  • Effective Ruby

    Posted by ブクログ

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

    0
    2017年01月04日