c5n's i18n

Webサービスの多言語化について書きたいとは思っています。

「プロを目指す人のためのRuby入門」から学ぶ「分かりやすい入門書」

@JunichiItoさんの「プロを目指す人のためのRuby入門」をとりあえず1周読みました。 まだ全部写経できた訳でも理解できた訳でもないですが、ひとまず読み終わりましたということで、考えたことを一度まとめてみようと思います。

Ruby初心者」にオススメ!

先にオススメしておきます。この本は僕のような他の言語で開発の経験があったり、すでにある程度Rubyプログラミングを進めていたりする人には強くオススメです!

言語に依らない基本的なプログラムの書き方(forやif、変数など)は理解していることを前提に、「Rubyらしさ」が重点的に書かれているため、新しい言語としてRubyを学ぶ時に知りたいことがとてもよく分かる内容になっています。

その辺りはまさに @JunichiItoさんがブログに書いている通りでした。

blog.jnito.com

というところで、Rubyの学習にとても良い本であるということは上の記事や他の方のブログなどに書かれている通りですので、この記事では詳しく書きません。代わりにこの記事では、どうやったらこんな分かりやすい内容の入門書が書けるのかという点に着目して考えてみたいと思います。

この記事の対象読者

先述した通り、この記事では「ここがよかった!」などの読む側の視点ではなく、「こう書くと分かりやすい!」という書く側としての視点から本書の良いところを探してみたいと思います。

現在僕はDjangoを利用したWebアプリケーション入門研修のテキストを作成しています。しかし自分の書いた内容がどうしても「分かりやすい」とは思えず悩んでいたところ、ちょうど本書が発売され、なぜこの本が「分かりやすい」のかを考えてみることが自分のテキスト作りにもプラスになるのではないかと感じました。

この記事は僕のような初心者に対して「分かりやすい」文章を書きたいと思っている方に役に立つような記事になれば良いと思います。

なお、この記事に書かれていることは引用部分を除いて全て僕の推測ですので、@JunichiItoさんや編集者さんの意図したことだとは限らないことにご了承ください。

50点の内容を100%理解できる本

まず、この本の一番の特徴は50点の内容を100%理解できるように書かれた本であるということだと思います。

多くの技術的な入門書やWebの記事は、なるべく誤解を与えないためか「100点の内容を書く」ことに注力する傾向があります。APIドキュメントのようにメソッドとその説明を列挙したり、文法を余すところなく説明したり、という具合です。

そのような内容はリファレンスとして有用ですし、それをきちんと理解できれば実際の開発で役に立つことは間違いありません。しかし「入門書」となると話は別です。

その分野の初心者としては、隅々まで説明されても実際の開発現場ではその中のどこが特に重要になるのかが判別できません。その結果、100点の内容のうち10%しか理解できない結果になってしまいます。

一方で、要点を絞り、主観を交えて大事な部分を強調することによって厳選された50点の内容を100%理解できれば、結果として5倍の内容を身につけられるというのが本書を読んで考えたことでした。

ここからは、厳選した50点の内容を100%理解できる文章にするための本書の具体的な工夫について考えてみたいと思います。

「分かりづらい」書き方

「分かりやすい」書き方を考える前に、ここでは先に「分かりづらい」書き方について考えてみようと思います。あらかじめ書いておくと、本書はここで説明する「分かりづらい」書き方を避ける工夫がいろいろと凝らされています。

今までの経験上、僕が本を読んでいて「分かりづらい」と感じてしまう瞬間は以下の通りです。

  • 何が便利でどう使われるのかが説明されないまま淡々と話が進む
  • 新しい話題が突然出てくる
  • 自分の前提知識や目的に沿っていない

それぞれについて、詳しく考えてみたいと思います。

何が便利でどう使われるのかが説明されないまま淡々と話が進む

たとえ素晴らしい技術や仕組みだったとしても、その素晴らしさが伝わらなければ読んでも頭に残りません。自分がそれを使う具体的なイメージがないままだと、その内容をとりあえず「暗記」しなければならない気になってしまい、結果的に「分かりづらい」説明になってしまいます。

新しい話題が突然出てくる

ひとつの技術について説明していると、周辺知識として別の技術の説明が必要になることがあります。そんなとき、「100点の説明」をしようとするとどうしてもその周辺知識の説明が長くなってしまい、読んでいて「あれ、今なんでこの技術を勉強してるんだっけ?」という気分になってしまい、結果としてその内容が頭に残らなくなってしまいます。

自分の前提知識や目的に沿っていない

基本的に入門書を読むときは、「これができるようになりたい」という目的や「今はここまで理解している」という前提知識があります。

そんな中、自分の目的に沿っていない内容にページを割かれたり、すでに知っている内容を改めて説明されてしまう(もしくはまだ知らない内容を既に知っている前提で説明が進んでしまう)と、「この本は自分に合っていないのではないか?読み進めても意味がないのではないか?」と考え始めてしまい、とりあえずページを進めることが目的になってしまいます。

 

以上、「分かりづらい」文章の特徴をざっと挙げてみました。

ここから考えてみると、自分にとって程よく新しい内容が書かれていて、さらに読み終わった後に自分がそれを活用できている姿が想像できると「分かりやすい」と感じられるのではないかと思います。逆にその状態から外れてしまうと、だんだんと集中力がなくなって「分かりづらい」と感じるようになるのではないでしょうか。

「プロを目指す人のためのRuby入門」はそれをどう解決しているか?

では、このような問題を本書はどのように解決しているのかについて考えてみます。

念のためもう一度書きますが、ここで書く内容はあくまで僕の推測や感想であり、@JunichiItoさんが意図した工夫だとは限りませんので、ご了承ください。

「何が便利でどう使われるのかが分からない」問題

これは「第3章 テストを自動化する」や「第6章 正規表現を理解する」が良い例だと思います。

本書では、その技術を「使わなかった場合」について説明した上で、「使った場合」に同じ要件をどれだけ楽に解決できるか、という順序で説明しています。

これについては@JunichiItoさんご本人も以下のようにツイートしています。

また、本書は各章の構成が「例題の要件定義」→「基礎的な説明」→「例題」→「さらに発展的な説明」となっており、中でも「基礎的な説明」は例題を解決するためいの必要最低限な内容に絞られているため、そのどれもが例題として挙げた要件を解決するために実際に使えるものであることを意識しながら読むことができます。

また、細かく文章を見てみると、「実際に使うことはありませんが知識として」とか、「Rubyの開発では~がよく使われます」などのように、どの程度の温度感で説明を読めばよいのかが分かる前置きがされていて、メリハリをつけて読めるよう工夫されています。

「新しい話題が突然出てくる」問題

