勘と経験と読経

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

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

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

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

前半の感想はこちら

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

「Beyond Legacy Code(レガシーコードからの脱却)」の総評

  • 技術書をマメに読む人にとっては、「どこかで聞いた話」が多いかもしれない。
  • 逆にふだんあまり技術書を読まない人やチームメンバーにとっては、様々な良書技術書からのエッセンスがまとまっているので非常にお得な本だろう。
  • 紹介されているプラクティスが9つしかないのも、取り扱いやすさという点では良い。迷う必要がない。

というわけで技術書をあまり読まない人にはオススメの本。ただ個人的には「どこかで聞いた話」も多かった印象は否めなかった。

ソフトウェア業界の改善に向けて

84zumeさんの感想でも触れられているけれど、最近のトレンドとしてアジャイル開発の「管理手法」の側面ばかりがピックアップされており、「技術プラクティス」の活用が十分ではないという著者の指摘は割と鋭いと思う。日本国内ではDXの文脈でもアジャイル開発手法も注目されているのだけれども、基本的には「管理手法」がピックアップされている印象だ。実際には「技術プラクティス」のほうが重要になるだろう。

とはいえ一方では

  • SIer/受託開発のビジネススキーム(契約の観点、チームの観点)
  • 発注者文化
  • 受注者文化
  • もろもろの契約スキームとソフトウェアの特性とのギャップ

などの問題も山積みで、技術プラクティスの採用は割とハードルは高いものも多い。うまいやりかたは自分でも探し中である。

そういえば余談だけれど、技術プラクティスといえばXP(本書でもすごい推している)だが、そういえばJoy.incもXP推しなんだよなぁ。

何かヒントがないか、再読してみるか悩み中。

美意識、オッサン、イノベーション・スキルセット

最近読んだいくつかの本が似たような論点について触れていたので面白かったという話。やはりこれからの時代、教養そしてアート/デザインに関するスキルの重要性は高まっていくようだ。個人的にはどうしたものか思案中。

アート/デザインの重要性が高まっていく

今年の後半に読んだ以下の本がいずれもアート/デザイン領域のスキル重要性について語っていて面白かった。この半年にピックアップしたのはかなり偶然である。これがセレンディピティというやつか......

イノベーション・スキルセット~世界が求めるBTC型人材とその手引き

イノベーション・スキルセット~世界が求めるBTC型人材とその手引き

  • 作者:田川欣哉
  • 出版社/メーカー: 大和書房
  • 発売日: 2019/08/24
  • メディア: Kindle

新書の2冊は(筆者が同じなのだけれども)

  • アート
  • サイエンス(あるいは論理)
  • クラフト(あるいは技術)

が大切であり、かつこれまで特に日本ではアートが軽視されてきたという事がテーマとして主張されている。
(ちなみにオッサン本では、2018年時点で五十代・六十代となっているオッサンたちは特にアートとサイエンスが抜け落ちてダメだという本)

現在のように変化の早い世界においては、ルールの整備はシステムの変化に引きずられる形で、後追いでなされることになります。そのような世界において、クオリティの高い意思決定を継続的にするためには、明文化されたルールや法律だけを拠り所にするのではなく、 内在的に「真・善・美」を判断するための「美意識」が求められることになります。
世界のエリートはなぜ「美意識」を鍛えるのか?~経営における「アート」と「サイエンス」~ (光文社新書)

そして「イノベーション・スキルセット~世界が求めるBTC型人材とその手引き」では、

の三分野(つまり頭文字を取ってBTC)に関するリテラシーを身につけなければ、これからのプロダクトデザインはできないという事が書かれている。超同意。

その意味で、デザインはテクノロジーやビジネスの大切な伴走者なのです。もはやデザインは特別なものではなく、デザインなしでは成功できない時代が到来しました。ですから、ビジネスパーソンやエンジニアが、このデザインというものの中身を知り、活用することはとても重要なことなのです。
イノベーション・スキルセット~世界が求めるBTC型人材とその手引き

もちろん、それぞれの本で異なる主張もあるけれども、大いに興味が湧いたという次第である。

エンジニア中心キャリアからアートを学ぶにはどうしたらよいか

さて、自分は理系出身でエンジニア中心キャリアを歩んでいるので、現時点では足りていないのはアートやクリエイティブの分野である。というわけで文系科目の学習意欲がムクムクと首をもたげているのだけれど、実際のところは

  • 家庭的な都合も含めて、大学に本格的に入り直すとか社会人大学院に行くのは現時点の選択肢にはならない
  • 独学で習得する心がけはもともとあるけれど、ちょっとしんどい(例えば「哲学」とか無理)
  • お金はそれなりにかかってもいいけれど、ものすごい投資はできない

という状況でもある。

イノベーション・スキルセット~世界が求めるBTC型人材とその手引きではエンジニアキャリアがデザインキャリアのリテラシーをつけるためにはまずプロトタイピングスキルを身につけて、プロのデザイナーと協業していくのが良いと書かれているのだけれども、Takramに所属していればそうできるかもしれないが、なかなか難しいだろう。

というわけで現時点ではコストパフォーマンスも踏まえて、今のところは春から放送大学に入学することを真面目に検討している。他のMOOCS系は理学と工学中心でパッとしないんですよねぇ。

年明けまで悩む予定だが、何かアクションを起こしたらまたブログ記事としてアップしたい。

「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版)に着手する予定なので重ねてマズイ状況。