今や生産性の可視化・評価指標といえば本書籍で紹介された『FourKeys』ですね。ちまたでは、絶対視されている様な表現・評価がされている記述をたまに見かけます。ですが、本当にそうでしょうか？ある方が調べたところ、FourKeys を使用している人のうち『Lean と DevOps の科学』を読んだことがない人は9割近くもいたそうです。

本記事では、FourKeys を有効に活用するために知っておくべき・理解しておくべき事柄を幅広い分野でまとめました。生産性を向上し、仕事の成果の質を上げたいと努力するエンジニアの方々が、次の日から使える情報を書けたのではないかと思います。FourKeys だけを見て生産性を上げるという行動は手段の目的化につながりかねません。Fourkeys の背景にある思想を知ることで、FourKeys を真に活用するきっかけになればと思います。

初めに
1. 2000年台〜2010年台間のソフトウェア業界におけるアジャイル開発の変遷と DevOps 概念台頭の影響
2．Lean と DevOps の科学とはなんなのか？
3．Lean と DevOps の科学でまず読むべきところ
4．Lean と DevOps の科学の成果とは何か？
- 4-1. 各用語の簡易解説
- 4-2. Lean と DevOps の科学の注意点
5. IT 業界における工学的理解と統計~医療従事者だった自分からの見え方~
- 5-1. 統計の身近な具体例~ナロンエース~
- 5-2. 今の確らしさがいつまでもそうである保証はない
6. 科学を支える哲学
- 6-1. 書籍『イシューから始めよ』~バリューのある仕事とは何か~
- 6-2. 永遠のたたき台ですよ。解なんて。
7. Fourkeys と SPACE
8. どういうふうに進めていくか？という壁にぶつかるまえに
9. 最後に
10 参考文献

初めに

GW中に読もうと思っていた『Lean と DevOps の科学』という書籍についての記事です。

本書籍は、DevOpsという概念が登場した2007年〜2008年頃から DevOps の有効性を研究していた Puppet Labs社が出していた技術レポートの「State of DevOps Report」が元になっています。

「State of DevOps Report」はソフトウェアのデリバリに関する調査・研究の結果が記述されています。2014年版から2017年版の4年間をまとめたのが本書です。

研究の目的は

「高業績の技術系組織を生み出す要因は何か」
「ソフトウェアは組織をどのように改善し得るのか」

という疑問に答えることです。

で、この書籍を読めばチームの生産性を上げる方法がわかると。しかも、個人や一社の成功例ではなく普遍性客観性が科学的統計的アプローチによってある程度の確度が担保されているらしいと。

これはみるっきゃねぇ！！と思い購入しましたが、読みながら調べていると事前に知っておかなくてはいけないこと、理解しておかないといけない事が多く、そのことを知らないまま読んだら逆に危ないんじゃ？と思い、それらをまとめました。

また、『Lean と DevOps の科学』を題材にした教養記事という側面もあります。大まかに4点について話します。

①書籍『Lean と DevOps の科学』を読む前に知っておいた方が良いこと
②組織の生産性を上げるためにしっておくべきこと
③具体的に行動をする段で参考になる実例集の共有
④そこから学ぶ科学・統計学・哲学を含めた教養・リベラルアーツ

4番に関しては、以下の様な項目で明日からの仕事に活かせる内容をまとめました。

科学とは何か？
統計の威力とは何か？
統計とソフトウェアテストの類似点
仕事のバリューを最大化する力である哲学とは
問いと解、どちらが重要なのか？
哲学の実用例
- チーム間での議論における不毛な対立を終わらせるヒント
「理解」という現象の種類
社会人に必要な哲学者・工学者・科学者マインド
さまざまな学問・法則・書籍からの有効なインサイト
- 大数の法則・生存者バイアス・確証バイアス
- 『イシューから始めよ』『どらえもん』
- テック系ポッドキャスト『texta.fm』
- 哲学・科学・統計学・行動経済学・認知情報科学

などを紹介します。
ただし、大前提なのですが、私、まだ、本書籍を全部は読んでいません！！！

「は？何を言っているんだこいつは？」

そう思った皆様、全くその通りです。なので、書籍の内容に突っ込んだ言及はしません（できません）が、有益なのは間違い無いと思っています！（ほんまか？）

私がここで書いたことは自身にとっての備忘録でもあります。ただ、まとめていく中で

これを知っておかないと本当の意味で理解できないのではないか？
生産性を上げたいと思っても逆効果になりそう
FourKeys は確かに有用そうだけどその裏側にある思想や背景をちゃんと理解しないと手段が目的化しそう....

といった気付きが多々あり、であれば共有して誰かの役に立てばいいな、という思いで公開することにしました。

また、統計とは何か？科学を支える哲学とはなんなのか？を明らかにすることで、エンジニアである皆様によりよいエンジニアライフを、そしてよりよい人生を生きることに繋がるのではないか？役立てるのではないか？という熱い想いもあり、同時に記述することにしました。

どちらにしろ、本書籍を背景にある思想や文脈から『Lean と DevOps の科学』を深く理解する事に繋がることをまとめました。

本書籍が登場するまでのソフトウェア業界でのアジャイル開発の流れ
どの時点で DevOps が登場し、どの様な影響を与えたのか？
『Lean と DevOps の科学』は何から生まれたのか？
『Lean と DevOps の科学』の功績
IT 業界に感じた非科学性（生存者バイアス）
統計とは何か？
良い科学の土台は良い哲学
FourKeys と SPACE の関係　
実践する際の参考にしたい事例・資料の共有
参考文献

それではよろしくお願いします。長いです。

1. 2000年台〜2010年台間のソフトウェア業界におけるアジャイル開発の変遷と DevOps 概念台頭の影響

