Sansan Builders Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

「Go言語でつくるインタプリタ」をRustで実装しました。

はじめに

こんにちは。DSOC 研究開発部 Architect Group Data Direction Teamの有山です。
気温が上がってきて夏っぽくなってきましたね。毎年夏用にTシャツを集めるのが趣味なのですが、今年は個人的にブームが再燃してるGOODENOUGH*1を古着で集めようかなと考えています。

ところで皆さんは普段何の言語を書いていますか? Data Direction Groupでは主にPythonを使用していますが、ある時から四則演算の計算順序やif文の条件分岐はどうして正しく動くのだろうと疑問に思うようになり、実際に正しく動かしているシステムを理解してみたくなりました。色々検討した結果、「Go言語で作るインタプリタ」という本が内容的にも分量的にもちょうどよく、これを読み進めることにしました。

初めは読みながらコードを写経していましたが、複雑なロジックについては理解した気になってしまっていたので、いい機会と思いGo以外の言語でちょうど気になっていたRustで移植してみました。今回はインタプリタの実装や、Rustで実装する上でのポイントついて紹介していこうと思います。

*1:日本のストリートブランドで藤原氏がデザイナーを務めた。2017年で活動終了している。

続きを読む

GCP の Error Reporting に飛ぶエラーを Slack に通知したい

DSOC サービス開発部のエンジニアの小山です。

私のチームでは GCP を使っており、GCP の Error Reporting というエラーを収集してくれるサービスでアプリケーションで発生したエラーを確認しています。

Error Reporting

ですが、この Error Reporting は現時点では Slack に直接通知する方法はなく、メールでの通知か mobile アプリへの通知しかありません。(Notifications, Cloud Console Mobile App)

メールを Slack に通知する方法もありますが、それだと Slack に通知されるまで数分のラグがあり、エラー通知としては微妙です。 メール通知や mobile アプリへの通知自体もそれはそれで便利なのですが、 業務中はやはり Slack に通知が飛んでくるのが一番気づきやすいですし、そのままチームメンバーとのやり取りもできるので便利です。

そこで、いくつかの案を検討し Slack へのエラー通知を実装しました。

続きを読む

日本のエンジニアリングを世界へ - Builders Box

CTO の 藤倉 です。

このたび、「日本のエンジニアリングが世界中で活躍できる未来をつくる」というコンセプトのもと、Builders Box というプロジェクトを立ち上げました。

buildersbox-online.com

いまや、ソフトウェアサービスは世界中いたる所で開発され、日常の生活や仕事の場面で広く使われています。Google や Facebook、Amazon、Uber Eats など、海外で開発された多くのものが、日本国内で使われています。一方で、世界中の人々に使われている日本のサービスというのは、まだそう多くはありません。

私は、自分が作ったプロダクトをもっともっと多くの方に使ってもらいたいと思います。

日本国内だけでなく、世界中で使われるサービスを開発することは、エンジニアにとってとても刺激的な仕事です。せっかくエンジニアになったからには、そういうものづくりがしたい。ひいては、日本でつくられたたくさんのサービスが世界中で使われる世の中になってほしい。Builders Box を立ち上げたのは、そんな想いからです。

アメリカでの体験

私は前職時代に、アメリカで数年間働いていたことがあります。アメリカの生活では、毎日のように車や家電など日本のハードウェア製品を見かけます。日本製のものはとても人気があるようで、日本人として少なからず誇らしい気持ちにもなりました。しかしながら、日本のソフトウェアプロダクトを見ることはほとんどありません。アメリカ発のソフトウェアサービスはすごいなぁと思う一方で、もう少し日本のサービスが使われるようになってもいいのではないかと感じていました。

その後、日本に帰国し、Sansan 株式会社に入社しました。

日本のエンジニアリングを強くしたい

Sansan では、世界の市場で成果を出すべく、エンジニアが一丸となって日々開発に向き合っています。その過程で得た知見を還元していこうと Sansan 社内のエンジニアが情報を発信する場を作ってきました。各種勉強会の主催や年次の技術カンファレンスの開催、このブログもその取り組みの一つです。この活動を通じて社内外の多くのエンジニアと接して、日本のエンジニアリング全体はもっと盛り上がれるし、そこでやれることもたくさんあると感じるようになりました。

それを形にしたのが Builders Box です。

国内外のエンジニアや有識者へのインタビュー、様々な技術情報から得られる世界で活躍するためのヒントを届けたり、イベント等を通じた学習機会の提供を継続的に行っていきます。

日本のソフトウェアエンジニアリング全体を応援し、一つでも多くの日本のサービスがグローバルで使われる未来。それに貢献できればと思っています。



buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com

Eight フロントエンド、Prettier 入りました

こんにちは。Eight でフロントエンドエンジニアをしている鳥山(@pvcresin)です。
最近は、Beat Saber という VR リズムゲームにハマっています。 音楽に合わせて、手に持ったライトセーバー的なものでブロックを切っていくゲームで、いい運動になっています。
さて、今回は Eight の Web フロントエンドにコードの整形ツールである Prettier を導入した話をしたいと思います。

Prettier とは

Prettierは Node.js 上で動く、コードのフォーマッター、整形ツールです。 ルールを設定することで、リポジトリ内のコードのスタイルを統一することができます。
Prettier にはデフォルトの設定があるので、細かな設定をしなくてもいい感じに整形してくれるのが良いところです。
HTML や CSS、JavaScript、Markdown などの形式に対応しています。
また、プラグインを入れることで Java や PHP、Ruby なども整形することが可能です。
今回は JavaScript のファイルに Prettier を適用してみました。

