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

らこらこブログ

唐揚げとアニメとプログラミングが大好きです

誤字・脱字と文章の信憑性

ポエム

結論からいうと、僕は誤字や脱字に無頓着な人間を信用できない。特に技術系の文章については敏感に反応する。

まず前提として、他人の書く文章や、他人の話す言葉には常に疑いを持って見聞きしている。 自分と相手では知っていること、バックグラウンド、考え方、すべてが違うので、最初から信じるのは難しい。 何度もコミュニケーションをして、「この人はこう言うだろうな」という推測ができるようになると、ある程度信頼度は上がっていく。

ここでの問題は、何を以って「この人が書いていることは正しそうだ」と判断するかということだ。 また前提の話になるが、他人の技術的な文章を読むときの状況は2パターンしかなくて、「自分のほうが知らない」か、「自分のほうが知っている」だ。 後者の場合には、その文章が正しいかどうかは中身を流し読めばだいたいわかるだろう。 問題は前者だ。自分は教わる立場であり、書かれている話が正しいかどうかというのはとても重要になる。 理由は言うまでもなく、その情報の正誤を判断できないからだ。知らないことを学んでいるんだから当然である。

じゃあどうやって「この文章で述べていることは正しそうだ」を判断するか、つまり信憑性を量るかという話になって、 そこで主題の「誤字・脱字」に戻ってくる。

単純な話、誤字・脱字がある文章とない文章、どちらを信用するかと聞かれたらまず後者になる。 きちんと他人に見せるように文章を書いていれば最低限一度は推敲をするはずで、 誤字・脱字が目立つということはまともに推敲をせず、書きなぐって即投稿していると判断する。

「文章が多少荒れていても内容には関係ない」という主張の人もいるだろうが、相手にするつもりはない。 なぜならここで話しているのは「自分のほうが知らない」状況であって、 確かに理解している人にとっては有益な情報なのかもしれないが、知らないものを教わろうとしている人間にはそれは判断できないのだ。

言い換えれば、これは「文章の第一印象」の話だ。その文章をある程度信用して、しっかり読もうという第一歩を躊躇させるのが誤字・脱字である。 「ちゃんと書く」という基本が出来ていない文章を「ちゃんと読む」気にはなれない。

誤字・脱字だけでなく、正式名称を正しく表記できているというのも大きな評価基準になる。 例えば「JAVA」や「Github」、「Javascript」などが文章中に出てくると、その文章への信頼が急降下する。 たかが大文字小文字の違い、内容には影響はないように見えるかもしれないが、さっきも言ったようにこれは印象の問題である。 その筆者の、文章への誠実さを推し量る上で、正式名称を使っているかどうかはとても重要だ。

文章の話ばかりだったが、これはプレゼンテーションでも同じことが言える。 プレゼンテーションにおける誤字・脱字はもちろんスライドの中の文章もあるが、言い間違いも重要な判断材料になる。 固有名詞や、特に難しくない英単語・漢字を言い間違っていると、「この人の話は大丈夫なんだろうか」という疑念が湧く。 一度疑念が湧くとその後の話は話半分に聞くしかなく、結局その話から得られる収穫は少なくなる。

他人に文章を読んでもらう、話を聞いてもらう上で、いちばん重要なのは自分の話を信用してもらうことだ。 相手が自分を信用しやすくなるように歩み寄るには、「正しく書く」ということが最も簡単で、最も重要な手段である。

[追記] s/嘘半分/話半分/

Design-JP 第1回 勉強会に行ってきたメモ

先日、 "Design-JP"という名前のデザイン勉強会に参加してきた。

design-jp.connpass.com

その名のとおりデザイナーやデザイン寄りのエンジニア向けの勉強会で、 専らGoogle App EngineやらAngularやらやってる人間からすると未知の領域だった。 今の仕事でデザインやプロトタイピングをやることはまず無いので、 "知識"を得るというよりは、"異文化交流"しようと思って、新しい考え方を求めて参加した。

以下はイベント中のメモや参考リンクの備忘録である。 発表中に"これは秘密で"と言われた部分はもちろん書いていない。


プロトタイピングツールの使い所の話

  • プロトタイピングツール
    • Prott
      • 聞いたことはあった
    • Adobe XD
      • 聞いたこともなかった
    • その他もいろいろ
  • 結論
    • 適切なタイミングで適切なツールを使うべし
    • 適切なタイミング
      • デザインが決まった後でアニメーション試すためにあとから突っ込むみたいなのは成功しない
    • 適切なツール
      • プロトタイピングにかかわる人間に合わせる
      • クライアントと共同作業があるならそれに合わせる
      • ひとつのツールにこだわって効率を落とさない
        • パーツ作りをXDでやって、Prottで組み合わせてプロトタイプを作る合わせ技
        • 若い人ほどひとつのツールを使いこなして完結させようとしがち

