勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

「Beyond Legacy Code(レガシーコードからの脱却)」の前半を読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第7回。今回は今年訳書も発売されて有用だと評判の「レガシーコードからの脱却」が題材である。大著なので2回に分けて読むことにしている。というわけで今回は2週間で7章まで読んだ。

デッドライン読書会のルールは、以下参照


なお、訳書が発売されてはいるのだが、本ブログでは原著「Beyond Legacy Code」のほうを読んでいる。https://learning.oreilly.com/ に加入しているので原著であれば購入せずに読めるからである。まぁ本書は実際かなり有用なので将来的にはチーム用に別途書籍購入してもいいかなぁと思っている。

「Beyond Legacy Code(レガシーコードからの脱却)」前半(7章まで)の感想

最初の3章は「レガシーコード」そして「ソフトウェア開発業界」に関する論考が中心である。まぁ真新しい話はほとんど出ていないのだけれども、うまく論点が整理されている印象がある。「名前だけアジャイル」問題はちょっと面白かった。

そして4章からは、本書の副題でもある「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」の説明である。基本的にはアジャイルラクティスの中で特に重視すべきものを精選して解説するスタイルと理解している。という意味ではやはり、真新しさは無いが、よくまとまっているというのが感想である。

というより、本書はおそらくこの手の技術書をあまり読まないような読者に向けてかかれたテキストである(という印象を、読めば読むほど強く感じるようになった)。「まずは本書を最後まで読め。話はそれからだ」と言われるような本を目指しているのではないだろうか。DDDやアンクル・ボブの本は決して読まないような人向けというイメージ。だとすれば、非常に良い本のように感じる(それでも、この手の技術書を読み慣れていないエンジニアが読み切るのは骨だと思うけど)。

「ソフトウェア・ファースト」をSIerのおじさんが読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第6回。今回は先日発売されたばかりの「ソフトウェア・ファースト」が題材である。

ソフトウェア・ファースト

ソフトウェア・ファースト

デッドライン読書会のルールは、以下参照

人でも技術でも品質でもなく、ソフトウェア・ファースト

ソフトウェア・ファーストという言葉は著者の造語だ。

ソフトウェア開発の手法が活かせる領域は多いものの、ソフトウェアだけでは解決できないものも見えてきました。そのような中、事業やプロダクト開発を成功させるには、ソフトウェアの流儀を知り、ソフトウェアの可能性も知りつつも、現状のソフトウェアが抱える限界も理解して開発に臨む姿勢が必要なのです。
ソフトウェア・ファースト

要はソフトウェアの流儀、思想、姿勢などを理解した上でビジネスに立ち向かう必要があるという話である。

しかし、今まではソフトウェア以外の〇〇がファーストにいた、のではなかったのか。それは例えば「人」であったり、「技術」であったり「品質」などであった。それらと、「ソフトウェア」は何かが違うのだろうか? という点についても触れられていて興味深い。

ほどよい説教本

わたしはSIer勤務のおじさんだが、その立場から見ると本書はバッサリとした物言いがむしろ小気味良く、大変に理解しやすいものになっている。なまじ、様々な業界や業種に忖度して抽象度を上げた書き方だとかえって読み解くのが面倒なのである。と思ったら、巻末にこれはわざとやっていることだというコメントもあった。

類書にない形で実践的にしようと思うあまり、つい刺激的な表現を用いたり、現状維持に対してチャレンジするような内容になった箇所もあったかと思います。それも、当たり障りのない内容や表現で、皆様の日常の読書体験で終わるのではなく、今日からの行動変容につながるきっかけになればと思ってのことでした。
ソフトウェア・ファースト

ちなみにSIerについては「2章:IT・ネットの“20年戦争”に負けた日本の課題と光明」でいろいろと深掘りされているのが興味深い。詳細はぜひ購入して見ていただきたいが、著者の及川さんがまさに目にしてきたIT業界の歴史を踏まえた分析は迫力があると思う。
ただ、及川さんのSIer今後の予測は刺激的だけれども、実際にはその通りには進まないというのがわたしの予想ではある。