https://open.spotify.com/episode/7JP6BFOB2grTJt5V3VmI9Z　
　　
ピクスタ株式会社CTOの後藤優一さんと技術顧問の和田卓人さんのポッドキャストです。本章と「4『Lean と DevOps の科学』の成果とは何か？」は、基本的にここからを抜粋してます。ちゃんと聞きたい方は上記リンクを参照してください。その他は最下部の参考文献をご覧ください。めっちゃ多いです。

背景も含めた要約

ビジネスとの関わりにおけるプラクティスはスクラムが
技術的なプラクティスは XP が巻き取っていたのが2000年台
スクラムが勢力を伸ばしていく中で技術的なプラクティスの存在感が希薄化
クラウドコンピューティングが出てきて、いわゆる DevOps の概念が登場（2007年ごろ）することで潮目が変わる
コンティニュアンスデリバリーのように迅速な仮説検証、迅速なリリースを実現するための環境・マインドが再び注目（2010年ぐらい？曖昧ですみません）
それを支えたのが、XP における技術的なプラクティス
1. 継続的インテグレーション
2. TDD
3. ペアプロ
4. リファクタリング
5. YAGNI など
XP における技術的なプラクティスや価値観は DevOps により推進されていった
「Lean と DevOps の科学」は、そういったアジャイルの技術プラクティス（に限らず）が組織パフォーマンスにインパクトを与えていることを統計的な事実や科学的なアプローチで示した
2000年代の巨人がKent BeckやMartin Fowlerならば、2010年代の代表選手は彼ら（著者ら三名）と言っても過言ではないと

技術の歴史の交差点みたいなものが2010年代にあるんですけど、その交差する切っ掛けを作ったというのがこの2人だな（著者の三人のうちの二人）というのを、私自身としたら？個人的に評価としてはそういう風に考えています。
（中略）

それに対して技術プラクティスというのは余り注目されず残ってた結果、ビジネスと技術の関係というのがやや歪な感じになって、いわゆるヘロヘロスクラム問題と言われるような、スクラムやってるんだけど、技術的にはボロボロでリリースをくり返す毎にどんどん品質が悪化している。

つまり、アジャイルソフトウェア開発とかスクラムとかを支えるだけの技術力が伴わないって問題が発生してたんだけど、それに対してスクラムもそうだし、リーンもそうなんだけど、特にインフラとしてのクラウドが出てきてからは、本当に安価に、かつ迅速に仮説検証ができるようになったので、よりビジネスとソフトウェアの関係が近づいたんですね。

で、ビジネスとソフトウェアの関係が近付いた上で、それを支える技術的背景とかがないと、そもそもその迅速な試行錯誤とかを回転させることができないよねっていうので、回転させるための技術たちや考え方たちが再び大きく注目されて、かつ研究されて編纂されるってことになったと。そこでガンガンちからを発揮してで知識体系をまとめで道筋を作ったのが（著者の人たち）だと思うので2010年台のヒーローという様な個人的な評価をしました。

技術、ビジネスを支えるためには、どういった技術が必要なのかっていうのをもう一度、ちゃんと整理整頓して道筋を作っていこうという流れを作ったというような感じで解釈してますね。

2．Lean と DevOps の科学とはなんなのか？

「State of DevOps Report」というソフトウェアのデリバリに関する調査・研究の結果を記述したレポートがあります。2014年版から2017年版の4年間をまとめたのが本書です。

State of DevOps Report は2013年にPuppet社が発行しました。

DevOpsの歴史とは？
DevOpsは2007年から2008年頃に始まった。しかし、Puppetでは、DevOpsという言葉を聞いたことのある人さえほとんどいなかった頃に、DevOpsの調査を開始しました。最初のDevOpsサーベイを開始して以来、私たちはサーベイの質問に答えてくれた約4万人の人々から、組織を変革するDevOpsの力について多くのことを学んできました（ありがとうございます！）。

この資料では、当社の「DevOpsの現状」レポートを通じて、長年にわたるDevOpsの本質的な歴史を振り返ります。

研究目的は

「高業績の技術系組織を生み出す要因は何か」
「ソフトウェアは組織をどのように改善し得るのか」

そして、本書籍には直接関係しませんが、Google Cloud の DevOps 研究チーム DORA からも同様な技術レポートがあります。比較対象としてこちらでの研究目的も紹介します。

「組織で高い IT パフォーマンスを実現する方法」
「ソフトウェアを開発・運用するために効果的かつ効率的な方法」

という問いに答えること。いやぁーいい問いですね。

3．Lean と DevOps の科学でまず読むべきところ

本書籍『Lean と DevOps の科学』では、FourKeys の有用性を主張しています。ソフトウェア企業の競争力というのを、ある程度定量化し決定づける四つの調査項目、測定できるメトリクスがあることを明らかにしたのです。

リードタイム（コミットからデプロイまでの間）
デプロイ頻度
MTTR（サービス復旧所要時間）
変更失敗率

前者二つが開発速度だとしたら、後者二つはソフトウェアの安定性に関する指標となるわけです。そしてこの4つの指標の裏側にはさまざまな要因があることを明らかにしています。

上記スライドでは、以下の図が『Lean と DevOps の科学』で最も有用だと語っています。texta.fm においても、まずこの図を見て全体を把握してから読んだ方がいいという話があります。

これは、ソフトウェア開発組織がパフォーマンスを発揮するための理論モデルです

ここでは、これらの要因をケイパビリティと呼び、全24個（最新は27個）を定義しています。これらを向上させると FourKeys に結果が反映されるといった相関性を示しています。速度・安定性共に高い開発組織としての能力を獲得するために、このケイパビリティがあることを示し、こういうものをに投資していくことで組織としての地力が上がっていく事ができるというわけです。