先述の通り、本書は「例題の要件定義」→「基礎的な説明」→「例題」→「さらに発展的な説明」という構成になっています。

そして、個別のAPI仕様などの細かな要素は例題の要件を実現するために必要なものだけに厳選されていて、それ以外の周辺知識についてはWeb上の記事や公式ドキュメントへのリンクを示すのみにしてバッサリと切り捨てる、という工夫がされています。

これによって、書く側としても今書くべき内容が何かを迷う必要なく、また読む方としても話題があちこち逸れる感覚がなく読み進められるようになっています。

書籍によってはバッサリ切ることも詳しく説明することもないままに「とりあえずこれはおまじないとして、~のようなものだと思っていてください」のような曖昧で混乱を招くだけの説明をされることもあることを考えると、この進め方はとても読者に親切だと感じました。

このあたりの既存の記事へのリンクの活用方法は、普段QiitaやブログなどWebで記事を書き慣れている@JunichiItoさんならではの感覚だなー、と思います。

「自分の前提知識や目的に沿っていない」問題

前提知識や目的は、読者一人ひとりによってさまざまですので、この問題を100%解決するのは難しいように思います。しかしだからと言って内容を網羅的にしてしまって「読者一人ひとりが自分に合った読み方をしてくれればよい」というアプローチは、この問題をさらに深刻にする結果にしかなりません。

本書はまえがきを以下のような質問から始めることによって、この問題を解決しようとしています。

Q1.すでにほかのプログラミング言語で3年以上の開発経験がある。もしくは「プログラミング歴=Ruby歴」で、 Rubyを始めてから半年以上経っている。 (Yes/No)

Q2.Rubyを学習する動機はRailsアプリケーションの開発に役立てるためだ。 (Yes/No)

Q3.すでに仕事でRubyを使っている。もしくはこれからRubyを使った仕事に就こうとしている。 (Yes/No)

 

みなさんはいくつYesになりましたか?  3つともYesになった方は、本書がみなさんのニーズを満たしている可能性が高いです! 反対に、3つともNoだった方は残念ながら本書がお役に立つ部分は少ないかもしれません。Yesが1つ、または2つだった方は、もしかするとみなさんのニーズにマッチする部分があるかもしれないので、もう少しじっくり本書の内容を吟味してください。

これからRubyを勉強しようという人の中で、これが3つともYesになる人の割合はそれほど高くないのではないかと思います。このような質問によって「読者を減らす」ことで、読者の前提知識や目的をある程度そろえることができるのです。

あとは、その絞られた読者に対してのみマッチする内容や文章を書くことによって、より多くの読者にとって前提知識や目的に沿った説明ができる、という訳です。

また、少し小道に逸れた説明に入る際は必ず「ちょっと難しい内容で混乱するかもしれませんが」のような注釈がついて、ここから説明する内容が前提知識や目的に沿っていない可能性があることを教えてくれるのも、本書の親切なところです。

「ターゲットを絞る」というのはマーケティングの基本だと言われたりもしますが、いわゆる入門本でここまで具体的に、バッサリと読者を選ぶ本というのも珍しいのではないかと思います。(たぶん「初級者でも中級者でも楽しめます!」と書いておいた方が売り上げが良いとかそんな事情があるんじゃないかと邪推しています)

しかし、そうすることによって読者にとってピッタリの内容を狙って書くことができるというのは、読者目線に立った工夫なのではないかと思います。

まとめ

以上、「プロを目指す人のためのRuby入門」から学ぶ「分かりやすい入門書」の書き方の考察でした。

テキスト作成であれ、Qiitaへ投稿する記事であれ、ある内容を誰かに説明する機会は少なからずあると思います。そんなとき、本書でされている(と思う)工夫を活用してみることで、もう一歩「分かりやすい」説明ができるようになるのではないかと思います。

少し話題は逸れますが、この本を読んでいてもうひとつ、@JunichiItoさんはとてもよく勉強されている方なんだなー、とも感じました。

このテキストは写経しやすいような閉じない紙質であったり、議論が発生することを前提にした主観的な説明であったり、すべての説明に付属されているサンプルソースであったりと、「読んでわかった気になって終わり」ではなく実際に仕事で使えるようになるための道案内がとても親切にされています。

これはきっと、実際に@JunichiItoさん自身がRubyRailsを1から勉強して仕事で使う中で、実践で使えるようになるために必要な道筋をその身をもって体感したした結果なのではないかと思います。

「本書の刊行に寄せて」に書かれているまつもとゆきひろさんの

「ああ、人の気持ちがわかるとはこういうことなんだなあ」と何度も感じました

という表現は、本書の読者と同じように@JunichiItoさんもRubyを勉強してきた経験が、本書に強く反映されているということなのかな、と勝手に解釈しています。


長くなってしまいましたが、このような良書を先行販売で読めてよかったです!

まだ仕事でRubyを使うのは少し先になりそうですが、それ時が来るまでに本書をもう一度写経し直し、それをベースにAPIリファレンス等を読み、実際にプログラムを書きながらRubyの腕を磨いておこうと思います。

ノンエンジニアのためのプログラミング入門 第1回:Hello World!

こんにちは。フリーランスでWebシステムの開発や新人研修などをしている @chooyan です。

先日、coconalaというサービスで「文系の方向け!プログラミングのプの字を教えます」というサービスを出品してみました。

このサービスは プログラミングのプの字も知らずにエンジニアになった @chooyan がチャット形式でプログラミングの基礎を教えます!というものなのですが、同じ内容を読み物として体験できる版として、この「ノンエンジニアのためのプログラミング入門」シリーズを書き初めてみました。

プログラミングなんてしたことないけどちょっとやってみたい、あわよくば仕事にしたい、という思っている方は是非読んでみていただければと思います。

想定している読者

このシリーズは、プログラミングは初めてだけれどもここで得た知識を仕事でなんらかの形で活かしたい、という方を想定して書いています。

そのため、他の入門サイト等では説明を曖昧にしたり割愛しているような、少し難しめな内容も必要に応じて突っ込んで説明している部分があります。

最初は理解が止まってしまう部分もあるかもしれませんが、実際に仕事で使う場合(自分で開発する場合だけでなく、エンジニアと技術的な話をする場合など)には必要な知識ですので、少しの頑張りとご協力をいただければと思います。

プログラミングを始めてみよう

さて、記念すべき第1回は、「プログラミングとは何か」ということを少し考えつつ、自分で書いたプログラムを動かしてみるところまでをやってみます。

プログラムとは

プログラミングとは、プログラムを書いて動かすことです。 では、プログラムとは何でしょうか。

と自分で書いておいてなんですが、「プログラムとは何か」と言われてもちょっと質問が漠然としすぎていてうまく説明できません。

