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

ボクココ

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

新技術とどう向き合うかについて

エンジニア

ども、@kimihom です。

テクノロジーの進化は速く、追いついていくのは大変だ。全部を完璧に吸収するってのは理想ではあるが、当然のことながら一人では限界がある。私たちはどう新技術と向き合えば良いのだろうか?

今回は私の思う技術を見極める方法について書いていこう。 ちなみに私はどちらかと言うと新しくサービスを作る側のエンジニアであり、何かに特化するスペシャリスト側のエンジニアではない。その目線からの話である。

その技術は本質的に “新しいか”

私は何か技術が生まれた時に、"その技術は本質的に新しいか" を見極めるようにしている。よくある新技術として、以下のような例があるだろう。

  • 新しい技術分野
  • 新しい仕様
  • 新しいプログラミング言語
  • 新しいフレームワーク
  • 新しいミドルウェア
  • 新しいインフラストラクチャ
  • 新しい設計思想

さて、同じタイミングでガッと色々と出てきた時、何を選ぶだろうか。

もちろん興味の度合いなどあるだろうけど、私は常に顧客目線を大事にするようにしている。新しく出てきた技術が、本質的に顧客体験を変えることができるのかという視点である。"今までできなかったことが、その技術でできるようになるのか"、とも言い換えられる。

例えば新しい言語やフレームワークってのは、得てして今までもできたけど純粋にちょっと速くなったり、ちょっと使いやすくなったりする程度の話が多い。その言語しかできないことってのは案外少ないものだ。フレームワークも同様だ。そのフレームワークの登場で、今までできなかったことができるようになるのか。その答えに対し明確に Yes と答えられるフレームワークと出会えることはほとんどない。 これまで色々な技術が出てきたけど、個人的には Rails, jQuery, Heroku (Postgres, Redis) 以上に素早く正確に新しいもの開発できる技術はないと思っている(私が単に得意ってのもあるし、私の判断なので人それぞれのはず。好みの技術で書き換えて欲しい)。新しいフレームワークをざっと見てみても、上記テクノロジー以外で新しくできるようになることってのが見つからない。だから新しいものに対して事前に調査はするけども、磨いていくってことはしていない。もっと他に学ぶべきものがあるはずだと考えるようにしている。

じゃあ例えばどんな技術に注目すべきかって話になるけど、例えば HTML5 の主要技術 はこれから一般的に普及するものであり、今までできなかったことができるようになるという点で注目すべき技術だ。また、新しく登場した各種 API も今まで難しかったことが簡単に実現できるようになったって意味で貴重だし、もっと大枠で言えばスマホアプリ開発技術も当てはまる。何かしらのプログラミング言語で作られたミドルウェアが今までできなかったことができるようになるレベルのものだった場合、その新しい言語を学ぶ価値があるかもしれない。そのような判断基準だ。

この基準でテクノロジーを見渡すと、学ばなければならないものがはっきりする。一部で話題になっている技術に飛びつくようなことをしなくなる。人と比較しないってのは大事なことだ。自分が目指す理想のサービスやシステムを実現することだけを考える。私にとってテクノロジーは自分の理想を実現する上で必要なものだけを取り入れる。それだけの話だ。

それでも終わらない技術への探求

ここまでの話は、あくまで学ぶものを選ぶことによって自らがすべきことを明確にするってだけの話。つまり、私たちは常に学び続け成長しなければならないことには変わりない。当初は甘くみていた新技術がいつのまにか革新的な開発効率を生むようなものになっている可能性だってあるし、そもそも新らしく出てきた技術にアンテナを立てなければ今までできなかったことなのかどうかも判断できない。だから、そもそも学ばないとかアンテナを立てないとかってのは問題外の話である。

エンジニアにとって一番大切なのは探究心/好奇心だ。新しいものをまず見てみて、それが自分の方針に合いそうだったらしっかりとやる。

師匠/先生がこれをやれと言ってるからやっている?教科書に次はこれってあるからやっている?なんか流行ってるからやっている? このような周りに流されながらの学習方針は、エンジニアとしての成長を鈍くさせるだろう。もっとも大切なのは、繰り返しになるが、自らの好奇心だ。湧き出る好奇心から生まれた技術への探求が四六時中そのことを考えられるようになるための、ついては自らが成長し続けられるようになるための条件だ。

私の磨く技術は私が決める。それが結局一番自分の技術力を高められることだと信じている。

