趣味・読書の最近のブログ記事

合併に伴うシステム統合がうまくいかず、二度の大規模障害を起こし、20万人月と揶揄された新システムへの一本化開発(本によれば最終的に35万人月らしい?)、というSI的システム開発の苦悩の象徴的なみずほ銀行の内情を描いた本。日経コンピュータが、みずほの中の人に怒られること承知で、内部の分析や推測や提言にまで踏み込んで意見している点が特徴となっている。

銀行にとって中央にある勘定系システムは心臓部であり装置産業であるから経営者層で適切にマネジメントしなければいけない、という点を強調している。お金の流れをシステムで一元管理しているからこそ、必要な業務を正しく定義し、それに寄り添うためのシステムを定義し開発し運用していかなければいけない、というある意味根っこのところを主張している。間違っても、合併に伴う各行の主導権争いやらリスクの先延ばしに注力して目を背けるようなことをしてはいけない、と記している。

過去のシステムトラブルのときにも本が出ていて(二度目の本一度目の本)、それを読んでいる人からするとあまり目新しい話は出てないと思う。期待に反して(?)、ようやくシステム一新できたのでこれから新サービスに注力していくよ、という宣伝なのか応援なのかな内容が付け加えられた点が新しいか。

もはや神話とも都市伝説ともなっているみずほ銀行の話だけど、ふつうの人にとって見れば「どことどことどこが合併したんだったっけ?」「三連休たびにATM止めやがって」程度なのかなと思う。IT革命とか言われたのもはや20年前、その当時とは比べ物にならないくらいIT技術ありきの社会となっている現在では、ふつうの人でもこの手のシステムの裏側の話は一般教養として知っておいたほうがいいのかもしれないと感じる。

ITだコンピュータだソフトウェア開発だといっても、こういうたくさんの人が関わる開発だとならではの苦悩がたくさん出てくる。そういう開発に苦悩したりする実例を知ることができるという意味では貴重な本。ただ過去の本を読んでいるならあえてこれを買う必要もないのかなと思う。

以下気になった点の列挙。

P61 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「三行で用語を統一するところから」 大きな会社やプロジェクトほどありがちで、用語や意味が違うからすれ違いが起こる。言葉が企業文化でもあるため、開発初期ほど言葉遣いには十分に注意したいと思った。

P64 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「開発のベンダが異なる」 先の用語と同じで、所変われば考え方や文化が変わるので、ここでも十分な意思疎通をとっておく必要性をよく感じる。

P73 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「ツールでしかプログラムを生成しない方針」 うーん、個人的にはこれはどうなのかな。一歩譲ってその方針を受け入れるとしても、ツールの仕様に口出ししたり場合によっては変更したりすることができないと個人的には辛いと感じそう。

P77 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「開発拠点の確保にも苦労した」 これは最近良く感じる事が多い。いくら音声通話やテレビ会議システムが充実してても、意思疎通の限界を感じることが多く、同じ場所に集まれるに越したことはない。

P83 第4章「緊張と重圧、一年がかりのシステム移行」より「重要な移行作業に三連休を充てた」 リアルタイムにATM休止のお知らせがアナウンスされるのを見ていたけど、障害だけは何が何でも避けようとコストをかける覚悟を持って作業しているのがよくわかった。

P153 第7章「検証、昆明の十日間」より「四億円の未回収が生じている」 銀行はこの手の締めに非常に厳しいというイメージを持ってるんだけど、それが出ること承知で、10万円まで引き出せる特別対応を行ったというあたり、トラブルのときの影響範囲がハンパないんだなと思わされる。

P168 第8章「重なった三十の不手際」より「システム装置産業とも言える金融機関」 結局ここなんよね、お金を扱う業界だったけど、今やコンピュータ上で数値を計算して決済するだけの業界になりつつあって、融資も銀行以外から行うことが増えた結果、銀行なのに紙幣や貨幣を扱いたくないというのが実情だったりと。「AIに置き換わる」とか象徴的に報じられるけど、そうじゃなく、銀行の役割が終わりつつあるのが実情よね。

