「1 + 1 = 2」の証明
私は大学生時代に数学を専攻していたのですが、飲み会でその話をすると「『1 + 1 = 2』を証明できるんでしょ？」なんて事をよく聞かれます。まあ、相手も本気で数学的な議論をしたいわけではないのですが、あまりによく聞かれるので、ここでひとつ「1 + 1 = 2」を証明してみましょう。
ここで「証明する」とはどういうことか議論をし出すと話が長くなるため、ここでは素朴に「ある命題をより基本的な命題から導くこと」としておきましょう。
「1 + 1 = 2」とは自然数の加算についての命題ですね。
今回は自然数に 0 も含めることにします。それは単に 0 も含めたほうが記述しやすいからで、深く考えないでください。「自然数に 0 が含まれる」に違和感があるなら「非負の整数」とでも言い変えてください。
足し算は小学一年生で習う基本的な数の操作です。しかし、数学では足し算よりさらに基本的な操作を考えます。それは「次の自然数」という操作です。つまり、０には次の自然数１があり、１には次の自然数２があり、２の次は３、３の次は４。どんな自然数にも次の自然数があります。
ここではある自然数 x の次の自然数を S(x) と書くことにします。 そうすると 1, 2 は記号としては不要になります。1 は S(0)、2 はS(S(0)) と書けるからです。 つまり、件の命題は「S(0) + S(0) = S(S(0))」と書けます。
さて、証明とは「ある命題をより基本的な命題から導くこと」でした。
今回は以下の２つの基本的な命題から導出します。
- ①∀x∀y (x + S(y) = S(x + y))
- ②∀x (x + 0 = x)
すなわち、
↑これらは、普通の足し算の交換法則とか結合法則などに比べ、より基本的っぽいですし、異議を唱える方はいらっしゃらないと思います。いませんよね？
では「S(0) + S(0) = S(S(0))」を証明しましょう。
①より S(0) + S(0) = S(S(0) + 0) が成り立ちます。(a) ②より S(0) + 0 = S(0) (b) (a) (b) より S(0) + S(0) = S(S(0)) が成り立ちます。 Q.E.D.
誰もオフィスワークの効果を知らないという不安
オミクロン株出現がニュースを賑わせており、新型コロナウイルスの流行の行先先は不透明だけど、日本ではまずまず落ち着いた状況。
なので、私の勤務先でもリモートワーク解除を進める動きがあるらしい。
でも、私はオフィスワークへの切り戻しは不安。反対ではなく、不安。というのも、オフィスワークとリモートワークにどんなメリット・デメリットがあるのか、基礎的な知識が社員間で共有されていない。
例えば「オフィスワークの方が雑談や相談が増えて仕事の効率が良い」という仮説も、では、週４日のオフィスワークにすれば、週２日の場合より仕事の効率が倍になるのか？1.5倍程度なのか？変わらないのか？そういった定量的な議論ができる状態ではない。
オフィスワークに戻したがる人も、リモートワーク推進派も、客観的な証拠ではなく、個人的な経験や好みで発言しているように見える。私も、正直、リモートワークとオフィスワークのどちらが良いのか、好みはあっても意見は無い。
現状でリモートワーク解除を進めると、結局地位が高い人の好みによって、なし崩しで解除が決まってしまうことになりかねない。そして、こういった曖昧な経緯で決まったことは得てして後から修正するのが難しくなる。誰も決定を下していないから、決定を覆したくても、誰を説得すればいいのか分からない。そして、「リモートワークをできない理由」が、後付けで都市伝説のように作り上げられていったりする。
こんな不安を感じている。
「監視は役割ではなくスキル」 by 入門監視
Mike Julian「入門監視」 オライリー刊を読んで、カルチャーショックというか、「我が意を得たり！」という思いをしたので、紹介します。
「監視は役割ではなくスキル」
私はソフトウェアエンジニア（Dev）に監視の知識は不要であり、 監視はインフラエンジニア（Ops）にお任せするものだと思っていました。 実際、これまでの職歴では、それで困りませんでした。
しかし、「入門監視」はこれを明確にアンチパターンだとしています。
ソフトウェアエンジニアはアプリケーションについて誰より詳しいので、素晴らしいアプリケーション監視の仕組みをデザインするには最高の場所にいるのです。
考えてみれば当たり前です。Opsはアプリの中身をよく知りません。 Opsが監視を任せられても、通り一辺の監視（CPU使用率など）しかできませんし、異常時にも自分で対応できないんです。
Opsが、
「CPU使用率が増えてるんですけど、大丈夫ですか？」
とDevに尋ねていたら「役割としての監視」に陥っている兆候です。
ユーザー視点での監視
「監視は役割ではなくスキル」を補強するのが、このデザインパターンです。
「監視」というとCPU使用率などの低レベルの指標がまず思い浮かびますが、 低レベルの指標は改善には役立たない、むしろノイズになってしまうことがあります。 です。
データベースサーバのCPU使用率が急上昇しても、ユーザーが影響を受けていないならそれは本当に問題でしょうか。
入門監視 P.30
「入門監視」では逆に「できるだけユーザーに近いところから監視を初める」ことを勧めています。
WEBサービスなら、CPU使用率より
- HTTPレスポンスコード
- レスポンス時間
の方が適切です。レスポンス時間が伸びていれば、少なくともユーザーが何か影響を受けていることはすぐに分かります。
「入門監視」では、さらにユーザーに（ある意味）近い部分の指標として、月次収支収益、顧客の解約数、アクティブユーザー数といった、ビジネスの指標も監視対象として挙げています。
今後は否応なしに、Devにも監視のスキルが必要になる
「そうは言っても、うちには優秀なOpsがいるし」と思う人もいるかもしれません。
しかし、最近はサービスを構築するときはクラウドがデフォルトの選択肢になっています。
クラウドでは物理サーバー構築が不要なので、Opsが他プロジェクトと兼任である、 あるいはOpsが不在のこともあるでしょう。
また、最近はインフラエンジニアが採用難であるそうです（AWSやGCPなどのクラウドベンダーに引き抜かれてしまうので）。 となると、今後増々、
という体制が増えていくことでしょう。
そうなったら、監視を構築するのはDevのあなたです。
「入門監視」は全エンジニア必読
「入門監視」は228ページと、オライリーとしては薄めです。
監視とは何か、何をどんな監視するべきかという、プリンシプル・技術以前のところから説明しており、ツールの流行り廃りに囚われない本質的な知識を教えてくれる本です。具
定価3,080円と、大変お求め安い価格なので、ぜひ買って読んでください。
「権限の分離」をもっとよく知りたいと思う
私は最近「権限の分離（Segrecation of duties, SoD, セグリケーション）」について勉強し直したいと思っているのですが、 手近に良い本が見つからず、困っております。良い書籍や記事をご存知のいらっしゃったら、教えて下さると幸いです。
こんなことを言うのは、WEB業界で働いていると、「権限の分離」と「権限の分離」っぽいものが混同されているとしばしば感じるのですが、 さりとて「権限の分離」を語れるほどの語彙も知識もなく、モヤモヤしているからです。
以下、自分なりの「権限の分離」とモドキの理解を書いてみます。
『権限の分離』
権限の分離（セグリケーション）
社員による不正や誤謬を防ぐために、業務を意図的に作り変えること。
１人に権限が集中しないようにしたり、監視役を設けたり、上司による決裁を必須にしたりすること。
『権限の分離』モドキ
権限の分離や不正防止に結果的に貢献することもあるが、貢献しないこともあるし、そもそも不正防止が目的ではなかったりするもののリスト。
上長決裁
特定の業務をする際に、上長による許可を必須にすること。
不正防止・事故防止の目的で行うこともあるが、上長がめくら判を押してしまい、機能しないこともしばしば。
どちらかと言うと、指揮系統の明確化・責任所在の明確化という意味が大きいのかもしれない。
職務分掌
業務を分担して行うこと・分担の仕方。２人以上で仕事をするには何らかの分担が必要になる。
分担を決める際には権限の分離も考慮することもある。
インフラ担当者とアプリ開発者の分離
大型コンピュータやネットワークなどのインフラを構築・運用するには高度な知識と人手が必要である。
よって、インフラを構築・運用する専門の担当者・専門の部署を設けることが多い。
データベースにおける権限階層
データベースソフトウェアでは、使用者の権限を「データの閲覧のみ可」「データの追加のみ可」「データやテーブルの追加削除も可」など、細かく権限レベルを分けて設定できる。データベースソフトウェアは、人間だけでなく別のソフトウェアからも利用されるので、ソフトが乗っ取られた場合の被害を防ぐため、細かい権限設定が重要である。もちろん、人間による不正や誤謬を防ぐためでもある。
SI業界における「開発」「運用」「保守」の分離
サービス開始時の開発、サービスの運用、運用開始後に見つかった不具合の修正や追加機能の実装（保守）を、別々の業者が請け負ったり、
同一業者でも別のチームが行ったりする。ぶっちゃけ請負業者側の大人の都合である。
開発者とテスト担当者の分離
開発者が自分が書いたコードを自分でテストすると、自分のミスを見て見ぬふりをしたり、視野狭窄に陥ったりして、テストが甘くなりがちだと考えられている。
よって、開発者とは別にテスト担当者を置いて、その人にテストさせる。
また、
- 「開発者の給料は高いから、給料が安いテスターにテストさせるべき」
- 「訓練を受けたテスト担当者（テストエンジニア）にテストさせる方が確実」
といった事情もある。不正防止に寄与する場合もあるが、主な目的はミスの防止である。
コードレビュー
開発者が書いたコードを、別の添削者が添削すること。不正を抑止する面もあるが、どちらかというとミスを見つけたり、コードのより良い書き方を指導するのが目的。添削者は１人の場合もあれば複数人の場合もある。
ペアプログラミング・ペア作業 １人でもできるプログラミングや作業をあえて複数人で行うこと。目的は色々あり、
- ３人寄れば文殊の知恵（２人だけど）
- 目玉が２個より４個の方がミスも見つけやすい
- 別途コードレビューする工程を省けて効率的
- ベテランと新人を組ませることで知識の伝承ができる
- サボリを防げる
機長と副操縦士
現在の航空機は自動化が進んでいるので１人でも操縦できるが、２人の操縦士を乗務させるケースが多い。
パイロットが航空機を盗んだり、乱心して故意に墜落させるのを防ぐためである。
もちろん、操縦士が急病で倒れた場合のバックアップや、トラブル発生時に分担して対応するためでもある。
江戸時代の武士における「相役」
江戸時代には１つの役職に複数人の武士を配置することがしばしばあった。不正防止という意味もあったのだろうが、武士が余っていたという面もある。
エンジニアの説明下手は「知識の誘惑幻惑効果」のせいかもしれない
ちょっと前、こんな記事が少し炎上していました。
説明が分かりにくいのは知的怠慢だ、技術者よ思い上がるな | 日経 xTECH（クロステック）
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00148/100300081/?n_cid=nbpnxt_twbn
「エンジニアの説明下手」については、
続きを読む