腐ったリンゴ理論／ヒューマンエラーを理解する

DevOps関連の書籍（DevOps HandbookやEffective DevOpsなど）やPostmortem関連の記事でよく引用されている書籍「ヒューマンエラーを理解する―実務者のためのフィールドガイド」について調べたメモ。

ヒューマンエラーを理解する―実務者のためのフィールドガイド

The Field Guide to Understanding 'Human Error' (English Edition)

安全尊重の文化

DevOps推進の文脈でよく出る話が、安全尊重の文化である。そしてこの安全を議論する上で避けて通れないのが「ヒューマンエラー」の誤用である。
例えば「The DevOps ハンドブック 理論・原則・実践のすべて」では次のように記載されている。

4.1 組織的な学習と安全尊重の文化を生み出す
複雑なシステムのなかで働くときには、定義上、自分の行動の結果をすべて完全に予測することは不可能である。そのため、たとえ事前に準備し、注意して仕事を進めても、日常業務のなかで予想外の結果が起きたりすることがある。
こういった事故が顧客に影響を起こしたときには、なぜそのようなことが起きたかを知ろうとする。根本原因はヒューマンエラーだと見なされることが多く、そうすると、管理者たちは問題の原因を作った者を特定し、非難し、恥辱を与えるという反応をとりがちだ。そして公然とそうでなくても、管理者たちはミスを犯した人物を処罰することをほのめかす。そして、ミスの再発を防ぐために、プロセスや承認を増やす。

「ヒューマンエラーを理解する―実務者のためのフィールドガイド」はまさにこの問題について書かれた良書のようだ。「The DevOps ハンドブック 理論・原則・実践のすべて」だけでなく、目につく範囲では

• 書籍 Effective DevOps ―4本柱による持続可能な組織文化の育て方、SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
• 記事 Further Reading - PagerDuty Postmortem Documentation

など、繰り返し紹介されている。

冒頭で紹介した通り翻訳書もあるのだが、調べてみるとlearning.oreilly.comで原著にアクセスできるようなのでちょっと読んでみた。

腐ったリンゴ理論

「ヒューマンエラーを理解する―実務者のためのフィールドガイド」では、ヒューマンエラーについて「以前の考え方（Old View）あるいは腐ったリンゴ理論」と「新しい考え方（New View）」を提示している。具体的には次のような対比になっている。

以前の考え方（腐ったリンゴ理論）	新しい考え方
「ヒューマンエラー」はトラブルの原因です	私たちが「ヒューマンエラー」と呼んでいるのは、より深いトラブルの兆候です
「ヒューマンエラー」は恐れられ、戦われるべき独立した行動のカテゴリーです。	「ヒューマンエラー」は帰属、事実の後に我々が下す判断です
「ヒューマンエラー」がターゲットです。人々の行動は私たちがコントロールする必要がある問題です	行動は、人々のツール、タスク、および動作環境の機能に体系的に関連しています
「ヒューマンエラー」は戦争を宣言するためのものです。人々は完璧を練習する必要があります	「ヒューマンエラー」とは、複雑さや実際の仕事の矛盾に人々がどのように対処したか（成功したかどうか）についての情報です
「ヒューマンエラー」は単純な問題です。すべてのシステムが整ったら、人々に注意を向けさせ、順守させます	「ヒューマンエラー」問題は、それを作成するのを助ける組織と少なくとも同じくらい複雑です
より厳格な手順、コンプライアンス、技術、監督により、私たちは「ヒューマンエラー」の問題を減らすことができます	人々の日々の仕事の厄介な詳細をよりよく理解することで、我々は彼らにとってそれをより良くする方法を見つけることができます
私たちは、ゼロエラー、ゼロ傷害、ゼロ事故を達成することができ、そして達成しなければなりません	私たちは人や組織の回復力を高めることができますし、しなければなりません

つまり、腐ったリンゴ理論とは「システムが正しく動いているのならば、腐ったリンゴおよびそこから生じる過ちを全て除去すれば良い」という考え方である。そしてこの考え方は現代の複雑な仕事やシステムには通用しない、というのはエンジニアのみなさんであればご存知の通り（そして常に「古い見方」をする敵に悩まされる）

なお、同書では（改めてみればあたりまえの）以下のような指摘などがされている

