場と人間の関係性、そしてチームをつくるということについて。 「決める場」 ある事柄に関して、決定権をもっている「場」を指す 例: 取締役会、株主総会、経営会議、... 多数決、あるいは議長による判断、なんらかのルールにそって合意形成をする場 「考える仲間」 ある事柄について同じ目的のためにともに考えてくれる他者を指す 「決める場」の思考 「決める場」の思考は 損得勘定の思考 事柄の必要性、自身への影響 利害関係者としての思考 「考える仲間」の思考 「考える仲間」の思考は 磨き上げの思考 事柄の可能性、目的に対する効果、「よりよさ」の追求 当事者としての思考 話している相手は「考える仲間」か、それとも「決める場」の利害関係者か 利害関係者に対して「よりよくする」ことを一緒に考えてもらおうと思ってもうまくいかない 自身への影響が現実的に想像できるようになるまで賛成も反対も起きない 「決める場」

技術広報ってなんとなく必要そうとは認識してるもののなぜ必要なのかとその成果をどう評価すればいいかわからないもの俺の中でトップ3に入るやつだ / “エンジニアが技術広報に取り組んだ奮闘記 2021年上期 | Money Forward Engineers' Blog” https://t.co/JjsvLRgK9I — Keisuke Nishitani (@Keisuke69) June 26, 2021 Twitter上で上記の発言を発見し、「確かに。技術広報の成果と評価について尋ねられることがあるが、うまく言語化できず返答に窮することが多いのでちゃんと整理しておこう」と考えました。 頭の中を整理することによって、今後マネーフォワードに関係する人が会社の意思決定のプロセスを誤解なく理解できるのではないかと思い、筆を取りました。 あくまでこの意思決定や合意形成は一時的なスナップショットなの

As many have recognized, when inventions and innovations first appear they are often (always) labeled as “toys” or “incapable” of doing “real work” or providing “real entertainment”. Of course, many new inventions don’t work out the way inventors had hoped, though quite frequently it is just a matter of timing and the coming together of a variety of circumstances. It can be said that being labeled

hey の @ffu_ と @ushiro_noko をゲストにSTORESのフロントエンドの今、デザインシステム、フロントエンドに詳しいCTOがいてよかったことなどについて聞いてみました。 ゲスト ヘイ株式会社より 2 名のゲストをお呼びしています。 @ffu_ CTO @ushiro_noko Front-End Engineer heyの組織とプロダクトについて STORES プラットフォームを開発している EC から始まる様々な領域をトータルマネジメントするような形 実店舗向けのサービスや決済基盤なども提供している 複数のプロダクトや合併した企業の都合を吸収するため、デザインシステムを開発中 技術としては React/Vue が混在しており、両方で TypeScript が使われている状況 @ushiro_noko が現在デザインシステムや Front-End Ops の専任者とし

幸せについて本気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。 発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか？」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。 成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。 一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題

この記事は 2021 年 9 月、React v17 相当時点での情報に依存しています。 React の Suspense による非同期処理は未だ Experimental な機能ですが、いくつかのデータフェッチ系ライブラリや状態管理ライブラリのインターフェースでサポートされています。 公式ドキュメントに例示された実装 Suspense を利用するときのエラー処理には、公式ドキュメントで ErrorBoundary を使う事例 が紹介されています。「データ取得のエラーの処理はレンダーのエラーと同様に動作」することに由来しています。 エラーレポートと一緒に使うと困る Sentry 等のエラーレポートサービスを利用していて、データ取得の準正常系にあたるエラーは検知したくないが、実行時エラーのような異常系は検知したいときに、この例示を素朴に採用するのでは困ることに気づきました。 ところで、Err

Just about four years ago, we announced Cloudflare Workers, a serverless platform that runs directly on the edge. Throughout this week, we will talk about the many ways Cloudflare is helping make applications that already exist on the web faster. But if today is the day you decide to make your idea come to life, building your project on the Cloudflare edge, and deploying it directly to the tubes o