マネージャーになり1on1を”する側”になってすぐに、第1の壁にぶつかることになる。何を話していいか分からないというやつだ。 マネジメント業をデビューした直後はとりあえず1on1をしなきゃと無計画なまま予定だけおさえ会話がうまくできず後悔したり、「最近どう？」から始まり「特に何も」と返されどうにも盛り上がらない事態に危機感を覚えたりした。 ここで1on1のやり方が書かれた本を数冊読んで、『相互理解』『傾聴』『承認』『フィードバック』に始まり数々の技やフォーマットを知り、それらを実践しているうちにいつの間にか壁を乗り越えたような気持ちになる。 ＊ ＊ ＊ 第2の関門は、フォーマット通りに話すぎこちなさとの戦いだ。 「傾聴しなきゃ」「自分と相手の発言量を3:7にしなきゃ」などと考えすぎて質問攻めにしてしまったり、承認しなきゃと必死に褒めポイントを探してしまったりと、学んだフォーマットやテクニッ

Figma Japanは、企業のCDOやCXO、デザイン部門のトップを招いたラウンドテーブルを開催。本記事では、サンフランシスコより来日したFigma CPO 山下祐樹さんによる「魔法のような製品をいかにして生み出すか」と題したプレゼンテーションと、後半で行われたファイアサイドチャットより、Figma Japanカントリーマネージャー 川延浩彰さんとの対話を中心にお届けする。 魔法のような体験提供のために最初に行った「OKRの廃止」 マイクロソフト、YouTube、Uberなどを経て、4年前にFigmaにジョインした山下さんは、それらの共通点を「素晴らしいデザインカルチャーがあること」と語り、セッションをスタート。そしてそれは具体的に「企業にとってさまざまなビジネスのプライオリティがあるなか、あえて超一流のユーザー体験にこだわって投資してくれる点」だと表現した。 英語圏ではこのような体験を

こんにちは、トキワです。 突然ですが、私自身、社会問題の当事者でした。 貧困家庭育ちやいじめなどの経験があります。そのため20代はずっと社会問題の研究をしてきており、「悪者図鑑」という本の出版にまで至りました。 悪者図鑑は「人間にどんな悪い影響があれば悪者になるのか」という研究成果なのですが、30代になってたまたま教育業界にくるようになり、現在は「良い影響」も調べています。 その結果、先日以下のnoteを書きました。 いわゆる「才能（遺伝）と努力（環境）どっちが大事？」という問題ですが、調べたことですごく色々分かってきて楽しかったです。 特に面白いと感じたものの一つに「性格（Personality）」があります。 性格診断というと16personalitiesのMBTIが有名ですが、学術的にはそこまで信頼されていません。信頼されているのがビッグファイブです。 ビッグファイブとは言葉の通り、

大学院で学ぶ「学習のデザイン」。自分がこの大学院で学びたかった目的の１つ、インストラクショナル・デザインの授業が後期からはじまりましたので、今日はそのご紹介です。 インストラクショナル・デザインとはまず言葉の定義から、それぞれ日本語にするとこうなります インストラクショナル：教育の デザイン：設計（組み立て方） つまり教育方法の設計です。もう少し具体的に言葉すると、このように定義されます。 教育・研修の効果・効率・魅力を高めるための手法を集大成したモデルや研究分野、またはそれらを応用して学習支援環境を実現するプロセス （鈴木克明 2005）インストラクショナル・デザイン（以降はIDと略します）ができたのは、第二次世界大戦後、アメリカで教員不足が深刻な問題となり、誰でも一定の品質で教えられるメソッドが必要になったという背景があります。 今回は第1回目なので、IDの基本的なメソッドを３つほど紹

判断と決断の話の違いはこのツイートの通り。 判断の話で言うとぼくはそーだいさんがしてくれた「判断と決断は違う」という話がだいぶ実になっていて、「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなければならないのは決断」という話をかなり大事にしている— しんぺいくんさん (@shinpei0213) 2021年12月10日 決断のコツ 結論から言えば、決断のコツは失敗できるようにすることだ。 失敗できる状態なら決断することができる。 そして素早くアクションして、失敗のフィードバックを受け取ることで新しい決断をすることができる。 そーだいさんがぼくに教えてくれた二大大事なこと「判断と決断は違う」と「ロールバック可能なことはどんどん試せばいい、ロールバックが難しいことは慎重に」です— しんぺいくんさん (@shinpei

Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない) 仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せている状態をつくることで、それにより絶妙なズレが生まれると感じる。 Engineering Manager の仕事を例にあげると、個々人のサポートをしたり、チームがうまくいくサポートをしたり、チーム間のコミュニケーションラインを整えたり、チームのはざまに落ちてるタスクを拾ったり、必要な人を採用したり、ビジネスや経営から求め