そこで、ここではエンジニアの思考回路を理解するための説明として、「インプット」と「アウトプット」という言葉の説明から始めてみたいと思います。少し遠回りになりますが、理解を深めるために少しおつきあいください。

一般的な「インプット」と「アウトプット」

「インプット」と「アウトプット」という言葉自体はプログラミングでなくてもビジネスではよく使われる言葉なのではないかと思います。

例えば仕事におけるスキルアップの会話では、「本を読む、ネットで調べる、講座を受けるなどの『インプット』だけでなく、人に話す、ブログに書く、資料にまとめる、などの『アウトプット』が大事だよね」といった話が出たりしますが、この場合の「インプット」と「アウトプット」とイメージは一緒です。

つまり、インプットは受動的に「受け取るもの」で、アウトプットは能動的に「生み出すもの」と言えるかと思います。

コンピューターの世界の「インプット」と「アウトプット」

では、コンピュータの世界でのインプットとアウトプットにはどのようなものがあるでしょうか。

たとえばインプットには、キーボードやマウスによる操作、温度センサーや照度センサ―などのセンサーから受け取るデータなど、様々なものがあります。一方でアウトプットは画面への表示やスピーカーからの音声、プリンタから印刷された紙などがあります。

我々ユーザーの操作によって発生する情報(キーが押された、画面が触られた、など)や、別の機械を通して受けとった情報がインプットで、その結果コンピューターによって作られたもの、表示されたもの、発生したものがアウトプット、というイメージです。

プログラムとは

さて、ここで「プログラムとは」に戻ります。

先ほどのインプットとアウトプットの話を踏まえると、「プログラム」とは「インプットを基に、ユーザーが必要としている情報を適切にアウトプットするための処理」であり、「プログラミング」とは、そのような処理を書くこと、と説明できるのではないかと思います。

「キーボードの"Aち"というキーがタイプされた」というインプットを検知して「PCの画面上に"a"、もしくは『あ』(もしくは『ち』)という文字を表示する」というアウトプットをしているのもプログラムですし、もう少し身近なところだと、スマートフォンの地図アプリで「住所を入力して検索ボタンを押した」というインプットに対して「その住所の地図が表示される」というのもそのように書かれたプログラムが中で動いているからです。

そしてこの記事を読んでいるみなさんは、そのようなプログラムを今まさに書こうとしている、ということになります。

始めてのプログラミング

さて、プログラムが何かについて考えてみたところで、カンタンなプログラムを書いてみましょう。

その「カンタンなプログラム」とは、「画面に"Hello World!"と表示する」というものです。

「"Hello World"ってなんだよ!」って思われた方、その通りです。僕もなんで"Hello World"なのかはよく分かりません。が、そういうものなのでそうなのです。

どの国でも、どのレベルのエンジニアでも新しい技術を学び始めるとき最初にやるのは"Hello World"です。ググってみると分かりますが、「PythonHello Worldしてみる」みたいなタイトルのブログ記事は無数にあります。英語圏であれば "Hello World in Python" とかでしょうか。それくらい、「"Hello World"と表示する」プログラムは定番中の定番なのです。

というワケで、この記事でもその定番に倣います。

なお、このシリーズではプログラミング言語としてPythonを使います。

理由は「始めてでも書きやすいから」に尽きるのですが、あまりPython特有の話は出さないようにしますので、他の言語の勉強を検討中の方でも読んで時間の無駄にはならないかと思います。ひとまずこの記事ではPythonを使うということをご了承いただければと思います。

Hello Worldのイメージ

まずは今から作ろうとしているプログラムの実行イメージです。

いきなりスマートフォンのアプリ上に"Hello World!"と表示したりするのはちょっと難しいので、まずはコマンドプロンプト上に"Hello World!"を表示してみるところから始めます。

まずは下の図1を見てください。

f:id:chooyan_eng:20171004084541p:plain
図1:コマンドプロンプトHello Worldが表示される

この黒い画面がコマンドプロンプトです。Windowsには必ず入っています。

このコマンドプロンプトを開き、python helloworld.py とタイプしてEnterキーを押すと、次の行に"Hello World!"が表示される、これが今回のゴールです。

なお、この記事では基本的にWindowsを前提に書いていますが、基本的にはMacでも同様です。「コマンドプロンプト」ではなく「ターミナル」を、「エクスプローラー」ではなく「Finder」を使って読み替えてみてください。

それではやってみましょう。

プログラミングを始めるその前に

さっそくプログラムを書いて実行、といきたいところなのですが、新しくプログラミングを始める場合、多くの場合は「環境構築」が必要です。つまり、Pythonプログラムを動かすためのプログラムが必要になります。

ちょっとなにを言っているのか良くわからないと思われたかもしれませんが、とりあえず「最初にPythonをインストールしなければならない」ということだけ把握していただければ良いかと思います。詳しくは別の回で説明する予定です。

まず、Pythonがインストールされていない状態であることを確認しましょう。*1

コマンドプロンプトを開きます。 "Win"キーと"r"キーを同時押し > "cmd" と入力 > Enterキーをタイプ これで開くはずです。Macの場合は"Command"キーとスペースキーを同時押し > 「ターミナル」と入力 > Enterキーを入力 でターミナルが開きます。

f:id:chooyan_eng:20171004084726p:plain
図2:コマンドプロンプトを開く

コマンドプロンプトが開けたら、python --version と打ち込んでEnterキーをタイプします。

f:id:chooyan_eng:20171004082606p:plain
図3:Pythonがインストールされていないことを確認

'python' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

と表示されたかと思います。確かPythonはまだインストールされていませんので、このエラーは想定通りです。

逆に、エラーにならずに

Python 3.6.2

と表示された場合は、すでにお使いのパソコンにPythonがインストールされていることを表します。おそらくMacの方はこちらになるのではないかと思います。(MacLinuxではPythonはプリインストールされているためです)

f:id:chooyan_eng:20171004082722p:plain
図4:すでにPythonがインストールされている場合はバージョンが表示される

もしインストール済みだけれども表示されたPythonのバージョン(3.6.2の部分)が3.6.2より低い、という場合は、このあと説明するインストール手順と同じ手順でバージョンをアップデートしてみてください。*2

では、エラーになることが確認できたところでインストールを始めてみましょう。

Python のインストール

Pythonの公式サイトを開きます。

Welcome to Python.org

ここが、Pythonというプログラミング言語の公式サイトです。ここから、Pythonの文法やアップデート情報などの資料へのアクセスやダウンロードができるようになっています。

ここからダウンロードページを開きます。ページ上部のメニューバーの"Downloads"をクリックしてください。

ダウンロードページを開くと "Download Python 3.6.2" というボタンがあると思いますので、クリックしてください。python-3.6.2.exe というファイルのダウンロードが開始されますので、ダウンロードが完了したらこのファイルを開きます。

