メモ
エンジニアとデザイナーなどなどあれこれについて、相変わらず色々考えていた。とりあえず定期的なアウトプットが重要だったのですごく簡単にメモ
１．エンジニアとデザイナーについて
- そもそもエンジニアとデザイナーの区分けは無い方がいい
- 「出来る人ができることをやる」方がいい
- エンジニアはデザイナーに、デザイナーはエンジニアになる必要はない
- むしろ、それをいかにマネジメントするか、という部分のほうが重要である
結論１：エンジニアデザイナー論において、成熟していないのはマネジメントである、かもしれない。
２．ブログを書いて論を組み立てるときに思うこと、論がもろくなる原因
- 仮定で論は進めることができるが、勉強・資料収集不足でエビデンスが不足する結果、論が脆い
- より良い論を導くには、短い論法ではなく、丁寧に長く論を進める必要がある、ある程度の思考に対する忍耐力、飽きないことも必要。
結論２：論を進める際、勉強・資料収集・集中継続（←語弊あり）が必要である。
３．エビデンスを集める方法
- 過去に頼る
- 実験してみる
結論３：勉強不足なら、その仮定のもと実験してみればいいじゃない！
一旦熊本に帰ります、あと諸々のメモ。
ホテルの中でこの記事はゆるゆると書いています。
ひとまず、ドワンゴに入社して1週間が経ちました。環境整えて、いろいろつくって、デザイナーの皆さんや社員の皆さんとも親交を深めることができています。結構いろんなことを話すことができています。楽しい人が多くて、直感的には多趣味な人が多いなぁと感じるところであります。毎日とても幸せです。
正月にポートフォリオをつくってから、期末テストの為ずっと数学をしていたので、デザインの方は少しリハビリが必要でした。現在少しずつリハビリみたいなものができている所です。
そういえば、僕の本業は数学で、月曜に研究室選択会議があるので、そのため熊本に1日だけ戻ります。また火曜からは出社します。
ここからは雑記です。非常に読みにくい文章になりました。まだまだ練習が必要ですね…。
僕がドワンゴを志望した理由の一つとして、説明会で上げられていた「エンジニアが強い会社内におけるデザイナーの地位向上」に対する取り組みをやってみたい、その上で数学科で培ったロジカルや、エンジニアに対する理解が出来るのではないかという所があります。
ここで、「地位」というのは、単純に偉い偉くないという尺度、これは誤解であり、より正確に言うと、優先度、認識の深さという尺度によるものです。
これに対する解決法や、うまいやり方を僕なりにも考えていますが、考えたのが、「エンジニアはデザインを理解しないのではなく、デザイナーという領域がエンジニアに理解されにくい」ということです。
この理由として一つ思ったのが、「情報発信量」と「製作過程」の違いに大きな差がある様な気がします。ここで、エンジニア（デザイナー）とは、Webで働くエンジニア（デザイナー）を指します。ああ、ここの定義すこし曖昧ですが、会社におけるエンジニアと言われる領域の人と、デザイナーと言われる領域の人のことです。（わかりやすくしようとしたけど、余計わかりにくくなっている）
すごく単純な比較をします。
エンジニア：
情報発信量->多い 製作過程->極度にロジカル、曖昧さは許されない
デザイナー：
情報発信量->少ない 製作過程->ある程度の裁量・曖昧さを許す
情報発信量については、これはエンジニアが文化の違いのように感じます。あと、デザイナーは発信する情報が社内機密情報に引っかかることが多い（最終アウトプットになるため）ので、これも情報発信量の違いをもたらす原因になりうると思われます。
次に、製作過程についてです。これも単純化すると、「明文化のスキル」と「主な対象」と「ロジカルである範囲」です。
まず、「明文化のスキル」ですが、エンジニアは基本的に事細かに明文化する習慣がそもそもたくさんあります、コーディングもそう、仕様書もそう、レビューなどもそう…ですから、ロジカルに明文化することが得意だと言えます。
それに対して、デザイナーは、全体としてはそこまで事細かに明文化する習慣は無いです。
次に、主な対象です。
基本的に、エンジニアが対象とするものはおおむね機械です。ですから、指標はきちんと動くor動かないという所になります。ですから、ある程度作る側も厳密さが要求されます。
しかし、デザイナーが対象とするのは、おおむね人間（社会も含め）です。そして指標はウケるorウケないです。そうすると、ある程度の常識に基づいたロジカルな判断は出来るのですが、それ以上関しては正確に判断するというのはほぼ不可能です。そのため、ある程度曖昧さと裁量が要求されるというか、必然的にそうなってきます。
そして、それをうけての「ロジカルな範囲」ですが、エンジニアはほぼ全てにロジカルが適用されるのに対し、デザイナーには「ある程度の常識の範囲（物理的な面や心理学的な知見によるもの）ではロジカル」に、それ以外の範囲では裁量となります。
これを鑑みると、デザイナーの領域とエンジニアの領域には違いがあります。僕が特に言いたいのは、「デザインはロジカルに基づくものである」というものに対して、エンジニアが理解しようとするとき、上記のようにロジカルな面とロジカルでない面があり、そのため、エンジニアがうまく解釈出来ないという齟齬が発生してしまっていることです。ですから、「エンジニアはデザインを理解しないのではなく、デザイナーという領域がエンジニアに理解されにくい」のかなぁと思いました。
ですから、僕は実験的に、エンジニアに理解しやすくするために、以下の2つを実践してみたいと思います。
①製作過程を明文化して多く公開する
②その際に、ロジカルな部分と、個人の裁量（感想）として行ったところをはっきりさせる。
う〜ん、やはりイマイチ歯切れの悪い文章を書いている気がする…。決して論理的に書いているように見えて、これは全然論理的ではなくて、どちらかと言うと正しい箇所がポツポツと浮いているような感じだな…。いつも疲れた時に書いているからかな…。
そもそも、エンジニアとデザイナーを2つにざっくり分けるという所が正しくなくて、どちらかと言うと「UXデザイナー」「UIデザイナー」「サーバーサイドエンジニア」「フロントエンドエンジニア」などなどと個包装にして議論したほうが正しく言えそうだし、そうあるべきだと思う。出来る人がやれば良いのかもしれない…。大事なのはそっちの認識かも…。
全然推敲も何もしなかったので、支離滅裂な文章になってしまいました。
でもこういう考えてることはこれからも書いていこう。
ドワンゴに入社した。
今回はインターンの扱いだから、正確には入社では無いんですが、色んな所に「入社」という文字があったのでもう入社でいいのではないか、ということで入社エントリとした。
当然、詳しいことは書けないので、今日やったことをすごく簡単に書いてみる。
パソコンを与えられる。少し安っぽいマウスとともにもらった。BlueToothでは無く、無線マウスだったのが残念だった。と言っても、自分で青歯マウス持っているので、明日は持っていく。今日は持っていくのを忘れた。
環境構築をした。大体やったことは以下のとおり。
- Adobeを入れた。体験版で他のもいろいろ入れといた
一番困ったのが、Illustratorのバウンディングボックスが表示されない問題。拡大縮小出来ないじゃん！！すごく困った。再インストールを繰り返し、なんとか表示できるようになりました。ビクビクしながら使っています。
まだ公式には解決していないらしい。 - メールの設定をした。結構使うようだ。メッセンジャーとの使い分けが重要そうだ。
- 各種社内ツールを入れた。思いの外歓迎モードで良かった。結構レアな迎えられ方のようだった。まだ僕はツールのやり方を理解していない所がある。人事の人当たりに聞くことにする。
- SublimeText3入れた。必需品。UserAgentも変更
- Google日本語入力入れた。PCとの相性が悪すぎてことえりに戻したが、あいにくことえりと僕の相性が悪い。これに関してはすごくむすっとなっている。
- 使わないのにGit入れた。一応基礎的な使い方は出来ます。
- AnonymousPro入れた。やっぱりエディタのフォントはこれに限る。
- デスクトップの設定を変えた。画面は灰色単色、アイコン表示はラベル右、アイコンサイズを最小、フォントサイズ12に設定。
- 隠しファイルを表示するようにした。ルートのライブラリフォルダの中に色々用がある。
- 文字組みアキ量ファイルを入れておく。
- フォントをまだ入れていないので、多分明日以降になる。
社内見学をした。２回にわたってした。最初は某寺生まれのSさんに案内してもらい、色んな人に挨拶した。基本コミュ症なので、外面は一生懸命取り繕ってるが、内心は非常にナイーブだ。初対面の人と沢山あって、何も話せなかったかもしれないし、申し訳ないがほとんど頭に入らなかった。ただ、だいたいフロアの形や場所は覚えた。ただ、多分迷う。迷った時はTweetします。
そして、２回めは自分一人で色んなフロアを回った。そしたらデザインセンターに戻れなくなりかけた。焦った。タリーズに行ったら、先ほど案内してくださった寺生まれの人が居た。
気に入ったのは座敷になっているスペース。非常にアイディアがリラックスして考えやすい。閉所恐怖症なので狭い所は駄目だし、かと言ってオープンにすると人の目がものすごく気になる非常にめんどくさい性格をしている自分には本当にちょうどいい空間だった。いい孤独感だ。ずっとあそこで作業していたかったが、なんかあんまり勝手にすると怒られそうだし、いちいちメッセンジャーで呼ばせるのも迷惑だろうからやめた。
お昼ごはんに行った。地元の話やらなんやらの話をした。ご飯美味しかった。非常に美味しかった。ありがとうございます。こういう店は開発していかなくては。
熊本は水は非常に綺麗で、東京や、首都圏とは大きな常識のギャップがあった。僕も昨日東京に来て、すぐに水を４L買ってホテルの冷蔵庫においている。
その後はいろいろやった。言えない。ただ、非常に面白い仕事だ。僕はパスを引くのが非常に下手、というかイラストを描くのが極度に苦手だ。これはデザイナーとして非常にまずい。仕事をしながら上達できればと思う。ただ、イラストの向上はどうやればいいんだろう。
あとは仕事に対するこころ構えとかを性格を交えて書いていく。
僕は人に聞くことが非常に苦手だ。気楽に聞いて欲しいのはすごくわかるが、どうしても聞けない。きちんというと、人に聞くことが苦手というのもちょっとあるが、それよりも人の作業中に話しかけるというのがものすごく苦手だ。嫌われたくないという自己愛が激しすぎるんだろう。だから基本的に孤独が好きだ。自分一人で考えることが好きだ。どうしてかわからなくなることがあるし、聞きたい時もあるが、自分一人で考えて解決するのが好きな人間なんだと思う。ただ、仕事というものは、どうしても納期があり、相談によって自分よりレベルの高い人から知識を享受し、スピーディに解決していく必要がある。だから、これを恐れては絶対にいけない。これを解決するには、、、と考えているが、今のところは、もっとよく話して自分のことを知ってもらうことが重要であると思う。どうやら僕はポートフォリオで過大評価されているようだ。絵は人並み以下だ。手も書けないし、棒人間を描くのが精一杯だ。無機物は比較的かけるが、CADみたいに書くから遅くなるし、ディフォルメは難しい。これは僕の短所で、非常に聞きにくい部分だ。これをきちんと理解してもらう必要がある。それを明日（今日）の最重要課題とする。
というか、先輩方から盗みたい。非常に盗みたい。
決して憂鬱ではない。希望に満ち溢れている。
明日も元気に頑張ろう。
そして、デザイナーの皆さん、すみませんがほとんど顔と名前と何もかも一致していないので、明日も初対面だと思って接していただければと思います。何気なく話しているように見えると思いますが、基本的に非常にコミュ症です。基本的に会話を1対1できちんと話すことができれば覚えることが出来ると思います。それでも覚えられなかったらすいませんが、努力します。
無理やり料理で解釈するGitHub。「Web制作のためのGitHubの教科書」
今回、WishListを晒したら贈っていただきました。ありがとうございます。
Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール
- 作者: 塩谷啓,紫竹佑騎,原一成,平木聡
- 出版社/メーカー: インプレス
- 発売日: 2014/12/08
- メディア: Kindle版
- この商品を含むブログを見る
ここ最近、GitHubという名前をWebに関わる人なら、エンジニアでなくとも耳にするようになってきました。
僕も、少し興味があって、アカウントだけは持っていたのですが、いまいち使い方がわからなかったので、非常に良い物を贈っていただいたと思います。勉強するきっかけになりました。
このブログでは、簡単に内容をまとめてみたいと思います。
１．GitHubとは？
GitHub · Build software better, together.
GitHub（ギットハブ）はソフトウェア開発プロジェクトのための共有ウェブサービスであり、Gitバージョン管理システムを使用する。
（Wikipediaより）
ざっくり言うと、
コードのバージョン管理がしたい！（今まではファイル名に日付とか書いたりして手動でしていた）
→Gitというバージョン管理システム完成
→クラウドでやったほうが良い！協力できるし！
→GitHub
という感じです。多分。
出来ること：クラウド上で、バージョン管理・ソーシャルコーディング（コミュニケーション）が出来ます。
２．無理やり例えるGitHubのバージョン管理概観
無理やり料理にして、図解してみました。多分余り分かりやすくありません…。
一応これが概観です。わかりにくいでしょう？
これからjavascriptをやるつもりですので、それをGitHubで管理してみて、適宜学んだことをこちたのブログにまとめてみることとします。
ギフトで贈っていただいた方、本当に有難うございます。
実際に扱いながら、もう少し勉強してみます。
お知らせ
ウィッシュリストから頂いたプログラミング本はこのブログや、Quitaにて記事を書いていこうと思います。ドワンゴに入るまでに勉強したいので、買っていただかなくても全く構いませんので、おすすめの参考書をお教えいただければと思います。@ln_northまで…。
もちろん、運良く購入いただければ、それは社内に入るまでには必ず全て目を通して実践して吸収しますから、こんな奴になっておいて欲しいという気まぐれな方は、なんでも買って下さい。
ウィッシュリストを晒したら大量にお菓子を頂いた話とか。
今日は、夜９時ごろに父から電話があり、「飲み会に行ったので迎えに来て欲しい」とのことだったので、迎えに行ったら、「お前も一緒に居ろ」と言われて２時間近く付き合うことに（飲んでないし、食べてません。ずっと酒臭い中話を聞いてました。）
父は大学入試の試験勉強を２時間しかしてないという話でした。
相変わらず適当な人だな、と思っていて自分を思い返すと、ほとんど変わりませんでした。親子はやっぱり悔しいけど似るものですね。
非常に疲れました。
それで、今帰ってきたわけです。
で、何話すんだったっけ？
ああ、そうか。
一昨日(2/26)は私の誕生日で、また就職先を正式に発表した日でした。
株式会社ドワンゴの中の人になることになった。同時に21歳になった。 - north-memo
この記事、非常に反響がでかく、正直怖くてねれませんでした。こんなにはてブがついたのも初めてで、普段ほとんど注目されないので（気づいてないだけ？）、とっても緊張しました。ただ、祝福は十二分に伝わりました。ありがとうございます。急に4000アクセス近くになりました。Dwangoすごい。
そこで、ウィッシュリストを晒したわけですが、早速お祝いを頂きました。ありがとうございます。
ウィッシュリストを晒したら大量の「ポテトフライ」が届いた。また今日の夜ブログ書きます。 pic.twitter.com/DHOY2UWA67
— ln_north (@ln_north) 2015, 2月 28ポテトフライ存在感すごい pic.twitter.com/iLbzy2UAsu
— ln_north (@ln_north) 2015, 2月 28
本当にすごいです。今日は一日こればっかり食っていました。いよいよ太りそうです。
渡した主さんが、非常に駄菓子好きだそうで、僕も大好きなんですが、社会人だからかは分かりませんが、量が異常ｗｗｗｗ
１００袋あります。
メッセージが添えられていました。
「Welcome to Dwango!」
ありがとうございます。明日はこれ食いながらGitHubの勉強をするつもりです。
これも本を頂いたのですが、明日のブログのネタとしたいと思います。
お知らせ
ウィッシュリストから頂いたプログラミング本はこのブログや、Quitaにて記事を書いていこうと思います。ドワンゴに入るまでに勉強したいので、買っていただかなくても全く構いませんので、おすすめの参考書をお教えいただければと思います。@ln_northまで…。
もちろん、運良く購入いただければ、それは社内に入るまでには必ず全て目を通して実践して吸収しますから、こんな奴になっておいて欲しいという気まぐれな方は、なんでも買って下さい。
ニコニコ静画にコメントを流すのがぎこちなくなる理由とか。
タイトルは相変わらずいい加減です。
最近、HTML5になって、より効果的にvideo要素が使えるようになった。
最近、多くのビジュアルで注目されているサイトは、動画を使っており、動画によって、静止画では表現できない状況の把握というか、次元の高い印象を与えることが出来るようだ。
僕はこの動きに、ずっと引っかかるところがあった。
最近、それの解決の糸口が見えてきたような気がするので、書いてみることにする。
「ユーザー各々のペースに合っている」という視点で考える。*1
すごく低次元の話であるが、文章や画像はそういう視点で見ると、ユーザー各々のペースに合っているメディアと言える。
では、ムービーはどうだろうか？ムービーは、人々によって、見るペースは一律である。１秒は皆にとって同じ１秒である。（倍速再生とかは除く）
ムービーの一番他とのメディアとの違うところは、ユーザーの時間を一律にするところであると思う。どうも、自分はココに引っかかりがあったようだ。
繰り返すと、文章や画像は「時間が伴わない」メディアであるのに対して、ムービーは時間という次元が入っているのが非常に大きな違いだ。
ここで、ニコニコ動画を見てみると、この時間という次元があるためにユーザーの時間間隔を固定し、固定化することで、コメントによる「ライブ現象」を巻き起こしていると考えることも出来る。ここでのコメントは、参照性はあまり持たず、感情の共有の材料（という言い方が正しいとはわからない。数学と思えば、集団の感情という集合を考えた時の元がコメントという言い方のほうが言いやすい）となる。コメントを動画の上に流す意味があるのは、これが由来と考えても良いかも知れない。
こう考えると、ニコニコ静画はこの時間の固定化が出来ないメディアであるために、ライブ性は薄く、ライブ性が薄いということは、コメントはより個々なものになり、流すものから読むものになっていく（少なくとも完全に読むものではなくとも、個々になっていることは確かである）僕は、これによって、ニコニコ静画にコメントを流すというのはぎこちないと感じているのだろうと考えた。
ちなみに、体系的にメディアを見てみるために、次のような図表を作ってみた。
こうしてみると、音声音楽によってもライブ性を作ることが出来る。ゲーム実況や歌ってみたがニコニコ動画で流行りやすいのは、これが原因だと思われる。一方、「ライブ性」というところだけ切り取って、青に属するようなコンテンツでもライブ性をもって面白いものは、ニコニコ動画というサービスと非常に親和性が高いと考えることが出来そうだ。（いつかきちんと裏取りをしてみたいものだ。）
改めてWebでムービーを装飾効果として使うUX（どうユーザーが体感するか）について考えてみる。ムービーは、動画に比べて次元が高いので、写真より情報量を効果的に多く伝えることが出来る。ただ、ムービーにはユーザーの時間を固定する効果があるということも非常に大きな役割の一つだと思う。
これによって、何が出来るか、というと、例をあげよう。
動かないWebの文章は読み飛ばす可能性がある。どれだけ良いコピーを装飾効果をもって配置しても、読者は興味がなければ、読み飛ばすことが出来る。
一方で、ムービーは時間を固定化する、言ってしまえばインターネット特有の「自由な時間で見れる」という時間次元を止めるという、ある種の利便性を逆行させる効果がある。そこで、例えば、文章をきちんとユーザーに読ませることが出来たり、記事に目を通させることが出来る…かもしれない。（文章との融合）
僕は、ハリー・ポッターに出てきた、中の写真が動く新聞はとても魅力的なメディアであると思える。（これは今までの論旨とは関係ない、ただの好み。）インターネットの新聞の写真が動画になって、動いて、更には新聞のレイアウトとは異なる、動画に適したレイアウトにすれば、かなり記事を読ませることが出来るであろう。このへんはどうでもいいが。
ネットに新聞記事を「コピペ」しただけの媒体は、もう遅いように感じる。インターネットによってどこでもいつでも見れるようになっただけのものになりつつある。（インターネットは平凡化してきたということ。）
すごい締めが変だ。
論理性がありそうで、ミクロではある場所があるんだけど、マクロだとめちゃくちゃなので、もっとそのうちまとめたいが、すごく眠いのと酒が入ってるので、もうめちゃくちゃになってしまった。申し訳ない。いつもバラバラに考える癖が抜けないので…。
ここでもっと多次元に考えるべき箇所が沢山有るので、これからも広げていきたい。
*1:これ以外にもいろ〜んな要因を考えたんですが、論理が複雑になりすぎたので、これに限定する。