これからの「強い開発組織」を考えるために/ソフトウェア・ファーストなキャリアを築くには

さて、繰り返しになるのだけれどもわたしはSIer勤務のおっさんである。翻って本書は基本的にはいわゆるユーザー企業向けの内容である。ではなんで手に取ったのかというと、「4章:これからの「強い開発組織」を考える」「5章:ソフトウェア・ファーストなキャリアを築くには」が読みたかったからだ。
実はエンジニアの立場で納得のいく、国産の組織論というのは中々に見当たらないものである。
(実は先立って「エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング」も読んだのだけれども、ちょっと抽象度が高すぎる。「エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド」も良い本だけれども海外事例ということで、そのまま適用するのはけっこう難しそう)

日本の場合、向き・不向きを問わず社歴や年齢を重ねただけの人がマネジャーに昇進し、若いメンバーが実務を担うという構図で組織づくりが行われるケースが多いように感じます。これではマネジメントがアマチュアなまま組織運営が行われ、機能不全に陥ってしまいます。
ソフトウェア・ファースト

ハイ。スイマセン。

マネジメントやそれに近い職位の社員は、現場発信の議論を受けつつ(引き出しつつ)、解決に向けたタスクを提案し、リードしていくことになります。中には技術選定やアーキテクチャについての議論も含まれるでしょう。つまり、エンジニアリング組織のマネジャーは組織を束ねてメンバーの成長を支援するだけでなく、技術面の判断も求められるのです。
ソフトウェア・ファースト

ハイ。存じております。

10 数年前に経験した実装の知識のまま、新しい手法を勉強もせずに過ごしていたら、現代的なエンジニアリング組織をマネジメントすることはできません。
ソフトウェア・ファースト

ハイ(土下座)。
・・・という感じでハッキリ書かれていて、大変にわかりやすい(笑)

どちらにしろ本書は非常にオススメ。ソフトウェア開発に関わらない一般企業の方だけでなく、ITエンジニアや、SIerの立場でも学ぶことの多い本である。

情報システムの障害状況ウォッチ(2019年前半)

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。
Graves 1

元ネタはこちら。みんな見たほうが良いよ!

2019年前半(1~6月)の傾向

  • 2018年と同等ペースで、月5.5件の障害が世間では起きていたようだ。ちなみに2017年以前は月4件ペース以下だったので、2018年以降高止まりしているとも言えるかもしれない。

主要なトラブルなど

というわけで、いまさらだけれど2019年前半のトラブルのおさらい。こんなことありましたね。

宅ファイル便 情報漏洩

電子マネー決済サービス「シンカクラウド」障害

改元対応トラブル

IPAの報告に記載された改元関係のトラブルは17件。うち1件のみが民間企業(金融機関)のものであり、他の多くのトラブルは自治体関連で発生していたようだ。

なお、改元対応トラブルについては下記のブログ記事が非常にわかりやすい。

では、次回は半年後あたりに。

運用設計の教科書 ?現場で困らないITサービスマネジメントの実践ノウハウ

運用設計の教科書 ?現場で困らないITサービスマネジメントの実践ノウハウ

Release It! 2nd Editionを読んでいる(Part.2)

近著の技術書では名著と名高い(個人的な観測範囲)Release It! 2nd Editionであるが、残念ながら翻訳はされていない。Google翻訳を活用しながら、えっちらおっちら原著を読むブログ記事のPart.2。今回は6章〜11章を読んでいる(全部で17章ある)。

前回記事はこちら。

6章〜11章は「Part II. Design for Production」つまり本番運用のための設計に関する指針といった内容。6章がケーススタディで、これを踏まえて7章以降で設計要素について語られている。

6. Case Study: Phenomenal Cosmic Powers, Itty-Bitty Living Space

