2026-07-02

わかったつもり ~読解力がつかない本当の原因~ を読んでみた

概要

自分が技術記事や社内ドキュメント、書籍などとにかく日本語で書かれた文章を理解することが苦手だったので何か解決の糸口になるかと思い読みました。

https://books.kobunsha.com/book/b10124320.html

以下要約です。

1章「読みが深まらないのはなぜか」

小学生の教科書を題材に、簡単な文章であれば理解できることを実演しつつ、簡単な質問をワークショップ形式で埋めることで、理解の解像度が浅かったことを読者に気づかせる
「わかった」というのは安定状態であり、それ以上に理解を深めようと思わず読みが深まらない

2章「読みにおける文脈のはたらき」

キーワード「スキーマ・活性化・文脈」
スキーマ
- 我々が持っているひとまとまりの知識
活性化
- 文章を読んだ時、特定のスキーマを自分の頭の中から引っ張り出して適用すること
文脈
- その文章特有の背景
「文脈」が「スキーマ」を引き出し「活性化」することで文章から意味を引き出す
- 「文脈」が異なれば引き出される意味も違ってくる

3章「これがわかったつもりだ」

長文を読んだ時、全体の文章の雰囲気で間違った理解(わかったつもり)のまま読み終わることがある
- センター現代文で100点取れないのと一緒
全体の雰囲気に引きづられて個々の文章の意味をきちんと理解できないまま終わる
「わかったつもり」も「わかった」状態と同じで一種の安定状態なのでこの自己認識を壊すのは難しい

4章「さまざまなわかったつもり」

「わかったつもり」の原因
- 「文脈」と「スキーマ」が明確なことによる文章の読み飛ばし
- ステレオタイプのスキーマ
  - = 先入観
文章から得た情報を分類・整理出来ない場合に発生する「いろいろあるだな」という雑な感想による思考停止状態

5章「わかったつもりの壊し方」

「わかったつもり」の状態であることを自覚する
- 無知の知
自分なりに「何がわかったつもりの状態にしているのか」を考えてみる
- 例. 先入観を持っていないか？, 全体の文章の雰囲気に流されて個々の文章を読み飛ばしていないか？
文脈を交換することで理解が深まり、矛盾や「わからない」状態に遷移する
- 矛盾を解決することで「よりわかった」状態になる
矛盾は忌避するものではなく、文章間のより緊密な関連を作り上げる契機であり歓迎すべきもの
緊密な関連の作り方は「客観的な事実」と「解釈」の2種
- 客観的な事実...データ・常識のイメージ
- 解釈...整合性の観点から理解する

2024-11-01

自分はエンジニアとしてやっていくには頭が悪すぎる

エンジニアになってから数年が経つ。

自分より圧倒的に実力が上のエンジニアを何人も見て「ああ、これは無理だ」と何度も痛感した。

じゃあ自分も努力しよう、手を動かしてひたすら知識と経験を積もう、という話なのだが如何せん自分はインプットのスピードが遅い。結果としてアウトプットも遅くなる。

一応過去にいくつかQiitaやZennでアウトプットしたものはある、がどれも質が低いと言わざるを得ない。

zenn.dev

qiita.com

ではなぜインプットが遅いのか？という問いに行き着くわけだが、これが分からない。

周りを見ていてもエンジニア歴が短くてもインプットのスピードが早い人もいるし、学歴関係なく優秀な人は優秀だ。

自分はどうか？

大学ではろくに単位を取れず中退し、スタートアップでは誰かにレビューを受けるわけでもなく一人でクソコードを量産していた。

今は時間も環境も整っているが、結局何かを勉強しても「何が分からないのか分からない」まま無駄に時間を溶かしている。

もちろんChatGPTに聞いたりもするが、結局「何が分からないのか分からない」のでは自分が何を質問したら良いかも分からない始末。

