主婦のRuby開拓日記
TAKI主婦がRubyをイチから学ぶ理由
私は自己紹介にも書いた通り、3歳の娘にプログラミングを好きになってもらって、将来「リケジョ」になってくれたら！という思いを込めて、今「Ruby」を学んでいます。きっかけは元SEの父からの「継承」です。
これまでもAIのガイドを受けながら、いくつかのファイルにコードを書いてフォルダーをターミナルで動かす程度のことはしてきました。けれど最近は「コードを自分で書けるようになったら、もっと自由に創れるのでは？」と思うようになり、父が強く勧めてくれた「Ruby」に挑戦することにしました。
父から譲り受けた学習書は『Ruby―プログラミング入門』（原信一郎 著）。なんとRubyの生みの親である まつもとゆきひろさん が監修しているのです。アラフォーになった私が、今から学び直そうと選んだ言語を、その作者本人が見守ってくれている。そう思うと、心強さとワクワクでページをめくり始めました。
オブジェクト思考スクリプト言語ってなんだ？！
この本の表紙裏には、こんな一文がありました。
Rubyは、手軽に本格的なプログラミングが楽しめる、オブジェクト思考スクリプト言語です。
プログラミング初心者の私は、これを読んで次のように推測しました。
- たぶん、ファイルにコードを書いて動かすだけじゃなく、構造ごといじれるからカスタマイズ性が無限に広がるという意味？
- スクリプト言語だから、パソコンへの伝え方が「まとめて」ではなく、その都度指示できるという意味？
正直、ありったけの知恵を総動員してもこのレベル。でもそれでも、ゼロから自分なりに意味を考えられたことが小さな一歩です。
AI先生の評価：65点／100点
私の推測に対して、AI先生から返ってきた評価は 65点／100点 でした。
評価の理由
-
良かった点
・「カスタマイズ性が広がる」という直感は、オブジェクト思考の本質に近い。
・「その都度伝えられる」という発想も、スクリプト言語の特徴を正しく捉えている。 -
惜しかった点
・「構造ごといじれる」という表現は少し抽象的で、クラスやオブジェクトという具体例をまだ意識できていない。
・「その都度」という理解は正しいけれど、「コンパイル不要で即時実行できる」という大事なキーワードに触れられていない。
付加価値としてのアドバイス
AI先生はさらにこんなアドバイスをくれました。
- オブジェクト思考は「現実世界のモノをプログラムの中に持ち込む考え方」。例えば「犬」クラスを作って、その中に「吠える」メソッドを持たせるイメージ。
- スクリプト言語は「小さな実験をすぐに試せる」環境が強み。たとえば1行の計算や文字列操作を書いた瞬間に実行できる。
これを聞いて、私は「Rubyって大規模な仕組みを作るためだけじゃなく、小さな試行錯誤にも向いているんだ！」と理解できました。
学びの気づき
「自分なりに推測する」→「AI先生に評価してもらう」→「修正し理解が深まる」
このサイクルを回すことで、Rubyが「難しいもの」から「身近な道具」に少しずつ変わっていくのを実感しています。
学び始めの今は65点でも、次は70点、80点と伸ばしていけるはず。
そう考えると、評価点数さえ「成長の証」に思えてきました。
TAKI実は…。
このスクラップを書き始める前に、私はすでに本の「はじめに」と「目次」あたりを、AIのサポートを受けながら読み進めていました。だからこそ、コンパイルについても「具体的な専門用語」は出てこなかったけれど、なんとなく「パソコンへの伝え方が『まとめて』ではなく、その都度指示できる」という霞がかった答えを出せたのです。
けれども「オブジェクト思考」に関しては、まだまだ概要すら掴めていませんでした。そこで今回のスクラップでは、「オブジェクト思考って何か」を自分の口で簡潔に説明できるレベル を目標に学習を進めることにしました。
さっきのAI先生のヒントから
AI先生はこう教えてくれました。
オブジェクト思考は「現実世界のモノをプログラムの中に持ち込む考え方」。
例えば「犬」クラスを作って、その中に「吠える」メソッドを持たせるイメージ。
なるほど、そう聞くと一気にハードルが下がった気がします。
「犬が吠える」なんて、まさに現実世界そのもの。だったら、現実の比喩で考えていけば理解できそうです。
そういえば、一度AI先生のガイド付きで本を読み進めていたとき、「ぬいぐるみ」や「くま」が登場して、「寝る」とか「遊ぶ」といった動作を例に出していたのを思い出しました。たしかに、日常にある「モノ」と「ふるまい」の組み合わせで考えると、すっと頭に入ってきます。
AI先生に頼んでみる。「オブジェクト思考を腹落ちさせて。」
ここで私はAI先生にお願いしました。
「オブジェクト思考を、もっと腹落ちするように説明してください。」
ただ定義を覚えるだけでなく、「自分が娘や友人に話すとしたらどう説明するか」を想定して教えてもらうことにしたのです。
AI先生が返してきたのは、こんな答えでした。
オブジェクト思考は、「モノ」と「モノの性質や動作」をセットで考えるプログラミングの方法です。
例えば「くま」というクラスを作ったら、そこには「体重」や「毛の色」といった性質（データ）、そして「歩く」「寝る」といった動作（メソッド）を持たせます。
こうすることで、現実に近い形でプログラムを組み立てられるのです。
この説明を聞いた瞬間、私は「ああ、なるほど！」と納得しました。
「データ」と「動作」を一つのまとまりにすることで、プログラムが“現実の世界っぽく”扱える。
それがオブジェクト思考の正体なんですね。
学びのまとめ
ここまで来て、ただ「オブジェクト思考はモノをプログラムに持ち込む考え方」と覚えるのではなく、「性質（データ）＋ふるまい（メソッド）」をひとまとめにした概念 と理解できました。
なるほど、オブジェクト思考の理解のキモって、もしかしたら、データとかメソッドとか要素を分けて、それごとに指示を出していくことなのかな。AI先生に採点してもらいました。
オブジェクト思考の解釈：今何点ですか？AI先生
AI先生が今回の解釈に点数をつけてくれました。
75点／100点
評価の理由
-
良かった点
・「性質（データ）＋ふるまい（メソッド）」という2つの要素を明確に切り分けて説明できるようになった。
・「現実世界のモノっぽく扱える」という直感的な理解に近づいている。
・「自分の口で説明できそう」という目標に、だいぶ現実味が出てきた。 -
まだ伸ばせる点
・「オブジェクト同士がどう関わるか（関係性やメッセージのやりとり）」までは触れられていない。
・「クラス」と「インスタンス」の違いがまだあいまい。
・例えを言葉で説明する段階から、実際のコードに落とし込む段階に進めると、理解がさらに盤石になる。
付加価値としてのアドバイス
AI先生からは次のようなヒントももらいました。
-
クラスとインスタンスの違い
「くま」というクラスは設計図。実際に作られる「くまのプーさん」や「白くまアイス」がインスタンス。
設計図と現物の違いを意識することが、オブジェクト思考の第一歩。 -
オブジェクト同士の関係性
くまクラスと「森クラス」を組み合わせると、「くまが森で遊ぶ」といったやりとりが可能になる。
オブジェクト同士の関係を考えられると、プログラム全体を“物語”のように設計できる。 -
コードにしてみる重要性
言葉で理解したことを、Rubyで数行書いて試してみると「あ、本当にそう動くんだ！」と実感できる。
頭の中の比喩が、実際のコードと一致した瞬間に、理解が一気に加速する。
学びの成長ログ
前回は65点。今回は75点。
点数の伸びは小さいかもしれないけれど、「データとメソッドをセットで考える」という核の理解に到達できたのは大きな進歩でした。
TAKIオブジェクト思考ってつまり（60点のその先へ）
昨晩のスクラップを書いた後、私はこう考えていました。
「オブジェクト思考って、『誰が、何を、どうする』という設計図（クラス）に、
条件分岐や枝葉をつけたようなもの？」
たぶん、方向性はそこまで間違っていない。
でも、どこか腑に落ちきらない。
そこで、AI先生に聞いてみました。
「今の理解は60点。設計図まではいいけど、“自分で動く世界”という視点がまだ弱いね」
「自分で動く」ってどういうこと？
「自分で動くオブジェクト」ってなんだろう？
私が日々やってる家事の中に、そんな存在はあるかな？と考えていたら、
ふと思い浮かんだのが「ホットクック」でした。
材料を入れて、ボタンを押せば、勝手に煮込みも蒸しもやってくれる高性能な調理家電。
まさに「命令されたら自分で動くオブジェクト」っぽいなと思ったのです。
でも──
そんな高級調理家電、私は持ってません。
うちにはもっとアナログな炊飯器しかないし、
炊き込みご飯も全部、自分の手で材料切って、水加減見て、炊くところまでやります。
じゃあ、私はどこにいるの？
ここでふと思うのは、
「ホットクック的な存在」がオブジェクトだとしたら、
私のように毎回手を動かしている人間のほうが、むしろ登場してこないこと。
プログラミングの世界では、
「誰かが操作してくれるのを待つ道具」ではなく、
「自分で動ける登場人物」が主役になる。
でもそれってなんだか、私がいない世界みたいで少し寂しい。
AI先生いわく、「あなたは舞台の外にいる」
この気持ちをぶつけてみたところ、AI先生はこう言いました。
「あなた自身は、コードの中には登場しない。
だけど、そのコードを書いて、オブジェクトに動きを与えているのはあなた。
あなたは“舞台の外にいる脚本家”なんです。」
なるほど。
たしかに、家では私が材料を入れてスイッチを押す。
でも、プログラムではその一連の流れを**“自分でやってくれる誰か”**を設計しておくんですね。
今のところの理解
いまの私は、こう言い直してみたいと思います。
オブジェクト思考とは、「自分で動ける小さな登場人物たち」を作って、
外からその動きを組み立てる考え方。
人は出てこないけど、
その動きをデザインしているのは「見えない誰か＝私」である。
だから「私がいない世界」ではなく、
**「私が動かなくてもいいように準備された世界」**なのかもしれません。
TAKIクラスとインスタンスを、自分のスクリプトで考えてみた
Rubyの学習で「クラス」と「インスタンス」という概念に出会ってから、ずっとモヤモヤしていました。
ぬいぐるみ、ペット、ホットクック…いろんな比喩で考えてきたけれど、どこかでつまずいてしまう。
どうやら私は、「実物のあるもの」と「コード上の概念」を結びつけるのが苦手だったみたいです。
そこで今日は思い切って、私自身が普段から使っている画像最適化スクリプトを題材にして、クラスとインスタンスのことを考えてみることにしました。
なぜ、ホットクックでは限界があったのか？
これまでのスクラップでは、オブジェクト思考を「ホットクック」になぞらえて考えてきました。
でも、あるとき気づいたのです。
「ホットクックは家電量販店に行けば現物がある。けれど、Rubyのクラスって、どこにも存在しない」
プログラムの中にしかいない「目に見えない存在」に、現実の家電を当てはめようとするのは、どこか無理があった。
いくら比喩を聞いても、感覚的なズレが拭えなかったのです。
私はXもYouTubeもやっていない。でも…
私が持っているスクリプトは、Kindle本の表紙画像を軽量化するためのものです。
圧縮率や画質を変えて、EPUBに適したサイズに変換するために使っています。
あるとき、ふと考えました。
「もしこれを、Xに投稿する画像や、YouTubeのサムネイルにも使いたくなったらどうするだろう？」
おそらく、スクリプトをコピーして、設定を変えて、別のファイルとして保存すると思います。
でも、やっていることの本質は“画像を軽量化したい”という一点。
それなら、ひとつの共通部分を持っておいて、必要に応じて使い分けできた方が効率的かも。
クラスで「共通ベース」を作り、使い方ごとにインスタンスを生む
ここでやっと、クラスとインスタンスの考え方がしっくりきました。
- クラス＝画像軽量化スクリプトの共通部分（やることはどれも同じ）
- インスタンス＝その日の目的に応じて出てくる「実際の設定」
つまり、X用・YouTube用・Kindle用でそれぞれの画像圧縮設定を変えたインスタンスを作ればいい。
いちいちスクリプトを複製して直すより、ひとつの設計図から使い分けできる状態のほうがはるかにスマートです。
インスタンスって、「用途別の具体的な命令のかたまり」だったのか
ここまで来てようやく、インスタンスという言葉が自分の中で腑に落ちました。
私は今まで、コピーして調整して…と、手作業で“似たようなもの”を複数作ってきました。
でも、クラスを使えば、それは自動的に生み出せる。設定を与えるだけで、同じ骨格の「別バージョン」が手に入る。
これが「インスタンスを作る」ってことだったんだ…！と思えた瞬間でした。
まとめ：自分が書いたスクリプトが、いちばんの教材だった
どんなに丁寧な比喩でも、抽象と具体の乖離があると理解は難しい。
でも、自分が書いたスクリプトの中にその答えがあったと気づいたとき、一気に視界が晴れました。
プログラミングの学びって、どこか遠くにあるものじゃない。
日常の中の「なんとかしたい」「こうしたい」という思いが、そのまま教材になってくれる。
私はRubyのクラスとインスタンスを、Kindleの表紙画像を軽くしたいという現実の中から学び始めたところです。