今年の夏、プログラミングをしている時に聞いている音楽の９０％は大森靖子でした。６月くらいに知ってから、かなりのヘビーローテションで聞いています。

この人のことが気になっていろいろ調べたら、この人はセルフマーケティングがしっかり出来ていました。それを強く感じたインタビュー記事を引用します。

「売れない、メジャーのレーベルに見つけてもらえない、という点を卑屈にばかり思って5年ほど活動した末、これからは絶対に好きなことだけやって生きてやろうとすべてのバイトをやめました。そしてそれをきっかけに、「売れるために自分は冷静に策を立てていたか？ 良い曲を作る、良い歌をうたう、そんなのは当たり前で、歌手だから他の努力はしないなんていうのは怠慢ではないか？」と思うに至りました。自分の状況を冷静に見つめたとき、

1. ひとりで活動しているのでバンドに比べて予定の擦り合わせの手間がなく機動力が高い。

→ 出演ライブ、イベントを場所やギャラや面子で選定せずとにかく手当たり次第出演する。

2. スタッフがいない＆幼少時代から何をやっても天下がとれず器用貧乏だと思っていた自分の性質

→ キュレーター気質な、つぎはぎのもの作りが認められるようになったいまの時代に向いているのではないか。「素人っぽい」はとりあえず気にせず、文章を書くことも、CDジャケのデザイン入稿も、フライヤーのデザインも、CDの発注書の処理も、とりあえず全部自分でやってみる。世界観を細部まで自分だけで創り上げることができて有効だと考え直す。

3. 大火傷しがちの感情的な性格

→ 隠さない。スルースキルを絶対に身につけない。笑顔ですべてかわすという、人として確実に不健康な風潮を認めない。ちゃんとしなきゃだめ、という誰かの決めた理想像、概念を一切受け入れない。

というように、いままで弱点だと思っていたところをすべて活かせるように、考え直すことができました。
ルールを目的にしない創造的な日本へ―シンガーソングライター 大森靖子

こうして、シンガーソングライターとしての指針が決まると、強いだろうなと思いました。そして、このプロセスは「結果が出ない」、「認めてもらえない」と嘆き・ぼやくクリエイターが一歩足を踏み出すヒントがあると思いました。改めて引用します。

「売れるために自分は冷静に策を立てていたか？ 良い曲を作る、良い歌をうたう、そんなのは当たり前で、歌手だから他の努力はしないなんていうのは怠慢ではないか？」

「良い曲を作る」「良い歌をうたう」「歌手だから」を自分がアウトプットしているものや、自分の職業に置き換えてみましょう。例えば私は、プログラムを書いたり、アプリを設計・開発するプログラマです。

「売れるために自分は冷静に策を立てていたか？ 良いプログラムを作る、良いアプリを設計・開発する、そんなのは当たり前で、プログラマだから他の努力はしないなんていうのは怠慢ではないか？」

ぐうの音も出ないとはこのことですね。当たり前のことをやっているだけなのに、必死にやっていて、それを認めてくれと周りに求めても、「当たり前じゃん」って感じですね。

そして、大森靖子さんと同じように、自分の状況を整理して、動き方、アウトプットの仕方を見直しました。今でも不平不満が出そうになったり、ネガティブな感情に支配されそうになった時は、大森靖子を聞き、この言葉を思い出して、踏ん張っています。

USJを変えたマーケティング術が話題ですが、大森靖子さんの曲を聞くのもマーケティングにはいいですよ。というお話でした。

引用した記事

受託開発において、新技術を採用するタイミングは悩ましい問題です。特に規模が大きくなるにつれ、お客さまに必然性や納得性を説明することが難しく、使い慣れた技術で開発をしている現場も多いでしょう。

しかし、使いやすいユーザーインターフェースを実装するためには、そろそろ新技術を取り入れないと、お客さまの要求水準を満たせなかったり、フロントエンドエンジニアの労働時間が指数関数的に増えていくと思います。

この記事は、そんな労働時間が指数関数的に増えているフロントエンドエンジニアやそれを見かねたリーダーが、Reactというユーザーインターフェース用のライブラリの導入を進められるように、上司やお客さまを説得するためのポイント（Reactがどんな問題を解決するのか）をまとめました。

