月別アーカイブ: 2020年12月

2020年、スタフェスに文化が来た

この記事は、スターフェスティバル Advent Calendar 2020の9日目です。
スターフェスティバルではエンジニアを募集しています。

こんにちは、soriです。おもに法人・団体向けのお弁当の宅配サービス「ごちクル」でご存じの方もいらっしゃるかもしれない、スターフェスティバル株式会社(=略してスタフェス)でエンジニアをしています。
現在はオフィスワーカー向けのランチ予約・お届けをするサービスの開発を主に担当していて、Node.js/TypeScript/Next.jsまわりのコーディングを日々やっています。
(前回のほぼコピペ)

さて、今日はスタフェスのエンジニア部署の環境についてお話させていただきます。
特に、スタフェスのエンジニアに興味がある人だけでなく、過去のスタフェスを知っている方、過去にスタフェスを受けたり調べたりしたもののマッチしなかった方にも、現在の状況を知っていただけたらと思います。

2020/2 @sotarokがjoin

以前元メルカリ社にてCTOとして活躍していた、@sotarok 氏が2020年2月にスタフェスのCTOとしてJOINしました。
このことは、エンジニア部署だけでなく会社全体を巻き込んでの大きな変革のきっかけになりました。

社内コミュニケーションツールがSlackへ全社移行

CTOの主導により、まず社内のコミュニケーションツールの見直しが始まりました。
それまで、スタフェスではSlackはFree Planにてエンジニア部署のみが使用しており、主にアプリケーション連携によるアラートや更新系などのフィード通知にしかか殆ど使っていませんでした。

全社的にはChatWorkが使われており、エンジニア間のコミュニケーションついても当初はChatWorkがメインとなっていました。
ChatWorkはたしかに国産プロダクトであるため、非開発メンバーにとっても一見とっつきやすいと感じる部分もありますが、弊社ではChatworkにおいてコミュニケーションがそれぞれのチャットルームで閉じており、他の部署において何が起きているのかわからない、また情報を拾いに行くことができないという課題がありました。また、そういった状態により健全なコミュニケーションがとりづらいという問題もあります。
もちろんエンジニア部署として、数々のIntegrationを使いたい立場としても、全社的にSlackを使用して諸々できたほうがモチベーションが上がるというのもありました。

2月初頭にSlack移行プロジェクトチームが発足し、その後各部署ごとに色々対応スべき事項はありましたが、6月末には移行プロジェクトがミッションを完了し、全社的にSlackでオープンなコミュニケーションをするための土台が完成しました。

現在でも、部分的にprivateDM問題などもあり継続して対処していかないといけない箇所はありますが、全体的に情報へのアクセス性が良くなり、いい雰囲気へ向かっていると感じます。

そしてコロナ禍がはじまる 〜リモートワークへ〜

Slack移行と時期を近く、日本国内でCOVID-19ウイルスの感染者が増加し、オフィスへの出社が見直される時期となりました。

スタフェスでも、緊急事態宣言頃からリモートワークや時差通勤体制が始まり、働き方がメンバーにより大きく変わりました。
その状況においても、Slack移行ができたのは状況下でも情報共有が大事となっていく中で良かったと思います。
現在では、社内の多くの部署が在宅での勤務が可能となっており、リモートワーク対象者には手当も支給されるようになりました。

また、エンジニア部署においてはいわゆるスーパーフレックスタイム制度での勤務となり、在宅勤務においても勤務時間において融通がきくようになり、効率的に業務を最善のコンディションにて行える環境が整っており、個人的にだいぶ助かっています。
(余談ですが私は埼玉から通勤していましたが、通勤がなくなった影響で仕事の効率が上がったのはもちろん、体を壊さなくなったり、自分の時間を取れるようになり新しい趣味ができたりと良い事ずくめで最of高でした)

プロダクト開発制の採用

また大きく変わった点として、それまでエンジニア部署はおおまかにチーム内で職種別(フロントエンド、バックエンド、インフラなど)に分かれており、各事業部署から上がってくる案件をこなしていくのみの、いわゆる社内にいながらにして社内受託のような状況になっていました。