P170 第8章「重なった三十の不手際」より「ハードウェアではないからだ」 未だにハードウェアとしてのコンピュータを提供してるベンダが全責任を追っているような開発をイメージしてしまう人っているのかな、と疑問に思いつつも、まぁ*年前はそれが当たり前だったわけだし、古い人向けにはこういう説明が必要なのかとも思った。

P183 第9章「一年をかけた再発防止策」より「情報伝達体制を見直し」 夜間バッチ処理って、タイムリミット...というかタイムラインが必要な作業なので、この手の決まりごとを決めておくのは必要不可欠だよねと思った。

P207 第10章「現場任せが諸悪の根源」より「四行統合」 形としては合併したのに中の組織が全然合併していない、てのはよくある話で、P212「割り勘にできないという理由で、三千九百万円に値切った」とかいう信じがたい話も信憑性が増してしまう。

P237 第12章「大混乱の二〇〇二年四月」より、いい顔してるねこの写真、このあと地獄のようなシステム障害が発生するわけだけど。

...縦書きの本って個人的には受け付けない体になりつつある...

Linuxカーネルの開発工程の流れ、品質の確保方法、具体的なバグからの修正例の紹介、の3本立ての内容の本。開発の現場に長年関わってきた立場からの解説となっている点が特徴となっている。

Linuxが切り開く輝かしい未来だとか、Linuxの内部設計をディープに解説するだとか、そういった方面の話はない。どちらかというと現場レベルのいち開発者の行っている作業を淡々と紹介するといったニュアンスが近いかもしれない。今やLinuxは、一部の天才が開発をリードするというよりも、大多数のふつうの開発者が業務のために開発したり解析したりメンテしたりするという側面が多いため、こういうスタンスの本のほうが実際のLinuxへの関わり方という意味で現実的でよくある例と言えるのかもしれない。

初心者からすると取っ掛かりにくいジャンルのLinuxの世界へ(バグを直すという)具体例を持ってわかりやすく紹介するという意味で良い本。逆に、Linux内部のコアな設計にはあえて踏み込んでいないので、そういうのを期待している人にとってはあえて読む必要はないかもしれない。

以下、個人的に気になった読書メモ。

P44 SECTION-006 ソフトウェアの品質より「メンバ名を変更して、意図的にコンパイルエラーを起こして」 変更漏れがないか確認するための方法の1つとして紹介されているこの方法、個人的にはよく使う。Makefileや依存関係・コンパイルスイッチが入り組んでいると、正直実際にコンパイルする手順じゃないと何もかもが信じられなくなっちゃうんだよねぇ。

P64 SECTION-010 デバイスドライバの取り外し3より「Coccinelle」 静的解析ツールの紹介だけど、この手のはあまり詳しくないので、助かる。

P76 SECTION-012 割り込みハンドラの登録直後より「IRQというのはIntel用語」 え?そうだったの?一般用語だと思って今まで「割り込み」とほぼ同義で使ってた。Wikipedia類だとっても「Intel用語だ」という明示が見当たらないので真偽の程がよくわからない。

P77 SECTION-012 割り込みハンドラの登録後より「スプリアス割り込み(Spurious interrupt)」 このエラーが出たとき意味がよくわからずに泣いた経験を思い出した。英語を訳してもよくわかんないんだもん。まぁ結局エラーを出してるコード周辺を読んで「よからぬ割り込みが上がりっぱなしの場合かな?」とたどれたから事なきを得たけど。

P101 SECTION-014 32bitと64bitの違いより「Documentation/core-api/printk-formats.rst」 いつも雰囲気でprintkの%のフォーマットを読み取るけどやっぱドキュメントちゃんと読まねば・・・Linuxの内部設計の意図なんかはDocumentation/以下のをちゃんと読むのがなんだかんだで近道なことが多いよね。

