ザッツ・スタートアップな一年を振り返る

f:id:tksmd:20171002233114p:plain (この一年の GitHub の contributions )

前回エントリから丸一年、主にプロダクトや技術領域におけるハカルスのこの一年を非公式に振り返ってみたいと思います。

目次

  • チームビルディング期 (10月-12月)
  • MVP 構築期 (1月-3月)
  • データ解析サービス立ち上げ期 (4月-6月)
  • サービスブラッシュアップ期 (7月-9月)
  • ふりかえりと次の一年

チームビルディング期 (10月-12月)

ハカルスジョイン後の最初のミッションは、それまでにあった iOS アプリのバージョンアップ ( 社内では v2 プロジェクトと呼ぶ ) でした。バージョンアップの主な目的は法人向けへのサービス切り替えのために、それまでの「フリーで使えて(基本は)スタンドアロンなアプリ」を、「認証を通す、サーバに確実にデータが保存されるアプリ」にする事が必要でした。そのために既存のモバイルのコードベースは一部流用しつつも、モバイル・バックエンドほぼ全てを置き換えることになりました。

僕のジョインよりほどなくしてフィリピンにチームを立ち上げ、バックエンド開発をフィリピン、モバイルの開発を日本、という体制をワークするようにプロセスを整えたりチームビルディングも並行して行っていました。この頃はフィリピンのメンバーも不安あったろうし、僕のジョイン前から開発をされていたモバイルチームも経緯をよく知らない新 CTO に戸惑いがあったんじゃないかと今に思えば感じるところがあります。

この頃のニュース

MVP 構築期 (1月-3月)

まず年初 1 月に iOS アプリ v2 の初期版をリリース。このリリースでは食事記録機能のみでしたが、それでも食事指導、レシピの推薦といった基本形をこの時期に立ち上げたことはメンバーの底力と頑張りを改めて感じる次第です。その後 iOS アプリは運動記録や体重記録 ( OMRON connect 対応なども ) を着々と進め、また 3 月には Android 版とクラウド版もローンチを行い、法人向けサービスの MVP が一通り整ってきたという感じでした。

1月にフィリピンメンバーを初めて日本に招き 2 週間ほど一緒に仕事。厳寒の京都はかなり応えた模様でした。チームとしてはお互いの得手不得手などが見えてきて、開発チームの「チーム感」がこの頃くらいから出てきたように思います。3-4 ヶ月はチームが馴染むのに必要な時間で、それは日本人・外国人で特に変わりはないのだな、と再認識。

この頃のニュース

データ解析サービス立ち上げ期 (4月-6月)

サービス開発にあわせてスタートした営業活動の中で、ハカルスで利用している技術そのものにも興味を示していただける事が多かったことから開始したデータ解析サービス。新聞・業界紙など幾つかのメディアで取り上げていただいたおかげでインバウンドでのお引き合いが多く、案件をこなす中で社内で共通に使われるライブラリも少しずつ整ってきています。この時期にハカルスの食事解析を別の形で切り出した Web API 開発にも着手しだしました。

モバイル及びクラウドがある程度形が定まったこともあり、この頃から僕自身はそれらのコードを書くことは基本なくなりました。代わりに営業支援、データ解析サービスの立ち上げ、採用活動にウェイトをうつし出しました。この辺りの作業ウェイトの変遷が GitHub の履歴にも現れています。

この頃のニュース

サービスブラッシュアップ期 (7月-9月)

Hacarus for RELO CLUB の提供をはじめたり、フィリピンサイドにメンバーが増えたり、一歩ずつモバイルアプリの機能改善を進めていました。また、まだ公開していませんが、この冬くらいにお目見えする予定の新プロジェクトにも着手しています。技術的には Kotlin 採用を決めて一部置き換えをはじめたりもしています。

法人様向けの案件が増えてきたこともあり、このあたりには特にプロジェクト管理に力を割くことが増えてきました。

この頃のニュース

ふりかえりと次の一年