また、ゾンビスクラムガイドが提供するスクラムを有効化するための理論モデルのDevOps版であることも述べています。

以下の画像は私（スクラムマスターです）が自身のチームで実際にゾンビスクラム診断を実施した際にサービス内で出てきた参考画像です。以下のリンクで無料にて実施できるので興味あればお試しください。めっちゃいいですよ（適当）。ちなみに上記のスライドの作成者が作った「A Theory of Scrum Team Effectiveness 〜『ゾンビスクラムサバイバルガイド』の裏側にある科学〜」このスライドを見て、やろうと思い立って診断しました。物凄く良かったです（適当）。

やはり、スクラム習熟度が可視化されることで、チームの共通認識を揃えられたというのはかなりでかいです。議論の際にスーパーでかい効果がありました。全員が同じ点に問題意識をもっている、統一されることの意義ったらないですよ。

4．Lean と DevOps の科学の成果とは何か？

スクラム以外でアジャイルとビジネスを近付かせた
リーン・アジャイルにおけるプラクティスの優位性を統計的科学的なアプローチで検証しようとした
研究ベースであり、査読付きの論文が根拠として用いられてるため信頼性が高い
1. 研究解説本の様な側面もある。特に中盤
ソフトウェアデリバリーパフォーマンスを定義・定量化
ソフトウェアデリバリーパフォーマンスへ正の影響を与える要因を明らかにした
1. 書籍発行時点（2018年）では24のケイパビリティ（2024年現在は27）があることを特定
2. 技術的なケイパビリティで言えば、テスト・デプロイ自動化・継続的インテグレーションなど
ケイパビリティがソフトウェアデリバリーのパフォーマンスに正の影響を与え、かつ、それがその組織パフォーマンスに正の影響を与えることを証明
1. 技術的ケイパビリティの正しい実践が、最終的に経営的な成果に繋がっていることを示した
2. ケイパビリティを改善した結果が反映されるのが FourKeys
ソフトウェアエンジニアリングの基礎であり重要なものと、企業業績・競争力に因果相関関係があることを統計的科学的に証明した
開発速度とソフトウェア品質はトレードオフではなく、正比例の関係性であることを明らかにした
1. つまり、速度が遅いチームは品質も低い

長らくエンジニアリングの現場では「なんとなくそうだろうな」と思っていたことが客観的な数字によって強い相関関係があることが証明されたということが画期的
和田卓人さんのツイートより

※ 現在、27のケイパビリティが記載されているのはこちら。

4-1. 各用語の簡易解説

統計
「集団」もしくは「集団現象」の「傾向・性質・規則性・不規則性」をデータから「数量的」な形で明らかにすること。数量的とはすなわち確率であり、確率の高さを表す言葉として「蓋然性」がある。社会における具体例は後述。

データは未加工の事実でしかないので、それ単体には意味はない。データを加工整理し意味を割り当てたものを情報と呼ぶ。データに情報を与えるには別のデータと比較して、その差分から意味を推測する方法などがある。

（DBには情報ではなくデータを保存すべき、という原則の中のデータと同じ意味）

参考：https://www.stat.go.jp/teacher/statistics.html

蓋然性
ある事象が起こる可能性や確率を示す概念。統計学や確率論において頻繁に用いられる用語で、特定の結果が生じる確からしさを数値化したもの、つまり蓋然を具体的に数量化したものが「確率」となる。蓋然性は、事象の起こりやすさを評価するための重要な指標であり、科学的な予測や判断を行う際には欠かせない要素。

科学
普遍・論理・客観性、再現可能（実証）性と反証可能性をもつ。反証可能性とは、言い換えれば「テスト可能性」「批判可能性」ともいう。「誤りをチェックできるということ」であり、それがないものは科学ではないと言われている。

哲学から進化した科学という歴史において、哲学は「意味」を取り扱う本質学であり、対して、科学は「事実」を扱う事実学。対象を検証し因果関係を明らかにする。因果関係は決して相関関係で代替してはならない。自然界の歴史や自然界の仕組みを、観察可能な物理的証拠を基礎として理解するもの。ここでいう事実とは、統計の文脈でのデータという意味。

「死後の世界がある」というのは、誰にもそれが誤りであることを確認する手段がないので、科学的であるとは言えない。神話なども同じく本当にあったのかも確かめられないの科学ではありません。宗教学となります。どちらが優れているという話ではありません。

相関関係
「二つの値の間に関連性がある関係」のこと。一つの値が変化すると、もう一つの値も変化することを指す。

因果関係
「原因とそれによって生じる結果との関係」のことで、原因の「因」と結果の「果」が組み合わさった言葉。一つの値を原因として、もう一つの値である結果が変化することを指す。

因果関係がある場合には相関関係もあるが、相関関係がある場合は必ずしも因果関係があるわけではない。

例：肺がん罹患リスク

ここで整理をしてみましょう。「ライターの所持」と「肺がんに罹るリスク」，「タバコの喫煙」と「肺がんに罹るリスク」は，両方とも一つの値が変化すると，もう一つの値が変化します。つまり両方とも相関関係があります。

しかし前者は，「ライターの所持」が「肺がんに罹る」原因とは考えられないので，後者のように因果関係があるとは言えません。

つまり，因果関係がある場合には相関関係もあるが，相関関係がある場合は必ずしも因果関係があるわけではない，ということになります。

参考：https://www.taishukan.co.jp/hotai/media/blog/?act=detail&id=405

ケイパビリティ
企業や組織の持つ「企業全体の組織力」や「組織固有の強み」を意味する。

組織のパフォーマンス
収益性・市場占有率・生産性など。

4-2. Lean と DevOps の科学の注意点

「本書に寄せて」