表示される案内に従ってインストールを進めます。

f:id:chooyan_eng:20171004083613p:plain
図5:"Install Now"をクリック

f:id:chooyan_eng:20171004083636p:plain
図6:Pythonのインストール中

インストールが完了したら、ダイアログを閉じてインストール完了です。

f:id:chooyan_eng:20171004083728p:plain
図6:Pythonのインストールが完了

インストールの確認

では、インストールが無事完了していることを確かめるために、再度コマンドプロンプトを開き直します。

※ 先ほど使ったコマンドプロンプトのウィンドウはまだインストールが反映されていないため、閉じてしまってください。

新しく開いたコマンドプロンプトで、先ほどと同じようにpython --versionと打ち込んで、Enterキーをタイプします。

f:id:chooyan_eng:20171004083806p:plain
図7:再度コマンドを打ち込んでPythonがインストールされていることを確認

今度はエラーではなく、Python 3.6.2が表示されました。Pythonが正常にインストールされていて、バージョンは"3.6.2"であることが確認できましたね。これでPythonのインストールは無事完了です。

いざ、プログラミング

これでようやくプログラムを書く環境が整いました。

それでは、先ほどの "Hello World!" のプログラムを書いてみましょう。

まず、「メモ帳」を開きます。

実際の開発現場ではここでメモ帳ではなくもっと高機能でオシャレなテキストエディタを開くのですが、そのエディタ自体の使い方を知る必要があるなど余計な手間が増えてしまうため、ここではなんの機能もないシンプルな「メモ帳」を使います。

メモ帳が開けたら、以下の一文をタイプします。コピペはダメです。勉強のためにも一文字ずつ書き取りましょう。エンジニアの世界ではこの作業を「写経」と呼んでいます。

print('Hello World!')

さあ、これだけです。

これだけ書けたらファイルを保存します。名前はわかりやすいよう、helloworold.py としておきます。ファイルの末尾についている ".py" が、Pythonプログラムが書かれたファイルであることを示す拡張子になります。*3

保存場所はどこでも良いのですが、あとで整理しやすいよう、Cドライブの下(C直下と言ったりします)に programming というフォルダを作り、その中に保存すると良いでしょう。

f:id:chooyan_eng:20171004083400p:plain
図8:helloworld.pyをprogrammingフォルダに保存

保存できましたでしょうか?

それではこのプログラムを実行します。

実行するのですが、ファイルをダブルクリックするわけではありません。プログラムの実行は、先ほど少しお見せしたようにコマンドプロンプトからするのが基本です。以下の手順でコマンドプロンプトを開きましょう。

まず、保存したフォルダをエクスプローラーで表示します。表示したら、エクスプローラー上部にあるアドレスバーに、"cmd" とだけ打ち込んでEnterを押してください。これでコマンドプロンプトが表示されるはずです。*4

f:id:chooyan_eng:20171004083129p:plain
図8:programmingフォルダからコマンドプロンプトを開く

最後に、表示されたコマンドプロンプトpython helloworld.pyとタイプし、Enterキーを押してみてください。

先ほど示した実行イメージの通り、次の行に"Hello World!"が表示されたのではないでしょうか。

f:id:chooyan_eng:20171004084541p:plain
図9:Hello World!

まとめ

お疲れ様です!

初めてのプログラミングはいかがだったでしょうか?

もしかしたら「Hello Worldなんてできて何になるんだ」と思われたかもしれません。確かにこれだけではまだ何ができたわけでもありません。しかし、「プログラムを書く環境ができた」ことは、実はとても大きな一歩です。次回からは、一度動いたこのプログラムに処理をどんどん追加する形でプログラミングを学んでいきます。*5

この記事を読みながら"Hello World"をする中で、様々な疑問やうまくいかなかった点が出てきたかもしれません。その場合はどんどん調べたり、コメント欄へコメントしていただければと思います。プログラミングを学ぶ上で一番大事なのは疑問や不明点はどんどん自分で調べて試して体験してみることです。この記事に書いてあることが全てではありませんので、ぜひ色々なサイトや書籍をみてみてください。

次回は「第2回:引数を使ってインプットしてみる」です。

それでは、楽しいプログラミングライフを!

*1:この「作業前の(エラーになる)状態を確認しておく」というのはとても重要です。作業後にBeforeとAfterを比較することで、自分の成果を明確にすることができます。

*2:特に、Pythonはバージョン2.x.xと3.x.xでは入門の説明から変えなければならないほど違ったりするため、ここでPython "2.x.x"と表示された方は必ずアップデートしてください

*3:「拡張子って何?」という方はググってみてください。簡単にいうと、ファイルの種類をWindowsに教えてあげるためにファイル名の末尾につける文字のことです。

*4:ここでコマンドプロンプトを開く手順を先ほどと変えているのには理由があります。詳しくは別途説明しますが、コマンドプロンプトは「どのフォルダで開いたか」によってできることが変わるためです。

*5:もしプログラムを書く前の環境構築が難しい、面倒だと感じた方、それもとてもまっとうな感想です。環境構築は得てして面倒でつまづきやすく、現場のエンジニアでもこの作業に想定外の時間をとられてしまうことが珍しくありません。この問題を解決するため、環境構築を誰でも簡単に、ミスなくできるようにする工夫は様々なアプローチで今も行われています。

フリーランスエンジニアになってからの2か月を振り返る

会社を辞めてフリーランスになってから約2か月が経ちました。

キリの良いタイミングというわけではないのですが、なんとなく今の生活にも慣れてきたような気がしますので一度ここまでを振り返ってみたいと思います。

これからフリーランスをやってみたいけどなんとなくイメージがつかないなー、という方(つまり3か月前の僕)へ、何かのお役にたてれば。

フリーランスになるまで

はじめに、僕がフリーランスになろうと思ってから実際になるまでを振り返ってみようと思います。

がんばっていろいろアウトプットしてみた

僕がフリーランスになろうと考え始めたのは去年の夏くらいでした。言い方を変えると、フリーランスになると決めてから1年近くを準備期間として使っていた、ということになります。

その1年間は、とにかく外に向けて「これをやったよ!」が言えるようにアウトプットすることを意識していました。具体的には、Qiitaに記事を書いてみたり、Twitterしてみたり、自分で書いたちょっとしたソースコードGithubに上げてみたり、といった具合です。

それをすればフリーランスでもやっていける、というよりは、それができてやっとフリーランスのスタート地点に立てる、という感覚でした。