Zenn の記事に清書しました：ReactNode型のpropを正しく扱う 〜もう謎の「0」や空要素を見せないために〜 背景 React コンポーネントを作っていると、しばしばオプショナル （任意）な ReactNode 型を受け取る prop を書くことがある 例1：Button に iconを渡したときだけスペースをちょっと開けてアイコンを表示し、渡さなかったら非表示にする <Button icon={<PlusIcon />}>Add</Button> → <button><span style={{marginRight: "0.5rem"}}><PlusIcon /></span>Add</button> <Button>Add</Button> → <button>Add</button> 例2：Checkbox に children を渡したときだけ全体を label でラッ

ALL STAR SAAS FUNDのメールマガジン「ALL STAR SAAS NEWSLETTER」購読登録受付中ALL STAR SAAS FUNDがお届けする 最新SaaSニュース、ブログ記事情報を配信するSaaS業界にいる方は必見のメールマガジン！ アメリカで支持を集める掲示板型SNS「Reddit」のCEO、Steve Hoffmanはこう言いました。 「数ヶ月のコーチングが、Redditに数十億ドルの価値をもたらした」と。 彼が絶賛した、「Mochary Method」をご存知でしょうか？これはOpenAI、Coinbase、Rippling、Notionなど、急成長を続けるテック企業の経営者たちが受けるコーチングメソッドです。 彼らはなぜ、コーチングを受けているのか。そしてそこでは一体、どのようなコーチングが展開されているのでしょうか。 「課題を抱えていた企業が、コーチング

インフラチームの西川です。 当社ではGitHubを利用しています。いろいろ便利な機能があるのですが社内でコマテクを募集してみたところ意外と知らないものがあったので共有してみます。 行動の見える化 特定コミットのリンク取得 通知 行動規範 ガイドライン .github リポジトリ テンプレートリポジトリ タグをたくさんプッシュさせない ドラフトプルリクエスト チケットの自動リンク化 ベースブランチの更新を取り込む まだレビューが終わってないプルリクエストの一覧化 レビュアーの自動割り当て コードの所有者 ファイル単位でレビュー済みをチェックする レビュー中のファイルを全部閉じる 具体的な修正を提案する レビューコメントをラベル化 デプロイ管理 リリースノートを自動作成 行動の見える化 以下の設定をすることで、GitHub上の行動を見える化することができます。 docs.github.com

" class=code-demo loading=lazy style=height:350px>これを突き詰めると、スプリングアニメーション（Spring Animation）のような、従来は JavaScript でフレームごとに描画していたアニメーションも CSS アニメーションで実装できます。 iOS のスプリングを CSS 数式アニメーションで再現する この記事では数式を使ったアニメーションを CSS で行う方法について、実際にデモを実装しながら解説します。 数式でアニメーションを表現できることの利点 #数式でアニメーションを表現すると聞いて、ピンとこない人もいると思います。以下の画像はこの記事のはじめのデモで使っている数式をグラフにしたものです。このグラフの形がイージング関数に似ていると気づいた方もいるかもしれません。 このようなグラフを描く数式を作ることができればイージング

ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス

いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。 207の1on1、めっちゃ良いんです！！ 先日の忘年会で業務委託の方に「207に所属していて良いところは何か？」とお聞きして「1on1、めっちゃ科学されていて良いですよね」という話題に上がるくらいには良いです！ 私自身、業務委託で色んな会社を見ているのですが、たしかに207の1on1は凝っていると思います。 という事で、本記事では「どんな質問を」「どんな意図で」しているのかを代表にインタビューしてきたのでまとめていきます。 1on1をやる目的 そもそも1on1を実施してよかった点ですが、たくさんのメリットの中でも特に、 - 認識のズレをなくす - 信頼関係を構築する - アラートの早期検出 みたいな効果を享受できています。それぞれ、どういう意味かをご説明していきます。 認識のズレをなくす 業務上

