![IT IT](https://srad.jp/static/topics/it_64.png)
「読み・書き・プログラミング」の時代は来るだろうか 100
ストーリー by reo
来ないな 部門より
来ないな 部門より
ある Anonymous Coward 曰く、
物心ついたときからスマートフォンやタブレット端末を身近に感じ使いこなす「スマホ世代」の中高生の中には、社会人顔負けのプログラミング技術を持つ人が何人もいる、として「未踏プロジェクト」に最年少で採択された高校 1 年生や、中学 2 年の女性プログラマーなどがITpro の記事で紹介されている。
開発ツールが安く手に入るようになった現在、年齢に関係なくやる気さえあれば技術を磨くことができる。首都圏であれば社会人による勉強会がそこかしこで開催されているし、それらの中継やまとめ記事にもすぐにアクセスできる。中高での授業でもプログラミングに関する様々な取り組みが (担当する先生に依存するだろうが) 行われている。IT 業界にとって彼らは 10 年後に戦力となるかもしれない貴重な宝だ。
江戸時代以来、身に付けるべき能力は「読み・書き・そろばん」だと言われてきたが、これらがより高度化して「そろばん」が「プログラミング」になる日が来るかもしれない、と記事は結んでいる。
読み・書き...と来れば (スコア:2)
実行だよね。
プログラミングは他人に任せられるから、重要度は低い。
自分でやる必要がある事が来ると思うけど、何が適切なのだろうね。
分析とか?
Re:読み・書き...と来れば (スコア:1)
コミュニケーションじゃね?
最近の若い子たちの能力が低いかっていうと
そうでもないと思うんよ。
ただ、話が合わないんだわ。
おっさんだからかな。
Re:読み・書き...と来れば (スコア:1)
> プログラミングは他人に任せられるから、
「読み・書き・そろばん(プログラミング)」という標語の意味を考えたら
「他人に任せられる」というのは考えちゃ駄目じゃないか?
何か「分析」するたって、わざわざプログラマに依頼して用件定義して
なんて手順を踏むようじゃ駄目でしょ。経営者の条件じゃないんだから。
Re:読み・書き...と来れば (スコア:1)
既に色々書かれているけれど、意味として 読み、書き、算盤 とは
入力、出力、(演算としての)評価 ですね。
オフィスでの仕事なら入力は文書を読むことが主で、出力も文書に記述することが主で、
その途中に、暗算でも表計算ソフトでもスパコン上でのシミュレーションでも必要に応じた
演算と評価を行っている訳で。
今風に言いたければ、読み書きパソコンとなるけれど、読み書きにもパソコンを使って
いるから途中で思考が歪んでプログラミングなんて書いているのでしょう。
Re:読み・書き...と来れば (スコア:1)
誤解を生む書き方をしたかも知れません。元の意味は、寺子屋の科目で
教科書を読むこと、習字を書くこと、算盤で計算すること、ですね。
でも、わざわざ現代に持ってくるなら、
情報を取得する、情報を発信する、情報を処理する、という能力や
その能力を養うことだと解釈していいかなと考えています。
独自の解釈というタグを付けて置くべきだったでしょうか。
Re:読み・書き...と来れば (スコア:2)
read, eval, print
と習った気がする(ソース: 脳内)
実行と評価って同義ですかね?
Re:読み・書き...と来れば (スコア:2)
手続き型指向だと「実行」、関数型指向だと「評価」という傾向がありますね。
Re:読み・書き...と来れば (スコア:1)
evalはセキュリティ上問題になることが多いので禁止です(キリッ)
#威張るだけのエライ人は別の意味で問題になってるのに禁止してくれない。orz
Re:読み・書き...と来れば (スコア:1)
すでに錬度の高い人たち、より高みをめざす人たちにはそっちがいいのでしょうね。わたしには無理かも。
Re:読み・書き...と来れば (スコア:2)
うまく投機実行できる人は尊敬できますね
逆かも (スコア:2)
なんだか高度な方向に進むことばかり考えているようですけど、
そろばん(=基本的な算数)すらも出来ずにプログラミングも何も無いんで、
そういう基本的な項目は無くならないんじゃないかと。
むしろ今まで学校以前とされていた基本的な事が要求されるかも、
人の話をちゃんと聞く、とか
まともな会話をする、とか
プログラマーは社会人の1割で足りる (スコア:2)
例えば、従業員100人の企業の社長になったとしますね。
仮に「電気設備施工と設計の会社」あたりとして
従業員100人全員にプログラミングさせたいとは思いませんよ。
「業績も順調!業務拡張!来年は30人採用」と採用条件決めるとしても
簿記経験者、電気工事士は数人を採用。プログラマー20人とかは採用しない。
会社に必要なのは
1割は:プログラマー
2割は:既存ソフトで工夫できる人間(webサービスの合わせ技とか)
7割は:一般社員。プリンタの紙詰まりは自分で対処できて、初対面のソフトでも
プルダウンメニューの中くらいは探す事のできる奴。そろばん(=基本的な算数)は理解していて欲しい。
これで十分、会社がうまく回ると思いますよ。
(プルダウンメニューの中さえも探さず助けを呼ぶ奴はクビにしたいです)
Re:プログラマーは社会人の1割で足りる (スコア:1)
国民が皆プログラマーになる必要はないと思います。
ただ、これから先、ソフトウェアやIT機器やネットワークがますます社会的に重要になってくると思われます。
ソフトウェアが国を左右するようになり、ソフトウェアをめぐる政治的な決断だとか決定を下さないといけない
場面だって出てくるかもしれません。
そのとき、プログラマーしか問題を理解できず、ほかの人は「プログラマーがそう言っているから」といって
判断ができないのは、民主国家として、まずい状況です。あるいは、プログラマーが、真に国家に必要だから
そう主張しているのか、それとも単にプログラマーの利権が拡大するように発言しているのを、誰もチェック
できないようでは困ります。
それは、全国民が科学者になる必要はないけど、似非科学にだまされないための最低限の科学リテラシーは
持っておいたほうがいいのと同じです。
Re:プログラマーは社会人の1割で足りる (スコア:2)
残念!高校生の時点で四則演算がまともにできない人はいたし、大学にもいましたよ!
#大学からは電卓を使用してもあまり問題にはならないと思いますが
Re:プログラマーは社会人の1割で足りる (スコア:1)
深呼吸してよく考えてみてください。
宝? (スコア:2, おもしろおかしい)
○ 10 年後に戦力となるかもしれない貴重な奴隷だ。
#宝は大事にするよね
プログラミング ⊂ { 読み, 書き, そろばん } (スコア:2)
過去ストーリー「刑務所でRubyを使ったソフトウェア開発 [slashdot.jp]」がその後どうなったか、ご存じのかたいます? 当時、うまくいくとは思えないと予想していたのですが、続報が出てこないし、探しても情報が見つからないので。
Re:プログラミング ⊂ { 読み, 書き, そろばん } (スコア:2)
続報はこれくらいしか見当たらないですね。
http://www.itmedia.co.jp/enterprise/articles/0710/17/news080.html [itmedia.co.jp]
担当会社自体が否定したどころか、その担当会社のサイトもお亡くなりですね・・・。
「20xx年に○万人のプログラマーが不足する」 (スコア:2)
とりあえず書いた記事でしょう。 (スコア:1)
どう考えても、記事を書く人が、それっぽくおもしろく、昔の言い回しをモジって書いただけに思える。
記事書いた人も本気では思ってないでしょ。そういう論調ではないし。
そういう私も、興味をもって記事を読んでしまった一人。そして内容に呆れた。
今こそそろばん! (スコア:1)
私はそろばんできませんが。
そろばんできる昔の同僚は、数の感覚がすばらしく
結構複雑な式のオーダー評価から、長たらしい細かい計算までやってのけ、仕事に活かしてました。
レジで打ち間違えて「2000100円です!」と、
頭を通さずに口に出してしまうとか。
(脳はそう最適化されるだろうから一概にせめられませんが)
実験値が明らかにオーダーからして違うのに疑問を持たないとか、いわば「数の常識」が衰えてる気がします。自分も含め。
そういうのを上手く養うのがそろばんだと思います。
# 読み書きは、ワープロその他のおかげで、ある程度人々の能力が拡張されていると思います。
# 「読めるべきだが書けなくてよい漢字」は、もっと常用漢字などにラジカルな変革を与えていいと思いますが。
「感覚」って大事だと思う (スコア:2)
同じことがプログラミングにも求められると思うのです。どういったことはコンピュータ(すなわちプログラミング)でできて,どういったことは難しいのかというような「コンピュータの常識」を持たない人が多いから。
Re:「感覚」って大事だと思う (スコア:1)
プログラミングのミニマムスキルって何でしょうね。
FuzzBuzz問題はともかく。
アセンブリやっておけばとか、構造化BASICとか、
はたまた「代入文は有害」だとか。
非構造化BASICの歴史が長い私は、いまだにmain文がでっかいプログラムを書いてしまいがちなので
はじめに何に触れるかは結構重要だと思っています。
Re:今こそそろばん! (スコア:1)
誤解にちょっと乗っかってしまったものとしては恥ずかしいのですが。
円周率に関しては、学習指導要領の文章もまずかったでしょうね。
適宜、3, 3.1, 3.14...を用いても良いとかしていれば。
相手が人だけかコンピュータも含むかが違うだけ (スコア:1)
ここで言う「読み・書き」とプログラミングの違いは
相手が人だけかコンピュータも含むかが違うだけ。
分ける必要もない気が。
#人に読めないコードを書く人も居ますが。
求められる基本能力の高度化 (スコア:1)
国立情報学研究所の新井紀子教授が著書「コンピュータが仕事を奪う [nikkeibp.co.jp]」で問題提起されているように、今まで機械化されていなかった「知的労働」も、あるマニュアル化できる定型的なものについては、積極的に機械化されていき本格的なOA化が進む時代が目前に迫っていることを考えると、今までのような能力では仕事を得るのも難しくなっていくと覚悟しないと。(人工知能にはフレーム問題のような根本的な問題があるので、オール・マイティな人工知能はむりだけど、特定業務に限れば実用にたる人工知能は実現目前だと思う)。
そう考えれば、機械に仕事を与える仕事としてプログラム能力は、ホワイトカラーの必須能力になるかもしれない。
機械(コンピュータ)にできない、人間の得意とする能力に磨きをかける必要があると思うなあ。
(人間にしかできない能力というと、独創性が真っ先にあげられるけど、異常を察する能力とか、全体を見通す能力とかもある。)
社会制度が複雑化し、使われる技術が高度化してくると、その社会の構成員に求められる能力も高度化するのは当然だけど、その前提には、それまで当たり前とされていた読み・書き・そろばん(計算能力)や常識があることを前提にしていると思うんだよね。
なので、社会から求められる能力を身につけるのが、だんだんと難しくなっていくような気がする。
新卒社員を例にとるなら、今までの新卒社員の能力+プログラム能力あるいはプログラム設計能力とか。
で、採用されるためには、その求められる能力が優秀なだけでなく、人間にしかできない能力にも秀でて無いとダメみたいになっていきそう。
なんか、これからの子供って大変だ・・・。
/*
機械化できるからといって、闇雲に機械化して「コンピュータが人間の仕事を奪っている」ような社会が望ましいとは思わない。
労働による社会参加って、自己存在を確かめる最も基本的なものだから、普通の人には、きちんと生活を維持できて、安心して暮らせるような仕事がある、というのが当然だと思う。
でないと、社会不安が増していって、今の少子化にさらに拍車がかかり、人口減と経済の弱体化、モラルの劣化のスパイラルから抜け出せず日本の衰退につながるだろうから。
*/
Re:求められる基本能力の高度化 (スコア:1)
隣のスレッドにも書いたのですが、今のプログラミングの世界は、ひと昔前と違って、API の使い方さえ知っていればプログラムが書けますね。API の先の具体的な実装やそこで使われているノウハウを知らなくても良いですよね。
このことを、そろばん(計算)についても当てはめて考えると、計算の具体的なアルゴリズムは知らなくても、例えば足し算とはどういうものか、その性質だけ理解していれば、あとは電卓の叩き方さえ覚えていればよいってなりますよね。実際、私達 sin とか cos なんかの関数ではそうしています。
こんなふうに考えてみると、計算の必要性っていうのも、程度問題のような気もしてきませんか?…あ、これは、掘り下げるための思考実験的な議論で、私の個人的な意見っていうわけではありませんけど。 (゚∀゚)
Re:求められる基本能力の高度化 (スコア:1)
>その性質だけ理解していれば、あとは電卓の叩き方さえ覚えて
確かにマニュアル通りに仕事(研究でもいいけど)をしていて、マニュアルの想定内であれば、そのとおりといえるかもしれない。
ただ、ちょっと異常事態になってくると、計算の仕方を理解していないとダメなこともあるよ。
読み書きそろばんの「そろばん」というのは、単純な計算能力だけではないと思うんだよね。
計算している際に、結果を見て、その計算結果が正しいかどうかを見極める能力なんかが、経理や財務みたいな帳簿付けなんかでは必要になってくるし。数字のカンは、自分で計算を繰り返し練習しないと身につかないと思うんだよね。
パソコンが使えるといって、表計算でしか集計をしたことがないと、計算式が間違っていたり、入力したデータに誤りがあっても見つけられないと思うな。
とはいえ、何かを便利な道具として「ブラックボックス」として扱っても、実用上、困らないことの方が多いですよね。
例えば推測統計は、理解するにはかなり数学に詳しくないといけないけど、普通のビジネスマンがデータから傾向を判断するときは、ブラックボックスとして扱うことが多い。データを入れて、Rとかの関数で検定して、という使い方も多いだろうし。
で、読み・書きにしろ、計算にしろ、基本的な部分は、理解しているべきだと思うし、その求められる基本的な部分は、その時代や社会で変わってくる。
少なくとも、ここしばらくは、今までのカリキュラムに上積みされた形でプログラムなりなんなりが求められてくると思うけど。
Re:求められる基本能力の高度化 (スコア:1)
あ、ありがとうごさます。
(読み書きソロバンの問題からは、離れてしまいますが…)実際のところ、私は、最近のプログラマーが 「API ユーザー」 に成り下がっていて、それらの下に潜んでいる部分を理解するよりも、それらをうまく使いこなす方に重心を置いている(…そうせざるを得ない環境にある)ことについて、危惧のしています。
例えば、API で抽象化されたレイヤーばかりを使っていると、例えば、Array List も Linked List も、ある一定のインターフェイスだけに注目している限りは、同じものに見えてしまいます。また、リテラルの部分文字列のマッチングで、リテラル検索(Java 言語でいえば indexOf )も、リテラルの正規表現によるマッチも同じものに見える、なんていう例もありますよね。下位の層を理解していれば、どういう場合に Array List を使えべきとか、indexOf を使えべきとかがわかるはずですが、理解していなければ、それもできません。
思いつかないのですが、もっぱら API ユーザーであることには、他にも懸念されるべき点がいくつかあるような気がしています。
論理的に説得力のある説明にはなりませんが、私も直感的に、プログラミングだけでなく、読み・書き・ソロバンも含めて、下位階層についてはある程度具体的に理解しておくべきだろうと思っています。
(゚ω^* )
Re:求められる基本能力の高度化 (スコア:1)
もう一つのスレッドに回答していて、思ったのですが、下位階層を知らないまま過ごすことで懸念されるのは、例えるなら、手料理を作らずに出前とかコンビニ弁当のような出来合いのものばかりを食べている人についての心配とにたようなものかもしれません。この例えで考えるなら、
など考えられますね。問題か起こるのは、いずれの場合も、何かそれまでとは違う変化が急に起きた場合のようです。状況の変化といえば、イギリスの「オオシモフリエダシャク」という蛾の 「工場の煤煙で樹木が黒ずんだため、白い蛾より黒い蛾が優勢になった」 という自然選択の話 [wikipedia.org] を思い出すのですが、下位階層まで知るとか、下位階層はそこそこに 無数にある API を匠に使いこなす、とかいったアプローチの差は、それ自身に正解というのはないのかも知れません。時・場所・状況に応じて、優勢(最適解)があるだけなのかも知れません。ただ、少なくとも、全員が全員例外なく唯一つの同じアプローチを採用するといった自体になると、環境が変わると全滅して生き残るものが居なくなるから、それは避けるべきだということは言えそうですが… (*´∀`*)
Re:求められる基本能力の高度化 (スコア:1)
そうですね。下位階層を実際に知らなければ、新しい法則性は発見できないと私も思います。
でも、その一方で、三角関数の加法定理なんかもそうですが、法則の殆どは、自分たちが自ら発見したのではなくて、すでに発見されているものを教わったもので、私たちがやるのは、せいぜい、その証明の過程を一度なぞることで、その後は証明の過程は忘れとしまって、定理の使い方だけ覚える… みたいなパターンが多いのではないでしょうか?(少なくとも私の場合は全部そうです (^w^))
証明の過程を知らなくても定理が使える状態、というのは、実装の中身を知らなくてもAPIを使えるというのと似ているように思えるんです。ご指摘なさっているとおり、実装をある程度知っている方が、効率の良いコードが書けるというのは、そのとおりだと思います。前にも出しましたけど Array List と Linked List みたいな例もありますもんね。 ( ^ω^)
Re:求められる基本能力の高度化 (スコア:1)
三角関数の加法定理ってなんだっけ…って。もうずっと見てないから、すかーり忘れてしまってました。ネットで調べてみたら…
これを習った当時は、まったく気がついてませんでしたけど、これって、回転行列そのままだったんですね。…と今更ながらに気づきましたた。
Re:求められる基本能力の高度化 (スコア:1)
三角関数の加法定理ですが、これを習ったときは、一般の代数学の一貫としてやっていたので、とにかく覚えるのが面倒だった記憶がありますねぇ。即興で導き出せる感じもしなかったですし。
でも、回転行列の場合は、もちろん、回転行列 R(⊿θ) を想定して、R(⊿θ) の単位ベクトル ex = (1, 0)、ey = (0, 1) に対する応答を考えるだけなので、すごく分かりやすいなと感じていた記憶があります。最初から、線形代数の一貫として教えてもらいたかったですねぇ。
スピンアウトで、スミマセン。(≧∇≦)
どこからがプログラミングなのか (スコア:1)
フローチャートはプログラミング?
いつぞやにhtmlはプログラム言語なのかどうかみたいな議論もありましたし
#論理的思考=プログラミング、だと思うんだけど基準は?と聞かれると難しい
Re:どこからがプログラミングなのか (スコア:1)
くるかもしれないじゃなくて (スコア:0)
もう通り過ぎた後だろ?
Re:くるかもしれないじゃなくて (スコア:2, 興味深い)
そうだね。
パソコンの電源を入れればそのままBASICが使えたのは昔のこと。
オープンソース活動を支えているのだって、今やおっさんばっかり。
さらに上の世代は、電子工作やアマチュア無線にとりくんだ。
でも、私たちの世代は、それを引き継がず、プログラミングという新たな課題を見つけてとりくんだ。
次の世代は、また新たな課題を見つけることでしょう。
むしろ、そうならないといけないと思う。
ただ、基礎知識というか社会常識として、パソコンや情報機器はプログラムという
もので動いていて、内部はデジタル信号をやりとりしているんだ、ということは
知っておくべきでしょうね。プログラミングの初歩くらい、かじってもいいと思う。
そういう基礎知識をベースとして、一般人として必要な情報リテラシーを乗せていくべき。
Re:くるかもしれないじゃなくて (スコア:1)
読み・書き・算盤
↓
読み・書き・電卓
↓
読み・書き・スプレッドシート ←今ここ
せいぜいこのくらいじゃないの?
プログラミングなんて面倒なものを一般人にやらせる必要は無いと思うけどなあ。
やらせればできる様になるのかね?
Re:くるかもしれないじゃなくて (スコア:2, おもしろおかしい)
読み・書き・算盤
↓
読み・書き・電卓
↓
読み・書き・スプレッドシート ←今ここ
No!
読み・書き・算盤
↓
読み・書き・電卓
↓
読み・スプレッドシート・電卓 ←今ここ
Re:くるかもしれないじゃなくて (スコア:3, 参考になる)
案外そうでもないらしい [hatena.ne.jp]
Re:くるかもしれないじゃなくて (スコア:1)
そんな規定はもともとありません。少しはずれたところに「〜プログラミング言語の習得が目的とならないようにする」という記述はありますが,プログラミング言語を使ってはならないということはありません。実際多くの教科書ではVBAやJavaScriptとか使ってますしね。
Re:くるかもしれないじゃなくて (スコア:1)
そのために、Lightweight Language とやらがどんどん重くなっていくからね。
そろそろ Lightweight feeling Huge Script Language とかに名前変更したほうが良いと思うんだよね。
# なぜか日本では Lightweight Language = 軽量スクリプト言語 なんだな
まぁ、アルゴリズムや規約で縛られているようなものは、いわゆるミドルウェアとして
モジュール化されていってる。可変部は設定ファイルに追い出せている。
そういう意味では、抽象化されてる。
Httpd やルータ等は当然として、Rails や Tomcat や Hadoop みたいに。
[Q][W][E][R][T][Y]
Re:資源の少ない日本にこそ (スコア:1)
おそらく桃色吐息 [wikipedia.org]以来の間違いなんだろうと思う.
Re:こじつけ (スコア:1)
その時に
情報系はみんな行きたがるけど、出来る人が多い=人材としての相対価値が低くなるのでは?
と考えてハードウエアの方に進みました。
10年ハードウエアの開発の仕事してきて、個人的には正解だったかなと思っています。
(あくまで個人の感想です)
Re:こじつけ (スコア:1)
ハードウェアってすぐに時代遅れになるイメージがあって
そっちの道に行かなかったのですが、
ソフトウェアと同じように常に新しいことを学んでいけば
ずっと食っていける物なのでしょうか?
Re:こじつけ (スコア:1)
経験が物を言うので、年を食っても食っては行けます。
ただし自分で考えて問題を解決する能力を身につける必要がありますし、何より好きでないと難しいかもしれません。
Re:プログラミングは「書き」に含まれるんじゃないの? (スコア:1)
ディベート的な意味で、自分の考えとは関係ないこと言ってみますね。今のプログラミングの世界は API の使い方さえ知っていればプログラムが書けるご時世で、API の先が実際にどういうアルゴリズムでどんなふうに実装されているかを知らなくても良いですよね。(昔は API の先にある中身まで作れてしまうような人は沢山いましたけど。)
「これと同じ事は計算についても言えないか」っていう視点もあると思うんです。つまり、計算の具体的なアルゴリズムは知らなくても、例えば足し算とはどういうものか、その性質だけ理解していれば、あとは電卓の叩き方さえ覚えていればよいってね。実際、私達も四則演算ぐらいならともかく、sin とか cos とかの関数ともなれば、それが実際にはどういうふうに計算されているのか、そのアルゴリズムなんて知らない人も多いですよね。でも、sin とか cos がどんなものかは理解してますし、値は電卓を使って求めますよね。
こんなふうに考えてみると、計算の必要性っていうのも、程度問題のような気もしてきませんか? (゚∀゚)
Re:プログラミングは「書き」に含まれるんじゃないの? (スコア:1)
>今のプログラミングの世界は API の使い方さえ知っていればプログラムが書けるご時世で、
ここまで呼んだだけで、プログラミングを書けない人の意見だって分かった。
やっぱりプログラミングの初歩くらいは全員に経験させておいた方がいいと思うな。
こういう勘違い君が出てくる度に、毎回同じことを説明するのはとても疲れる。
Re:プログラミングは「書き」に含まれるんじゃないの? (スコア:1)
sin と cos の例は、確かに、例としては良くなかったかもしれませんね。(>_<)
ですけど、足し算と引き算とかは、概念だけ教えてあとはブラックボックスにするっていうこともできますよね。実際、「数学」の授業では、具体的な数値ではなく、「x」だの「y」だの「a」だの「b」だのといった、文字(代数=具体的な数の代わり)によって四則演算を表現して、それぞれの演算がもつ性質だけを使って数式を処理してしまいますよね?つまり、数学者でさえ具体的な数値計算は殆どせず、ブラックボックスとしてこなしてしまうわけですよね。
…といった、代数による数式の変形なども「計算」に含めて考えていらっしゃると、そういうことでしょうか?。
(゚∀゚)
Re:プログラミングは「書き」に含まれるんじゃないの? (スコア:1)
補足です。
もし、そういうことでしたら、Excel のワークシート関数なんかも、計算に含まれるということでしょうかね?逆に質問ですが、計算に含まれないものとは、どういったものを想定していらっしゃるのでしょうか? 「○○ウィザード」 みたいに、促されるままに空欄に必要事項を入れ込んでいけば、答えが求まるようなのの、とか、色とサイズを指定すれば3日後に商品が郵送されてくるようなもの、つまり、必要な情報を入力すると、何の加工も変形もせずにすぐに使えるズバリ欲しいモノが完成品の形で直に出力されるようなもののこと(だけ)でしょうか?材料からつくる手料理ではなく、食堂の料理や仕出し・コンビニ弁当みたいな… (゚∀゚)