ボクココ

サービス開発を成功させるまでの歩み

流行を生み出すスタートアップ

ども、@kimihom です。

いつの時代にも流行がある。流行は時に個々の判断を鈍らせ、「あの人がやってるから自分もやる」というだけでどんどんと広がっていく。一方でその流行は、発起人が意図的に仕組んでいる側面がある。本記事では意図した流行をどうやって生み出していくのかについて考えてみたい。

流行の始まりは、今見るとちょっと変わったこと

流行の始まりは、現時点で他の誰かから見ると一風変わったように映ることが多い。流行する前なので当然他の人にとっては一般的ではない何かである。その何かを最初に見つけた熱狂的なフォロワーたちによって、やがて未来の当たり前になる。 熱狂的なフォロワーの勢いはどんどん増していき、ある一定のタイミングを過ぎるとむしろそれをしない方がダサいくらいになる。すると今度はその"流行"に乗り遅れまいと誰もが参加するようになっていく。以下のTED はあまりにも有名なので見たことがある方も多いだろう。

誰もがご存知の Facebook は当時大学生のザッカーバーグが作ったことは有名な話だろう。Facebook 自体も、最初のユーザーは他から見たら人の顔写真集めてニヤニヤしてる狂ってるヤツらという風に見られていたに違いない (事実、映画「ソーシャルネットワーク」にはそのように描かれていた)。しかし、あまりにも Facebook の初期ユーザーがコアなファンであったため、その熱狂が他人に伝わり、大人にも伝わり、世界にまで広がっていった。今では60歳のおっちゃんまでが使うくらいに一般化されているほどの熱狂である。

www.amazon.com

その流行を作ったのは、紛れもなく 当時10代の若者ザッカーバーグだったのだ。

この成功を予測できなかったからこそ、彼は多くの株を持ちながら上場し、会社を大成功させるという偉業を成し遂げた。こうして彼は世界で誰もが知る有名人となって今でも革新を起こし続けている。

ここで何が言いたいのかっていうと、「ザッカーバーグ並みに超大成功したいなら、現時点で"これから流行る"って言われているような事業を興しても既に遅い」ってことだ。投資家とか成功したビジネスマンとかから 「そんな事業儲かるの?」と言われるくらいのものじゃないと未来のザッカーバーグにはきっとなれない。もしあなたが一発大逆転を狙う、流行を生み出す源 になりたいのなら、年寄りからは狂ってると思うわれるくらいのサービスを考えてみてほしいと思う。

加えて、初期段階でそれなりの割合で投資を受けてしまったら、その時点であなたは未来のザッカーバーグになることは難しいという点も伝えておきたい。ザッカーバーグがなぜあんなにすごいのかというと、株を社長自らが保有しながら、ものすごい評価額で上場したという点だ。そうして彼は一般的には不可能である、富と名声の両方を手に入れることができたからこそ、希少なのである。 初期段階でお金を受け入れて自分の持ち株がどんどん薄くなってしまったら、どんなにビジネスが成功してもあなたはその持分を株主に還元する必要があり、株主と調整しながら事業を進めていかなければならなくなる。そんで事業がうまくいかないと社長追放などもある厳しい世界だ。

(Facebook 上場時、彼一人で 28% を所有していたとのこと。) Facebookの大株主一覧:ザッカーバーグは28%を所有 | TechCrunch Japan

最初に流行を作るのは、いつの時代も若者から

そしてもう一点大事なポイントを挙げさせてほしい。いつの時代も、若者が流行を最初に作り出すという事実がある。彼らは常に新しいものを探し続け、いいものを徹底的に使い、すぐに友達に広めてくれる。その友達も波に乗り遅れまいと、真っ先にその輪に加わることだろう。こうして流行が生まれる。

だからこそ、若者が BtoC の分野で起業するってのは至極真っ当な戦略であると言える。一部の大学生が熱狂するレベルのサービスが出てくれば、それは未来の Facebook になるポテンシャルを秘めている。その熱狂は学生間で即座に広まり、やがて若い社会人にも使われるようになり、ゆくゆくは60歳のおっちゃんでも使うくらいのレベルにまで成長していく。

BtoC の起業で25~30歳くらいになってしまったら遅いくらいかもしれない。その頃にはそれぞれ自分なりの価値観的なものが出てきてしまい、新しい何かが出てきてもすぐに判断して取捨選択してしまうようになる。これは次の流行を生み出す上では致命的で、全員の価値観を満たす 70点くらいの何かになってしまう。30代で流行する何かってのがいつの時代も出てこないのはこれが理由だと考えている。