フリーランスになると、多くの場合仕事を得るために自分のことを全く知らない人に対して自分に価値を見出してもらう必要が出てきます。 つまり、自分が前の会社でどれだけ頑張ったとか、どんな製品を作ったとか、どんな人脈があったとか、そんなことは全く関係のない人に対し、「自分のスキルにはこれだけの価値があります」と言えなければなりません。そんな時に最低限の説明材料として必要になるのが、所属する会社に関係なく価値のある情報を、インターネットを通して誰でも見ることができる場所に公開されていることだと考えました。

いろいろやってみた結果、たとえばQiitaでは37記事を投稿して1294コントリビューションを得ることができ、フォロワーも49人まで増やすことができました。(2017/7/25現在) 周りを見渡すと決して多い数字ではありませんが、1年前に全くのゼロからスタートしたことを振り返ると、自分としては珍しくコツコツと積み重ねられたものだなと思います。(もともと飽きっぽい性格です)

詳しくは後述しますが、結果としてこれをすることで得ることができた知識や実績、自信などが役に立ち(かどうかはわかりませんが)、フリーランスになった後もすんなりと当面の仕事を確保することができました。

フリーランスについて調べてみた

また同時に、この期間にフリーランスの情報をネットで調べてみたりしました。 が、こちらは今振り返ってみるとあまり役に立たなかった印象です。

そもそもフリーランスエンジニアといってもスキルの低い人から高い人、仲介サイト経由で仕事を請ける人から自分で仕事を探したり創ったりする人などとても多様なワケですし、それぞれにメリットデメリット、楽しいことやつらいことがあるワケで、「フリーランスはこうだ!」と言える人はどこにもいないのです。

結局、自分はどう働きたいのか、そのために何を準備して、どんなスキルを身に着けて、誰にどうアピールしていけばよいのか、といったことを自分で考えて実行するのが大切で、同時にその自由さがフリーランスの一番楽しいところの1つなのだと今は考えています。

フリーランスになってから

フリーランスになって最初の仕事は、とある研修ベンダーの外部講師として新人研修のサポートをする、というものでした。

これは完全に前職のツテで決まった仕事で、その研修ベンダーの方々も僕のことをそれなりに知ってくださっていたため、とてもすんなりと話が決まった印象です。コネって大事だなー、と思った瞬間でした。

あまり詳しくは書けないのですが、この研修では技術以外にも企画の立て方を同じくらい叩き込まれる内容で、後ろで聞いている僕の方が勉強になるくらいでした。新人たちもとても前のめりでいろんなことにチャレンジしていて、とても楽しい仕事だったことを覚えています。

これともう一か所の研修の講師補佐を合わせて1か月ほどしていました。これが6月です。

7月から、つまり現在はとあるメーカー会社でAndroidアプリの開発をしています。 この仕事はとある仲介会社を経由して見つけることができた仕事で、今までのWebサービス開発とはまた違った経験のできる仕事です。

海外にも支社があるおかげでそこから来ている外国人も多く、雑談などを通してWebサービスの多言語化のヒントが多く得られる職場です。

3か月ごとの自動更新で、週5で会社に常駐のためあまり生活スタイルとしては会社勤めと変わらない働き方ではあるのですが、とりあえず安定した収入源は確保できた形です。

今の仕事が決まった経緯

前提として、僕は自分で仕事を探したり創ったりしたい派です。ただ、フリーランスになっていきなりそれで生活に十分なお金を稼げるほど簡単なことだとも思っていません。僕は家のローンもあれば子供2人の育児中でもあるので、まずは「食いっぱぐれない」ことがフリーランスとしての最初の目標でした。

そのため、ひとまず食いっぱぐれないために、前職のツテで知ることができた仲介会社へ相談して仕事を探してもらうことにしました。

驚いたのは、「7月以降の仕事のご提案をお願いします」とメールしたその直後から次々と仕事の提案が来たことでした。合計10件くらい提案をいただき、概要から判断して面談の日程調整を5件くらいお願いし、結局最初に調整のついた2件の面談をする、という流れだったのを覚えています。

1件は前職と同じような環境のWebサービスの提供会社で、もう1件は今のメーカー企業でした。

面談の結果はどちらもその場で「7月から開発に参加してください」で、当然両方の現場に参加することはできないため、今後の多言語化の仕事のプラスになりそう(海外に支社があって、同じチームに外国人がいることは面談の際に伝えられていた)という理由と、なんとなく前職と違う環境で違う経験も積んでみたいという漠然とした理由で今のメーカーの方を請けることにしてみました。

面談ではやはり先述したQiitaなどのアウトプットの部分から話が広がったり興味関心を理解していただけた場面が多く、そのあたりもすんなりと話が決まった一因になったのかな、と思っています。

仕事が決まる過程を振り返ってみると、仲介会社にあれこれ相談すればフリーランスでも食いっぱぐれることはないのだな、という感想です。 また、案件の紹介される勢いから見ても、エンジニアという職業はどこも人が足りていない様子がうかがえ、そこに対して適切にアピールできれば「仕事がない期間」ができてしまうなんて想像できない、というのが正直なところです。(当然、「適切に」アピールするためには日ごろのスキルアップとアウトプットが必要ですが) 報酬も、経費分を差し引いても前職の稼ぎより少し余裕が出るかな、という額なのでこちらも問題ナシでした。

面談をしていて印象的だったのは、今の案件の面談の中で、部長の方に「開発スピードに自信はありますか?」と聞かれ、とっさに「あります!」と答えると、「自信があるのはとても大事」とおっしゃっていたことでした。 その理由については特に何も伝えられませんでしたが、結局スキルなんて実際に一緒に仕事してみないとわからないものだから、自信の有無が今までどれだけ頑張ってきて、どれだけ役に立ちそうかの良い判断材料になる、ということなのかなと勝手に想像しています。

結果的に、1年間アウトプットを続けて得られた自信はここでも役に立てることができました。

これから

とりあえずフリーランスとして仕事をスタートできた段階ではありますが、今後はもっと自由な働き方で、もっと高い報酬で働けるようになることが当面の目標です。

といのも、フリーランスになった目的のひとつは、家事、育児や自分の趣味などの時間をもっと柔軟にとれるようになりたい、というものでした。特に育児については、子供がいつ病気にかかって仕事している場合でなくなるかもしれませんし、世間一般と休みをずらすことでより外出を楽しむことができたりします。これが、今まで通りの平日週5で会社に通うスタイルでは状況は変わりません。

さらに、子育て&週5の通勤だとスキルアップの時間が圧倒的に不足します。平日の日中はオフィスで仕事をしなければならず、休日は1日子供の相手をしなければならず、結局集中できるのは通勤電車の中と夜子供を寝かしつけたあとの合計1日3時間程度だけだったりします。

