ビジネスを変える「ゲームニクス」

「ビジネスを変える「ゲームニクス」」
サイトウ・アキヒロ（著者）

4時間くらいを1回で読了．ゲーム機の写真やゲームのスクリーンショットをふんだんに使ってゲームニクスを説明してある本でした．本書はどうやってゲームニクスという考え方が生まれたのか簡単に説明し（1章），実際のゲームで用いられているゲームニクス理論の解説（2章），ゲームニクスを応用したサービスの事例の紹介（3章）という流れで進みます．
これを読めばゲームニクスを用いてすばらしいサービスが提案できるようになる！という本というより，問題解決の方法の1つとして引き出しを増やすことができるという感じです．点を増やすような気持ちで読むといいと思います．

何かしらのサービスを提供するんだ！という気持ちを持つ限りUIやUXの勉強はしなきゃいけないとは思ってたんですが，中々後回しにしてしまっている現状．UXとかUIとか考えれば考えるほど狙ってそんな事できるの，とかマイナスな感情しか抱けなくなってきたのですが，本書を読んで，少し頭がすっきりした気がします．
兄や父の影響があって子供の頃からゲームと身近だったんですが，実際に自分が遊んだゲーム（マリオとかカービィとかゼル伝とか）でゲームニクスが説明されていました．自分の体験をもとに説明を読む事ができたので，よりわかりやすかったです．もしUIやUXについて興味はあるけどよくわからないんだよな，難しそうだな，という人でゲームが好きな人にちょうどいいのかもしれません．
それにしても，小さい自分がクリアできないゲームを投げ出さずに頑張ってしまうミソが沢山組み込まれていた事を知って，ああまんまと大人の罠にかかっていたんだとびっくりしました．でも沢山のノウハウがこめられていたことを知って，何かこう極まるものがあります．著者が語ったそそぐ愛ではなくてささげる愛というのはこういうことなのかあと思いました．

いちばんやさしい教える技術

「いちばんやさしい教える技術」
向後千春（著者）

8時間を1回で読了．文章の言い回しがとてもわかりやすかったので，本当は5時間くらいで読みきることができると思うのですが，今回は読みつつまとめを行ったので，ずいぶん時間がかかりました．その成果物をあげながら簡単に内容をまとめてみます．

まずは1章のまとめ．どんな人でも何かを人に教えること，先生になることはあると思います．例えば私だったら，大学のTAとしてTeXやCを学部生に，母にはPhotoshopやiPhoneの使い方だったりを教えたり，など．普段を振り返ると結構な頻度で小さなことから大きなことまで教える機会がある気がします．そんな時に多かれ少なかれよく思うのが「なんでこんなこともわからないの!?」というイライラ感情です．それを解決してくれるのがインストラクショナルデザインという学問です．この本はその基礎となる部分をわかりやすく説明しています．

続いて2章のまとめ．この章では教える際のルールについて触れています．よくある先生像から，問題点をあげどうするべきかをまとめたのが教え方のルール10ヵ条というものです．図では左下に本文からそのまま引用しています．はじめから10ヵ条すべてを実行するのは大変だと思うので，自分の足りてないところから気をつけてみようと思います．

最後に3章から7章までのまとめです．教える課題を運動スキル，認知スキル，態度スキルの3種類にわけて，それぞれにあった教え方が提案されていました．少しずつ確実に進むスモールステップの話は特に納得できました．運動スキルで取り上げられていた話ですが，大抵の課題に対して使っていける気がします．今度何かを教える機会を得たら，スモールステップを実践してみようと思います．

余談ですが，最近ノウハウ本を読んでて思ったことで，本を読んだ後に，そこで得たノウハウを振り返りづらいなあと悩んでました．ということで紙に書いてまとめながら読んでみました．視覚的に覚えておくことができるので，頭の引き出しに収納しておきやすいです(このことから私は視覚型だと気付きました)．ついでに，動的にまとめる練習ができて一石二鳥です．しばらく続けてみようと思います．

ファシリテーション・グラフィック―議論を「見える化」する技法

「ファシリテーション・グラフィック―議論を「見える化」する技法」
堀 公俊，加藤 彰（著者）

4時間を1回で読了．
読んでからかなり時間があいてしまった．
この本は，話し合いの見える化によって，ハッピーな話し合いを目指すファシリテーション・グラフィックの基礎から実践について，非常にわかりやすくまとめた本だ．

この本を読んでいると，小学生の頃の宿題だった，社会見学新聞を思い出す．
小学生の頃，消防署やテレビ局，工場など様々な場所へ社会見学に行った．その度に1人A4用紙1枚の新聞を発行するのだ．ずいぶんと昔の話なので，詳細は忘れてしまったのだが，非常に楽しい思い出がある．前もって調べたこと，見聞きしたこと，わかったこと，感想などを，見てくれる人がわかりやすいように，自分なりにまとめるこの作業はなかなか骨が折れるけれど，楽しかった．小学生の宿題といえど，単にまとめるだけじゃなく，表にまとめてみたり，アクセントにイラストをいれてみたり，囲いにこだわりをいれてみたり(テレビ局新聞だったらブラウン管テレビで区切ったり)と中々こだわりポイントは多い．鮮やかで分かりやすい新聞が発行できたときには，よく祖父母にまでお披露目したものだ．小さい頃にそんな経験をしたおかげなのか，ファシリテーション・グラフィックの技術的なことについてはすんなりと飲み込むことができた．

