読者です 読者をやめる 読者になる 読者になる

おじさんの適当ブログ

技術のことやゲーム開発のことやゲームのことなど自由に雑多に書き連ねます

SHIROBAKOいまさらながら見ました

もう最高すぎました。モノづくりに対して色々と考える良い機会になりました。感想をだらだら書こうと思いましたが最高の一言だけで!

 

今、Amazonプライムで見放題なのでまだ見ていない方は是非!

「書くときに考える」のではなく「書くように考える」

最近、ブログを書き始めて思ったことです。

「結論を出せた!きちんと整理できた!」と、思考を中断してしまっていることがよくあると気づきました。この時点では"中断"という認識はなく、"解決"したという認識です。ですが、実際は"解決"ではなく"中断"です。もっと悪いと"放置"のこともあります。

そしていざブログを書き始めてみると、「もっと考える余地があるな」ということに気づきます。はじめから記事を書き起こしているつもりで考えるようにしてみようと思います。アウトプット前提だと効率上がるよ的なアレです。

アウトプットを前提にすることで得られる様々なメリットを認識しているつもりでしたが、自分が頻繁にアウトプットする立場になって初めて実感できました。これもまたなんとなく理解した気になっていて、"中断"もしくは"放置"していたのかもしれません。自分の考えとして落とし込めていることを意識する必要もありそうです。

考えていることを記事にするかどうかは別として、とりあえずタイトルにある思考法で頑張ってみようと思います。アウトプット前提!

「八百万の人の思い」的なモノの見方のススメ

はじめに 

八百万の神」という言葉、日本人ならほとんどの人が聞いたコトのある言葉だと思います。勉強嫌いで、ろくに本も読まなかった私が幼い頃から知っているくらい有名な言葉だと思います。「万物に神が宿るとし、それらを崇拝する」という感覚、すばらしいですよね。

今回の記事は、この八百万の神という崇拝スタイルに習って、「万物に人の思いが宿るとし、それらを考える・リスペクトする」ということを意識して物事を観察してみると世の中がもっと面白く見えるよ!という記事です。これを「八百万の人の思い」と呼んでいます。微妙に語呂が悪いですがそれは言わない約束。

きっかけ

私は最近、散歩にハマっています。目的は気分転換です。天気がいい日はそりゃもう最高にリフレッシュできます。

ゆらりと散歩していると、街の中にある様々なものが目に入ってきます。初めのうちは、それらを全く気にしていませんでした。風景を見るというよりは、安全に道を歩くための情報を取得しているにすぎませんでした。ウォークマンから流れるお気に入りの曲達やツイッターに意識を奪われていたからかもしれません。

ある日、ウォークマンを洗濯機にぶちこんでしまうという事件が発生しました。ウォークマンはもちろんお亡くなりになりました。「今日は曲なしだな・・・」という憂鬱な気分で散歩へ。悪いことは連鎖するもので、少し歩いてからスマホを忘れたことに気づきました。こうして、手ぶらで散歩することになりました。

そうすると、いつも意識していないものが自然と目に入ってくるようになりました。やがて、お姉さんが店頭ボードに色々書いては消し、書いては消しを繰り返していたのが目に入ってきました。店頭ボードに、その日のおすすめメニューやランチメニューを書いているようでした。このときに、モノに宿る人の思いの存在に気付かされました。それ以来、目に入ってくる様々なモノをどんな思いを込めて作ったんだろう」と意識すようになりました。

手書きのボード、道端にそっと植えられた花々、誰が見てるかわからない掲示板に貼られた様々なチラシ、バス停の脇に置いてあるおそらく近所の誰かが提供したボロボロの椅子などなど、人の思いが込められているであろう物が街中にはあふれています。もちろん家の中にもたくさんあります。私が今使っているMacbook、毎日使う調理器具や家具、世にある様々なソフトウェアやWebサービスなどなど・・・これらは、すべて人によって作られたものです。言われてみれば当然のことですが、ついつい忘れがちなことでもあると思います。

どんな効果があったか