“いい師匠を持つことが大事だ"って意見をよく聞くが、本当にそうだろうか。確かに凄い人を見ればモチベーションは上がるけど、私はその人が言うからやるみたいなことはしたくない。その人から言われてやっていることをやり続けたところで、その人を超えることはいつまで経ってもできないのだ。

終わりに

新技術と向き合った時、それは一つのチャンスである。まだ誰もタッチしたことのない新しい領域だから、極めれば自らが第一人者になれることができるかもしれない。ただし、自分がそこまで没頭してでも磨きたい技術なのか。その磨いた先にある未来は見えるのか。そうした冷静な分析が、今後の学習を正しい方向へ誘ってくれるだろう。

共に次なる高みへ進んでいこうじゃあないか

テクノロジーが変える未来について思いを馳せる

書評

ども、@kimihom です。

今回はこんな本を読んでみたので感想をまとめてみる。

〈インターネット〉の次に来るもの―未来を決める12の法則

〈インターネット〉の次に来るもの―未来を決める12の法則

確実にやって来るであろう未来

ネットで流れて来るニュースを眺めていると、「新しいテクノロジー/ビジネスが登場!」というようなタイトルを目にすることが多いけども、ちょっと読んでもそれらの生まれた具体的な背景までを知ることはできない。とりわけインターネット業界に精通していない方であれば、最新のテクノロジーは何があって何を目指しているのかを理解することは難しいだろう。でも、新しいテクノロジーは LINE が一般家庭にまで普及したように、いつかどこの家庭にもやって来るものなのだ。

本書は最新の技術が進化して行った先に、どんな世界が待っているのかを “不可避なもの” として表現していた。

“不可避なもの” の傾向を、動詞としてまとめていた。その動詞を強引に名詞として挙げるならば、例えば AI / IoT / ビッグデータ / VR / ロボット / シェアリングエコノミー などがある。最近これらワードを聞くことは多いけど、"不可避なもの" が発展した 5年 10年先のことをあなたは考えたことがあるだろうか?

例えば、 AI が人間以上に賢くなった (シンギュラリティーを迎えた) とき、私たち人間の立場はどうなる? 眼鏡や時計、体内に埋め込まれたチップなど、あらゆるものがインターネットに繋がったときにどうなる? 人間の五感すべてをハックし、別世界へと飛び立てるようになったら?人間の脳を操作できるようになったら?….

こんなことが数十年で現実になってしまうのだ。私たちはその流れに抗うことはできても完全に止めることはできない。テクノロジーってのは進化を常に続けていくものだ。例えば一時的に法律で固めたとしても、人が決めた法律自体がなくなっていくのは時間の問題だ。今 Uber のようなサービスを止めようと一部の業界が躍起になっているけども、どこかの誰かがそれをこっそり始めて圧倒的なサポーターを味方にすれば法律だって変えられてしまう。そんな感じでインターネット自体も歴史の中であらゆる課題にぶち当たって今まで成長してきた。

現在一部の人がやっているだけの最新のテクノロジーは、3年もすれば一般に普及し、5年もすればそれをやらないほうがおかしいレベルにまで変わっていく。スマートフォンを例にとれば明らかなことで、このスピードは今後ますます速くなっていく。インターネットの与えるスピードの力でね。

私たちは確実にやって来る未来を受け入れる必要があるってことだ。

私たちはどう対処していくべきか

不可避な現実に対して私たちはどう対処していくべきなのだろうか。もちろん自分がその未来を作る側に入ることだってできるだろうけど、99% 以上の人はその未来の流れに乗っていく運命にあろう。

個人的に思うのは、"為せば成る" ということだ。かつて(今でも)あんだけインターネットが人に悪影響を滅ぼす的な批判を言われているけど、発展に発展を重ねた今、そう思っている人はどれだけいるだろう(ほとんどいない)。逆にインターネットで情報が透明化されて、より良い未来に近づいている。当然悪い方向も考えたらあるにはあるけど、生活レベルは確実に上がっている。なぜなら、今ある不便を解決するために私たちはインターネット上で考え働き続けているのだから。

ネガティブな未来を恐れる必要はない。そのようなネガティブな未来は、必ず未来の人がその解決策を掲示してくれる。そうやって市場は回っていくのだ。ネガティブなことがあれば、あなたがそれを解決して周りから感謝される存在になれるのだ。時代が進化してもどんどん仕事は生まれていく。