の部分で、リファクタリング・XP の書籍、アジャイル開発宣言起草メンバーで知られる Martin Fowler さんは以下の様に述べています。

心から推薦できる IT デリバリの測定手法の解説本ーひと握りの分析者のバラバラな体験談に基づいた本よりはるかに優れた本ーが誕生したのである。
　本書で著者3人が明かしている実態には、有無を言わさぬ説得力がある。たとえば、

とある。しかし、以下の様に二つの点に対して注意喚起もおこなっています。まず1点目について

まず、この研究が採用したアンケート調査で、なぜ信頼性の高いデータを得られるのか、<中略>主観的な感覚に関わる回答を求める調査であるため、この研究のサンプル集団が、広く一般のIT業界の実態を正しく反映しえているのか、との疑問が残る。
〜中略〜
今後、この種のさらなる裏付けが重ねられれば、「この調査結果は、自分たちが支持し推奨している理論や運動を追認する結論をだしているだけではないか？」との私の懸念も薄らいでいくと思う。

この中では確証バイアスの影響は甚大だ、といいその懸念も取り上げていますね。

続いて2点目。

本書の焦点の当て所がIT分野におけるデリバリにかぎられる、ということーつまり、ソフトウェア開発の全工程ではなく、コミットから本番かどうの段階までにしか目を向けていない、という点ーにも注意が必要である。

とはいえ、続いて以下の様にも述べていました。

以上、2点について、あえてケチを付けさせていただいた。いずれも注意を要する点であるが、本書の根幹となる論拠を損なうものではない。

とのこと。『Lean と DevOps の科学』は2018年当時の書籍であり、2024年の現在では6年の年月が経っています。この中での変遷や新しい事実やそれらへの解釈の取り方などを理解した上で、自身の企業でどう活用するかを自分自身で見極める必要がありますね。

5. IT 業界における工学的理解と統計~医療従事者だった自分からの見え方~

※ 以下の記述は、前述にある 4-1. 各用語の簡易解説 を理解した上で読まないと理解しづらいかもしれません。

ソフトウェアの世界を見ていると(3年目のくせに非常に恐縮ではありますが)、残念ながら科学的統計的な視点が十分な世界とは言えないのではないか？と思っています。なぜかというと、生存者バイアスによる報告や成功事例が多い様に感じるからです。また、大体の話で N 数は数人〜数社であることが多いので大数の法則があまり重視されていない印象です（という意見も N 数1という.....）。

そういった意味では Google の各種調査（ex. プロジェクトアリストテレス）や State of DevOps Report は科学的統計的なアプローチをしているなと感じました。批判は多々あるでしょうが。以下に調査方法に関するリンクを貼ります。どの様に調査したのか？調査方法に確証バイアスを潜ませない機構があったのか？対象属性に偏りはないか？大数の原則にそった N 数はあんのか？など批判的な疑問を解消したい方は取っ掛かりとしてどうぞ。

大数の法則とは、

「サンプルサイズが小さいと、より極端な値をとる確率が高い」
「サンプルサイズが大きければ大きいほど、極端な値をとる確率が低くなっていく」

ことを表す法則です。簡単な例はサイコロです。各出目が出る確率は理論的には1/6です。ですが10程度しかサイコロを降らなかった場合、それぞれの出目の出る確率は偏ります。もしかしたら、5が5回・１が3回・４が2回、といった内容になるかもしれません。全く1/6の確率ではありません。では、これを一億回振ってみたらどうでしょうか？各出目の出現確率は限りなく1/6に近づいていくと思いませんか？この現象を理論値への収束や確率収束などと言います。それが上記の二つ目の現象の意味になります。

つまり、一例（一つのサンプル）だけでは極端な事例や値だったりするので参考にできない、という解釈ができます。サンプル数は多ければ多いほど良いのです。理想は無限。

本当に知りたいのはその事例が全体でも当てはまるのか？ということでしょう。他の会社で成功したやり方が、自分の会社でも通用するのか？世間一般的にある程度の確度あるやり方なのか？ですよね。色んな所で同じ様な成果が出ているのなら、「確からしい」と感じませんか？大数の法則を満たしているかどうか？というのは、色んな場所・色んな集団でも有効なのかを示すための重要な要因です。理想は全数調査ですが、現実的に無理ですよね。なので、有効だろうと思われる数をサンプリングして理想値に近い近似値をとるわけです。これを統計学では

「母集団から抜き出された一部の標本を使って、母集団を推定することができる」

と表現します。母集団とは、統計の対象とする人や物の集まりのことです。
言い換えれば、ある企業で成功したやり方が通用する集団、のことを言います。

なので N 数が少ない事例というのは極端な値や現象になりがちです。再現性が低い、生存者バイアスがかかりやすいなどの懸念があるので鵜呑みにすることはできません。SNS で成功例を語り散らかすアカウントの無意味さが良くわかりますね。

生存者バイアスとは、

「失敗例を考慮せず、成功例にだけに着目して物事を判断している状態」

を指します。有名なのが、撃墜されていない戦闘機の損傷から戦闘機を補強・改良しようとした話。帰ってきた戦闘機を参考にしても意味がありません。何故なら、帰還した戦闘機は撃墜されていない、つまり致命的な箇所への被弾がなかったから帰還できたからです。
　補強・改良を行い、撃墜される戦闘機を減らしたいという課題を解決するには、本来は撃墜された戦闘機を参考にしなければいけないはずです。帰還（成功）した戦闘機だけに着目して検証・実験した結果は間違った結果になることは明らかではないでしょうか。失敗例を中心に、成功例は比較材料として扱うべきだったという話ですね。