しかし，大きな問題を抱えてしまった，もとい気付いてしまった(ありがたい話なのだけれど)．
ファシリテーション・グラフィックはリアルタイムで社会見学新聞を作るようなものであるということだ．どんどん増えていく情報を取捨選択しながら，わかりやすくまとめ，話し合いを支えるのだ．つまり，ロジカルシンキングで情報をまとめなければならない．普段の会議を思い出すと頭がくらくらする．まるで得体の知れぬ生命体と戦うみたいだ．もとより私はロジカルシンキングが大の苦手で(おかげさまで卒業研究は苦労した)，いまだに筋の通ってない意見を主張してばかりな気がする．勉強しなければいけない，とはなんとなく思っていたけれど，今度こそ見て見ぬふりはできない．
ハッピーな議論のためにグラフィッカーになりたい！　と思ったので，グラフィッカーの経験をためながら，ついでにロジカルシンキングの練習もしてしまおうと思う．

それから，面白そうな本を紹介してもらったので，今度読んでみようと思う．
「4日で使える 実践! 超ビジュアルシンキング」

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」
Dustin Boswell，Trevor Foucher (著者)
角 征典 (翻訳)
須藤 功平 (解説)

4時間を2日，計8時間くらいで読了．日本語が軽快で，うんうんと素直に頷きながら読み進めることができた．とはいっても，その内容はずいぶんと骨太かもしれない．これから先，何度も見返すことになりそうだ．ひとまずKindle版リクエストを押しておいた．
今日書いたコードをいじる未来の自分に楽をさせたい人なら，人の感想なんて読んでいないで，本書をすぐにでも読むべきなんじゃないだろうか，とか思わないでもないけど，自分なりにまとめてみようと思う．

本書は最初から最後まで，様々なプログラム言語での例を交えながら，リーダブルコード（＝読みやすいコード）とはどんなものかをわかりやすく伝えてくれる．基本的には，まずリーダブルでないコード（＝読みにくいコード）の例をあげ，そこからどこが問題なのか，どう改善していくのか（時には何通りかの思考法がある），その結果リーダブルでないコードがどうリーダブルになったのか，が1セットになっている．
これのおかげで，リーダブルコードとはどんなコードなのか，どうしていいものなのがよくわかる．隣でプロのプログラマに指導してもらってるってこういうことなんだろうか，とか少し考えたりもした．

さて，本のレビューなんて積もるほどありそうだから，ここで学生チームの開発経験1年ちょっとの駆け出しの私が，特に注目した点に焦点を当てることにする．それは，14章の「テストと読みやすさ」の14.8節「テストに優しい開発」だ．

 // 引用ここから
あとでテストを書くつもりでコードを書くと，おもしろいことが起きる．テストしやすいようにコードを設計するようになるのだ！　このようにコードを書いていけば，いいコードが書けるようになる！
　テストに優しい設計をすれば，振る舞いごとにうまく分割されて，自然にコードが構成されていく．
// 引用ここまで

学部3年の授業によくある電卓の開発を行う(使用言語はJava，環境はEclipseだった)授業があった．そのときにテスト駆動開発（TDD）というものに初めて出会った．しかし，それからずっとテストが苦手だ．テストがすごい！ありがたい！というのはわかるのだけれど，自分でテストコードを書こうとすると，ううんと頭を抱えて動かなくなってしまう．このプロジェクトは絶対にテストファーストで開発を進めるぞ，と心に決めても，駄目なのだ．結局諦めてテストコードを書かずに手でテストを行ってしまうのだ．
本書では，テストファーストはさておき，上記で引用したことに重きを置いていると思う．これまで私は，テストコードを書くことばかり考えていたが，本書のおかげで自分がテストしやすいようにコードを設計すればよいのだということに気付くことができた．
いわれてみれば当たり前のことなのだろうけれど，テストに対する苦手意識は軽減した気がする．明日からはぜひテストしやすいコードの設計に気を使ってみようと思う．

最後に，テストの話に注目をしたが，他にも言語にとらわれない技術を身につけるノウハウがたっぷり詰まっていた．駆け出しプログラマは第1部だけでいいから，必ず読むといい．幸せになれる．まあ，第1部を読み終わった頃には次が読みたくなっているだろうけど．
また，日本語版のみについてくる須藤 功平さんによる解説がリーダブルコードの解説にあるので，興味のある人はこっちもどうぞ．

はじめて本の感想らしきものを書いてみたけど，難しいもんだ．何かつっこみがありましたら，コメントから（優しく）よろしくお願いします．