そのあたりを改善するためにも、1か月あたりの稼ぎをもっと多くして、仕事をしない期間があっても大丈夫な状況を作り出し、自分の都合に合わせて仕事とそれ以外の時間を調節できるようになりたいところです。

そして何より、Webサービスの多言語化という内容で自分で仕事を見つけ、自分で稼げるようになることを引き続き目指したいと考えています。今はとにかく仕事の内容を選ばずに稼いでいますが、やはり名刺にも書いた通り「Webサービスの多言語化」を自分の一番の価値として売り出せる仕事が僕の実現したいところです。

というわけで、Webサービスの多言語化はぜひ chooyan.engineer@gmail.com までご連絡ください!

その他

各種事務手続きについて

フリーランスになるための開業手続等ですが、思ったより簡単でした。 だいたいの場合、ネット上で軽く前提知識を得た上で窓口へ相談すれば効率よく必要な手続きについて教えてくれますし、その場で実際の書類を一緒に書いて提出までしてしまえば手戻りもなく手続きを済ませることができます。ついでに必要な手続きが他にあればその場で教えてくれたりもします。

小難しい手続きはネットで済まそうとするのではなく、最後は専門家を直接頼るスタンスで進めれば特に苦労することはないのだと知りました。

金銭感覚について

金銭感覚もだいぶ変わりました。 フリーランスは、正社員以上に収入が増減しやすいです。つまり、投資した分のリターンも見込みやすい、と考えることができます。

最近は、たとえば通勤の際の30分間の電車移動に片道400円の特急を使うようになったり、空き時間の作業場所をカフェではなくコワーキングスペースにしてみたり、といったことを意識してやってみています。多少お金がかかっても集中して何かをできる環境を確保することで、そこでの成果によって今後もっと良い条件の仕事を見つけられたり、副収入を確保できるのではないかと思っています。

また、同じような理由で自分や家族の健康やストレス解消に必要だと思ったものは、値段は見て見ぬふりをして買ってみるようにしています。フリーランスにとって病気(家族も含め)で仕事する時間が減ることはそのまま収入減につながりますので、多少の節約よりも健康への配慮を優先するようになりました。

業務内容について

正社員でなくなったことで、自分の仕事は「開発」のみになり、上司との面談や研修などの「組織のためのタスク」がなくなったことも大きな変化でした。

オフィスの椅子に座っている間は打ち合わせもなく、横から入るタスクもなく、ひたすら今自分に求められているアプリの完成に集中できるため、1日に使える時間が前職の5倍くらいに増えた感覚です。それだけ、横槍が全く入らないという状態は開発がはかどるものだと知ることができました。

もともと僕は会社から面倒を見られることにそれほど必要性を感じないタイプで、さらにはちょっとしたことで集中力が切れやすい人間だったため、この変化はとてもプラスでした。

まとめ

総じて、フリーランスに転向したことはとても自分にとってプラスになったと感じています。毎月のように新しい人たちと新しい場所で新しい仕事をすることができ、とはいえ収入が不安定になることもなく、今のところ仕事を楽しむことができています。 よくネット上で「フリーランスはやめた方が良い」という内容を目にすることは多いのですが、今のところそんな実感はなく、むしろこの働き方をもっといろんな人に体験してほしいと思ったりしているくらいです。(あまり無責任に勧めたりはできませんが)

とは言え僕もフリーランスになってまだまだ2か月そこらの駆け出しですので、1年くらい経った時にどうなっているのかは全く予想できていません。そのあたりはまた来年このブログにかければと思います。

最後に、フリーランスをやっていると「10年後どうするの?」とよく聞かれたりしますが、最近そんな先のことはあまりこと細かに考えなくなってきています。

前職では同じ会社に7年間勤めていましたが、1年前に予想していたことが次の年にあっさり覆っている、という経験を何度も体験しました。同じ会社に所属していても数年先はわからないのだから、先が見えないという点では正社員もフリーランスも変わらないような気がしています。

それよりも1年先にどうなっていたいかを考え、それを実現するためにどう行動すればよいかを考え、ちょっとずつ目標に近づいていく、というのを毎年重ねていけば、そのうちなるようになるんじゃないかな、というのが最近よく考えることです。 10年後については、「最低限子供たちの学費は無理なく払えるくらい稼ぎたいなー」ぐらいなものです。

長々と書いてしまいましたが、とりあえず僕は今楽しくフリーランスの仕事をしています、ということが今回書きたかったことです。 世間では祝日がないと騒がれる6月も、僕は合計6日ほど平日にオフがありました。

またなにか変化があればこのブログに書きたいと思います。

再掲:Webサービスの多言語化はぜひ chooyan.engineer@gmail.com までご連絡ください!

新卒から7年間働いた会社を退職してフリーランスエンジニアになりました

先週、新卒で入社して7年間働いた会社を退職し、フリーランスエンジニアとしての生活をスタートしました。

大学の専攻ががっつり文系だった僕でもエンジニアとして採用してくれ、3ヶ月の研修とさらに3ヶ月ものOJT期間を提供してくれて、徐々にエンジニアとしてのスキルを伸ばしながらWebサービスの開発の仕事をさせてくれる、とても良い環境の会社だったと思います。

この記事では、そんな会社を辞めてフリーランスに転向した経緯を振り返りつつ、今後フリーランスとしてどう仕事していこうとしているのかをまとめてみます。

どんなことをやっていたのか

前職では、主に自社開発のWebサービスをB to Cで提供する会社で、AndroidアプリやServletによるWebアプリケーションの開発をしていました。 言語はJavaが一番多く、次いでJavaScriptPython、という感じでした。

僕は落ち着かない性格で、1年前後のスパンでプロジェクトを転々とし、時には人事としても働いてみたりしながら、データのクローリングや整形、ServletJSP, JavaScriptによるWebアプリケーション開発、Androidアプリ開発、さらには新卒採用や教育研修まで幅広く経験しました。

そんな7年を経て、現在ではLinuxの文字だけの世界がとても居心地よく思えるようになったり、Qiitaに記事を投稿するようになったり、といったことは当時からすると考えられない変化ではないかと思います。

プライベートでもNode.jsやRailsを書いてみたり、EC2でマインクラフトサーバー立ててみたり、Raspberry Piで電子工作してみたり、だいぶエンジニアを満喫している現在です。

フリーランスへの転向の理由

そんな至れり尽せりの環境ではあったのですが、いつからだったか、「自分の技術に世間一般ではいくらの値段がつくのか」というのに興味が出てきました。 また、入社以来社内のエンジニアとばかり仕事をしていたので、勉強会やWeb上で見かけるような、外のエンジニアと仕事をしてみたいと思うようにもなりました。

自分の意思決定で、自分の責任において自分の好きな環境・条件で好きな開発ができ、好きにお金を稼げる、という状況にとても憧れがあり、最終的にフリーランスでやっていこうと決断して今に至っています。

