Webプロダクト開発をしていると様々な諸事情によりUI構成を変えたり機能を増やしたり減らしたりすることが多々あると思います。そんな時に避けられない事態として「UI変更に対するお怒りがユーザーからわんさか届いてしまう」ということがあります。今回はUI上の１要素の色を変えただけで虎の尾を盛大に踏んでしまった事件の話をしようと思います。差し当たりどういうUIをどう変えたのかを明示しておきます。変える前がこちら↓↓ beforeUIほんで変わった後がこちら↓↓ afterUIご覧の通り「作業カード」と呼ばれるコンポーネントの色を「緑＆黄」から「緑塗り＆緑枠線」に変更しました。「え、それだけ？」という声が聞こえてきそうですがそうなんです。それだけなのです。しかしここはレガシードメインのtoB SaaS。toB SaaSではUIの変更がユーザー業務への影響に直結するので軽微な変更を加えるのもハードルが

こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。 私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。 開発チームとCapabilityの定義 開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームを

1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

カミナシPMのかこもえ（@kakomoe3）です🐙 Lboseさんにお声かけいただき、PM向けウェビナーでLTをさせていただいた。それをフォローするnoteを書こうと思う📖 ↑文字読むのめんどい方は、スライドだけでも見ていってくださいませ✨ 💡このnoteで書いたこと💡 ・組織で顧客に向き合い、一次情報を得る文化や仕組みの作り方 ・PMとして、今日からできそうなこと 現場ドリブンってなに？『現場ドリブン』とは、私の所属するカミナシのバリューの1つだ。 事件は会議室で起きてるんじゃない！現場で起きてるんだ！つまるところ 「泥臭く、顧客に向き合う。足を運び一次情報を得、自分ごと化していく」 という意味の言葉で、私が最も好きなバリューでもある。 そしてこれはただの推測だが、カミナシ社内バリューランキングを開催すると、おそらく70%くらいの人が 👨👩「現場ドリブンがいちばん好きです‼️

はじめに 今回は有名企業の公開されているエンジニア新人研修資料をまとめました。 昨今、新人向けの研修資料を公開する企業が増えています。 またクオリティーがかなり高いものが多く、初級者~中級者でも学びがある資料となっています。 資料の作り方も勉強になるので「勉強会で登壇している人」「企業の研修担当の人」にも有益な資料になっています。 この記事の主な対象者 有名企業の研修資料を網羅的に見たい人 エンジニア初級~中級者の人 独学で学習をしている人 研修資料の作成を今後していきたい人 ミクシィ まずはじめに紹介するのは、毎年新人向けの研修資料を公開している株式会社ミクシィです。 ミクシィの研修資料で公開されている内容は、 Git研修 データベース研修 設計・テスト研修 コンテナ研修 iOSアプリ開発研修 Androidアプリ開発研修 フロントエンド研修 ゲーム開発研修 Flutter研修 AI研修

はじめに こんにちは！お会計チームの yamakazu (@yamarkz) です。 10Xでは4月から新しい期が始まるため、最近はバタバタしています。新しい組織や取り組みが始まってきていて、今年度はこれまでとはまた違った大きな変化が生まれそうで楽しみです。 さてそんな今回は期の変わり目ということもあり、 節目として「Stailerの開発を支える取り組み」を紹介します。 取り組みはプロダクトの規模や性質、組織構造、願望によって変わる唯一無二の存在で、各社様々な工夫を凝らして、より良い開発体験を追求していると思います。 自分たちもその時々の状況に合わせて、最適なやり方に変えて開発してきました。 今後も取り組み自体は変わっていくと思いますが、2023春時点での取り組み状況 (仕組み / ルール / 文化 / ツール) をスナップショットとして取り上げみようと思います。 はじめに 前提 取り組み

カミナシPMのかこもえ（@kakomoe3）です🐙 現在はPMとデザイナーのチーム（通称：P&D部）のマネジメントをしているのですが、ふと思い立ってnote📖の連載企画を立ててみました。 テーマは「カミナシと◯◯とわたし」 この連載企画について📓この連載企画は、カミナシのPMとデザイナーのみんなが、自分自身の「こだわり」「偏愛」「感情」みたいなものについて、カミナシに絡めながら語る、というやつです。 これまでカミナシに興味を持ってくれた方とお会いすると、ありがたいことに何かしらの発信を読んでいて、そういった外に出している情報からは見えない生っぽい情報に興味をもってくださる方が多いです。 でも、このカミナシという箱の中身を何かしらの形で先に伝えられれば、もっと早くお互いの理解を深め合えるかもしれない。 そんなこんなでこの連載では、カミナシの中にいる人たちの「空気感・温度感」のようなもの

はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発

仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方 💡このnoteはなに？ プロダクトに関するドキュメントの種類呼称別の整理と、どうしたら現在のチームにドキュメントに関する目線合わせのアイデアを書いたものです 💡誰のためのnote？ プロダクト開発に必要なドキュメントについて日々心を悩ませている人 ドキュメントの話に着地をつけたい 誰かが言い出すアレ今までの経験上、どこに配属されても、プロダクトに関するドキュメントとして誰が何を書き、そして運用するのか、という議論が起きないことは1度もない。 プロダクトに関するドキュメントは、PRD・要件定義書・仕様書・Design Docなど、さまざまな呼称があり、会社や部門によってさまざまな使われ方をしている。 そしてそれぞれの言葉には単一の定義があるわけではない。 そもそもドキュメン

