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

Amazonアフィリンク

IT技術を活用できるように変革をするべきとうったえる本。ビジネスは顧客の利益となるよう常に変化していかなければならないと前置きした上で、IT技術が社会の変革をもたらすからこそ、IT技術を生かしたビジネスモデルやマインドや組織づくりをしていく必要がある、と主張している。

「ソフトウェア」と本書では言っているものの、あまりソフトウェア特有の視点が多くなく、どちらかというとネットワークやシステムづくりも含めたIT技術と主張したほうが本書の論調にあっているように思う。それらは、IT部門や現場だけでなく、管理層や役員も含めた全社員にかかわるような変革をもたらすからこそ、担当者任せにせず、各々がビジネスの進め方を常に見直していくべきで、またそのために、内製化や内製化とはいかなくても自社でIT基盤をコントロールできるような組織へと変化していかなければならない、という主張が特に強調したい点なのだと思う。

ただ、個人的にその主張がいまいち響かなかった。確かに言ってる内容はそのとおりだと思うし、それらをていねいに主張してはいるんだけど、個人的にはそれらが「当たり前のことを言っているだけ」に感じられた。私はかなり前から根っからのソフトウェア開発者(だと思っている人)なので、主張そのものはもう大昔から何度も聞いてきたことの繰り返しにしか思えなかった。

著者は、DEC・Microsoft・Googleという経歴とのことで、根っこのマインドとしては私に近いはずだと思う。そんな著者が、いわゆる日本の大企業を相手にコンサルしていった先に本書のような主張が出るということは、逆に、私や著者が当たり前と思っているそんなマインドが全然当たり前になっていないというのがまだまだ現在の実情なんだろうなというように思う。

というわけで、IT技術がビジネスモデルや組織をどう変えていかざるをえないように追いやっているのかの話を今一度ちゃんと学び直したい人向けの本。逆に、データサイエンティストやAI技術といった新しく盛り上がっているソフトウェア技術がもたらす新たなパラダイムシフト、みたいなのを期待する人はあまり読まなくてもいいかと思う。

P91「本来、自動車は移動のための手段です。」 走る歓び、みたいな主張をするメーカもあり、変革したくない・変革する必要がないという振り戻しが起こっていたりもしていて、象徴的な文章だなぁと思った。

P109「内製化するのは現実的ではないと思う方もいらっしゃるでしょう」 日本の大企業を相手にしたときにこういう主張が必要になるのだろうなと感じた。開発終わっても社員だと切れないとか、多重下請け問題とか、そういうことを言っている間にもはや自部門や自社でやりきるというマインドすら失われてしまった組織や会社も当たり前のように目にしてしまう今日このごろ。

P271「リモートワーク」 この本はコロナの前に書かれた本だからどちらかというと必要性については抑制的だけど、逆に今は著者はどう考えているのだろうかとも思った。人手人材不足も待ったなしになった今の日本だと、皆が平等に働くようなやり方ではなく、アメリカのように少数の猛烈に働く人を中心とした開発体制にでもしないと厳しいのだろうか。

Amazonアフィリンク

TCP輻輳制御アルゴリズムについての本。インターネットとTCPの位置づけを歴史踏まえながら概要説明し、TCPの輻輳とそれに対処するアルゴリズムを解説し、近年の輻輳対策のトレンドを紹介している。

ほぼタイトルしか見ずに買った私のせいではあるけど、本書はTCPの本ではなくてTCP輻輳の本だった。TCP輻輳制御アルゴリズムの話で2/3くらいを占める。さすがに私も細かいとこはもういいやとなってしまった。読んでて予感はしたけど著者はやっぱりNTT本社研系の人だった。

インターネットのようなノード間通信の延長にあるネットワークでは輻輳他のトラブルに対する制御が極めて難しい、という話はもはや説明するまでもない前提で話が始まるけど、一般人には「輻輳」という用語すら知られていないのが実際なので、このあたりはもっと丁寧に書くべきだったのではと思った。まぁこの本は一般人を相手にしていないから気にしてないというだけなのかもしれない。

本書を読んだ感想として、専門家でもない人が抑えておくべきポイントは、輻輳制御は難しい、Reno CUBIC そして新顔のBBR、広帯域高遅延や無線(ケータイ)をどうするかがトレンド、というあたりまでかなとは思っている。第7章は、成果アピールや予算獲得的な話にしか見えなかったのでスルーで。