“ロボットが仕事を奪う” ってのは、今の仕事しかできることがない人が言うセリフであり、柔軟に時代のニーズを感じ取って自在に行動を変えられる人には全く問題にならない話ではないか。そう思った時、私は気楽になった。今の時代を生きる人間として、起きている課題を解決して顧客に正しいプロダクトを提供する。今も昔もこれの連続で人は生き続けてきたのだ。だから不可避な未来が来たとしても、柔軟に時代の流れを読み、人々の不便を解決する何かを提供すれば良いのである。"変化についていけない" と言うのは、マラソンにおいて自分の実力と割に合わないペースメーカーの後ろをついていく姿のようなものだ。しっかりと時代の流れと同じくして自分のペースで走り続ければ、変化についていけないってこともないだろう。

私としては時代に引っ張られる(流される)ような存在ではなく、常にリードし続ける存在でありたいと思う。そのためには当然たくさん勉強をしなければならないし、最新の動向を気にし続ける必要がある。大変だけども吸収し続ければテクノロジーの不可避な存在を、自分自身で操れるようになる。このような時代の変化を味方につけることが、今後さらに求められて来るのではないかと思っている。

取捨選択を誤るな

このような本を読むと、真っ先に最新技術に飛びつきたくなる気持ちが芽生える。しかし作ろうとしているモノが “今” まさに求められているのかどうかをよく考える必要がある。この点に関して私は慎重派だ。最新テクノロジーよりも、今の時代の顧客が求めているものがあるのではないか。Airbnb のような仕組みは 10年前に作れたけども今になってようやく普及してきたのは、インターネットの中で匿名ではなく実名個人が証明できるようになって責任が持てるようになったからだ。そのように、最新テクノロジーが普及するには何かしらの条件があったりするし、"今" の時代の顧客が本当に求めているのかはわからない。

だから私としては最新テクノロジーの動向に目をむけつつ、今の顧客が本当に求めていることは何かを見失うことはしないようにしたいと思う。 「これからは AI や! 」と言ってサービスをやみくもに AI 化しても意味がない。顧客が本当に AI を使ったソリューションを求めているとわかって初めて使っていかなくてはいけない。

本書を通じて新しい発見もあったし、自分の思いを再確認することもできた。

こうして私はまた明日から、目の前にあるサービス改善に精を出すのである。

クレジットカードと下請け構造

ども、@kimihom です。

SaaS サービスを運営していると、クレジットカード決済の処理を提供することが多い。んで基本的に支払いはクレジットカードのみとしているため、一部のお客様は「請求書払いにできませんか」という問い合わせを数回は経験することがある。日本企業の支払いの構造について学んだことをメモする。

f:id:cevid_cpp:20170225223852j:plain

企業における文化やプロセスの違いを理解する

今まで会社間の取引は基本的に「請求書」でのやりとりだった。企業が企業に対し、「〜円を請求します」という表を渡して、それを経理が確認し、支払先へ振り込む。そんなフローを経験したことのある人もいるかもしれない。私は社会人からずっとインターネット企業に勤めていたため、その文化を一切経験してこなかった。エンジニアとしては"会社のお金を使う"みたいなシチュエーションがほとんどなかったので意識してこなかったというのもある。

請求書ベースのやりとりによって、会社のキャッシュの IN/OUT を管理する人を配置することで、今後のキャッシュの見通しなどを分析できる部隊が"経理"という枠組みだと理解した。請求書払いをクレジットカード支払いにしてしまうと、経理を通さずに支払いってことになってしまうので、企業の持つ色々な承認フローや支払い方法を変えないといけなくなってしまう。だからクレジットカード払いっていう新しい支払い方法に対応したくないケースが多くあるとのことだった。

何より会社のカードを誰がいつそのカード番号をどこかに入力し、どこがいくら決済するのかが不透明になるってのは一抹の不安があるのかもしれない。

実はさらに大きなハードルがある。間にいる業者問題である。

今までの IT 製品って、間に営業代行会社がいて、彼らが色々な企業に IT 製品を売りに行くという方法が一般的なようだ。

それはそれで良いのだが、間の業者が入ると起きる問題として、"プロダクトの正規料金を IT 製品側で大きく載せてしまうと、その間の業者の取り分がなくなってしまう" という点がある。だから大きなエンタープライズ向け製品であればあるほど、提供元のサイトでは料金を載せない方針をとっているか、わざと料金を高めにセットして、間の業者経由だと安くなりますよといった方法で販売しているケースがあるとのことだ。