jQueryはプログラムを簡単に書くために開発されたライブラリ

今なお多くのウェブサイトがユーザーインターフェースを実装するためにjQueryというライブラリを使用していると思います。jQueryは、JavaScriptというブラウザ上で実行できるプログラムを簡単に書くために開発されました。

というのも、jQueryが生まれた2006年は、JavaScriptがブラウザ上で実行できましたが、ブラウザごとに文法や命令文が違っていて、全てのブラウザで同じ動作をさせるのは職人技でした。その職人技を誰もが使えるようにライブラリにまとめたものが、jQueryの始まりです。

ちなみに、この頃のウェブサイトというと、mixiが印象的です。日記を書いて、みんなにコメントしてもらうというブログやSNSの存在が一般的になりました。

iPhoneが発表されておらず、インターネットといえば、パソコンでmixiを見る。そんな時代に誕生したjQueryは、「簡単に書ける」ということをうりにどんどん使われるようになっていきます。

iPhone登場後、ウェブサイトのアプリケーション化が加速

jQueryの登場から2年経ち、iPhoneが発表されました。心地よく・直感的に操作できるインターフェースがユーザーの心を掴み、一気にモバイル化・アプリ化が進みました。これを受けて、ウェブサイトもアプリのようなサクサク・ヌルヌルした動きを求められるようになました。

この頃から、ボタンをクリックしたら入力フォーム画面に移動して文章を書くというウェブサイトよりも、ボタンをクリックしたら画面内に入力フォームが浮かび上がるような、画面を移動せずに画面の一部が変化するウェブサイトが増えてきました。

このように、ウェブサイトのあり方が変わってくると、JavaScriptに求められるものも「簡単で書ける」ことから「画面の変化に柔軟に対応できる」ことに変わりました。そして、その手法（フレームワーク）が数多く誕生し、消えていきました。

というのも、どの手法も一見jQueryの問題を解決できていそうなものの、何か本質的な課題を抱えたまま決めてにかけていました。

なぜ、画面の一部を変化させるのが難しいのか

「日記を書く」ボタンをクリックすると「日記フォーム」に移動するのは簡単なのに、同じ画面に日記フォームを表示するのがなぜ難しいかは、なかなかイメージしにくいと思います。ただ、ここを理解することが重要なので少し掘り下げます。

ウェブサイトにはDOMという仕組みが使われており、画面を移動する場合は、DOMを1から作り直します。反対に、画面の一部を変更する場合はJavaScriptを使ってDOMを操作します。日記フォームを表示するくらいであれば、なんとかなりますが、日記フォームの中の絵文字ボタンをクリックすると、絵文字パレット表示して、絵文字パレットでは使いたい絵文字を検索できて…など、機能が増えていくごとに爆発的に複雑さが増していきます。

もしも、ボタンをクリックする度にDOMを1から作り直すことができれば、複雑さの大部分を解決することができるのですが、毎回、画面を移動していては時間がかかってiPhoneに慣れたユーザーが離れてしまいます。

そんな中、「時間をかけずに、ボタンをクリックしたタイミングでDOMを1から作り直しことができないか」という仮説から生まれたのがVirtual DOMという考え方です。

Virtual DOMというパラダイムシフトとReact

Virtual DOMとは、名前の通り、仮想のDOMです。DOMと一対一で対応し、画面には表示されずデータとして存在している見えないDOMだと思ってください。

ボタンをクリックした時は、Virtual DOMを1から作り直します。そして、Virtual DOMと対応するDOMを比較して変更があったDOMを更新します。こうすると、DOMを1から作り直すようにウェブサイトを作りながら、実際にはDOMの一部を更新することが出来ます。

このVirtual DOMという考え方をライブラリとして誰でも使えるようにしたものがReactです。

Reactは、こうした背景の中2013年にFacebookが発表して以降、海外のスタートアップで積極的に取りれられ日本でも2014年の冬頃から採用事例が増えてきました。

Reactが必要かを判断できることが重要

今では、開発元のFacebookをはじめ、Instagramやtwitter、airbnbなど人気のあるサービスで採用されているReactですが、jQueryに比べて手間がかかる部分もあるので、メリットを理解したうえで使いどころを見定めることが重要です。