というわけで、またもや空恐ろしいケーススタディである。このケーススタディでは主人公の休暇中に破滅的なシナリオが時系列で進行するというもので、読んでいて心臓が止まるか毛が生える勢い。ECサイトブラックフライデーに原因不明でダウンする事例である。

障害は避けられるものではないため、障害を前提とした設計をする必要があるという話で紹介されている「ROCプロジェクト」が興味深い。

Recovery-Oriented Computing(ROC)プロジェクトは、バークレースタンフォードの共同研究プロジェクトでした。プロジェクトの設立原則は次のとおりです。

  • ハードウェアとソフトウェアの両方で、障害は避けられません。
  • モデリングと分析が十分に完了することはありません。すべての故障モードの事前予測は不可能です。
  • 人間の行動は、システム障害の主要な原因です。

彼らの研究は、システムの信頼性に関するこれまでの研究の多くに反しています。ほとんどの作業は障害の原因の除去に焦点を当てていますが、ROCは障害が必然的に発生することを受け入れています。これはこの本の主要なテーマです。彼らの調査の目的は、障害が発生した場合の生存性を改善することです。 ROCの概念は、2005年の時代を先取りしました。今では、マイクロサービス、コンテナー、および弾性スケーリングの世界では自然に見えます。

7章以降

(私の知る限り)本書独自の観点スタックで本番環境向けの構成設計に関して議論されている。
f:id:kent4989:20191022143449p:plain

  • Foundation
  • Instances
  • Interconnect
  • Control Plane
    • コントロールプレーンって日本語だとどうなるんですかね。運用制御と監視など。コントロールプレーンが高度になるほど、実装と運用にかかるコストが増加する。バランスを取る必要がある。また、新しいオープンソースの運用ツールが次々と登場しており、慎重に選択しなければならないとか。
  • Operations
    • システムの運用そのものについて。なお本書ではSecurityのみをトピックとして扱っているようだ。

次は「Part III. Deliver Your System」(12章〜15章)。これはさくっと読めそう。

なお本書には興味があるけど、ハードルが高いと感じられている人はアーキ部のオンライン読書会に参加すると良いだろう。

気になる洋書技術書をとりあえず斜め読み 2019/9

読んでみたい本が多すぎる。が、よく考えてみたら米oreillyのサービスに加入しているので何冊読んでも追加でお金はかからない(定額読み放題)。というわけで、目ぼしい未読の洋書技術書について、まず冒頭だけざっと読んでみた。
今回目をつけているのは以下。

  1. More Fearless Change: Strategies for Making Your Ideas Happen
  2. The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done
  3. Clean Agile: Back to Basics (Robert C. Martin Series)
  4. The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)
  5. Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

More Fearless Change: Strategies for Making Your Ideas Happen

More Fearless Change: Strategies for Making Your Ideas Happen (English Edition)

More Fearless Change: Strategies for Making Your Ideas Happen (English Edition)

訳書が出ている前作「Fearless Change」が非常に良かったので興味を持ったもの。
以下のページでは増補改訂版と紹介されていたのだけれども、SNSでつぶやいたら翻訳者の川口さんから「別本の扱いです」とのコメントが。

今回の特別ワークショップでは、今月末に出版される『More Fearless Change』のパターンを用いたワークショップを行います。この本は、とても有名な『Fearless Change』の改訂増補版です。

というわけで、ざっくり目次比較もしてみたのだけれども、確かに別本のようだ。ストーリーというか、パターンの使い方の解説部分は減って、追加のパターン+既存のパターンに関する説明が主となっている。

冒頭を斜め読みしてみたけれども、前作出版後の10年の議論などから発見されたパターンについて書かれているっぽい。
ただ、この本はGoogle翻訳だと非常に読み難い(おそらく相性の問題)ので、これ以上読み込むのは見送り。組織変革などの悩みに直面したら、トライしてみるかもしれない。

個人的な期待度:★(悩んだ時に手にとるかも)

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done

この記事を書いた人が書いた本。

この本の中心テーマは、企業が組織や組織化の方法を根本的に改革し、新しい管理パラダイムを取り入れなければならないというものです。