例えばRDBのインデックスについて勉強した時も「結局インデックスの仕組みはどうなっていてどこに貼ったらどういったクエリを改善することができるのか」が分からなかった。またある時はCSSでbackground-attachmentというプロパティについて調べる機会があったがどれだけ調べてもどういう動作をするプロパティなのか理解できなかった。いまだに関数のメモ化が理解できていないのでReactのuseMemoの使い所も理解できていないし、JavaScriptのPromiseも貧弱な理解のまま書いている。競プロもABCのB,C問題で何度挫折したか、、、(恥ずかしい)

インプットのスピード・精度が低いというのはエンジニアとしては致命的で、侍で言うところの刀が錆びている状態だと思っている(知らんけど)。

インプットのスピード・精度が低い→何かを勉強しても理解できない→仕事で成果が出ない・新しい技術についていけない→時間がひたすら溶ける

という感じでとにかく悪循環。

いや、やるしかない、動くしかないんだけど、、、。

なぜ自分のインプットのスピードが遅いのか、人より理解が遅れているのか言語化できないでいる。

周りに相談したこともあるが、自分と同じ悩みを持っている人はいなさそうだった。

なぜ自分は頭が悪いのか、、、分からん。

2022-11-09

エンジニアとしてやっていく自信を失くした話

TL;DR

自分のエンジニアとしての成長スピードが最近ガクッと落ちた感じがあってなんとなく頭打ちしている感がある。エンジニア30歳定年説はこういうことなのかもしれないと思った。

詳細

自分は今年で25歳になる(一応まだ24歳だけど...)。シードのスタートアップと上場企業を経験して現職では見習いSREをさせてもらっています。スタートアップでは一人でコードを書いていたため誰かにレビューをしてもらう機会は無く、全部独学だった。前職では社内に自分以外のエンジニアがいたが、自分が所属していた部署が新規事業だったということもありあまり誰かと話したりすることなく大体一人でコードを書いていた。そんな中でよくないコードでたくさん実装したし、新しい技術をキャッチアップしないままとにかくコードを書いた。自分が他人と比較して実力が低く、成長スピードが遅いのはレビュワーや同僚がいないからだと思っていた。誰かにコードをレビューしてもらったり、教えてもらえる環境であれば自分は絶対にもっと速く成長できると信じて疑わなかったし、自力で調べながらある程度なんでも実装できるエンジニアになれると思っていた。しかし、転職して自分に初めて上司がついてコードレビューを頂き、自分と同年代のエンジニアに囲まれた環境で働いてその考えが間違っていたことに気がついた。結論、成長スピードは変わらなかった。同僚は全員自分より遥かにエンジニアとしても一人間としても優秀で「これが本物のエンジニアなのか」と毎日圧倒されている。自分なりに色々インプットして頑張ってみたもののどうにも追いつけず、それどころか実力差は開く一方だった。ここで初めて自分のエンジニアとしての人生はここで終わるのかもしれない、と恐怖を感じた。本当に、なんというか、手も足も出ないのだ。これまでRailsでちょこっとサービスを0から開発したり、バックエンドをTypeScript * DDDで開発したり、フロントをNext.jsで開発したり、ちょこっとAWSでリソースをいじったりとなんとなくWebアプリケーションエンジニアとしてやっていけるかなと思っていた矢先、その自信はあっけなく木っ端微塵に砕けた。なんというか、解決策が見えない。どれだけ頑張っても自分が目標としているエンジニア像にはなれないというハッキリとした感覚がある。毎日コードを書き書籍を読んだりしたが、歯がたたない。世の中の自分が目標とする最前線で戦われているエンジニアになれそうにないとハッキリわかったのが今。

こいつどれくらいの実力なんだ？と思われた方は

katsukiniwa.dev

github.com

こちらを覗いてなんとなく実力を感じ取って頂ければと :bow

どこにでもいるジュニアのエンジニアだと思います。今年でエンジニア4年目です。 TwitterでDM開いてるんで実力が気になる方はペアプロしましょう！疑似コードで何かソフトウェア書いたりsystem designの話とかしてみたいです！

結論

だから何か解決策があるという話ではない。エンジニアは実力社会であり、生存者バイアスのかかりやすい職種だと思っているので今一流として活躍されている方はそもそもこういった悩みにぶつかったことがないのだろうかと思ったりしている。もちろん似た悩みや課題にぶつかったとしても自分とは遥かに次元の違うレイヤーで戦っているのだろう。自分は本当に、なんというか、実力が足りない。どうにかして自分が憧れているエンジニアの方々に少しでも追いつけるよう頑張りたい。