このようなケースの場合、請求書払いにすればその料金を間の業者が自由に発行できるため、色々と都合がいいのだ。料金は営業代理店的なところが自由に発行して管理することで、儲けを生み出すことができる構造だ。このような販売方法が確立された世界においては、サービス提供元と利用者が直接取引されると儲けがなくなってしまうのである。こういう話って、スタートアップ界隈にいると割と衝撃的な話に聞こえる。今やどんなクラウドサービスだって自社サービス経由で販売し、堂々と正規料金を載っけている。

このような方法で大きな利益を上げている企業もいるってのは理解しておくと良いだろう。


さて、上記ケースを踏まえた上で SaaS プロバイダである私たちが対応しなければならないことは何だろうか。

必ず領収書を発行するようにする

“この日にこの金額を支払っていただいたよ” と証明する資料を用意してあげることで、ほとんどの企業で対応が可能になる。そのため、サービス内で領収書を発行できるページを用意し、PDF でダウンロードできるようにしておこう。そうすれば社内の人が PDF をそのまま経理に渡せば良いこととなる。請求書などは発行できないけども、割と領収書だけで何とかしてくれるケースが多い。

それでも、「支払いの承認が~ 」とかって話で請求書も必要みたいな会社もいるだろう。そのような企業がよく SaaS を使おうと思ってくれたな、と逆に感心するが、そのような場合だけ特別に対応するようにはしている。ただ、そんな企業が増えていけば自ずと請求書もダウンロードできるような仕組みが必要になるのかもしれない。

これはサービスを使っていただく企業がどんな特性が多いか(レガシーな企業が多いか、スタートアップが多いか等)を検討した上で、どうすべきかを考えるべきだろう。大抵、領収書の PDF をダウンロードできるようにするだけで良さそうな感覚は持っている。

サービス提供者側から"発信"する

知らない営業から勧められたサービスを使うってのではなく、自分で調べて人は評判をもとに SaaS サービスを使い始めるって流れになりつつある。そのような状況で大事なのは、SaaS サービス提供者側から、正しい情報を発信するってことだと思う。積極的な情報開示によって企業はその会社を信頼してくれるし、使ってみたいと思ってくれることだろう。

これを怠った状態で Web ページを載せるだけ。そんな方法で顧客はどうやってサービスを使うという判断をしなければならないのか。顧客がそのサービスのページを覗いて「色々あってわからない」という判断をされれば、それはよく知っている誰かに相談して、その人のおすすめに従うようになるだろう。"よく知っている誰か"は紹介フィーをもらうためにその企業と交渉するようになるので、結局 先ほどの営業代理店的な話になって行ってしまうのである。

営業代理店がサービス提供元以上にサービスを理解し、正しい顧客に販売することなどできるのだろうか。彼らにとってはただ売上が上がれば良い認識であることが多い(反論もあるだろうが、そう思っている人は必ずいる)。それで運用保守はサービス提供者側任せなので、なりふり構わず売れそうな商品を売り抜くことをするだろう。それで間違った顧客を獲得して大変なサポートをしなければならないのはサービス提供者側の方だ。今やインターネットを通じていい商品はユーザーが勝手に調べて勝手に使い始めてくれる時代になった。大事なのは"評判"である。評判をあげる努力をサービス提供者側がやっていけば、営業はそもそも必要ないのだ!この SaaS としてのトレンドは今後ますます顕著になっていくと思われる。

顧客が正しいサービスを選択でき、サービス提供者側と顧客の両者が幸せになるには、顧客のサービスに対する正しい理解が必須なのである。

クレジットカード支払いの時代になるのは不可避

今後はクレジットカード支払いがますます一般的になることだろう。特にクラウドサービスを使うってなればなおさらだ。 あの有名な AWS もクレジットカードを登録しなければ利用できない。その中で導入企業を見てみると、とんでもない大企業の事例がある。つまり、どんな大きな企業でもクレジットカードを発行しているのだ。企業が諸事情でクレジットカードを発行しないなんてことは今後なくなって来るし、カードを持たない体制では時代に取り残されるような時代がやって来るだろう。

だから、SaaS サービスでクレジットカード払いのみにする方法を恐れる必要はない。その企業が今はクレジットカード払いがダメだという判断になっても、近い将来にクレジットカード払いが使えるようになる日が来る。その日が来るまで待つのだ。目先のちょっとした利益のために、余計な仕事を増やしてはならない。

