JavaScriptツールチェインの統一を目指す「Rome」開発チームが起業、「Rome Tools, Inc.」を立ち上げ 現在、モダンなJavaScript開発環境としては、ESLintに代表される構文チェッカーや、Babelに代表されるJavaScript変換ツール、モジュールを組み合わせるなどのバンドル操作を行うWebpackなど、さまざまなツールを組み合わせる、いわゆるツールチェインを用いるのが一般的となっています。 こうしたなかで、このツールチェインの機能をすべて備えた1つのツールでJavaScriptの開発環境を統一してしまおうというオープンソースのプロジェクト「Rome」が、昨年発表されました。 Romeでは、JavaScriptやTypeScript、JSXなどでの開発において、現時点で以下の領域をカバーする予定です。HTML、CSS、Markdown、JSONなどにも対

こんにちは！CTO の芹澤です。 前回投稿した「エンジニア採用が再びピンチ！ 窮地を脱すべく改善施策の企画会議をしました」という記事ですが、おかげさまで多くの反響をいただけました。 みなさまから寄せられた意見は一部 saiyo-tasukete プロジェクトにも反映させておりますので、引き続きこちらも楽しみにお待ちいただければと思います。 さて、この投稿はそんな saiyo-tasukete プロジェクトに起票された「CTO からの大切なお知らせ」というチケットを元に書いています。 荘厳なチケットタイトルではありますが、お伝えすることは採用目標の具体的な内訳とその根拠についてです。 「採用がピンチです！」とだけお伝えしても、「どれくらい採用するつもりなのか？」とか「退職が相次いでいるのか？」といった点をクリアにしないと、安心してご応募いただくことは難しいかと思います。 なので、今回はその辺

こんにちは！CTO の芹澤です。 突然ですが、SmartHR社では現在エンジニア採用の進捗が非常に悪く、本記事の執筆時点で目標達成率9.3%という状況です。いわゆる、ピンチです。 どうしてこんなことになってしまったのか...人事グループの方々とここ最近の採用関連の数値を分析したところ、採用の母集団形成がうまくいっておらず、特に「自己応募数」の減少が深刻なことがわかりました。 採用をオープンしているにも関わらず自己応募が減少している。多くの場合、これはエンジニアの採用ブランディングがうまくいっていないことが要因としてあげられます。 過去の施策とその功罪 思い返せばこのエンジニアの採用ブランディングとは、長い付き合いになります。 2018年にも約半年間エンジニア採用ができず、真剣に採用ブランディングと向き合った時期がありました。チーム一丸で認知獲得施策を捻り出し、「エンジニア歓迎会の練習会」や

おつかれさまです。プロダクトデザイングループのこぎそ（@kgsi）です。みんなのデザインシステムことSmartHR Design Systemプロジェクトの一環として、より良い文書を書くための校正ルール「textlint（テキストリント）」のSmartHR用ルールプリセットをオープンソースで公開しました！ SmartHR用ルールプリセット公開の背景 SmartHRのバリューには「一語一句に手間ひまかける」と、SmartHR Design Systemのデザイン原則の中でも「言葉からはじまるデザイン」と表されていますが、改めて、SmartHRは「言葉」をとても大切にしている会社ですよね。 UXライティングチームを中心に、日々文言ガイドラインが整備され、SmartHRの扱う言葉は進化しています。整備対象は各部署共通で使う文言から、ヘルプページ、プロダクトで使う文言まで多岐にわたっています。 ▲

今年の春ぐらいから独学でデザインを練習し始めたのだが、そもそもやり始めた自分のモチベーションと、実際やってみて「こういうところがフロントエンドエンジニアとしての業務にも活きそう！」と感じたことを言語化しようと思う。 ここで言う"デザイン"とは何かはじめに、デザインと一口に言っても主語が大きいので、イメージがずれないよう具体的に述べると、いわゆるUXの5段階モデルの「表層」と「骨格」をイメージしている。 具体的なDoで言うと「実装者がUIを作る時の指針となる成果物としてのデザインを作ること」、もっとざっくり言うとFigmaなりSketchなりで本番でも使われるデザインを作ること。 思うに構造より上のレイヤーの"デザイン"はプロダクト開発に携わる人なら普段からある程度やっているのではないかと思う(もちろんかける時間の比重はデザイナーやPdMというロールを持っている人の方が多い)。 個人的にそも

社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて

2020年11月20日、DeNA主催のゲームクリエイター向け座談会「Game Developers Meeting」において、現在開発中のオンラインアクションRPG『BLUE PROTOCOL』に関する勉強会が行われました。この記事では、登壇したバンダイナムコスタジオのリードAIプログラマである長谷洋平氏の話をまとめることで同ゲームのAIフィロソフィーとその仕組みを明らかにします。 『BLUE PROTOCOL』の概要とAIアーキテクチャ『BLUE PROTOCOL』とは、バンダイナムコスタジオが開発するPC向けオンラインアクションRPGです。同ゲームの最大の特徴は、「操作できる劇場アニメ」をコンセプトとした美麗なアニメーション描写にあります。また、パーティ同士のバトルも魅力のひとつとなっています。こうした同ゲームは2020年4月にクローズドβテスト、同年11月にはマッチング負荷テストを実

