見出し画像

【第5話】プログラミングは理系のもの、ではない/連載『プログラマ夫と算数嫌いの妻が、プログラミングについて話してみたら』

はじめての方へ:本連載は、プログラミングについての知識がゼロで漠然と苦手意識しかない妻(筆者)が、プログラマ夫にインタビューしながら、なんとかプログラミングと少しでも仲良くなろうとがんばる雑談シリーズです。どうぞ肩の力を抜いて、夫婦の雑談をお楽しみください。

<全5話予定>
序章・目次
第1話:そもそもプログラミングってなんなのさ
第2話:お笑いと育児とプログラミング
第3話:日常生活にひそむプログラミング
第4話:当然のように数字の話をはじめないでください
第5話:プログラミングは理系のもの、ではない(←今回、最終回!)

今回の見どころは、「未来について熱く語る夫」です。

■ 「ど文系の算数嫌い」にプログラミングってできる?

↑我が家の日常風景をボーン・トラッキング(骨格の動きを検出)。夫のPCではよくこんな感じの画像を見かける。なお本文とは無関係。

私:結局さあ、前回みたいに二進法とかサラッと出てくるし、算数・数学とプログラミングって縁が深いわけじゃん。やっぱり、小学校からすでに算数嫌いだった「ど文系」のわたしみたいなひとには、プログラミングなんて無理なんじゃない?……っていう先入観がなかなか拭えないんだけど。

夫:いや、最近のアプリやWebのプログラマは、もしかしたら、数字のことを考えなくても、ある程度のものが作れるかもしれない。

私:なんで?

夫:ツールが充実しているから。機械語をプログラマが書かなくてよくなったように、計算のことを考えなくてもいいプログラミング環境が、もうすでにあるんだよね。

私:あ、テレビに出てきた「Scratch(※)」とかもそのひとつ?

※Scratch(スクラッチ):アメリカのマサチューセッツ工科大学(MIT)のメディアラボが開発したプログラミング学習用ソフト。「もし〜なら」「○○回繰り返す」などの命令が書かれたブロックを画面上で組み合わせることでプログラミングを行うことができる。下記画像参照。

↑このスクリーンショットを撮りたいがために、さくっと10分くらいでScratchプロジェクトのサンプルを作ってもらいました。こんなふうに、難しいプログラミング言語を知らなくても、ブロックを組み合わせることでプログラミングができます。

ちなみに表示言語は左上の地球マークを押して自分で選択できるのですが、「日本語」と「にほんご」があることに夫婦で感動。漢字が読めない子どもでも、プログラミングはできる。

なお下記URLから、上記サンプルがどんな動きになるのか、実際に試せます。質問されたら、「はい」か「いいえ」を入力してみてください(※個人的なおすすめは「いいえ」です笑)
https://scratch.mit.edu/projects/288153247

夫:そうだね、Scratchもそのひとつだとは思う。ああ、でも完全にそういうツールかというと、そうじゃない部分もあるかな。というか、どんなツールを使っていても「数字を考えなくても作れるもの」の範囲っていうのはあるんですよ。スクラッチを使おうが、C言語(プログラミング言語の一種)を使おうが。

だけど、「それ以上のことを知らないと、作れないもの」っていう領域もあって。つまり、ある便利なツールをつかうと、それより下のレイヤー(層)を知らなくても、意識しなくても、物が作れる。

私:あ、誰でもテンプレ選んでいくだけでホームページを作れる、みたいなソフトあるよね。ああいう感じ?

夫:そうそう。だけど、そのツールを使っているかぎり、そのツールの表現力の中でしかものがつくれない。

私:うん。それはわかる。もっと細かいカスタマイズしたい、ってなると一歩踏み込んだ知識がいるよね。

夫:そう。で、そのツールよりも下のレイヤーのことを知っておくと、作れるものがもうちょっと広がってくわけですよ。「計算」っていうのは、その下のレイヤーの話。