というわけで、TCP輻輳制御アルゴリズムに入門したい人におすすめする本。逆に、そうでない人は正直読まなくていいんじゃ、とも思ってしまった。

P107「Linuxにおける輻輳制御アルゴリズムの実装」LinuxだけでなくWindowsやBSDについても触れてほしかった。私は理論上の話ではなくて現実世界の話のほうに興味があるので。

P177「既存アルゴリズムとの親和性」理論屋さんがハマりやすい話なのかなと思った。皆が新しいアルゴリズムに一気に乗り換えるのが理想だけど、現実はそうはいかない、進化論のような生存競争だと他者を押しのけるのが正解だけど、ネットワークだとそれがいいとは限らない。既存アルゴリズムのままの人もそれなりに通信できるように公平性を保つにはどうやればよいのか。

P201「パケットロスのおもな要因はバッファ溢れによるものです」近年は通信機器も高性能化したので、信頼性が上がっている反面、安易にバッファを増やして遅延増加を招いているだけでなく、溢れたときにバースト的にパケロスを起こしてしまう、という実情の話、あまり考えたこともなかったので参考になった。確率的に早めにロスさせたり帯域制御したりして基幹のノードでパケロスが頻発しないように対処したりしているのだろうか。

Amazonアフィリンク

Linux上でのPCM音の入出力の標準となっているALSAについての入門書。音をデジタルデータとして扱うための導入、ALSAの役割とその基本的なAPIについて、ALSAを使ったサンプルプログラミングの解説、という構成になっている。

プログラミングというタイトルになってはいるものの、音をハードウェアから出力する部分を扱うため、比較的低レイヤーなプログラムの話になるし、同時に音をどのような形でデジタル表現しているかについての知識を要する内容になっている。たしかに入門書的な説明の本とはいえ、このへんの分野のことを学ぶんだという心構えは最低限必要かと思う。

プログラミングという触れ込みの本ではあるが、サンプルコードを見る限り、著者はどうもコーディングに慣れていないように見受ける。分野が分野なだけに、信号処理やリアルタイム処理やDSPといったハードよりの分野から流れてきたのかなと推測される。サンプルプログラムは、処理のフローを理解するのにはよいが、細かなコーディングの手癖はマネしない方がよい。

ハイレゾやらUSB Audio Device Classやらの話が登場するが、ハイレゾは本書ではほとんど関係ないし(ビットレート計算くらい)、また現代ではalsaがUSB限定というわけでもないので、このへんは差し引いて読んだほうがよい。

入門書にケチを付けても仕方ないのだけど、実践的な内容にまでは触れられていない。いつでもどこからでもデータを拾い放題な音声ファイルをALSAのクロック任せで出力すれば良いケースは一番シンプルな例で、現実は、音声ってストリームなリアルタイムのデータなので、アンダーラン・オーバーランやレイテンシやASRC(asynchronous sample rate convert)なんかを気にしないといけないのだけど、さすがにそういう内容を求めるのは酷か？とはいえ、P79のNoteにあるniceで優先度をあげようの部分なんか、ごまかすにしてももう少し書きようがあるだろうにと思ってしまう。ここはSCHED_FIFOのキーワードくらいは記載すべき。

と酷評気味に書いてしまったが、ALSAをていねいに解説したものなんて、書籍でもネット上の記事でも皆無に近いので、そういう意味では非常に貴重な本となっている。逆に、ALSAなんて公式ドキュメント読めばいいだろ(当然英語)、というくらいの心構えがある人はやっぱりあえて読まなくても良いとなってしまうか。

Amazonアフィリンク

完結したはずの前作(みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」)のまさかの続編。前途多難で非常に苦労し全面刷新して構築したシステム「MINORI」が稼働したものの、その後も断続的にシステム障害を起こしているみずほ銀行のシステム障害の詳細を掘り下げようという趣旨の本。

立て続けに障害が起こったものの、それらをわかっている範囲で個別に原因を項目化するだけでなく、なぜそのような事象に至ってしまったのかについてもできるだけ掘り下げようとしている。他の例と比較しながら、銀行システムならではの事情や、海外での似たような障害の例も紹介しつつ、1つ1つは他のシステムでも起こっている問題でありつつ、みずほの場合はそれが波及的に連鎖して大規模システム障害に至ってしまっている点を指摘している。

