株式会社ウフルを退職します

· Read in about 8 min · (3751 words) ·

先日、在籍する株式会社ウフルに退職願を出してきました。 せっかくなのでこの会社で得られた色々な経験を記しておきます。

得られた経験

Salesforce

ウフルは今でこそ IoT を打ち出していますが、元来 Salesforce.com (SFDC, 以下 Salesforce) 導入・インテグレーションで成長してきた経緯があり、今なおビジネスの多くが Salesforce 関連です。 そして、私にとってもクラウドエンジニアとして活躍する以上、理解しておきたい SaaS の一つでした。

主に私が携わったのは、Salesforce の代名詞 CRM の中核である Sales Cloud のほか、コンタクトセンターを提供する Service Cloud、顧客コミュニティ構築の Community Cloud, 分析・ビジュアライズの Analytics Cloud といった製品の導入・カスタマイズでした (その他、Marketing Cloud や Pardot 等にも少しだけ絡みました)。 Salesforce の強みはなんといっても顧客が必要とする価値を素早く、本当に素早く提供できることです。洗練された標準構成と豊富な設定項目に加え、Apex や Visualforce を用いた柔軟なカスタマイズが可能で、スクラッチでは半年から一年ぐらい掛かりそうな要件でも Salesforce であれば2ヶ月3ヶ月といった超短納期で対応できることがあります (それ以上かかるような派手なカスタマイズは、むしろしないほうが良いかもしれません、ていうか、止めて欲しい 笑)。 ウフルにはこの Salesforce の導入を数えきれないほど手がけた精鋭のエンジニアが揃っており、未経験で入社した私を先輩達が強力にアシストしてくれました。また、日本システムデザインやソシオネットといったパートナー企業から派遣されるエンジニアやプロジェクトマネージャー、そしてフリーランス勢も層が厚くスキルフルで、プロジェクトの成功をとても強力に支えています。

一方で、Salesforce が打ち出している最新 UI である Lightning Experience に関しては、入社当時は周囲にキャッチアップしている人も少なく、新参で Lightning ネイティブ世代な私としては自力で打開するしかなく苦労することもありました。しかしこれは移行期ならではの一時的な問題で、今では徐々に解消されてきているかと思います。

Heroku

Salesforce が買収し、そしてウフルがクラウドインテグレーションの手段として多く採用しているアプリケーション開発プラットフォームが Heroku です。 元は Rails をサクッと動かせるサービスでしたが、今では様々な言語・フレームワークをサポートする柔軟な PaaS となっています。 また、Heroku の魅力として容易にインテグレートできるアドオンの充実も挙げられます。Postgres, Redis, Kafka といった公式のマネージドサービスはもちろん、Fastly (CDN), Cloudinary (メディア処理), Auth0 (認証認可), mLab (NoSQL), CloudAMQP (メッセージキュー) といった 3rd party サービスを駆使したスケーラブルで高付加価値・高信頼な機能を素早く顧客へ提供することができます。

私はこの Heroku を用いて実際に Node.js, Java (Kotlin), そして Go で開発を行いました。特に Go との親和性は強力で、GAE/Go で強いられる厳しい制約とは対照的な、最新バージョンが使えて様々なビルドシステムが使える Heroku の Go 対応力には惚れ惚れしました。 とはいえ、実際の案件で Go が採用できるケースはかなり限られていて、エンジニアが私一人の極小案件でしか採用できなかったのは残念でした。会社としては Node.js と Java が大勢を占めています。

Heroku のもう一つの魅力として、GitHub からの自動デプロイや Slack 連携など、DevOps のレベルを容易に引き上げることができることも挙げられます。ウフルでは GitHub も Slack も組織的に採用しているため、こうしたプラットフォームを最大限に活用した開発サイクルを回すことができました。

AWS, Azure, GCP

クラウドインテグレーションのエンジニアを自称する以上、3大クラウドの経験は外せません。 ウフルでは AWS, Microsoft, Google 全方位対応しており、最も結びつきが強いのが AWS です。 残念ながら社内の実案件では IaaS (EC2) の採用例が多く、AWS が誇る高度なマネージドサービスをフルに活用できているとは言い難い状況ですが、それでも実案件で多数採用しておりリアルなクラウドの経験の手応えは得られました。

Azure に関しては、会社としては実案件もありましたが私自身が携わることはありませんでした。しかし日本マイクロソフトの様々な方と前職以上に接点が生まれ、特に牛尾さん (@sandayuu) から Kubernetes や DevOps のレクチャーを受けることができた事はとてもエキサイティングでした。