私:はーん。そうなんだ?

夫:だから、数字に強くなくても、スマホアプリは作れる。

私:へえ。

夫:ただ、数字に強いほうが、表現力があがる。いろんなものが作れる。でもそれは、数字だけが特別なのではなくて、時事ネタに関する知識の量とか、人付き合いのうまさとか、なんでも強みになりうるんだけど。プログラミングという手段においては、根っこでCPUが動いているから、計算を知ってると有利になりやすいってこと。

私:ふむ。じゃあ、プログラミングによるものづくりを極めるには、やっぱり数字は欠かせないものだけど、数字にうとくてもツール次第で「限られた範囲のもの」ならできるってことか。ちょっとだけ希望が見えてきた。

夫:そうね。


■ そもそも「プログラミングは理系のもの」ではない!

↑こちらは我が家の日常風景を、ポイントクラウド(距離を色に対応づけた点群)で表示したもの。さあ、それぞれ何をしているでしょう?(答:夫はPC作業、私は焼酎お湯割りを飲んでいる)

夫:っていうかそもそもね、俺は「プログラミングが理系のものだ」みたいに言われる分類にはとても違和感があるんですよ。

私:そうなの? なんで。

夫:確かにプログラミングをやるにあたって理系的な発想を求められることもあるけど、そのプログラミングを手段として何を達成しようとしているかによっては、文系的な知識・知見、思いつきが重要になることもあるからね。たとえば文章を生成するプログラムを書くとしたら、文章について知っていたり、感性があるほうが強い。

私:まあそりゃ、そうかもしれないけど。

夫:とりあえずね、「プログラミングって、記号と数字をあれこれやる難しいことでしょ」みたいな認識を“理系”っていう言葉でもたれるのが一番、もったいないと思う。

私:もったいない……ねえ。

夫:さっき話したように、数字云々より、もっと高度化された概念を扱うのが、現代の、そして未来のプログラミングでもあるんだよ。

私:うん……(納得しきれていない顔)。

夫:計算とか二進数の概念は知らなくても、ものがつくれる時代はすでに来てる。

私:すでに来てるし、これからもっとそうなっていく? だから「プログラミングは理系のものだけじゃないんだ!」と。

夫:そうそう。あの、Scratchとかはさ、まだ文系理系にわかれていない子どもたちとか、コンピューターにあまり触れてこなかった大人とか、いろんなひとが触っているけれど。

それでも現状のScratchは、やっぱり、最終的には数字とか記号化の概念に強いひとが難しいものを作れる、というものではあると思う。でもそれはね、“ツール側の力不足”だと思う、理想の未来から見ると。

私:じゃあ別に、数字に強くなくてもいいと。でもさ、わたしが「理系的な」と先入観を抱いているのは、数字だけじゃなくて、「論理的な思考」とかも含まれていると思うんだよね。段取りよく、手順を踏んで考えるみたいな。そういう意味ではやっぱり、理系脳のひとの方が得意なのかなって、思ったりするんだけど。

夫:それは、現状ではそう。だけどさっきの話といっしょで、ツール側の力不足だと思う。

私:ほう。

夫:よく、「障がい者か健常者か」という話のなかで、眼鏡の例が出されるんだけど。俺もぽこねんもそうだけど、視力が悪い人は、眼鏡がないと「障がい者」になるじゃない。

私:社会生活を送るのが著しく不便という意味では、そうだね。

夫:逆にいうと、眼鏡が視覚障害のある程度の部分を解決して、健常者にした、ともいえるよね。それと同じで、プログラミングツールの高度化によって、“理系苦手人間”がプログラミングをやるっていうことが、不自然じゃなくなる、っていうことが起こりうるだろうと。

私:ほー。

夫:つまり、「苦手なこと」「できないこと」を抱えている人たちが、それを意識せずにできちゃう、ということね。

私:はー、なるほどね。そのレベルにこれからなっていく……の?

