Magnolia Tech

いつもコードのことばかり考えている人のために。

ビジネスとコードの関心の非対称性

Noteの過去記事の転載

—-

コードの8割とかは例外への対応だったりする一方で、ビジネス側の人はせいぜい2割くらいしかない、実現したい業務の主たる内容に関心の重きを置いている。それは必ずしもコードの量や割合の多さと比例するとは限らない。

一方でコード自体に、王道ルートも例外ルートの色分けは無く(ユースケース図で言うところの基本ルートと、代替ルートは有るけど)、等しくロジックとして実装しなければいけない。テストの密度を変える、みたいな話はあるかもしれないけど、王道ルートだろうが例外ルートだろうが、必要なロジックに合わせてコードを書くしかない。

このビジネスの関心と、コードの関心の非対称性が、時に「なんでたったこれだけのことをやるのにそんなに工数がかかるの？」みたいな不信感につながっていくのではないか。

また、当たり前だけど、ビジネス要求に基づく例外ルート以外にも、「メモリが不足していたら？」「外部サービスへのリクエストが返ってこなかったら？」「インフラに異常が発生したら？」などなど、さまざまなシステム上の要求に従って実装しなければいけないコードが有る。

また、業界の法規制(内部統制とか)からの要求によってはさらに、ビジネス側の主要な関心事項から外れるけど、実装しなければいけないことも発生してくる(ログが参照できるようになっているとか、さらにそれが改ざんできないようになっているとか)。

この非対称性を認識しないと、いつまで経ってもスピード感や、コスト感に対する合意が得られないのではないか？