終わりに

私自身、社会のお金の動きの構造などを理解してなかった面があるので、今回はその分野に詳しい方からお話を聞いた情報をもとに書いた記事である。

今後、IT エンタープライズの時代から、クラウド SaaS になっていくにつれ、人々の IT との関わり方が変わっていくかもしれない。私たちはそんな時代の変化の真っ最中にいるのである。

SaaS ビジネスの日本輸入に備える

スタートアップ

ども、@kimihom です。

私自身、 SaaS サービスを開発運営しているのだけども、その中で最近感じている海外勢が日本にやってくることについて考える。

US スタートアップの世界展開

一般的には何らかの海外展開となれば、しっかりと現地調査して、その国での取引先などを構えて、諸々調整を経てようやく始められるようなものだ。しかし、インターネットの世界ではそんなことは必要ない。 誰もが URL を叩けば世界中のどこにでもあるサーバーにアクセスできるし、今や国際化のための翻訳だってそこまでハードルの高い作業ではない状態にある。だから、海外でうまく成功したサービスは、これからもどんどん世界向けに展開し、世界中で使われるようなサービスを目指していくことだろう。

事実、既に SaaS ビジネスで日本に来ている US スタートアップ発の SaaS サービスは多くある。 Slack, Zendesk, Intercom, SurveyMonkey など・・。これらは URL さえ定まっていれば、どこからでもアクセスできるわけだから世界展開が楽だ。英語だとしても使うような人ってのはたくさんいるし、翻訳自体もそれほどコストにはならない。

こうしたテクノロジーの中心は、アメリカにある。優秀なエンジニアは皆アメリカへ行くのだ(最近はちょっとトレンドが変わってるみたいだけど、間違いなく日本ではない)。いいプロダクトってのはそうした優秀な人がいるチームから生まれるものである。日本で優秀な人が集まったところで、世界中から優秀な人が集まったチームに敵うことは難しい。

日本のスタートアップの生きる道

ここでの話は、スタートアップってことで、最終的にイグジットまで狙うような爆発的に成功するサービスにするために必要なことを考える。

先ほどのように、US のスタートアップがどんどん日本にやってくるもんだから、例えば今から Zendesk みたいなメール対応システムを作ったり、 Intercom のようなチャットサポートシステムを作ったとしても、必ず 海外プロダクトと比較される運命にある。基本的に世界中で要件が変わらなかったりするサービス仕様の場合は、日本生まれか海外生まれかは関係なく、純粋に安くて性能のいいものが選ばれる。サポートも海外サービスが日本法人を立てて受ければ、日本で作って運営しているのと大差ないクオリティを提供できてしまうのだ。こうして世界中で弱肉強食な世界が生まれるのである。

だとしたら、日本人がスタートアップで一発成功する方法はないのだろうか。これは、あなたがどの程度成功したいかによって変わってくると思う。

日本でたくさんの人に使われるサービスにしたいってなら、日本人の問題に特化したサービスを作れば良い。日本で独自に作られたシステムや法律向けの SaaS を作れば良いのだ。そうすれば海外で作られたプロダクトってのは間違いなく日本には合わないので、顧客はあなたの作ったサービスを選ぶことだろう。競合が一気に減るため、あなたのサービスがその分野では世界一だと言えるレベルにまで持って行くことが可能である。正直日本で SaaS スタートアップをやるならこの方法が一番確実だと思う。

世界共通の課題を解決するような SaaS サービスを作りたいって場合でも、最初は海外製の似た競合サービスと比較して日本だからこそのメリットを提供すると良いだろう。海外プロダクトと差別化できるのは、当然ながら"機能" である。例えば国産 Web サービスと外部連携できるようにするとかはメリットが大きい。海外だと日本プロダクトとの連携機能などはまず実装できないので、早めにそのサービスならではの機能やサポートを実装したいところだ。ただし、やってることとしては日本に最適化するってことをしているにすぎない。

本当に今後世界を圧巻するサービスを目指すってなら海外勢のサービスと真っ向勝負するしかない。でもそういうサービスを日本で作るメリットをあまり感じないので、それをやりたければ早めにアメリカに行って莫大な資金得てガッとやったほうがいい気もする。

