勘と経験と読経

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

ゲリラでない採用面接ガイド(自分用)

Project Management

ほぼ自分用メモ。人材の採用面接はいつも悩ましくて、いろいろ調べたり考えたりしている。いっぽうですぐに調べたことを忘れてしまう（だって人間だもの）のでストアしておく記事。定期的に更新していきたい。

現時点の採用面接の基本方針

所属組織のガイドラインはあるのだけれども、個人的にはいろいろと改善していきたいと思っている。というわけで現時点の方針は次のような感じ。

  • イントロダクションで面接の流れを説明する
  • 面接官(自分)の自己紹介をしっかりする
    • その後の質疑応答をスムーズに進めるために、面接官のレベルを(出来れば)把握してもらう
  • 予め決めた評価軸に沿って評価する(思いつきで質問しない)
    • アドリブを否定するものではないが、あくまで点数をつけるために必要な質問をする
    • このあたりの詳細はGoogleのワーク・ルールズ本が詳しい
    • 評価軸は秘密
  • 妥協しない
    • 短期的な視点(例えば今すぐ、どうしても人が欲しいとかで)で決定しない

参考文献（順次追加予定）

デマルコ / デッドライン

古典その1。

デッドライン

デッドライン

正しい管理の四つの本質

  • 適切な人材を雇用する
  • その人材を適所にあてはめる
  • 人びとの士気を保つ
  • チームの結束を強め、維持する

（それ以外のことは全部管理ごっこ）

常にこの言葉に戻るようにしている

Joel on Software / 採用面接ゲリラガイド

古典その2。

Joel on Software

Joel on Software

面接の前に、私は候補者の履歴書を読み返し、面接のプランを紙切れに書き出すようにしている。プランと言っても、要は私が聞きたいと思っている質問のリストだ。次に挙げるのはプログラマの面接で使う典型的なプランだ。

  1. イントロダクション
  2. 候補者がやった最近のプロジェクトについての質問
  3. 簡単なプログラミングの質問
  4. ポインタ/再帰の質問
  5. 答えに満足しているか?
  6. 質問は?

面接の終わりに、その人が頭が良く物事を成し遂げる人だと納得させてくれ、4人か5人の他の面接者も同じ意見なら、あなたはその人を雇ってもたぶんまずいことにはならないだろう。しかしもし何であれ疑念があるなら、誰かもっといい人の現れるのを待った方がいい。

ほんこれ。

ワーク・ルールズ！―君の生き方とリーダーシップを変える

ワーク・ルールズ！―君の生き方とリーダーシップを変える

ワーク・ルールズ！―君の生き方とリーダーシップを変える

要するに、ほとんどの面接が時間の無駄なのは、面接者が最初の10秒で得た印象を確証するために99.4%の時間が費やされているからなのだ。「あなた自身について聞かせてください」「あなたの最大の弱みは何ですか？」「あなたの最大の強みは何ですか？」。こんな質問には何の価値もない。
多くの企業で採用されているケース面接や難問奇問にも、同じく価値はない。(中略)
こうした類の質問でわかるのは、せいぜいのところ、訓練すれば改善できる個別のスキルにすぎず、受験者を評価する役には立たない。最悪の場合、こうした問題は相手の知らない取るに足らない情報や知見を土台にしているため、面接者を賢くなった気にさせたり自己満足を感じさせたりするだけに終わってしまう。

おっしゃるとおり・・・

Joy, Inc. 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

メンロ ーでは密接に協力しあいながら仕事をする 。ゆえに 、最初のインタビュ ーでの必須事項は 、 「幼稚園レベルのスキルを持っているか 」だ 。礼儀正しくしているか 、周りとうまく遊べるか 、人と分けあえるか ？

最近のプロジェクトでは本当にこの要素の重要性が高まっていると思う。

NETFLIXの最強人事戦略～自由と責任の文化を築く

NETFLIXの最強人事戦略?自由と責任の文化を築く?