一部のファッションや化粧品は CM や雑誌などで大金をはたいて半ば強引とも言える形で流行を作り出そうとしている。そうしないと若い層に届かないからだ。でも現時点であなたが大学生だったらそんなことをする必要がない。自分が最初の流行を作り出し、他の人たちが乗ってきてくれるような仕組みを最初に作ればいいだけなのだ。そこのアドバンテージを活かすことができた時、学生起業で大成功するという誰もが憧れるステージに上がることができるだろう。

終わりに

とにかく最初の流行を作り出し、熱狂的なファンを獲得すること。その最初の一歩を超えられれば、やがて未来の常識を自らの手で作り出すことができるはずだ。そんな未来のザッカーバーグが日本からも出てくることを期待して、この記事を締めるとする。

ソースコードに「愛着」はあるか?

ども、@kimihom です。

f:id:cevid_cpp:20171015162220p:plain

今回はちゃんとしたソースコードを運用し続ける上で大切な考え方について記す。

あなたは読み直せるソースコードを書いているか

ハッカソンや 0->1 のフェーズの何が楽しいのかというと、真っ白なキャンバスに思いっきり絵を描いていけることだ。これから作ろうとしているのが自分の頭の中にあって、それを具現化していくステップってのはワクワクするし、完成した時の満足感もひとしおだ。

さて、そんな急ピッチで作り上げたソースコードってのは、大抵はひどく醜いものだ。ぐちゃぐちゃなソースコードに対してテストケースを書いていくのも大変だし、何しろバグも多く存在することだろう。しかし、それは最初のフェーズでは認めるしかない。どんどんと変わっていく仕様に対して柔軟にソースコードを変えていくのだから、当初考えていた設計と異なっていくことなんて日常茶飯事で、未来のことを見据えた完璧なソースコードを最初から生み出すなんて不可能だ。

だからこそ、唯一ソースコードを改善し続けることこそが、いいプログラムのコードを保ち続ける方法だ。そして、ソースコードを綺麗にし続けるには、ソースコードに愛着があるのか が重要となってくる。

ソースコードに愛着を保ち続けるってのは本当に難しくて、一度でも愛着がなくなってしまうと、自分や誰かの書いた酷いコードをそのまま放置したままの状態になってしまったりすることが頻発する。すると、「あの部分のソースにはもう手をつけたくない」となって、その部分のサービスの改善が困難となり、やがて開発スピードが劇的に落ちる。 最初作り始めていた頃に比べて明らかに開発速度が落ちている という感覚を感じ始めた頃には、もう手遅れだ。

エンジニアがそのプロダクトやソースコードに愛着がわかなくなるターニングポイントってのが存在する。

  • システムに関わるエンジニアがどんどん増え、"自分が書いた" という感覚が薄れていく
  • ある日誰かが書いたとんでもなく汚いソースコードを発見してしまい、メンテ不能であることを悟る
  • 周りのエンジニアのレベルが率直に低い、成果物の手戻りが多い
  • エラー通知やテスト失敗通知が来すぎて通知を無視するようになった
  • 不本意な機能開発を命じられてサービス自体に愛着が沸かなくなった
  • しばらくしてもサービスがそもそも使われていない

こうしたタイミングで、一気にソースコードに対しての愛着が薄れていく。流行りのクールな開発手法を取り入れたところで変わらない。むしろ、ソースコードに愛着を保ち続けることが、最も大切な開発手法 ではないだろうか。

なぜソースコードを美しく保ち続ける必要があるのか

こんな話はエンジニアにとっては至極当たり前なんだけど、「ソースを綺麗に保つことに時間を使ってビジネスにどう寄与するの?」みたいな、目の前のカネ儲けにしか目がない方々に向けて書いておきたい。

まずソースコードを美しく保ち続けるだけで、開発スピードは劇的に上がる。なぜなら、不用意なバグに悩まされ続ける時間を無くし、設計/実装時に悩む時間を無くすことができるからだ。誰かの書いた酷いコードに対して機能追加/修正/削除 するには、まずその酷いコードを理解しなければならない。それが複雑であればあるほど、最初のステップで大きくつまづいてしまう。んであまりに酷いと作り直しっていう荒技に出るしかなく、誰かのコードを書いたその時間は完全に無意味なものとなってしまう。

おっと、ここで大金で優秀なプログラマを雇えば OK とか言っても無駄だということを付け足しておきたい。途中でどんなに優秀なプログラマが入っても、最初にとんでもなく酷いメンテ不能なコードが目の前にあれば、それだけで開発者のやる気を失わせる。以前の負債を返済することがその人に仕事となってしまい、その人の持つ能力を最大限発揮することができない。酷いコードを整備していくだけで半年や1年はかかるので、それまではどんな優秀なプログラマが入っても開発が遅くなってしまう。それだけ「誰かが書いたコードを読んで修正する」って作業は難しいのである。

