プログラムのすんごく基本的な書き方

プログラミングは、数字ばっかりアルファベットばっかりでなんだかよくわからん！

というのが最初の印象でした。

でも自分で例題を作ると、結構わかりやすいです。

１.普通に文章を作る

「今年の社長の年齢は５０歳。２年後の年齢はいくつか」を出力したい。

2.文章を分解する

こつは　主語　主語に続く助詞（は、が）、述語　にわけること。

　　今年の社長の年齢は５０歳。

　　「今年の社長の年齢」「は」「５０」

3.主語に続く助詞（は、が）を「に」に変換し、述語のあとに「をいれる」を追加

「今年の社長の年齢」「に」「５０」「をいれる」

4.上の文章をプログラミングの式に直す

「今年の社長の年齢」「に」　「５０」歳をいれる

　var shachoNoNenrei:Int= 50

5.2年後の社長の年齢を式で表す

２年後の社長の年齢は今の年齢＋２

　　　　　　　↓

「２年後の社長の年齢」「は」「今の年齢」＋２　

　　　　　　　↓

「２年後の社長の年齢」「に」「今の年齢」＋２「を入れる」

　　　　　　　↓

var ninengonnoShacho:Int = shachoNoNenrei + 2

6.出力する

出力はprint（）をつかう。（）の中身を出力せよ、とう指示の言葉。 

この一連をまとめると

↓

var shachoNoNenrei:Int = 50

var ninengoNoshachoNoNenrei:Int = shachoNoNenrei + 2

print(ninengoNoshachoNoNenrei)

うん。簡単簡単。

なんでプログラムで、最初に＝０をやらなきゃいけないのか

プログラミング（swift）文法を学んでいて、ほんとによくひっかかって立ち止まっている。そのうちのひとつがタイトルの話。

いろんな参考書が、変数（もしくは定数）の初期設定として

var 変数の名前：型　＝　0　（型がIntもしくはDoubleの場合）

を書いている。「=0」をつけないっていう　var 変数の名前：型　もある。

どちらにしても、いろんな参考書のサンプルデータを読んでいる時、

どうして最初から値をいれないのだ？というなぞは解けないまま。

しばらくすっきりしなかった。

「なぜ」がわからなくても、覚えなければならないのが文法。

なんか覚えるためのいい方法がないかなぁと思ったときに思いついたのが
「プログラミング＝会社」理論（誰に認められなくても、自分で勝手に命名）。

仕事で新しいプロジェクトをするときに、まずはポストを作るだろう。

例えば、プロジェクト責任者、実働部隊、お客様担当、経理とか。

そう、先にポストとその人数の設定が必要で、その後に具体的な人選が始まる。

変数（定数）の初期設定はそれと同じ。まずはどんなポストがプログラム内で必要かを機械に教えなければならない。

だから最初に、

var kacho: Int = 0

みたいにかかなきゃいけないのだ。

と思うと、意外にプログラムの読みが早くなったし、
自分で書いていてもエラーも減ったので、メデタシメデタシ。

「＝」で困った話

真っ先にプログラミングで困ったのは、この「＝」。

小学生のときに算数を習い始めてからウン十年とつきあっているものです。

その小学生のときから使っている「＝」って、こういう使い方が多いと思います。

１　＋　１　＝　２

１に１をたすと２と同じ（になる）

繰り返して言っているだけに見えますが、

１＋１（原因）　→　２（結果）

という流れになってます。

言い換えれば、

左辺　「は」　右辺「と同じ（になる）」

という構成です。

ところが、プログラムの「＝」ってこういう使い方ではないのです。

「＝」は代入演算子。

難しい漢字をつかってしまいましたが、

プログラミングでは

左辺　←（に）　　右辺（を代入する）

になります。

最初これを聞いたときに「ふぅーん」としか思わずさらっと

しか聞いていませんでしたが、のちのちサンプルのプログラムを

読むときにこんがらがりました。

例えば、

a　=  a + b　という　プログラムがあったとします。

（aは数学でいう、変数だと思ってください）

数学の「＝」のつもりのままで読むとおかしいんですよね、この式。

「え？　なんで　a とa+ bが同じになるの」

「aがどうしてa+b になるの」

っていう疑問にかられ、

「わからない！どして！どしてなのぉ」と叫んでしまいます。

