心理的安全性という概念がある。ここ十年ほどチームづくりの最重要ファクターであるともてはやされ、他方では粗雑な理解によって批判されてきた。急に人気の出たアイドルの宿命みたいなものを背負っている。 世間的なイメージがどのようなものか、少し羅列してみよう。 なんでも言える。否定されない。安心して働ける。不安がない。感情を大切にしてもらえる。あなたはあなたのままでいいと肯定される。 こうしたイメージを抱いている人もいるかもしれないが、残念ながらこれらは、心理的安全性の正しい姿からは遠くかけ離れている。ただ安心してほしいのは、こうした誤解をしている人は決して少なくないということだ。 手持ちのグーグルで「心理的安全性　誤解」と検索してみると、何ページにもわたって理解を正す記事が並んでいる。NewsPicksも、プレジデントも、朝日新聞も、Qiitaも、東洋経済も、あらゆるメディアが心理的安全性の誤解に

めもりーさんと語るFindy Engineer Lab オフ会＠東京 LT https://findy.connpass.com/event/294069/

世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ

freee人事労務の開発チームで給与計算関連の機能開発を行っているbanaと申します。最近はポケモンスリープに睡眠を支配されています。 freee人事労務の給与計算チームでは、先日入退社月の日割り計算の機能をリリースしました。この機能開発は自分が経験した中では比較的ドメインや仕様が難しい開発で、学びが多くあったため、プロジェクトを前に進めるためにやったことをこの記事にまとめたいと思います。 1つでも役に立つことがあれば、また、深いドメイン理解が求められるアプリケーション開発の大変さと面白さを少しでも感じていただければ幸いです。 前提 入退社月の日割り計算とは 今回記事で取り上げる内容が伝わりやすくなるよう、簡単に入退社月の日割り計算について説明します。 例えば、給与の締め日が月末（=給与計算期間が月初から月末）の会社に入社するときの基本給について考えます。従業員は月給制とします。 1日に入

iOSDC Japan 2023登壇資料

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog Overview 30万を超える同時接続数を持つチャットサービスにおいて、リアルタイムでメッセージの受信などのイベントを配信するメッセージブローカーとして、私たちはRedis ClusterのPub/Subを使用していました。 私たちのサービスでは、ユーザー数の増加に伴い、Redis Clusterのシャード数を増やすことでクラスターの性能を向上させてきました。しかし、Redis ClusterのPub/Subでは、シャード数の増加に伴ってネットワーク帯域が圧迫される問題が生じ、これ以上シャードを追加することができない状況になりました。 この課題を解決するために、メッセージブローカーをRedis Pub/SubからRedis

ドキュメント文化は健全な組織のスケールのために必要　組織の中でドキュメント/文章を残し活用していくことはとても重要だ。クオリティの高いドキュメントがあることで、組織に情報が流通し、透明性を確保できるようになる。情報を流通させるためにいちいち口頭の説明がいらないから、メンバーの数が増えた時でもスケールしやすくなる。過去の結論にアクセス可能になるので、議論を積み上げていき、意思決定のクオリティを高めることにもつながる。そもそも何かを読むということは何かを聞いて教わるよりも時間あたりの処理量が多いし、非同期に実施できる。良いドキュメントをアセットとして社内に蓄積していくことはスタートアップのみならず、ありとあらゆる組織が成長していく上でとても重要であると言える。 しかしその一方で、良質なドキュメント文化を徹底できている会社は多くないように見える。例えば、社内のドキュメントを蓄積させていく場所とし

大学院大学至善館 教授、幸せ経済社会研究所所長、有限会社イーズ代表取締役、環境ジャーナリスト、翻訳家。 東京大学大学院教育心理学専攻修士課程修了。『不都合な真実』（アル・ゴア氏著）の翻訳をはじめ、環境・エネルギー問題に関する講演、執筆、企業のCSRコンサルティング等の活動を通じて、地球環境の現状や国内外の動きを発信。 システム思考やシナリオプランニングを生かした合意形成に向けての場づくり・ファシリテーターを、企業や自治体で数多く務める。島根県隠岐諸島の海士町や熊本県の水増集落、南小国町、北海道の下川町等、地方創生と地元経済を創りなおすプロジェクトにアドバイザーとしてかかわっている。

最近、ピアフィードバック（360度フィードバック）の機会があった。フィードバックしてもらいたい相手を自分で選ぶスタイルで、ありがたいことに何人かからフィードバックする人として選んでもらったのだ。 フィードバックは匿名化されるので、本人に伝える必要はないのだけど、僕は本人に伝えるタイプ。なので本人に伝えたら「そのフィードバックいいですね」って言ってもらったので喜んだのだ。 自分がどんな事を考えながらフィードバックするかを書き残しておくのもいいなと思って書くことにした。 大前提 大前提として、フィードバックは自分のためじゃなくて、相手のために書く。そのフィードバックを受けて、相手が気づいてなかったことに気づいたりして、一歩踏み出せるようなのがいいなって思っている。 9割が、僕が相手に対していいなと思っているところ。1割は、もっとこうすると仕事をしやすくなるかなと思うところ。かな。 いいところ9

エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満