だから、最初から綺麗に保ちつづけようという意識が大切だ。最初ちょっと強引に書いちゃったコードがあれば、その後にちゃんと時間をかけて修正して改善していかなければならない。そんな地味な改善を繰り返すことで、初めてソースコードに愛着が持てるようになる。そんなソースコードが書かれたプログラムは、何かしらの修正に非常に強くなる。だからこそ、どんなビッグチャレンジでも受け入れられる開発体制ができあがる。

1つのシステムで人数をかければその分開発速度が速くなるってのが誤りであるのは、まさにこのことだ。人が多くなればなるほど、1人1人がソースコードに愛着を保ち続けるのを難しくさせる。「どうせ自分はそのうち辞めるし」とか「どうせ自分は雇われ給料もらってるだけだし」とか、そんなことをちょっとでも思っているエンジニアがいれば、愛のないコードが生まれ、一気に開発効率を落とす悲劇がいとも簡単に生まれてしまう。

だからこそ、1つのシステムで担当するエンジニアが少なくさせるのが重要だ。そうすれば、ソースコードに愛着のある割合が増え、結果的に開発速度が上がる。人月とか工数を計算したり、エンジニアの替えが利くようなマネジメントをしている人がいつまでたってもいいシステムが作れないのは言うまでもないだろう。

終わりに

あなたの書いたソースコードに愛着はあるか。

私の書いたソースコードには愛着がある。私がシステムの全てを知っているし、どこをどう修正しなければならないのか、機能修正や追加の時にどこを追加/削除しなければならないのかが全部わかる。そして何より私の書いたソースコードに根拠のない自信がある。常にコードを良くし続けているという自負があるからである。そんな状態だからこそ、愛着を持って開発することに幸せを感じている。 これをチームとしてキープできれば、最高のエンジニアチームが生まれ、劇的な開発効率の中でクールなサービスを保ち続けることができるかもしれない。

なぜ10人の中途半端なエンジニアより、1人の優秀なエンジニアなのか。本記事で少しでも理解いただけたら幸いだ。

上司と素直に話すことについて

ども、@kimihom です。

f:id:cevid_cpp:20171013224905p:plain

たいていの社会人には上司という存在がいるはずだ。そして何かしら上司の不満を抱えながら、我慢して働き飲みの場で愚痴をこぼすといった姿が日本の社会として見受けられる。本記事では上司に言いづらいことに対して実際に私がやったことと思っていることについて記してみる。

上司と素直に話すべき理由

私が社会人になりたての頃は、正直に言ってかなりの自信家だったのかもしれない。

当時の私は、相手がどんな上司だとしても自分が正しくないと思ったことは理由と共に全て口にしていた。相手にどんなにめんどくさい存在だと思われようとも、自分が我慢し続けるというのは耐えられないと思っていたからだ。理由を口にすることで、相手はどう思っているのかを知って落ち着くこともあったし、徹底的に話し合ったこともあった。つまり、相手からしたら"めんどくさい部下"って思われていたことだろう。

ぶっちゃけそれでクビになったところで、全く問題ないと思っていた。クビになったら他でいくらでも就職できる自信はあった。だからこそなんでもできたってのもあるかもしれない。私が入社して以降、同じように何でも意見を言う尖った新人はそのあと出てこなかったことを考えると、やはり特殊なパターンだったように思う。

実際に上司に思うことを素直に言ったところ、かなりの割合で共感してくれる仲間がいた。「お前の意見に俺は賛成だから、どんどん言え」みたいな感じで励ましてくれる人がいた。そして共感してくれる人たちと結束しながら、組織をより良いものに自分から変えていこうとした。組織が大きければ大きいほど、単なる新入社員の意見なんて無視されがちだけど、それでも何も言わずに我慢するよりかは言って納得する結果を得たほうがよっぽど良いのだ信じていた。

だから私は飲み会とかで愚痴をこぼさないで、逆にどうしたら良くなるのかを考えて行動に移していた。これが本来あるべき組織としての正しい行動だと思っている。行動してみて変わらなければ、その組織はそういう体質だと諦めて、とっとと辞めたほうが自分のためでもあるしその組織のためでもある。悔しい思いをしたのなら、それを見返すくらいの成果を他の場所で上げればいいだけなのだ。

めんどくさい部下こそ将来性を感じる