GCP に関しては、GAE や BigQuery を駆使した案件に携わることができました。私にとっては初の GCP 実務経験が得られた場でもあり、またそもそもウフルで GCP の経験が得られると思っていなかったので、これはとても刺激になりました。 GCP 案件に参画する上でとても為になったことは Google Cloud OnBoard というイベントへの参加でした。Google のスペシャリスト達が GCP における最適なアーキテクチャ・技術選択をレクチャーしてくれるため、実案件にダイレクトに効くイベントとなりました。書籍「Google Cloud Platform エンタープライズ設計ガイド」などでも語られていますが、GCP は AWS とはカルチャーが異なり、特にソフトウェアエンジニアにフレンドリーな設計思想が特徴です。個人的にも今後ファーストチョイスにしていきたいプラットフォームと感じています。

ARM Pelion IoT Platform

ウフルは IoT ビジネスを猛プッシュしている次第ですが、中でも英 ARM 社のパートナーとなっていることは強力な武器の一つです。 その ARM が打ち出しているクラウドサービスが Pelion IoT Platform なわけですが、このインテグレーションにも携わることができました。 最初携わった当時は Mbed Cloud という名前だったのですが、その名の通り組み込みプロトタイピング基盤である mbed と親和性の高いマネジメント機能が備わっています (現在の名前は Pelion Device Management Services)。 特にセキュリティ機能に関しては徹底されており、証明書のライフサイクル管理やハードとの連携では AWS IoT を上回るといっても良いぐらいです。 肝心のデータ利活用に関しては (プラットフォームとしては) 大穴が空いている感じでしたが、 Tresure Data を買収し Pelion に統合したことでそうした穴もすぐに埋まり、それどころかセールスポイントになっています。

enebular

ウフルが自社プロダクトとして開発・提供している IoT オーケストレーションサービスが enebular (エネブラー) です。 enebular はビジュアルプログラミングツールである Node-RED のホスティングと様々なプラットフォームへのデプロイ機能を提供しており、IoT サービスやゲートウェイのラピッドプロトタイピングが可能です。 enebular を紹介するとついついスクショ映え?する Node-RED 部分に目が行っていまいますが、本質はここではなくアセット管理やデプロイメント機能にあると言えるでしょう。オーケストレーションサービスと銘打っているゆえんでもあります。 また ARM mbed デバイスに処理ロジックをデプロイする機能も開発が進んでおり、プロトタイピングの可能性も広がっています。

私はこの開発には絡んでいませんが、顧客へインテグレーションを提供する仕事を担当し、実際に短納期の概念検証 (PoC) を実現することができました。 残念ながらステートフルでフットプリントの大きい Node-RED が前提のプラットフォームではプロダクションレディなマジもんのシステム構築には難がありますが、概念検証などでは大きな時間短縮効果が得られるプラットフォームであることは確かです。 またアセットデプロイ機能などを通じて今後開発基盤の選択肢も広がれば、真の IoT オーケストレーションサービスと胸を張れる時代も来ることでしょう。

アジャイル開発

ウフルではプロダクト開発や準委任契約の案件を中心にアジャイル開発が多く採り入れられています。 採用するプラクティスはスクラムが支配的で、XP 用語などが通じない人も多いぐらいです。 カンバンに関しては色々なものが使われていますが、私が最もよく使ったのは ZenHub です。GitHub と組み合わせて使うサービスなのですが、これが開発サイクルをとても気持ちの良いものに変えてくれました。ただし予算の都合で ZenHub が導入できない案件は GitHub の Issues / Projects で代用していました。 私の担当した案件では、1スプリント (ZenHub / GitHub 上はマイルストーン) はだいたい2週間で、ストーリーポイントについてはあまり考えすぎず見積もった時間 (をフィボナッチ数に寄せた数値) ベースでサクサク付けていくことが多かったです。

ところで前職では一度 VSTS (Visual Studio Team Services) を使い、とても気に入ったのですが、以来縁がありません。ここのところ GitHub との連携機能も強化されているので、今からでもありなんじゃないかなと思ったりもします。

その他

ほかにも色々な経験を得ることができましたが、技術ブログの範疇におさまらないため割愛します。

今後について

この記事を見て採用を検討したいと考えてくれた方、ありがとうございます。 嬉しいことに日頃から多くの企業からお誘いを頂いており、実際にオファー (内定) もいただいたりしたのですが、それらは結局辞退してしまいました。 今後は社会に貢献するやりがいを求めて次のステージへとチャレンジします。

もちろん本ブログは継続していきます。ブログ開設時に掲げた目標である「IoT フルスタックエンジニア」道は 1mm も揺るぎません。むしろここ2年ほどサーバーサイド (特にバックエンド) に寄りすぎていたので、少し組み込み・エッジ寄りに戻らないとと思っているところです。引き続きよろしくお願いします。

Happy Hacking!