こちらについてもCTOの主導により、プロジェクトチームを軸とした体制となり、プロダクトマネージャ、マーケティング、運用、デザイナー、エンジニア等それぞれのポジションのメンバーが一体となってサービスの質を高めていける良い循環が発生し始めています。

…しかし、まだ今後のプロダクト開発を進めていくにあたってどうしてもメンバーが足りません!!今年に入ってから勢いのあるメンバーがたくさんJOINしてくれていますが、まだまだスタフェスのプロダクトを動かしてくれるメンバーを必要としています。興味のある方は是非

社内の技術スタックの向上

これまでスタフェスでは、開発環境として主にPHP、CakePHP、Laravel、js、Vuejs(2)を中心とした技術を用いてきました。

PHPやLaravel自体に罪はないのですが、サービス全体として設計や過去の負債を多く抱えている状態の中大きな改善をすすめることができずにいた状況でしたが、今年に入ってからCTOや他の勢いのあるメンバーのJOINによりスタフェス開発をとりまく環境についても大きく変わってきています。技術的な雑談レベルの話も、以前に比べて格段にしやすい環境になっています。(前はしにくかったのかという話ですが、割とそういう部分がありました…)
そのあたりの話についてはスタフェスのnote(この記事とかこの記事)も是非読んでみてください。

GitHubの採用

これまで社内ではStash(Atlassian社のコード管理、いまではBitbucket Serverとなっている)を使っていましたが、GitHubへ多くのプロジェクトを移行しています。

GitHubの強力なインテグレーション、Actionsなどを使うことができるようになったのはもちろんのこと、Contribution(草)に成果を反映することができるようになったのでエンジニアのモチベーションも高くなったと思います。

nodejs/TypeScript/Reactなどのjs系技術の採用

はじめに新規事業のプロダクト「ごちクルNow」にてこれらのjs系の技術を採用し、その後新規で始めていく大きなプロジェクトについても徐々にこれらの技術の採用が始まっており、型レベルでの開発の保証や、テスト駆動開発などの健全で堅牢な開発が多く進められるようになっています。また、新規事業にてスピード感のある開発を進めていく中で、得られたノウハウを他プロジェクトにフィードバックすることもできています。

既存アプリケーションについての改善

新しい技術の採用があるとはいえ、ビジネスを継続していくためには既存のアプリケーションのお世話もしなくてはなりません。先程のnoteの記事にて紹介のあった @ytake氏がJOINし、既存のPHPプロダクトなどの大規模な改善が始まりました。
過去の技術負債についても次々と改善が進んでおり、PHP,js系に限らずインフラを含めた最適な技術選択により、既存メンバーを巻き込んで全体的なブラッシュアップが始まっています。

毎月のWin Session Partyの開催

プロジェクト制での開発を行っていく中で、どうしても他チームでやっていることが普段のやり取りだけではわかりにくいこともあるかもしれませんが、その点についてはスタフェスのエンジニアは月に1度Win Session Partyを開催して、プロジェクトチーム内でのやっていることの共有や、成果を各自褒め合うポジティブな会を設けています。
現状都内を中心に感染症の状況が悪化しているためオンライン開催が中心ですが、状況が良くなったときには定期的にメンバーのリアルでの顔合わせができる機会になると良いと思っています。
各プロジェクトチーム内でもふりかえり会などを実施してチーム内での良いサイクルが回るよう日々努力しています。

最後に

他にもご紹介できることがあったかもしれませんが、一旦思いついたこの辺にて。
まだまだ課題もたくさんあり、楽な仕事と言うことはできませんが、チームでの開発は楽しく、やりがいがあり、確実に良いやりかたに向かっていると感じています。ぜひ、興味を持った方はスタフェスに来てくださいね!

せっかくWFHだしワーケーションしてみた

この記事は、スターフェスティバル Advent Calendar 2020の5日目です。
スターフェスティバルではエンジニアを募集しています。

こんにちは、soriです。そういえば前回のAdvent Calendarの記事は自己紹介をしてませんでした…。おもに法人・団体向けのお弁当の宅配サービス「ごちクル」でご存じの方もいらっしゃるかもしれない、スターフェスティバル株式会社でエンジニアをしています。
現在はオフィスワーカー向けのランチ予約・お届けをするサービスの開発を主に担当していて、Node.js/TypeScript/Next.jsまわりのコーディングを日々やっています。(これ前回のときに説明するべき内容かもしれない…)