どんな思いを込めて作ったんだろう」と意識するようになってから、街を歩くのが一層楽しくなりました。散歩だけでなく、旅行の際に観光地を練り歩くのも非常に楽しめるようになりました。実際には思いが込められてないものもあるかもしれません。それでも、「何かあるはずだ」と色々妄想してみるのは楽しいです。

いつもと異なる思考を巡らせる良いきっかけになります。異なる思考の強制は、気分転換にも効果バツグンです。思考を完全にリフレッシュすることで、より良いアイデアが思いつくことも何度かありました。

いろんなモノに注視する癖がつくので、アンテナの感度も良くなっていってるような気がします。

 

なんか面白そうだな、と思ったらぜひ試してみてください!

 

コードレビューに対する自分なりの考え方まとめ

はじめに

私はコードレビューするのもされるのも好きです。自分の知らないことをたくさん知れる良い機会ですし、それを簡単にみんなに共有できる場でもありますし、場合によっては熱い議論の場になることもあります。色々なきっかけを作ってくれます。

自分以外のコードレビューの内容をメールで届くようにして、それらすべてに目を通していました。その場でふむふむと思ってもいざ自分で書いた時に忘れてることもよくありましたが・・・無意味。

コードレビューの様子を1年間観察してみて、色々思うところがあったので、だらだらと書いていきます。コードレビューに対する自分なりの心構えや姿勢について書いています。具体的なコーディング規約に関する話は一切しません。具体的には以下のようなことです。

  • なぜを意識した指摘内容になっているか
  • レビュー対象はソースコードだが、それを見るのは人間
  • レビューは本当に人がやらなければいけないのか
なぜを意識した指摘内容になっているか

「なぜその修正が必要か」を書かずに「このように修正しなさい」だけ書かれた指摘をよく目にしました。

プログラマになってまだ日の浅い人やプロジェクトに配属されて日の浅い人は、指摘された理由がわからないこともあります。指摘されたからとりあえず直すという状態になってしまうと、せっかくの学習機会が失われてしまいます。自分で調べて自己完結するのも良いですが、コードレビューという対話の機会を活かすのも手だと思います。

理由を理解せずに修正した場合、誤った修正をしてしまうことが多いです。誤った修正をすると追加の修正に余計な時間がかかるだけでなく、精神的ダメージも大きいです。理由が理解できていると修正が的確になることに加え、議論が深まりやすいです。議論の末、より良い修正案やコーディング規約の変更などに発展することもあります。これはすごく良いことだと思います。

指摘する側は、理由を書くことを意識し、指摘される側は、理由が書かれていなければ質問する、といったようにお互い意識することが大事かと思います。

レビュー対象はソースコードだが、それを見るのは人間

テンションが下がってしまいそうな言葉使い・口調の指摘を何度か目にしたことがありました。

レビューの対象はソースコードですが、指摘を確認して修正するのは人間です。指摘事項を読んだ人のテンションが下がったり、嫌な思いをしないかを意識するのは大事だと思います。コードレビューが気分が乗らないものと認識されてしまうと、前述した議論の発展はほとんど望めないと思います。

ちなみにですが、これは指摘を控えなさいということではありません。指摘することはしっかり指摘して、それが嫌な思い出として残ってしまわないように配慮しよう!ということです。

そのレビューは本当に人がやらなければいけないのか

プロジェクトごとにコーディング規約があるかと思います。コーディング規約には、「少し細かいことだが、そのプロジェクトでは必要とされていること」が定められている場合もあります。

些細な指摘の内容によっては、レビューする側もされる側もうんざりしてしまうことがあります。コーディングは楽しい作業であるはずなのにうんざりした気持ちになってしまうのは悲しいです。些細なことだとそれが何度か繰り返されることもあります。何度か繰り返されると、繰り返した分だけうんざりしてしまうわけです。