夫:わかんない。そこはね、具体的には想像できないので、なっていくかと言われると弱いんだけど、個人的には、なっていくべきだと思う。

私:夫さんの考えでは、というところね。ふむ。そして、とりあえず現状でも「文系だからプログラミングでものづくりができないわけではない」し、すでに「ある程度のものは作れる状況」だし、さらに高度なものを作れるような未来が、これからくるかもしれないと。

夫:そうそう。むしろ「文系だからできること」があると思うよ、プログラミングにも。文理に限らず、たとえば国語が得意なひとは、国語にかかわるプログラミングをやることが得意だろうし、歴史が得意なひとは歴史にかかわるプログラミングが得意だろうし。それは当然のことであって。そういう意味で、「プログラミングは理系のものではない」って言いたい。

私:プログラミングは理系のものではない。その断言はいいね。

夫:ただ現状、そう見えるのは事実。それは“ツールの力不足”であると。

私:じゃあその現状の中で、わたしみたいなひとはどうアプローチしたらいいんだろう。

夫:ベーシックなことを知らなくても使えるツールを使うこと。そして、もっと深い知識が必要になったら、そこだけを学ぶこと。一切勉強しなくてもいいものが作れるっていう未来はこないと思うよ。

私:まあ、それはどの分野でもそうだね。とりあえず、この連載5回を通して、「プログラミングって畑違い過ぎてなんか怖い」って先入観がちょっとずつ壊れてきただけでも、この会話の意味はあった気がする。いや、どうやってまとめるんだろう、これ……(笑)。

●夫のつぶやき補足:プログラミングは現状では理系に優位なものであって、そのこと自体は未来にも変わっていないのかもしれない。でも、いまプログラミングと呼ばれている行為が、普通のこととして万人に広まっている未来は想像できる。専門家と技術オタクにしか扱えなかったものが、大衆に普及するにつれてだんだんと、それが技術だとすら認識されずに日常に溶けていくという現象は、カメラ、車、電話、インターネット、スマホなどを想像すればわかるように、いつのまにか起こる。プログラミングに関しても、大衆化が進んでおり、近い未来に(もうすでにだんだんと?)日常に溶けていくのだろうなぁ、と。


■ 非エンジニアが、プログラマと仕事をするときに知っておいたほうがいいこと

私:そうだ。せっかくの機会だから、わたしみたいな知識のない素人が「プログラマと仕事をするときに、知っておいたほうがいいこと」を聞いてみたい。

夫:ほう。なんで?

私:昔、プロジェクトの企画側でデザイナーさんやプログラマさんに依頼したりすることがあってさ。やっぱり畑が違うから、お互いの意図がかみあわなくてコミュニケーションコストばっかりかかることあるじゃない? で、お互いにイラッとしちゃったり(笑)。

夫:ああ、なるほど。

私:たとえば今、わたしが「こういうもの作ってほしいんですけど」という企画側だとしてさ。一緒にやっていくにあたり、たぶん無自覚にいろいろ無茶を言っちゃったりするんだけど。

それって相手の考え方を「知らない」からなんだよね。だから少しでも円滑にやっていくうえで、最低限、知っておいたほうがいいことがあったら教えてほしいなあと。

夫:うーん。

私:たとえば、仕様の出し方はこうしてほしいとか、こういう指示の出し方は困るとかさ。たぶんいろいろあると思うんだけど。……じゃあまず、どういう依頼だったらやりやすい

夫:あー。それでいうと「完全に決まってる」か「決まっていないけど自由にやれと言われる」かのどっちかだとやりやすい裏を返すと、曖昧な指示はやりにくいね。

私:曖昧な指示というのは、たとえば?

夫:たとえば……。あ、これは他のひとので申し訳ないけど、ちょっと前にバズってた記事があって。「エンジニアと仕事するときに……」みたいなタイトルの。

私:あ、わかった! フロントエンドエンジニアさんのnoteだよね。それわたしも読んだよ。

