こんにちは。スタメンエンジニアの松川です。 今回は、前回、市川の方からスタメンの開発コンセプトにあげられた ・ツールやライブラリをちゃんと使いこなす に着目したいと思います。 前回、紹介があった通り、スタメンではアプリケーションフレームワークとして、Ruby on Railsをメインに使用しています。 スタメンでは、「少ない人数で いかに(ラクをして)サービスの開発に注力するか」という観点の元、ライブラリとして複数のgemを活用して開発を行なっています。 gem gemとは、サードパーティ製のライブラリのことです。日本語では"宝石"を意味しており、数々の宝石のように優れたオープンソースのライブラリがこの世には存在しています。 主に活用しているgem スタメンでは、様々な場面でお世話になっているgemがあります。ログイン、非同期処理、Modelの状態遷移、decoratorなど自分達で実装するのは、実装工数が多く、共通化されたgemを使用すると恩恵が生まれやすい部分に活用しています。 ログイン部分では、Railsでログイン認証周りの管理を簡単に実装できるメジャーgemであるdevise 非同期処理部分ではdelayed_job、Modelの状態遷移ではaasm、decoratorではdraperをそれぞれ使用しています。 今回は、ログインに使用しているdeviseを取り上げて、ご紹介したいと思います。 https://github.com/plataformatec/devise deviseに全く触れたことがないという方やdeviseを試しに入れてみたのだけど使い方、全体像がよく分からないという方を対象にしていますので、概略の説明になっています。deviseのモジュールの中身の話については、次回以降、機会があればご紹介出来ればと思います。 devise Railsでログイン認証周りの管理を簡単に実装できるメジャーgem gem ' devise ' スタメンとして、deviseを導入した経緯としては、スタメンが運用しているTUNAGというサービスが、複数の役割を持ったユーザーのログインを想定したプロダクトであったためです。deviseは、wardenというシステムを元にして開発されたgemであり、複数の役割を持ったユーザーのセッション管理を容易にする機能を持っています。 例として、下記のような役割が別れたユーザーのログインを想定したサービスの場合、deviseの力が発揮されます。 ControllerやViewの内部で、 current_user user_signed_in? current_admin_user admin_user_signed_in? のようなhelperメソッドでセッションを複数保持した場合でもログイン状態のユーザーを個別に参照できるため、ログイン管理の煩雑さから解放されます。ログインユーザー個別の情報にアクセスしたい場合でも、 current_user.feeds current_user.reports などのassociationで辿れるため、可読性&安全性が高まります。 構成モジュール 　deviseは、10個のモジュールにより構成されており、それぞれが異なる機能を提供しています。 　それぞれの機能は、Modelに下記のような形で設定することでON、OFFを管理することが可能なため、非常に便利です。 devise :database_authenticatable , :registerable , :recoverable , :rememberable , :trackable , :validatable database_authenticatable(パスワードの暗号化など) registerable(サインイン処理) recoverable(パスワード再設定) rememberable(セッション期間の延長) trackable(サインイン回数やサインイン時間、IPアドレスの記録) validatable(パスワードやメールアドレスの登録検証) confirmable(アカウントの認証) lockable(アカウントのロック) timeoutable(セッションの時間管理) omniauthable(外部サービス認証) 　deviseをフルに活用すると、下の図のような登録フローやパスワードの再設定フロー、アカウントのロック機能などを実装することが可能です。例えば、パスワード認証を許可せずに外部サービス認証のみ許可するということもdeviseを使用することで可能となります。 ログイン管理をしたいModel(User、Customer etc)が決定したら、 rails generate devise User 上記のコマンドによって、deviseの認証に使用するmodelとDBのカラム(migrationファイル)が自動生成されます。 # == Schema Information # # Table name: users # # id :integer not null, primary key # email :string(255) default(""), not null # encrypted_password :string(255) default(""), not null # reset_password_token :string(255) # reset_password_sent_at :datetime # remember_created_at :datetime # sign_in_count :integer default(0), not null # current_sign_in_at :datetime # last_sign_in_at :datetime # current_sign_in_ip :string(255) # last_sign_in_ip :string(255) # created_at :datetime not null # updated_at :datetime not null # class User < ApplicationRecord devise :database_authenticatable , :registerable , :recoverable , :rememberable , :trackable , :validatable end devise :database_authenticatable , :registerable , :recoverable , :rememberable , :trackable , :validatable の表記で活用する機能の取捨選択が可能となります。ただし、導入する機能によっては、新たにカラムを追加する必要があるものやカラムを追加していない場合には、代替のカラムで機能が実現されている可能性があるため、注意してください。 　deviseの実際の実装方法については、公式ドキュメントやqiitaの解説記事に詳細が載っていますので、割愛しますが、deviseの利点は、カスタマイズ性の容易さも挙げられます。認証機能を実現しているDevise::SessionControllerのメソッドをオーバーライドすることにより、ログイン画面で表示させたい情報やログイン後にやっておきたい同期・非同期処理を組み込むことも容易に可能です。 class Users :: SessionsController < Devise :: SessionsController def new super end def create super do |user| # add some process end end end 　また、外部サービスを使用した認証の場合でも上記のControllerに認証アクションをまとめておくことで、コードの見通しも良くなります。 　その他にもdeviseで標準で用意されているメールテンプレートやログイン・パスワード設定画面なども独自にカスタマイズすることが可能なため、基幹部分のロジックを崩すことなくサービスに合わせた形で認証機能を実現することが可能となります。 　この基幹部分を崩すことなく、様々なカスタマイズが可能な点が多くのWebサービスにこのdeviseが採用されている意味だと感じます。 deviseと連携可能なgem 　TUNAGでは使用していませんが、deviseは外部サービスとのOAuth認証のためのgemが数多く公開されています。 TwitterアカウントやFacebookアカウントを使用してサービスにログインさせたい場合でも、公開されているgemを使用してログイン実装することが可能です。 gem ' devise ' gem ' omniauth ' gem ' omniauth-facebook ' gem ' omniauth-twitter ' 終わりに 　今回は、ログイン部分に使用しているgem deviseについて紹介しました。優れたgemを使いこなすことで、サービスの開発効率や品質を向上することが出来ます。その他にも、サービスを開発するにあたり、様々なgemを活用して開発の効率化をしています。 　次回以降、deviseの詳細なモジュールの中身の話や様々な認証方式(SAML認証やOpenID Connect)についても紹介していきたいと思っています。 スタメンでは一緒に働くメンバーも募集しております！是非ご覧ください。 → スタメンの採用情報