“今は” 世界にいる競合が日本展開していないからチャンス!という領域もあるにはある。ただし、今後ほぼ間違いなく世界にいる競合は日本にもやってくる。その時に比較された時に互角以上のものを提供できるようにならなければ、そのあとの成長は難しい。

以上で共通して言えるのは、"他でも作れるようなよくある機能" を開発するのではなく、 “そのサービスでないと実現できないもの” っていうコア技術を開発して行くことが、市場で絶対的な存在になれる数少ない方法になるだろう。

今後のサービス開発の参考になれば幸いである。

エンジニアの生存戦略について考える

エンジニア

ども、@kimihom です。

エンジニアとしてやっていくと決めた時、意識していかなければいけないことはどんなことだろう?技術力はもちろん必要だけど、それを証明できるものを持っていないといけない。あなたがどれだけ技術があるのかを他人に示さなければならないからだ。エンジニアとして生存していくための戦略について考察する。

f:id:cevid_cpp:20170219222525j:plain

あなたなりのアウトプットを持とう

一昔前の考え方であれば、「資格」がこれに相当した。相応の資格を持っていれば、そのスキルを持っていると対外的に証明できるから、仕事に困ることはない。今でもそのような資格ベースで仕事の裁量が決まる業界は多いことだろう。

しかし、テクノロジーの世界ではそれは一つの参考程度に過ぎず、"めんどくさいお勉強がちょっとできる"程度にしか思われない傾向がある。特に技術の進歩は早いので、数年前に取った資格が、もはや必要のないものだったり、そもそもその技術が企業で使われなかったりすることも多い。テクノロジーの世界で資格が重宝されるのは、エンタープライズやお堅い仕事向けの場合に限るだろう。

私は、エンジニアはもっと自由で色々なものを作れて、理想を追い求め続けられる素晴らしい仕事だと思っている。エンジニアはプログラミングをただ単に仕事としてのツールとして持つのではなく、自分の追い求める理想を実現するためのツールだと考えるべきである。そのアウトプットとして出てきたものってのは、間違いなくどこの会社でも欲しがられる貴重なエンジニアとしてのアピールポイントとなるだろう。

それを証明するために一番手軽なのは、自分の作ったサービスやライブラリを持つってことだ。ただし、サービスの場合は自分が担当していないところも多かったりするから、端から見るとあなたはそれにちょっとだけ加わっただけの人間かもしれないと疑われる可能性もなくはない。ライブラリ、とりわけオープンソースの世界でも一回プルリクがマージされただけでコントリビュータですなんて言われた日にはたまったもんじゃない。

しかし、こういうのはちょっと面接で深掘りして聞けばすぐにわかることだから、気にする必要はない。あなたは技術に没頭してきた分だけ、そのことについて深く語ることができる。Aの資格を持っていますとかいうよりよっぽど素敵なことなのだ。なぜなら、あなたは実際に行動し、人に役に立つものを作れるというのを証明できたからである。

ただ不幸なことに、それを評価できる人間が少ないってのがある。そんな評価すらできない企業に入る価値はないっていう意見もあると思うんだけど、それを正しく評価できるガチエンジニアが面接に来てくれるかって言ったらそういうわけでもないので難しいところがある。だから、誰もが「この人は腕利きのエンジニアだ」と思われるような何かを持つってのは重要だと考えている。

そこで私が重要視しているのがアウトプット、つまりこうやって記事を書いたり、イベントに登壇したりすると言った活動だ。ブログでそれなりに読者がいたり、はてブされていたりすれば、誰だってその人が世の中に必要とされている記事を書いている人だということは認識できる。同様に、どこかに登壇したという話があれば、そのコミュニティで必要な存在であるという認識を与えることができる。私も登壇履歴として、その経緯を毎回まとめるようにしている。

ただ単に Twitter や Facebook で記事のコメントをしている程度ではいけない。あなたから生み出した、本当のコンテンツを世の中に提供しなければ、流れに乗っかっているだけの存在程度でしか認知されることはない。

とりわけエンジニアってのはそういう文章を書くだとか、どこかで発表するだとかは苦手な傾向が強い。でもこれは色を濃くして言いたいんだけど、慣れの問題である。最初 自分にあえてプレッシャーをかけてブログを書き続けるようにしたり、思い切って登壇募集のイベントに申し込んでみたりするだけでいいのだ。それで次第といいものがアウトプットできるようになると、ブログ記事経由で面白い話が舞い込んで来たり、発表経由でより大きなイベントに出させてくれたりするものなのだ。やがて、それがあなたのステータスとしていつまでも残り続けることになる。