NETFLIXの最強人事戦略?自由と責任の文化を築く?

最適な人材を探すうえで大切なのは、「カルチャーフィット（文化の適合性）」ではない。カルチャーフィットがよい人とは 、一緒にビ ールを飲みたい相手だというくらいの意味しかない 。この方法で人材を探すのは 、往々にして激しくまちがっている。会社が必要とする仕事に合致したスキルをもつ人材には 、じつにさまざまな個性をもった人がいる 。

これは興味深い指摘だと思う。というわけで個人的には「所属組織に向いているか」という観点での評価はしないように心がけている（むしろ、自組織の特徴をしっかりと相手に伝えて、相手側で判断してもらうようにしたいと思っている）。

アジャイルエンタープライズ

アジャイルエンタープライズ

アジャイルエンタープライズ

第21章 アジャイルで使える人事制度を考案する

従業員を大切にする文化を築きたいなら 、内発的に動機付けされた従業員がいれば実現できるでしょう 。ここで疑問となるのが 、内発的に動機付けされた従業員を採用するときに 、 HRは何を求めるべきかです 。これについては 、自律性 、熟達 、目的についての考えを聞きましょう 。たとえば 、以下のような質問をするといいでしょう 。

  • 何を学んでいますか ?
  • 最後に読んだ記事は何ですか ?
  • 何について興味がありますか ?
  • 習得したいと思っているスキルはありますか ?
  • 仕事の自律性についてどう思いますか ?
  • プロダクトを作るときに 、顧客はどのような役割を果たしますか ?
  • コラボレ ーションを促進する方法は何ですか？

Joy,Inc.本と同じだが、最近このあたりの重要性が高まっていると思う。

その他個人的に有用だと思うリンク集

2018年下半期に読んだ本まとめ

Kindle book safaribooksonline

2018年7月～12月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2018年下半期に読んだ本

2018年7月～12月に最後まで読み終わった本はこんな感じ。

  1. [asin:B01LPWS4X6:title]
  2. レッド・ドラゴン〔新訳版〕 上 (ハヤカワ文庫NV)
  3. レッド・ドラゴン〔新訳版〕 下 (ハヤカワ文庫NV)
  4. いちまいの絵　生きているうちに見るべき名画 (集英社新書)
  5. 問題解決大全
  6. Linuxカーネル Hacks ―パフォーマンス改善、開発効率向上、省電力化のためのテクニック
  7. うつヌケ　うつトンネルを抜けた人たち　【電子書籍限定　フルカラーバージョン】 (角川書店単行本)
  8. 生き物としての力を取り戻す50の自然体験 ―身近な野あそびから森で生きる方法まで (Make: Japan Books)
  9. micro:bitではじめるプログラミング ―親子で学べるプログラミングとエレクトロニクス (Make:PROJECTS)
  10. [asin:B016W4PU8O:title]
  11. ミライミライ
  12. The Site Reliability Workbook: Practical Ways to Implement SRE (English Edition)
  13. The DevOps ハンドブック 理論・原則・実践のすべて
  14. 世界で800万人が実践! 考える力の育て方――ものごとを論理的にとらえ、目標達成できる子になる
  15. [asin:B00P0QOW3U:title]
  16. [asin:B00QWGZ718:title]
  17. メカ・サムライ・エンパイア (新☆ハヤカワ・SF・シリーズ)
  18. 異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養
  19. The Art of Monitoring (English Edition)
  20. 騎士団長殺し :第2部 遷ろうメタファー編
  21. 人体六〇〇万年史 上──科学が明かす進化・健康・疾病 (早川書房)
  22. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (English Edition)
  23. AI vs. 教科書が読めない子どもたち
  24. 業務システム開発モダナイゼーションガイド
  25. [asin:B015SSE15I:title]
  26. なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
  27. 方法序説 (岩波文庫)
  28. プロジェクト:シャーロック (年刊日本SF傑作選) (創元SF文庫)
  29. [asin:B06XP3GJ7F:title]
  30. [asin:B01934EF3Q:title]
  31. [asin:B078YJV9ZW:title]
  32. SIer脱出マニュアル
  33. もうすぐ絶滅するという紙の書物について
  34. 寺山修司青春歌集 (角川文庫)
  35. 知の仕事術（インターナショナル新書） (集英社インターナショナル)
  36. 人を動かす　新装版
  37. お金2.0　新しい経済のルールと生き方 (NewsPicks Book)
  38. 鳥の巣の本 (絵本図鑑シリーズ)
  39. 理科の目で見るしぜんのふしぎ (進学レーダーBooks)
  40. 超動く家にて　宮内悠介短編集 (創元日本ＳＦ叢書)
  41. 系外惑星と太陽系 (岩波新書)
  42. パラノイアだけが生き残る
  43. NETFLIXの最強人事戦略～自由と責任の文化を築く～
  44. 逆数宇宙 第2回ゲンロンSF新人賞優秀賞受賞作 ゲンロンＳＦ文庫
  45. Optimizing Java: Practical Techniques for Improving JVM Application Performance (English Edition)
  46. 宇宙樹
  47. [asin:B074W6G31L:title]
  48. だまし絵を描かないための-- 要件定義のセオリー
  49. the four GAFA　四騎士が創り変えた世界
  50. OKR（オーケーアール）
  51. スタートボタンを押してください　ゲームＳＦ傑作選 (創元ＳＦ文庫)
  52. 桜井信一のわが子に教えたくなる中学受験　算数・国語
  53. Chaos Engineering [Book]
  54. Practical Monitoring: Effective Strategies for the Real World (English Edition)
  55. ――システム構築の大前提―― ITアーキテクチャのセオリー
  56. 自分の頭で考えて動く部下の育て方　上司１年生の教科書
  57. ［改訂新版］プロのためのLinuxシステム構築・運用技術