P102 SECTION-014 32bitと64bitの違いより「SipHash...セキュリティに強いハッシュ」 初耳だった。ハッシュというと、SHA-256のような暗号用途のと、CRC32のような化け対策の用途のと、くらいしか意識したことなかったもので。。

P166 SECTION-025 スクリプトのshebang行の解釈より、shebangの127文字制約の仕様の議論はちょっと参考になった。LinuxはLinus本人の強い意向で、ユーザランドの互換性を壊す変更は何が何でも悪だという方針になっているので、それが垣間見れる一例になっている。

最後に、この本は3分の2くらいが具体的なバグと修正の例に費やしているわけだけど、実際のところ、見慣れない変なバグに出くわしてしまったら、バグ出たドライバのLinuxのupstreamの最新版でなにか修正が入っていないか確認して、その修正と出くわしたバグとを照らし合わせる、みたいな作業が多いわけで、まぁなんというかものすごく実践的だなと感じられた。

「The DevOpsハンドブック」読んだ

DevOps的な考え方・業務の回し方を、DevOpsがもてはやされる前から実践してきた人たちが、今一度立ち戻りDevOpsとは何なのかを、これから実践する人向けに解説した本。具体的な会社での導入事例を豊富に取り入れて解説に付け加えているのが特徴になっている。

手放しに喜べるような万能の手法ではない、と前置きをしながらも、どうしてもこのアメリカ的な文章のせいで、手放しに喜ぶようなノリの文章になってしまっているのが少し気がかりだった。そもそもこの本の解説から理解するなら、DevOpsって手法のことじゃなくて、単に業務の回し方に対する考え方でしかないように思えてしまう。そう、技術の話じゃなくて、業務プロセスの話。

変更を反映させるまでのデプロイのチェーンに問題があった場合はその解決にみなで協力して当たる、というのが正しい方法だという記載がある。ただ実際には、現場は作業の細分化が進んでいて各々は自分の担当の業務に手いっぱい、直接は担当じゃないとこの問題にまで手を伸ばせる余裕のある人は少なく、結局いつも臨機応変に手を伸ばせる器用で全体もよく見えている人ばかりが対処する。そういう役回りの人が消耗していき、特に上から評価もされない場合は成果とみなされず給与にも反映されず、そして去っていく、というような姿になってしまうというのが欧米では多くなるんじゃないかと思う。

本を読んでいて気に止まった点をいくつか

11.3 まとめより、「燃え尽き症候群になる率は低いのだ。」アメリカでも燃え尽き症候群みたいな話はあるのね。まぁあっちだと離職して少し休みその後転職というのはよくある話なのに対し、日本だと一度ドロップしてしまうとなかなか戻れないという違いはありそう。

17.2 機能テストにはA/Bテストを組み込むより、「価値を産まない機能を機能を1つ作るよりも、チーム全体に休暇を与えたほうが会社や顧客のためになる」、お、おう。そこまで割り切れる会社は日本にはほとんどないだろうなぁ。

19.6 回復力と学習を生み出すために本番環境にエラーを注入するより、Netflixが意図的に本番環境に擬似的な障害を起こして訓練にする話は今は結構有名になったのかな。Chaos Monkeyでググるとたしかに結構ヒットする。本番環境に手を加えるなんて、日本の大企業じゃ絶対にやらないよねぇ。

20.1 チャットルームとチャットボットで組織的な知識を自動的にキャッチするより。チャットルームにオペレーション状況をリアルタイムに全員に流す話と特定の人にだけ情報を届ける電子メールとの対比がある。チーム規模にもよるけど、情報をあえて一部の人にのみ開示してコントロールするのがマネジメントだと信じる人も少なくないので、やっぱこういう話は大企業ほど抵抗があるだろうなぁ。