例えば、Reactの国際的なカンファレンスのウェブサイトにもReactは使われておらず、jQueryが使われています。

また先日発表のあったLINE MOBILEの申し込みフォームは、とても見やすく使いやすいですが、こちらでもReactは使われておらず、jQueryが使われています。

長くなりましたが、自分がフロントエンドエンジニアとして、ユーザーインターフェースの実装をすることになるウェブサイトのユーザーや使い方、ストーリーを理解したうえで、Reactを使うべきかどうかを判断できるようになれれば、上司やお客様にも自然と納得してもらえる説明ができると思います。

ReactやVirtual DOMの理解を深めるのにおすすめの記事・スライド

私が、ReactやVirtual DOMを理解するまでによく読んだ記事やスライドを紹介するので、もう少し知識を増やしたい方は参考にしてください。

また、もしもまだ実際に手を動かして作ったことがない方は、まず、公式チュートリアルを一度やってみるといいと思います。

いろいろと社会現象が起きているようですが、個人的に気になったものを2つピックアップしました。

新宿御苑が大変

『新宿御苑にピカチュウ』が出ると噂が広がり、日曜日の新宿御苑に異常な人集りができたそうです。

人集りの中、頑張ると、こんなにピカチュウがゲットできたそうです。

警察が摘発・補導ツールに採用？

「ルアー」というポケモンをたくさん出すアイテムを使うと、使っていないひとからも「ルアー」を使っていることがわかります。それを利用して深夜の公園でルアーを使っていると、少年少女が集まっている判断しているそうです。

ちなみに、夜の公園でルアーを使うとこんな風になります。

とにかく時間のかかるゲームなので僕は早々にリタイア気味ですが自宅で毎晩11時にフシギソウというレアポケモンが出るのでそれはゲットし続けようと思います。

彼女の体内に埋め込まれたナノマシンが、彼女の視線や行動、言動、感情を計測し、その内容を人工知能が解析すれば、きっと彼女が潜在的に欲しいものを明らかにできる。だけど、僕はそれを知って、機械の言われるがままにプレゼントを用意することはできない。

プレゼントの本質は、思いを馳せた時間

僕何をプレゼントしたかは重要じゃない。重要なのは、数多ある可能性の中からそのプレゼントを選んだプロセスや時間だ。

例えば、カバンをプレゼントに送ろうとする。しかし、ブランドや形、色など、組み合わせは無限大にある。そこからたった１つ（もしくは数個）に絞るために必要なのは、とにかく思いを馳せることだ。まずは、最近着ている服や読んでいる雑誌の傾向、生活スタイルなど、自分が知っている情報を丁寧に思い出し、つなぎ合わせながらなんとなくイメージを描く。

次に百貨店やセレクトショップに足を運び、とにかく数を見る。店員や友人に話を聞き、トレンドや使い勝手を調べ上げる。

これを1週間繰り返すと候補が３つ〜６つになるので、自分の直感を信じて１番グッと来たものを選ぶ。別の言い方をすると、渡した後に「ここがいいと思うんだ」と言いやすいものを選ぶ。

あとは、祈るのみ。

思い馳せた時間は、僕だけのもの

ここまでやって喜んでもらえる確率は、これまでの実績で５０％くらいだと思う。また、一度成功すると、次は、その時を上回らないといけなくなるので、難易度はどんどん上がる。

それでも、思いを馳せながら、ああでもないこうでもないと考えた時間は、何気ない言葉や行動に表れる。だから僕が選んだプレゼントより、人工知能が選んだプレゼントの方が、瞬間的な喜びは大きいかもしれない。だけど、思いを馳せた時間の大きさは、きっとそれを凌駕する。

現実問題

妻の誕生日まであと2週間。人工知能の助けを借りたい気持ちはグッと抑えて頑張ろう。

大学生の頃、よく通ったイタリアンレストランがありました。それはJR円町駅の裏道から住宅街に入ったところにひっそりと店をかまえるCheerという名前のイタリアンレストラン。僕が社会人になると同時にシェフが体調を崩して閉店してしまったので、今はもう行くことができません。

