CEDEC2019の心理的安全性の講演資料がとても良かった
今年はUnite2019に参加することを優先したためCEDEC2019には参加できなかったけれど、公開された資料を見て学んでいく。
自分もチーム開発で大事にしている「心理的安全性」をテーマにした講演が3つあったのが印象的だった。
そのうちの2つが、特に感じることがあったので、メモっておく。
「言える化」の重要性と攻撃力
では，心理的安全性を高めるにはどうすればいいかというと，「言える化」の推進が必要だという。言える化は「思い込みを取り除き，気軽に発言できる。不確かなことでも発言できる」「新入社員やベテランの区別なく相談ができ，助けを求められる」「問題や間違いを互いに指摘しあえる」といった3段階からなっており，これを進めることが心理的安全性の高さにつながっていく。
「言える化」の推進には同意で、自分もできるだけ「忖度無し・空気を読まずに意見を言う」を心がけるようにしている。
ただ、それ以上に気をつけないといけないと思っているのは、「言える化」は「言いたい放題に言われる化」でもあるということ。
チームが「言える化」に賛同して率直なフィードバックや批判が飛び交うようになると、自分自身に対してある程度批判的な意見が飛んでくることになる。
また、他人を見下して自尊心を高めようとする人や、キツイ指摘・言葉の使い方を改めようとしない人たちが「心理的安全性の言える化を実施してるんです」と隠れ蓑にする可能性もありうる。
「言える化」はゲームでいうところの「攻撃力超アップ」に近いと思っていて、それだけ達成してしまうと、高まった攻撃力によってチーム内で同士討ちが起きる恐れがある。
そのため、「防御力」を高めることがまず大事だと自分は考えていて、その方法についてもう１つの心理的安全性に関する講演で説明していた。
心理的安全性を高め「気づき」を尊重する生産性の高いチームを目指して
心理的安全性を高め「気づき」を尊重する生産性の高いチームを目指して ～ティール組織・マインドフルネスのチームへの導入の試み～
チームの心理的安全性パラメータを観測する
まず、こちらの資料で良いなぁと思った点は、メンバーのHPや攻撃力、防御力などの本来見えないパラメータをwevoxを使って観測しようとしているところ（もちろんこれで全て分かるはずはないけれど、それでも感覚・印象値だけのゼロ観測よりは指標になる）。
「エンジニアリング組織論への招待」でも以下の記述がある通り、そもそも観測できてないものは改善しようとしても変わったかどうかが分からないから改善しようにもない。
観測できるもの/できないもの
このとき重要なのは、本来コントロールできないはずのものをあなたの行動で変化させようと試みるときには、その対象が「観察できる」必要があるということです。なぜなら、「観察できない」ものは、どんなに行動したとしても変わったのか、変わらないのかわからないからです。
広木 大地. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) (Kindle の位置No.866-868). Kindle 版.
なので、「今のチームには心理的安全性が無い！」と思って改善行動に乗り出す場合は、まずwevoxなどを使って観測できるようにしたほうが良いなと思った。
メンタルの防御力を高める
講演資料の中で凄くいいなぁと思ったのが、S.I.YというGoogleで生まれたマインドフルネス研修をチームメンバーで実際に受けているところ。
マインドフルネス瞑想とかに疑わしい感想を持つ人もいるけれど、自分は自分の感覚・印象よりも観測データにもとづく科学検証結果を参考にしたいタイプなので、実際に効果がある可能性の行動は取り入れたいと思っている。
そういう意味で、上のマインドフルネス研修の中でやっているレジリエンスやセルフコンパッションは、メンタルの防御力を高め、その結果他人のアドバイスや批判を受け入れられる力がつくことが期待できる。
この、「他人のアドバイスや批判を受け入れられる力（謙虚さとも言える）」がとても重要だと思っていて、フィードバックを受け入れられてこそ自己の成長へコンバートできるようになる。
逆に、心理的安全性の高い環境に、フィードバックを受け止める準備ができてない人が入ってしまうとメンタルが病んでしまう可能性が高いんじゃないかなぁと個人的には感じている。
「言える化」を隠れ蓑にして他人を見下して自尊心を高めようとする人がいたとしても、メンタルの防御力で一旦受け入れた上で、「その指摘内容は見下してる感じがしたので良くないよ」とフィードバックを返せる関係性が大事だなぁと思う（まあそこで更に喧嘩になるかもしれないけど、そうなるような人はチームメンバーとしてどうかと・・・）。
まとめ
心理的安全性が確保されるとネガティブフィードバックが飛び交うようになり、チームの攻撃力が超アップする。
それによる同士討ちを避けるために、チームメンバー全員がそういったネガティブフィードバックを受け止める防御力を鍛えておくのが必須だと思う。 kidooom.hatenadiary.jp
ネガティブフィードバックを受け止める力は成長マインドセットだけでなく、セルフコンパッションやレジリエンスなど心理学の世界が役に立つ。
「自分は自分を褒める役割で、他人は自分の悪いところを指摘してくれる役割」はとても良い言葉だと思った。 kidooom.hatenadiary.jp
この辺を踏まえた上で、
「忠誠心より、真実を語ることや柔軟であることを優先せよ」
「批判的な意見を口に出していえないのなら、批判的意見をもつ権利はない」
といった強烈な文化が発揮できると強い組織になれると思っているので、少しずつ広めていきたい。
TGS2019参加してきたレポート
先日、初めてTokyo Game Show 2019 に参加して大いに興奮したので、忘れないようにレポート書いておく。
パワーを持つ"人"を実際に自分の目で視たこと
映像やネット上で何度も見かけている有名人を実際に自分の目で視れることは、こんなにもパワーを感じるだなと感動した。
今回自分の目で視れて感動した人たち
- ウメハラ
- ウメハラ | 格ゲープレイヤーWiki
- 一番好きなプロゲーマーで、「１日ひとつだけ、強くなる」はベースの考え方として真似させてもらっている。
- ときど
- ときど | 格ゲープレイヤーWiki
- 最も誠実さを感じるプロゲーマーで、安定して結果を出し続けていて凄い。著書の「東大卒プロゲーマー」も情熱を感じとれて面白かった。
ふ〜ど
- ふ～ど | 格ゲープレイヤーWiki
- 天才的なプレイスタイルが魅力的で、ひょうひょうとした性格も感じが良い。ウメハラの番組にもよく出てるし、視れて嬉しかった。
どぐら
- どぐら | 格ゲープレイヤーWiki
- ギルティギア勢としても好きで、とにかくトークが面白いので注目しちゃう。
ももち & チョコブランカ夫妻
- ももち | 格ゲープレイヤーWiki
- チョコブランカ | 格ゲープレイヤーWiki
- 初めてももちを知ったのは、スト3 3rdのユン使ってるとき動画で、ものすごい粘りが印象的で未だに覚えている。映画「リビング・ザ・ゲーム」でも夫妻のシーンが入っており、本気で強くなりたいというストイックさが感じられて面白かった。
だから、「人が多い“山”に登らない」っていう選択肢をとれる人が強いんだなと思うんです。
邪道でもいいから、誰もいない山の頂点を目指す、と。
色々勉強になる発言も多い。
- バチェラーシーズン2に出演した福良真莉果さん
- シーズン2で一番面白くていい雰囲気だった方。歩いてる時に一瞬すれちがっただけだったけど、そのオーラで福良さんだと気づいた。
東京ゲームショーなう＼(^o^)／
— 福良真莉果 (@Marika3581) 2019年9月12日
18時くらいまでずっとカプコンブースにいます♪！#MHWアイスボーン #カプコンTGS pic.twitter.com/z4l0WYx5QP
- シーズン2で一番面白くていい雰囲気だった方。歩いてる時に一瞬すれちがっただけだったけど、そのオーラで福良さんだと気づいた。
やりたいゲーム増えた
CyberPunk 2077
これは絶対やろうと思っている。CD PROJECT RED の最新作。
キアヌ・リーブスのキャラも期待。
NEW GUILTY GEAR
前作めっちゃやってた。会社の昼休みにやってた。
表現かっこよすぎる・・・。
一時期、仕事兼趣味でToonShaderを研究していて、ギルティギアの表現が最高峰だと思ったので超参考にしていた。
しばらく時間の関係で格闘ゲームは封印してたけど、NEW GUILTY GEARは流石にプレイせざるを得ない。
ペルソナ5 ザ・ロイヤル
アトラスゲームは全般好きで、ペルソナ５も面白かったのでトロコン目指して２周目途中までやってたところ。
せっかくだから、追加要素があるザ・ロイヤルもやってみたい。
元が面白いゲームだから、そのちょっとした違いが新鮮となってまだまだ面白く感じられそう。
モンハンワールド アイスボーン
Witcherコラボしてるのでずっとやりたいと思ってるけど、やれてない。
龍が如く7
モンハンと同じく、やりたいけどやれてないシリーズ。
写真撮影ブースが面白い雰囲気だった。
まとめ
人混みが嫌で今まで参加しなかったTGSだけど、いざ参加してみたら非常に楽しかった。
自分が好きな有名人を見かけたのは実際モチベーションになったし、やっぱりゲームっていいなぁと思えたのでこの気持ちを忘れないでいきたい。
なんでも知っている超人の神話とハードワークの神話を捨てる
９年振りに読んだ「プログラマが知るべき９７のこと」から学んだことシリーズその２
シリーズ１はこっち kidooom.hatenadiary.jp
35. 超人の神話
何も情報を与えられなくても、あらゆる質問に答え、あらゆる問題を解決できる。そんな人はいません。ソフトウェア業界にそんな「超人」がいるという神話は、そろそろ一掃すべきでしょう。どれほど優れたプログラマも人間であることには違いはないのです。彼らも他の人と同じように、論理的に考え、体系的に分析をしない限り、どんな問題も解決できないのです。経験を積んでいる分、勘がはたらくため、普通の人より早く正解にたどり付けることはありますが、基本的には他の人と同じです。
このトピックを読んだとき、以前読んだこの記事のことも思い出した。 note.mu
質問に答えるという行為は、質問者の背景に潜む膨大なコンテキストを理解した上でないとまともな回答なんてできない。
そのことを、質問者も質問に答える人も理解した上でコミュニケーションを取って、問題を解決していく姿勢が大切だなと改めて思った。
36. ハードワークは報われない
ハードワークは報われない | プログラマが知るべき97のこと
プログラマという仕事は、時に、懸命に働いても意味がない、ということかあります。長時間オフィスにいれば、プロジェクトに多大な貢献をしているような錯覚に陥ることもあゐし、同僚たちもそう思ってくれることがあります。しかし事実はまったく逆で、自分の働く時間や労力を減らせば減らすほど、プロジェクトへの貢献は大きくなると言えるのです。ときには、頑張って働くよりも、働かずに済む努力をした方が、はるかに大きな貢献ができることもあります。神経を集中させる時間、製品を産み出すのに使う時間が週に30時間を超えるようなら「自分は働き過ぎだ」と考えるべきでしょう。自分のかけている労力を減らすことを検討する必要があります。もっと効率的に働く方法、少ない労力と時間で多くを生み出す方法を探さなくてはならないということです。
この週３０時間を超えるようなら「自分は働きすぎだ」と考えるべきの箇所は、先日読んだ「超時間術」にも同様の記述があったので、自分の脳内で情報が繋がってハッとなった。
ある研究では、男女７５００人にアンケートを行い、いつもどれぐらい忙しくしているかを調べたうえで、認知テストの結果とくらべました。
・週の労働時間が３０時間を超えたところから、認知機能にマイナスの影響が出始める
・週の労働時間が６０時間より多いと、普段はまったく働いていない人と同じぐらい認知機能が下がる
週３０時間労働は今までの自分の感覚だと少なく感じるが、集中して仕事の成果を出す時間が３０時間と考え、残りの時間は自己研鑽や自分自身のために使うことでより良い３０時間の使い方ができるようになることを日々意識すると、気づいたら強くなれているのかもしれない。
ストリートファイター３のリュウが勝利時に言うこのセリフが、個人的にはとても好きである。
43. プログラミング言語は複数習得すべき
プログラミング言語は複数習得すべき | プログラマが知るべき97のこと
プログラミング技術の習熟度は、どれだけ多くのプログラミングパラダイムに親しんでいるかによって大きく変わることが知られています。「親しんでいる」とは、名前について知っている、ちょっとかじったことがある、というような程度では駄目で、その言語を使って正しくプログラムを書けるということです。
前回と同様で、関数型言語を新しく学ぶモチベーションが今高まっているので、現在メインで使用しているC#でオブジェクト指向を深堀しつつ、Erlang, Haskell, Scalaのどれかを選んで学んでいこうと思う。
これは、この半期の目標「ゲーム開発」の一部に組み込んで取り組んでいきたい。場合によっては来年のガッツリ目標に入れたほうがいいかもしれない。時間は有限なので、よく考える。
ニーバーの祈りで査定評価を乗り越えるメンタルハック
査定の時期になると評価制度周りで悩むことが今まで多かったが、「エンジニアリング組織論への招待」と「問題解決大全」を読んでからは「ニーバーの祈り」を意識するようになって心理的負担が大分減った。
ニーバーの祈りとは
アメリカの神学者、倫理学者ラインホールド・ニーバー（1892-1971）の言葉で、下記の通り。
神よ、
変えることのできるものについて、
それを変えるだけの勇気をわれらに与えたまえ。
変えることのできないものについては、
それを受けいれるだけの冷静さを与えたまえ。
そして、
変えることのできるものと、変えることのできないものとを、
識別する知恵を与えたまえ。
The Serenity Prayeriƒj[ƒo[‚Ì‹F‚èj
宇多田ヒカルの「Wait & See ～リスク～」にも似た表現があったらしい（全然気づかなかった）。 sugimuratakashi.com
コントロールできるもの、コントロールできないもの
「エンジニアリング組織論への招待」では、直接ニーバーの祈りの言葉は出していないが、「コントロールできるもの、コントロールできないもの」や「観測できるもの、観測できないもの」のトピックで似た概念を言っていると感じた。
何か問題を感じたり、不安を感じたりしたときに、人は知らず知らずのうちに、「コントロールできないもの」をコントロールしようとして、さらに思考が混乱するとか、ストレスに感じてしまいます。
何か、問題を解決したかったり、良い結果をもたらしたかったら、何がコントロールできるのか、そして何がコントロールできないのかを冷静に判断する必要があります。
広木 大地. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) (Kindle の位置No.852-855). Kindle 版.
「観測できないものはコントロールできない」というのはそのとおりで、他人の頭の中は観測できないしコントロールなんてとてもできない。
われわれにできることは何でしょうか。
それは、今まで見てきたように、「コントロールできるもの」を操作し、そして、「観測できること」を通じて、その結果を知識にすることだけです。
私たちは、つい、何か問題に出くわすと、「コントロールできないもの」を操作して、「観測できないもの」を改善するという不可能な問題設定を行ってしまいます。
広木 大地. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) (Kindle の位置No.880-883). Kindle 版.
他人からの評価はコントロールできないが、自分の行動はコントロールできる
今までの自分は、他人の頭の中で勝手に決まる査定評価を気にしたところで結果メンタルに良いことは特に無かった。
このニーバーの祈り的な考えに触れてから、コントロールできない他人の評価結果は気にしないこととし、コントロールができる「評価結果に繋がる行動」の方を意識して増やすようになってメンタルが安定するようになった。
まとめ
というわけで、何かストレスを抱えるような問題が起きた時は、まずはニーバーの祈りを思い出す。
そして、それがコントロールできるものなのかどうかを判別していこうと思う。
9年振りにプログラマが知るべき97のことを読んで学びになった
最近仕事でリファクタリングをやっているが悩ましい部分が多く、ヒントを求めて家の本棚に眠っていた「プログラマが知るべき97のこと」をパラパラ読んでみたら思いのほか学びになった。
本を買わなくても97のことシリーズは全てWebでも公開されている様子（自分はほとんど買っちゃってるけど）。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
この本を買ったのは2010年なので９年振りに読んだことになるが、この９年間の経験が繋がったことで初めて理解できた部分が多く、ほぼ初見に近い感覚で本を読めた。
本に書かれている内容は変わらないが、その本を読む自分自身の脳が常に変わっていて理解度もその時で異なるんだなと感じた。
９７のことのうち、前半３０個までの中から特に印象に残った部分をメモ。
2. 関数型プログラミングを学ぶことの重要性
関数型プログラミングを学ぶことの重要性 | プログラマが知るべき97のこと
リファクタリングで意識する部分として、この章で書かれている「参照透過性(referential transparency)」を高めることが１つだと思う。
グローバル変数を色んな箇所で参照・変更するような可変な部分がバグを生みやすい場所になっていることは確かで、ここをどう修正するか今手こずっている。
wikiに書いてある関数型言語を１個もガッツリ触ったことがないので、参照透過性の考え方を強めるためにも１つは関数型プログラミングを学ばないとなぁと感じた。
Erlang, Haskell, Scalaあたりを考えてみようかなぁ。
7. 共有は慎重に
コードの再利用を容易に促進すると、かえってひんしゅくを買ってしまうのだ、ということを。
考えた結果わかったのは、私が1つ重大なことを見逃していた、ということです。
それは「コンテキスト」です。
例えばシステム内に同様の処理を行う部分が2つあったとしても、両社のシステムにおける役割が大きく異なっていれば、再利用によるメリットは小さいのです。
同じミスを、自分もこの９年間で何度か犯していたなぁと気づかせられた章だった。
再利用を勧めすぎた結果、巨大なUtilクラスができあがって管理しづらくなるようなケースも何度も見たし、作った覚えがある。
私は、システムを構成するコードの絶対的な行数は減らしたのですが、依存しあう部分を増やしてしまったわけです。
こういうミスはとても厄介です。「再利用」は一般的に良いこととされており、たしかに基本的には良いことだからです。コンテキストさえ適切なら、間違いなく有効です。
「共有は慎重に。事前のコンテキスト確認を忘れずに」ということですね。
コーディングをミクロな視点で見ているのか、マクロな視点で見れているのかの違いとも言えそう。
コーディングテクニックばかり学んでいても良いプログラマになれないというのは、こういった視点の違い・コンテキストの理解度によるものでもあるのかなと感じた。
経済学と同じく、ミクロとマクロをバランス良く学んでいきたい。
10. ツールの選択は慎重に
Unityでゲーム開発していると、便利な外部Assetがたくさんあるので労力を減らすためにどんどん流用していきたいとも思うが、ここに挙げられてるようなデメリットも多く存在する。
外部Assetを使うことでその機能を作る最初のコストは減らせるものの、その後のメンテナンスコストがどうしてもかかってしまうので、最近自分が思うには、短期的なプロジェクトもしくは人手が足りなすぎるプロジェクトでは有効だけども、そうじゃないプロジェクトでは慎重にしたほうがいいかなと思う。
短絡的に外部Assetを採用することは、その後のメンテナンスコストを考えると技術的負債を抱えたことにもなると思うので、下の記事にもある通り長期的な開発効率の低減を招いてしまいそう。
ソフトウェア開発において質と開発速度はトレードオフの関係ではなく、早期から質に投資すれば結果的に安く早く開発できる。技術的負債を軽視すると速度は落ち続ける。質への投資の損益分岐点は1ヶ月以内に訪れる / “Is High Quality Software Worth the Cost?” https://t.co/tL3zIPjcM0
— Takuto Wada (@t_wada) July 29, 2019
ここまであげてきたような問題の発生を防ぐために、私は「まずは最低限のツールだけを導入する」という戦略を採っています。よく検討して、どうしても必要と判断したものだけに絞り込んで導入するのです。
というわけで、「まずは最低限のツールだけを導入する」というのが技術的負債の増加を抑えられるバランス取れた戦略だなぁと同意した。
13. コードレビュー
おそらくコードレビューを成功させるために最も有効な方法は、レビューを楽しいものにすることです。
ほんとこれはそう思う。
コードレビューは楽しく！
仕事の全てを楽しくしていきたい。
自分は日々ずっと楽しくゲームをして生きていきたいと思ってるけれど、それぐらい仕事も楽しくなっていればいいじゃないかと常に思う。
先日も厚生労働省の労働環境の問題について挙がった記事が話題になってたけど、「仕事は苦しい」「仕事は楽しくない」という考え方を撲滅したい。
・職員の4割がハラスメントの被害
— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) August 28, 2019
・残業することが美学
・暑い暗い狭いの劣悪な職場環境
管理職がよほど無能でなければこうはならない。おそらく、上層部に頭の固いどうしようもない人たちが居座って権力を持ってしまっているから組織が腐ってしまっている。https://t.co/3VqSWnbUAQ
18. 学び続ける姿勢
これはまあ当然という内容だけど、改めて良いことが書いてあるのでメモとして残しておきたい。
新しく学ぶのは、必ずしもコンピュータ関連技術でなくても構わない。システムが応用されるドメインについて学ぶことも重要で、ある。そうすれば、顧客の求めていることがよくわかり、ビジネス上の問題の解決により役立つシステムを作ることができる。また、自分の生産性を高める方法も学ぶべし。「生産性を高める」とは、一定の労力、時間で得られる成果を大きくすることを意味する。
技術はすごい速さで変化していきます。学ばなければ置いていかれるのは確実です。
すごく分かる。仕事が忙しいとなかなかインプットできず、技術貯金を切り崩し、手持ちの技術だけで作ってしまう。それを数年繰り返すと、あっという間にどんどん技術は新しくなって置いてきぼりに。アート面の根源は技術ほど刷新されないように思いますが、それでも時流ありますよね
— PKY (@pky_blog) August 15, 2019
人間、忙しくなればなるほど更にパフォーマンスが落ちて、もっと忙しくなるというクソ循環があることを学びました。これも学び。
— Jini | ゲーマー日日新聞 (@J1N1_R) August 13, 2019
学び続ける姿勢が好循環を生むことは間違いない。
26. 言語だけでなく文化も学ぶ
言語だけでなく文化も学ぶ | プログラマが知るべき97のこと
新しい言語を学び、その勘所をつかんだら、前から知っていた言語の使い方がそれまでと変わっていることに気づき、自分で驚くことがよくあります。
私は、Rubyを学んだおかげで、C#のdelegateをうまく利用できるようになりました。また、.NETのGenericsの持つ潜在力を十分に知ったことで、JavaのGenericsの活かし方がわかるようになり、LINQを学んだおかげでScalaを楽に理解できるようになりました。
前に、英語学習が脳にもたらすメリットという記事を書いたけど、
各言語には構造や特徴が存在しており、その特徴に応じて使う人の脳の認識も異なってくる。
複数の言語を学ぶことは、こういった言語の背景にある考え方も学ぶことになり、認知能力にも変化が生じる。
これはプログラミング言語においても同様の効果は期待できると思っていて、プログラミング言語の背景にある文化や構造・目的を学ぶことでプログラマーとしての認知能力にも良い変化が生じると予測できる。
Unityが採用しているC#を深く知ることは大事だし、上にも書いた通り関数型プログラミング言語なども理解して認知能力を変化させていきたいなと思った。
28. 「魔法」に頼りすぎてはいけない
「魔法」に頼りすぎてはいけない | プログラマが知るべき97のこと
他人のする仕事というのは、どういうものであれ、遠くから見ているとどうしても実際より簡単に思えてしまうものです。自身が開発を経験していないマネージャは、プログラマの仕事を簡単だと思ってしまいますし、逆にマネージメントの経験のないプログラマは、マネージャの仕事を簡単だと思い込んでしまいがちです。
自分の知らない仕事、自分の直接関わっていない仕事をしている人を尊重するということが大事です。
忘れてはならないのは、「魔法が解けてしまった時は、誰かがかけなおさなくてはならない」ということです。
これは、Googleでさえミスってしまった事例があるので、人間が起こしてしまうバグなんだと思う。
先日も、チームの要のディレクターを追放にしたら、チームが言うことを聞くようになるだろうと考えたP氏が実際にその通りにしてみたら、たった一ヶ月で制作ラインが瓦解し、慌ててるみたいな話を聞いたばかり。洋の東西を問わず、現場を理解してないマネージャのやらかすことは同じだねと思った次第。
— 小林信行 Nobuyuki Kobayashi (@nyaa_toraneko) August 17, 2019
どうすれば自分の中で謙虚さをKeepできるのかなぁといつも課題に感じている。
自分だけでさえ難しいんだから、謙虚さを他人に強制することなんてできないし、謙虚さをKeepできているチームや組織にすることなんてめちゃくちゃ難しいだろうなぁとも思う。
まとめ
9年前に買って読んだはずの本でも、全然自分の血肉になっていなかったことが分かったのは良かった。
こうやってブログにアウトプットする前提で本を読んでるのも効果として出ているので、今後もアウトプットを意識して昔読んだ本を再読していくの有りだなと思った。
Witcherシリーズで英語多読とゲーム開発を学び続ける
この半期の目標が「英語学習」ということもあって、最近は英語多読に力を入れている。
記事に書いたとおり、ゲームやアニメの英語版をターゲットとして楽しんでいるが、自分の今のレベル感だと下記の傾向が分かった。
- 1度日本語で体験済みのコンテンツであれば、「英語音声・英語字幕つき」だとギリギリ分かって楽しめる。
- 自分が好きなシリーズやコンテンツでも、１度も日本語で体験していなければ、「英語音声・英語字幕つき」であまり理解できない。
- 例えば、Witcherシリーズが好きだけどWitcher1や2は初見で英語だと分からない。
- 「英語音声・日本語字幕つき」だと、結局日本語の字幕ばっかり見て英語音声スルーするから意味無い気がする。
というわけで、Witcher1・2のCutSceneを英語で見てたけどよく分からないので、一度日本語でコンテンツを体験してから、英語版をプレイするようにしてみる方針にした。
丁度SteamでWitcherシリーズが激安特価になっているので、1000円前後で各作品が買えてお得。
WitcherシリーズはGDCのコンテンツも大量にあり、英語だけでなくゲーム開発のノウハウ学習にも役立つので、しっかり学んでいきたいなと思った。
何より話が面白くて、英語を苦痛に感じさせない点がポイントだと思う。
英語の次はWitcherシリーズの制作本場であるポーランド語も学びたいなぁ。
「インターネットの次にくるもの」がとても面白かった（part 1)
「インターネットの次にくるもの」は、インターネットの恩恵を受けまくっている自分は非常に興味深く読めた本。
１２のトピックが書かれているので、それぞれを簡単にメモる。
BECOMING
BECOMINGは「なっていく」という意味で、常に変化が行われていく時代になっているということ。
インターネットの普及によって情報の生成と共有が爆発的に進み、人々やテクノロジーの変化のスピードもどんどん加速している。
そんなインターネットが当時どれだけボロクソに言われていたことから、我々は１０年先のことなど想像できないことが分かる。
小さな変化が積み重なって、とてつもない巨大な変化になる。
Youtubeやニコニコ動画が普及する前は、映像コンテンツはテレビ業界など制作会社が作るもので、一般市民は受動的な消費者という立ち位置でしかなかった。
それが今や受動的な消費者たちの多くが活動的なクリエイターにもなっており、昔と今の我々で常識が大きく変化していることに気づく。
このように変化のスピードが速くなっているので、謙虚に永遠の初心者でいられることが大切になる。
これに気づかないでいると、老害化するスピードも加速してしまいそうだなと個人的に感じた。
変化の早い時代だからこそ、「なっていく」に対応できるマインドセットの重要性も必然的に高くなってきている。
COGNIFYING
COGNIGYINGは「認知化する」という意味で、今まさに起こっているAIによる破壊的な変化のことを指している。
チップが小型化され、AIのアルゴリズムがどんどん進化してきたことにより、日常のありふれたものにAIを仕込み「認知化する」ことが容易になってきた。
このような「認知化する」例として、自動車の自動運転や、スマート家電などの変化が挙げられる。
今はまだ人間が行っている多くの仕事がどんどんAIによって置き換わっていくというのは昨今よく聞く話だけど、それはもう避けられない自明な流れになってくる。
アメリカでは７０％の労働者が農場で働いてた時代があったけれど、産業革命によるオートメーションによってその割合が１％にまで下がった流れと同じと言ってもよさそう。
ここで大事なのは、仕事が奪われると考えるのではなく、マシンと共同することによって可能性が拡張されていき、我々がもっと人間らしい仕事に集中できると考えること。
人間がより抽象的でクリエイティブな存在になるべき流れについては、自分が大好きな本である「エンジニアリング組織論への招待」の著者の広木さんがプレゼンやPodcastで話していた内容ともリンクしていてとても印象的だった。
このスライドの４７ページ目あたり。 speakerdeck.com
聴いた。コンピュータに任せる仕事が具体から抽象になってきてることから、人間の仕事もより抽象的になってるという話が特に面白かった。 https://t.co/CTT3uTjnBz
— kidooom (@kidooom) August 26, 2019
まとめ
抽象的だけども示唆に富む内容の本で、いざ記事にまとめだすとめちゃくちゃ文量が多くなって時間がかかると分かったので、一旦ここで区切ってまた別の記事に・・・。
（12トピック中、2個しか消化できず・・・）
12のトピックを使って本書のまとめを引用すると、
ネット化したデジタル世界は名詞（結果）ではなく動詞（プロセス）として生成し（第１章 BECOMING）、世界中が利用して人工知能を強化することでそれが電気のようなサービス価値を生じ（第２章 COGNIFYING)、自由にコピーを繰り返し流れ（第３章 FLOWING)、本などに固定されることなく流動化して画面で読まれるようになり（第４章 SCREENING)、すべての製品がサービス化してリアルタイムにアクセスされ（第５章 ACCESSING)、シェアされることで所有という概念が時代遅れになり（第６章 SHARING)、コンテンツが増えすぎてフィルターしないと見つからなくなり（第７章 FILTERING)、サービス化した従来の産業やコンテンツが自由にリミックスして新しい形となり（第８章 REMIXINNG)、VRのような機能によって高いプレゼンスとインタラクションを実現んして効果的に扱えるようになり（第９章 INTERACTING）、そうしたすべてを追跡する機能がサービスを向上させライフログ化を促し（第１０章 TRACKING)、問題を解決する以上に新たな良い疑問を生み出し（第１１章 QUESTIONG)、そしてついにはすべてが統合され彼がホロスと呼ぶ次のデジタル環境（未来のインターネット）へと進化していく（第１２章 BEGINNING)
といった感じで未来が楽しみになってくる。