アウトプットを持った先に待っているもの

それは本当の意味での自由だ。あなたがどんな状況だろうと、あなたを必要とする企業は必ずいる。あなたが世の中に必要とされたエンジニアであることを誰がみても明らかな状況を作っているので、職探しに困ることはない。

だからこそ、いつだって思い切って何かをチャレンジしたり、休養をとって世界一周したり、時には企業のエンジニアとして腕を振るったりすることができる。そんな “自分の意思” で生まれた行動によって、また素晴らしいアウトプットが生まれ、多くの人に必要とされるコードや記事を書き続けることができるのだ。これがエンジニアのゴールデンサイクルである。

“企業に所属したエンジニア” をアピールすることはできても、"個としてのエンジニア" をしっかりとアピール/ブランディングできている人はまだまだ少ない。だからこそ、毎回どこかの記事に上がってくるような人が固定化されているのだ。あなたにも必ずチャンスはある。

そこに年齢の言い訳は必要ない。あの有名なエンジニアは何歳だと思っている?一度ブランディングに成功し、色々な人からエンジニアとして認められたなら、年齢なんて関係ないのだ。しかし、あなたが無名でアウトプットのないエンジニアであれば、年齢は言い訳になってきてしまう。この違いをしっかりと認識しておこう。

初めて会った人に対して、「〜社のAさんなんですね。」と言われるのではなく、「Aさんって〜社にいたんですね。」と言われるようになろう。それこそが会社という枠組みに縛られないエンジニアの条件である。

エンジニアとしての生存戦略として、ぜひアウトプットを意識してみてはいかがだろうか。私もその途中ではあるが、いつかどこかで、発表の場などで会えたら嬉しいな、そう思っている次第である。

あなたの躍進を心待ちにしている。

CSS でもプログラミングを意識しよう

ども、@kimihom です。

CSS って言うと、目の前の部品の CSS だけをいじって、なんとかやり過ごすみたいなコーディングスタイルを取っている方が結構いるのではないだろうか。当然のことながら、その場しのぎの CSS プログラミングはやがて破綻し、開発効率を著しく低下させる原因になるし、多くのデザイン崩れを発症させる源になりかねない。

そこで今回は正しい CSS の書き方について改めておさらいしていきたいと思う。

常に影響範囲を気にしよう

CSS において最も手軽にデザインを変えさせられて、かつ危険であるのが、 CSS セレクタの指定方法である。例えば以下のような CSS を見てみよう。

.container {
  width: 980px;
  margin: 0 auto;
}
<div class="container">
   ...
</div>

コンテンツをセンタリングさせる方法として、 container クラスを作ることはよくある。さて、この container はいわば"グローバル領域"に放り出された CSS である。HTML の中で container クラスを指定すれば全てに適用されてしまうという最高にワイルドな状態だ。

「"container" くらいはグローバルでもええやろ」という考えの方ならそれでいいのだろうか。ここが CSS の難しいところで例えば

#main .container {
  background-color: #f2f2f2;
}

みたいな、#maincontainer だけに適用するみたいなコードを書くことがあるかもしれない。#main .container だけであればそれほど問題になることはないかもしれないけど、このような 特別な container がどんどん作られていくと、もはや何が何だか分からなくなってくる。そうして、グローバルの .container をいじってしまうと、他の思いもよらぬところに書いてある container が意図しないデザインとなってしまったり、崩れてしまったりする。

ここから学ぶべきことは、グローバルな CSS 設定は被らない名前で、かつ全体で共通であるもの、基本的にカスタマイズできないもの を定義するようにすべきだ。先ほどの例で言えば、 #main .container で背景色を指定するのは間違えていて、他のクラスを定義してそれの背景色を変えるようにすべきだ。

グローバルに持っていくのは、例えば .clearfix.corner.container などといった、基本的に共通で必ずそれしかないもののみに留めよう。

コンポーネント単位で ID を振って平穏を保とう

HTML では設計が必要だ。ページ中にある要素をそれぞれコンポーネントとして分割し、それぞれに ID を振って CSS がぐちゃぐちゃにならないようにしなければならない。

f:id:cevid_cpp:20170216233952p:plain

部品としてまとめるために、最後にCmp などの接尾語を設けると良い。これは、例えばheader というクラスを他で誤って指定してしまっても影響が出ないようにするためだ。何かしら部品の最上位の ID で個別で割り当てられる何かであれば何でも良い。こうすれば、