夫:え、読んだの? 

私:え? だってnoteだもん。

夫:noteだもの、が理由になるっていいね(笑)。

私:えーっと……。これこれ。

夫:そう。この記事はかなり、俺も納得していて。このnoteにも書かれてたみたいに、「この場合はどうする」が決まってない、のがやりにくいよね。

私:そうか。それでいうと、わたしはあの記事をみて、ああこういうところで迷うんだ〜って例はわかったけど、やっぱりそういうところまで全部最初っからヌケモレなく指示する、ってのは非エンジニアには厳しいなあ、って改めて感じちゃったりもして。

「空欄の場合、何を置くか」とか、言われてみれば“なるほど、たしかに!”ってなるんだけど。言われないと、気づけない……。まあだからこそ、ああいう記事がすばらしいわけなんだけども。デザイナーですらない自分としては、応用できるかというと、かなり限界を感じるというか……。

夫:まあ、あの記事にもあったとおりエンジニアのほうがそれを見渡せる環境にいるから、ある程度はしかたないところもあるよね。

でもそういう「決まってない」ことがあったときに、自分で勝手に判断していいのか、判断するにしたら何(企画やデザインの意図)をもとに判断すべきなのか、ってところを事前にクリアにしてほしい。もしくは、それを相談できる環境がほしい。

私:なるほどー。

夫:つくるにあたって「迷わない」っていう状態がやりやすいんだよね。つくるものが難しかろうと、「決まって」いればたぶん作れるわけで。

決まっていないことがあると、「そこがどう変わってもいいように作る」という手間をかけるうえに、「それでも想定しきれていない危険をはらむ」というストレスがつきまとうんだけど。

私:そうか、企画側だと「パッとここだけ変えちゃって」みたいに一部変更をお願いしているつもりが、プログラムの書き方次第では「全部書き換えないと無理」という状況になったりするんだな。

夫:そうそう。逆にもう時間をかけずに単純にパッと作ってしまって、柔軟性のないものにする、というのもひとつの選択肢にはなるけど。とにかく、そこの迷いが生じることが仕事上やりにくい状態。かな。

私:じゃあやっぱり、大きな目的とか、ブレさせたくないところだけをしっかり共有して、任せるならあとは「その目的や意図をもとに判断してもらってOKです」というのを明確に伝えればいいのかな?

夫:そうねえ……。まあプログラマにもいろんな人がいるし、いろんな職種があるから。必ずしもそういうわけじゃないけど。とりあえず、「迷わないように」してほしい。

私:う、うん……(迷わない、って何回言ったんだろう)。


【ちょっと一息〜ぽこねん落書き劇場:「街で見かけるプログラマ」 

一緒に街を歩いていると、いろんな自動ドアの前で、微妙な距離から手をかざして可動範囲をチェック、かつキョロキョロしてセンサーやカメラを確認している……夫を、よく見かける。知らずに見ると不審である。危ない。
● 夫のつぶやき:自動ドアだけじゃないよ?


■ 作者へのリスペクトってどの分野でも必要よね

私:あのさ。なかったらいいんだけど、たとえば企画側とトラブったとか、どんでん返しがあって「こんなはずじゃなかった」と思ったとか、そういうエピソードってある?

夫:あー。あるかも。

私:たぶん、そういうときも双方の考え方の違いが原因になっている気がするから。ちょっと参考に聞いてみたい。

夫:あのね、展示の仕事だったんだけど。展示のオープニング・レセプションのときに、「レセプションでこんな演出をしてくれ」って、本番20分前くらいに言われたことがあって。たぶん数分押しくらいで対応したんだけど。それは、怒ったね。

私:夫さんが怒るの珍しいね。具体的にはどんな状況だったの?

夫:その展示には、演出のひとつとして電球があって。その展示用に、電球の光をコントロールするっていうシステムはすでに作ってあったのね。

私:ふむふむ。

