中堅SIerから開発者向けツールベンダー CData Software Japanに転職しました!(1年経ってるけど)
せっかくなので一回書きたいなー、書きたいなーと思っていた、退職・転職エントリ。
SI・SES系からWeb系に転職する人、コンサルに行く人、それなりに居る気がしますが、ツールベンダーに転職する人の記事は見たことが無いなぁと思っていました。
それに1年経っていろいろとわかってきたこともあるので、ここいらで投下してみようと思います。(遅いですかね。でも逆に落ち着いて、今の会社を見れるようになったので、それはそれでいいかなと思ったり)
それはそれとして、色々と転職で悩んでいる人の参考になれば幸いです。
そもそもあなたはどんな人?
・31歳(転職当時は30歳) 既婚・3ヶ月前に子供ができた
・Microsoft系中心のSIerで7年 Dynamics CRM/365というCRM系SaaSのパッケージSIが中心でした
・実際にプログラムを学び・書き始めたのは、ここ4年ほど
・ひたすらBlogやコミュニティ活動を行って、気がついたらMicrosoft MVP for Business Solutionを受賞
・今の会社で5社目(卒業→観光写真撮影→機織りの弟子入り挫折→Web系SI→小規模SI→中堅SI→現在)
・大学時代はデザイン科。機織り・染め物をしていた。刺繍もやります。もともと超絶アナログ人間。
facebookもtwitterもLinkdInもInstagramも晒しています。
なぜ転職しようと思ったか?
23~26歳ぐらいまでは、技術というよりクラウドサービスのMS Dynamicsが中心で、なんかわからないけどお客さんと話したりするのは苦じゃなかったので、パッケージのカスタマイズやプリセ、マネージメント紛いのことを中心にやっていました。(デザイン科出身だったので、提案書を整えたり・メッセージを考えたり、プレゼンするのが苦じゃなかった)
それまでもチマチマ技術には触れていたものの、あまり理解や腹落ちすることなくやっていたのですが、東京にやってきて、これは技術をまなばねーとヤベえ! 生き馬の目を抜かれる! と思いたち。
そこから色々とやりはじめ、27の時に、ようやくC#書くの面白いな、なるほどな、と少しづつ腹落ちしてきました。
29歳ぐらいでようやく、Web APIって面白いな! プロトコルってそういうことなんだ! ODataすげぇ! あ、HTTPってそういうことなんだ! ITパスポートのOSI参照モデルが腑に落ちてきた! となり (それまでパッケージ用SDKベース開発が中心だったんですよね。)
でも、これはもっとテックな部分身につけないと、これから自分のキャリアってヤバくない? そんなことを、また考えはじめました。
そんな時に、主催していた勉強会で、「CDataどうですか?」って今の会社の代表と技術マネージャーの人に声をかけられ
ふーん、JDBC? ODBC? ADO.NETーへーへー、でDynamics 365にアクセスできる製品? なにそれ? おいしいの?(ほじほじ
はぁ!? ADO.NET EntityFrameworkでDynamics 365やTwitterのAPIが叩ける!? なんじゃそりゃあ!? 変態か!? そんなもの商売になるのかよ!?
みたいな感じになって、実際に製品を触って見る中で「これは面白い!こんなテクノロジーのビジネスがあるのか!」と膝を打ち、転職を決意。
今の会社は仙台なのですが、もともと大学が仙台だったので、じゃあちょうどいいじゃんと、結婚と転職を機に青森から東京につれてきて、色々と振り回している妻をなだめて、仙台へ移動しましたとさ。
CData Software Japan はどんな会社?
アメリカの東海岸にあるノースカロライナが本拠地で、日本では宮城県・仙台市に本社があるツール系ベンダーの会社です。
他にも、中国・アルバニア・ヨーロッパに拠点があります。
社員の9割がエンジニアで、ファウンダーのGent(写真右)もCEOのAmit(写真左)もテックな人です。
もともとは/n softwareという、もうちょっと低レイヤーなSSHやSFTPといった部分のライブラリ開発が中心の会社で、CData はその技術やライブラリを活用したスピンオフみたいな会社になっています。
どんなビジネスをしてるの?
ODBC・JDBC・ADO.NETといった、DB接続用インターフェースのためのDriverを開発し販売しています。
SalesforceやKintone・Dynamics・Twitter・FacebookといったクラウドサービスのAPI、MongoDBやDynamoDB・Google BigQueryといったNoSQLや列志向DBなど、Web APIや独自プロトコル・フレームワークを通じて操作する各種サービスをODBC・JDBC・ADO.NETといった「SQL」で操作できるようにするという、Driver 製品が中心の会社です。
それって何が嬉しいの? ってなると思うんですが、
私が過去のエントリで書いているように、今いろんなクラウドサービスにユーザーがデータを格納していますが、それを操作するプロトコルやライブラリは残念ながら統一感がありません。(RESTで統一とかバカなこと言わないでね)
また、現在多くのBIツール(Tableau・Power BI)・ETL/EAI(AsteriaやMulesoft)はSQLをベースにして、DB間やサービス間の接続を実現しています。
さらにこのAPIエコシステムの時代、一つのAPIだけ触れればOKなんて生ぬるいことはありません。でも、あのAPIとこのAPIはプロトコルが違う、SOAPだRESTだ、GraphQL?
なので、一口にAPIを扱うにあたっても、どのようにそのモデルを扱うか? ツールとの齟齬を吸収するのか? といったところには大きな壁があります。
そんな仕様がバラバラなAPIをCData Driverがラップして、標準のSQLでアクセスできるようにし、ツールも開発者も楽にしようぜ! 楽につなごうぜ! というのがうちの製品です。(それに最近SQLそのものが、見直されつつある感)
普段何をやってるの?
日本市場でCDataの製品を広めるのがミッションなので、契約周りや事務周り以外は、基本的に何でも屋です。営業・マーケティング・サポート・開発なんでもします。とはいっても、私の日々の業務的な割合は「1:1:4:4」ぐらいでしょうか。そして、たぶん一般的な営業とはかなり毛色が違います。
営業
やっていることは、大きく分けてパートナーの発掘とセールス。セールスとは言ってもインサイドセールスかつ、技術ベースのセールスです。
特に面白いのは、トライアルをダウンロードしてくれたお客さんにヒアリングをすることかなと思います。
うちの製品は基本的にライブラリのような立ち位置なので、どんな感じで使うのか、お客さんごとでかなり違います。なのでそこをヒアリングしながら、適切な使い方やベストプラクティスを案内する、というのは営業的でありながらもサポートやカスタマーサクセス的観点もあり、楽しいところです。
あと、自分のブログ経由でトライアルのダウンロードがあったりすると、めちゃくちゃ嬉しいですね!
他にも、展示会に出て直接顧客を発掘したりもしますし、逆に周りで展示している会社さんからパートナーを見つけたりもします。
マーケティング
CDataはとにかくコンテンツで攻めます。自社のKBサイトやQiitaへも技術記事を投稿しています。
Webマーケティングのネタではありますが、最終的にトライアルの顧客への参考資料にもなりますし、サポートのマテリアルにもなり、これだけで契約が成立したりもあるので、めちゃくちゃ重要です。
また、新しいツールを発見すれば、それにCDataのDriverが接続できないか検証して、Blogやホワイトペーパーに仕立て上げます。
他にもハンズオントレーニングを開催したりと、どうしても技術的な製品なので、単純な提案とか営業活動よりも、とにかく触ってもらうこと、検証してもらえる環境を準備することをトコトン重要視しています。
サポート
サポートはトライアル中の顧客と購入済みの顧客で大きく分かれます。(基本メールベース)
既存顧客は障害対応やバグ対応等が中心になりますが、トライアル中のお客さんには、どんなことを達成したいのか? どんなツールやテクノロジーでつなぎたいのか? といったところも鑑みながらサポートしています。
そして何より重要なのが、顧客も基本的にほとんどエンジニアの方、ということでしょう。
プロトコル仕様や、RFCベースで話があったり、最終的なアーキテクチャをヒアリングしながらサポートの案内をしたりする必要があるので、ただサポートと言っても技術的なベースラインは絶対的に欠かせません。
開発
メインの開発拠点は、ノースカロライナやアルバニアといった国外ですが、日本のAPI用のDriverは日本でも開発します! (そもそも日本語のドキュメントしか無いところもあるしね!)
DriverはJavaベースで開発していて、そこから.NET C#のソースコードを生成。(意味がわからない? できるんです。興味の有る方はjava c# 変換 とかで調べてね。)
そのJava・C#のソースコードをベースにしながら、各テクノロジーレイヤーのDriver(ADO・ODBC・JDBC・SSIS・Excel・Mule・PowerBI・PowerShell・etc...)へビルドしていきます。
なので、データソースカットとテクノロジーカットで製品SKUは1000種類を超えます。
一つのAPI・データソースに対応すれば、自ずと10種類製品が出来上がる。テクノロジーカットを増やせば、一気に100種類製品が増える、みたいな変態的製品構造をしています。(褒めてます)
ただ、ビルドが2パターンあるので、Javaでビルドが通っても、.NETでビルドがコケたり、Javaと.NETのソースコードで互換性を気にしながら、作る必要があったりと、なかなかクセがありつつも面白い開発環境です。
CDataの仕事は何が面白い?
とにかくいろんなテクノロジー・サービスに触れ合える! やってみる・動かしてみることが大事!
プロトタイプファースト! 検証ファースト! APIファースト!
ざっくりですが、そんなところでしょうか。
Web APIを提供している会社やツールを作っている会社はすべてパートナーになる可能性があるので、日々プレスリリースをチェックして、新しいサービスやツールを発見し、APIを叩いてみては、これはDriver向きじゃないか? こんな感じで使えるといいよね? みたいにあーだこーだ言って、戦略を練っています。
気に入ったAPIはDriverのプロトタイプも作ります。絵に描いた餅みたいな提案書ではなく、動くものがあるかどうかの方が重要です。
例えば以下は、最近私が感動したCloudSignというサービスのAPIをプロトタイプドライバー化した記事です。
もちろん、なんだこのAPI設計は!? こんな認証ありえねー、みたいに愚痴愚痴も言います。それだけひたすら様々なAPIを見て、食らってます。でも、それもまた裏にいるエンジニアの設計思想みたいなものが見えて、楽しいものです。
Driver 開発はJavaと.NETがメインですが、サポートだと顧客はPHPを使っていたり、Pythonを使っていたり、Powershellでやっていたり、ツールから接続したりと、なんでもござれなので、なんでもやります。
さらに、CData Driverの接続先サービスも100種類以上あるので、都度新しい技術に挑む必要があります。もちろん、そのDriverそれぞれにメインの開発担当者が居るので、その人と二人三脚しながら、問題を解決していきます。
Accessで検証したかと思えば、次の日にはBigQueryを触り、Salesforceを触ったかと思えば、freeeやKintoneの接続検証をしたり、LinuxでSparkを立てたり、得意なDynamics 365をやったりと、日々てんてこ舞いです。
ただ、基本的にはそのAPI・インターフェースの部分を中心に扱うので、その製品のプロフェッショナルになるというわけではないです。もちろん、そのAPIの仕様や用途を正しく把握するために、その製品の特徴は把握しておかないと、うまくサポートはできないので日々学ぶことがつきません。
それにUSや中国の技術メンバーは本当に技術力が高く、Driverの中でも認証やテクノロジーカットのビルド、ネットワーク周り等の根幹部分は本当に勉強になります。(そもそも元がそういったレイヤーに強い会社なので)
その他よかったこと
その他、細々とよかったことも。やっぱり会社が仙台にある分、通勤や周辺環境はすごくいいです。
家から会社まで自転車で20分(地下鉄でもそのぐらい)ですし、地下鉄でも東京のような満員電車はありません。
自然も近いので、パラグライダーをやりに行ったり。
あと、リモートワークに寛容的です。そもそも、日本がアメリカのリモートワークみたいなところがあるし、開発拠点も中国・アルバニアにあるので、それを踏まえるとハワイで仕事をしていても咎められないかもしれません。(CTOは1人でコロンビアに居ます)
大変なところ
大変なところは、とにかく触れる技術の幅が広い! そして、製品のアップデートや修正がとにかく多い・速い! 日々キャッチアップ・検証・コミットログのチェックに終われます。
あと、やっぱり英語でのコミュニケーションは大変ですね・・・。こればっかしは私の問題ですが。ただ、USやアルバニアとのやり取りは基本メールベースなので、Google先生と二人三脚で頑張ってます。
そして、1年に1回はUSに行く感じです。肉を死ぬほど食わされます。ヒアリングをもっと鍛えないとだめです。
というわけで
そんな会社に転職して、四苦八苦しながらも楽しくやっております。
そして、CData Software Japanでは、日本のメンバーを募集中です! APIが好きな人、いろんなテクノロジーに触れたい人、是非ご連絡ください!