2020年3月、エス・エム・エスの開発チームではリモートワークへの移行に伴い、iPadアプリのリモート実機QA環境を構築しました。 限られた期間のなかで、MDM（Mobile Device Management: モバイル端末管理）選定から社内承認、端末の確保、iPadの設定、ポリシーの確認までスピーディーに進行。プロダクト開発部のリモートワーク開始前日には、安全に自宅から実機での検証をできる環境が整いました。 本記事では、リモートでの実機QA環境を構築するまでの経緯や背景にあるエス・エム・エスのカルチャーについて、取り組みの中心となったプロダクト開発部エンジニアの清水智徳さん、神谷典孝さんに話を聞きました。 リモートワークへの移行、新たなMDMの導入を即日決定 これまでプロダクト開発部では、iPadアプリの実機検証を行う際、社内ネットワークを経由して検証環境に接続していました。 しかし、
医療、介護、ヘルスケア、シニアライフの領域で高齢社会に適した情報インフラを構築している株式会社エス・エム・エスでエンジニアをしている @moro です。 主に介護領域におけるキャリア分野のサービス、平たく言えば介護の担い手である従事者の方の就職・転職を良いものにするための事業に携わっており、特に カイゴジョブという求人サービスの開発・運用をしています。 カイゴジョブについて カイゴジョブは 2004 年にオープンした、介護職向け求人情報サービスです。 2019年9月にフルリニューアルし、現在は Ruby on Rails で動いています。筆者は2018年にエス・エム・エスに転職してこのリニューアルに関わり、以来ずっとカイゴジョブの開発・改善を続けています。 現代のソフトウェアサービスでは、リリースしたら完了でそのあとは変更しない、というものは少なく、多くは継続的に変化し続けます。これは、サ
2020年11月にエス・エム・エスに入社した福嶋です。これまでに国内大手ソフトウェア企業でのシステム開発や、約200万人のユーザーが利用するWebサービスの開発などを経験してきました。 今回は、私がエス・エム・エスに転職を決めた経緯や、現在の仕事内容、今後目指したいことについてお伝えしてみたいと思います。 ユーザーと共にサービス開発に従事する楽しさ 「長いエンジニア人生をどのように過ごすか」 これはエンジニアであれば誰もが考えることではないでしょうか。定年を60才と考えると、エンジニア人生の半分を過ぎたとき、私はどう残りのエンジニア人生を過ごすかを考え、転職を決断しました。この決断に至るまでの流れを少し振り返ってみます。 私のエンジニアとしてのキャリアは、大学卒業後に国内ソフトウェア開発会社に入社し、パッケージ製品の設計・開発に携わることから始まりました。その後、転職してグループウェアサー
@sunaot です。『「継続性アーキテクト」という生き方』や『アーキテクトを目指すエンジニアの最短ルート』が興味を持ってもらえたので、この記事ではアーキテクトの仕事の重要な一部だと考えている「ビジネスの構造をアーキテクチャで表現する」ということについて書いてみます。 ビジネスの構造と書いてしまうと、業務のモデリングの話かなと思われるかもしれません。実際、設計手法について書かれている書籍では業務のモデリングの話が中心です。その時代の前提は、要求を持っている人としてのユーザーがいて、業務があって、そのシステム化をしていくというものでした。現在、サービス開発をしていくという中で直面している仕事はやや性質が変化していると感じています。正解となるサービスの姿というものはなく、やっているビジネスの状況やユーザーの関心も変化する中でサービス開発をし、サービス自身も変化をしていきます。サービス開発年代の
はじめまして。エス・エム・エスで、エンジニアリングマネージャーとして働く岩田です。 エス・エム・エスは従業員が2千人近い企業であり、組織も整っている、安定した大企業というイメージを持つ人もいるかもしれません。 しかし、私の担当するクラウド型の介護事業者向け経営支援サービス「カイポケ」の開発組織は、まだまだ成長途中。土台を整えていくフェーズだからこその面白さを感じています。 この記事では、私がエス・エム・エスに入社を決めた理由や、組織改善の取り組みについてお伝えしていきます。エス・エム・エスの魅力が少しでも伝われば嬉しいです。 組織開発の力を試せる、成長できる“カオス”を求めて 私は、もともと技術やコンピュータに関心があり、大学も情報系の学科を専攻。卒業後はエンジニアとしてシステムやWebサービスの開発に携わってきました。 組織開発に関心を寄せるようになったのは、前職のメガベンチャーでの経験
みなさん、こんにちは。介護経営支援開発グループでグループ長をしている岩田文彦です。 事業やサービスの成長に合わせて開発組織も大きくなると、新しい課題が浮かび上がってくることがあります。とくに、複数のチームに分かれて開発を進めていると、各チームで最善を尽くしていても、サービスやプロダクト全体で取り組む課題や舵取りが必要になってきます。サービス全体の技術的な課題にトップダウンで取り組んでしまうと、現場のエンジニアに、コミュニケーションの乖離やモチベーションの低下が生じがちになります。 そこで、私たちは、複数の開発チームの横断的な課題を対象にして意思決定する「プロダクトボード」という活動を始めました。この活動により、規模の大きなサービス開発でありながら、現場のエンジニアも参加しつつ、プロダクト全体を舵取りできるよう体制を整えようとしています。 エンジニアリングマネージャーの方や、一定規模の大きな
エス・エム・エスで、チーム開発の支援を主に担当している西村（@nawoto）です。今回は、チームを支援するうえで心がけている視点について書いてみます。 ソフトウェアとチーム開発について 弊社のようなサービス開発を行なっている会社だけでなく、今は多くの事業においてソフトウェアの存在が不可欠になっています。事業を成長させていくのは簡単でシンプルではありません。そのため、事業に寄りそっていくソフトウェアづくり自体も複雑な課題に対峙することになり、一筋縄ではいきません。 僕は、ソフトウェアづくりには誰かスーパーマンのような人の個人の力で成果を出していくことより、あらゆる局面でたくさんの知恵や能力を活かしていくチーム開発の方が成果を継続的に出しやすいので有効だと思っています。 チーム開発は難しい？ では、複数人で開発を行なっていれば、チーム開発として成立するのでしょうか？ 残念ながらそう簡単ではあり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