（実は、この話はフェイクである可能性も高く真偽のほどは定かではないんですよね〜。有名な以下の画像は「架空の画像」なのが判明しています。出典は Wikipedia。とはいえ、伝えたいことの説明としては分かり易いので引用事例としています）

もともと救急医療にて、血液浄化・呼吸器疾患・心臓外科・心血管脳血管カテーテル手術分野にて医療従事していた身（医者・看護師ではありません）としては、生存者バイアスによる判断や少ない N 数での研究・臨床結果は意味が薄いどころか、非常に危ないものだと感じていましたし、常識でした。ある患者でうまくいったやり方が他の患者へにも適用できるわけではないからです。救急に限らず医療においては、患者ごとに正解が全く違います。

年齢
人種
性別
持病・既往歴の有無
家族構成と家族の持病・既往歴
体質・体格・血液型やアレルギー
薬剤の使用履歴
宗教（エホバは輸血拒否される）
症状の度合いや栄養状態
失血量や臓器損傷の有無
酸素飽和度とヘマトクリット値
浮腫の有無に種類や度合い、血液検査結果
敗血症などの致命的なショックの有無
併発する免疫不全や血管内凝固症候群の有無

これ以外にも、把握しきれない変数が無数にある中で、患者の命やこれからの生活の質・取り戻せる質、生活復帰への期間などに関わる治療の意思決定を行うが私が見てきた救急医療でした。
眼の前で今にも死にかけている人。内臓破裂してストレッチャーでオペ室に運ばれてる人のお腹が、みるみると膨らんでいくのを目撃しました。1秒の遅れ、意思決定の遅れがその人のその後の人生を左右するのです。

暗闇の中でどの方向へ進むのが正しいのか全くわからないまま進むのと同じです。その暗闇を照らす松明、もしくは灯台は統計だったと思います。

もちろん、既存の学問は前提としてだけど、既存の知識では判断できない領域で、唯一根拠として挙げられるのが統計ではないかと。これってエンジニアリングでも同じことが言えると思いませんか？これってアジャイルが適している複雑系に近い話だと思いませんか？(医療はどっちかというと複雑系とカオス系の混在だと思いますが)

よくビジネス側を説得できない、といった困りごとをリアル・ネット問わず目撃しますが、こういった根拠をうまく利用できれば解決しやすくなるだろうな〜とふんわり思っています。

論文を読む際は以下の様な点を気にしていました。あくまで医療従事者観点なので悪しからず。パッと今思いつくやつです。

p値
統計的有意性
前向き後ろ向き研究
コホート分析・クラスター分析
システマチックレビュー
メタアナリシス
ランダム化比較試験か
認知の歪みを表す諸々の心理効果
- 生存者バイアス・確証バイアス・初頭効果・近接効果など
良い問いか？良い解か？解の求め方が適切か？
N数は？
対象の属性（年齢・性別・人種・遺伝的体質・既往歴・持病・薬歴とか）は？
参考文献は提示されているのか？信頼できる文献なのか？
どこの組織がどこの出資で行なっているのか？
その他etc

その上で、治療方針会議時での発言・提案、カルテ記載、医師への報告をしていました。（専門ではないのでその程度でしかなかったけど）

話は変わりますが、認知の歪みも相当面白いので話したいのですが、書ききれないしとっ散らかるので諦めます。気になる方は書籍『ファストアンドスロー』を読んでみてください。誰が言ってたか忘れましたが、

「人間OSの間違い方パターン大全集」

という言い方がぴったりな書籍です。分野としては行動経済学(最強の学問とか最近言われています)。人間の本質が誤謬性（間違うこと、反対は間違わないことを意味する無謬性）であることがよくわかる本です。失敗をむやみやたらに批判する組織の愚かさがよく分かります。

5-1. 統計の身近な具体例~ナロンエース~

分かり易い例としては、みんなもお馴染みの鎮痛薬の「ナロンエース」の主成分「アセトアミノフェン」です。

少なくとも自分が医療従事者であった2021年時点では作用機序（メカニズム）が解明されていませんでした。つまり、鎮痛効果や解熱効果の作用機序が解明されていないのに使用され続けているということです。しかも、子供に飲ませてもよい数少ない解熱鎮痛薬です。病院で処方される代表的な商品は「カロナール」です。お子様がいらっしゃる方で聞いたことがない人は少ないのではないでしょうか？

解明できない原因は三つあると言われています。

人体に未知のメカニズムが存在する
アセトアミノフェンの成分に未知の薬効が存在する
その両方

それでは、なぜこの様にどうして効くかも解っていない薬効成分がここまで市民権を得ているのでしょうか？それは「統計」によって有効性と安全性が証明されたからです。統計とは、不確実性を切り拓く人類の武器。その様に私の中では位置付けています。とはいえ、扱いを間違えば危険なものであることも忘れてはいけません。

長くなりましたが、そういった感覚から IT 業界に入って感じたのが、最初に挙げた生存者バイアスの多さや大数の法則まわりの話だったというわけです。とはいえ、それらを含む発表や資料・情報を否定しているわけではなくこれまでもこれからもお世話になっていくし、それらの情報発信を行う企業や個人の活動には敬意を払うべきだと思っています。言いたいのは、そういった問題を抱えていることを認識しておくことの重要性と必要性です。

そういった所感の中で、科学と銘打った書籍である『Lean と DevOps の科学』を見つけたときは興奮しました(笑)
リーン・アジャイルにおけるプラクティスの優位性を統計的科学的なアプローチで検証しようとしたのは、ものすごいことではなかろうか！ソフトウェアの工学性を引き上げる大きな契機ではないか、と感じたわけです。

おお〜！科学って銘打った書籍がソフトウェア業界でも高く評価されてるんや〜といった感じでした（自分が知らなかっただけの話なので無礼失礼申し訳ありません）。