夫:その電球を、レセプションのときに明るくしておいて、「じゃあこれから、1回目の上映をはじめます」ってときにパッと暗くして、そこからはじめてください、みたいなことをその20分前に言われて。

こちらは「展示に連動したシステム」は作っていたけれど、そういう「あげて」「おろして」みたいなマニュアルの調光機能は作っていなかったわけ。

私:なるほど。それは、お願いする側が、何を理解していなかったからそうなったんだろう。“そんなの簡単にできるっしょ”と思ってることが問題?

夫:そうそうそう。

私:でも、何が簡単で何が簡単じゃないか、って専門外からはわからないんだよね。

夫:まあね。だから解決策がもしあったとしたら、ひとつは「俺がそれを想定していたらよかった」っていうのは確かにあるんだけど。外に解決策を求めるなら「レセプションがあるよ」という情報だけでも事前に知らせてくれていたら、もしかしたら気がつけたかもしれない。

もしくはその、「レセプションにあわせて点灯、消灯してくれ」という指示の重要度を一緒に伝えてくれれば、いまからは無理だと断れたかもしれない……っていうのもあるかな。

私:はー、なるほどね。

夫:というか、その話でなにより俺が怒ったのは、その電球のシステムは「展示のために作ったもの」であって、レセプションの演出のためのものではない、というところ。「違う目的で作ったものを、当然のように利用しようとしたこと」に怒っていたんだけど。

私:ああ……。そういう視点は確かに、エンジニアと非エンジニアではズレているかもしれない。というか、それは文章書いたり写真撮る身からしても、感じることがある話だね。

わたし、どっちの立場にも身を置いたことがあるから耳が痛くもあるんだけど。企画側ってさ、“追加コストをかけずについでに利用しちゃおう”みたいな感覚をあたりまえのように持ってるひともいると思うんだよね。だから、そのあたりの意識はたしかに、クリエイターと非クリエイターだと、ズレが生じてしまうのもわかるなあ。

いまのわたしは、どちらかというと書いたり撮ったり、コンテンツを生む側に意識があるから、そういう対応をみると“人が生み出したコンテンツを軽視しているなあ”と感じてしまうんだけど。でも、予算が厳しい中でプロジェクトを回す気持ちもまあ、わかる。そういう溝ってあったりするよね……。

夫:うん、どの分野でもあるよね。

私:リスペクト、大事やね。

夫:ねー。


■ こんな私にも、プログラミングで何かが作れるの?

↑今回ヘッダーに使っていたこの画像は、夫婦の日常風景にエッジフィルター(輪郭抽出を行う)をかけたもの。背景を黒にするとなんだか一気にプログラマさんのPCを覗いたような近寄りがたさが出る……というのが妻の雑感(笑)。このとき私が飲んでいるのはお茶です。お酒じゃないよ。

私:ところでさ。ここまで話してきて、いかにわたしがプログラミング向きの思考じゃないかわかってきたとは思うんだけど。こんなわたしでも、プログラミングで何か作る、っていうのはできるのかな? 夫さんに、横で教えてもらいながら。

夫:できるんじゃない?

私:そうか。じゃあそのバージョンも第二弾で書かなくちゃ(笑)。なんか……、今回よりもっとヘビーになりそうだけど。

夫:どうぞどうぞ。がんばって(笑)。

私:っていうか、どういうものが作れるんだろう? 全然想像がつかない。

夫:んー。「どういうものが作れる」から発想するとつまらないから、「どういうものが欲しいか」から発想したほうがいいよ。こういうものがほしい、っていう発想は、それこそプログラマより柔軟だったりするだろうし、それを作ろうとするほうが面白いと思うし。

私:なるほどー。いま、ぱっと思いつくものはないなあ。でもとりあえず、実用的なものがいいな。ゲームとかで遊ぶというよりは、日常生活の中で使えるものがほしい。なんだろ。家事関連かなあ?

夫:うん、いいんじゃない。