でも、プログラムでは

左辺のaという場所 「に」　a+bを置き換える

ということをやっているだけなんです。

例として

a =   8 + 9

print (a)←（）内を出力せよという意味です

というプログラムを書くと、

画面に現れるのは 17です。

—————

だったら、

いっそのこと　8+9 = a

 print (a)だっていいじゃん？って思いませんか？

なんで、プログラムはこんなわかりにくいことになっているのか？

と考えてみました。

「プログラムを書く」というのは、機械にわかりやすい指示を出すということです。

この機械は、蛇みたいなもの。

この蛇は、餌をひとかたまりずつだけ噛むという特徴があります。

さらに、その蛇は、「＝」の左辺は覚えていられるけれど、

右辺は「覚えていられない」という特徴があります。

もし、 8+ 9 = a

print (a)

と書いたとすると、

蛇は、８＋９は覚えていても、aは覚えていられないので、

aを出力せよ、といわれても「はぁ？aってなんですの？」

とわからなくなってしまうのです。

機械という蛇に餌を食べてもらうために、蛇に食べやすい形にしなきゃいけない

というのはすこししんどいかもしれません。

でも、最初のうちは「＝」は、

と思い込むことで、機械の言葉のルールに慣れていくのではないでしょうか？

っていうより、わたしがそうでした。はい。

で、何がいいたいの？（プログラムにはスペースが必要）

「もっといいたいことをまとめてから言ってくれない？」

社会人になりたてころ、何がわかっているのかもわかっていないのかもわからず、

電話で聞かれたことをそのまま上司に聞くということをしょっちゅうやってました。

今ふりかえってもだめだめ新人だなぁと。

息をつく時間がないほど忙しかったからではないです。

わからないから、言われたことをそのまま肉団子状態にして

上司に投げてたんです。今振り返っても無責任な新人。

でも、その肉団子を簡単にバラバラにする方法はあるんです。

それは「わける」。

つまり、要素をはっきりとバラバラにする。

その要素を短文で組み立てなおしていく。

・今なにがわからなくて、こうしたいと思っている。

・こういう結果がほしいのだが、その結果を得るために何が必要なのか。

大体のことは「原因」→「結果」のロジックにあてはめれば解決できるなぁっていうのは

今までの体験から得たことです（英語の論文も、広告企画書もこれで対応してきましたよ）

それはプログラムも同じ。

その基本として、最短要素をはっきりとさせるスペースが超重要。

・　＝　の前後は半角スペースを開ける

・文字、数字の間もひとつのまとまりの前後は必ずスペースを開ける

（例外もあるけれど、最初はこれでよいと思います）

X-code（プログラムを書くソフトみたいなもん）は、「スペース空いてないよ！」

とエラー表示してくれます。だから、そんなにビクビクする必要はないとわかっているのに、

「エラー警告」に動揺してしまうのですよ。

でもそのときに「スペースはちゃんと空いているか？」と、少しでも頭の中に浮かぶと

気持ちは落ち着きますよ。

——

自分の知識定着のため、プログラミング日記はswiftについて自分なりにかいています。

もし間違っていることがありましたらお知らせください。

プログラミングって理想的な会社作りと同じなんじゃない？

アプリ（ios）を作るのに3ヶ月かかりました。。

1ヶ月目はスクールのテキストをよみよみ、写経状態。

2ヶ月目から本格的に自分で企画、そしてわからないところを聞くというスタイルをとりました。

この間、なんとなく書いてはいるけれども、本当に自分で理解して書いていたのかしていたのか？

と言われると不明です。

あとで自分で書いてみて「どうしてこうなるんだ？」ばっかりでした。

特に文法はまったくもってはてなの嵐。

自分で書いたものを読めないっていうのは、なかなかつらいものです。

手書きの文字ならまだしも。

なので、

アプリをitunesでリリース後、

一般的によく聞く「他の人に教えるように考えると覚えるよ」という教えに従い、

ずっと考えてました。どうやったらプログラミング文法を理解できるんだろうか？

それでふと思いついたのが、

プログラミングって理想的な会社づくりだなっていうこと。

会社組織は基本トップダウンです。上司の命令は絶対。

それに逆らっても組織は動かない。

プログラムも同じで、上位プログラムが下位プログラムを管理しているので、