1階には雑貨屋があり、独特のラインナップでした。そこで買った雪だるまの指人形は今も棚に飾っています。2階に上がると、耳触りのいい洋楽が聞こえ、ドアを開けると柔らかい光に照らされた大きなソファが目に映ります。テーブルとテーブルの間は、隣の席の話し声が聞こえないくらい余裕がありました。

料理もお酒もとてもおいしいのですが、その辺りは学生街なこともあって、値段は手頃でした。何度行っても閉店時間ギリギリまで居てしまい、お店の方には迷惑だったかもしれません。でも、あんなに居心地がいいお店にはまだ出会っていません。

前置きが長くなりましたが、私はMediumに、このイタリアンレストランと同じ心地よさを感じています。どちらにも時代の流れに左右されない変わらない良さがあります。レイアウトや色合い、形、手触りなどが自分の感性にピッタリあって、気持ちいい。しばらく顔を出しておらず、久々におとずれると、「やっぱりここが1番だな」と再認識する感じ、私は好きです。

たくさんの人に見てもらいたいけど、あんまり流行り過ぎて欲しくはない。世の中的な流行りではなく、A/Bテストの結果でもなく、運営者の感性の赴くまま自由に変化して欲しい。

大流行することはないけれど、いつもそこにあって、ファンから愛されている。そんなウェブサービスがひとつくらいあって欲しいし、それがMediumだったら私は嬉しいです。

と山を張っている。正確には、作業的な仕事を効率よく行う手段として流行る可能性はあるが、生活の一部分を置き換えることにはないだろうと考えている。なぜなら、チャットボットを操作するためには文章の入力が必要で、それはスマートフォンで最も面倒な操作だからだ。

文章を入力するほど面倒くさいことはない

スマートフォンの優れているところは、アイコンやボタンをタップして操作できるという直感性だと思う。写真アプリのアイコンをタップすると最近撮影した写真がズラッと並び、気になった写真タップすると、大きくなる。大きくなった写真をタップして指を左右にズラすと前後の写真に移動できる。まるで現実世界のアルバムを見ているような気にさせるのが、マウスで操作するパソコンとの決定的な違いだと思う。

そんな直感的に操作できることが魅力のスマートフォンでも、文章を入力するのは面倒だ。とりわけ日本語は面倒で、まず小さい画面の中に表示された9つのボタンを丁寧に使いわけてひらがなを入力し、その後9つのボタンの上部に表示された漢字の変換候補から適切な漢字を選ばなければならない。

そんな文章入力をコミュニケーションの中心にして、機械と会話することをユーザーが望むとは思えない。少なくても僕は嫌だ。それなら電話した方がマシだ。

チャットボットが解決できない時に人間に変わるのは、サービス提供側の都合

チャットボットの活用事例としてよくあるのが、お問い合わせをチャットで受け付けて、その1次対応にチャットボットを使うというもの。よくあるお問い合わせであればあらかじめ用意した内容をすぐに返す。もしチャットボットで判断できないものがあれば人間がチャットボットに変わって対応する。

サービス提供側のコストカットに繋がるのはよくわかるが、ユーザーとしてたらい回しにされるのは感覚的に気持ちいいものではない。それだったら最初から人間と話させろと思う。

ボットは自動的に情報を取得し、いい頃合いでユーザーが必要なものを提供しなければならない

ユーザーに文章を入力してもらい、その内容を判断するのは、前時代的なボットだと思う。そうではなく、ユーザーの知らない間にいろいろな情報を取得していて、その内容からユーザーが必要なものを、絶妙なタイミングで提供する。そんな気の利くボットが必要だと思う。

気の利くボットのデザイン

ユーザーが情報を入力する必要がなくなれば、チャットのような見た目はベストではなくなる。例えば、iOS 9のProactive Assistantみたいな方が適していると思う。Proactive Assistantは、iPhoneがユーザーの利用習慣を学習し、その時、その場でユーザーが探したい情報を提供してくれる。

運用しているソフトウェアのバージョン管理システムを変更するには、開発責任者や間接的に影響の出るステークホルダーへの説明が必要です。ただ、バージョン管理システムというツールの性質上、変更するメリットや必要性についてはなかなか理解されません。

私自身、SVNというバージョン管理システムを使用しているソフトウェア開発に携わっていますが、長らくその問題点については気づいていませんでした。

