長尾高弘のレビュー一覧

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

図解と比喩でわかりやすい、さまざまなアルゴリズムの概念。

アルゴリズムとあるが、具体的なコードの載った実装のための本ではない。
「わたしたちが日常的に用いる、具体的で、コンピュータ科学理論に関連した」アルゴリズムを、情報検索、情報通信から人工知能に至るまで9分野にわたって扱っている。

複雑になりがちなテーマについても、段階を踏んだ説明があり（公開鍵暗号とデジタル署名における指数南京錠、決定不可能性におけるイエスノープログラムなど）、
また適切な図解と比喩が理解を助けている（公開鍵暗号の絵具混合トリック、ページランクのランダムサーファートリック）。

以前から知っているアルゴリズムについても、比喩を通じて核心を理解を深め、他のアルゴリズムとの関連を学ぶことができる。
（データベースのWALプロトコルの有用性：To-doリストトリック。誤り訂正とデータ圧縮：情報理論。）

わたしたちの普段の生活を支えているアルゴリズムに触れ、コンピュータ科学とはなにかというを学ぶことができる一冊。

Effective Ruby

序文にもあるとおり、Rubyの書籍は数多ある中で、今更何が書かれているのだろうと思いながらもなんとなく気になったので購入。

読んでみると、意外にも面白いトピックスが並んでいた。

話の展開としてはRubyの基礎から始まり、クラス、コレクション、例外、メタプログラミングといわゆる教科書的な構成なのだが、入門書に書かれているような基礎的な文法の説明などは一切なく、普通に学習しただけでは見落としがちな細かなポイントをケアしている。

Rubyの基礎を一巡りした後に読むと、Rubyのことがもう一段深く理解できる一冊。

Effective Ruby

学ぶことが多すぎて付箋だらけになった．「こういう時はこういうメソッド・手法を使おう」という指南書としての側面や，Rubyならではのハマりどころとその対処法についての最高のFAQであったり，とかく勉強になる本だった．
Rubyを書くときは，常に手元においておきたい一冊だと思う．

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

IT関連にかかわる仕事をしている私としては、それなりに理解できているアルゴリズムであったが、用語を知っている程度の人でもわかりやすいようなたとえで説明されていて、自分の理解が正しかったこと、中途半端に理解していたものを再確認できた。
ディジタル書名や公開鍵暗号は、これから学ぶ人にも役立つと思うのでぜひ読んでもらいたい。
うちの若い人たちにも紹介したい一冊である。

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

【目的】　ソフトウェア開発の問題における社会学的側面に注目し、どのようにマネジメントすべきかの指針を与える。

【収穫】　いかに人のやる気を引き出し、力を発揮してもらうか、ということがマネージャーの果たすべき役割と理解できた。

【概要】　■プロジェクトにおける問題の本質：　技術的な問題というより、人がに関する問題、すなわち社会学的なものが多くの原因である。
■生産性に関する錯覚：　生産性＝利益÷コスト。コストは、退職者の補充にかかるコストも含まれるべき。長時間残業やプロセスの機械化により生産性を上げたとしても、それで人が退職すれば、実際の生産性は下がる。また、人のやる気やコミュニケーションを無視して、新しい技術的な手法によって生産性が飛躍的に向上するというのは、錯覚である。
■生産性向上に果たす要因：　誰と一緒に働くか、オフィス環境が快適か、チームとして一つにまとまる目標があるか、官僚主義的な手順に縛られていないか、といったこと。
■メソドロジー（方法論）における問題と代替案：　書類の著しい増加、手法の不足、責任観念の欠如、全般的な意欲の低下。作業方法の統一を実現するには、教育研修、ツール導入、ピアレビュー実施などの方法がある。標準化が必要でも、10ページ以下のゆるいガイドラインにすべき。
■マネジメントに必要なこと：　無理な納期や品質削減や権限を振りかざすリーダーシップは彼らの生産性に対して有効な手段ではない。オフィス環境をよくする、目標を一致させる、小さくて簡単な成功を体験させる、信頼する、等によりチームのやる気を引き出すこと。

【感想】　プロジェクトマネジメントのうち、特に人に関わる部分に対して深い洞察が行われている名著。ソフトウェア開発に関わっていれば、必ず理解できる部分があると思われる。

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