半年ぶりのカキコ……ども……。気づいたらHRソリューション本部からMFBC-CTO室に異動していたVTRyoです。兼任で引き続きHR系のマネーフォワード クラウドシリーズも担当しています。 ソフトウェアエンジニアとしての経験値が増えてくると、次第にレビュー担当者になることが増えてくるでしょう。私が所属するSREチームでもTerraformの相互レビューが頻繁に実施されています。そこで、事件は起きたのです。 自信を持ってApproveしたPull Requestで次々に事故が起きてしまった 現在HR内のマネーフォワード クラウドシリーズは、モダンな開発基盤へとリプレイス作業を多く行っています。これまで動いていた基盤に感謝しつつ、新しいPlatformへと移行し、最終的に元あったリソースを削除します。 事件はこの リソース削除 で起きました。 チーム内レビュー OK リポジトリ管理者レビュー

恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま

お金は人生の選択肢を広げたり、悲しみを減らすことに役立ちます。今日は「給与額は（だいたい）影響力の大きい順に 1.利益率 ＞ 2.需給バランス ＞ 3.経営の意思 ＞ 4.パフォーマンス で決まるよ」という話です。 ※会社員の場合。個人事業主や経営者は除く。 まずはじめに1枚でまとめるとこうなります。 ひとつずつ見ていきましょう。 1 利益率（業種の差）会社員として「30歳までに年収1000万円」と意気込むなら、まずそれを実現できる業種を選ぶ必要があります。というもの、業種ごとで利益率の水準は大きく異なっており、それらの給与に与える影響は少なくありません。 ちなみに、会社によって差はあるものの「金融」「コンサル」「製薬」が業種として利益率が高い傾向にあり、高給な人たちが多いという印象がありますよね。 参考：業界別 利益率ランキング 2 需給バランス（職種の差）職種によって採用の難易度は大き

キャパオーバーしてしまうと、自分を自分らしく保てなくなりますよね。ということで、今日はとても大事な「キャパ」の話。 予定がないから休む、ではなく 休むという予定を入れる 先日、大学にお邪魔してお話しした時に、学生から「つい自分の予定を詰め込み過ぎて、ヘトヘトになってしまうんですけど、どう管理すればいいですか？」と聞かれました。分かる分かる。 その時、僕はふたつのことを伝えました。 ひとつめ。 自分を自分らしく保って、パフォーマンスを発揮するためには、休息が必要です。特に就職活動中は、予定が空いていると「何かしなきゃ」という思いから予定を埋め込んで安心したくなる気持ちもあるでしょうが、行動から学んだことを咀嚼するには「休む」必要があります。 だから、「休む」という予定を入れて、アクティブに休んでしまいましょう。「予定がないから休む」ではなく「休むという予定を入れる」。いのちだいじに。 そして

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

認知的負荷（認知負荷）とは「認知的負荷（認知負荷）」の理論は、オーストラリアの教育心理学者、ジョン・スウェラー（John Sweller）氏によって1980年代に開発・確立された理論だ。この論でいう認知負荷とは、脳のワーキングメモリが常に処理している「情報量」を指し、脳への情報のインプットが私たちの認知能力にどのような負担をかけるかを表している。 スウェラー氏の研究は、教育設計の手法として知られることが多く、何かを学ぼうとする人間に対し、情報をどう伝達するのが最善かを判断する材料として用いられている。 言うまでもなく、脳のワーキングメモリは有限であり、それを使い果たしてしまうと新しい知識の定着（学習）やタスクの完了が困難になる。ゆえに、インプットされる情報の量や種類が人の学習能力に影響を与えそうな場合には、認知負荷理論を活用するのが適切とされている。 認知的負荷の3つのタイプ認知負荷理論で

「B/43 Tech Talk 〜 Fintech×サブスクリプションサービス立ち上げの裏側〜」にて @ohbarye が"サブスクリプションサービスをつくる時にエンジニアが考えること"と題して発表した資料です。 イベントURL: https://smartbank.connpass.com/…

こんにちは、Web Engineer の @wozaki です。 今回は、採用プロセスの改善として、職務経歴書に記載いただきたいことを公開した背景をご紹介します。 概要 職務経歴書に、採用チームとして期待する情報が不足していることがある 不足すると、以下の課題が発生することがある 書類選考は通過するが、その後の選考でミスマッチと分かる (経歴書が充足していたら、より早期にミスマッチが分かったかもしれない) 面接の前に経歴に踏み込んだ質問を設計できずに、面接時間内でマッチしているか情報を引き出す難易度が上がる 既存の対策として、情報の追記をお願いすることがある 新たな対策として、記載いただきたいことを ガイドとして公開 することにした 記載いただきたいこと 早期ミスマッチ解消の必要性 Web Engineer の採用は競争が激化している肌感があります。 応募者の方々にとっても、様々な企業の中

Test which reminded me why I don't really like RSpec | Arkency Blog (日本語訳：Rails: RSpecが好きでないことを思い出したテスト（翻訳）｜TechRacho by BPS株式会社) を見ての感想。 元のコードのイマイチなところは 4 つあって、 params を before で書き換えている *1 it "will succeed" の文言 it { is_expected.to be_success } と expect(result.success?).to eq(true) が混ざっている let が不思議な順序で連発されていて事前条件を読み解けない すべて、これによって何をテストしているのかが分かりづらくなっているという問題を引き起こす。 params を before で書き換えている let(:pa

The NEXT of REST 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST REST で解決していない問題 REST っていうのは本当に難しくて、 開発者のお気持ちで API が異なる 指針であって仕様じゃないのが理由 POST がワイルドカードとして使われるとか クライアントとサーバ間のまだある精神的な溝 API はサーバが作るもので、クライアントは手出ししづらいという意識 REST だとクライアントごとに最適化した API を作りづらい Web とスマホで同じ API を使うときに不要なレスポンスがある 提供されている API が不十分なときにクライアント側で JOIN するハメに のような問題を抱えています。 これかを解決するために、API Query Language (