• 腐ったリンゴ理論は有用性に限界があるだけでなく、逆効果になる可能性がある
• 腐ったリンゴ理論から生み出される拙速な対策（関係者の懲戒、再訓練、手続きの追加など）は組織の学習を阻害し、生産性を悪化させ、かつ対策としても不十分となる

また、同書では航空業界などの様々なトラブル事例分析も添えて、具体的なヒューマンエラーの分析などについて記されているようだ。いつかちゃんと読みたいが、とりあえず今回はこんなところで。

EAの死あるいは再生、複雑適応系

昨年読んだ「――システム構築の大前提―― ITアーキテクチャのセオリー」は現代版のEA(Enterprise Architecture)の教科書として非常に素晴らしい本であった。というわけで久しぶりにEAに興味が湧いていろいろと調べていたところ、2019年に入って「Complex Enterprise Architecture: A New Adaptive Systems Approach」という書籍が出版されていたので読んでみた、という記事。

Complex Enterprise Architecture: A New Adaptive Systems Approach

なおKindle化はされていないが、APressでPDF版が購入できるようだ（プレビューもできる）。

• Complex Enterprise Architecture - A New Adaptive Systems Approach | John McDowall | Apress

また米オライリーのSafariに加入していれば追加費用無しにWebで読むことができる(加入方法はこちらの記事を参照)。

• Complex Enterprise Architecture: A New Adaptive Systems Approach [Book]

くわしくは後述するが、なかなか難しい本である。一方でEAを取り巻く最新の状況や歴史も紹介されているので、キャッチアップには非常に役立った。

EAの死

「Complex Enterprise Architecture: A New Adaptive Systems Approach」は、従来のEAは現在は機能不全となっており見直しが必要であることを主張している本である。既存EAの機能不全については同書以前に次のような批判があることを紹介している。

• Is Enterprise Architecture Completely Broken?
• The Death of Enterprise Architecture?

では、改めてEAは何が問題なのだろうか。同書では次のような指摘がされているようだ。

• 従来のEAはトップダウンアプローチのフレームワークである。これは、企業が単一の大規模な情報システムを構築している時代にはうまく機能していた。
• しかし時代は変わり、企業が多数の情報システムを保持し、開発プロセスの多くははアジャイル/DevOpsに変化。
• 巨大な情報システムをスクラッチで構築する時代は終わった。システム開発の多くは新技術を用いた既存システムの更改や、既存システムをベースとした機能追加となっている。
• この環境下で従来のEAはその価値を正しく発揮できていない。
• 現代の企業は非常に動的に変化している。静的なEAでコントロールすることは難しい。企業情報システムのすべてを少数のエンタープライズアーキテクトが掌握、管理することは現実的ではない。

まあ、ですよねー。実際のところEAを活用できている企業は存在するのだろうけれど、一般論としてはうまくいっていない印象はある。

Complex Enterprise Architecture

というわけで、本書ではこの状況を打破するために以下のような提言を実施している、と思う……（ここでちょっと自信が無いのは私の英語力の問題もあるのだけれども、本書はほとんど例示がないのだ。念のため著者のWebサイトも確認してみたけれども見当たらない様子。ということで私が正しく理解している自信はちょっと無い。興味のある方は原著をあたっていただきたい）。

• EAをトップダウンのアプローチから、ボトムアップのアプローチに転換する必要がある。
• 企業情報システム群とその開発組織を、複雑適応系として扱う。
  • 複雑適応系 - Wikipedia
• 新EAはトップダウンのアプローチをやめる。企業情報システムの全容を少数のエンタープライズアーキテクトが掌握、管理することは現実的ではない。そこで組織の創発的な行動に任せて、目標の達成方法を把握しながら監視することに集中する。
• 新EAは各システムの互換性や相互運用を可能とするための規律と制約を策定、共有する。

というわけで本書ではこれを実現する場合に整理すべき事項（オブジェクト類）などについても整理している（がほとんど文章なのでイメージしにくいのだ）。

うーん、これはどうなんだ……

現実的ではあるが、これでいいのか？

自分の見聞きした範囲が狭いのだが、実態として多数の情報システムを抱える企業が統制を効かせる方法としては、本書に書かれたような方向性になってしまうような気がする。