私が塾講師をしていた頃、何でも質問をしてくる生徒がいた。説明をしていると、"なんで?" と事あるごとに聞いてきた。実際は本人がその "なんで?" を突き詰めるべきだとは思うが、塾講師という立場上、私はそれにできるだけ応えようと質問に答え続けた。塾講師からすれば彼はめんどくさい生徒だろう。わざわざ説明していたらキリがないので答えることを諦めたりすることもあるだろう。でもそういう"問題を突き詰められる"人ってのは、何においても考えられる術を持っているように感じる。

組織においても同じことだ。何かしらの違和感を感じた時に、相手が誰であろうと "なんで?" と疑問を投げかけられる人物。そして自分が正しくないと思ったら、正しいと思うことを実際に行動に移すことのできる人物だ。

その人の違和感がずっと続けば、結果として組織に合わなかったということは否応にして出てくる。しかし、その人の考えと組織の考えが一致した時、その人は半端ない力を発揮するポテンシャルを秘めていると思う。何かに我慢し続けているだけでは自分の力を100%出し切ることは到底不可能だからだ。

上司のいない世界

私は現在、上司のいない職場にいる。働く人たち全てが対等な、そんな仕事場だ。1人1人の発言全てが対等で、対等に評価される。自分が正しいと思うことは正直に言えるし、相手も自分の発言が正しくないと思えばそれを言ってくれる。

そして私は思う。そもそも上下関係こそが諸悪の根源なのではないか? その人たちの能力や経験で評価が変わることはあったとしても、話すときは常に対等な組織体系が理想なのではないか?誰もが問題を突き詰められるようになれば、自然と課題の根本解決を実現してより強力な組織になっていくのではないか。これは単に当事者意識とも言い換えられるだろう。

終わりに

自分が正しくないと思ったら、それを我慢せずに素直に言ってみよう。そしたら同じことを思っていた仲間が協力してくれるし、正しい方向へ進んでいくかもしれない。上下関係がそれを邪魔しているのなら、そんなのは取っ払ってしまって、正々堂々と言えるような環境づくりが必要だ。上下関係を気にせずに何でも意見を言えるような人材を大切にして、育てていけるような文化こそが組織を強くするだろう。

もちろん採用の時点から気をつけるべきことではあるけども、それ以外のちょっとした細かい部分で摩擦が大きくならないようにするためにも、今いる社員がなんでも言えるような組織を目指していくことは、とても大事なことであるはずだ。

ContentEditable のハマりどころと対処法

ども、@kimihom です。

f:id:cevid_cpp:20171008154936p:plain

前回の記事で、ContentEditable についての概要をざっと書いた。ContentEditable の持つ魔力については以下の記事を参照いただきたい。

www.bokukoko.info

さて、本記事では実際に ContentEditable を使って実装しようと思った際に気をつけておいたほうがいい点をざっと挙げていく。もし今後 ContentEditable を使った実装をする方の参考になれば幸いだ。

タグ挿入後の罠

ContentEditable を使うなら、何らかのテキスト入力でリアルタイムに HTML タグの挿入をする(document.execCommand('insertHTML'))といった実装をしていくことになるだろう。 実際上記コマンドを実行するだけなら問題なく動作するが、問題はその後にやってくる。例えば <span> タグを動的に挿入した後、その直後に日本語入力をしようとすると、数文字打った後で変換カーソルから外れるという謎バグが発生する(Chrome version 61)。また、ContentEditable 内の<span>タグのの後に何も文字入力がない状態だと、キャレット( | 点滅の文字入力カーソル)が ContentEditable 外に飛ぶというバグも発生した。

ContentEditable の実装で例に挙げた Twitter のタイムラインの ContentEditable は、タグを入力するたびに ContentEditable 内を全てを書き換えるという何とも大胆な実装を施している。 Twitter の投稿文字が140字までという制約があるからこそ成せる芸当だ。実際、Twitter のテキストエリアにタグを100個以上挿入すると、Twitter テキストエリアの動作が極端に重くなる。

本問題に対し、私は<span>タグで何かを入れた後には必ず半角スペースを入れるという実装で対応した。つまりは keydown イベントで全ての対象 <span>タグを走査し、タグ直後にスペースがなければ document.execCommand('insertText', false, " "); を実行している。意図しないスペースが入るということでユーザーにはあまりそのことを気づかないような UX にすることに苦労した。他の方法で対応できた方がいれば是非教えていただきたい!

keydown と keyup の罠

Twitter のように # 入力でタグの候補が出てくるような何かを実装したい場合、keyup でイベント補足をしたいと思うことだろう。そうすれば、#を入力した後のイベントとしてコードを書くことができるので、動的な HTML の書き換えが楽に対応できるためである。