追記：あと、追加する機能自体はすごくシンプルで、小さいけど、既存のコードへの影響が大きい(コード値が追加になる、何かのチェックを緩くするなど）ものは影響調査に物凄い時間がかかるし、整合性を取るために凄い量の改修が発生したりするんだけど、機能を依頼する側から見れば実際に変わって見える箇所は凄く小さいから「なんでそんなに時間がかかるの？こんだけの機能だよ？」となりがち。関心の非対称性は、解消していかないといけない。

『それはあくまで偶然です』を読んで、"生存者バイアス"について考えた

それはあくまで偶然です　運と迷信の統計学

それはあくまで偶然です　運と迷信の統計学

去年の暮れ、「生存者バイアスナイト」というイベントを思いついた。

生存者バイアス - Wikipedia

何らかの選択過程を通過した人・物・事にのみを基準として判断を行い、通過に失敗した人・物・事は見えなくなるため、それを見逃してしまうという誤謬である。

生存者バイアス……「たまたま運よく生き残っただけ」という人もいれば、「あの時のあの判断が効いたから」と因果を明確に語る人もいる。でも、結局はもう一つの、生き残らなかった方のルートを同時に経験することはできないので、その回答に対して「それはただの生存者バイアスじゃない？」と言われれば、そうかもしれない。

なので、”生き残っているのは、単なる運による偶然なのか、実力による必然なのか”という問いに安易に答える人は、あまりいない気がする。

だからこそみんなの”生存者バイアス上等”な振り返りを聞いてみたいと思った。

「生存者バイアスナイト」……まだ開催できていないのだけど、近々ぜひ開催したいと思っているのでお楽しみに。

……などと考えているタイミングで書店の店頭で見つけて気になったのが、この『それはあくまで偶然です』という本。あまりに面白くて、1日で読み切ってしまった。

なぜならば、統計学は本来、たった一つの単純で直感的で重要な疑問、すなわち、それはただの運なのか、という疑問についての学問なのだから。

筆者は、不吉な日と言われる13日の金曜日に生まれた、トロント大学で統計学を扱う大学教授であるジェフリー・S・ローゼンタール。

もっと専門的に書こうと思えばいくらでも書けるところ、せいぜいそれらしい専門用語は「p値」に留め、あとは豊富なエピソードを元にした、実に分かりやすく、それが偶然なのか、必然なのか、統計学の観点からの説明が続く。ちなみに、冒頭の引用は、「p値」の解説が載っている、第十二章の冒頭に出てくる言葉だ。

冒頭からあまりに有り得ない偶然の出会い、遺失物の奇跡的な発見、ギャンブルなど、いかに運命的で、何か超自然的な力によって起きた事象であると主張する人々がエピソードが紹介され、前半の山場、「第六章　射撃手の運の罠」において「真の技能」「まぐれ当たり」「散弾銃効果」「下手な鉄砲も……」「大勢の人」「特大の的」「隠れた助け」「偽りの報告」「プラシーボ（偽薬）効果」といった事実を歪めてしまう要素が紹介され、第十一章までそれらのキーワードとともに、それまで出てきたエピソードや、新しいエピソードで「偶然についての構造」が解説されていく。この種明かし感はその辺の推理小説より全然面白い。

また、筆者は13日の金曜日生まれであることに興味をもち、「13日の金曜日が持つ意味」について統計的な視点から分析したくだりは、「そんな見方があるかー」と感心してしまった。

みんな目の前のできごとに、過剰に”意味”を見出したいんだけど、実際にそんな全てのことに意味があるのはフィクションの世界だけであり、ほとんどのことはたまたま偶然起きたにすぎない、ということが書かれていく。またその一方で明らかに統計的に優位な差が出ていることについては、それが何か、ということが解説される。

特に、中盤で出てくる宝くじのエピソードなど、筆者は”引き”が強すぎて、それこそ何らかの超自然的な力が働いてないか？と疑ってしまうほどだ。

そして、後半はスポーツや、犯罪、占星術など、さまざまなエピソードを元に、それが統計的に有意差が有るか無いか、つまりそれを引き起こす原因が有るのか、たまたまそうなっただけなのか分析する様子が語られていく。

統計の本といっても豊富なエピソードに基づく事例集になっているので、非常に読みやすく、語り口も分かりやすく、さっと読める。この本を一冊読み終わる頃には、いろいろな出来事に対する見方が、ちょっとだけ変わっているに違いない。そして自分の人生のこれまでを振り返る時にも、ちょっと解釈が変わっているかもしれない。

これまで起きたことが”必然”だったのか、”偶然”だったのか、振り返ってみてください。

magnoliak🍧 (@magnolia_k_) | Twitter

『達人プログラマー第2版』のKindle版が出てたので今すぐ読んだ方がいいです

達人プログラマー ―熟達に向けたあなたの旅― 第2版

達人プログラマー ―熟達に向けたあなたの旅― 第2版

昨年末に出版された『達人プログラマー第2版』、確か紙の本がリリースされた時はKindle版が出ていなかったと思うけど、今見たらKindle版も出ていたので、みんな今すぐ読んだ方がいいです！

必読！というか、今すぐ読まなくても、どこかで必ず読んで「なるほどー」って時期がくるので、一家に一冊、一人に一冊レベルで確保しておいた方がいい名著です。

昨年書いた紹介エントリは、以下のエントリをご参照ください。必読です！

blog.magnolia.tech

『理科系の作文技術』を久しぶりに読み返し、とにかく「6 はっきり言い切る姿勢」「7 事実と意見」だけは絶対にみんな読んだ方がよい、と思った

理科系の作文技術（リフロー版） (中公新書)

理科系の作文技術（リフロー版） (中公新書)

いまさら紹介するまでもないけど、とりあえず作文方法を学びたい時は、まずはこの「理科系の作文技術」を読むことをお勧めする。

最近ブログのエントリをざっと書いてそのまま公開してしまうことが多かったので、少し反省し、それを直すためにこの本を改めて読み直した。そうしたら、タイトルで全部言い切っているのだけど、とにかく「6 はっきり言い切る姿勢」「7 事実と意見」だけは絶対にみんな読んだ方がよい、と思った。

日常的にメールや、ブログの記事など、それなりの量の文章を書くことが多いけど、論文や雑誌の記事など、きちんと他人の目を通した上で公開される文章を書くことは、まずない。一度だけ、雑誌の記事原稿を書いたとき、自分なりにかなりの推敲を重ねたつもりでも、プロの編集の方から見れば言葉使いや、言い回しなど、たくさんの指摘をいただいた。おかげで、普段自分が書いている文章にフィードバックすることができ、少しはレベルが上がったと思う。

その時にも、やはり読み返したのがこの『理科系の作文技術』だった。過去に何度か、いろいろな人からこの本を紹介されることが有り、その度に読み返している。

『理科系の作文技術』は、タイトルに『理科系の』とついてはいるが、必ずしも論文のようなアカデミアで書かれる文章だけでなく、ビジネスの報告書でも使えるポイントが多数解説されている。

前半の「2 準備作業（立案）」や、「3 文章の組み立て」あたりは、ビジネスで書く文書は、量もそこまで多くなく、そもそも書く目的や、内容がある程度決まっているので、論文や、本の執筆のように「そもそも何を書くか」「どのように材料を集めるか」というところから出発することは少ないので、ちょっと退屈というか、そんな大作は書かないし……という気分になるのだけど、そのまま読み進めていって「6 はっきり言い切る姿勢」「7 事実と意見」に差し掛かると、普遍的で、とても重要なことが書かれているので、まずはここを読むことをお勧めする。

6 はっきり言い切る姿勢

報告文書だったり、ソフトウェアの解説ドキュメントなど、本来「相手に正しく理解してもらう」「理解してもらった上で何らかの行動・意思決定を促す」ための文書において、結論があいまいなことを書かれても読む方は困ってしまうが、意外とそのような書き方になっている文書は多い。「結論はどこだっけ？」というのは、レビューで言ったことも、言われてこともたくさん有るはずだ。

本書では欧米と日本の比較、日本人の心理的な傾向からはっきりと名言しない傾向が有るころを解説している。

最後の方にこう書かれている。

私たちは，無意識のうちにぼかしたことばを濫用する習癖をもっている.仕事の文書のなかでは，「ほぼ」，「約」，「ほど」，「くらい」，「たぶん」，「ような」，「らしい」，……の類をできるだけ削ることも大切な心得の一つだ.

確かにこれだけでも気をつけると大きく変わる。

また、英語の「ステート」が“明確に表明する”という意味であり、それに類する言葉が日本語にないことも触れられていて、最後は“ステートするときには当然，一句一句に責任がともなうのである.”と締められていて、改めて文書を書くときの姿勢について考えさせられた。

7 事実と意見

意外と、”事実”と、”意見”が混在し、きちんと分離されていない文章は多い。報告書のレビューなどで「まず事実はどれ？」と聞かれたり、聞いたりしたことはよく有るのでないか。

本書では「意見」は幅広い概念で、その中には、「推論」「判断」「意見」「確信」「理論」が含まれるとしている。確かに意外と広く、そのような観点で見返すと、自分が書いた文章が「事実」と「意見」を適切に分離しているか、客観的にみることができる。

また、色々な例を持って、事実と意見を分離して書く方法が解説されている。

事実と、意見は、自分の中では区別されていても、いざ文章として書こうとすると混ざりがちなので、まずは一度メモなどに書き出すなどして、最初から分離する工夫をしないとすぐに混ざってしまうので、気をつけたい。

おわりに

どんな文章も一気に書いて、振り返りもしなければ、必ずよく分からない文章になってしまうので、自分でも常に以下のような工夫をしている。

  • 想定する読者の気持ちになって読み直す
  • 声に出して全部読んでみる
  • 紙に印刷し、別の部屋で読む(環境を変える)
  • 赤ペンを持ちながら読み、読み終わったところはチェックする

ただ、改めてそもそも書く前の準備や、書き方の姿勢といったところから見直していきたいと思った。

magnoliak🍧 (@magnolia_k_) | Twitter

知りたいことが有れば、勉強会を開いてみるといい…いや知らないから開いてみるといい

noteからの転載

f:id:magnoliak:20210122230240j:plain   吉祥寺.pmという勉強会をここ7年ほど運営している。

kichijojipm.connpass.com

「地域名」＋「pm」という形式の勉強会は、昔はたくさん開催されていて、主にPerlの話題を扱う勉強会、という意味になる。つまり、吉祥寺.pmは、吉祥寺で開催されるPerlの勉強会、という意味になる、本来は。

トーク15分、LT5分で、だいたい10件ほどの登壇枠を用意しているけど、最近はPerlの話題は1件〜2件になっていて（まだ有るのか！という話はさておいて…）、Java, Go, PHPなど、色々な言語や、プロダクトマネージャー、採用などなど…話題の幅は広がり続けている。

正直、運営も事前にどんな内容が話されるのか把握していないし、当日聞きながら「へー」と驚くことばかり。

とはいえ、最初はPerlのことをもっと知る機会が欲しい、必ずしも開催される勉強会に行くだけでは自分が知りたいことが必ず知ることができるとは限らない、だったら自分でテーマを決めた勉強会を開催すれば知りたいことを知ることができる…という動機だったことを、昨日始めるきっかけの話をしながら気がついた。

勉強会の主催者が一番そのテーマに詳しい必要は全然なくて、むしろ知らないからこそ始めるのが動機になりやすいと思っている。知っている人は始める必要無いし。

という訳で、知りたいことが有れば、それをテーマに勉強会を開くといいという話でした。

『グッド・マス ギークのための数・論理・計算機科学』を読みはじめた

グッド・マス ギークのための数・論理・計算機科学

グッド・マス ギークのための数・論理・計算機科学

もうずいぶん昔、大学のコンピュータサイエンスの学科に通っている人に「どんな勉強をしているのか？」と聞いたら「数学」と返ってきて、「なんで？」と疑問に思ったことがある(その後、理由は身を持って理解した)。

”数学”、コンピュータを扱う上では切っても切れないけど、どこから手をつけたら良いか分からない人向けの1冊。目次を見てみると分かるけど、わずか280ページに全部詰まっている。と…言いつつ、買ったことを完全に忘れて、カバーをかけたまま本棚に眠っていたのを今日発見した。

必ずしも順番に読む必要がなく、一つ一つが独立しているのも読みやすい。おすすめです。

主要目次

“Good Math” 推薦の声

前書き

第I部 数
第1章 自然数
1.1 自然数を公理的に語る
1.2 ペアノの帰納法を使う

第2章 整数
2.1 整数とは何か？ 
2.2 整数を自然に組み上げる

第3章 実数
3.1 実数を形式ばらずに
3.2 実数を公理的に
 実数の公理、第1部 ：足し算と掛け算
 実数の公理、第2部 ：順序
 実数の公理、第3部 ：連続性
3.3 実数を構成的に

第4章 無理数と超越数
4.1 無理数とは何か？ 
4.2 無理数に「あ゛ー！」となる瞬間
4.3 何を意味していて、何が問題なのか？ 

第II部 変わった数
第5章 ゼロ
5.1 ゼロの歴史
5.2 イライラするほど難しい数

第6章 e：自然数でない自然な数
6.1 至るところにある数
6.2 歴史
6.3 e に意味はあるの？ 

第7章 φ：黄金比
7.1 黄金比とは何か？ 
7.2 伝説的なたわごと
7.3 黄金比の本当の住処

第8章 i：虚数
8.1 i の生まれたところ
8.2 i の働き
8.3 i の意味

第III部 数を書く

第9章 ローマ数字
9.1 位取りの体系
9.2 どうしてこうなった？ 
9.3 算術は簡単（でもそろばんならもっと簡単） 
9.4 こうなったのは伝統のせいだ

第10章 エジプト分数
10.1 4000 歳の数学試験
10.2 フィボナッチの貪欲アルゴリズム
10.3 時に美しさは実用性に勝る

第11章 連分数
11.1 連分数
11.2 すっきりしていて、明快で、ただただ楽しい
11.3 算術計算

第IV部 論理

第12章 ミスター・スポックは論理的じゃない
12.1 それでは論理って何なのでしょう？ 
12.2 FOPL、論理的に
12.3 何か新しいのを見せて！ 

第13章 証明に、真実に、木：おおこわい！ 
13.1 単純な証明を木で組み立てる
13.2 無からの証明
13.3 家族のすべて
13.4 分岐のある証明

第14章 論理でプログラミング
14.1 家族関係を計算する
14.2 論理で計算
 Prolog でペアノ算術
 Prolog のクイックなクイックソート

第15章 時間がかかわる論証
15.1 時間と共に変化する命題
15.2 CTL はどんなふうに役に立つのか？ 

第V部 集合

第16章 カントールの対角化：無限はただ無限なんじゃない
16.1 集合（素朴に） 
16.2 カントールの対角化
16.3 単純にしておくな、この間抜け

第17章 公理的集合論：長所を残して、短所を捨てる
17.1 ZFC 集合論の公理
17.2 選択公理の狂気
17.3 なぜ？ 

第18章 モデル：数学の世界のレゴブロックとして集合を使う
18.1 自然数を組み立てる
18.2 モデルからモデル：自然数から整数、そしてその先へ！ 

第19章 超限数：無限集合の数え上げと順序付け
19.1 超限基数の導入
19.2 連続体仮説
19.3 無限の中のどこ？ 

第20章 群論：集合の対称性を見つける
20.1 謎めいた対称性
20.2 いろいろな種類の対称性
20.3 歴史に立ち入る
20.4 対称性のルーツ

第VI部 機械じかけの数学

第21章 有限状態機械：単純だけどすごい奴
21.1 最も単純な機械
21.2 有限状態機械が目を覚ます
21.3 正規表現から有限状態機械への橋渡し

第22章 チューリング機械
22.1 テープがあることがとても重要
22.2 メタへ行く：機械を真似する機械

第23章 計算の病理学と、その心髄
23.1 BF の紹介：偉大で見事な完全なるおちゃらけ
23.2 チューリング完全か、さもなくば完全に無意味か？ 
23.3 至高から滑稽へ

第24章 計算：違う、ただの計算じゃない ― λ計算だ
24.1 λ計算を書く：プログラミングも同然！ 
24.2 評価：動作せよ！ 
24.3 プログラミング言語とラムダの戦略

第25章 数、真偽値、そして再帰
25.1 でもそれってチューリング完全なの？ 
25.2 数を計算する数
25.3 選択？ チャーチに戻ろう
25.4 再帰：ナンデ・ナンデ・ナンデ？ 
 再帰を理解する
 λ計算の再帰

第26章 型、型、型：λ計算のモデル化
26.1 型と遊ぶ
26.2 証明するんだ！ 
26.3 なんの役に立つのか？ 

第27章 停止性問題
27.1 輝かしい失敗
27.2 止まるべきか、止まらざるべきか？ 

訳者後書き

参考文献
索引

その他、オライリーから出ているこの辺りの本も、ぜひ読んだ方がよい。

アンダースタンディング コンピュテーション ―単純な機械から不可能なプログラムまで

アンダースタンディング コンピュテーション ―単純な機械から不可能なプログラムまで

  • 作者:Tom Stuart
  • 発売日: 2014/09/18
  • メディア: 大型本

計算できるもの、計算できないもの ―実践的アプローチによる計算理論入門

計算できるもの、計算できないもの ―実践的アプローチによる計算理論入門

  • 作者:John MacCormick
  • 発売日: 2020/12/24
  • メディア: 単行本（ソフトカバー）

コードの意味、意図や重要性を読み取る

noteからの転載

コード自体は等しく平等だけど、重要性は人間が見出さないといけない、という話。

でもひょっとしたら、いつの日か、実行時に使われるコードや、分岐の判断結果などで、重要度を見出す、みたいな研究も進むかもしれない（もう有る？）。

品質保証の観点で、ドメインエキスパートが指摘する「この機能が一番重要、こっちの昨日はまず使われることは無い、さらにこの機能は過去に一度も動いたことが無い」みたいな話を解析してくれる仕組みが有ればいいのに。

シンタックスハイライトは、コードに対して文法に応じた色づけをしてくれる点で画期的な発明なのだけど、残念ながらコードの“意味”や、”意図”、"重要度"までは表示してくれない。

ロジックの順序や、スコープの切り方で意味や意図を見いだしやすくすることはできるし、コメントや変数名、メソッド名に直接的にそれを込めることは、できる。

だけど、最終的には意味を見いだすのは人間側だし、その時点で読み取りたい内容は異なってくる。

例えば、人事システムで過去にM&Aなどで社員に移行登録された人を示す特別なフラグが有り、評価や昇給などの判定のために度々そのフラグが使われたとする。M&A直後は該当する社員も多く、そのロジックを通る割合が一定のマジョリティを占めていた…が、月日も経ち、それに該当する社員がほぼいなくなった時、コードの保守性という観点では、このフラグの存在、対応する数々のコードがノイズになってしまう可能性が出てくる、とか。

コンピュータは正直だ。書かれたコードの通りにしか動かない。例外的な対応や、一時的に必要だったコードも、全て等しく「コード」だ。だけど、そこにどう意味を見いだすかは、そのコンテキストによって全然変わってくる。

”どのコードが重要か？”は、極めて主観的で、かつ動的なものであり、客観的に、静的には確定できない。

また、時に非常にトリッキーなコードが、とても短いコードで実にさまざまなパターンに”対応できてしまっている”時が有り、このような時に、”できること”のバリエーションが分からなくなってしまうことも有る。

ざっとコードの流れを知りたいのか、王道ルートのパターンを知りたいのか、特定の条件での処理の詳細を知りたいのか…それら全てに等しく答えられる万能の解は今の段階では無いので、僕らはせいぜい今日もコメントにコードの意図や、表層的には読み取れないパターンなどを補足を書いていくのだけど、いつの日かこれが解決してくれる方法がアッという方向からやってくるのかもしれない。

magnoliak🍧 (@magnolia_k_) | Twitter