「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
第七十七回：法則を見つけろ
今日は2022年3月29日です。私は自営業をやっているのですが今月も無事に黒字で終えることができました。そこで頑張った自分へのご褒美として真っ昼間からスパークリングワインを飲んで酔っ払っているのですが、ふと思ったのです。「このベロベロに近い状態でコラムを書いたら、どんなことを書くのだろう（－－？」と。ということで、今回は実験的にベロベロに近い状態でコラムを書いてみます。そのため今回のコラムでは、はじめに3つ言い訳をしておきます。その1、いつもは読んでくれる方をそれなりに意識して書いているのですが、今回はそれが甘い可能性が高いです。その2、一応、自分で読み直して推敲してはいますが、所詮は酔っ払いによる推敲です。誤字脱字や意味のつながりがよく分からない部分がありましたら、あなたの想像力で補ってください。私は信じています、あなたの行間を読む力を！その3、素面に戻った私が読んで「こんなことを書いたんだっ？！Σ（￣◇￣；はずかしっ！（＊ノノ）」と思ったら消します。なかったことにします。ある日突然このコラムがなくなったら「あぁ、そーゆーことね（＝＝；」と察してください。そんな大人の言い訳を華麗にしたところで、今回もゆるく行ってみましょう。超不定期連載「分かりそう」で「分からない」でも「分かった」気になれるITコラムでございまぁす。このコーナーでは、各用語の説明ページでは取り上げにくいIT関連のネタをテーマに、だらだらと思いついたことを書いていきます。みなさんが「あぁ、なんか役に立ちそうな気もするけど、役に立たないかなぁ。でも、もしかしたら役に立つかも」と思える情報を発信できるように頑張ります！
はじめに
栄えある七十七回目のテーマは……ピヨピヨピヨピヨ（ぴよぴよ的ドラムロール）……じゃん！
法則を見つけろ
です。
いつも通りITとは関係ありませんが、どーんまい。
今日は酔っ払っているので、長文を書く体力と気力がありません。
ちゃちゃっといきますよ。
お忙しい人に向けて先に結論を書いておくと、今回のコラムで言いたいことは
その結果を導いた要因を一旦抽象化して一般化しないと再現性がないよ（せっかく経験したのにもったいないよ）
です。
最後まで読んでくださる方は、この結論を知らないことにして読み進めてください。（←ここら辺の文章はコピペで手抜きしています）
ベロベロに近い状態で、思いつくままに書いてみるよ
半分自慢なのですが、私が運営している『わわわIT用語辞典』の月間PV（1ヵ月の間に見ていただいたページ数の合計）は大体300～400万PVだったりします。
もちろん上には上がいることは承知していますが「個人運営の割りには頑張っている方なんじゃないかな？（－∀－ゞ」と自画自賛していたりもします。
さすが私、頑張ってるぅ（自画自賛）。
とはいえ、ですよ。
誰かに「ササキさん、月あたり300～400万PVのホームページを作りたいので協力してください」と言われたら、協力できません。
理由は、そうなった要因を私自身が全く把握できていないからです。
要因を把握できていないのですから当然、再現性もありません。
ですから「月あたり300～400万PVのホームページを作る」という要望には応えられません（応える力がありません）。
一方で「初心者が取っ付きやすい〇〇の分野の解説ページを作りたいので協力してください」と言われたら多分、協力できます。
それがITとは無関係な分野であってもです。
理由は、初心者が取っ付きやすいと思える説明の仕方を（実際に合っているかは別にして）私なりに法則化できているからです。
それでは、どうすれば初心者が取っ付きやすいと思える説明になるのか？
ゼロスさん風に言えば、それは秘密です（－ｂ－）
私が『わわわIT用語辞典』を運営していく中で試行錯誤して自分なりに見出したノウハウなので。
……と素面のときなら言うと思いますが、今は酔っ払いです。
そこら辺の駆け引き的なあれやこれやを考えるのが面倒くさいので言っちゃいます。
酔っ払っているときの私は気前が良いので。
※私に何か面倒くさい依頼をするなら酔っ払っているときが狙い目です。
初心者が取っ付きやすいと思える説明の仕方、それは
簡単そうに見せる
です。
実際に簡単である必要は、ありません。
ポイントは、簡単そうに「見せる」です。
難しく見える説明というのは「頭」の前に「心」が折れます。
「うわー、なんか難しそう（－Ａ－）」と思うと、読もうとする気力がなくなります。
そうなったら負けです。
実際の説明内容がどんなに正確で、どんなに丁寧で、どんなに分かりやすかったとしても意味がありません。
読んでもらえないからです。
逆に言うと「おっ、この説明なら自分でも分かりそうだ」と思ってさえもらえれば、結構ややこしいことを書いても理解しようと努力してもらえるものです。
その結果、本当に理解できちゃったりします。
結果おーらいっ。
世の中には「自分はバカだ。難しい説明は理解できない」と思っている人が少なからずいますが、そう思っている人には2種類いると私は考えています。
それは
１．難しい説明が理解できない人
２．諦めが早い人
の2種類です。
「１．難しい説明が理解できない人」は仕方がありませんね。
難しい説明が理解できない、本当の意味で簡単な説明でないと理解できません。
できるだけ簡単な説明をしてあげる努力が必要でしょう。
ただ、世の中には、ですね。
「２．諦めが早い人」が意外に多いと私は思うのです。
２の人は、本当は理解力があります。
ちゃんと説明を読んで、自分の中で咀嚼できれば、難しい説明だって理解できるのです。
ただ、そこに到達する前に「こんな難しそうな説明、読む気がしねーよ」「こんな難しそうな説明、読んでも理解できないよ」と諦めてしまいます。
その結果、説明を（表面上は）読んでも理解できず「あぁ、自分はバカなんだなぁ」と勘違いしてしまうのです。
ということで、実際に簡単かどうかは別にして、簡単そうに「見せる」ことで「おっ、この説明は分かりやすいな」と思ってもらえる可能性は高くなります。
その結果、読み手の方は書いてある内容を理解しようとする努力を放棄しないようになり、キッチリ読み込むことで本当に理解できちゃったりします。
その結果「バカな自分でも理解できた！分かりやすい説明だ！」と勘違いしてくれたりします。
本当は、説明が分かりやすいのではなく、読んでくれた方が自分の理解力を過小評価しているのですけどね。
誰も不幸にならない勘違いなので問題なっすぃんぐです（－∀－）
ほんでは、どうすれば説明が簡単そうに見えるのか？
それは自分で頑張って試行錯誤して考えてください。
そこまで教えちゃったら、こっちの商売あがったりだよっ！（￣д￣）
……と素面のときなら言うかもしれませんが、今は酔っ払いです。
ややこしいことを考えるのが面倒くさいので言っちゃいます。
説明を簡単そうに見せるための工夫！
パッと思いつく限りですが、私は以下のことを意識しています。
１．読んでいる方が一番知りたいであろうことをさっさと伝える（知りたいことが知れないのはストレスになりますよ！）
２．漢字を減らす（ひらがなとカタカナと漢字のバランス、読んだときのリズムを考えて「漢字」「ひらがな」「カタカナ」のどれにするかを選んでいます）
３．同じ意味なら簡単な言い回しにする（「行う」じゃなくて「する」にするとか。公文書なんかでハッタリをかますときと逆の言葉選びをしています）
４．文字だけじゃなくて絵を入れる（文字が詰まっていると難しそうに見えるから）
５．文字を大きくして行間を空ける（文字が詰まっていると難しそうに見えるから）
６．自分で「分かりやすい」と言わない（「これで理解できないなら、あなたの理解力が足りない」というニュアンスになる気がするから。あと、自分で「分かりやすい」と宣言すると読む側の期待値が上がり過ぎる気がするので。「今から面白い話をします」と宣言すると面白さに対するハードルが上がるのと同じ）
７．他にも何かいろいろある気はするけど、酔っ払いなので思い浮かばないっすぅヾ（≧▽≦）ノ
……ってな感じで『わわわIT用語辞典』は一種のイメージ戦略で勝負しています。
内容の正確性という点では「えへへ……（＾＾;ゞ」な部分もあったりするのですけどね。
幸い「ゴミ情報を増やしやがって！」という声よりも「助かっていますぅ！」という声の方が多いので、心が折れずに運営を続けられています。
かなり話がそれてしまった気はしますが、酔っ払いなのでドンマイということにしてください（と言い訳することで、話の順番とかを考えずに思いつくままに書いています）。
話を戻すと「初心者が取っ付きやすい説明の仕方」については、私は私なりに法則化できています。
だから他の分野（IT以外の分野）でも応用が利きます。
そして、これはかなり重要なことじゃないかなーと個人的には思っています。
あなたにも「これは良い結果になったなー（*´ェ`*）」と思えることや「これは哀しい結果になったなぁ（つд`）・°・。」と思えることがあるはずです。
その経験を、その経験だけで終わりにしちゃうのは、もったいないです。
その結果を導いた要因を自分の中で法則化できれば、今後の人生でかなり役に立ちます。
それじゃー、どうすれば自分の経験を法則化できるのか？
それは
１．その結果を導いた要因を見つけ出す
２．その要因を抽象化することで一般化する
の手順を踏むことです。
まずは「なんで、そんな結果になったの？」な要因を探しましょう。
ささいなことでもいいのです。
かなり限定的な状況における特殊なことでもいいのです。
「あぁ、これがあったから、これになったのね」なことを見つけ出しましょう。
次は、その要因を一般化することで他にも応用できるようにします。
一般化するためには抽象化することが必要です。
この抽象化と一般化のやり方は……酔っ払っていて説明するのが面倒くさいです。
ひとつ例を挙げておくので、あとは行間を読んで推測してください。
ジュンちゃんにスイートピーをあげたら喜んでくれました。
「ジュンちゃんにスイートピーをあげたら喜んでくれた」という具体的な経験を「女の子にお花をあげたら喜んでくれた」と抽象化します。
そこから「女の子はお花をもらったら喜ぶ（かもしれない）」と一般化して（仮説を立てて）、今度はユウちゃんにヒマワリをあげてみる、みたいなのが法則化の一例です。
そんな感じ（－－）ノ
まとめ
今回は
法則を見つけろ
というテーマで好き勝手に語ってみました。
酔っ払いながら語ったので、当社比1.5倍マシで好き勝手に語っています。
今回のコラムで言いたいことは
その結果を導いた要因を一旦抽象化して一般化しないと再現性がないよ（せっかく経験したのにもったいないよ）
です。
何かをやりました。
何かの結果が出ました。
それだけで終わらせるのは、もったいないです。
せっかく経験したのですから、その経験を次にも……は当然として、他の分野にも活かしましょう。
その気になれば、一見すると無関係なところにも、その経験を活かせます。
そのために必要なのは、その経験から得た学びを法則化することです。
法則化する手順は
１．その結果を導いた要因を見つけ出す
２．１で見つけた要因を抽象化する
３．２で抽象化した要因を一般化することで法則化する
です。
ここまでに書いたことは酔っ払いの戯言ではあるのですが、そんな酔っ払いの戯言を読んでくれるくらいには、あなたは優しい人です。
「毒を食らわば皿まで」の精神で気が向いたら実践してやってください（－－）ノ
蛇足な補足
今日飲んでいるのは「ランブルスコ」という種類？のスパークリングワインの750mlボトルです（ほぼ空きました）。
個人的にワインはそこまで好きではなかったのですが、甘口のランブルスコは飲みやすくて気に入りました（*´ェ`*）
ランブルスコの存在を教えてくださった方に、心より感謝申し上げます。
あと、何気に『わわわIT用語辞典』の運営が10年目に入りましてね。
自分なりに「取っ付きやすい説明の仕方」の方法論が見えてきていたのです。
それを誰かに披露したかったのですが、素面の状態だと「おまえ、それは自分の承認欲求を満たしたいだけだろ。恥ずかしいやつめ（－Ａ－）」みたいなツッコミが自分から入ってですね。
書くことに躊躇いがありました。
ということで、お酒の力を借りて、自分なりの「取っ付きやすい説明の仕方」の方法論を披露してみた次第です。
10年後くらいに「10年前にこんなことを書いたけど、あれは考えが足りてなかった。今の私の考えは、こうだ！」みたいなことを書けたら良いな～と思っています。
「どうすれば取っ付きやすい説明になるか？」の検討は、これからも続けていきまっす（－－）☆
P.S.
冒頭で「長文を書く体力と気力がありません」って書いたのに、なんだかんだで長文になっちゃった（－∀－;ゞ
思いつきで始めて惰性で続けている「分かりそう」で「分からない」でも「分かった」気になれるITコラムですが、いかがでしたでしょうか。また何かネタがあったら、ちまちまと更新していきます。コンゴトモヨロシク。
