![見出し画像](https://assets.st-note.com/production/uploads/images/25244102/rectangle_large_type_2_9bd788439a4219e8ce7224ca7d535750.png?width=1200)
【読書メモ】教養としてのプログラミング講座
ある自治体職員の方がオススメしていたのを聞いて、読みました。
あっという間に読み切れる文章量です(約180ページ)。
※著書の発刊は2014年。書籍に記された具体的なプログラミング技術や当時のホットトピックなどの個所をほぼ読み飛ばしてしまえば(私はそうしてしまいました)、教養としての読みものとしては、とても入りやすかったです。
「プログラミング思考」って、最近は小学生も授業で習うほどだけど、どういった意義があるのか、著書を読むまで今一つピンと来ていませんでした。どこか別世界の技術的・専門的な遠い存在のようなイメージに思えていた私には、目からうろこでした。
人と人とのコミュニケーションは、近い関係性になるほど、曖昧で、簡略化した伝え方になることが多いです。「いつものあれ買ってきて」「次の会議の資料準備しといてくれるかな」など。でも、これはプログラミングの考え方からすれば、バグが発生する最大の要因。具体的な依頼することを定義して指示しないとトラブルのもとになります。そうしたことからも、日頃意識していないだけで、プログラミング思考は、実生活に近い存在なのだなあと思えました。
以下、著書の読書メモです。
「プログラミング」とは何か?
プログラムは、
・順序立てられていること
・予め作られていること
・何らかのタイミングでとるべき行動が決められていること
→どういったシチュエーションで、どう対応するかを書き示したもの。
一言でいえば、「手順を正確に記した文章」。
加えて、著者は、プログラミングとは人類の叡智であると述べています。
プログラムが書けるということは、「コンピュータを含めた自分以外の人やものに仕事を頼むことができる」ことと同義。
プログラミングの鉄則
1.伝え漏らすべからず
(例)お母さんからのお遣いに行く娘や夫
言われたとおりに買ってきたはずだが、期待に沿わない結果。なぜ?
・相手(=コンピュータ)に対し、指示(=プログラム)を作成(=プログラミング)した母(=プログラマー)が良くなかった。
・コンピュータは、自ら判断を下すのではなく、指示に従って動く。
→期待している事象があるのなら、それを伝え漏らさず、プログラミングしなければならない。期待通りの動きでなければ、それは命令を下したプログラマーの責任である。
2.あくまで「コミュニケーション」の一様態
(例)指示が「安い果物あれば買ってきて」など曖昧なもの
基準が個人の感覚に任されてしまう。安いの基準は?100円?500円?
・経験を積んだ大人同士の場合であれば、指示の内容を自分なりに解釈し直し、相手の望む結果はどのようなものか、最適化することができる。
・(逆に意思疎通が十分でなかったり、不慣れな状況下にある場合は、期待する結果へと最適化できない)
→コンピュータは期待している通りではなく、プログラミングされたとおりに動く。プログラミングはコミュニケーションの一様態。ミスを犯すことを前提としつつ、コミュニケーションの手段について工夫することが鉄則。
3.「フールプルーフ」を活用しよう
(例)強盗の乱入や天変地異といった事態まで想定した指示
・プログラムには想像しうる限りの最悪な使い方をしても、決してシステムが壊れない設計をする。
・そのためには、ありとあらゆる事態をあらかじめ想定して指示を出さねばならない。でも現実的にそれら指示を書ききれない。
→「例外処理」を付け足して対処する。想定しないトラブルがあった時、人ならばある程度対処できることも、コンピュータの場合は、はっきりとプログラミングすることが必要。
4.「インデント」や「カラーリング」でメリハリを
実際のプログラミング作業は、書き込んだコードが非常に長く複雑になってしまうため、インデントや色つけをしてメリハリを持たせる。
プログラミングのテクニック
・アルゴリズム:効率的な作業手順を「形」にする
・処理、分岐、ループ:プログラムの基礎パーツ
・ルーチンと関数:繰り返すだけなら、省いて表現
・ハイパーリンク:別の情報にワープする
・ハッシュ+テーブル:名簿の管理を効率的に
・計算テーブル:考える手間と時間を、劇的に短縮
その他
私が読んでいた中で心に留まった部分を紹介します。
・「プログラムは思った通りに動かないが、書いた通りに動く」
・プログラムにこれを指示したい、これをさせたいという一貫した論理性が求められるが、人の持つ論理性には限界や矛盾がある。人と人との間に生じた勘違いのミスは、現実に多く見られる。
受注者が思った通りにコードを書けてはいるが、発注者の期待とズレてしまっているなんてことは、思い当たるところが多くあります。私自身も発注者に言われたとおりに作業はしたのに、違う!って言われたり、発注したはずの内容が全然違う形になって仕上がってきた経験が色々と思い出されます・・・。
組織やグループでのコミュニケーションは、わかっているはずだ、伝わっているはずだ、から始まる行き違いは多々あるものと思います。自分自身もコミュニケーションを取る際の心得として、今後に役立てたいです。詳しくは、ぜひ一度、著書を手に取って読んでいただければと思います。
まず我が家では、妻との家事分担でのやってほしいことを互いに定義することから始めます。
(自分ではちゃんと家事を済ませたはずなのに、妻から物足りないと言われることがいくつかあったなあ、と)。
著者の清水亮さんは、イベントスペースでの講座や成蹊大学での講義を基に執筆されたとのことで、こうした教養の授業があれば、ワタシも学生のころに受講したかったです。
清水亮さんHP
https://wirelesswire.jp/author/ryo_shimizu/
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?