これまでの本は、経営者層がシステム開発と運用を軽視しているという論調が多かったけど、今回の本はその色は弱めた内容だった。とはいえ、テストや運用にさく工数をケチってるんじゃないかの指摘はしており、特に小さなシステム障害が起こった場合の対処マニュアルや実施訓練がほかと比べて不十分というのを具体例を出して述べている。

なんというか、批判するのは簡単なんだけど、じゃどうすればよいのかを大規模開発を対象に語る難しさというのを感じる。規模の差はあれ、私自身も似たように多人数の関わる大規模プロジェクトが迷走する実例をよく見るだけに、この本から何を教訓にすべきかを意識して読まざるを得なかった。プロジェクトなんて成功するか失敗するかは水ものだから、どれだけ小さく早く開発を回せるようにするかがキーなのかなぁ。もしくは、ある程度見識を持った少人数の集団で集中的に開発しコア部分を作り上げてしまうべきなのかなぁ。OSS類をモジュールとしてたくさん利用するのが当たり前な昨今、いくらモジュール志向をもって開発したとしても特定プロジェクトでしか使われないのならば汎用性が低いものしかできあがらない、それを洗練させるには複数のプロジェクトの採用例を増やしてアダプトさせるしかないのかなぁ。などなど。

以下はこれまでと同様に読んでて気になった項目をずらずらと。

第3章p133「二重エラーが発生している旨を伝えた」「二重エラーの報告は受けていない」、障害発生時の情報共有を口頭でのみ行っているという決定的な例かな。エラーメッセージなんて1字1句間違わないようにコピペしてテキストで共有するのが当たり前ですね。

第3章p167「オールフラッシュのストレージ装置に移行していれば、ハードディスクの故障という前時代的なトラブルに遭遇しなかった可能性」、いやそれはさすがに主張がおかしいだろと。SSDも壊れる。HDDより壊れにくいなんてことはない。ただ、頻繁な読み書きをするストレージ部位をSSDにすれば圧倒的な性能でシステムのボトルネックを取り除けるのは確か。

第4章p178「自らの持ち場でやれることはやっていたといえる」、部分最適の極みは実は相当難しい。というのも、システムの開発や運用をやっている末端は、子会社や孫会社どころかそこの孫請けやひ孫請けで、彼らは仕事を受けた単位が自分の持ち場だけなので持ち場を離れて横断的に作業をする義理もないしお金ももらっていない、むしろ契約書に書かれた担当をおろそかにしたと責められる。かといって全体責任を持つ上位の人は指示を出す仕事だけでいっぱいいっぱいになりとても現場の実情をチェックすることもできない。組織の壁でさえよく批判を受ける話なのにそれが会社や契約をまたぐととてもじゃないけどそうはいかない。権限を持った人も現場に入っているような体制でないとこれはそう簡単には解決しない。

第5章p183、みずほのシステム開発の歴史表は参考になる、
第5章p185、銀行各社の統合とそれに連動したシステム統合も参考になる、
どちらも、20-30年といった人のキャリアすべてを費やすような単位で進行するので、人生をかけてシステム開発に携わる覚悟のある人を何人も囲い込まないと成功させるのは難しいよなぁと思う。

第6章p262「(セブン銀行は)東阪交互運用方式を導入する」、予備システムをホットスタンバイさせるのをさらに進めて、何もなくてもメインサブを定期的に入れ替えてシステム運用するの、ウワサには聞いたことあるけど本当にやってるのかなぁこれ。

Amazonアフィリンク

合併に伴うシステム統合がうまくいかず、二度の大規模障害を起こし、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章「大混乱の二〇〇二年四月」より、いい顔してるねこの写真、このあと地獄のようなシステム障害が発生するわけだけど。

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

Amazonアフィリンク

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

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

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

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

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

P64 SECTION-010 デバイスドライバの取り外し３より「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の最新版でなにか修正が入っていないか確認して、その修正と出くわしたバグとを照らし合わせる、みたいな作業が多いわけで、まぁなんというかものすごく実践的だなと感じられた。

Amazonアフィリンク

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

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

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

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

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

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

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

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

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

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