しかし、平行して複数の機能を開発した時に、バージョン管理にかかるコストが爆発的に膨らみ、SVNを使い続けるリスクを身を持って感じました。そこで、この記事ではSVNやVSSといった前時代のバージョン管理システムを使い続けるリスクとその解決方法についてご紹介します。

バージョン管理システムとは

バージョン管理システムは、ソフトウェア開発に必要な最重要ツールのひとつです。バージョン管理システムという言葉を初めて聞いた人や、よく知らない人は、以下のページに概要や必要性がわかりやすくまとまっているので読んでみてください。

（上記ページより抜粋）バージョン管理システム(VCS)を使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。

現在、新しいソフトウェア開発の現場では、Gitというバージョン管理システムを使うことがスタンダードになっています。少し前は、Subversion（SVNと呼ぶのが一般的）やVSSというバージョン管理システムが主流でした。

バージョン管理システムを正しく使う

バージョン管理システムをただ使うだけでは、複雑化・大規模化するソフトウェア開発を安全かつ速く進めていくことはできません。

例えば、以下のような変更履歴のあるファイルを想像してください。

// あるファイルの変更履歴
1. いいねボタンを押すと投稿に「いいね」できる
2. いいねボタンを押すと投稿に「いいね」できる（バグ修正）
3. iPhone5だけうまくいかなかったので修正
4. いいねボタンを長押しすると、6種類のリアクションを選べるようにした
5. iPhone5だけうまくいかなかったので修正
6. バグ修正
7. いいねボタンにハートアイコンをつけた

ファイルを以前の状態に戻せるといっても、いつ、どんな変更を行ったかを誰が見てもわかりやすくしておかなければ意味がありません。同じファイルでも以下のようになっているとだいぶわかりやすいですね。

// わかりやすい変更履歴の例
1. いいねボタンの新規作成
2. [機能追加]いいねボタンを長押しすると、6種類のリアクションを選べる
3. [緊急対応]いいねボタンをクリックした時に他の人にいいねしてしまうバグを修正
4. [機能追加]いいねボタンにハートアイコンをつける

実は、この程度の変更履歴であれば、最初の例でも、それぞれの詳細な変更内容を目で追っていけばなんとかなるかもしれません。ただ、長年開発を続けていると変更履歴が1万を超えることはよくあります。1万個、目で追うのは現実的ではないですね。

誰が見てもわかりやすい変更履歴になるように心がける。これがバージョン管理システムを使ううえで最も重要なことだと私は考えています。

とはいえ、最初から見やすい変更履歴になるように開発を進めることは現実的ではありません。最初からバグのないプログラムをかける人間はいないでしょう。

しかし、もしもある程度バグを修正し終わったタイミングで変更履歴を整理できれば、誰でも心がけ次第で綺麗な変更履歴を作ることができそうです。少し先出しになりますがGitは、後から変更履歴を整理することができます。

SVNの問題点

これまでにバージョン管理システムの概要と正しい使い方について説明しました。バージョン管理システムは、ファイルの変更履歴を残すためのツールで、変更履歴をわかりやすくすることが重要でした。ただ、最初からわかりやすい変更履歴にすることは難しいので、後から整理するのが現実的なアプローチでした。ここまで読むと、なんとなくSVNの問題点がわかってきたかもしれません。

SVNの問題点、それは、変更履歴を後から整理することができないということです。SVNは「集中バージョン管理システム」とも呼ばれ変更履歴の改変は不可能な作りになっています。

ソフトウェアの設計や開発をしている時、頭の中に小人がいることに気がついた。ふたりの名前は、カジュアルくんとシリアスちゃん。

カジュアルくんは楽観的で感覚的、口癖は「これ面白くない？」。シリアスちゃんは悲観的で論理的、口癖は「なんでやるの？」。ふたりの性格や考え方は正反対だけど、最近仲がいいみたい。

それは、自分の強み・弱みを知り、お互いの必要性に気づいたから。カジュアルくんは慎重に考えることが苦手で、シリアスちゃんは思い切って行動することが苦手。ひとりでは行き詰まってしまうこともふたりなら答えが出せる、動き出せる。

中庸ってこういうことなんだろうな。