弊社ではCOVID-19情勢を受けて、2020年3月から段階的にWFH(Work From Home、いわゆる在宅勤務、リモートワーク、テレワーク)を導入しています。当初は緊急事態宣言の発令など、急遽対応せざるを得なくなったこともあり制度が整っていない点もありましたが、状況の長期化や、WFHによる利点の多さなどもあり徐々に全社的に制度も整ってきています。(なお、感染対策をした上で希望によりオフィスでの勤務しているメンバーも居ます。人によりWFHは合う合わないはあると思いますので、いずれにしても押し付けのない働きやすい環境です)

WFHの具体的な事例についてはまた機会があったらお話するとして、今日はWFHの状況を利用してワーケーションをした話をします。
WFHを初めて、感染者の状況も落ち着きつつあった11月の頭、私は長崎へ5日間のワーケーションを楽しんできました。といっても、日曜・祝日・移動日の休日を利用したので、実質仕事をしたのは2日間です。

宿泊について

朝食のサバサンド
ホテル近くの朝食で食べたサバサンド。

仕事をする場所について、一般的なwebエンジニアがワーケーションするには最低限インターネット及び電源環境が安定している場所が必要かと思います。
基本的には長崎のコワーキングスペースや、電源のあるカフェを当てにしていましたが、それなしにも最低限宿泊地でも仕事ができる場所を探し、結果長崎市内大浦にあるレジデンスタイプのホテル(マンションをリノベーションしたようです)を4泊5日で押さえることにしました。

ホテルは小綺麗なワンルームのような間取りで、小さいキッチン(ガスやIHはなかった)、バストイレ別、洗濯機が備え付けで、まるまる5日間の暮らしには問題ないものでした。簡易なデスクと椅子もあり、短時間のエンジニアリング作業には問題ない感じでした。

ちょっとしたよかった点として、周辺に感じの良いカフェがあり、4回の朝のうち3回はそこで朝食をとりました。長崎ではサバサンドをご当地グルメとして推しているらしく、朝にさっぱりして美味しかったです。

ワーケーション1日目

ワーケーション1日目は旅行自体の2日目です。
移動の初日や最終日は、移動疲れなどもあると思うので休みにしておくのがいいと思います。

旅行先での仕事をしたのは月曜日で、その日は長崎県内で海鮮を食べたいという野望があったので、まず午前中にホテルにて仕事、お昼に移動と朝食、その後カフェで仕事という計画にしました。

午前中については先程書いたとおりで、ホテルの回線状況も問題なく普通に仕事できました。強いて言えばホテルの椅子がIKEA製の固いもので、長時間の作業には向かなそうでしたが、今回は長い時間作業しなかったので問題なかったです。

お昼前ぐらいにレンタカーを借りて移動を開始し、長崎の北部の松浦の道の駅でブリの丼をいただき、海鮮欲を満たせました。その道の駅のご飯のようすは道の駅メモの記事に書いてあるので良かったら見てください。

その後佐世保に移動し、五番街という港湾沿いの商業施設にあるスターバックスの電源席で午後の作業をしました。弊社のエンジニアは勤務時間に自由が効くため、このような移動のときも融通が効いて便利です。

インターネット回線についてはスターバックスのフリーWifiも使えなくもないのですが、セキュリティに安全を期すため、同行者と折半してこの旅行のためにモバイルルーターを借りています。

お昼過ぎから夜19時頃にかけてそこで作業したのですが、景色もよく夜に向かって段々と景色が変わっていく港の景色を見ながらの仕事はとても快適でした。

夕方ぐらいにZoomでのミーティングに参加したのですが、旅行先で仕事をしていると現在の状況をミーティング先に共有したくなるという気付きがありました。なんとなくテンションが上がるもんです。

佐世保での仕事風景。