しかし、keyup イベントで # の入力を保障しようとすると問題が発生する。なぜか keyup では #を素早く入力した場合に keyup# の入力を取ってこれないことがあるのだ! この致命的な問題に対応するには、 keydown の時点で # 入力を補足するようにするしかない。この問題により、keyup 時点での実装とは異なった実装の工夫が必要になってしまった。

このように、keydown と keyup, keypress などのイベントの違いを理解した上で、適切な実装が必要になってくる。当然素早いキー入力や記号の入力など、実際に入力されるであろう文字列を全て考慮した上で実装しなければならない。

キャレットの罠

テキストエリア入力なら当然のようにあるキャレット (| で現在のフォーカスを示すやつ) だが、ContentEditable で最も苦戦する機能実装の1つといっても過言ではないだろう。

例えば Twitter のタグ # 入力後に 選択肢が出てきて、そのうちの1つを選択した後にはタグを確定して入力カーソルをそのタグの外から始めるという実装にしたいという場合を考えてみる。この場合、キャレットは新規で作ったタグ外側に合わせるという実装をすることになる。

そこで Range ってのを使うことになる。例えば以下のようなコードだ。

      var range = document.createRange();
      range.setStartAfter(tag);
      var sel = window.getSelection();
      sel.removeAllRanges();
      sel.addRange(range);

この Range は、キャレットを調整するための色々なメソッドを用意しているので試行錯誤しながら調整をしていくことになるだろう。ここら辺の実装をしている時の、ContentEditable でドツボにハマっている感はなかなかエキサイティングなのでぜひ楽しんでいただければ幸いだ。この Range の動作を工夫することで、違和感のない心地よい UX を ContentEditable で実現できる。

ContentEditable 内の子タグで keydown等のイベントを補足できない

色々と ContentEditable の実装を試行錯誤していると、例えば ContentEditable 内の特定の <span> タグでのみ keyup イベントを補足したい みたいなアイディアが浮かんでくる。残念ながらこの方法は実質不可能である。(ContentEditable 内に ContentEditable=false タグを入れてさらにその中にある ContentEditable=true の要素の keyup イベントは取れるが、実装の解として適切ではない)

そのため、ContentEditable 自体の keyupkeydown イベントだけを使って、キー入力を最適化していくことになる。その事実を知った時の絶望感は半端なかった。子タグ内でイベント捕捉できたら実装がどんなに楽になっていたことか。つまり、やるなら Twitter のように、ContentEditable 内の対象タグを毎回チェックして実行する というようなコードを書くことになるだろう。この実装をするのには躊躇したが、検討した結果この方法しかなかった。本件に関しても、他に方法があれば是非教えていただきたい。

そして最後の砦、 IME

英語だったらこんな問題が起きないのだけど、日本語入力の場合は変換という作業がある。ご想像の通り、keydown 等のイベントは、日本語入力時にも全て取ってきてしまう。ここで何が問題になるのかというと、Enter の挙動だ。

日本語入力時の確定Enter では何も起こさず、その後の確定 Enter の際にのみ実行したいといったことが出てくる。全ブラウザでこの挙動に対応するには、結構面倒な手続きが必要だ。これはもう日本語を扱う我々にとって宿命だと思ってやるしかない。以下のリンクを参考にしていただきたい。jQuery じゃなくても参考になる。

jQueryでIME入力確定時にイベントを発行する - Qiita

当然、IME 以外にもクロスブラウザの問題は当然のように出てくる。ブラウザごとのバージョンアップなども追従する必要があるので、この実装がどんなに大変かは簡単にご想像できることだろう。

終わりに

今回は私が遭遇した ContentEditable の実装の一部だけではあるがご紹介した。

前回の記事でも書いたが、改めて ContentEditable を利用する際には、本当に今やりたい実装は ContentEditable が必要か? を考え直してみることをオススメする。以前、私はこんなツイートをしていた。

実際にContentEditable を実装してみて、Markdown の手軽さを痛感した次第である。

本当に ContentEditable が必要なタイミングで、この苦難を乗り越えた先に、最高の UX を提供できるサービスを実現できるはずだ。

SaaS にカスタマイズは悪なのか?

ども、@kimihom です。

SaaS(Software as a Service) 界隈でよく言われるカスタマイズの是非について。

顧客ごとに最適なアプリケーションを用意(カスタマイズ)してしまうと、そのための改修や運用コストなどで今後のサービス改善に支障をきたすなどの理由でカスタマイズは悪とされている。本記事ではこのカスタマイズに関する持論を記そうと思う。

カスタマイズのジレンマ