2021-11-14

システム設計のまとめリポジトリ作ったとか師匠が欲しいとか色々

社会人1年目も終わろうかという感じなのでちょっと日曜日の余暇を利用して近況報告だったり最近感じた事なんかをダラダラ書いてみました。

awesome-software-design-jaというリポジトリを作りました

概要

システム設計やアーキテクチャの議論をする時に

QiitaのXXっていう記事読んどいて〜

とか

YY出版社のZZっていう本が良書だよ！

と、アドバイスをさせて頂くことが重なったので一念発起して自分がこれまでシステム設計やアーキテクチャを考える上で参考になった記事や書籍をまとめたリポジトリを作成しました。

github.com

作ってみた感想

Twitterで投稿した所、予想以上の反響を頂き素直に嬉しく思いました！
特に以前から作る構想があったわけではなく金曜日の仕事終わりにふと「作るか〜」というくらいの気持ちでザーッと挙げ連ねたという感じです。自分の持っている知識の割合がなんとなく可視化されて面白かったです。

サービスを開発する時に思うこと

いくつかのサービスの立ち上げを経験して、まず自分がエンジニアとして一人前にならないとどうにもならないな〜と痛感しました。作れるサービスって開発に携わるエンジニアの技術力によると思っていて。もちろん技術力が必須ではないサービス(コンサルとかD2Cとか)もありますよ。ただ自分がこれまで携わってきたサービスってエンジニアがまずコードを書いてサービスのPoCを作って、って感じでした。そうなるともうサービスをどれだけ質・スピードを高くしながら作れるかはエンジニアの技術力次第なんですよね・・・。1年前の自分よりは多少視野が広がったかもしれない、とは思いつつも根本的な部分では周りと比較してまるでダメだなと痛感しています。こればっかりは自分の実力・練習不足という他なく猛省しています。

ただ最近友人から「師匠がいないのも停滞している原因ではないか」という指摘を受けました。自分はエンジニア人生の大半を文字通り一人で過ごしてきました。レビューを受けたことはほとんどないですし、技術的な話も気軽にできる人は周りにほとんどいないです。まあ、これに関しては自分の社交性の低さとか徳の低さとかもっと他の部分に原因があるのは自覚していますw。ただ自分にはエンジニアの知り合いがいないので身近に師匠になってくださる方がいなく・・・。

とにかく師匠が欲しいです。自分のどこが具体的に駄目で、どう強くなるのが良いのか。もちろん本当に強い人は独学で強くなれるのは知っています。ただあれ、完全に生存者バイアスというか、再現性が皆無で一種のギフトだと思うんですよね・・・。もちろんその裏にはものすごい努力があるもの知ってはいるのですが、自分程度の実力だとそもそも自力で突破できる壁なんて全然ないんですよね。けどやるしかないのでなんとか根性で勉強はしているつもりですが、目標としている方々や活躍している同世代のエンジニアを見ると「本当に彼らに追いつけるのだろうか・・・」と心が折れそうになります。ウサギと亀の話ではないですが、現実のウサギはトップスピードのまま走り続けますし止まってはくれないです。亀の僕は差が広がっていくのをマザマザと見せつけられて終わる、みたいな感じです。師匠募集しています、っていって募集が来るわけないのは分かってるんですが、皆さんはどうやって師匠を見つけましたか？何卒迷えるエンジニアに１つアドバイスをください・・・。

さて、若干視点を変えて、サービスを開発する時って一人じゃ限界があります。となるとビジネスサイドの人間とやりとりをしてどうやったらリリースまでこぎつけられるか、という話し合いをします。戦略レベルの話ですね。技術選定だったり、アーキテクチャ議論だったり、採用の話だったり、納期だったり。ただ最近ライティングソフトウェアという本を読み始めて(まだ序章ですが)、戦略に対する認識が変わりました。