個人的な意見かもしれないけど、やっぱDevOpsって技術の話じゃないと思う。コードを変更してからそれを反映した本番環境を作るとこまでを自動化・効率化・高速化する、なんて話は当たり前にしか感じない。組み込みの世界だと、ビルド用PCのセットアップ・各種ツールのインストール・ソースコードのチェックアウト・ワンストップなビルドシステム・ターゲットイメージの生成・ターゲット実機への確実なイメージの書き込み・標準化された自動テスト、あたりはソフトウェ開発者ならワンストップでとまでは言わないまでも手順化・自動化しているのは当たり前だと思う。

と、DevOpsそのものに否定的な意見の内容になってしまったけど、DevOpsを知るという意味では丁寧にかつ全体を追って書かれた本なので安心して読める。

OSをまだあまり身近に感じられていないプログラマを対象に、Linuxがなんのためにどんなことをやっているのかを、実際にプログラムを動かしながら理解しようという趣旨の本。あまり難しい話には持っていかずにわかりやすくかつ実践的に迫っている点が特徴になっている。

大学のOSを対象にした講義などではどうしても「OSを作る人の論理」で解説がなされてしまうことが多いが、本書は、OSを使う側の視点に立とうとしているところがよいと思う。世の中、OSなんて小難しくてとっつきにくくブラックボックスとしてしか扱えないプログラマが多いので、そういう人のためのOS入門書としてはよく書かれている。

ただ敢えて厳しく書くと、著者はHPCが専門ということもあり、4章(プロセススケジューラ)や5章(メモリ管理)は非常にわかりやすく書かれているものの、7章(ファイルシステム)や8章(ストレージデバイス)は中途半端に感じられる。特にファイルシステムは、あまり実験的な例が出ていなくて、性能面よりも機能面を強調していて、また他の章に比べて具体的なファイルシステム名が前面に出すぎている。前半が非常に良いだけに、もう7章や8章は取っ払っても良かったんじゃないかとすら思える。

最近はLinux Kernelについての本は壊滅的だったりするので、そんな中で、本書は特に前半が非常によく書かれていて、OSの初心者にはオススメ。反面、それなりにOS開発に触れている人にとっては手応えがないのであえて買う必要はないのかなと思う。

下記はただの個人的な本書に関するメモです。
- $ swapon --show
- /sys/kernel/mm/transparent_hugepage/enabled
- /sys/devices/system/cpu/cpu0/cache/index0
- /proc/sys/vm/dirty_writeback_centisecs
- /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

経営層やプロジェクトマネジャーの立場の人をターゲットに、システム開発の失敗事例やプロジェクトの回し方について語った本。開発プロジェウトの中でプログラマが具体的にどういう仕事をしているのかについても触れている。

先に書いてしまうと、私からするとこの本はタイトル詐欺でした。プログラマという業種の人柄に触れて書かれた箇所も確かにあるものの、結局のところこの本はシステム開発におけるプロジェクトマネジメントの本です。タイトルだけ読むとこう、日常生活やら友人としての接し方やらにフォーカスしてるかのようにも見えますが、そうではなくて、よくあるプロジェクトマネジメントの話です。

その上で、プロジェクト開発の点から考えても、他の本と比べて特筆して語られていることがあるわけでもなく、敢えてこの本を選ぶ必要もないのかなぁ。たしかに8章や9章あたりにプログラマ特有の気質に迫ろうとする部分もあるけど、正直あまり掘り下げて洞察しているわけでもない。英語から日本語に訳した場合に見られる独特の言い回しも多く、読みやすいわけでもない。その中でコンピュータ学の触りを中途半端に解説してる箇所もあったりと、どうもチグハグな感が拭えない。

というわけで、私からするとこの本の良いところをあまり見いだせないという辛口評価です。プロジェクトマネジメントの話を求めるにしても、別の本を買ったほうがいいかと思います。

リファクタリングのあり方を2000年頃に包括的に語った本の実質の改定書。リファクタリングとは何かから始まり、その具体的な取り組み方や典型的なリファクタリングのパターンなどについて広く語っている。