#headerCmp {
  ...
}
#mainCmp {
  ...
}
#diaryIndexCmp {
  ...
}
#diaryDetailCmp {
  ...
}
#sideCmp {
  ...
}
#footerCmp {
  ...
}

という感じで、それぞれコンポーネント内だけにしか影響の受けないCSSを書くことができる。このコンポーネント内は基本的に HTML のクラスで指定してあげると良いだろう。CSS でコンポーネント以外の ID はあまり使わなくて良いだろう。 JavaScript 側で何か必要な時に入れるくらいだ。

このようにコンポーネント単位で分けると、CSS のファイル分割も可能になり、見通しの良い CSS を書くことができるし、程よく共通化することができる。

しっかりと"まとめる" ってことをしていけば、メンテナンスしやすい CSS をコーディングし運用していくことができる。さらに適切に分割すれば、"コピペして他のところも同じようにする"、 みたいなプログラミングでやっちゃいけないことをしなくて済むようになる。CSS もプログラミングだというのは、こうした点からである。例えば管理画面とランディングページの body タグにそれぞれ ID を割り当て、それぞれに適用できる共通 CSS なども定義できるだろう。

#landing {
  ...
}
#console {
  ...
}

とにかく、影響範囲に気をつけながらも部品をまとめていこうということだ。

デフォルトの CSS では、この影響範囲を絞ることが難しいので、LESS や Sass を使うのはほぼマストとなってくるだろう。これらを使えば、CSSを階層表示できる。

#landing {
  ...
  // #landing #mainCmp {..} と同じ
  #mainCmp {
     ...
  }
}

ちょっとした開発環境のセットアップに時間がかかるかもしれないが、その時間は間違いなく無駄にならないので頑張って欲しい。

終わりに

CSS において大事なのはこれだけって言ってもいいかもしれない。これさえ気をつければ、あなたも幸せな CSS コーディングライフを過ごすことができるだろう。

ただ闇雲に新しく CSS の指定を作るのではなく、毎回 CSS を適用する時には"設計"の思考を巡らせ、最適なコーディングをしていこう。

少額決済の分野がなかなか面白い

雑談

ども、@kimihom です。バレンタインデーでも熱海でこもって開発してるため、チョコという言葉すら聞きませんでした。

さて、最近の Web サービスを見ていると、どんどん私たちの生活の中にのめり込んでいるように感じる。その裏で少額決済サービスがどんどん登場してきている。

人との会話は当然のようにスマホで行われるようになったし、売買は誰でも持っているものを販売できるようになったし、誰かの持っているスペースを手軽に借りたりできるようになってきた。そこでますますニーズが高まってくるのが少額決済のサービスだ。

少額決済ってのはどんな分野かっていうと、なんらかのサービスのアカウントとクレジットカード情報や住所などを紐づけておくことで、そのアカウントを通して少額な決済を行なうビジネスだ。これの何が面白いかっていうと、支払いに際して必要なのはそのアカウントだけになって、しかも個人がその支払いを受け取ることができるってのがすごい。今までなら銀行口座を教えて振り込む or クレカ登録して支払い、一定数溜まったら銀行から下ろせる といった流れだろうが、今後はスマホで承認/却下 するだけであらゆる個人間の支払いが済まされる時代がやってくる。

今でも CtoC の分野ではそのような個人間での決済のやり取りは行われているけども、個人間決済のプラットフォームが成熟していけば、もはや個々のサービスでクレカや銀行口座を登録する必要などなく、ただ単に少額決済サービスのアカウント情報を好きなところにどこでも載せればいいだけだから楽だ。個人のブログや Twitter などに “~ 売ります” みたいなことを書けばいいだけとなる。買う側も共通の小口決済サービスアカウント経由で支払いができれば楽なもんだ。

この分野は各社がこぞってシェアを取ろうと戦国時代になりつつある。どこが最初に一番普及させられるか見ものだ。

個人的には常に時代のトレンドを生む10代のユーザーが、どのサービスを使うかってので勝負が分かれる気がする。10代でクレカだとちょっと難しい気がするから、それ以外の支払い方法を持っているところが強いのかもな。

私自身この分野の専門家ってわけではないので、より具体的な話は詳しくないんだけども、見守っていきたいなと思う。

ちょっと今回は短いけどそんなところ。