下位プログラムが上位に逆らうようなことをしても動かないんですよね。

そして、いろんな部署間がの連携がきれいに組み合わさって、商品をだす。

これに気がついたときに、ぱぁぁっと目が開いた感じがしたんです。

プログラミングを会社に置き換えることで、ひょっとしたら会社組織での働き方も学べるんではないだろうかと。

……実際は部署間の連携はぐちゃぐちゃだったり、トップダウンじゃなかったり、上司のそもそもの命令がおかしいとかあるけれども。うむむ。

はじめに（あれ？もしかしてどん底ってこれ？）

はじめまして、キムラユと申します。

広告代理店にて20年近くサラリーマン生活を続けていました。

楽しい時は一瞬でつらいことが多い環境でしたが、

それでも「職場の仲間のために」っていう思いで仕事をしてました。

でも2017年春先。激務で倒れました。

原因は婦人科系の病気。

手術をしてすぐに復帰予定が、持病の影響で手術できず。

自宅療養をしばらくすることにしたら、

会社から添付ファイルがついたメールが一枚ぴろっと。

「会社やめてね」

え？そんなことってあるの？ひどい！っていう言葉よりも、

「今まで頑張ってたつもりだったけれど、わたしの仕事は認めてもられなかったんだ。わたしは必要な人間じゃないんだ」

っていうことにかなり動揺しました。

お客さんから「明日の朝に欲しいの」と夕方に急に仕事を投げられても。

夜23時からミーティングでも。

ここで誰かががんばらなきゃ、会社の業績がもっとひどくなってしまう。

クライアントに嫌われてしまう。

だから頑張ろう、と歯を食いしばっていたんです。

ところが実際やめてみてどうでしょう。

まだいる人々は「大変だヨゥ」と言いながらも会社はつぶれていません。

わたしが苦笑いと「大丈夫ですよ」っていう無理をした我慢ワードを吐かなくても

会社は廻るんですよ。

「人生、詰んだ、なんだこれ！」と、はじめて口にした瞬間でした。

でもですね。

だんだん時間が経つうちに、わかってきました。

会社がわるいんじゃない、わたしが悪かったんだと。

会社のせいにして、自分の健康をおろそかにしてたしました。

自分をおさえて、他の人の意向を優先させてました。

ほんとうはいいたいことがあったのに。

やりたいことがあったのにー。

ほんとにはやりたかったこと。

課題を解決するサービスを実体化すること。それは広告コミュニケーションではできないこと。

にもかかわらず、それをクライアントの広告コミュニケーションで叶えようとすることが

そもそも無理だったんです。

しばらく療養生活をしていると、

会社に属していなくても「あ、こういうサービスがあったら○○さんにいいな」

「どうしてこういう問題解決のほうほうがないのだろう」という疑問がポンポンあがってきたので、

毎日コツコツと書き溜めてました。

それを実体化させるためにはどうしたらいいんだろう。また会社をさがす？

いやいや。今は自分で実体化できる時代です。

そのひとつがアプリ制作。

今はアプリ制作はもうからないと言うひともいますが、

「まだ課題を解決する」アプリはまだまだよちがあるように思えます。

そして、今年、というより先日、Metro’s Gnome Tokyoというアプリを

つくりました。＝の意味もわからず、英単語の意味がわかっても、それがプログラムで

どういう意味かわからないという状態で始めたのが今年７月。

そこからなんとかいろんな人に助けれられ、10月はじめにリリースしました。

作りとしてはまだまだです。

でも自分としてはこれからこのアプリをもっと育てたい。

もっと他のアプリも作りたい。

そのためにスキルをみにつけたい。

だから、自分のスキル理解を促進するために、

アプリの文法swiftに関するブログを書くことにしました。

また、自分が作っているアプリのことに関しても書こうと思います。

サラリーマン生活20年近くと書いたように、

わたしが40歳越えということがおわかりですよね。

それでもアプリは作れました。

そして、「あーわかんない！」と叫びながらも充実した毎日を過ごしています。

さらには、アプリの文法理解を通じて、「これって会社で働くことと同じだよな」と

仕事の仕方について理解をすることもできました。

 アラフォー、アラフィフの人にもアプリ制作をやってみていただけたらなぁと思います。

よろしくお願いします。