• 企業単位の全体俯瞰モデル(EAにおけるBAやDA、SA)は作成できたとしても維持困難で、実態としては割とカオス。
  • まれに基幹系システム更改やM&Aなどで資料が大慌てで整備され、その資料がロゼッタストーン化
• 一方で統制を効かせる必要はあるので、ルールやガイドラインを整備してエントロピーの増大を抑制。
  • しかし、ユーザ部門などによるシャドーITの導入増加などで混乱は拡大。

ただ、この状況を「複雑適応系としてコントロールする」なんて、本当にできるのだろうか？ というのはちょっと疑問である。
もうちょっと、調べてみようかな……

――システム構築の大前提―― ITアーキテクチャのセオリー

PagerDutyのPostmortem（トラブル事後分析）ガイドが公開。かなり良さそう。

Monitoring Weekly - Improve your application monitoringのニュースレター経由で知ったのだけど、PagerDutyからPostmortemのガイドが公開されていたようだ。

• Introducing the PagerDuty Postmortem Guide | PagerDuty
• PagerDuty Postmortem Documentation

ざっと読んでみたところ、かなり有用そう。

Postmortemとは

訳書だとSRE本やEffective DevOpsなどが詳しかったと記憶しているが、定義はこんな感じ。

ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。
SRE 15 章 ポストモーテムの文化：失敗からの学び

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

Effective DevOps ―4本柱による持続可能な組織文化の育て方

未訳だけれどもSRE本の続編、SRE Workbookに書かれたPostmortemの話は以下の記事で触れているので興味があればご一読いただきたい。
agnozingdays.hatenablog.com

PagerDutyのPostmortemガイド

PagerDuty Postmortem Documentation
というわけで、ざっと読んでみた感想。

• ChromeのGoogle翻訳機能でもけっこう読める（ただし、Postmortemが「死後」と翻訳されるため、かなりスピリチュアルな翻訳になるので注意）
• 「学習する文化」といった背景の話から初めて、ステップバイステップの執筆ガイド、共有方法までカバーされていて、たぶんいきなりトライすることができそう
• テンプレートだけでなく、チェックリストなども含まれていて至れり尽くせり
• Apache Licenceなので使い易そう
• 参考資料集が充実していて興味深い。紹介されていた以下の本はぜひ読んでみたいが・・・(どちらもSafariBooksOnlineに収録はされているようだ)

The Field Guide to Understanding Human Error (English Edition)

Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments, and Bad Behavior, Second Edition: - (English Edition)

SREやDevOpsを採用(?)していなかったとしても、品質改善活動の一環として「トラブル報告」「原因分析」「再発防止」などの活動をしているのであれば、いろいろと改善のためのアイデアが見つかりそうだ。

Scratch3.0でAtCorderに参加できるようになったのでいろいろやってみた

AtCorderという競技プログラミングサービスがある。設問に対して各種の言語で回答を書くと合否判定されるものなのだけれども、最近Scratchで書いたロジックをC++に変換してAtCorderの解答欄に入力できるという面白ツールがリリースされていたので、これを利用していろいろ遊んでみた。

• Scratcher's AtCoder の紹介 - Qiita
• Scratch3.0を使ってAtCoderで競技プログラミングを楽しむ - Qiita
• Scratcher's AtCoder - Chrome Web Store

やってみて気づいたこと

はじめのはじめ

基本的には次のページの通りだけれども

• Scratch3.0を使ってAtCoderで競技プログラミングを楽しむ - Qiita

Scratchの全てのブロックのうち何が利用できるかがわからず、途中で対応していないイベントブロックを使おうとしたりして、少し回り道をしてしまった。
利用できるブロックは以下にあるので、軽く目を通しておくとよさそう。

• scratch2cpp/blocks.md at master · yos1up/scratch2cpp · GitHub

入力処理について

こちらのページの説明では

Scratch では標準入出力は使えないので、標準入力の代わりに「〜と聞いて待つ」ブロック（一行の文字列入力欄が現れます）、標準出力の代わりに「〜と言う」ブロック（指定された文字列をネコがしゃべります2）を使っています。
Scratcher's AtCoder の紹介 - Qiita

とあったのだけど、この標準入力は改行までを受け付けるのではないという事に最初は気づかず少しハマってしまった。
例えば練習問題のPracticeAだと

入力は以下の形式で与えられる。

a
b c
s