プロトタイピングによる効率化

  • なぜ多彩なデザインツールが出てきているのか

www.yasuhisa.com

  • ありがちなプロトタイプ失敗パターン

www.yasuhisa.com

  • プロトタイピングによくある失敗

    • プロトタイプを成果物と思ってしまう
      • 学びを得るためのツールだと思っていない
    • プロトタイプを共有する相手を見ていない
      • 自己満足な作りこみ
    • ひとつのツールに固執する
  • プロトタイプの目的

    • イデアやデザインを忠実に伝えるために本物に限りなく近いものを作ること ではない
    • 時間をかけずに目的に合わせて内容を可視化すること
  • ツールの充実
    • 動くもの(それは本当にプロトタイプなのか?)を作ることが前提っぽい風潮
    • 無駄なことをやってしまう
  • 本末転倒なプロトタイプ
    • 相手に伝わらない
    • 画面数が多くて修正に時間がかかる
    • 見せたかった部分じゃないところにツッコミ
    • 実装が無理だった
  • 本来の目的を思い出す
    • 内容の確認
      • 何を?誰と?
    • 共有
      • 誰と?
    • 実装機能の検証
      • 何を?どのレベルで?
    • フィードバックの収集
      • 誰から?何を?
    • 実際の環境に向けての最終調整
      • どんな環境?
  • Keynoteは最強のプロトタイピングツール
    • 静止画で画面のストーリーを作る
    • 実装がないので修正も早いしわかりやすい
    • お客さんが理解できるツールのほうがいい場合も多い
      • クライアントの担当者の、さらに上からOKを貰えるプロトタイプが必要