特に狙ったわけではないのですが、プロダクトや会社のフェーズにあわせて三ヶ月ごとくらいに少しずつロールを変化させながら一年がたちました。また、今月から現地にプロジェクトマネージャがメンバーに加わり、これまでの仕事を委譲していくので、次の三ヶ月はまたきっと違うものになるでしょう。

この一年は、いわば B 向けサービスのリーンスタートアップを粛々とやったのですが、「リーンスタートアップ、言うは易し、行うは難し」を体感しきりでした。改めて認識したことの一つが「リーンスタートアップ」の考え方は、特にその初期は「より良いものを届けたい」というエンジニアの気質に反する、ということです。経験を積んだエンジニアであれば、「もっとこうすればよくなる」点が生まれたてのプロダクトには沢山目につきます。その状態で、ユーザさんの目の前にだしフィードバックをもらうという行為は、わかってはいても「本能に反する」ので、中々にしんどいです。

これまでの体験からリーンスタートアップの有用性を信じているので、なんとか「本能に反する」ことも僕はできましたが、もしこれから初めて「リーンでプロダクトつくるぜ」っていうエンジニアの皆さまには、この認識だけでもあれば、少しは楽になるんではないかと思います。ともあれ、粛々と続けてきた結果がいよいよ実を結びつつあるのを感じています。おかげさまで幾つかのプロジェクトも走りだし、それを通じてプロダクトをガンガンと磨いていくことで、サービスがより良いものになる感覚を強くもっています。

20代の若手 CTO に比べると、体力では勝てないですし、特化した技術力ではなかなか戦えないおじさん CTO で、プロダクト開発面では優秀なチームメンバーに本当に支えられている一方で、経験に基づいた判断速度や、人への頼り方、開発の優先度の付け方へのバランス感覚、みたいな部分は、これまでのキャリアに裏打ちされていると思うところではあります。「米ベンチャー成功者 大学出たてより30~40代が多い」みたいな話もあり、40近くのおじさんエンジニアに、ベンチャー CTO というのはマネージャーやシニアエンジニア以外のキャリアパスの選択肢になり得るんじゃなかろうか、と思ったりもしています。

さておき、来年に向けては、(あくまで、まだ個人的にですが)技術サイドとして「サービスの徹底的なブラッシュアップ」「グローバル展開」「データ解析サービスのプラットフォーム化」といったところに注力できれば、と考えています。また採用計画なども練った上で適宜応募も開始していくことになると思いますので、こういったフェーズのベンチャーで腕試ししたいエンジニアの方がお近くにおられましたら、ぜひご紹介ください。来年一年は怒涛になるとは思いますが、かなり技術的にも、会社的にも面白いことになる感覚がありますので、なにとぞ! (個人的に twitterfacebook でご連絡いただくでも構いません! )

ハカルスにジョインしました / I've just joined Hacarus!

f:id:tksmd:20161003012722j:plain ( 前職ヌーラボの同僚からもらった扇子で、末広な形から繁栄を意味する縁起物とのこと。ありがたや。)

English follows Japanese

タイトルのとおり、京都のヘルスケアのベンチャーハカルス に CTO としてジョインしました。

CTO という役割は色々解釈もあると思いますが、ベンチャーの初期においては「提供したい価値をプロダクトという形で結実させる」ことに、名の通り技術方の責任者としてコミットする事が、大きな仕事の一つかな、と考えています。

その「プロダクトのあり方」は、プロダクトマーケットフィットを追いかけて行く中で変化するものなので、その仮説検証の段階からプロダクト作りに関わることや、スピード感をもって沢山の仮説検証をするために開発やデリバリーのプロセスを構築していくことも大切な仕事だとおもっています。チームに参加するにあたり、まずは現在の状況を把握した上でそういったところも一つずつやっていければ、と思ってます。

ちなみに、技術領域的にモバイル、機械学習に踏み出すにあたり、京都や関西圏でオススメのコミュニティなどあれば教えてもらえると嬉しいです。あと主言語は Python になります。

ということで、もしよければ以下の Twitter アカウントのフォローや FB ページにイイねもらえると、励みになりますので、よろしくお願いします

--

As seen in the title, I've just joined Hacarus, which is a health care venture in Kyoto, as CTO.