今後

今後は「多言語対応フリーランスエンジニア」という肩書きで、Webサービスの多言語化を専門とするエンジニアとして仕事しようと思っています。 多言語対応はシステムの根本的な設計に関わるために一度進めてしまうと後戻りしづらく、とはいえ自社にノウハウを持っている会社もそれほど多くないと踏んで、この分野のプロフェッショナルになれば一定の需要があるのではないか、と予測しています。

多言語対応のライブラリは “i18n” とつくライブラリがどの言語にもありますが、それらのライブラリの使い方だけでなく、技術以前の言語や文化、宗教、政治などの文系的な知識も提供できるエンジニアとして、文系のメリットを最大限に活かしながら仕事ができればと考えています。実際調べていると多言語対応はシステム的にもテキストを翻訳すれば良いだけではないことがわかるのですが、そのあたりはこのブログに一つずつまとめられればと思っています。

多言語対応と言ったら @chooyan_i18n!と言われるよう、セルフブランディンク的なことをしていく所存です。(このあたりも文系的な知識が役に立つ、はず、、、!)

というわけで、多言語対応は @chooyan_i18n へ!

Webサービス多言語対応 技術的なチェックリスト

Webサービスの多言語対応について絶賛勉強中です。

この記事では、Webサービスの多言語化を実現するために、システム面でできることや考慮しなければならないことをチェックリスト形式でをまとめてみようと思います。


文字コードUTF-8になっていますか?

とにかく文字が表示できなくては多言語化は始まりません。 世界各国の文字を収録しているUNICODEは必須と言えるでしょう。

文字コードはシステムの全ての箇所で統一されている必要があります。 HTMLやアプリ等のフロントエンドだけでなく、サーバー、Webアプリケーション、DBなど、システム全体がUTF-8で統一されていることを確認します。

なお、UTF-8は日本語などの全角文字を3バイトで表現するのに対し、UTF-16は日本語も英語も全ての文字を2バイトで表現する、という性質上、アジア言語をメインにサポートする場合はUTF-16という選択肢も考えられるようです。 (とはいえ広く使われる文字コードはやはりUTF-8ですので、そこまでデータ量にこまかなチューニングが必要になるわけでなければUTF-8を使うのが安全なのではないかと思います)

テキストのハードコーディングはないですか?

システムにおける多言語化対応の大部分はテキストの翻訳作業です。

一般的に多言語化の仕組みとして、プログラム上ではテキストに対して「タグ」を割り当て、そのタグが具体的にどのような文字列を指すのかを言語ごとの翻訳テキストファイルから探し出す、という手法が広く用いられます。 プログラム内でテキストをハードコーディングしていると、そのような言語設定によるテキストの出し分けができなくなってしまいます。

多言語化を視野に入れた段階で、テキストをプログラム内にハードコードするのはやめ、タグと言語ごとの設定ファイルによってテキストを動的に変えられる仕組みを徹底するようにする必要があります。

スタイルはロケールによって切り替え可能ですか?

同じ内容の文章でも、文章の長さや読みやすいスタイルは言語によって様々です。

例えば、漢字という表意文字を使う日本語は、同じ情報量を英語よりもかなり少ない文字量で表現することが可能です。逆に、ドイツ語やフィンランド語は、英語よりも40%ほど文字数が多くなると言われています。

文字の長さだけでなく、右から左に文字が進むアラビア語、縦書きで左から右に文章が進むモンゴル語など、我々に馴染みの無いルールでテキストを表示する言語も存在します。

そのため、国際化対応ではテキストの変換だけでなく、そのテキストできれいにレイアウトを作るためにスタイルそのものを変えることが必要になってきます。そのため、言語設定ごとに適用するCSSやレイアウトファイルが切り替えられる仕組みを検討します。

画像はロケールによって切り替え可能ですか?

国際化において考えなければならないのはテキストだけではありません。画像も、対応する国や地域によっては大きな問題となる場合があります。

例えば、イスラム教では偶像崇拝を禁止しているため神様やそれに類する画像を見せるのは避けるべきです。また、女性の肌、髪の毛の露出なども、地域によっては避けたほうが良い場合があります。Webサービスではありませんが、スターバックスのロゴ問題などが有名です。

スターバックスのロゴ問題 中東編 : きよおと-KiYOTO

また、タイでは曜日ごとに色が振られており、国王や首相が生まれた曜日の色はその人を象徴する色となることがあります。そのため、社会情勢によっては色の使い方で「この人を支持する」という意思表示と解釈されてしまう可能性があったりします。

タイ人にとっての色のお話|INJカルチャーセンターのブログ

テキストだけでなく、画像も対象とする国や地域、社会情勢によってすぐに切り替えられるようにしておくと、不測の事態にすぐに対応できるでしょう。

入力フォームは各国の事情に対応できますか?

名前や住所は、国や地域ごとの文化や宗教などに大きく影響を受けます。 日本のように姓・名の入力ボックスだけではミドルネームを始めとする3つ以上の名前の構成要素に対応できないですし、逆に「よみ」はひとつの漢字に対して複数の読み方が存在する日本語固有の項目です。

ロケールによって入力フォームの構成が変えられること、また、テーブル構成がその入力内容を受け付けられることなどが求められます。

人名 - Wikipedia

サーバーの配置場所は大丈夫ですか?

例えば、ロシアやイランでは、サービス提供者はその国民の個人情報を国外に持ち出すことを禁止しています。

外国企業の半数がサーバ移転中――ロシア人ユーザの個人情報を国内に保管 / SYNODOSが選ぶ「ロシアNOW」 | SYNODOS -シノドス-

また、地理系のサービス提供者が中国でビジネスをする場合、地図データを中国国外に持ち出すことができないなど、様々な制約を課せられます。

http://www.tcci-wbiz.jp/hotnews/2140.html

このように、ターゲットとする国によっては電子データの扱いなどに法律による制限をかけている場合がありますので、それぞれの国の事情に合わせてシステム構成全体を考え直さなければならない場合があることを考慮しておく必要があります。

ネットワークは大丈夫ですか?

法律的な制限がなくとも、地球の裏側の国へサービスを届ける場合、どうしても物理的な距離によってリクエストとレスポンスの速度が数百ミリ秒という単位で遅くなってしまう場合があります。

また、物理的な遅延以外にも、ターゲットとする国や地域のネットワークの整備上記によって、現実的な通信量は変わってきます。

もしサービスが日本の通信網で、日本国内で使うことを前提に設計されているのであれば、データの通信量自体の削減を検討する必要がある場合があります。

URL体系は整っていますか?