工学的理解とは実現「できる」という意味です。再現可能性が高いに近いかもしれません。

数学的理解：分類できる
- ex. topology・位相幾何学は物の形を分類、マーケにおけるユーザ属性（性別など）
物理学的理解：予測できる
- ex. ミサイルの弾道計算、太郎くんが投げたボールの飛距離計算問題など
工学的理解：実現できる
- ex. 予測した弾道計算で想定通りの目標・地点に着弾する

これらの理解の分類の話しは、古典物理学者・楽天常務執行役員の北川拓也さんのお話から頂いています。詳しく聞きたい方はこちらのポッドキャストをどうぞ！

https://open.spotify.com/episode/6ZMAKIHJhDP84j7HbGedVl?si=NvgJfKhRSdabonbgbpw6_g

工学的理解が高い分野としては、デザインパターン（クラウド・アプリなど幅広く含む）や数々の設計原則、DDDにクリーンアーキテクチャ、その他コード規約の有用性、などかなと感じています（感想）。コンピュータサイエンスもそういった分野なのでしょうかね。全く分かりませんので知ってる人がいたら教えてください。

蓋然性（確からしさ）が高いので統計的有意さが証明されなくても、古くからそのまま生き残ったり、幹はそのままに枝葉の形を変え継承され続けるのだと思います。それは歴史が正当性を証明してくれているのかもしれません。この先もそうであるとは保証していませんが。

余談：書籍「チームトポロジー」はチームの形やあり方を分類している書籍ってことですかね？まだ読んでないので想像ですが。次読んでみたい書籍です。
ちなみに2021年の State of DevOps Report に本書籍の著者が参画してるとのこと。本書籍を読んでからレポート読んでみたらだいぶ見方が変わりそうです。おもろそう！

5-2. 今の確らしさがいつまでもそうである保証はない

2023年厚生労働省はアセトアミノフェン製剤の添付文書に重大な副作用として「薬剤性過敏症症候群」を追記・改訂することを指示する通知を発出しました。アセトアミノフェン製剤の歴史は100年以上あります。

1873年に初めて合成され、1893年に医薬品として使用されて以来、100年以上にわたって世界中で広く用いられているわけですが、未だに上記の様な新発見が続いています。いかに統計が強力な武器であろうと、分からないものが無いこと、どの様な状況でも有用であることや危険がないことを保証しているわけではありません。

ソフトウェアテスト7原則における 「原則1 | テストは欠陥があることは示せるが、欠陥がないことは示せない」 と似ていませんか？統計への造詣を深めることは、ソフトウェア品質保証への造詣を深めるのに通じているかもしれませんね。

6. 科学を支える哲学

この様に、如何に統計的科学的なアプローチによって蓋然性の高い結論が導かれたとしても、それが未来永劫間違わないことは誰にも保証できません。そして、間違っているから価値がないのではなく、間違っていたとしても上質な問いを打ち立て、今現在において最も確からしい解を出したということが『Lean と DevOps の科学』、元になったレポートである『State of DevOps Report』の素晴らしい点だと思っています。

今の時代に生きる私たちは、この研究者たちの想いを受け継ぎながら、共に間違いや不足を発見したり、その確らしさを高め続けるというリレーを繰り返していく必要があります。

私たちエンジニアは科学者であると思っています。そうでなくてはいけないと思っています（ビジネスマン・ウーマンは皆その側面を持つべきちゃうか思ったりしてます）。常に確らしさを追い求めてますよね？変更容易性・テスト可能性・デプロイ容易性の高い設計とはなんなのか？保守し易くて認知負荷の低いコーディングはなんなのか？ユーザにとって良いプロダクトとはなんなのか？所属組織にとって利益になるものとは何か？考え続けなくてはいけないですよね。

良い科学者であるためにはどうしたらいいのでしょうか？ここに答えを出してくれるのが「哲学」です。では哲学とは何か？哲学と科学は実はもともと同じものでした。両方とも確からしさを求める学問です。では何が違うのでしょうか？

上記でも軽く書きましたが、哲学は本質を求める学です。例えば、良い社会とは何か？良い教育とは何か？良いプロダクトとは何か？これは科学的なアプローチでは導き出せませんよね。意味や価値を問うのが哲学で、そのための方法論を2400年以上かけて追い求めてきたわけです。これは科学の仕事ではありません。

科学とは事実のメカニズムを明らかにする学です。事実を観察・観測・測定し、そこで何が起きているのか？何が行われているのか？というメカニズムを解明するのが科学の仕事です。

たとえば、ストレスを感じたときに人はコルチゾールというホルモンを分泌します。人はストレスを感じるとコルチゾールを分泌し、ストレスから身を守ろうとするという事実を観測し、因果関係を明らかに出来るのが科学の力です。

しかし、そもそもストレスとはなんなのか？を明らかにしないと何を調べればいいのかが分かりません。人によってストレスと感じるものが違うからです。私は人に自分の人生をコントロールされたり、自身で制御できないと感じた時に強いストレスを感じます。ですが、人によっては誰かにコントロールされている状況下の方がストレスを感じない人もいるわけです。いわゆる奴隷の幸福などが近い話ですね。（そもそもストレスをネガティブなものであるとした場合の見解です。ストレスには良いストレスもあります）

ストレスとは何か？を明らかにしないことには、ストレスを科学しようとしているのに幸福を科学してしまうかもしれないというわけです。何がストレスと呼ばれるものなのか？ストレスの本質とは何か？をまずそれらの本質・意味を明らかにしないことには科学をすることは出来ない、と。

本質・価値・意味をおざなりした科学ではよい解を求めることが出来ません。良い解を求めるのは、まず良い問いを導出する必要があります。ここで言うところの「ストレスとは何か？」から始めなくてはいけないのです。