Though CTO's role seems not clearly defined in general, I think one of the most important work of CTO in an ealry stage venture is simply to make what generates value the company wants to offer to customer as "product".

As what product should be could change while trying to find out product-market-fit, it's also important to be involved in validation of hypothesis and build flexible development and delivery process so that we can do trials-and-errors quickly. I'll start with understanding how team works now and then do what I should do one by one as fast as possible.

I want to learn mobile and machine learning technology and I'd appriciate if you tell me good tech communities in Kyoto or Kansai in those tech domains.

Finally, I'd like to invite you to follow or like the following Hacarus's twitter or Facebook page to encourage me :-)

統計解析・機械学習のもくもく会をはじめます

お題の通り、統計解析・機械学習もくもく会をはじめます。

  • 日時 : 隔週火曜 18:00-21:00 ごろ (状況によって適宜調整の可能性あり)
  • 場所 : ヌーラボ京都事務所 1F ( 河原町丸太町くだる このあたり )

ということで早速第 0 回を、もう今日になってしまいましたが、今日から開催しようと思います。

開催の趣旨

先のエントリ にも書いた通りなのですが、弊社のサービスにおいて「各種データ解析を行い、ユーザの行動をより良く知りたい」なぁ、と思っています。そうした背景もあって、統計解析や機械学習について少しずつ書籍を読みすすめていたのですが、理論的な難易度と僕の理解度の問題もあり、読むだけではなかなかピンと来ない!そこで写経みたいなノリで、何か簡単なサンプルでも良いので手を動かしながら学んでみたいと思うに至りました。

また技術領域的には社内でも未踏の領域もあるので、もしお近くに同様の領域に興味がある人がいれば色々とディスカッション出来ると嬉しいなぁ、ということもあってオープンなイベントとしてやろうと思いました。僕自身はこの領域に関してはど素人ですが、ツールとして使おうと思ってる PythonAWS のインフラ周りの道具立ては割と手馴れていますので、そのあたりで面白い話し出来るかな?出来ないかな?などと淡い期待を抱いております。

是非、たまに局所的に噂になる弊社の京都事務所にずどーんとお越しいただければ嬉しいです。

何をやるのか

テーマとしては統計解析および機械学習に関する何かであれば、何をしても良い感じにしようと思います。ちなみに僕は Amazon.co.jp: 入門はじめての統計解析: 石村 貞夫: 本 の各章の問題を、pandasIPython あたりを使って実装していこうと思ってます。最初の一章だけ既にコミットしてます。

これがひと通り終われば Amazon.co.jp: 実践 機械学習システム: Willi Richert, Luis Pedro Coelho, 斎藤 康毅: 本 で同じようなことをするかもしれません。

ちなみに Python 使う人が社内にも少ないので個人的に Python 友達が欲しかったりはします。

どう参加するのか

今回は今日告知の今日開催なので、この状態で人に来てもらえたら奇跡なのですが、もし「行くよ」という方いれば、ここにコメントか @tksmd までメンションください。次回移行は FB イベントか何か用意します。

あと 18:00 スタートは早すぎるよ!という意見もあると思いますが、もくもく会なので基本あんまり時間は関係なかったりもします。一応このあたりの時間であれば誰かいます、といった目安と思っていただければ。

参考図書

www.amazon.co.jp

染田、エバンジェリストやめるってよ #DevKan

先日 DevLOVE 関西の 自分戦略〜エバンジェリスト編〜 という、エバンジェリストのキャリアについて語るイベントで「エバンジェリストをやめる」というお話をしてきました。( ※ 会社は変わってません。会社の中でミッションが変わりました。)

今回の発表は長沢さん、寺田さんという大先輩に囲まれている上に、「エバンジェリスト、やめます」という内容もあって、この二年のエバンジェリストとしての発表の中で、もっとも難産かつ緊張も最大級でした。ミッション変更が決まったのが三月末ということもあって登壇も迷ったのですが、イベントのオーガナイザの中村さんから「諸々の経緯や想いをそのまま話してもらったらいいです」というありがたいお言葉をもらったこともあり、赤裸々に語ってきました。

