Newbeeはいいぞ
Newbee Advent Calendar 2025 12日目の投稿です。 （日を間違えたので遅れての投稿ですが...）
いくおさんの動画を見てやるぞと思ってアドカレ登録したので、投稿遅れてしまったけど書くぞー
どうやってNewbeeを知ったか
まず私が元々newspicksを知っていた経緯で佐々木さんを知る
→独立したと聞いてpivotを見ていて蜂須賀さんを知る
→蜂須賀さんが独立したと聞いてnewbeeを知る
何がきっかけで継続して見るようになったかは曖昧ですが、記憶の中では及川さんの動画だったり
あとはログラスの斉藤さんの、ここで初めて聞いたAIオペレーションマネージャーの回が個人的にはめっちゃ面白くて以降ずっと見るようになった気がします。
この動画はAIオペレーションマネージャーの話を通じて、事業のバックキャストとかアービトラージに対する考え方、これも初めて知りましたが「両利きの経営」の深化と探索の実践などログラスという企業の事業運営の奥行きを知ることができたのもすごく良かったなと思いました。
特に良かったと個人的に思う動画
これ以外ももちろんたくさんあるのですが独断と偏見でピックアップさせていただきます。
【ふりかえりの本質】ふりかえり = 反省会の誤解 / 地獄の反省会を“神回”にするふりかえり術 / プロジェクトのふりかえり設計法 / マンネリ回避に必要な思考法 / 忙しすぎるチームの、最初の一歩
今までやってた振り返りとはなんだったのかと思ってしまうぐらい、目から鱗過ぎました。
問題解決のために振り返りをしていると思ってたが、それはhowの一つであり、本来の目的はより良い未来を描くことだったんですね。
早くこれはやらねばと思い、直近で新規事業の振り返りをやる予定があったのでnotebooklmに読み込ませてまとめて同僚に共有しました。普通にやるとかなりお通夜になりそうな振り返りできたが、もちろん反省もあるけど色々なチャレンジや学びがあったことに目を向けられて、前を向いて終わることができました。
知っている会社でも「振り返りは苦しいものだ」と教えているところがあるのですが、そう教わってきたしそういうものだと思っている方にこそ見てもらいたいなと思います。
【やり切る意思決定】AI時代何を選び、何を捨てる？ / 意識の外腿裏して検討する方法 / 重要課題を捉える"選別作業" / 最優先事項の定め方 / 現場を知り、ユーザーに憑依する / やり切る行動力
改めて見直しましたがテックタッチ中出さんのやり切る意思決定回も良かったですね。
自分も直近ではお客さんから話を聞いて解像度を高める、やることを絞るを実践しています。
やることを絞るというのは「世界一流のエンジニアの思考法」でもアメリカのマインドセットとして紹介されていました。
お客さんに会うのはめちゃめちゃ重要で、その道何年もやっている人でも一次情報をちゃんと拾わないで会議室だけで仮説を考えてたら簡単にズレた仮説が生まれるし、そのまま突っ走ってしまったらとんでもなく
B/SとP/Lの概念というか構造知っておくのは経営レイヤーの方に受けがいいのでやっておいた方がいいですね。
このB/Sの話を聞きながら、当時（？）VisionalのCTOだった竹内さんのこの記事を思い出しました。
やりきれる人を見極めるためにやっている面接ね話は「人を選ぶ技術」ですね。いい本なので採用にかかわる人は
【Sponsored by UPSIDER】攻めと守りは「忍者と侍」で切り替える / 柔軟性と堅牢性のバランスはどうやって両立するのか / トランスフォーメーションハラスメントに気をつけろ
このUPSIDERさんの動画も良かったなと思いました。 当時はいわゆるモード1をひたすらやっていることに苦しくなる現象を感じていたがそれが何なのかが自分の中で言語化できていない時期があり、ここ数年ぐらいで自分がモード2寄りの人間でありモード1の人との価値観の違いというのを理解できるようになってきたのでこの動画をもっと早くに見たかったなーと思いました。（そしてこれがさらに2015年にガートナーがバイモーダルITと名前をつけていたのも初めて知りました。）
これって例えば現職において自分がどちら寄りのキャラクタであり、自分や現職のチーム、あるいは転職先での期待値がどっち寄りなんだっけというのを意識できると（受け入れ側も含めて）ミスマッチが減りそうだし、「忍者」と「侍」をちゃんと組織として分けるのはやはり大事だよねというのはとても同感です。現職でも「侍」の既存事業と「忍者」の新規事業のチームは分けた方がいいと意見して意図的に分けています。
最後に
来年もよろしくお願いします！
個人的には経営・役員レイヤーの方が出る動画はとても好きで、経営・役員レイヤーの方々がどういったことを考えているのかというのは現状の自分にとっては二段上の抽象度の話ですがその抽象度の視座を知っておくことはとても重要だと思っているので来年もたくさん投稿してもらえるといいなと勝手に思っています！
Obsidianでtemplateから作成したNoteを任意のディレクトリに移動するスクリプト
前提
Templater pluginを入れることが前提になっています。
解説
コマンドパレットを開いて（macOSならcmd+P）Templater:Create new note from templateを選択し、対象のtemplateを選んだ後に実行されます。
// このテンプレートのルートフォルダ（このフォルダが起点になる）
const folder = "Notes";
const path = await tp.system.prompt("titleは？")
const dirs = path.split('/');
const title = dirs[dirs.length-1];
// 全てのディレクトリ部分だけ取得して並べ替える
const allFolders = [...new Set(app.vault.getAllLoadedFiles().filter(item => item.parent && item.parent.path.startsWith(folder)).map(item => item.parent.path))];
if (allFolders.length === 0) {
new Notice("このフォルダにはサブフォルダがありません。");
} else {
const selectedFolder = await tp.system.suggester(allFolders, allFolders);
if (selectedFolder) {
console.info(`選択されたフォルダ: ${selectedFolder}`);
console.info(`移動先:${folder}/${selectedFolder}/${title}`);
await tp.file.move(`${selectedFolder}/${title}`);
tp.hooks.on_all_templates_executed(async() => {
const file = tp.file.find_tfile(tp.file.path(true));
await app.fileManager.processFrontMatter(file, (frontmatter)=> {
frontmatter["title"] = title;
});
});
}
}
課題としてはフォルダが増えるとフォルダ選択がめんどくさくなりそうというのと、例えばnote名を入力してフォルダ選択をする前にやっぱやーめたってするとUntitledが作成されてしまう。（後者は回避する方法あるのか？）
参考
11月第2週
本
ベイズ周りをやっておいた方が良さそうで買ってみた。
会社でAmazon Sagemakerを使っているが、JupyterLabを起動するEC2インスタンス以上の使い方ができていないのでちゃんと使い所を理解しておきたい。
あと直近データ分析後のレポーティングとかビジュアライゼーションで困っているので。
将来的に数理統計学をちゃんとやろうとした時に、確実に数学で詰む可能性があるので買った。せめて統計検定準一級は欲しいよね。
大学
Rで学ぶ確率統計は終わった。難しくない。回帰分析はやらなかった。
情報ネットワークはハブ・ルーター・ADSL・FTTH・CATVあたりをやった。マスタリングTCP/IPをやって既出なものも多かった。 FTTHの種類とかあるんだ。
その他
モニターがちょっと古くなってきたのと毎日とんでもない時間画面を見ているのでどうしても目が疲れるので、根本的には休憩なんだけどできるだけ目に優しくしたいのでpaperモードがあるFlexScan ev3450xcを購入。
10月第1~3週
ブログ更新頑張ります。目指せ週一。
読んだ本
サンプルサイズの決め方
2つの母平均の差の検定のサンプルサイズの計算方法を確認していました。
サンプルサイズの計算式をサクッと見るぐらいだったのでそんなに内容を理解できているわけではないので、詳細の理解はこれからの宿題になります。
統計学入門
t検定や仮設検定自体の確認で読んでました。だいぶ理解できるようになってきた気がするので、どこかでちゃんとアウトプットやっていきたい。
A/Bテスト実践ガイド
ここ最近ずっと読んでいる。これを読んでからA/Bテスト設計したかった。（今の所A/Aテストは成功しているので大丈夫であってほしいが。。。）
気になったやつ
Welchのt検定のやり方
調べているとWelchのt検定を行う前にF検定をしている記事がたまにあります。Welchのt検定自体が等分散性を前提にしていないのとF検定をしてさらにt検定すると多重検定になってない？と思いましたがあってそう。
結局Welchのt検定の方がStudentのt検定よりも頑健なので、t検定なら迷わずWelchの方で良いなという理解をしている。
あとscipy.stats.ttest_indでequal_var = Falseにしているので内部的に実行しているのはWelchのt検定なのにStudentのt検定の自由度をそのまま使っている人もいた。
MMMのOSS
LightweightMMMを実践データで使ってみた感想 - DMM inside
MMM(Marketing Mix Modeling)のOSSとかあるのか。
読みたい
ティール組織 ― マネジメントの常識を覆す次世代型組織の出現
現職のチームに似たものを感じるので何か得られるものがないか。
詳解システム・パフォーマンス
ISUCON出る予定なので。初手はISUCON本読んだ方がいいかもしれない。
解像度を上げる
事業に対する解像度を今以上にもっと上げないといけないなと思うので。
9月読んだ本
Pythonで学ぶ効果検証入門
業務で効果検証ちゃんとやっていきたいと思い、forkwellのライブでやっていたのを思い出して購入した。A/B テスト難しいという感想になったし、この本を読んだだけでそのままA/Bテストできるとはならないなーと思った。（たとえばサンプルサイズをどう決めるかは本書では踏み込んでいない）
ライブで言ってたように一人では厳しいので誰か2読んでもらって議論できるような状態になりたいと思うなど。
統計学入門（赤本）
これも読んでる。
6年前は全然分からなかったのが今はそれなりに理解できるようになったので進歩を感じる。
解像度を上げる
ミクロでの課題解決の質（エンジニアリング観点での課題解決）は現職でなんとかなっている気がするが、より広く課題解決の質を高めること課題自体にたいする理解を高める必要性を感じて読んでる。kindleで読んでるがなかなかボリューミーてまだ読みきれてない。
ちな書籍の表示のこれは解像度ではない。
以下はふと気になって読んだ小説。
舞姫は原文は昔国語の授業でやったところは理解できるが他はふわっとしか分からなかったので現代語訳に頼った。
F欄大学文系からソフトウェアエンジニア6年目の振り返りと現在
2023年Advent Calendar集まれ文系エンジニア！25日目の投稿です。
この記事は自分自身が真のF欄大学を、それも新卒就活をせずに現在6年目のソフトウェアエンジニアとして生き延びている軌跡を書き記したものです。
これまでの自分のやってきたことと現在地を踏まえ、それぞれのフェーズでどういったことを気にして生き延びてこられたかを考えようと思います。
とりあえずAdvent Calendar書こうと思って書いたのでちょっと（？）散らかっているかもしれません。
一部でも誰かの参考になれば幸いです。
前提
まず私がどのような生い立ちで人間であるかです。
- 東京都23区の西の端が実家
- 実家は中ぐらい？（リーマンショック以後自分が大学生の頃は大体700ぐらい、その前は+200ぐらいはあったみたい）
- 父がエンジニア（ただし何も教わっておらず、自分がエンジニアになるまで職業を知らなかった）
- 母はフルタイム→弟が生まれた後はパートタイムで介護職とかやっている
- 中学は少しだけ勉強した（自称進学校ぐらい）
- 高校は本当に勉強せず無事F欄大学へ入学
- 色々あり新卒就活せず
- 1年フリーター後に大学院受験で落ちてエンジニアとして就職
ここで東京都23区に実家というのを見て帰らないでください！確かに実家が東京23区内にあったのは幸運でしたが、それとは別にも参考になることもあるかもしれないのでブラウザバックせず見てもらえればと思います。
大学生から現在に至るまで
大学生
高校生であまりにも勉強しなかった結果、ほぼ全て落ちてF欄大学に行くこととなりました。たまたま前職で一人先輩がいました。
入学当初は二人ほどたまに話す程度の知り合いはいたものの、当時はインターネットで知り合ったヲタクとずっと遊戯王で遊んでいたのもありだんだん疎遠になって最終的には大学の知人は文字通りゼロになりました。 そんなこともあり大学に馴染めず、適応障害になって授業に行けなくなった時期もありましたが、なんとか治療していけるようになり卒業しました。
ひどい大学でしたが学問を修めると言う観点では様々な気づきと知見を得ることができました。ここでの学びからクルーグマン教授の経済入門を読んで、以降経済学にを研究したいというモチベーションへとつながることとなりました。
しかしその時期が大学3年も終わりの時期で、すぐ院試を受けるか就職するかでしたが
就職したところでこんなF欄大学の新卒の行き場なんてよくわからない企業に行く羽目にしかならなそう
そもそも就職とかしたくないと言う甘え
変に就職するぐらいならある程度時間が守られるバイトをしながら学費を稼いで、その間に勉強もして受験した方がいいのでは
と言う理由と、1年~2年あたりの適応障害で相当数の単位を落としたのが理由で単位も取りまくって卒研もやらなければならない事情もあり、卒業後に諸々やって行くこととなりました。
フリーター時代
全く自分では遊ばないけど時給がいいのでパチ屋のアルバイトをしていました。朝もそこそこ早いのと慣れると楽、忙しい時間帯はほぼフロアを走っていることもあるので運動不足解消にも一役買っていたかもしれません。
この時期はバイトをしない時間はほぼ勉強していました。
無職時代
ちょうど一年バイトしてお金も貯まって勉強のラストスパートのためバイトを辞めました。それでも結局TOEFLはSpeakingとWritingがボロボロで全然使える点数が取れなかったので語学学習は本当に向いていないかもしれません。
結局TOEFLのスコア提出がいらない京大・北大・東北大の公共政策大学院を受験し、京大は一次は通過しましたが二次で落ちました。しかもボーダーで落ちた（京大は後で試験の成績と順位を問い合わせたら教えてくれる）のでとても悔しかったですが、今では特に後悔はありません。
そしてこの頃、Rによるやさしい統計学を読んでいたので多少プログラミングの経験があり、Pythonもちょっとだけ触っていたので「落ちたらプログラマーにでもなるかw」と漠然と思っていました。
そして見事落ちたのでプログラマーになることに決めました。プログラミングと就活両方を無料でサポートしてくれると言うことで確か10月ぐらいにUZUZカレッジに話を聞きに行きました。
Javaをやると言うことで帰り道に池袋のジュンク堂でスッキリわかるJava入門・実践編・サーブレット&JSP入門を買い、以前からやっていたProgateと合わせて勉強していました。
現在は動画講義だと思いますが（最後に見に行ったのが2019年とかだった気がするので確証はない）当時はオンサイトで目の前で教えてもらっていました。
webの所謂な掲示板を作って、その後は面接対策を行いなんとか年明けてだったか内定をいただきました。
あとこの頃はPythonが好きだったのとLinuxにも興味がありVagrant+VirtualBoxで仮想環境を構築してPythonでDjangoをherokuにデプロイして遊ぶと言うのをやっていました。
この面接対策は今でも生きていて
- ハキハキと話す
- 結論から話す
こう言うのは駆け出しであろうがなかろうが変わらないと思いました。
あとはちゃんと自分の主張に対して、相手が腹落ちできるようなストーリーと理由をつけると言うのも今もやっています。
Railsでポートフォリオ作るぐらいならちゃんと面接対策しましょう。
一社目
晴れて正社員エンジニアとして岩本町にある会社に就職することとなりました。
結論としては三ヶ月で退職することとなるのですが、前提として自分ももう少しできることがあったなと言う認識があり反省があります。
入社してすぐに受託開発をやることとなり、とりあえず技術選定をしてと言われます。駆け出しにそんなことできるはずもなく、Javaの方が詳しいけどC#の会社なのに急にJava使ったらやばいだろと思って今まで使っている技術資産があるからと言うことでC#とAngularJSでどうでしょうかと提案しました。（今考えるとあれは何の意味があったんだ？）この頃Angular自体も初めて知ったのですが、どうやらAngularはver1とver2でだいぶ違っていて、Angular2の方はTypeScriptを使っているしこちらの方がモダンらしいと言うことで業務外ではAngular2で遊んでいました。
そして実質一人でC#とAngularJSを使ってWebアプリケーションを作ることとなりました。C#がJavaと似ているからってそんなに書けるはずもなく、MyBatisとMyBatisの社内ラッパーも使い方もよくわからんしOJTどころかただのOJでとんでもないストレスに苛まれていました。最終的にIISに公開するのも紙ペラ一枚だけ渡されて何が何だかわからず、めっちゃ業務委託の中国人のお兄さんに聞いてなんとか予定通り一ヶ月ぐらいでリリースできました。本当にしんどかったですね。
そしてここは書けないですが、端的に言えば雇用契約書と言ってることが違うじゃんという事態が発生し、契約書を巻き直すことになりました。この辺であまりにも意味がわからず転職エージェントに相談して、奇跡的に内定をもらったので3ヶ月での退職となりました。
二社目
業界ではかなり大きめのSES企業でした。
ここでも最初の現場が全く合わず、最初はオフィスの最寄駅の手前で体調が終わるのが最終的にベッドから起き上がれなくなるぐらい体調が悪くなってしまい抜けることとなりました。
その後は日○の孫会社に出向し、Java+AngularJS+SVNで色々不満はありながらも比較的まともな開発ができるようになりました。
めちゃめちゃ不満があるほどではなかったですが、ここではパブリッククラウドに触ることもできないしモダンフロントエンドを業務で触ることも難しいということで転職活動を行い、無事現時点での前職から内定をいただきました。辞める時に現場の上司の方が、当時やっていた統合テストが終わったらもう少し腰を据えて開発経験ができるところに異動させようと思っていたらしいです。
最終的に三ヶ月と九ヶ月で合計一年在籍していました。
今となってはこの九ヶ月が一番色々やっていた時期で、プライベートでほぼ誰とも会ったり遊んだりせずひたすら何かをしていた気がします。（DjangoやVueやAWS、Pythonのwebフレームワークを自作しようとしたりScalaとPlay Frameworkとか本当に色々でした）
三社目
こちらもSES企業でしたが、エンド直か二次請けの商流が浅いところでした。
転職時の期待はほぼあっており、一部よくわからないのはありながらもLaravel+Vue.js+AzureやTypeScript+Next.js+MySQL+GCPなどでの0→1フェーズを経験することができました。ここでフロントエンドからインフラまで一貫して携わったり、テストコードの導入や自動化などの旗振り、Terraformの導入、クライアントの新卒の育成など様々なお手伝いをさせていただきました。
エンジニア採用にも携わるようになり、（前職のレベル感故かもしれませんが）基準の高いエンジニアの少なさと面接が下手なエンジニアの多さというのもここで知ることとなりました。
一定満足していましたが、結局何かを変える時って成果はクライアントの熱量を超えることは無いので、今自分がやっていることに対して虚無感のようなものを感じるようになりました。（この辺は日本のDXというものに対しても近いものを感じていますがここでは割愛）
最終的にはその企業の中にいないと難しいと思うこととなり、そうなると
そもそも事業会社がどんな感じなのかもわからない
かといって儲かっていない事業会社はただの地獄なので踏みたくない
次の選択肢はかなり重要だという直観
ということから、退職してフリーランスをして内部を見て考えるという方針にしました。
フリーランス時代
ありがたいことにTwitterで次の職を募集したところ、多くのお声がけをいただきました。面接も並行でしながら、フリーランスでたくさんのお客様のお手伝いをさせていただきました。特にフリーランス初期は書類周りや業務の進め方がなっていなかった点が多々あり、初期にお手伝いさせていただいていた企業様には大変ご迷惑をお掛けしたと思います。この場を借りてお詫び申し上げます。
この頃はGraphQLやったりGoやったり
フリーランスをして
一方でスキルと時間の切り売り感は否めない（企業によるが面白い仕事は社員に行きがち）
目安としてテックリードとかマネージャー相当のスキルがない状態で長くやると、リーダー・マネジメント経験がないのにまあまあ年齢が高い人が出来上がってキャリアが詰む可能性が上がる
という感想を持ちました。
こういったことを身をもって感じたり書類・税金に多少詳しくなったり、色々な会社を見ることができたのでやってみて良かったと思います。
また自分がマネージャー相当の職位を経験したらどうなるかも気になるのでやっていみたいですね。
この期間に転職活動も行い、最終的には当時フリーランスでお世話になっていた企業にそのまま入社することとなりました。
四社目（現職）
決め手としては
事業について高い解像度で解釈を伝えてくれたり会話ができる人がいる
大規模広告配信
チームで自分が明確にポジションを持てる領域が存在しており、そこがチームの課題になっている
相対的に色々整っていない（気がする）
といったところから現職に決めました。
まだあまり書けることはない（様々な理由で）ですが、技術負債の解消だったりアドタグ周りの改善、外部連携など色々やっています。
技術的にはGoにPythonに業務で触ることはあまりなかったAWSと関わり、所謂なWebフロントエンドアプリケーションとは違ってそのままのブラウザと向き合うこともしています。
タスクマネジメント・プロジェクトマネジメントみたいなのは苦手ですが、エンジニアが少ないのもあり一人一プロジェクトでやっているので昔よりはマシになっているかもしれません。
来年は自分から提案した取り組みをやるかもしれないのと事業に対する解像度をさらにあげていきたいですね。
来年度からは放送大学に入学して、学位授与機構を使って情報工学の学位を取ろうと思っています。
現在地のスキル
だいたいこの辺をやっています。
順番は特に関係ないです。
言語・FW
TypeScript、Express.js、React.js、、Vue.js、Go、Python、Laravel、Rails(嫌いだけど)
最近はソフトウェア設計方面に重心を重心を置こうとしている。
DB
ただしそれぞれの仕様について特別詳しいとかではない
Public Cloud
Cloud RunとBigQueryとかはまあまあ使っている。AWSは現職でちゃんと使うようになった。
DevOps
Terraform、GitHub Actions、Jenkins、Renovate、Airflow
Terraformが最高。GitHub Actionsもめちゃいい。
各フェーズの生き残りスキル
駆け出し
ポートフォリオを作らない
よくあるプログラミングスクールでRails教えたりポートフォリオ作らせたりするを虚無だと思っているのでここについて書くとそれだけで記事にできてしまうのですが、ざっくり書くと
ポートフォリオ（ここではとりあえずなんか作ったアプリケーション）はストーリーがないので評価しにくい
ポートフォリオを作っている時間があるなら面接対策してさっさと就職した方がいい（他職種で実績がある人はともかく、ほとんどの駆け出しは対等なテーブルに立てない）
といった理由です。
とにかく面接対策
駆け出しエンジニアはそもそも企業と対等な立場では無いので、とにかく潜り込んで経験年数を早期に獲得するのが至上命題だと思っています。
面接対策は同じスキルでも採用担当者からの見え方が変わりますし、今後のキャリアにおいても効いてくるのでちゃんとやりましょう。
1年目~3年目
自分のスキルよりちょっと上をいつも試す
自分のできることの少し上を常に試してみましょう。
自分の場合は1年目ではソフトウェアテストについて勉強してエクセルテストの時に提案をしてみたり、足りていないテスト項目を自分で試してみて未知のバグを見つけたこともありました。2年目ではソフトウェアテストを自分も詳しく無いけど提案してメンバーと一緒に試してみたり、色々自動化してみたりと何か新しいことを常に取り込んできました。
こう言った習慣が身についている人とそうでない人では大きな差が生まれるでしょう。
設計に携わる
最低限詳細設計、できれば基本設計と呼ばれるフェーズをやるといいと思います。
SIerは無縁かもしれませんが、ChatGPTやGitHub Copilotの出現でエンジニアの頭数が必要になることが減ってくると思っています。現時点で他の外部要因があるにせよ、駆け出しエンジニアや詳細設計しかできないエンジニアの採用は厳しくなっています。設計という行為は何らかのトレードオフに対して技術的な判断が必要になるものであり、機械だけでは直近はできそうにないと考えます。
できればこの期間のうちに駆け出しアーキテクトになっておきたいです。
全体としての所感
F欄しか受からなかった時は人生詰んだと思いましたし、院試の勉強をしている時は貯金が日々減っていく中で落ちたらどうなってしまうのかという不安に苛まれていました。今となっては、給料もそこそこもらえてフリーランスでも月単価税抜80万ぐらいはもらえる（し今後はもっと上げられる余地がある）というのも分かったのでこの業界でしばらくはやっていけそうな安心感があります。
やはり世の中エンジニアの適性が明らかに無い人も多いです。 適性の有無をどう考えるかで言えば、好きか嫌いかではなく他人よりも楽しているのに評価してもらえるものが適正だと考えています。自分は今でも休日に暇さえあれば色々試してみたりOSSを探してみたりと比較的エンジニアとしての適性があったように思います。
8月読んだ本
業界のお金の流れとかWeb広告の数値の関係性とかを見るのに良かった。
これはこれで興味深かったけどWeb広告の話がほぼ出てこなかったのでちょっとnot for meだった。
イシューからはじめよ――知的生産の「シンプルな本質」eijipress.co.jp
ざっくり読んだ。
まとめとかまあまあ読んでたのでなんとなくは分かっていたけどその通りだったので、ここまで有名になったらわざわざ読まなくても良かったかも。
HSPがどの文脈から発生したか、学術的なHSPの定義と巷で広まっているHSPの認識の相違、HSP周辺の怪しいビジネスの実態などが書かれていて興味深かった。
HSP自体は心理学のちゃんとした研究対象であるらしいが、心理学（さらには経済学との学際分野である行動経済学）の有名な研究が追試に失敗していること、提唱者のエレイン・アーロンが吊り橋効果という胡散臭い実験を行ったアーサー・アーロンの妻らしいのでそもそもHSPという概念自体がどうなのかとは思う。
9月はMySQL関連を読んでいく。