オススメ文芸書編

「蜜蜂と遠雷」「騎士団長殺し」などは過去のベストセラーでもあり期待通りに面白かったが、ここは古川日出男さんの「ミライミライ」を推したい。史実とは異なる戦後を迎えた日本を舞台にしたSF小説なのだけれども、音楽それもヒップホップが大きな役割を果たしていて、面白い。文章の勢いは往年の村上龍さんに近いものがあり、鋭い。読み始めると止まらなくなる類の小説だ。

ミライミライ

ミライミライ

オススメビジネス書編

まぁ流行り物であることも重々承知の上だが、やはり「ティール組織」はいま読んでおくべき本だろうと思う。本書以降のビジネス書は当然のように本書を引用していくだろうからである（すでに、現在読んでいるいくつかの本では既知の概念として扱われている）。

ティール組織 ― マネジメントの常識を覆す次世代型組織の出現

ティール組織 ― マネジメントの常識を覆す次世代型組織の出現

イラスト版が出版されたようだが、こちらは未チェック。

［イラスト解説］ティール組織――新しい働き方のスタイル

［イラスト解説］ティール組織――新しい働き方のスタイル

オススメ技術書編

この半期は割といろいろと技術書の類を読み切ったと思うが、有用度が高いという意味では、「業務システム開発モダナイゼーションガイド」がダントツだと思う。

業務システム開発モダナイゼーションガイド

業務システム開発モダナイゼーションガイド

ただ問題は、

  • 本書が本当に必要な層の多くは、本書をはじめとする技術書の類をそもそも読まない
  • 本書の良さを良く理解できる層は、そもそも本書を読まなくても大丈夫

というジレンマがあって、どうしたものだろうかというのが直近の悩みである。

この半期の振り返り

こちらの記事でも紹介いただいたのだけれど

ちょっと工夫して、今年から年額99$で洋書技術書に実質無制限にアクセスできるようにしている。そして技術書は極力原著で読むようにしている。といっても、わからない部分はGoogle翻訳等もフル活用はしているけれど。