カミナシPMのかこもえ（@kakomoe3）です🐙 このnoteは、チームのメンバーから「ファシリテーションをすることが多くなってきたので、コツを教えてほしい」という話があり、日頃私が意識している話を書いてみようと思ったものです。 割とどこにでもあるかもしれない会議の進めかたのコツですが、社内ドキュメントとして書いたものがわりと評判がよかったのでnoteに転載しようと思います📖 ファシリテーションとは？「ファシリテーション」を調べてみると、意味としてはだいたいこんな感じのことが出てきます 💡 人々の活動が容易にできるよう支援し、うまくことが運ぶよう舵取りすること 💡 会議やミーティングを円滑に進める技法 個人的には、ファシリテーションは以下2つの役割を持っていると考えています コト…論点に対する結論を出し、次のアクションを決めるためのプロセス進行 ヒト…結論、アクションを決める過程

※この記事は、Mercari Advent Calendar 2022 の5日目の記事です。 こんにちは。メルカリのエンジニア組織開発を担当するチーム「Engineering Office」で、主にInternal Engagementを担当している@afroscriptです。 最近、私は「エンジニア組織内のコミュニケーション最適化」に取り組み始めました。そのプロジェクトの第一歩として、以下のことを整理しました。 組織内コミュニケーションにはどのようなものがあるのか？ 組織内コミュニケーションの理想状態はどのようなものか？ このプロジェクトはまだ始まったばかりです。そのため、プロジェクトを進めるうちにこの定義も変わっていくかもしれませんし、まだブラッシュアップが甘い部分も多々あるかもしれません。ですが、せっかくのアドベントカレンダーの季節なので、現段階で整理できた部分をシェアしてみようと思

📚「失敗の本質」はどういう本か？📚 太平洋戦争で日本は負けた。その日本軍が失敗した要因の本質はどこにあるのかを、現代の組織に活かすことを目的に組織論を中心とした研究者たちが研究・分析した本。 合理的・近代的な組織であったはずの日本軍が、そことは反する組織的な振る舞いにより敗北に向かっていった。これを、6つの敗北した作戦を例にとり解説している。 本書に書かれている、失敗の背景にある日本軍という組織。 日本軍は現代の企業組織にも通ずるあるあるな課題を踏み抜いてきており、組織について考えたことのある人であれば誰でも、何か具体的なシーンが思い浮かぶのではないかと思う。 本書では、日本軍は『自己革新組織』である必要があったという話をしている。 これをどうしたら自分の業務の中で活かせるのだろうかと考えていたのだが、定点でのヘルスチェックのような形にすれば、組織の状況を確認し、なにかしらのアクション

こんにちは、かこもえ（@kakomoe3）です。 株式会社カミナシ🐐でPM（プロダクトマネージャー）をしています。 さて今日は、タイトル通りBtoC企業からBtoB企業へ転生転職した私のアンラーニング集と題して、以下の問いに自分なりの結論を出していきたいと思う🗒 🤔 BtoC PMは、BtoBでも活躍できるのか？まあこんな名前の記事を書いているので察しのいい方はすぐにわかると思うが、結論は「Yes」だ。 なんで「Yes」なん？具体的にどこが活かせるん？逆にアンラーニングせなあかんとこは？ そんな細かい話に興味がない方はここで終わってもらって大丈夫。な、泣かないもんね😂 BtoCとBtoBのプロダクトの違いと共通点さてBtoC PMがBtoBでも活躍できるのかを考えるために、まずはBtoB PMになって感じたいろんな違いについて、6つの観点でまとめてみる。 ぼくのかんがえたさいきょう

<> 2024.1.11 みなさんも編集可能・かつさらに使いやすくなった「コミュニティ版」をリリースしました。 是非そちらもご参照ください！ https://qiita.com/viva_tweet_x/items/f4db2c923d474f67fe0f 古今東西のふりかえり手…

詳細な使い方や更新履歴はQiitaをご参照ください。 https://qiita.com/viva_tweet_x/items/cc3bad3bd298406b6cc7 ふりかえりカタログとはふりかえりカタログは、ふりかえりの手法（現在）70個とその特徴を網羅したカタログです。 ふりかえりの各手法を「手法名」「手法を使う場面」「手法のイメージ」「出典」「進め方」「いいところ」「手法のポイント」に沿って分類しています。 DLしていただいたものは、ご自由にご利用ください。 この商品の仕様無料でDLいただけます。 ご自由にお使いください。 引用する場合は、こちらのページのURLを出典リンクとして明記いただくようお願いいたします。

私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記:  思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき

という、よこしまな理由で筆を取り始めたが、4m超の本棚を作るくらい本が好きなので、みんなに読んでほしい本というのが、実はたくさんある。 (本棚、やっと埋まってきた・・・) ということで、この勢いでおすすめ本を紹介する記事を書いてみようと思う。 第一弾は、エンジニアだからこそ読んでほしいビジネス書。読みやすいカジュアルなやつから紹介する。ある程度読まれたら次のやつも何か書く。 自分の意見を発信するのが苦手だなーと思ってる方に読んでほしい本

こんにちは、かこもえ（@kakomoe3）です。 株式会社カミナシ🐐でPM（プロダクトマネージャー）をしています。 📖 このnoteはなに？ 📖 私がカミナシに入社して6ヶ月、7月にPMチームができて3ヶ月経ちました🙌 その6ヶ月間の実録として、PMチームを組織化する過程での課題と取り組みについて書きたいと思います💪 📖 誰のためのnote？ 📖 ・1人目PMや、これからPMチームを組織化していきたいと思っている人 ・カミナシのPMって何やってるの？気になる！という人 ・加古は最近元気かなと心配してくれている人 PMチームが7月にできました私は2022年4月にカミナシに入社をしたのですが、当時カミナシの専任PMはおらず、CSチームのリーダーがPMを兼務していました。 さすがに兼務は厳しい！ということで私が採用されたのですが、PM、ないしそれに準じる組織がないところに入社をした