新しい管理パラダイムは、目的地ではなく旅です。それは、技術革新を決して終わることのない関係の両方の組織が顧客のために生成し、特定の技術革新の面でと経営そのものの実施に着実に改善。企業は、「私たちは今アジャイル」であるため、リラックスできる安定した状態に「到達」することはありません。新しいパラダイムを採用するには、継続的なコミットメントと経営陣のリーダーシップが必要です。

この本は、それぞれの旅のさまざまな段階にある企業のスナップショットを提供します。それらが現在の場所に到達したことは、将来の成功を保証するものではありません。これらの企業は、新しい目標、原則、価値観を受け入れ、継続的なイノベーションで顧客を喜ばせ続けた場合にのみ繁栄し続けます。

というわけで、本書は経営パラダイムとしてアジャイルを取り組む方法に関する話のようだ。目次を見ていると様々な企業の事例分析も含まれている模様。技術書というよりビジネス書だけど、けっこう面白そう。

個人的な期待度:★★★(ぜひ通読したい!)

Clean Agile: Back to Basics (Robert C. Martin Series)

Clean Agile: Back to Basics (Robert C. Martin Series)

Clean Agile: Back to Basics (Robert C. Martin Series)

最近読んだ「Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)」の著者の続刊。

この本は研究成果ではありません。私は熱心な文献レビューを行っていません。あなたが読んでいるのは、アジャイルとの20年にわたる関わりについての私の個人的な記憶、観察、意見です。これ以上でもそれ以下でもありません。

この本は、プログラマーと非プログラマーを対象としています。技術的ではありません。コードはありません。プログラミング、テスト、および管理の深い技術的な詳細に触れることなく、アジャイルソフトウェア開発の本来の意図の概要を提供することを目的としています。

技術エッセイ好きとしては、かなり興味をそそられる内容である。

私はこの序文を2019年の最初の日に書いています。そのリブートからほぼ20年が経ちました。どうして?なぜなら、アジャイルのシンプルで小さなメッセージは、この数年間で混乱してきたからです。リーン、カンバン、LeSS、SAFe、モダン、スキルド、その他多くの概念が混在しています。これらの他のアイデアは悪くありませんが、元のアジャイルメッセージではありません。

ここでいうリブートとは、90年代のソフトウェア開発の混乱の後の業界の再起動とアジャイルソフトウェア開発宣言のことである。そして、もしかすると大規模アジャイルに関する警鐘も書かれているような気がする。非常に気になる。

個人的な期待度:★★★(ぜひ通読したい!)

The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)

The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)

The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)

名著の誉れが高い「新装版 達人プログラマー 職人から名匠への道」の二版。昔読んだけど記憶の彼方なので、ちゃんと読み直したい。

  • 20年前、新しいクライアントとの議論を短縮するために書いたメモを発展させることにより「達人プログラマ」は生まれた
  • 20年が経過して、多くのソフトウェアは寿命が来て世代交代した。しかし、ソフトウェア開発の常識、実践とアプローチは変化していない
  • 20周年版を出すにあたって、テクノロジー面の更新に加えて、20年の経験を踏まえた見直しを行った

その結果、この本はテセウスの船のようなものです。本のトピックのおよそ3分の1は真新しいものです。残りの大部分は、部分的または全体的に書き換えられています。私たちの意図は、物事をより明確にし、より関連性のあるものにし、できれば時代を超越したものにすることでした。

うーん、つまり全部読み直さないといけないということか。
興味深いけれども、自分の興味としては後回しかなぁ。若手エンジニアの皆さん、もしくは未読の方は読んだほうがよさそうだけれども。

個人的な期待度:★(きっと良い本だけれども、読み直す時間が無いので後回し)

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

訳書も出た。
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

が、とりあえず定額読み放題の原著で内容をチェック。