6-1. 書籍『イシューから始めよ』~バリューのある仕事とは何か~

イシューとは、「2つ以上の集団の間で決着のついていない問題」であり「根本に関わる、もしくは白黒がはっきりしていない問題」の両方の条件を満たすもの。

著者である安宅和人さんは本書の中の「バリューのある仕事とは何か」で以下の様に述べています。ちなみに安宅さんの経歴はこんな感じ。

僕の理解では、「バリューの本質」は２つの軸から成り立っている。ひとつめが、「イシュー度」であり、２つめが「解の質」だ。
〜中略〜
僕の考える「イシュー度」とは「自分のおかれた局面でこの問題に答えを出す必要性の高さ」、そして「解の質」とは「そのイシューに対してどこまで明確に答えを出せているかの度合い」となる。
〜中略〜
本当にバリューのある仕事をして世の中に意味のあるインパクトを与えようとするなら、あるいは本当にお金を稼ごうとするなら、この「イシュー度」こそが大切だ。

安宅和人. イシューからはじめよ知的生産の「シンプルな本質」 (Japanese Edition) (p.28). Kindle 版.

つまり、「解の質」よりもは「問題の質」の方が重要であるという事です。ここで問題になるのは、ストレスをまず定義しないことには、ストレスの科学ができないという点になります。であれば、まず問わなくてはいけないのは『ストレスとは何か？』であるのです。

このように本質を先に明らかにすること、その必要性に気付ける力、物事の中核、根本の根本を解き明かす。それによって、そのことについてまつわる様々な問題の解き明かすための考え方を提示するのが、哲学の仕事です。

6-2. 永遠のたたき台ですよ。解なんて。

『生産性を上げるためにはどうしたらいいのか？』

この議論はエンジニアであれば一度は考えたことがあるのではないでしょうか？ここで言いたいことはもうお分かりですね？

まずこの議論を始めるには

『そもそも生産性とは何か』

を定義することから始めないといけません。人によって生産性の定義が異なる中で議論しても全く意味はありません。それらについてを置き去りにすると、どこまでいっても対立が続くわけです。お互いがお互いにとっての生産性について、正しいと思われることを議論しているわけですから。

そんな時に、確かに生産性とはそのようなものだとみんなが納得する答え・定義があれば、共に協力してより生産性を上げていく方法を探す関係になる。競争から共創に、対立から共同に、していくことが出来るわけです。それが哲学の力だと思うわけです。XP でいうところのインセプションデッキなんてのはここに焦点をあてたものだと強く感じています。

問題としてまず取り上げなくていけないのは、生産性の定義がチーム・組織内で統一されていない、という点です。それが定まっていて初めて、生産性を上げるためにはどうしたらいいのか？という次の問いに進めるわけです。安宅さんが定義した問題にぴったり当てはまります。

「2つ以上の集団の間で決着のついていない問題」
「根本に関わる、もしくは白黒がはっきりしていない問題」

なので、極端な話ですが解の質はある程度低くてもなんとかなると思っています。みんなで上げていけばいいわけですから。共創と共同すればなんとかなります。永遠のたたき台ですよ。解なんて。

「State of DevOps Report」は、ソフトウェアのデリバリに関する調査・研究の結果を記述したレポートでした。

そして、研究目的は

「高業績の技術系組織を生み出す要因は何か」
「ソフトウェアは組織をどのように改善し得るのか」

そして、Google Cloud の DevOps 研究チーム DORA の研究目的はこちらです。

「組織で高い IT パフォーマンスを実現する方法」
「ソフトウェアを開発・運用するために効果的かつ効率的な方法」

個人的に一番すごいと思っていることは、これらの『問い』を導き出したことです。この優れた問いがあれば、その解の質を上げ続ける事が出来ます。

古代ギリシャの哲学者、タレスは今から2700年ほど前にこの様な問いを打ち立てました。

『万物の根源とは何か？』

タレスは水だと考えました。それが間違っていることは周知の事実です。ですがそれが何だというのでしょうか？

間違ってること言ってんな〜昔の人は

その様な解釈は私は間違っていると強く言いたいです。その後、顕微鏡など存在しない時代に頭の中だけで、原子という概念を見つける人が登場します。それがアトム(これ以上分割できない物質の最小単位)と呼ばれるものでした。これは2500年前に発見されたものです。
そして、今でもこの問いに対する解は求められ続けています。超弦理論です。物質は紐だというのです。

タレスが打ち立てた『問い』は人類史上最も優れた問の一つではないでしょうか。なにせ、2700年も問われ続けている問いなのですから。

7. Fourkeys と SPACE

『Lean と DevOps の科学』で FourKeys の有用さが提唱されています。ですが、3人の著者の一人でもある Nicole Forsgren 氏は2021年に「The SPACE of Developer Productivity」という論文でSPACEフレームワークを発表しました。開発者の生産性を多面的に評価するためのフレームワークです。この論文は、GitHub・ヴィクトリア大学・Microsoft Researchなどの複数メンバーによって作成されています。

The SPACE of Developer Productivity
There's more to it than you think.

開発者の生産性を高めるスペース
あなたが思っているより、もっと多くのことがあります。

本書籍『Lean と DevOps の科学』では、FourKeys の有用性を主張しています。

リードタイム
デプロイ頻度
MTTR（サービス復旧所要時間）
変更失敗率

前者二つが開発速度だとしたら、後者二つはソフトウェアの安定性に関する指標となるわけです。

しかし、本論文では

productivity and perhaps even for predicting it. For example, productivity and satisfaction are correlated, and it is possible that satisfaction could serve as a leading indicator for productivity; a decline in satisfaction and engagement could signal upcoming burnout and reduced productivity.