うーん、他の人にとってはどうなのかわからないけど、少なくとも個人的にはこの本のスタイルは嫌いだなぁ。なんというか、綿密なルールを隅々まで作り上げた上で、これはこう・それはそう、とマニュアル的にリファクタリングを適用していく的な。もちろんそう画一的にはいかないところもあるんだけど、それに対しても、論理的にというか文章力で読破しているような。そうまさに「委員長」のような。そのスタイルのせいでどうも個人的に「納得いかない」感じで読み進めている気がした。

Smalltalkを持ち上げつつJava(の1.1)をベースにコードの例を出しているあたりも、新装でもあえてそのままにしたという意図はわかるんだけど、ちょっととっつきにくくしてしまっている点である気がする。Java2レベルの古い知識で止まってしまっている私ですら「ちょっと」と思ってしまう。

あと本書ではオブジェクト指向を全面的にアピールしていて、GoFのデザインパターンの話もちょこちょこ出てくる。GoFの知識なしでも読める程度ではあるものの、著者の意図をきちんと汲み取ろうと思うならばデザインパターンの知識も必要になるとは思う。ただ近年は、あまりオブジェクト指向という感じでもないんだよなぁ。未だにC++やJavaでやってるのならば、そうでもないのかもしれないけど。

コードの「不吉な臭い」を項目化して並べているところ(末尾開きページに一覧がある)あたりは、いざリファクタリング作業をするという場面でターゲットを探す時の作業の目安になってよいかと思う。

と、新装版とはいえ古臭さが否めないので、あえて今更買って読む必要はないかなぁという感じだった。今ならもっと簡潔にリファクタリングかくあるべきと述べた本もたくさんあるしね。

LSIとしてのGPUを中心にしつつもそれを取り巻く幅広い技術について解説した本。コンピュータグラフィックスの歴史から最先端のGPUの応用まで広く紹介している。著者のHisa Ando氏のシリコンバレーでの実経験を背景とした詳細な内容も特徴となっている。

スプライトからポリゴンへの話やら物理計算的なプログラミングの話やらは想定していたけど、CRTからディスプレイコントローラの話やら、最先端の半導体製造プロセスの話やらまで絡めてくるとは思っていなかった。幅広く同時に深く技術の紹介を入れていくあたりは、さすが安定のHisa Ando氏という気がした。ここまで書ける人はなかなかいない、ライターとしては後藤氏を超えてると思う。

この手の本の想定する読者的には仕方なかったんだろうけど、もう少しパソコン以外のジャンルも充実させてほしかったか。組み込みやスマホの事情やら、最新のディスプレイアダプタ(HDMI,DisplayPortやら非同期フレームレートやら)の事情やらも解説があっても良かったかもしれない。デコーダやらエンコーダやらもかなぁ。CRTのアナログ伝送から話を始めてるんだし。ただ、そうしてしまうと本題の3DグラフィックスやGPGPUからは外れてしまう、というのもわからなくもない。

ただ、ちょっとNVIDIAを持ち上げすぎなところは気にはなった。まぁ確かに業界は今はCUDA一色に近いんだけど、NVIDIA以外が頑張ってるVulkanとかはもうちょっと登場しても良かった気はする。確かにNVIDIAが強いんだけど、もう少し長い目で見たら業界図が大きく変わってる可能性はあるんだし、標準化の話を存在感もって取り入れても良かったんじゃないかと思う。

と、批判的に書いてしまったけど、広く深く技術を解説した良本なのは間違いない。GPUのジャンルを詳しく知りたい人はぜひ読んでほしい。反面、最低限の知識がないと理解するのが難しい項目も多いので、初心者がいきなり読むのは注意が必要かもしれない。

このアーカイブについて

このページには、過去に書かれたブログ記事のうち趣味・読書カテゴリに属しているものが含まれています。

前のカテゴリは趣味・鉄道です。

次のカテゴリは日常です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

Powered by Movable Type 7.5.0