最初は読書コスパの向上（一般書に比べて翻訳技術書は単価も高いので、年99$ならすぐに元が取れる）が大きな魅力だった。しかし現在はコストだけでなく、制限なく技術書にアクセスできるという事自体が大きな魅力となっている。

  • 現在読んでいる本で紹介されている参考書籍に、即時にアクセスできる
  • Web記事についても同様
  • 引用文について、原著で前後の記載まで確認できる

という点が素晴らしいのである。

というわけで来年は未翻訳の技術書類をもっと紹介できるくらい読めたらいいなぁ。

過去の読書ふりかえり記事

紙駆動開発とのつきあい方

Project Management

開発者向けのPodcastの「しがないラジオ」を聞いていたら、SIer受託開発で「紙駆動開発（Paper Driven Development）」がキツかった的な話が面白かったので、いろいろ思うところを書いてみる。

n1339epinal

紙駆動開発とは

明確な定義は見当たらなかったのだけど、多分こんな感じ。

  • ウォーターフォール型開発プロセスの一形態
  • 強いフェーズゲートが設定されており、各工程の成果物のレビューや検証証跡を提出することで次の工程に進む
  • 紙資料が証跡の正本であり、紙資料に対してレビュー実施のサイン、マーカーによる着色、押印がされて成果物として完成する
    • 紙資料を正とするため、資料の再利用性に目が向きにくい（いわんや、自動化おや）
    • Excel方眼紙、神Excel
    • 手書き重視
  • コードやテスト結果についても人間のレビューや検証を重要視
    • ツールでテストをしようとしても、「ツールにバグが無いことが証明できないからダメ」と言われたり
  • コードの目検を重視するので、古いコードはコメントアウトして全部残したり、修正行全部にコメントしたり
    • モダンな構成管理と親和性が無い
    • 伝説の日付フォルダ管理

ネガティブな事ばかり書き連ねてしまったが、高い品質が求められるシステムであればコード1行あたりに多大なコストを投入しているという意味で、必ずしも紙駆動＝悪というわけではないだろう。例えば有人宇宙機、航空機、原子力発電所など（あくまでイメージです）の開発プロセスがライトだったら、嫌じゃない？

どうしてこうなった

特殊な高品質システム開発以外のいわゆる通常システム開発が現在も「紙駆動」だった場合、経緯は以下の２つが思い当たる。

パターン1（昔は良かった）

  • 大規模な初期開発が非常に大昔で、構成管理や自動化などのプラクティスがそもそも初期に存在しなかった。
  • 保守フェーズ以降は小規模体制となり、開発プロセスの改善投資する余力なく長期間最初のやり方を継続した。
  • 保守フェーズが長期化する中で開発能力が低下（推進力の高いリーダーやベテランの離脱、世代交代、コスト削減などにより）、改善する能力がさらに低下して現状維持で精一杯になる。

要は「昔からこうやっているし、問題はない」という話。
でも実際には構成メンバーは高齢化していくし、体制補充で新規要員を追加しても新参者が定着しないなどの課題はあるだろう。

パターン2（間違ったベストプラクティスの導入）

  • 太古の大規模な基幹システム開発が一度大失敗、経営からの指示で過度な標準化や重厚な開発プロセスが敷設される。
  • その後、第１世代は実際には標準化や開発プロセスというより、知恵と工夫でいくつかのプロジェクトを成功させる。
  • しかし開発体制が世代交代する中で組織の官僚化が進み、いつしかプロジェクトの成功よりも標準化の遵守を重視する文化の固定化。
  • 形骸化したルールだけが残る一方で、ルールを変更するのは大変すぎるので、ほぼ全員が下を向いて従っている。

「これがうちのルールです。従わないベンダーはお断り」という話である。
発注者側が強い限り継続することはできそうだけれども、既存のベンダーがやる気を失った瞬間爆発しそうな気がする。