実際にプログラミングするための技術書ではない。しかし、（社会的に影響力のある各種）アルゴリズムの「妙」を平易な言葉でうまく伝えている。そこに美学を感じられるかどうかは人それぞれだろう。自分は十分共感するので星五つ。
どの章もわかりやすく面白いが、一風変わった（ゲーデルの不完全性定理とも絡んでいると思われる）「実現不可能なプログラムの存在証明」の章が一番印象的。

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

大規模なインフラを活用したテストとか、テスターもコードはバリバリ書けますとかはさすがだなと思う一方、Sテスト（単体テスト相当）、Mテスト（結合テスト相当）、Lテスト（システムテスト相当）とか、手動テストをやってたりとか、意外と普通な一面もあると思った。
バグのあるコミットをした数分後には問題が通知されるとか、SIerでもそういうの当たり前にやっていかなければいけないと思うし、とても良い刺激を受けたと思う。あとは行動あるのみ。

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

この本は改善を重ねた結果のテストの取り組み方としての組織のつくり方という部分が描かれていたり、また、採用に関しての話も面白かった。また自由に使える２０％タスクが現実的にはどのような形で運用されているのかというのも垣間見えた。

テストをする人を2種類に分けて考えるという考え方はなるほどと感じる部分があった。

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

2006年頃から、Googleがどのようにテストに関するソフトウェア開発組織をつくり、どう運用してきたかという話。SWE, SET, TEという職制の話あと、人々と個々の製品へのインタビューという形式。

20%を使って、リポーティングを含めたテストの効率化のツールを開発したという話がいたるところで出ている。Googleがとてもツールを大事にしているか、動くものを大切にしているかがわかる。
一方できちんとROIに基づいて判断をしているあたりもさすが。

ぜひ見習いたいものだが、マネジメントを含めた人材の質が違いすぎるのが問題か、、、
しかし、ソフトウェアに携わる人は誰でも、この組織と競争しなくちゃいけない状況にあることを意識する必要がありそう。

テストについてだけでなく、Googleのソフトウェア開発について知りたい人にもお勧め。

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

Google社内ではよくあるソフトウェア開発会社と異なり、製品開発チームと品質管理（テスト部門）が別組織として活動している。
別組織としてある事のメリットとしては以下のようなものが有るとのこと。
・製品間をテストのスペシャリストが移動することで、良いテスト手法を広めることが出来る
・テスタの数を抑えることが出来る。（製品開発序盤はテスタが必要とならない場合が多い）
・製品の価値を客観的に捉え、潰すべきバグの優先度を開発チームに周知することが出来る。

この時、Google内ではACC（Attribute Component Capability)という3つの値を利用して、製品の価値の優先度分析を行なっている。

SI企業ではPMOと呼ばれる進捗・課題・リスク管理を行う組織が製品開発部門のサポートに入ることはあるが、製品の品質向上をサポートする外部組織は聞いたことが無い。
ある程度大きなプロジェクトであれば製品開発当初からテスト部門が関わり、テストプランの作成、テスト環境構築、テストケースのチェックなどをサポートすることが必要なのではないだろうか。
Googleの様な高品質のプロダクトを生み出す秘訣がここにあると感じた。

しかし、巻末には、未来のGoogleにはテスト部門はそのうち無くなるのでは無いか？という記述がある。
品質の優先度を管理するメンバはよりユーザ側に立ち、製品のテストをコードレベルでサポートするメンバは開発エンジニアに近づいていくという理由からである。
これは、ある程度テストの手法・技術が社内で確立されたGoogleだから言えることではないかと思う。
その他の一般企業は先ずはテスト部門を立ち上げることから始めると良いのだろう。

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

マガジン（雑誌）のような本です。WhittakerらがGoogleでいかにCoolなテストをやり遂げたかが書かれています。

ここに書いてあること全てをそのまま実践するのではなく、何故彼らはこうしたんだろうと考えて、ヒントとして受け取り自分たちに合ったテストを構築していくのが正しい読み方だと思います。

とてもたくさんの刺激と知恵を貰えました。

そっかー、STEはTEの倍いるのか……。

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

新卒で企業に入社する前、入社後にシステム分野に取組むことになったことをインターン先に上司に報告したところ、紹介して貰って読んだ本。最近「The DevOps」・「運用」に悩む・取組む必要があり改めて読み直した。