ライティングソフトウェアでは著者がザ・メソッドというプロジェクトを正しく進めるためのメソッドを提唱しています。そのザ・メソッドはシステムデザインとプロジェクトデザインから成り立ち、前者がシステム設計やアーキテクチャに関するデザインで後者がプロジェクトを進める上での原則をまとめたものです。そしてシステム構築においてシステムデザインよりもプロジェクトデザインの方がシステム構築の可否を握る割合が多いと主張しています(確かそんな主張だったはず・・・)。これは確かにそうだな〜と思いました。完璧なアーキを提唱・実行したところで無謀な納期、アテのない採用、足りない予算では勝てる戦も勝てません。ただそこらへんにも首を突っ込むとなると単なるプレーヤーとしてのエンジニアではなくCTOとして立ち振る舞う、ないし権限を委譲してもらう必要があり、それは一個人でできる範疇を大きく超えています。ただ、少しでも勝率を上げるためにはそういったエンジニアリング以外の部分の手綱も握った上で戦場に立つことが必要なのかな〜とか思いました。

最後に

タイトル考えるのが一番難しかったりしません？自分の場合書きたいことをテキトーにば〜っと書いて最後にタイトルを考えるので文章にピッタリのタイトルが思い浮かばないんですよね笑

2021-04-08

DDDで開発するにあたって

はじめに

自分はRailsでの小規模なアプリケーション(テーブル数が約40~50)の開発経験しかなかったため、新しい会社に入社してからDDDをキャッチアップするのに苦労している。しかし、最近になってようやくDDDの全体像が見えて来たので備忘録がてらどうやってここまで来たのかその道中を記しておこうと思う。

書籍一覧

自分がまず最初に読んだ本はこちら。

little-hands.booth.pm

DDDに関する基礎的な知識が体系的にまとまっていてとても参考になりました。DDDは登場する概念が多いのでまずは上記の書籍で全体感を把握すると良いのではないでしょうか？

次に自分が手に取ったのはこちら

www.shoeisha.co.jp

gihyo.jp

サンプルコードが大量に記載されているので、実際に自分の手を動かして理解する事が出来ました。この本のおかげでDDDに対する基礎知識の叩き台が出来上がりました。サンプルコードはC#ですが実装内容はシンプルなので何らかの静的型付き言語の経験があれば十分読み替えられると思います。自分はRuby以外にTypeScriptの経験しかなかったので写経する時はTypeScriptで行いました。

ちなみに写経してて最初につまづいたのがDIでした。Rubyはダックタイピングが採用されているのでinterfaceを使用して抽象に依存する、という概念を理解するのに時間がかかりました。こればっかりは何度も写経して自力で理解するしかないと思います。constructor DIを使用した場合は注入時に振る舞いが決まるというのは初心者には難しかったです。

この2冊を読んでから今現在、実践ドメイン駆動設計やエリック・エヴァンスのドメイン駆動設計を読み進めています。

www.shoeisha.co.jp

ちなみに今自分はドメインイベントの部分で詰まっています。何らかのコマンドが発生した時に別のコンテキストにその変更を通知する、というのは何となく理解できたのですが、いまいちIDDD_samplesを読んでも理解できないんですよね・・・。

その他参考になった記事

個人的に名人さんのQiita記事全般にお世話になりました笑

エンティティのconstructor自体もprivateにする手法は面白かったです。

qiita.com

あとこちらの記事のDDDを把握するのセクションは大変参考になりました。

qiita.com

思う事

DDDで、つまりドメイン駆動で開発していて痛感するのは開発対象となるサービスを正しく理解する事の難しさです。DDDは文字通りDomain Driven、つまりドメイン駆動で開発します。Rails時代はテーブル駆動でモデルを設計していましたがそうはいきません。ドメインモデル図の作成やユースケースの洗い出しを行って行ったり来たりしながら正確なドメインを作成していきます。ドメインを見間違える、つまり集約の定義や境界を間違えるとそのあとどれだけ緻密にコードを書こうとしても設計が根本から破綻してしまいます。最近自分はその事に気がついたのでこの本を読み進めています。

www.shoeisha.co.jp

まず正しいドメイン層を定義できるよう頑張ります。