仕事の後は佐世保のローカルグルメ、佐世保バーガー…ではなくレモンステーキを食べに佐世保のLemond Raymondという有名店に。とにかく普段では食べれない美味しい食べ物を仕事の日でも堪能できるのがワーケーションの醍醐味ですね。

レモンライスというセットを注文。混ぜるとチーズのとろけ具合がやばい。

ワーケーション2日目

また日を改めてワーケーション2日目。この日の前日は祝日だったので、ペンギン水族館を見たり島原半島を巡ったりして楽しみました。ワーケーション2日目は旅行の4日目です。

この日はあまり移動はせず、前もってスペースマーケットで予約していた、コワーキングスペースのHafH Nagasaki Gardenへ。

この施設はHafHという働きながら宿泊ができるサブスクリプションサービスの施設で、この施設についてはドロップイン利用(つまり、コワーキングスペースの日中利用)のみもできるとのことでそれを利用させていただきました。

こちらの施設がとにかく良さみが高く、旅行先の仕事場として最高でした!

ロケーションは長崎の路面電車の諏訪神社前からバスで10分程度、高台にありあちこち移動するには至便とは言えないのですが、高台にあるだけあってとにかく景色がよく、古民家のリノベーションされているスペースで快適、ワーキングスペースには掘りごたつ式にコンセントのある作業スペースと、あと人をダメにするソファ完備で完璧、もちろんインターネット回線スピードについても問題ありませんでした。

コワーキングスペースの部屋内の写真は撮り忘れてしまったので、さきほどのスペースのサイトを見てもらえればと思います。

とにかく外の景色が開けていて良いので、普段パソコンに向かってばかりで目が疲れてしまったときには遠くの景色を見て気分転換なんてこともできます。

ランチなどご飯を食べる場所は近くにないんですが、お昼はまたバスに乗って少し移動して、諏訪神社近くの「カレーの店カルカッタ」というお店でトルコライスをいただきました。

トルコライス。カレーがけができる。カレーがピンク色で面白い

施設の直ぐ側にはファミリーマートもあるので、そこで大体のものは済ませられるでしょう。

先程もちらっと触れましたがこちらの施設は宿泊もでき、聞いたところによると移住して長期滞在している人もいるとのこと。

HafHのサービス施設はわりと全国にあるようなので、次回また機会があれば他の場所でも宿泊も含めてワーケーションに使ってみたいですね。(余談ですが、別の機会で普通に旅行で宿泊した施設も偶然HafHの施設でした、びっくり)

ワーケーションに行って帰ってきて

結論から言うとワーケーション、こういった状況の中自宅にこもってばかりで普段の閉塞感のある環境からがらっと居場所を変えることで、最高のリフレッシュになりました。
今回は5日間の間2日だけ仕事という限られた期間でしたが、次回はまるまる一週間ぐらいどこかでワーケーションしてみたいという気持ちになっています。

遠くに行ってワーケーションしてみるのもいいですが、ちょっと足を伸ばした場所の河原とかで、キャンプ椅子持ち込んで仕事するとかもいいかな、とも思っています(その場合電源が問題になりますが、、)

次回に活かしたい点としては、割とでかけたい場所がいっぱいあるとほぼ観光に時間を割きたくなるので、仕事をするなら環境はきれいで良い場所だけどそこまで魅力的なスポットがないところでもいいのかなと少し思っています。

もちろん、こういった現況ですからわたしたちも、人の混み合った場所に行かない、食事のときはあまり喋らず、喋りたいときは食べ終わってからマスクして話すなど、色々気を使っていました。感染対策には気をつけて、できる状況にある方は楽しんでみるといいかもしれません。

prismic.ioではじめるGraphQLの第1歩

この記事は、スターフェスティバル Advent Calendar 2020の2日目です。
スターフェスティバルではエンジニアを募集しています。

近頃、仕事で扱う技術スタックがPHPからNext.jsやexpress等node.js系へ移行したため、趣味に個人的な学習を兼ねて新たに個人サイトを作ることにしました。
それが以前のブログ記事でも紹介した道の駅メモです。
(こちらは技術的試行を兼ねているのととりあえず要素が強かったためデザインと呼べるレベルの内容をしていないのはご容赦ください…)
技術スタックの移行について詳細はまた後日のAdvent Calenderにて書く予定です。