「そもそもその規約が必要なのか?」をまず考えると思います。不必要であれば規約から排除してしまえばいいと思います。必要だと判断される場合はそうもいきません。必要であれば、それを機械に任せられないかどうか考えます。一般的なコーディング規約であれば、世にある様々な便利ツールやLintを使えば対応できます。コードをコミットする前にツールにかけて規約から外れている箇所を検出し、それを修正する。これであれば、自分で完結しているのでストレスにならないかと思います。

しかし、プロジェクト特有のコーディング規約の中にはツールでフォローできないことも多いかと思います。C#であれば、RoslynのAPIを使って独自の静的解析ルールを拡張したりもできます。独自の静的解析ルール追加にはそれなりにコストがかかります。時間効率が良くなり、うんざりもしなくなると思えば、コストに見合う効果があると思います。

さいごに

精神的なストレスを緩和するような話が大半となってしまいました。毎日のように行われることなので、ストレスなく進められるかどうかは非常に重要だと思います。コードレビューが辛くなってしまうと、ただのプロセスの1つと捉えられがちです。これでは良いレビューはできないと思います。

変なことを色々と書いているかもしれませんが、これを読んで「コードレビューを幸せなものにしよう!」という意識が少しでも芽生えたなら嬉しい限りです。

ゲーム制作で利用しているMilanoteとChatworkの話

私は友人と2人でオリジナルゲーム制作をしています。2人の本職はそれぞれ、エンジニアとアニメーターです。エンジニアがコード書く人、アニメーターがデザインする人とざっくり役割分担しています。私はコード書く人です。それ以外のことは2人でアイデアを出し合いながら進めています。

イデア出しやコミュニケーションを円滑にするために、ChatworkとMilanoteを利用しています。Chatworkはその名の通りのチャットツールで、Milanoteは思考を助けるツールでWeb版ホワイトボードみたいなものです。せっかくなのでそれぞれのツールの使い分け方や所感などを雑多に書き残しておこうと思います。

www.chatwork.com

milanote.com

使い分け

制作しているコンテンツに関する議論はMilanoteを、進捗報告などにはChatworkを使っています。こう使い分けよう!と決めて使い始めたわけではなく、使っていくうちに自然とこういう使い分けになりました。

Milanote

Milanoteでは以下のような事柄をノートとしてガンガン追加していきます。

  • プロット
  • スキルやステージギミック
  • キャラクターやUIのデザイン
  • その他、仕様が不明確だと思ったこと

お互いが追加された項目に反応して、議論を広めていきます。Milanoteは、前回からの差分を表示してくれる機能があるので、変更があった部分も非常にわかりやすいです。

加えて、自分のタイミングでじっくり考えて、意見を書けるので議論も深まりやすいです。対面でのミーティングだと場所だけでなく時間の制約もあるので、議論が思うように深掘りできないこともあります。場所・時間の制約を取っ払えるのは非常に良いです。Milanoteでは文字だけでなく画像のアップロードもできるので、デザイン関連の議論も非常に進めやすいです。ただし、動画はアップロードできません。

実物のホワイトボードにある空間の制約が、Milanoteにはありません。したがって議論をどんどん発散させていくと、Milanoteのボードもどんどん広がっていきます。私は、15インチのMacbook Proを使っていますが、すぐに画面に入りきらないサイズのボードになります。ボードがあまりに大きいとストレスになります。Milanoteではテキストや画像の他に、別のボードへのリンクを貼る機能があるので、それでうまくカテゴリを分けるなどしないと、たちまちカオスなボードになります。ブレストのために利用しているのでカオスでも構わない、むしろカオスのほうが良いのでは?という意見もあると思いますが、思考の妨げになるレベルのカオスはちょっとなぁと思います。

もう1つのカオス化対策として、ボードの左上に「制作理念」や「志」を常に掲載しています。自分たちのゲーム制作に対する想いを言葉にし、常に目に入る場所に置いておくのはカオス化対策として効果絶大です。

Chatwork

Chatworkでは以下のようなことを書いています。

  • 今進めている作業の進捗報告
  • インディーゲーム制作に関連するイベントの情報共有
  • ゲーム制作に関連する記事の共有
  • ミーティングの調整
  • 動画を共有したいとき(Milanoteには動画をアップロードできないため)