運用の仕事は、予定された仕事の流れを作り出して社内に価値を届けることが重要であり、４つの仕事に分類されるという。ビジネス・プロジェクト、IT運用のプロジェクト、プログラム変更、予定外の仕事である。本書ではシステム改修のミスにより予定外の仕事が運用を圧迫し、予定外の仕事が出てくる要因を突き止めることから改善が始まる。予定外の仕事は修整作業であり目標から引き離すものである。

そして本書全体通して強調されるのは制約条件・ボトルネックの存在である。ボトルネック・制約条件により処理量が制限される以上、その前後の関係は無意味である。この点を踏まえつつ、予定された仕事の流れを管理、制約条件・ボトルネックに従い処理を構築し、制約条件・ボトルネックに遊ばせることがないようにする。予定外の仕事は制約条件・ボトルネックに係るか、本書では優秀なエンジニアであるブレントどうかで判断する。

運用には３つの道があると解く。「第１の道は、開発からIT運用への仕事の流れを速くするにはどうすればよいかだ。IT運用こそ、会社と顧客の間にあるものだからだ。第２の道は、フィードバックループを短縮、強化する方法だ。すると、源のところで品質を上げ、やり直しを避けることができる。そして第３の道は、実験、失敗からの学習、反復と練習が熟達には不可欠という考え方を並行して育てていく企業文化を作ることだ。」

それ以外に個人的に面白かったのは予定外の仕事が発生させないように予防する、変更管理の定義として「変更』とは、アプリケーション、データベース、オペレーティングシステム、ネットワーク、ハードウェアに対する物理的、論理的、仮想的な働きかけのうち、提供しているサービスに影響を与える可能性のあるものである」、細かい内容を提示させるがゆえに機能しない変更管理である。後者が見覚えしかない。

CTOの思考法 技術と組織を動かす意思決定・戦略・リーダーシップ

特にIT企業においてはCTOは常にインポスター症候群のリスクに苛まれる。CEOの信頼は時間と信用とCTO自身の自信から生まれる。技術畑の人が議論の勝ちを焦って意見を事実であるかのように話すと、致命的に信頼を損ないかねない。CFOとは仲良く…取締役会の心構えなど、今の自分には必要無いが、そういう世界もあるのかと勉強になった。トラブル時のプレゼン「PIP（問題、影響、防止策）」。集中してることを示すため、ノートPC持ち込まず紙と鉛筆で。誰かを責めたり名指ししない。社内政治を感情的意見を黙らせるデータがない状態と定義。緩和方法は、まず自分の社内政治的要素の認識をしてから、①脅しや受動攻撃に対しては敵意・皮肉無しではっきり言うよう指摘し、態度明確化、②相手の怒りの原因を明確化・理解、③具体的な批判を歓迎など。CEOやCTOに期待される指導は外部環境変化に受け身対応するのではなく、先回りして市場ニーズ予測し、最前線で指揮を取ること。エレベータピッチ。プロジェクトの節目達成のお祝い。スキルマトリクスはまずマネージャーが部員の職務経歴等から客観値を入れて、それを本人と面談して修正してもらうのが良い。Disaster Recovery。マイクロサービスかモノリシックか。オープンソースを公開する理由①コミュニティへの感謝の印②他の人にデバッグを手伝ってもらい堅牢化③狭い領域で標準を確立し、他の人を入れて開発加速するため。20人以上の技術チームにはテクニカルライターが必要。本の終盤ではあるが、セキュリティに関しても多くの紙面が割かれている。読み終えて、こんなにも多くの領域に対して、一人の人間としてある程度の知識と考えと責任を持たないといけないのかと思うと、インポスター症候群にもなるわと思ってしまった。

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

　どのアルゴリズムも今や日常に溶け込んでいるものばかりでそれぞれの仕組みを知る機会はなかなかないので非常に学びの多い1冊であった。
また、それぞれの解説に分かりやすい例えとイラストがあり理解が進みやすかった。個人的に公開鍵暗号法のトリックはとても興味深く誰かに話したくなるような内容であった。