ソフトウェア開発者と協力するマネージャーのために、この本は、9つの重要なプラクティスに投資することで、チームがより効率的に作業してレガシーコードに陥らないソフトウェアを提供する方法を示します。そして、それを行うには、単なる技術的なTo Doリスト以上のものが必要です。その理由を方法に追加する原則をしっかりと理解する必要があります。

というわけで、後半は具体的なプラクティスの説明になっている。9つのプラクティスは以下の通り。

  • ラクティス1 やり方より先に目的、理由、誰のためかを伝える
  • ラクティス2 小さなバッチで作る
  • ラクティス3 継続的に統合する
  • ラクティス4 協力しあう
  • ラクティス5 「CLEAN」コードを作る
  • ラクティス6 まずテストを書く
  • ラクティス7 テストでふるまいを明示する
  • ラクティス8 設計は最後に行う
  • ラクティス9 レガシーコードをリファクタリングする

一方で注目したいのは前半の総論的なレガシーコード論である。これは面白そうなのだけれども、原著で読むのは骨が折れるので訳書を買うべきな印象。SNSのタイムラインをみていても賞賛の声がよく見えるし、有用度が高そうなので訳書を買ってしまおうかなぁ。Kindleでセールになっていたら間違いなく購入するのだけれども、日本オライリーだとセールになることは無いのが残念。

個人的な期待度:★★★(有用度高そう。訳書購入を検討!)

ところで、前回チェックした本とその後の状況

前回も何冊かチェックしているのだけれども、

現在はその中から1冊「Release It!: Design and Deploy Production-Ready Software (English Edition)」について、少しずつ読み進めている状況。途中経過は以前に書いた。Part.2は現在下書き中。