例えば、生産性と満足度は相関関係にあり、満足度が生産性の先行指標となる可能性がある。

と主張しており、FourKeys　にはまるで無かった視点で生産性を論じている様に見えるわけです。ですがよくよく見てみると「職務満足度」とか「バーンアウトの軽減」など、類似するケイパビリティが存在するので、結構親和性の高いFWであることが伺えます。因果関係ではなく、相関関係いうてますけどね。とはいえ、直感的にもそらそうだよな、という感じです。持続可能性そっちの方が明らかに高いだろうなとも感じます。

SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024

で、2023年に

ファインディ株式会社が主催した「開発生産性Conference」の基調講演では、2018年にGoogleに買収されたDevOps Research and Assessment（DORA）社の元CEOであり、「LeanとDevOpsの科学」の著者であるニコール・フォースグレン氏がDevOpsによる開発生産性向上に欠かせない要素を紹介。DORAのメトリクスとSPACEフレームワークをキーに、測定や文化がどのような役割を果たすのかについて解説した。

で、この中でニコール・フォースグレンさんは以下の様に述べていたようです。

DORAとSPACEは補完的な関係と先述したが、「共通点もある」とフォースグレン氏。DORAはSPACEのメトリクスの一部なのだ。DORAはいくつかのSPACEの要素をカバーしている。ソフトウェアのデリバリープロセスで考えてみると、リードタイムは効率性とフロー、デプロイの頻度はアクティビティ、MTTRは効率性とフロー、変更障害率や可用性はパフォーマンスの指標として見ることができる。「DORAはSPACEの5つの側面の内、3つをカバーしている。つまりDORAはSPACEの一部と言えるのです」（フォースグレン氏）

引用元：PR数から「SPACEフレームワーク」へ、技術組織の成長と共に進化した開発生産性の計測手法より

Myth: One productivity metric can tell us everything
One common myth about developer productivity is that it produces a universal metric, and that this "one metric that matters" can be used to score teams on their overall work and to compare teams across an organization and even an industry. This isn't true. Productivity represents several important dimensions of work and is greatly influenced by the context in which the work is done.

神話：1つの生産性指標ですべてがわかる
開発者の生産性に関する一般的な神話の1つは、普遍的な指標を生み出し、この「重要な1つの指標」を使って、チームの仕事全体を採点し、組織全体、さらには業界全体でチームを比較することができるというものだ。これは真実ではない。生産性は、仕事のいくつかの重要な側面を表しており、仕事が行われるコンテキストに大きく影響されます。

特定の指標を重要視することの危険性はよく聞く話ですね。FourKeys がいかに有用であろうとも、誤謬性が本質である人間が定義したものが絶対的に正しいはずなどありません。こういった新たな指標が登場するのは必然なんだろうなと思います。また、ここのあたりは組織開発におけるプロセスロス・プロセスゲインとも通じている様に感じました。

いまから FourKeys を導入する場合、SPACE も併せ持って使用していくことを検討するのが良さそうに感じます。

引用元：“心理的安全性が高い”チームのつくり方 - 第2回　心理的安全性を高める組織開発のステップ

株式会社ZOZOのZOZOMOチームでは FourKeys と SPACE を用いてチームの生産性と健康状態を可視化する取り組みをおこなったそうです。

DORAってなんやねん？って思った人用

DORAについてですが、『Lean と DevOps の科学』は State of DevOps Report の2014年版から2017年版の4年間をまとめたものですと前述しました。で、

元々は State of DevOps Report は2013年に Puppet Labs 社が発行
2015年に DORA 社が創業し、Puppet Labs 社と共同で State of DevOps Report を発表するように
2018年には DORA 社が Google により買収
DORA 社のパートナーは Puppet Labs 社から Google Cloud 社に
その後も、Puppet Labs 社は State of DevOps Report を発行し続け、
DORA 社も同じく DevOps に関するレポートを発行
で、Puppet Labs 社は2023年から State of DevOps Report Platform Engineering Edition という名前で発行している

DORA　と Puppet Labs どっちのレポートなのか区別付きづらい。ようわかりませんぶっちゃけ。

なので、ここで State of DevOps Report ではなく DORA と表現されているのはこういった経緯があるから何やろなーって適当に思っています。ガッツリレポート検証して批判するとかでなければそこまでしらんでもいいかもしれないですね。

State of DevOps Reportの歴史

引用元：LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report

8. どういうふうに進めていくか？という壁にぶつかるまえに

以下が非常に参考になる。冒頭で説明した通り、『Lean と DevOps の科学』をしっかり読んでもいないし、実践もしていないわけですが、実践する段になったら参考にしたいと思っているのが以下になります。

9. 最後に

いやぁ疲れました。もう『Lean と DevOps の科学』読んだ気分です。これからしっかりと読み込みたいと思います。

これを書き始めたのは、Lean と DevOps の科学を有効活用したいという思いから情報収集を始めたのがきっかけでした。で、その内容をみんなに共有して、あわよくばいろんな人から建設的な批判いただけないかなーという下心もあり。ただ、書いている途中で変質していきまして、最も伝えたいところは「科学を支える哲学」の部分に変わりました。

哲学って人生・仕事・社会・企業・人間関係を良くするための強力なツールだと思っています。いわゆるリベラルアーツです。学問のキングオブキング、学問の祖とまで言われているのに日本では影が薄いので悲しいです。これを機に哲学やリベラルアーツに興味を持っていただけたら嬉しいです。

ここらへんのスライド資料にその辺り書いたので、もしご興味持っていただけたら是非とも見ていただけたらと思います！！最後になりますが、ここまでご覧いただきありがとうございました！もし参考になったよーって方がいらっしゃいましたら、いいねお願いします！咽び泣いて喜びます。

目次

初めに