私:よし。何がいいかは、もうちょっと考えてみるわ。


(第一部 おわり)

※第二部へつづく……のか?!


■ おわりに

きっとこの文章にまで目を通してくださるあなたは、長々とつづいてきた全5回の連載をすべて、読んでくださった方に違いありません。最後まで一緒に伴走してくださって、ほんとうにありがとうございました。

「せっかく夫がプログラマなんだから、話を聞かない手はないんじゃない?」そんな思いつきと貧乏根性からはじまったこの企画。

“絶対わたしみたいな苦手意識もってるひと、いるって!”と謎の使命感にかられ、勇猛果敢に夫を取材(質問攻め)したのは昨年秋。確かに話はおもしろかったものの、それを実際にかみくだいてまとめていく作業は本当に、敵陣で裸にされてあぶられているような生みの苦しさがありました(笑)。

正直、日常のことを書いているほうが自分も楽だし楽しいし、もともとのフォロワーさんもそっちが好きだってわかっているし、スキの数がいつもの日常系noteより下がるのもわかっている。そんななかで粛々と全5回をアップしつづけるのは、気持ち的にもいくらかしんどいところもありました。

いやあ!でもそんなことはもはやどうでもいいですね!敵陣のフィールドで全5回のマラソンを完走できただけで、もはや自分で自分を褒めてあげたい(どこかで聞いたセリフ)。

そして言うまでもなく、途中で挫折することなく完走できたのは、沿道で見守ってくださったみなさんのおかげです。沿道でにこにこ手を振りながら「がんばってー」って声をかけてくださったり(コメントやメッセージ)、実質的に力になる水や食料(サポート)を投げ入れてくださったり、ほらほら、なんか必死だけどこのひとがんばってるよーって他のひとにも伝えてくれたり(シェアやおすすめ)。

ひとりきりでも、取材して書きはじめるところまではできたと思いますが、もし反応がゼロだったら、第3回くらいで走り続ける意義が感じられなくなり、カスカスの燃え殻になって道ばたに転がっていたと思います。ころん。

そもそも最初から、「万人受けを目指したコンテンツ」ではなかったけれど、「だれからも反応が返ってこない状態」と「ひとりでも待ってくれている状態」には雲泥の差があります。しかも実際に、声援や物資を送ってくださる方まで複数いらっしゃる。

楽しみにしていてくださる方がいるなら、ちゃんと走り切るぞと思って、なんとか走りきることができました。ほんとうに、感謝しています。はい、こんな隅々までちゃんと読んでくれているあなたのことですよ。

……なんだか感動のゴール、そして締めくくりみたいな文章を書いていますが、ほんとうは知っています。これがただの「第一章」のゴールにしか過ぎないことを……。

第二章はまだ何も手つかずなので、ほんとうに第二章「実践編」が行われ、わたしが夫に教わりながら何かを作り上げて、その過程が記事化されるかは、まだわたしにすらわかりません。実践編、自分も興味があるしやってみたいけれど、はたしてそれをまとめる気力がわたしにつづくのでしょうか。謎です。

でも「読んでみたいよ」なんて声がちらほら聞こえてきたら、つづいてしまうかもしれません。それをどこかで楽しみにしている自分もいたりします。読んでみたいですか。興味、ありますか。

自分でも何を目指しているのか不明ですが、「わからないことがわかるってうれしいよね」「できないことができるようになるってうれしいよね」そんなシンプルなところに、おとなになっても挑みたいなあという気分が、きっとどこかにあるんです。日々、昨日できなかったことが今日できるようになり、「でった!(できた)」と自分で手をパチパチたたいている2歳の娘を見ていると、そんなふうに思います。

Thank you for all of your support! Hope you have a wonderful day :-D
温かい応援ありがとうございました。今日も、よき日を^^


※第一話から読み直したい方はこちらのマガジンをどうぞ。


自作の本づくりなど、これからの創作活動の資金にさせていただきます。ありがとうございます。