　これを読んだからといってすぐ使えるようなスキルやマインドは身に付くわけではない。
ただ、ITの仕組みを知ることでより深みが出るのは確かだ。
本書の最後にも「天文学の知識があるから夜空を見上げる体験に深みが増す」とあるように本書の本質はそこにあると思う。

　私も日々すぐに使えて効果の出るハウツーに手を出してしまいがちだが、(それらももちろん重要かもしれないが)もっと根底にある重要なものを本書で改めて気付かされた。
今後もたまに世界の仕組みについて理解することでより深みのある人間になりたいと思う。

The DevOps ハンドブック 理論・原則・実践のすべて

2017年発行だけど、既に少し古くなってきている。
アジャイルが前提なのか、関連をもっと書いて欲しいなぁ。
第1の道、フローの原則（可視化、WIP、バッチサイズ…）
第2の道、フィードバックの原則（行燈？）
第3の道、継続的な学習と実験の原則（レトロスペクティブ、ポストモーテム…）
をベースに全体を構成。
最後の部で、セキュリティや変更管理、コンプライアンスに触れている、これら重要そうだけど大きな企業しか関係ない？やるとなるとアジャイルやDevOpsのやり方的に大変そう。

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

前のプロジェクトフェニックスより良かった。
主人公のマキシンさんはオタクなんだね。
イミュータブルな関数言語（Closure）が好みとか濃いな…
けど関数型言語どれか勉強してみようかと思った
社員多いと良いなとも思った

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

ザ・ゴールみたいなストーリー仕立ての技術本？
面白かったけど、どう役に立てるのか分からない。
解説で触れていたように、もう一度３つの道を念頭に読み直さないといけないのか？
DevOpsをやるに至るまでに、ずいぶん長い前置きだなという印象。
ほとんど最後の方で、出てきて技術的な細かいところは触れてなかった。
心理的安全性とアジャイルで触れられるほどアジャイルに関係あるか？と思った…。

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

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

プログラマーでモブプログラミングの普及に尽力しているマーク・パール 氏の著書です。

モブプログラミングの入門書です。

【本書で学べること・考えること】
- モブプログラミングとは？
- モブプログラミングの利点
- モブプログラミングの始め方
- モブプログラミングの軌道修正
- モブプログラミングのための環境整備
- モブプログラミングの定着
- モブプログラミングの長期的展望

読んでみての感想です。

3人以上で行うモブプログラミングは興味がありましたが、やったことがなくどのように導入すれば良いかをしりたくて本書を読みました。
入門書らしく、平易な表現で、量も少なめで解説されていたので、読みやすかったです。ポイントもしっかり押さえられており、理解が進みました。
今度、職場でも実験的に行ってみたいと考えています。

Web APIテスト技法

テスト戦略をモデルとして示し、APIのテスト技法とどの領域をカバーするテストなのかをモデルと対応付けながら説明している点が良かった。
作っているプロダクトが満たす必要がある品質と、優先度を決めるためのリスクの把握が大事。

一部日本語訳が漏れていたり、誤字脱字や分かりにくい言い回しがある点が残念。

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

日常的に利用されている有用なアルゴリズムや簡単なコンピュータ科学について、誰でも理解できるように書かれた本。

全体的に読みやすく面白かったが、公開鍵暗号・デジタル署名の部分に関しては、サイモン・シンの説明の方が複雑である代わりにストーリー性が感じられたため、読み物として優れていると感じた。本業かそうでないかの違いだろうか。

本書内で扱っている、アルゴリズムやコンピュータ科学に関する話題は次の通りである。

1.検索エンジンのマッチング・ランキングに関するトリック。主なものを挙げると、メタワードトリック、ハイパーリンクトリック、オーソリティトリック、ランダムサーファートリック。

2.公開鍵暗号、デジタル署名に関するトリック。

3.誤り訂正符号、データ圧縮に関するトリック。反復トリック、冗長性トリック、チェックサムトリック、ピンポイントトリック、ロス無し圧縮、ロスあり圧縮など。

4.パターン認識に関するトリック。最近傍法、決定木、ニューラルネットワークなど。

5.データベースの一貫性に関するトリック。to-doリストトリック、「準備してからコミット」トリック、仮想テーブルトリックなど。

6.決定不能性について。クラッシュ検出プログラムの不可能性についてなど。

7.今後有望なアルゴリズムについての簡単な紹介。