紙駆動開発とのつきあい方

じゃあ、目の前に紙駆動開発プロジェクトがあらわれたとしたらどうすればいいだろう。逃げる以外の選択肢を考えてみる。

  • 開発継続性という観点で長期的なロードマップを描いてみる
    • 上記でも触れたけれども、5年や10年といったタイムスパンで線を引いてみるといろいろなリスクが見えてくるような気がする
    • リスクを洗い出した上で「ずっとこのまま継続できるのか」「放置しておくとどうなるのか」まで見据えた上で、近代化（モダナイゼーション）の提案を考えてみるのが良いのではないだろうか
  • そういえば経済産業省でこんなレポートが出ているのも参考になりそう

多くの経営者が、将来の成長、競争力強化のために、新たなデジタル技術を活用して新たなビジネス・モデルを創出・柔軟に改変するデジタル・トランスフォーメーション （＝DX）の必要性について理解しているが・・・ ・ 既存システムが、事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化 ・ 経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められる中（＝経営改革そのもの）、 現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている → この課題を克服できない場合、DXが実現できないのみでなく、2025年以降、最大１２兆円／年（現在の約３倍）の経済損失が生じる可能性（2025年の崖）。
DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜

まぁこの整理はどうなのよ、というツッコミもあるのだけれども・・・
しかし、真正面に対応するのは大変そうだ。では緩和策はあるのだろうか？

  • 少しずつ「紙」の資料を無毒化、解毒していく
    • あくまで紙資料はインデックスであるという整理で、提出物として印刷や押印するけれど、中身は「電子ファイル参照」という形に移行していく
    • 電子ファイルも一足飛びにMarkdownなどにチェンジするのではなく、まずは紙資料をスキャンしたPDFファイルあたりでソフトランディング
    • 縦型モニタを導入して「紙じゃないと見れない」派を懐柔
    • イマドキPDFファイルも電子押印や書き込みができるので、書き込みや押印類も少しずつ電子化

うーん、時間はかかりそうだけど、こちらのほうが抵抗は少ないかもしれない。

どうですかね。
ちなみにシステム開発の近代化（モダナイゼーション）についてはこの本がオススメ。

業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス

業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス

軽めに情報システムの障害状況ウォッチ（2018年前半）

Project Management Postmortem

趣味の情報システム障害状況ウォッチ。2017年後半のウォッチが飛んでいるのは自分自身とか所属組織が巻き込まれたとかではなく、単に忙しくなって忘れていたから。とはいえ現在も忙しいので個別事象のピックアップは省略。

過去に書いた関連記事は以下の通り。

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

2018年上半期（1～6月）は前年比で障害は多かったそうだ

2017年は月平均4件の障害だったものが、2018年前半は大きく増えて平均5.8件と躍進していたそうだ。聞いただけで胸が痛くなる。
ただしこのカウントは

  • 報道等でピックアップされた件数カウントなので、報道されていないトラブルはノーカウント
  • ヒューマンエラーなどもカウントされているので、システムそのものの品質についてどうこう言えるようなデータではない

という点に注意が必要ではある。

大ネタだけおさらい


こんな事も書かれてるよ

なお、このようなシステム統合とは問題が異なるが、来年5月には改元されることになっており、官民の多くのシステムは新元号への対応が必要である。報道によれば、新元号の公表は改元の1か月前を想定しているとのことであり、システムの変更に使える時間は非常に短い。1か月の短期間ですべてのシステムが改修を終えることは困難なため、一定期間は旧元号の利用も認められるようであるが、その間は新旧元号を用いるシステムが併存することになる。 システムが単独で運用されることはまれで、むしろ多くのシステムが相互に接続されて運用されるため、このような混在は問題をより複雑にすることが予想される。さらに、来年10月には消費税率の10%への引上げが予定されてい る。2014年4月に実施された8%への引上げの時にはシステムのトラブルが 7 件報道されており[松田 2014]、同様の障害が再発しないよう注意が必要である。いずれにしても、事前に十分な準備を行い、障害なく円滑な移行が行われることを期待する。