「カスタマイズは一切しないで小規模向けのみでサービスをずっと運用し続ける」って意見なら、カスタマイズは一切しないという方針で良いと思う。しかし、ほとんどの SaaS スタートアップの場合、実際に資金調達を受けて顧客を大規模事業向けにまで増やしていかなければならない。顧客の組織が大きくなればなるほど、このカスタマイズが必要なケースはどんどん増えていく。そこでカスタマイズを一切受けなかったスタートアップは、大規模事業の顧客の要望を叶えるべきか否かの岐路に立たされる。

カスタマイズをしなければ、大企業などの顧客にドンピシャに刺さるサービスを作ることはできない。しかし、カスタマイズをしてしまうと、そのための顧客のために時間を取られる。この両者のトレードオフに SaaS は常に立たされている。

じゃあ どうにかして対応することができないか。ここは先人の知恵を借りることが大事であろう。

開発者をも味方につけたセールスフォース

SaaS の王者といえば セールスフォースだろう。そのサービスを使ったことがなくても名前くらいは知っている方も多いはずだ。基本的には他でもよくある "CRM" のサービスを提供する同社が、なぜここまで大成功と言えるレベルにまで達したか。

それは先ほど挙げた、カスタマイズのジレンマを見事にクリアしているからだと考える。

セールスフォースは、カスタマイズを一切受けない代わりに第三者の開発者が自由に開発/拡張できる SaaS プラットフォームを提供したのである。開発者はセールスフォースの提供する API や独自プログラミング言語 Apex などを利用することで、あらゆる形態のアプリケーションを、開発者が自由に拡張して特定の顧客のための最適なシステムとして構築できる。 これによって、あらゆる業種業態の企業に最適なアプリケーションをセールスフォース内で統合できるようになった。

セールスフォース側では、相変わらずサービスのコアの部分(つまりCRM)に集中することができる。第三者の開発者がどんどん増えていけば、あらゆる顧客にとって最適なアプリケーションがバンバン出てくる。しかも第三者の開発者はセールスフォース"アプリ"として世界中に公開することのできるプラットフォーム(AppExchange) まで用意している。顧客は、欲しいアプリがあればダウンロードして一瞬で自社に最適な形でサービスを利用することができてしまう。開発者側が自社のセールスフォースアプリを利用してもらうためにセールスフォースを使うよう案内してもらうような広告の仕組みも実現できてしまう。

当然、その SaaS プラットフォーム自体に多くの顧客や成功事例がないと、開発者は波に乗ってこようとはしない。ここが難しいところなんだけども、カスタマイズを受けないで顧客にカスタマイズを提供する という技を実現するにはこの方法しかないだろう。

全ての SaaS は連携の基礎となる API の提供を検討すべき

この記事で私が言いたいのはこれ。今の日本の SaaS は API を提供しなさすぎだということ。自社で顧客の要望を全て完結させようなどという考え方はとっくに捨てるべきで、他の特徴のある SaaS と連携をしていくことで、顧客ごとに最適なシステムを選んで構築できるようにしなければならない。これがわからない方は、チャットツールに過ぎない Slack がなぜあんなにも大成功したのかも改めて考え直すべきだろう。

「カスタマイズを一切受けない」でサービスをより成長させたいと思うスタートアップなら真っ先に API を公開すべきだ。そうでなければ、全ての顧客がサービスの提供する基礎機能のみしか利用することができない。これでは大きな組織に最適なアプリケーションはいつまでたっても出来上がらないし、他に最適で柔軟なサービスが出てきたら、他社サービスに移ることだってあり得る話だろう。

SaaS API のエコシステムが成り立ち、顧客はどんなサービスとも連携できて自社に最適なシステムを選んで構築することができる。そんな自由な選択こそが、すぐに最適なシステムを利用できるという SaaS の良さを更に引き出すことだろう。

もし読者が SaaS を選ぶ(利用する)側に立ったときには、そのサービスが、API を積極的に公開しているか というのを注目してみよう。API が公開されていなかったり、クローズドな API しかないようなサービスは、今後のサービスの拡張性を全く考えず、自社で全てをまかなおうとしている、旧来の考え方のサービスであると判断できるだろう。

終わりに

本記事では SaaS をカスタマイズすること自体は悪ではないということと、カスタマイズのためには外部の開発者を巻き込み、自社の API を積極的に利用していただくような仕組みの構築が必要だと説いた。

今後はサービスごとの密な連携こそが、 SaaS の運命を左右しかねない。てことで、開発者の皆さん頑張って API を公開していこう。

きみにしかできないことなんだろ、これは!

ども、@kimihom です。

夏も終わりっすね。そこで夏の終わりのサマーウォーズってことで、その映画の中に私の好きな言葉がある。それが、主人公のけんじ君が最後に一生懸命数学の問題を解いている時に、励ましてくれる医者のおじさんが発する言葉だ。最終的にけんじ君は目の色を変えて超人的とも言われる問題解決能力を発揮して、世界を救うことになる。