年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。 自分がウェブやアプリのエンジニアなのでその文脈で話します。 「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。 プロダクトのあるべき姿と現状を把握する 関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。 1. ア

インターフェイスの操作がユーザー主体でなく、提供側主導になってしまうということについて考えます。 （2019年2月18日発表） ユーザー自身の道具とはどういうことなのかというと、大抵の道具というのはまずユーザー自身が主体的に利用できるようになっているべきだと思います 対して現状としては、提供側がユーザーの行動を主導するという意識が強く出てしまっているデザインが世の中の至るところに蔓延しているように感じます これはこの後ろにある電子レンジです 僕はこの電子レンジをよく使うんですが、最初のころは毎回操作に迷ってスムーズに使えないということがよくありました 物を入れてボタンを押すだけだと思われるかもしれないんですが、実はこの電子レンジは人にとってかなり不自然な操作を要求してきます まずはこのボタンが集まってる部分を見てみて下さい 上の方に「あたため」「解凍」「牛乳」「おにぎり」というようなボタン

こんにちは！ SmartHRのプロダクトサイドでUXライターをやっている、おおつかあぐり（@aguringo）です。開発現場では、UIテキストの作成や デザインシステムの整備 をしています。 以前、こちらでも 豊田聡さんがアジャイルコーチとしてジョインしました！ で紹介させていただいた通り、SmartHRの開発組織はアジャイルコーチの豊田さんにサポートしていただいています。 およそ半年間、豊田さんの助言を受けながら、SmartHRの開発組織はアジャイルの推進を加速させてきました。スクラム勉強会 を実施し、アジャイルやスクラムを概念として理解し、実務ではフィーチャーチーム*1にエンジニア以外のスキルセットを持つメンバーが入っていくという試みも進めています。 今回は、非エンジニアでありながら、スクラム勉強会第2期卒業生*2である私が、豊田さんに興味津々、じっくりとお話を伺いました。 tech.

Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針

調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや

日本時間の3/4の未明に行われたFlutter EngageでFlutter2.0が発表されました。 変更点をまとめていきます。 Web/Windows/MacOS/LinuxのサポートがStableに 元々モバイル向けのクロスプラットフォームであったFlutterは、ベータ機能としてWeb、 Windows、 MacOS、Linuxをサポートしていましたが、 Flutter2.0でこれらのサポートがStableになりました。 従来の「モバイルフレームワーク」から、「ポータブルフレームワーク」へ変わるぞ！と発表されています。 Flutter for WebではWebassemblyとSkiaを使って直接CanvasにUIを描画するCanvasKitが紹介されました。 これは従来のdomを直接操作する方法と比べてパフォーマンスに優れ、モバイル版との差異も少ないレンダリング方法ですが、 Ski

達人プログラマーを読んだせいか、最近よく考えてることでもあるので、この際なのでポエムにしてみた。 受託の会社バイアスはあるかもしれないけど、基本的にコードを書くエンジニアには通ずるところがあるはず。 設計に時間をかける これは、「いきなりエディタに向かってコードを書き始めない」ということ。 フォーマットはなんでもいいけど、 まずどういうものを実装しようとしていて 愚直にやるならこうする それによって既存のコードに影響がないか 過去のコードと一貫しているか 他の要件とぶつからないか etc.. などなど一通り思案して、必要ならメモを書いて、頭の中でコードをイメージする作業を先にやる。 そしてイメージできたものを、ガッとエディタに打ち込んで動くコードにしていく。 もちろん書いてみてはじめて気づく落とし穴もあったりするけど、その時はまたエディタから離れる。 コードを見てコードを治そうとすると、あ

Danti, an artificial intelligence company building a superpower search engine for Earth data, has brought on prominent defensive tech investor Shield Capital as it looks to scale its technology for go

こんにちは、Classiに入社して1年になるGoogle Developers Expert for Angularのlacolacoです。 今日はClassiに新しく フロントエンドエキスパートチーム を作った話を紹介します。 フロントエンドエキスパートチームとは？ 日本のフロントエンド界隈（？）の方なら、フロントエンドエキスパートチームと聞いて真っ先に思い浮かぶのはサイボウズさんのチームだと思います。 Classiで新たに立ち上げたチームは、名前も含めてサイボウズさんのフロントエンドエキスパートチームをかなり強くインスパイアしています。 そのメンバーであり友人でもあるsakito君にはチームの設計にあたって相談に乗ってもらい、名前をそのまま真似ることも快諾してくれました。この場を借りて改めて感謝です！ speakerdeck.com メンバー構成 2021年1月現在、lacolaco

"CSS Module" が指すもの ２つある 従来のコミュニティベースのもの これのこと。そしてその実装。 現状フロントエンドエンジニアが指すものはだいたいこれ。 Web 標準になりつつあるもの Import Assertions で実現しそうな Synthetic Module としての CSS Module 標準になりそうな所まで来ている。 この２つに関して話がごちゃごちゃになるんで整理する。 コミュニティベースの CSS Module https://github.com/css-modules/css-modules コレ自体は概念的なもの。 その実装 として Webpack の CSS Loader などがある。 なので、一般的に「CSS Module か Styled Component か」みたいな議論ででてくるものの場合、 Webpack の CSS Loader を入れ