まぁ、仰る通りなのだけれども・・・

LeanとDevOpsの科学/Accelerate翻訳版が出るみたい

book

先日英語版で読んだAccelerateがさっそく翻訳されたようだ。なるほど、タイトルはこうなるのか・・・

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ

Kindle版が出るのかは発売日まで不明、でも出そうだな～
出てました。というわけでリンクはKindle版に変更。

パフォーマンス分析に関するアンチパターン

Professional Engineer

いくつかの書籍に書かれたパフォーマンス分析に関するアンチパターンを整理してみた。ここに無いものでご存知のパターンがあればご教授いただきたい。アーキテクチャや組織のパターンはよく見るけど、対応手法に関するパターンってあんまり多くないのかも（もしくは単にアンテナ感度が悪いだけ？）

詳解 システム・パフォーマンス (Systems Performance: Enterprise and the Cloud)より

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

第2章 メソドロジでいくつかアンチパターンが紹介されている(アンチではないほうのパターンも)。
書籍の内容の一部は、以下の翻訳記事および元ネタ記事と同様と思われるので、書籍にあたる前に一読するのが良いかも。

Streetlight Anti-Method (街灯のアンチメソッド)

自分のよく知っている観察ツールや、インターネットで拾ってきた可観測性ツール、その他何でも適当な観察ツールを使って、何か明らかな問題が現れるかどうかをチェックしてパフォーマンス分析とする

このメソドロジは、次のたとえ話が示す街灯効果（streetlight effect）という観察結果のバイアスから命名されている。

ある晩、警察官は街灯の下で探しものをしている酔っぱらいを見て、何を探しているのかと尋ねる。酔っぱらいは鍵を失くしたという。警察官も見つけられず、酔っぱらいに尋ねる。「街灯の下のここで失くしたというのは確かなことなんですか？」 酔っぱらいは答える。「いいや、でもここは明かりの具合が一番いいからね」

詳解 システム・パフォーマンス

Random Change Anti-Method(ランダム変更アンチメソッド)

どこに問題があるかを適当に推測し、その問題が消えるまで適当に変更を加える。

Blame-Someone-Else Anti-Method(誰か他人のせいにするアンチメソッド)

  1. 自分に責任のないシステムまたは環境のコンポーネントを見つけてくる。
  2. そのコンポーネントに問題があるという仮説を立てる。
  3. そのコンポーネントに対して責任を負うチームに問題を丸投げする。
  4. 仮説の誤りが証明されたら、ステップ1 に戻る。

詳解 システム・パフォーマンス

Optimizing Java

Optimizing Java: Practical Techniques for Improving JVM Application Performance (English Edition)

Optimizing Java: Practical Techniques for Improving JVM Application Performance (English Edition)

Chapter 4. Performance Testing Patterns and Antipatternsでいろいろと紹介されている。

Distracted by Shiny

レガシーコードは掘り起こさず、新しい技術やテクノロジー部分からチューニングしようとする

Distracted by Simple

われわれが理解している部分から始めよう

Performance Tuning Wizard

天才、スーパーヒーローを雇用して対応する

Tuning by Folklore(民間伝承に基づくチューニング)

「マジック」設定パラメータをネットで探すことに熱中する

The Blame Donkey

分析せずに、特定のコンポーネントが原因だと決め付ける

Missing the Bigger Picture

全体像を把握する前に、アプリケーションの特定の部分のプロファイリングや変更に注力する

UAT Is My Desktop

本番環境と異なる環境で調査する

Production-Like Data Is Hard

本番環境と同等のデータを準備することは難しい

個人的なまとめ