イベントでは、長沢さんの「エバンジェリストは市場を創る者」、寺田さんの「エバンジェリストには覚悟と情熱が必要」といった言葉がとても響きました。僕自身はエバンジェリストはやめることになりましたが、共感できることがとても多く、手探りながらやって来た二年間が間違いではなかったと、救われた気持ちにもなりました。最前列かぶりつきで聞いていましたが、おそらく聴衆の中で一番心揺さぶられた自信があります(笑

僕の発表については資料の公開も考えたのですが、赤裸々感あふれるのと資料だけでは分からない行間の多い発表でしたので、このエントリであらためて文章としておこして、この二年間のエバンジェリストとしての活動を通じてお世話になった人に対してもご報告とさせてもらえればと思っています。

エバンジェリストをやったことが次のステップに

まず「エバンジェリスト」という役割はやめることになりましたが、それを経験したことで、自分が今のチームの中で取り組みたい領域がよりはっきりしました。ですので、決してエバンジェリストに対してのネガティブな気持ちがあるわけではなく、むしろそれをやってきた事で次の決断が出来たと思っています。

発表の中でも言ったのですが、二年前「エバンジェリスト」に転向しようとしていた自分に、もし今の自分が「とめる」か「すすめるか」をアドバイス出来るとしたら、やっぱり「すすめる」と思っています。アウトプットしていく事を通じて得たチャンスもありましたし、何より沢山の良い出会いに恵まれました。今回のイベントの参加者の方にもここは誤解されないように、ともっとも気遣ったところではあるのですが、長沢さんや寺田さんのお話を伺って、あらためてかっこいいなぁと思う、そんな仕事だと思っています。

では、なんでやめることにしたのか。

エバンジェリストになった年の秋ごろ、これも DevLOVE 関西のイベントで、自分のキャリア上の決断をお話をさせていただいたことがあったのですが ( 参考 )、そこでチームの成果に貢献するために「開発の最前線にいることをやめる」ことを決めた、という話をしました。具体的にいえば、当時マーケティングを担当するスタッフの絶対数も少なく、かつ自社の特徴を考えても、エンジニアサイドの人間がマーケティングに関わることで、よりよく会社やサービスが認知され、さらなるサービスの成長に貢献できるのでは、と考えていました。

そうしてエバンジェリストとしての活動をはじめたのですが「エンジニアがマーケティングの領域で貢献できることは多い」という仮説に対しては、確信に近いものを肌感覚として持つに至りました。幾つかの仕事においては、エンジニアとマーケティングが協調しないと生まれなかったような成果も出ることもありました。( 2014年の活動内容 )

その一方、具体的な成果を定義しづらい多くのタスクに対して達成感を得にくくなったり、自由に一人で動き回れる反面、社内のメンバーと結果や悩みを共有できない孤独感が募っていきました。また、エバンジェリストになった時、他に頼りになるメンバーがいるから「原則手は動かさない」と決めていました。それより自分しかできないことに注力しようと。ところが、そうして過ごした去年の冬ごろ、五歳の娘にふと言われた「父ちゃんはつくるのが好きなんやなー」という言葉が、思いのほかこたえたんです。それが一つのきっかけとなって「コードを書きながら考える」という「得意」を活かす方向はないか、という気持ちが大きくなりだしました。

こういった悩みを旧知の友人や役員とも何度か相談した結果、軸足は「エンジニアとマーケティングの間」に置いたまま、

  • サービスの成長そのものを直接ゴールとしてもつ
  • チームと密接に関わる
  • 得意な部分を活かす

といった、ミッションのピボットを行うことにしました。

じゃあ、次は何をやるのか

一つのサービスに集中してグロースハックを担うことになりました。具体的には

  • 各種データ解析を行い、ユーザの行動をより良く知ること
  • 様々なデータやメトリクスを計測可能な状態にすること
  • データ解析から得た知見をベースに改善施策を立案すること
  • 開発およびマーケティングチームと協同して施策を実行すること
  • 施策後のメトリクスの結果から次のアクションを考えること

といったところがミッションになります。

まずは各種のデータを集めて AARRR モデルをベースにしてメトリクス設計をしようとしています。今は前段としてデータの可視化のためのツールを試しています。並行して、実際にデータ解析でどんなことが出来るのか、またどんなデータを集めることが必要かを知るために機械学習の勉強をはじめました。

新しいミッションも簡単なことではないと思いますし、また失敗も沢山すると思いますが、一歩ずつやっていきたいと思います。ということで今後は、グロース☆ハッカー染田としてやってまいりますので、引き続きよろしくお願いいたします。

※ 尚、コミュニティには変わらず参加しますので、また何かあれば適宜お声かけください!

2014年やったことをざっくりまとめました

まだ終わってませんが、概ね落ち着いてきました。今年は色々と対外的なところのお仕事を頑張ってました。

イベント関連

発表や企画、ブースなど関わったイベントが年間で30本。今年は月一何らかのイベントで発表、もしくは企画するといった所を目標にしていたので、そこはクリア。

ブログ・コンテンツ

ヌーラボ日本語ブログが年間17本。イベント関連のものや、セキュリティ周りのものもそれなりに書きました。幾つかのエントリはそれなりにブクマをいただけて励みになりました。

英語ブログは 8 本。幾つかは描き下ろしではなく日本語コンテンツの翻訳依頼と内容の調整などをした感じでした。

その他、今年は サルでも分かる Git 入門 の多言語化に取り組んで、主に翻訳の調整・公開にまつわる諸作業などを行いました。何とか年内中に 5言語版を出せました。英語以外は内容さっぱり分からないので、翻訳者だけでなく別のレビュアーにダブルチェックをお願いするなどしました。このガイド、英語版は Git のオフィシャルサイトからもリンクをはってもらっております。( "Short & Sweet 参考" )

また Developers, let's play! | Nulab DevelopersDrupal にて立ち上げたりしておりました。

その他

事務所引越し たり、日経コンピュータの特集向けの取材をうけたり、サーバの様子をみながら Mackerel の導入を進めたり、などしておりました。

DevLOVE 関西 Decision 後記

間が空いてしまいましたが、先日 DevLOVE 関西 Decision にて発表させてもらいました。

このエントリでは当日時間が足りずに伝えられなかった事を少しと、後は僕自身の気付きを書き残しておきます。

      • -

まずお話出来なかったのが資料で言うところの最後の方 50 枚目 からの数枚です。

まずオペレーショナルな仕事はどんどん取って変わられるという所。僕自身の経験で言うと、サンに居た頃の仕事の一つに、データセンターでの環境のセットアップがありました。冷蔵庫みたいなサーバの構成を組んだり、ネットワークやストレージを配線したり。今では AWS でコマンド一つで済んでしまっています。

また最近何度か オフショアをやられている方の話 を聞く機会があったのですが、口を揃えて言うのは基本的な能力は非常に高い、との事。例えばいわゆるフィーチャーレベルの仕様は日本で設計するけれど、それをブレークダウンして詳細の課題を上げるような所から、オフショア先に任せていると。そういった方々が日本の数分の一のコストで開発しているという事実。また、オフショアに限らずとも例えばチームに若手が入ってきたような場合も同様でしょう。

僕は開発や運用は創造性や経験を要する仕事だと思っていますし、簡単に取って変わられるようなオペレーショナルなものばかりではないと思います。ですが、若手の成長といったチームの新陳代謝や技術の進化を考慮すると、少なくともこの業界においては、自分の今やっている仕事の何割かは少なくとも将来的に「何かに」取って代わられるべき、だとも思っています。

では経験を積んだエンジニアとして何にフォーカスしていくべきか。僕はざっくりですが「生み出す事」だと思っています。それは例えば、データベースなどの技術志向な「ツール」でもいいですし、アジャイルや DevOps といった「考え方」でもいいですし、顧客向けの「プロダクト」でも、なんでも良いと思ってます。その為には、何をやるにせよ「生み出すものの価値」にちゃんとフォーカスしていかないといけない。

「プロダクトを生み出す」という事でいえば、「ユーザにとっての価値」にフォーカスする必要がある。ただ、これは頭で分かっていても、実は結構難しい。「問い合わせ対応・障害対応には関わりたくない」「技術的なチャレンジのない仕事はテンションあがらない」エンジニアだったら、正直こういった感情を持ったことありませんか?これは制作に集中している状況に割り込みは避けたいという自然な思いであると同時に、こういった感情だけにとらわれ続けている限り「ユーザにとっての価値」にフォーカスするようにはなれません。

「感情」は自分の行動のベースとなりますが、これをコントロールするのは自分でも難しいものです。ただ経験を積んで見える世界が変わり、「欲望」が変化することは僕自身が体験したことです。なので、自分自身のど真ん中にある「欲望」の形を少しずつでも変わるように働きかけることで、そこから産まれる感情が変化し、結果として自分の行動が変わっていくのではないかと考えてます。

その為に僕の場合は開発の最前線にいることは諦め、一旦「己の成果」を脇におき「チームの成果」の最大化にフォーカスの中心を移す決断をしました。そうすることで、よりプロダクトの成長を加速させる方向で行動がとれるように変化していこうとしています。ただ、やみくもに今までやってきたことを捨てるべきという話ではなく、僕の場合「未知のものに対する学習」プロセスを好む性質と、収集心ともいえる「色々やりたい」という性質が強く、全く新しい事でも一生懸命やることで楽しめるようになるだろう、という算段はあっての決断です。

結局「自分自身をまず知る」という事が大前提で、その上でタイミングが来たときに、恐れず行動を取りましょう、といった、ここまでの一連の話がタイムオーバーで出来なかったところです。既に長い。。。

      • -

僕自身の気づきについてもあと少し。

まず、全く違うバックグラウンドをもっていて、かつ今も僕とは異なる仕事をしてる川畑さんの話にすごく共感する所が多く興味深かったです。僕自身のプレゼンの内容は、村上隆さんの「芸術起業論」を読み返していて見つけた「欲望」という言葉がストンとハマった所からきています。正直、エンジニアの方とこれまで話した中で村上隆さんの名前が出たことはなかったので、そういった意味でも面白かったです。大石さんのお話も刺激たっぷりでした。僕自身とは違う考えではありますが信念もってやられている姿に考えるきっかけを沢山いただきました。

また、懇親会で話をしていても、会社が傾いた結果給料が払われなかった経験などから「働いたらお金がもらえるのは当たり前ではない」ということを肌身で理解されてる方が数名もいたことに驚きました。お金の話は嫌がる人多いですが、正しく「対価にこだわる」事はエンジニアにとっても大事なことだと思っていて、そういった経験をされてる方は、理屈ではなくて体験としてこの辺りが共感できる感じでした。

最後にもう一つ。僕自身が話したことは同じ世代のエンジニアの方には共感していただけた方も多かったように思います。が、自分自身を振り返っても、たとえば十年前の自分に理解出来たかと問われると自信を持ってノーといえます。年齢も含めチームの多様性を認めつつも、こういったところを共通のゴールや目標として見いだして、共有していくことは継続的に取り組むべき事なんだろうなぁ、とも思いました。頑張ります。

最後に宣伝。価値を生み出すプロダクトを作るために実際にどんな試行錯誤をしているのか、といった内容で、 DevLOVE 関西ゆかりの方々と書かせていただいた電子書籍に一章よせさせてもらいました。十名各々が特色あって面白い書籍になっていますので、ご興味あれば是非読んでいただき @ 宛にでもフィードバックいただけると嬉しく思います。

開発現場に伝えたい10のこと
DevLOVE関西
達人出版会
発行日: 2013-11-16
対応フォーマット: PDF, EPUB


最後の最後に発表の機会を与えてくださった中村洋さん、及び DevLOVE 関西のスタッフの皆様、本当にありがとうございました!

「小さなチームのエンジニア」にとっての英語

をタイ出張の合間に読みました。

この手の話は本当に文脈次第なので「全て」というのは少し言い過ぎかなぁ、と思いつつ、でも「小さなチームのエンジニア」にとっては、元エントリとはまたちょっと違う視点から、今後英語の必要性は高まるかもしれないなー、と思ったのでツラツラと書いてみます。

昨年の春に、台北で開催されたスタートアップウィークエンドにテクニカルメンターとして参加させていただいた時のこと。たまたま最終日にジャッジに加わらせて頂くことになり、最後ピッチを聴いていたのですが、何組かは中国語で発表されていて、会場は盛り上がってはいるものの中国語の分からない僕にはどんなことを伝えたいのか理解することは出来ませんでした。

ジャッジをさせてもらうことになった手前、何とか理解したいなと思いつつも発表資料だけでは限界があり、申し訳ないながらも、良い悪いといった「評価すらできない」という結果として回答した記憶があります。確か僕以外にも同様に中国語がわからない方がいらっしゃって、彼らのサービスはジャッジ間で話題にあげられることは残念ながらありませんでした。

これは、英語を母国語としない外国人として

  • インターネットを通じてサービスを提供するものにとっての英語の重要性

を、英語を母国語としない国にいながら再認識させられる、という不思議な体験でした。

ざっくりインターネット人口が 20 億人いるなかで、英語を利用するユーザは 1/4 強です。

ヌーラボ代表の橋本さんの言葉で、僕が好きなものに「僕らは "海外" にものを売ろうとしてるんじゃなくて、"インターネット"でものを売ろうとしてる」というのがあります。そうなると最大のパイである英語圏は無視出来ないものである事は自明です。

クラウドスマートフォンといった全世界に展開するプラットフォームのおかげで、小さなチームでも世界のインターネットユーザをターゲットにして挑戦できる時代がやってきています。例えば 100万ユーザを獲得する場合、日本語圏のみをターゲットにした場合は全体の 1% を取らなければならないけれど、英語圏も含めて考えると、0.2% を取ればよい事になります。勿論、現実はそんな簡単な数字の話ではありませんが、国内の並みいるビッグプレイヤーと同じ土俵で戦うより、後者のほうが小さなチームにとっては現実的に戦っていける土俵であるように感じています。実際 AWS のユーザグループの中にも、小さいチームでも世界を見てる人達は少なくありません。

僕自身は、Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 で語られているような「小さな ISV」が沢山存在している状態になっていくと、エンジニアにとっても、より面白いくて、エキサイティングな業界になるんじゃないかなぁ、と思ってます。作り手が

  • 何を作るかを考えるところからはじめ、
  • 実際にモノを作り、
  • どう届けるかを考え、
  • そしてユーザに届けて、
  • 最終的に対価を得る

という全体に関わるには、やはり小さな ISV のほうが向いています。エンジニアリングそのものも十分エキサイティングで魅力的ですが、「自分が作るもので何を生み出したいか」という視点のあるなしは、そのエンジニアが生み出すものの魅力を大きく変えうる要素だと思っています。

そして、その視点を育むには、泥臭いながらも時にはユーザの声をきき、時には障害と戦い、時にはリリース案内の文章を考え、時にはイベントで製品紹介をする、といった様々な事をエンジニアが「自身の仕事」として引き受ける事が必要だと思っています。正直いえば「エンジニア」としては面白くない仕事もあるでしょう。ただ、それを積み重ねることが良いプロダクトを生み出すための感性を育むという事を、入社以来ずっと一緒に仕事をしてきたヌーラボの同僚の姿から僕は教わりました。

そういった小さなチームが「インターネット」でものを売る場合、エンジニアも社内外問わず「伝える」役割を担う場面が必ずあります。そして、伝える相手は「インターネット」=「英語」です。英語もプログラミング言語と同じで積み重ねでしか上達しないものですので、普段から少しずつでも自分にあった形で英語のトレーニングをすることは、小さなチームのエンジニアにとっては必要性が高くなるのでは、と冒頭のエントリを読んで改めて感じました。

まだ模索中で成果もあやしいですが、この四月くらいから試行錯誤しながら僕自身が取り組んでる英語学習のやり方を機会あればまたエントリにあげてみたいと思います。