Next.jsを使うことは決めていましたが、これまで運用していた(このブログが動いている)Wordpressのサーバで共存して動かすのではなく、運用負担などを考え新たにheadless CMSやFaaSを採用することにしました。
こちらで採用しているメインのアプリケーションは以下のようなものです。

  • Headless CMS(記事や画像の管理などを行う)
  • フロントサイド(Headless CMSで取得した内容の表示等を担う)
    • Next.js (React Framework)/TypeScript
    • Vercel (Faas、静的サイトホスティング等)

Prismic.ioでは、はじめにCustom Typesによりタイトル、本文、各種属性、画像フィールドなどを設定しておくと、APIサーバとして動作し各種アプリケーションに対して記事のコンテンツを各種形式にて出力する役割をしてくれます。
なお、現在Community Planで無料で使うことができます。(詳細

REST APIは各種言語にてライブラリが用意されており、簡易な手法でjs系各種フレームワークや、PHP、Ruby、Javaなど各種言語から容易に取得することが可能となっています。

ここで私が着目したのはAPIの出力形式としてGraphQLに対応している点です。
GraphQLはデータベースに対してスキーマを定義しクエリを呼ぶことで、使いたい各種ビジネス要件に対して個別にクエリを発行し、フロントエンドより必要なデータのみを取得することができます。

一般的にREST APIを使用した場合、当初は完璧と思ってAPI設計をしたものの、追加した各種ページで表示したい要件が増え、似たような要件を持つendpointが増えがちということがありますが、そのような場合にとりわけGraphQLはマッチしていると言えるでしょう。

またGraphQLを使った場合、SQLで言うSELECT文に相当するフィールド指定には*(すべてのカラム)のような指定ができないため、意図しないテーブルのデータが流出することをロジックレベルで回避することができるかもしれません。(例えば、APIのレスポンスからIPアドレスなどの情報を意図せず出力してしまうことなど)

具体的な文法などの情報については今回の記事では特に触れませんが(この点に関しては各種先行記事が参考になるでしょう)、GraphQLについて煩雑な構築等を避け手っ取り早く体験するため、このPrismicは大きな助けになると思います。

最初にご紹介したサイトでは、Next.jsからPrismic.ioのGraphQL endpointにクエリを発行し、条件に応じた記事一覧や記事情報を取得するということをしています。(なお、後から知ったことでPrismic.ioのGraphQLではグループフィールドにおいてフィールド指定の検索ができず、都道府県ごとの記事検索には別途REST APIを使っています。この場合はタグを使用したほうが良かったらしい…)

Prismic.ioではGraphQLを使う際に、GraphQL API Explorerを使用してコードに組み込む前にクエリのデバッグもできる点も評価できるでしょう。

node.js環境からGraphQLにアクセスするためのクライアントは apollo-client を使っています。
apollo-clientを導入した場合、強力なコードジェネレータを使うことがNext.js/Typescriptの環境において大きな助けになるでしょう。

まずprismicからAPIによりスキーマファイルを取得した上で、必要なクエリをgraphql-tagライブラリのgql文によりcomponentなどのソースコードに記述し、targetやクエリの場所、スキーマファイルを指定しコードジェネレータを使うと、ソースコードと同階層に__generated__ディレクトリが生成され、クエリのレスポンスに対するTypeScriptの型ファイルが自動生成されます。

特に複雑な定義をせずともクエリ文を書くだけで型定義が着くのはすごく便利と感じられる方が多いのではないでしょうか。

とはいえGraphQLにはパフォーマンスを考慮したりスキーマを正しく設計する点が難しかったり、課題は沢山ありそうで、場合によってはREST APIと並行して運用することが必要だったりするかもしれません。
しかし近頃DB migrationやORMなど、実装に難しさを感じる点などについて新たなパッケージが成熟しつつあるように思えます。

今現在すぐにGraphQLが活かせる状況になくても、近い将来手近に活用するシーンが見えて行きているように感じますので、今のうちにできる事から学んでみるのはいかがでしょうか。

(理解しきれていない箇所や間違いなどあるかもしれません、ぜひコメントなどでご指摘ください)