こんにちは。　スタメンでエンジニアをしてます 市川 です。 今回はスタメンの開発環境や利用しているツール等を紹介したいと思います。 こんな環境で開発してるんだなぁーと、なんとなくイメージいただれば幸いです。 コンセプト : いかにサービスの開発に注力するか ベンチャーは人手も時間も足りません。　スタメンでは、少ない人数で いかに(ラクをして)サービスの開発に注力するか をコンセプトに、下記のような方針をとっています 便利な外部サービスがあれば積極的に使う サービスの根幹部分についてはしっかり作り込む 自動化出来る部分は進んで自動化して効率化する ツールやライブラリをちゃんと使いこなす 言語、フレームワーク、DBについて プログラミング言語 : Ruby , JavaScript , Swift , Android Java アプリケーションフレームワーク : Ruby on Rails スタメンで開発している TUNAG ( ツナグ ) は Ruby on Rails の 5.1 を利用しています。　Rails は DRY ( Don't Repeat Yourself : 同じ記述を繰り返さない ) 、CoC ( Convention over Configuration : 設定よりも規約 ) という設計思想の通り、開発効率が高く、保守もしやすいです。　その他、ドキュメントや事例が豊富である、大抵のやりたいことは既に gem がある、使っているエンジニアも多く、採用や教育に困らない等々、スピード感が命のベンチャーでの採用事例が多いのも納得です。 また、TUNAG は Web アプリの他に、iOS と Android のアプリもあり、それぞれ Swift , Java を利用して開発を行っています。 スマホアプリについては別の機会に詳しく書かせてもらいますので、どうぞご期待ください。 JS ライブラリ : jQuery, React フロントエンドの JS ライブラリは jQuery と React を利用しています。　TUNAG はタイムラインの機能があり、そこで React を利用しています。 React は学習コストも低く、DOM 操作から解放されるのが一番のメリットだと感じています。 Rails と React の連携ですが、あまり良い話を聞かない webpacker は使わず、素の webpack + babel でトランスパイルした JS を Rails の assets の中に書き出し、 react-rails を利用してERB 内に React のコンポーネントを配置しています。　下記のようなイメージです。 app ∟ assets ∟ javascripts ∟ webpack ∟ app.js ( webpack + babel でトランスパイルすると、こいつができる ) frontend ( React 用に追加したディレクトリ ) ∟ react node_modules src ∟ ここに React のコンポーネント群配置 package.json webpack.config.js 個人的には Rails の sprockets を捨てて、全部 webpack でやるようにしたいなと思う今日この頃です。 デザインテンプレート : Bootstrap デザインテンプレートについては、管理画面のみ Bootstrap を利用し、エンジニアでもそれっぽい画面を自作できるようにしています。　ユーザー向けの画面はデザイナーが SCSS で作成したテンプレートを Rails に組み込んでいます。 DB : MySQL DB は MySQL の 5.7 を利用しています。ベンチャーで Web アプリを作るとなると PostgreSQL か MySQL のどちらかになるかと思いますが、初期の開発メンバーがより精通して使い慣れているという事から MySQL を利用しています。 NoSQL : Redis Redis はキャッシュ用途で利用しています。　データの永続化を実現したかったので memcached ではなく Redis を採用しました。　また String 以外の型も扱えてソートやランキングなどを実現できるので、今後拡張していきたいと考えています。 サーバー構成について AWS 本番およびステージング環境では AWS を利用しています。　オンプレに比べてクラウドでは、欲しい時に簡単にサーバーのインスタンスを立ち上げる事ができ、スペックが足らなくなった際にも簡単にスケールアップ、スケールアウトできるのがメリットだと感じています。　また、使ったぶんだけの従量課金制なのも良いですね。 簡単ですが TUNAG の現状の AWS 構成図になります。　よくある Web アプリの構成かとは思いますが。。。 現状サーバーは chef で管理しているのですが、今年こそは docker 環境に移行したいと考えています。　その他 RDS for MySQL を Aurora に移行したり等、やりたい事・出来る事はまだまだたくさんあります。 スタメンでは AWS Activate ( スタートアップ支援プログラム )を利用させてもらっています。　一部のアクセラレーターやインキュベーター、VC ファンドとの提携が条件にはなりますが、2年間有効な 15,000 USD ぶんのクレジットを提供してもらえるプログラムで、インフラコストを抑える事ができ、とても助かっています。 エラー監視 : Bugsnag エラーの監視には Bugsnag を利用しています。　GitHub と連携してエラー発生時に Issue を自動で作成したり、Slack と連携して通知をとばす事も出来るのでとても便利です。　Ruby 用に gem が用意されているので導入も簡単です。 開発環境について バージョン管理 : Git リポジトリ : GitHub リポジトリ運用 : GitHub flow CI : circle ci デプロイ : capistrano リポジトリの運用は GitHub flow で行っています。　 GitHub の Issue 毎にブランチを作成し、master へマージする前には Pull Request を作成して必ずレビューを行うようにしています。　master へマージした際は circle ci でテスト ( rspec ) を実行し capistrano が本番環境へデプロイを行うようにしてあります。 開発用 PC : MacBook Pro 開発環境は Mac に Rails の環境一式を構築しています。　テストは rspec での自動テストと個人環境で puma を立ち上げて行う他、AWS 上にステージング環境を用意してあるので、そこへデプロイしての確認も行っています。 開発用 PC は CTO のがんばりにより、最新の MacBook Pro ( 2.8GHz Intel core i7 , 16GB ) が支給されました！！！　マシンのスペックは開発効率に直結するので、ここは譲れないですね。 IDE : RubyMine 開発環境は RubyMine を利用しています。コードのジャンプ機能がとても便利で、gem とかのコードを読むのが捗ります。　年額で ¥10,000- くらいかかりますが、毎日さわるメインツールなので、すぐに元はとれるかと。　現状、エンジニアは皆 RubyMine を使っているので、ペアプロする際も統一されているので便利です。 開発の流れ scrum 開発手法はスクラム開発を採用しています。　スプリントは 2 週間に設定しています。　割り込みが多々発生してスプリントが崩壊したり、見積もりの精度が甘かったり等、改善改善の毎日です。 GitHub Issue 管理 : waffle.io タスクの管理は GitHub の Issue をカンバン方式で管理できる waffle.io を利用しています。　スタメンでは大まかにタスクを下記の 5つに分類しています。 ( GitHub の Issue では label に相当 ) Product Backlog ( いつかやるモノ , プロダクトバックログ ) Next ( 今スプリントでやるモノ , スプリントバックログ ) In Progress ( 今とりかかっているモノ ) Needs Review ( Pull Request でレビュー中のモノ ) Done ( リリースが完了したモノ ) スプリントミーティング時に Product Backlog の中から今スプリントでやるべきタスクを抜き出しNext に移すようにしています。 チャット : Slack チャットツールは slack を利用しています。　シンプルで洗練された UI が使いやすいです。　また、外部サービスとの連携が容易なのも魅力です。　 スタメンでは AWS ( Cloud Watch ) 、Bugsnag 等と連携させ、AWS での障害発生時、TUNAG でのエラー発生時に通知をとばしている他、TUNAG 内で特定のイベントが発生した際に通知をとばしたりもしています。 終わりに 以上、駆け足ですがスタメンでの開発のイメージをお伝えできたのなら幸いです。　今後、エンジニアの人数が増えたり、サービスが成長して行ったりと、環境はどんどん変わっていきますが いかにサービスの開発に注力するか という部分はぶらさず、チャレンジを続けていけたらと思います。 少しでもスタメンに興味を持っていただけましたら、 株式会社スタメンの最新情報 – Wantedly で、スタメンでの仕事をもっとよく知っていただき、ご応募いただければ幸いです！　よろしくお願いします！

こんにちは 株式会社スタメンでCTOをしている小林です。 今回、スタメンのコーポレートサイトがリニューアルされるに伴い、スタメン開発チームのブログを開設しました。ちょうど年末ですし、良い機会なので創業してからの１年半を振り返って見たいと思います。 創業するまでの振り返りは、 CTOと主夫を二人三脚するエンジニアが名古屋で創業するまで を御覧ください。 創業時の計画とミッション 2016年8月の創業時に、自分自身のミッションとして下記と捉えていました。 創業プロダクトのTUNAGを創ること ビジネスモデルを理解し、必要な機能の絞り込みと将来の発展性の予測。 インフラ、アーキテクチャの設計と実現に向けた技術選定。 エンジニアとして、設計、実装、テスト、インフラ構築を行いリリースすること。 エンジニアチームを創ること エンジニアチームのビジョンを考える 採用や育成の方向性の策定 プロジェクトマネジメントとラインマネジメント エンジニアとして経営参加すること 経営の意思決定にエンジニア的な視点を加えること 開発力と営業力の双方を会社の強みにすること 家庭と仕事を両立すること ライフワークバランスの一つのカタチを皆さんに提示すること 仕事について、家庭を言い訳にしないこと 家庭について、仕事を言い訳にしないこと 実際にやってみてどうだったか 創業プロダクトのTUNAGを創ること 創業プロダクトのTUNAGは、エンゲージメント経営を支援することを特徴とした社内SNSです(詳細は こちら を参照)。スタートアップベンチャーは、とにかく構想をカタチにしないと意味がありません。創業CTOの最初の仕事はサービスを作ることです。 創業直後は人も、お金も、時間もかけられません、速く確実に創るために、以下のことを行いました。 ビジネスモデルをCEO加藤とCOO大西とディスカッションして深く理解する。 経営陣が同じゴールとサービスイメージを描けることが大切。 コンセプトを画面や仕様まで具体化し、リリースまでの道のりを描く。 必要な機能と工数を概算して、採用計画とスケジュールを決め、事業計画に反映する。 サービス全体の設計を行い技術選定を行う。 自身にノウハウがあり確実に速くサービスを実現できる技術として、Ruby on Rails と Amazon Web Service を技術の中心に決める。 ひたすらコーディング。同時に細部の仕様を決めていく。 結果、当初想定した創業半年後の2016年2月に最初のリリースを行い、現在に至るまで改良＆運営を続けています。 これまでの SNS や ECサイトを作ってきた経験がサービス全体の設計や技術選定等で大いに活き、全体的なアーキテクチャは当初予定から大きくずれることなく実現し、現在でも拡張し続けています。これまでの各社での経験が各所で活きました。まさに Connecting The Dots で不思議なものです。 ただ、当初約半年(27週間)と見積もった開発規模は、リリース時期こそ見積もり通りとなりましたが、これは結果で、実際には社外の知り合いに助けてもらったり、エンジニアを採用するなどして、開発リソースを当初予定より大幅に増やしたことでやっと間に合ったのでした。 事業は構想段階では抽象的で曖昧で、実装する過程で具体的な仕様にしなければなりません。同時に、仕様を考えたり、作ってみると足らない機能に気づき工数が増えてスケジュールが遅れます。マクロにサービスやスケジュールの全体像を俯瞰しつつ、ミクロにUIや機能を作り込む必要があります。こういうとき、タスクが増え過ぎたり、並列すると生産性が落ちます。やらないこと、忘れても良いことを意図的に決めることをいつも意識しました。 また、30代に入ってからはコーディングする時間よりは、マネジメントする時間が多かったのですが、この１年半はこれまでで一番コードを多く書いた日々でした。コーディングすることの面白さや奥深さを改めて実感し、もっともっとエンジニアとして成長したい(しなければならない)と感じています。プログラマの35歳定年説なんてスタートアップベンチャーには全く存在しません。ガンガンコードを書きましょう。 TUNAG の技術的な詳細や、開発環境、開発プロセス、利用しているツールなど、ここでは書ききれない内容がたくさんあります。今後このブログでご紹介していきたいと思いますので、興味を持っていただけましたら幸いです。 エンジニアチームを創ること スタートアップベンチャーにとって採用は非常に大切なミッションです。どれだけ頑張っても一人で開発できる規模は限界があります。仲間が集まらなければ事業を大きくすることはできません。TUNAG の開発と平行して、開発チームの立ち上げも行いました。 スタメンのエンジニアを採用にするにあたり、下記を重視してきました。 仕事についての価値観 何かしらやり切った経験 エンジニアリングについての熱量 仕事についての価値観は、仕事を通して何をしたいのか、日々仕事をすることをどう捉えているかなど、仕事についての人生観です。 スタメンは毎日終電が続く会社ではありませんが、プロジェクトの終盤などではどうしても忙しくなる時期もあります。また、新しい分野での事業や、未経験の技術を用いた開発では、うまく行かないことも多々あります。だからこそ、創業期のベンチャーでは、何事も積極的に、主体性を持って取り組み、日々の挑戦を楽しむことができることが重要です。 何よりそういう人たちと一緒に仕事することは楽しく、互いに切磋琢磨することで強いチームになります。 また、上記のような価値感はある日突然できるものではないと思っています。子供の頃の体験、学生時代の勉強、アルバイト、部活や、社会人になってからの仕事など、趣味、スポーツ、仕事、何かしらにひたむきに取り組み、成果がでるまでやりきった経験をお持ちの方が多いと思います。面接の場では過去に熱心に取り組んだ経験についてお聞きすることが多かったです。 そして、仕事の価値観がベンチャーに合い、何かしらやりきった経験がある方が、エンジニアとしての仕事に対して熱意やこだわりを持っている場合、本人の成長と会社としての成果が重なって WINｘWIN な関係を築けると考えています。 そんな感じで採用活動を続けた結果、私含めてエンジニア4名、フロントエンジニア兼デザイナ1名の計5名のチームになりました。 開発チームに限りませんが、ピンチを救うように助っ人が登場したり、既存メンバーが急成長して乗り切ったり、まるでバトル系の少年マンガのようにチームが育っていきました。こんな創業直後の小さい会社に飛び込んできてくれた現在のメンバーに感謝するばかりです＆今後もよろしく。 ベンチャーにとって人材は非常に重要です。いい人がいれば良いサービスが生まれますが、良いサービスであっても良い人がいなければ廃れてしまいます。 引き続き採用は最重要なプロジェクトで、来年も積極的に採用していきます。創業期の小さなチームでの仕事はエキサイティングで楽しいだけでなく、非常に濃い成長の機会となります。興味を持っていただきましたらぜひ下記よりご応募ください！！ 名古屋で自社サービスの開発・立ち上げに挑戦したいエンジニアを募集！ ≪名古屋≫ 急成長する HR Techを支えるインフラエンジニアを募集！ エンジニアとして経営参加すること エンジニア的な観点で経営の意思決定に参加すること。と書いてみましたが、これが何を意味するのかを簡潔に書くには自分自身の経験は浅いと感じます。 ただ、自分自身がこうありたいという姿は、過去接してきた尊敬する先輩CTOの方々に重なります。先輩方に共通するのは、会社を運営する際の様々な場面で技術的な観点で組織や事業の将来を語り、意思決定に寄与し、実現に導くリーダーシップと行動力でした。エンジニアとして、経営メンバーとしての全幅の信頼であり、私もそうありたいと思っています。 スタメンの経営理念は「一人でも多くの人に、感動を届け、幸せを広める。」です。 この理念を実現するため、TUNAGを始めとした様々ななサービスを提供していきますが、有望な事業(案)を技術不足を理由に諦めたり、伸ばしきれないことが無いように、強い開発チームを作っていく必要があります。 エンジニアチームの実力が、その会社の事業の上限を決めると思います。スタメンの可能性を広げるためにも、まずは私が先陣を切って、TUNAG の普及に貢献し、エンジニアのロールモデルでありたいと思ってます。 家庭と仕事を両立すること 創業のときに書いた CTOと主夫を二人三脚するエンジニアが名古屋で創業するまで では、下記のように書きました。 ベンチャーでの仕事はハードワークが続きますが、必ずしも深夜残業や休日出勤だけが解決策ではありません。いままでよりも、計画的に、効率的に、これまでの経験を活かして最大限生産性を高めることで成果を出し続けたいと考えています。また、各種クラウドツールの発達により、自宅でできる業務も随分広がってきました。こういったツールを使うことによって、夕方早めに帰宅しても、夜に開発や打ち合わせに参加することもできます。こうやって家庭と成果の最大化を両立することが私のライフワークバランスです。 家庭を妻に任せて一心不乱で仕事することよりも、若さに任せて不眠不休で仕事することもよりも、家庭と仕事を両立しながらベンチャーで成果を出すことは難しいように思えますが、家庭があっての仕事ですし、仕事の先に家庭が崩壊するならば大きな後悔が残ると思います。何よりも、良いエンジニアでありながら、良いパパでいたいですし。 これまでとは違った難しさ、苦労があるかと思いますが、これを乗り切れたら全部ハッピーだと思ってがんばってみたいと思っています。 創業直後は、家庭と仕事の思考の切り替えに苦労したものの、徐々に切り替え＆両立に慣れてきました。これはスタメンに仲間が増えて、信頼して任せられるようになったことが大きいです。いつもありがとう。 想定外としては、スタメンが現在のオフィスに移転し、オフィスにキッチンができてからは、 たまにオフィスで料理 してます。凝り性なので、料理するからには真面目に作るんです。ちゃんと主夫もしてますよ！とアピールする絶好の機会になってます。「小林の料理が食べたい！」という人は、ぜひスタメンに入社してください！ 入社祝いを作ります！ まとめ と これから スタートアップに転職するのと創業に関わるのは違う。創業以来、何度も思いました。 これまで5社のベンチャーで仕事をしてきましたが、前任者が方向性を示したことを拡張していくのと、ゼロから決めるのは違いました。技術選定、仕様策定、チームの立ち上げ、すべてをゼロから始める。真っ白いキャンパスに最初の線を描くような緊張感がありました。 でも、ほんと様々なことについて、これまでの仕事での経験、出会ってきた人々からの教え、スタメンに入ってきてくれた社員の貢献に助けられました。さらに、TUNAG を導入してくださったお客様の皆様には、本当に多くの勇気や学びを頂いています。TUNAG を始めとしたスタメンでの仕事で、頂いたご恩を少しでもお返しできるように、地道に頑張っていきたいと思っています。 最後に、この業界に入ってからずっと目標としていることがあります。それは、IT業界のエンジニアが以下の三冠になることです。 子どもたちが将来なりたい職業。 彼氏/彼女にしたい人の職業。 結婚したい人の職業。 これ本気です。エンジニアには、それぐらい夢も希望も理想もある職業だと思います。世のエンジニアがもっと楽しく、良い仕事をして、世に貢献して、社会から評価されることで、幸せになって欲しいと思います。そのためにも、まずはスタメンのエンジニアがこれを実現できるように、経営者として、エンジニアとして恥じない仕事をしたいと思ってます。 スタメンは、創業してまだたったの1年半です。経営理念の「一人でも多くの人に、感動を届け、幸せを広める。」は、まだまだ全然実現できていません。やりたいこと、やるべきこともたーーくさんあります。もっとたくさんの頼もしい仲間が必要です！ 少しでもスタメンに興味を持っていただけましたら、 株式会社スタメンの最新情報 - Wantedly で、スタメンでの仕事をもっとよく知っていただきご応募いただけないでしょうか！ よろしくお願いします！ というわけで、スタメンのエンジニアブログとして、創業以来の1年半を振り返ってみました。 今後、各メンバーから、様々な記事を書かせていただき、スタメンでのエンジニアライフをご紹介したいと思いますので、今後ともよろしくお願い致します！