続きを読む

2020年卒の DSOC 研究開発部 の新卒研修を実施しました!

DSOC 研究員の吉村です。在宅勤務が続いているので、今更ながらいくつか家具を追加しました。その結果、家の中がかなりスッキリして、生活しやすくなりました。

さて、本題ですが、2020 年卒で DSOC 研究開発部配属になった新卒社員に対して部内で研修を設計し、実施しましたのでこの話について書いておこうと思います。

はじめに

DSOC 研究開発部 の新卒研修の設計については、組織デザインに関する施策を考えるためのタスクフォースチーム*1で議論をして進めました。

当初は「そもそも新卒研修が本当に必要かどうか?*2」というレベルから考え始めました。しかし、本当に新卒研修をやるべきか否かでいくと、内容如何に依るという結論になったので、まずはやってみようということで、実施する方向で話を進めました*3。新卒研修を実施する方向で固まった次には、新卒研修を行う目的について議論しました。

*1:弊社研究員は様々なバックグラウンドを持っているので、シナジーを生むためにどういう組織にしていくかを考え施策を打つチーム。

*2:DSOC 研究開発部に配属になる新卒は19卒まで最大でも2人だったので、これまでは部署での新卒研修というものは行っておらず、メンターが実際の業務をする際に十分にフォローするという運用でした。ちなみに、全社での新卒研修は毎年実施されています。

*3:このあたりの意思決定の裏には、弊社の Values である 「変化を恐れず、挑戦していく」などがあります。

続きを読む

お仕事紹介:Eightのアーキテクト

こんにちは、Eightのアーキテクトの大熊です。最近は家にいる時間が長いのでVRゲームにハマっています。直近やっていたのは「Journey of the Gods」です。

今回はEightのアーキテクトって何やってるの?という話をします。といっても、一言でまとめればQCDの改善です。良いものを効率良く早く世の中に出す、そのレベルを上げていくことが責務です。

解釈次第ではいろいろなことがQCD改善とも言えますが、私が特にフォーカスしているのは次の4つの領域です。

  • 概念設計
  • QA
  • 中長期の技術課題の解消
  • バックログ管理プロセスの設計

一つひとつ見ていきます。

続きを読む

ひよこで変えるチームの働き方

こんにちは。Eightでデザイナーをしている三松です。
もう少し詳しく説明すると、PM(プロジェクトマネージャー)と組んでプロダクトの様々な施策のUI/UXデザインを担当しています。
今回はチーム内から出た働き方の問題点を、ある方法で解消したお話をしようと思います。

Backlogをまとめたはいいけど…

これからやる施策はまとめてスプレッドシートに記入し、Backlogとして活用しています。
そこにデザインのURLや、工数、担当者、諸々のチェック項目などを記入し、ひと目でその施策の状態がわかるような状態にしていた…のですが、ある時エンジニアの方からこんな意見が。

いつも施策の進捗が分かりづらく、いきなり開発に着手するように感じ、心理的負担がある。

なるほど。
では、明確にわかるように共有しよう!ということで施策のデザインがどんな状態を明記する列を増やしました。

整理はこうです。

  • Planning 未着手
  • Refining デザイン、仕様考え中
  • Dev. Ready 開発OK
  • Developing 開発中
  • Done リリース

この運用で施策を進めていたのですが、ある時またエンジニアの方からこんな意見が。

Dev. Readyの状態だったから開発着手したのに手戻りが多い。
Dev. Readyが自分の期待していた状態ではない

そうなのか!
私はDev. Readyの状態を「仕様は決定し、開発はできる状態だが文言等は変更できる」と認識していたのですが、エンジニアは「仕様も文言も全て揃って完璧な状態」という認識だったのです。

ひよこ、じゃないか

これはまずい、各ステータスの共通認識を合わせよう!という話の中で浮かんできたのが「ひよこ🐥」でした。
ステータスを英語で表記するよりも、絵文字のひよこでステータス状況を表し、その状態の認識をみんなで合わせました。

整理はこうです。

f:id:sansanmimatsu:20200608192428j:plain
施策の状況をひよこで表す図

殺伐としたスプレッドシートに現れたひよこの大軍

ステータスをひよこにしてから、認識の齟齬がなくなり、「これ殻外せる?」「出荷するぞ!」「やっとひよこにできるね!」などチーム内の共通言語となり、コミュニケーションの活性化に一役かってくれる結果となりました。
単純な解決方法ではありますが、これで一年ほどスムーズにBacklog運用できています。


ひよこの良かった点をまとめると

  • 絵文字だとスプレッドシートで使用でき、色がついていると目立って視認性が向上した。
  • 完全に新規のツールを持ち込むことにより、強制的にチーム全体での共通認識を合わせられた。
  • ひよこの絵文字が4種類しかなく、そこまで細分化できなかったが、結果として記憶コスト・記載コスト削減できた。
  • 単純にひよこがかわいい。

です。いいこと尽くめですね🐥
働く上でのいろんな問題は、新しい技術やサービスでなく、もっと簡単な方法で解決できるのかもしれません。
ひよこ運用がそんな一例として心にとめてもらえたら嬉しいです。



buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com

© Sansan, Inc.