プロトタイピングのコツ

  • 忠実度を考える(作り込み過ぎない)
    • 誰に見せるか、適材適所と作業時間でどれを作るかを考える
    • 自分だけ(素早さ) < チーム(話し合い・共有) < テスト用(見た目・印象) < クライアント(見た目・完成度)
  • ツールの使い分け
    • 目的別のツール選定表 Prototyping Tools | Cooper
    • どこでも素早く仕事したいならネイティブアプリのツール
    • Keynote最強 誰もが持っている・使える・編集できる
  • 早く作り過ぎない/打ち合わせの場で作る
    • ちょっと早く出すくらいがちょうどいい
  • みんなではじめるデザイン批評
    • プロトタイプを批評してもらう、批評するタイミングが重要
    • イデアを自分の言葉で説明できるくらいに固まってから批評をもらう
  • A shorthand for designing UI flows
    • デザイン抜きで、各画面で見えているものとできることだけを書き出してつなげておくと、デザインするときに頭が整理されている
  • アニメーションは作ってしまうのもひとつの手
    • アニメーションはカーブを使って表現する
      • 直線?指数関数的?
      • とりあえずエンジニアに頼んで作ってもらうが、そのコードは 捨てる前提 で書いてもらう
  • ダミーではなくちゃんと本物の画像や文言を使うことで、コンテンツの意味を考えて幅や文字の大きさなどデザインを評価できる
  • (iOSとかAndroidとかそれぞれのプラットフォームの標準パーツを組み合わせて作ったものが、基本的にいいものになる
    • 独自のパーツはよっぽど斬新なアイデアのときだけ
  • プロトタイプのときはまずひとりで使えるもの、ソーシャルはその後
    • はじめて使う時だけの画面は忘れがち
    • インストール/登録→初回→友達がだれもいない状態のデザインが重要
  • 狩野モデル
    • 作りこんでも当たり前だと思われる部分、作りこんだら魅力になる部分
    • "当たり前品質要素"をまず大事にする

以上、ざっくりメモ。噛みくだいていけばプログラミングにも応用できる話がいくつもあったように思う。 話の内容こそ実感のないものだったが、特に難しい用語があるわけではないのでイベントは十分楽しめてよかった。 次回もぜひ参加したい。

GitHubでしりとりを始めました

プログラミング

何を言っているかわからないと思いますが、僕も自分が何を始めたのかいまいちわかりません。

github.com

Pull Requestでしりとりを繋いでいくだけのリポジトリを作りました。次に挙げるような意図があります。

  • GitHubOSSへのコントリビューションに不慣れな人に、遊び感覚でプルリクエストの練習をしてほしい
  • GitHubの緑を絶やしたくない人のための遊び場に。
  • 僕がいろんなプルリクエストを処理してみたい

初日からたくさんのプルリクエストやイシューをもらって、「しりとり」から「ニジェール」まで進みました。地道に続けていきましょう。


技術的な話として、せっかくGitHubを使うので、ユニットテストとCIによるしりとりの整合性チェックを自動で行おうとしています。 現在実装済みのテストは以下のものです

  • すでに使われている単語のチェック
  • 末尾の文字が「ン」か「ん」でないことのチェック
  • 発音した時に最後が「ン」にならないことのチェック

3つ目の発音のチェックは kuromoji.js を使った形態素解析によるものです。このチェックによって、「習慣」のような単語を弾くことができます。

次の段階としてしりとりがしりとりになっているか、すなわち「前の単語の最終音と次の単語の開始音が一致するか」のチェックを行おうと思っていますが、長音や促音など考慮する点がいろいろあるので慎重に実装していきたいと思ってます。 一番つらそうなのは表記ゆれ、「ユーザ」と「ユーザー」をどう処理するかという問題です。おいおい考えます。

将来的にはテストが通ってCIグリーンなPRは自動でmergeされるような仕組みができればいいなと思ってますがまだまだ先になりそうです。

Angular 2へのコントリビュート支援をしていきます

Angular OSS

らこです。今回は所信表明という感じで。

僕はここしばらくAngular 2にコントリビュートをしていて、今まで出したプルリクエストは10数件ですが、だいたい受理されています。 なんとなくコツも掴んできたし、Angular TeamとのGitHub上でのやりとりも慣れてきました。 Angular 2はまだまだ開発途上なので修正する余地はたくさんありますし、特にドキュメンテーションの整備など人の手が必要な部分はコントリビューションを大募集しています。

そこで、日本からのAngularコミュニティからのコントリビューションをもっと増やすための取り組みを行おうと思います。 うまくいくかどうかはわかりませんが、Angularをもっとよくしたいと思っている日本人の助けになればうれしいです。

日本語でIssueを書けるようにする

コントリビューションの基本はIssueです。バグ報告や質問、機能の要望や提案など、まずはIssueでの議論から始まります。 ですが公式のリポジトリはすべて英語ですし、いきなりAngular Teamの目に留まるところに書き込むのは抵抗がある方もいるかもしれません。

そこで、私がコントリビューション用にフォークしているAngular 2のリポジトリのIssueを、日本語でIssueを書ける場として開放します。

github.com

これはwatildeさんがnpmのCLIリポジトリで始めた取り組みで、とてもいいなと思っていたので真似させてもらいました。

github.com

まだ始めたばかりでドキュメンテーションはできていないですが、いつでも気軽に書き込んでください。

コントリビューションガイドの作成

Angular 2にコントリビューションする、具体的にはパッチを作ってプルリクエストを送り、受理されてmergeされるまでの手順、フローを解説したドキュメントを作成しようと思います。

まだ取り掛かっていないのですが、6月中には出せれば良いなと思います。


僕はAngular TeamでもGooglerでもないですが、いちコントリビューターとして、Angularをよりよくするための活動をしていくつもりです。 質問や意見、なんでも https://github.com/laco0416/angular/issues に書き込んでください。

みなさんからのコントリビューションをお待ちしています!

JSer.info 5周年記念イベントに行ってきた

プログラミング

JSer.info 5周年記念イベントに行ってきました。

jser.info

会場のサイボウズさん、広いし綺麗だし面白い。

f:id:laco0416:20160116145709j:plain

f:id:laco0416:20160116145655j:plain

イベントの内容はazuさんが↑の記事でまとめてくれているので割愛、印象に残ったことだけ書く。

JSer.infoの仕組み

azuさんがJSer.infoがどう運用されているのかの話は感心しっぱなしだった。 つい最近ng2-infoというブログを立ち上げた身としてはフル手動なのが恥ずかしくなる。 まあ個人の片手間ブログをどこまで自動化コストかけるかというところで、JSer.infoは毎週更新という決まりがあるので時間を短縮することのメリットがでかいのだと思う。観測対象も多いし。 参考にはなるけど自分にはオーバースペックな運用だなと思った。

「仕様を理解していないコードは書けない」

mizchiさんの「React on 現場」で出てきた。 既存のレガシーなコードをリファクタしたいというときに、その仕様を理解せずに動きだけ真似ようとするのは無理だという話。 先にアプリケーション単位、画面単位、機能単位での仕様を把握したうえでやらないといかんなぁというのは今の仕事でもちょうど少し悩んでいたところだったので、 共感しつつ、乗り越えなきゃいかんなと勇気をもらった。

スティングフレームワーク「ava」の話

t_wadaさんのLTで出てきた新しいテスティングフレームワーク

github.com

アサーションにpower-assertが組み込まれていて、しかもbabelも入っているのでES6でテスト書くならすごくいいと思う。 TypeScriptから吐き出したES6でもテストできるのか後日試す。 気になったポイントはmochaのdescribeitのようなグローバル変数を使わないというところ。 実はAngular2がjasmineを組み込んでいるせいでグローバルの型定義が汚染されているため、mochaのテストを書けない問題があるのだけど、 それを解決してくれるのではという期待が持てる。ダメかもしれんが。

この他にもたくさん気になる話があった。雑談の中ではFalcorやGraphQLなどのオーケストレーション的なものをどう見るかだったり、 オフレコの話だったり、面白かった。

またJSer.infoのイベントがあったら是非参加しようと思う。