例えば、以下のように日本語と英語のページで、URLのロケール部分だけが違うような設計になっている場合、ユーザーはURL自体を修正することで自分の求める言語のコンテンツを表示することができます。

・日本語
https://www.example.com/ja/some/contents/0001

・英語
https://www.example.com/en/some/contents/0001

ユーザーはどのリンクを踏んで、どの言語のどのページから自社のサービスに流入するか予測できないため、言語部分を修正するだけで同じコンテンツの言語違いのページを表示することができれば、ユーザービリティは大きく向上できるでしょう。

他にも、もしロケールによって準備ができていないページがあったとしても、該当のページが存在しないことをユーザーに提示した上で、一つ上の階層に戻るか、別の言語で表示し直すかを選ばせることができるような構造になっていれば、混乱を最小限に留めることが可能です。

サービスで利用する文言は全て任意のタイミングで表示できるようになっていますか?

翻訳者は、単語や文章だけ渡されてもそれを正確に翻訳することはできません。 想定ユーザーやサービスのコンセプト、どのような場合にどのようにそのテキストを見せるのかなど、情報量が多いほど翻訳はより正確になります。

そうなると、実際に翻訳者にサービスを触ってもらい、実際のユーザーとしての視点から翻訳作業が行えるのが理想です。

好きに触っても本番環境に影響がなく、翻訳をすぐに当てはめて検証することができ、レアなケースで表示されるテキストも任意のタイミングで表示できるような仕組みを作ることができれば、翻訳はより効率的に、正確に進められると思います。


以上、多言語化をするにあたっての技術的な確認観点をまとめてみました。 実際には、これに加えて各々のWebサービス特有の設計や事情から、他にも検討事項が出てくるのではないかと思います。

追加で記載できる内容があれば、この記事も随時更新できればと思います。

Webサービスを多言語化するリスクを考えてみた

IKEAサウジアラビアで製作したパンフレットが物議を醸しているという記事がありました。

IKEA's Women-free Catalogue in Saudi Arabia

内容は記事を読んでいただければと思うのですが、これを読んで、自社のWebサービスを「国際化」するつもりが「多言語化」だけで満足してしまうことのリスクについて考えたので、まとめてみます。

多言語化することのリスク

最初に紹介した記事はいわゆる「多言語化」とは違った取り組みですが、今までの顧客とは違った文化を持つ層にアプローチするという意味では多言語化するのと同じだと考えています。

その上で、多言語化することのリスクについて、以下の2つがあると思いました。

新しいターゲットに意図しないメッセージが届いてしまうリスク

例えば今私たちが日本語で日本人向けのサービスを展開していることを考えた場合、作る側が使う側の立場になって自分のサービスを見ることができるため、作る側が提示しているテキストや画像がどのように受け取られるのかをある程度予想することができます。

しかし、多言語化して自分とは全く異なる文化、言語で生活している人たちにサービスを提供するとなると、先ほどの「作る側が使う側の立場で自分のサービスを見る」ということができなくなるため、そのテキストや画像がどのように受け取られるか、予測することはほぼ不可能になってしまいます。

さらに、多言語化という意識で「言語」だけを見てしまうと、言語は同じだけれど国も文化も宗教も全く違う人たちの存在を見落とします。 例えば、スペイン語はスペインだけでなく、はるか海を渡った中南米でも公用語として使われていますし、中国語(特にMandarinと呼ばれる共通語)は中国本土の各地域や台湾、香港、さらにはシンガポールといった様々な国や地域で、13億人以上が読むことができてしまいます。

私たちが日本語で日本人に発しているテキストを単純に翻訳すれば、新しいユーザーにもそのまま同じように届くとは限らないのです。

想定外の人にメッセージが届いてしまう

今回のIKEAの件は、イスラム教を厳格に守っている人たちに向けてサービスをチューニングした結果、それが全く意図しない「女性の人権を考える人たち」に拾われてしまったことが発端のようです。

つまり、良かれと思って特定の言語に対応した結果、それ自体を快く思わない人たちが出てくるリスクがある、ということになります。

例えば、同じハングルでも韓国と北朝鮮では書き方・読み方に方言のような差異があるそうなのですが、韓国人向けにハングルでサービスを提供した結果それを目にした北朝鮮の人が「ハングルと言ったら北朝鮮だろう、なんで南訛りの表記をしているんだ!」とクレームの声を上げることも考えられないことではありません。

上の例はさすがにそう起こることではないかと思いますが、とはいえ宗教上の対立、紛争地域、歴史的な経緯などが影響して、「こっちのユーザーを想定してこの言語で出したら、それを読めちゃうあっちのユーザーが不快に思う」という事態は十分起こり得るのではないかと思います。


システム的な多言語対応というと、言語設定ごとのテキストの変換や、画像などのリソースファイルの選択をサポートしてくれるものがほとんどで、それを使って満足してしまうこともあるのではと思いますが、それだけでは不十分どころか、サービスの内容や翻訳方法によってはブランドイメージを損なう可能性もあるのではないかとIKEAの記事を読んで考えました。

本当にターゲットの国のユーザーに使ってほしいのであれば、テキストの翻訳だけで満足するのではなく、いわゆるグロースハックのような、継続的な検証と修正が国・地域ごとに必要なのではないかと思います。

技術的には、翻訳文を変換する仕組みの実装だけでなく、国・地域ごとに継続的に細かなチューニングができる柔軟な環境づくり、場合によってはある国向けのサービスだけ全く別のシステムとして構築し直すことになった場合にシステム全体を再設計する力、などが必要になるのではないかと思います。

やればいいというものではない、ということかなと思います。

i18n対応で参考になりそうなサイト

Webサービスの国際化対応について勉強するにあたり、参考になりそうなサイトをまとめます。随時更新です。

コーディングのガイドラインなど

文字コードとは、みたいな基本的なところからまとまっているので入門として使えそう。

Androidアプリを国際化する際に知っておきたい基本的な仕組み。

実際の例

実際に世界中にサービスを展開している企業のウェブサイトは参考になることが多い。

stackoverflowの議論

それぞれ言語は違うけれど、サービスを国際化する際に考えなければならないこと、という意味では特にどの言語で書くかは関係ない。

その他参考になりそうな記事

SwiftでiOSアプリを国際化する際に知っておきたいTips、ノウハウなど。iOS以外でも同様に使える知識が書かれている。

“10 Best Practice Tips On How To Write Global-Ready Content For Localization” というタイトルの記事。国際化対応は大変だけど、これだけ抑えておけばある程度対応が楽になる、という話。

さらにその他

Webサービスが開発できる言語であれば、だいたいサービスの国際化をサポートするライブラリなりツールなりが開発されているので、それらができることをじっくり見ていけば、どんなところに気をつける必要があるのかある程度分かってくる気がします。