きみにしかできないことなんだろ、これは!

仕事で言われたら、きっと誰だって全力で取り組むだろう。他の誰でもない、自分自身が絶対にやり遂げる。自分がやり遂げられなければ、他の誰もがやり遂げることのできない仕事。私はそんな仕事を増やしていきたいし、これからもやっていきたい。

それは当然、仕事では正しくない働き方だと言われる側面もある。"属人性の排除" である。今回はそのことに関して私の思うことをつらつらと記していく。

マネージャーの視点とプレイヤーの視点

人を管理するマネージャーの立場であれば、"きみにしかできないこと"を抱えてしまうようでは、リスク分散ができないとして考えられることだろう。人が一時的でも恒久的でもいなくなってしまった時に、迅速に復旧対応できるようにするための管理能力が求められる。そして何より管理する側としては"きみにしかできないこと"ってのを多数抱えるのは不安を抱えることだろう。だからこそ、"きみにしかできないこと"をできるだけ排除し、誰にでもできるような仕事のフローに変えていく必要がある。そんな考え方が一般的になっているように感じる。

しかし、私は部下を徹底的に信じ抜くマネージャーこそ、本当の管理者だと考える。(きっとあいつなら必ずやり遂げてくれる。私はあいつに賭ける)。 そのくらいの意志で部下に仕事を任せられる上司ってのは私の理想だ。それくらい部下が全力で思いっきり打ち込むことのできる環境を提供できなければ、部下の持つ力のほとんどを出し切ることはできない。私はそう考えている。

プレイヤー側からすれば、やる気があれば完全に任せられた方が責任感を持てる。それこそが俗に言う仕事のやりがいなんじゃないかな。言われたまんま、何も考えずに仕事を淡々とやりたいみたいな人もいるにはいるだろうけど、そんな人と働いて何が楽しいのか私にはわからないし、マニュアル通りにこなす仕事が顧客に正しい価値を与えられるか甚だ疑問である。確かにマニュアル通りの仕事は一定のクオリティを顧客に提供できるかもしれない。しかし、顧客ごとに趣味格好が違う中で、これだけやれば正解みたいなことはきっとないはずだ。

きみにしかできないことは、自分で見つけよう

誰かから言われてやる仕事自体、"きみにしかできないこと"ではない。そんなことは他の誰でも言われればやる気次第でやるからだ。自分の心から湧き出てくる、挑戦したいという気持ち。これはその人の勘違い的な側面も持ってるので、とにかく正しいものに対して信じ込んでやってみるってのが大事なことのように思う。そうして毎日一歩ずつでも勘違いという名の信念を持って成長していけば、いつかきっと"きみにしかできないこと"のレベルにまで到達できることだろう。

自分の意思で起こす行動ほど強いものはない。ふと思った時にすぐに行動に移せるようにすることで、言われてからじゃないと行動しない人の何倍もの差をつけることができる。やがてその行為が習慣となって体に染み付いていくのだ。

次第に誰でもできるような仕事をやるのではなく、"きみにしかできない" 仕事を任されるようになれば、仕事のポジションとしても非常に重要な立場の仕事を任せられるようになる。そういった仕事は本当に楽しいし、けんじ君のように目の色を変えて仕事のできる環境が与えられることを意味する。 そんな仕事をやることにこそ、仕事の楽しさってのが生まれるのではないかと考えている。

終わりに

私は今でもプレーヤー側の最前線で仕事をしているという自負がある。だからこそ自分にしかできないことを追っていきたいし、自分だけでなく周りからもそう評価されるくらいになりたいと考えている。

これは別にスキルを持つことだけじゃなくても良いと思っていて、その人にしか圧倒的な情熱を持てない事業にチャレンジしたり、その人にしかできない価値を創造するってことに意味があるはずだ。

きみにしかできないことなんだろ、これは!

最後にこの言葉を読者へ捧げつつ、本記事を締めくくろうと思う。

拡張テキストエリアを ContentEditable で実現しよう

ども、@kimihom です。

今回は ContentEditable という知る人ぞ知る HTML5 で導入された HTML 属性についてご紹介する。

まず始めに、 大いなる力には大いなる責任が伴うということを伝えておこう。ContentEditable を本気でやろうとすると確実にどハマりし、長い開発期間を要することになる。そして本当にイメージする機能を実現できるかの保証はできない。しかし、その険しい道の行く末に、誰も経験したことのないような、拡張テキストエリアの UX を実現することができる!

ContentEditable で実装できること