結局のところ、環境やOSを含めたアーキテクチャの全体像をモデル化して計測を行い、仮説の構築と測定を繰り返すのが正しいと思われる。しかし全体像のモデル化が難しい。Linuxサーバであれば「詳解 システム・パフォーマンス」を参考にするのが良さそう。Winodwsサーバはどうだろう、手元で取り扱っていないので良いモデルがあるのかはちょっとわからない。

おまけ：開発者が間違った技術選択をし続ける理由

前述の「Optimizing Java」で紹介されていたブログポストが興味深いのでこちらもピックアップしておく

  • 理由#1：退屈
  • 理由#2：開発者の経歴書に追加するため (Résumé Padding)
  • 理由#3：同僚や上司からの圧力
  • 理由#4：技術理解の欠如
  • 理由#5：誤解／存在しない問題に対する対処

どれも困ったことだけど、気持ちはよくわかる。#1～#3が発生しないように気をつけたいけれども、どうしたものか。

おまけ：アンチパターンのたのしみ

主人公たちの失敗をオーバーに描くことは、喜劇の定石である。その意味で本書の読後感ならぬ読中感は、アメリカ製の上出来の喜劇映画を見ている思いがする。なにしろ、この本は一貫して笑える。
アンチパターン―ソフトウェア危篤患者の救出 訳者あとがき、より

アンチパターン―ソフトウェア危篤患者の救出

アンチパターン―ソフトウェア危篤患者の救出

最近チェックしている英語技術書（2018/11）

book safaribooksonline

Safaribooksonlineを個人で利用できるようにしたので（詳しくはこちら）時々面白そうな本が無いかチェックしている。最近チェックした本についてのまとめ。なお、どれも完読はしていない。

Seeking SRE

Seeking SRE: Conversations About Running Production Systems at Scale

Seeking SRE: Conversations About Running Production Systems at Scale

SRE本というとGoogle発の2冊が有名だが、本書は出自が異なり、SRECon Europeというコミニュティがきっかけで書かれたエッセイ集（一部はインタビュー）のようである。エッセイ集なので話題は多岐に渡っていて、テーマによってもちろん執筆者も異なる。
というわけで、タイトルなどを見ながらつまみ食い的に読めばよいと思う。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Technology Strategy Patterns

Technology Strategy Patterns: Architecture as Strategy (English Edition)

Technology Strategy Patterns: Architecture as Strategy (English Edition)

2018年のO'Reilly Software Architecture Conferenceで発表された次の資料をベースにした本。

いわゆるビジネス戦略コンサルティング会社が使うような戦略分析のメソッドをベースに、技術戦略を構築するフレームワークとパターンについて書かれているようだ。さわりの部分しか読んでいないが、MECEとかSWOTとか見慣れた分析メソッドも含まれている。

SIerさん的な観点で見ると企画段階にコンサル会社さんが入っていれば役割分担的にも無視してよさそうだが、実際は諸々の事情によりSIer側でビジネス分析を求められる事がある。そういったシチュエーションで使えるノウハウが載っていそうな期待あり。

なお本書の冒頭を流し読みしている中で次の本が紹介されていた。こちらも読みたい。

戦略の世界史(上) 戦争・政治・ビジネス 戦略の世界史 戦争・政治・ビジネス

戦略の世界史(上) 戦争・政治・ビジネス 戦略の世界史 戦争・政治・ビジネス

Fundamentals of Data Visualization

Fundamentals of Data Visualization: A Primer on Making Informative and Compelling Figures

Fundamentals of Data Visualization: A Primer on Making Informative and Compelling Figures

文字通りデータの視覚化に関する本。技術的にはRとggplot2で視覚化しているが、技術的な側面より視覚化に関する包括的な考え方や注意点について書かれているように見える。
この手の本としては古典としてタフテのThe Visual Display of Quantitative Informationが知られているが邦訳も電子版もなく、ちょっと人に見せてもらったのだけれども人力だけで読むのは相当骨が折れそうだ。

The Visual Display of Quantitative Information

The Visual Display of Quantitative Information