こんにちは！学習動画・Webテストの開発を行っています エンジニアの daichi (id:kudoa) です。 この記事では、最近チームで導入したライブラリアップデートを自動化した仕組みとその経緯について紹介します。 なぜ自動化しようと思ったか サービスを開発するだけではなく、日々の運用も必要です。 その運用業務の1つとして、ライブラリのアップデートがあります。 これはサービスを運用する上では大切なことではありますが、日々ライブラリアップデートのPRをさばき続けるのも大変です。 その時間をできるだけ減らし、その分空いた時間をユーザーへの価値提供や将来の投資に充てるために、今回の自動化の仕組みを作成しました。 この辺りの話は以前勉強会でLTしたことがありますので、興味があればご覧ください。 作ったもの 前置きは長くなりましたが、凝ったものを作ったわけではありません。 作成したものはライブラ

サマリー：意思決定スタイルの相違によりチームの協力が妨げられることは、組織でたびたび生じる問題である。そうならないためには、自己を認識し、チームメンバーのプロファイルを理解することが重要だ。経営者は「問題解決者...　もっと見るプロファイル」を活用したうえで、柔軟な意思決定を行う必要がある。本稿では、5つのプロファイルを提示し、リーダーが多様な意見を協力的に取り入れる方法を解説する。　閉じる 人は同じような考え方の人たちと仕事をしたがる 環境に配慮したホスピタリティ企業のCEOであるエブリンは、コスタリカでの事業を視察するため、上級幹部チームとともに現地に飛んだ。ワンランク上の富裕層市場への参入のチャンスを与えてくれそうなホテルが売りに出されており、現地支社の責任者はその機会を逃したくないと考えていた。 しかし、チームが現地に集合すると、コスタリカ支社の財務データに不可解な点があることが明

装飾用の画像は、互い違いになったリストのレイアウトで使われていると、ページを流し読みするユーザーがつまずく原因になることが、アイトラッキング調査でわかった。一方、テキストや画像が縦に整列しているページでは、ユーザーは効率的に流し読みをしていた。 Zigzag Image–Text Layouts Make Scanning Less Efficient by Kim Flaherty on November 26, 2017 日本語版2018年6月27日公開 画像は、大きな写真であれサムネイルであれ、現在のWebデザインには欠かせないものだ。特に、トップページや「こういう仕組みです」（How it works）ページのようなストーリーを伝えるページで、企業が複雑なトピックについて書いたり、製品の説明をするときには、関連する画像を付けた説明的なテキストのかたまりがあり、次の列も同じようなテキ

Zodとの比較 公式サイトで、Valibot は、Zod と比較して、バンドルサイズが最大98%削減できると記述されています。今回作成した問い合わせフォームでも、92.2%の削減を確認できました。 VSCode 上で Zod で作成した Schema ファイルのサイズは gzipped 圧縮で12.8kです（Zod を利用した Schema はこちらを参照ください）。 ZodのSchema実装 import { z } from "zod"; const email: z.ZodString = z .string({ required_error: "入力が必須の項目です" }) .min(1, { message: "入力が必須の項目です" }) .max(255, { message: "255文字以内で入力してください" }) .email({ message: "メールアドレスの

こんにちは！SmartHRで基本機能の開発を担当している、エンジニアのwakasaです。2023年の1月から半年かけて、自チームのテストフロー見直しを行い、実装時間を大幅に増やすことができました。今回はその取り組みをご紹介します。 見直し前のチームの状態 私の所属するEチームは、SmartHRの基本機能の中でも、従業員情報やマスターデータの履歴データ管理周りの機能開発を主に担当しています。2023年8月現在、エンジニアが6名、プロダクトマネージャーが1名、プロダクトデザイナーが1名所属しており、QAエンジニアは所属していません。以前はQAエンジニアがチームに所属していましたが、2022年10月にチームを離れました。QAエンジニアがチームを離れたあとはエンジニアがテスト業務を兼務しています。 今回の取り組みを始めるきっかけとなったのは、2022年の年末に実装にどのくらい時間を使えているのか計