そのほか、Milanote上で議論が発散しすぎて収集がつかなくなった場合に、意見や方針固めのためにChatwork上で議論することもあります。チャットツールの構造上、議論が自然とシングルスレッドで進むので、収束させるのに向いていると思います。

SlackではShift + Enterで改行ですが、ChatworkではShift + Enterで改行ではなく投稿されてしまいます。はじめはこの違いに慣れず、途中で文を送信しまくっていました・・・Slack⇄Chatworkあるあるではないでしょうか。

議論内容を保管したい!しかし・・・

Milanoteを無料版で運用しているので、1人あたり100個までしかノートを追加できません。料金プラン( https://www.milanote.com/plans/ )は3つあります。ノートの数に限りがあるか、ホワイトボードを複数人で使うかといった違いがあります。複数人で使うなら「Professional Team」プランが割安になるので良さそうです。

趣味の開発なので、できるだけお金はケチりたいところです。ただ、複数項目の議論を並行に進めて、かつ、過去の議論内容もすべて取っておこうとすると、すぐに限界を迎えてしまいます。

Milanoteにはエクスポート機能があります。PDF, Word, Markdownなど、さまざまな形式でエクスポートできます。見た目をそのまま保存したいのであれば、PDF保存が良いです。そのほかの形式のエクスポートはただの過剰書きとなってしまい、後から見た時にちょっとわかりづらいです。しかし、PDFエクスポートは日本語対応されていない、ノート間の関連を表す矢印がグチャグチャになるという悲しい展開が待ち受けていました。こんなことになります・・・改善されることを期待。

f:id:subarunari:20170408141944p:plain

なので、スクリーンショットを取得して議論内容を保管することにしました。文字をコピペしたいこともあるかもしれないので、一応Word形式でもエクスポートしています。議論が終わったら、スクリーンショット取得とWordエクスポートをして、それらをGoogle Driveに配置。それぞれ配置されていることを別の作業者に確認してもらい、確認が取れたらMilanoteから対象のノートを削除します。この運用だと定期的にノートを削除することになるので、ホワイトボードが散らからないというメリットもあります。たった$10〜$12/月と安いので、お金を払ってしまったほうが楽かもしれませんが。

さいごに

以上、コミュニケーションツールの話でした。読み返すと全然大したこと書いてないな・・・この記事が誰かの何かのきっかけになれば幸いです。

やや脱線しますが、Milanote上に欲しい機能投票があるのはおもしろいなーと思いました。

 https://www.milanote.com/poll 

個人的には「Video Card」あたりがあると嬉しいのですが、投票数は結構少ないです。うーん確かに思い返してみると、動画が欲しい状況はあまりなかったし、動画へのリンクで代替できるので優先順位としては低いのかもしれませんね。デスクトップアプリの投票数が1位です。オフラインでも作業できるようになると便利そうなので、これは期待です!

やりたいことをやることにしたときの話

4月は新しいものごとが始まる時期ですね。前向きな気持ちで迎えられる人もいれば、少し後ろ向きな気持ちのまま迎えてしまった人もいると思います。

「自分のやりたいことを自由にやってみる」

私はそのために無職で4月を迎えました。もともとは転職するつもりでしたが、転職活動をやめてしばらく無職でいることを選択しました。オリジナルゲームの開発と勉強に注力するためです。ゲーム開発はUnityで、勉強はゲーム開発に限らず基礎的な内容を勉強し直しています。前向きな気持ちで4月を迎えられています!

と、さらっと書きましたが、「自分のやりたいことを自由にやってみる」決断を下すのにひじょーーーに悩みました。悩みの一番の原因となったのは一般論といわれるようなものでした。

「会社で働いているのがふつうだよ。」「無職の期間はなるべく作らないほうがいいよ。」などなど、誰が言ったのかも誰から聞いたのかもわからない、それでもなぜかそう信じてしまっていることがありました。一般論がいつの間にか自分の意見になってしまっていました。情けない限りです・・・自分で決めているつもりが、そうではない状態って様々なシーンでありえる気がします。

なぜかそう信じてしまっていること=自分の意見でないと気づいてからは、やりたいことに一直線に進む決意ができました。諸々の選択肢の価値基準が明確になりました。やってみた結果、一般論と同じ意見に落ち着くかもしれませんし、自分なりの意見が生まれるかもしれません。でも、後悔することはないと思います。

なぜか信じてしまっていること=ブレーキとなってしまっている方が色々と見つめ直すきっかけになってくれればいいなぁと思い、この記事を投稿しました。私のような若造に言われるまでもないかもしれませんが!

一応書いておくとずっと無職のままではありません。5月中旬に転職活動を再開します。これはもちろん自分の意思で決めたことです。あと1ヶ月、全力でやりたいことに取り組みます!作り上げたオリジナルゲームはインディーゲーム展等に出展する予定なので、機会があればプレイしていただけますと幸いです(最後に宣伝みたいになり申し訳ありません・・・)。

「コーディングを支える技術」を読んで

先日読み終えたので長らく放置していたブログに感想を。すでにいろんなところで書かれているので何番煎じかわかりませんが・・・ちなみに章ごとの感想などは一切書いておりません。

どんな本?

公式ページ:「コーディングを支える技術」著者公式ページ

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

 

「ある文法を使って何ができるか」だけではなく、「なぜその文法が存在するのか」ということが歴史的経緯と共に書かれています。それらの内容について学べるだけでなく、「言語思想や文法に着目する姿勢」も身につけられる本であるという印象を持ちました。

この本をおすすめするならどんな人?

全くの未経験者よりも、アプリやツールを作った経験がある人が読んだほうが得ることが多いような気がします。コーディングをほとんどしたことない人にとっては、読むのがツライところもあるかもしれません。

今の時期は、はじめてコーディングをする人が多い時期だと思います。新入社員研修や大学の講義などなど。だんだんコーディングできるようになってきた!という時期に復習も兼ねて、この本を読んでみると色々と気づきを得られそうです。読み進めやすいので、はじめての技術書としてもちょうど良さそうです。読み終えたあと、コーディングそのものに対する印象も少し変わっているのではないでしょうか。

感想

プログラミング言語に関するいろいろな概念を一通り復習することができました。それだけでなく、新たな言語やツールを触る際に「なぜを意識すること」を習慣化する良いきっかけになりました。今回「コーディングを支える技術」を手に取ったのは、このきっかけづくりのためでもあるので、目的達成です。目的達成できたのは、この本が楽しく読み進められるようになっていたおかげだと思います。つまらないと感じる内容だったら、きっかけにならなかったと思います。

つまり良い技術書だと思うということです!

モチベーション

せっかくなので、一番最後にこの本を手に取った経緯を。

私はなにかを作る時、「さっさと作りあげたい」という思いが先行しがちです。「これを使えば実現できるから、とにかくこれを使っておけばいい」という思考に陥ってしまうことがよくあります。仕事の時は当然吟味しますが、趣味で色々触っているときには「とりあえず動けばいい」思考に陥りやすいです。そして、しばらくして振り返ってみると "書き方・使い方だけわかる"  という残念な状態になっていることがよくありました。非常にもったいない時間の使い方をしていたなぁと反省です・・・趣味だからこそ自由にできて学習の幅も広がるというのに・・・。

そしてある時、自分が「言語やツールがどのような歴史を歩み、どのような思想を具現化しており、どのような動作原理なのかをあまり理解せずに使っていること」に気付かされる出来事がありましたそれは自分が思い描くエンジニアの姿でないことにも気づきました。その現状から脱却するための起爆剤としてこの本を手に取ってみました。結果としては、感想にも書いた通り良いきっかけとなったように思います。

本から学べることは読み手が置かれている状況やタイミングによって変わると思いますが、一度読んでみるといい刺激を受けられるかもしれません。