とあったので「a」「b c」「s」が入力されると思ったら違った。普通に4回に分けて入力されるようだ（つまり2行目のb cは別々に入力される）。
よく見たら以下の記事で細かく説明されてた。

入力は調べるの「a と聞いて待つ」のように使う (改行とスペースで分けて読まれる)
Scratch3.0を使ってAtCoderで競技プログラミングを楽しむ - Qiita

なるほど〜

テストをやりやすくする工夫

AtCorderに提出するためには上記の通り入力を受け取るようにする必要があるのだけど、コードをテスト、デバッグする際にいちいちキーボードから入力するのは面倒。
というわけで試行錯誤した結果、次のような形にすると良さそうということがわかった。

• 初期化、主処理はブロック化する
• 提出用のスタートイベント（緑の旗）とは別にテスト用のイベントを作って、テスト時はコードでデータを入力する
• テストパターン（問題で示される入力例）を最初にコメント文にしておく

具体的にはこんなイメージ。

https://scratch.mit.edu/projects/281501288/editor/

便利関数が使えない

たとえばSortなどもScratchでは手組みする必要があるのでなかなか手強い

その他の感想など

• まずはAtCorder Beginners Selectionを正解例を見ないで自分で解いてみた。
• その後AtCoder に登録したら次にやること ～ これだけ解けば十分闘える！過去問精選 10 問 ～ - Qiitaの解説をチェック。勉強になるな〜
• 今後はもう少し過去問に取り組んでみる予定。
• いつかはコンテストにも挑戦してみたい。

頭の体操になって面白い。ブラウザだけで完結するのも手軽で良い。

小学生からはじめるわくわくプログラミング

小学生からはじめるわくわくプログラミング2

Scratchで学ぶ プログラミングとアルゴリズムの基本

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

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

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

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

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

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

デマルコ / デッドライン

古典その1。

デッドライン

正しい管理の四つの本質

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

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

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

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

古典その2。

Joel on Software

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

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

• 採用面接ゲリラガイド(version 3.0) - The Joel on Software Translation Project

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

• 採用面接ゲリラガイド(version 3.0) - The Joel on Software Translation Project

ほんこれ。

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

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

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

おっしゃるとおり・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• エンジニアの採用面接対策 - @ledsun blog
• エンジニア採用における面接者の心得をまとめてみた | 「世界」旅と子育てとガジェットを愛するエンジニアリングマネージャーのブログ
• This is How Coursera Competes Against Google and Facebook for the Best Talent | First Round Review
• 【翻訳】「シリコンバレーから生まれた最高の文書」と絶賛されたNetflixのカルチャーガイド全文 - BppLOG
• 公開されている採用ピッチ資料19選 （6/20更新）｜シニアル｜note (2019/7/26 追加)

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

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小説なのだけれども、音楽それもヒップホップが大きな役割を果たしていて、面白い。文章の勢いは往年の村上龍さんに近いものがあり、鋭い。読み始めると止まらなくなる類の小説だ。

• 途方もない小説『ミライミライ』で語られる「もう一つの戦後史」――「作家と90分」古川日出男（前篇） | 文春オンライン

ミライミライ

オススメビジネス書編

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

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

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

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

オススメ技術書編

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

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

ただ問題は、

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

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

• 継続学習力 - 勘と経験と読経
• ITエンジニアの業務時間外の学習 - 勘と経験と読経

この半期の振り返り

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

• 技術系の洋書をたらふく読もう！ - SSTエンジニアブログ

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

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

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

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

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

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

• 2014年に読んだ68冊からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
• 2015年上半期に読んだ本のふりかえり - 勘と経験と読経
• 2015年下半期に読んだ本のふりかえり - 勘と経験と読経
• 2016年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
• 2016年下半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
• 2017年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
• 2017年下半期に読んだ本まとめ - 勘と経験と読経
• 2018年上半期に読んだ本まとめ - 勘と経験と読経

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

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

• しがないラジオ sp.19a【ゲスト: Dear_you_cry】楽しい！？PL／Iでレガシー銀行システム開発
• しがないラジオ sp.42【ゲスト: 7coAim】転職したいあなたがまずやるべき楽しい”仲間づくり”と、人との出会いで変わっていく人生

紙駆動開発とは

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

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

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

どうしてこうなった

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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