現在オンラインで本書を扱った読書会が進行中なので、参加しはじめている(#3のみだけど)。遅い時間スタートかつ自宅から参加できるので(社畜派でも)お勧め。

時間が足りないのだよ。そして月末からはDQ11(Switch版)に着手する予定なので重ねてマズイ状況。

Google Colaboratory で AtCorder生活

以前にScratchでAtCorderする方法を記事に書いた。

その後AtCorderの過去問をScratchで解きまくってみたのだけれども、実行時間制限が厳しい問題をクリアできなくなってきた。Scratchでは例えばソート関数などが提供されていないのでアルゴリズムを手組みせざるをえないのだけれども、高速なアルゴリズムを組むのはしんどい。
というわけでPythonに浮気した。しかし、ローカル開発環境を構築するのは面倒だ。そこで、まるっと使いやすいサービスを探していたところ、Google Colaboratoryがよかったというのが本記事の内容。

Google Colaboratoryとは

このあたりからどうぞ。GoogleがホストしているJupyterですね。

類似のオンライン実行環境としては、国内では某転職斡旋業者のサービスもあるようだが、私はなんとなく避けている。なんとなく。

Google ColaboratoryでAtCorder

基本的にはGoogle Colab上でコーディングとテストを実施して、完成したらAtCorderのフォームから提出するという流れ。
特に工夫をしないでも

  1. Google Colab上で、テストデータをインプットとするコードを書く
  2. サンプルデータで正解になるか確認する
  3. 問題が無さそうであれば、AtCorderに提出する用のI/Oを追加する
  4. 提出する

という流れでAtCorderに参加できるが、最後のI/Oの追加あたりが面倒だ。

そこで、以下のようなテンプレートコードを考えた。これであればColab上で開発完了したら、そのままAtCorderへも提出できる。

def main():
  if 'get_ipython' not in globals():  
    # 以下のコードはAtCorder提出時のみに実行される。問題の種類に応じてinputメソッドを準備する
    N = int(input())
    # AtCorderでよくある入力形式
    # A, B, C = input().split()
    # b = [int(i) for i in input().split()]  横持ち
    # S = [input() for _ in range(N)]  縦持ち/行数N
    # t = [0] * N    ti xi yi 縦持ち/行数N
    # x = [0] * N
    # y = [0] * N
    # for i in range(N):
    #   t[i], x[i], y[i] = map(int, input().split())
  else:
 # 以下のコードはColab上でのみ実行される。テスト用の入力データを書いておく
    N = 1

  # 以下にコード本体を書く
  print(N)

main()

例えば、AtCorderサンプル問題「practice_1」の回答は以下になる。

def main():
  if 'get_ipython' not in globals():  
    #以下のコードはAtCorder提出時のみに実行される。問題の種類に応じてinputメソッドを準備する
    a = int(input())
    b,c = map(int,input().split())
    s = input()
  else:
    #以下のコードはColab上でのみ実行される。テスト用の入力データを書いておく
    a,b,c = 1,2,3
    s = "test"
 
  # 以下にコード本体を書く
  print("{} {}".format(a+b+c, s))
  
main()

2012年のKnight Capitalのシステムトラブルについて調べた

名前だけは知っていた有名なソフトウェアトラブルの事例。「巨大システム 失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法」という本で詳しく語られていたのを見て興味が沸いて、いろいろ調べてみた。今は調べたことを、少し後悔している。

巨大システム 失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法

巨大システム 失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法

トラブルの概要

  • 2012年8月1日ニューヨークの証券会社であるKnight Capitalにおいて、コンピュータを使った自動売買トレーディングソフトウェアのインストールに絡む問題により「大量の誤注文」が発生。
  • 損失額は4億4000万ドル

何が起こったのか

  • 既存システムにはもともと「パワーペグ」と呼ばれる試験的な取引機能があった。この機能は結局本番稼動しなかったが、コードは削除されなかった。いわゆるデッドコード。
  • パワーペグ機能の廃止に伴い、取引モニタリング機能も廃止された(これによりトラブル後の原因調査が難しくなったようだ)。
  • 取引所で新たな制度「個人投資家流動性プログラム(RLP)」が開始されることとなり、システムに対応機能を追加したが、その際の処理フラグは「パワーペグ」で過去に利用していたものと同一で設計された(合掌)

これらの一見無害な一つひとつのステップ――RLPの導入、パワーペグ機能の保持、パワーペグ取引の追跡不能、パワーペグフラグの再利用――が、金融メルトダウンのお膳立てをした。RLPプログラム開始の数日前、ナイトのIT社員が更新プログラムのインストールに取りかかった。問題がないことを確認するために、まず一部のサーバで試し、正しく作動するのを見届けてから、8台のサーバのすべてにRLP機能を組み込んだ。いや、そうしたつもりだったが、実際には1台だけ追加し忘れた。7台のサーバは修正ずみのソフトウェアを実行したが、8台目のサーバは、パワーペグコードが残る、古いバージョンのままだった。

読むだけで寿命が縮むレベルだが、いろいろ調べてみるとさらにお腹の痛い事実が次々と・・・

  • The Rise and Fall of Knight Capital — Buy High, Sell Low. Rinse and Repeat.
  • コードのデプロイは手動であり、ダブルチェックはなかった。各サーバのコード不一致を警告するようなチェック機能も導入されていなかった
  • 取引初日の稼動直前に「Power Peg disabled」というエラーがメッセージ通知されていたが、内容もあいまいであり、リアルタイムで対応する体制もなかった為に見過ごされていた
  • 同社はインシデント対応フローが確立されておらず、問題発生時に大きな混乱に陥った
  • 2010年のフラッシュクラッシュで追加されたサーキットブレーカー(価格変動を基準とした自動停止機構)条件には該当しなかったため、自動遮断はされなかった
  • トラブル発生直後、直近で修正されたコード(RLP対応)が原因であるという誤った(最悪の)判断があり、全サーバが1世代前の状態に切り戻された。これは、8台全台のサーバがパワーペグコードが残る、古いバージョンに戻されたということである(黙祷)
  • 当然のことながら、全台でパワーペグ機能が稼動し、さらに大量の取引が実行された
  • その後エンジニアが原因を特定しシステムをシャットダウンした。ここまで(なんと)業務開始から28分である

いやぁ、勉強になるなぁ~