まず ContentEditable の簡単な概要をご紹介する。最も一般的に ContentEditable が利用されているのは、おそらく Twitter だろう。公式 Web サイト上のテキストエリアに # の文字を入力してタグ付けをしてみよう。

f:id:cevid_cpp:20171002184710p:plain

ご覧の通り、テキストエリアなのにまず色付けが行われている。そもそも普通の <textarea> ではこれすらも実現不可能だ。また、 # を押した後にはタグの候補が表示されたり、対象のメンションをマウスオーバーするとユーザー情報が表示されたりする。

マークダウンとはなんだったのか。そんなふうに思ってしまうような拡張テキストエリアを、ContentEditable なら実現できるのである。

そして、ContentEditable の原理としては至ってシンプルだ。

<div contentEditable='true'></div>

なんとこれだけで編集可能なテキストエリアを実現できる。Twitter のテキストエリアの部分のHTMLソースを見てもらえばわかる通り、<textarea>ですらないのがポイントだ。CSS や JavaScript を駆使して、 Twitter のツイートエリアのような拡張テキストエリアを作り上げるのである。

ContentEditable を始めてみる

ContentEditable にワクワクした読者の皆様、ようこそ茨の道へ。これの実現には本当にたくさんの罠をくぐり抜ける必要がある。

そもそも、ContentEditable は よくあるブログの編集画面のような、ツールボタンをクリックして文字を太字にしたり色付けしたり画像を挿入したりといった使われ方を想定した設計になっている。これであれば、ContentEditable は容易に実現できる。

f:id:cevid_cpp:20171002185433p:plain

具体的には、 document.execCommand を呼び出すことで書式変更をする。つまり、書式変更ボタンをクリックしたら、document.execCommand('bold') といったようなコマンドを実行するだけで、書式変更のかかった文字を ContentEditable 内で入力させることができるようになる。

しかし、今回私たちが最終的に実現したいのは、Twitter のようなリアルタイムで変わるクールなインタフェースだ。これの実現は半端なく難しいので、チャレンジできる人だけ来て欲しい。

まず、 Twitter ライクな実装を実現するためには、個々のキー入力イベント "keydown" , "keyup" を補足し、その文字によって対応する処理を変えていく必要がある。「"スペース+@"の文字が入力されたら、候補となるユーザー一覧をテキストエリア下部にリスト表示する」 といった実装となる。ご想像の通り、あらゆる文字入力が考えられる中で、その全てのキー入力に対応して違和感を起こさないような実装が必要となってくる。単なる文字だけでなく、Enter, Space, 上下左右、Shift, Control とった文字まで、keydown, keyup イベントは全てを補足するので細かな実装とテストが必要だ。 一応記しておくと、keydownは文字入力される前に呼ばれるイベントで、keyup は文字入力された後に呼ばれるイベントだ。ContentEditable ではこのイベントの使い分けも非常に重要になる。

最終的に生成される文字列は、当然 HTML だ。改行なども<div>タグで表現されたり、書式は <span> で登録されたりする。そのためちゃんとしたテキストとしてデータベースに保存したいのなら、そのHTMLを解析して最終的に整形した文字列を保存しなければならない。そのまま保存して表示みたいなことをすれば、簡単にXSSの脆弱性を生み出してしまうことだろう。

また、キー入力イベントのハンドリングだけではなく、ContentEditable 内のカーソル移動も検討する余地がある。例えば自動入力でテキストエリアに文字を挿入した場合、カーソルはそのテキストエリアの前や後ろに持っていきたいなど、機能の特性によってカーソル位置を変えたいことが出てくる。そこで登場するのが、Range という概念。これも ContentEditable の実装をすると確実に必要になって来るのでドキュメントを見て学んでいただきたい。また、ExecCommand の一部が正しく動作しないとか普通に起こるので、替わりに Range を使って代用する方法など、数多くの地雷が待ち受けていることだろう。

やがてあらゆるハードルを乗り越えれば、リアルタイムに編集しながら自由に HTML を作り上げることができるという夢のような機能を実現できる。

そこまで苦労して ContentEditable を実現したいか。この点に関してはきっとサービス特性によって異なることだろう。

終わりに

私は ContentEditable の持つ魔の力を利用して、拡張テキストエリアを実現することができた。Twitter のタグを見ればわかる通り、普通ならタグ入力の別の検索ボックスのようなものを用意しなければならなかったのが、1つのテキストエリアで全てが表現できるようになった。ContentEditable はそこに価値を感じるか感じないかの世界だ。シンプルで柔軟性のあるサービスを本気で目指しているのなら、ContentEditable の実装を検討してみてはいかがだろうか。

大いなる力には大いなる責任が伴う。ContentEditable で拡張テキストエリアを実現するかしないかを検討してみていただきたい。