プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
今日でCloudflareに入社してちょうど1年が経ちました。 DevRelチームに所属し、Developer AdvocateとしてHonoの開発をメインに活動してきました。 41歳にして初めての会社員ですが、楽しい時間を過ごしています。今日はそのことについて書いてみます。 入社までの経緯 詳しいことは入社時のブログに書いたのですが、その経緯を再び。 2021年の12月にHonoというCloudflareで動くWebフレームワークをつくり始めて、それがだんだんと人気を得ていきました。 2022年の10月、CloudflareのエンジニアGlenが「Cloudflareで働くのに興味はないか?」と声をかけてくれました。当時UKに住んでいた彼が、地元のオーストラリアに戻りたいので、同じタイムゾーンのエンジニア仲間を探していたのです。ちなみに、GlenはCSS in JS「styled-com
私たちの脳は睡眠時でも休むことなく動き続けており、睡眠中の脳ではニューロンが協調して電気信号を発し、それらが蓄積してリズミカルな波となることで脳にたまった老廃物を洗い流している可能性が、ワシントン大学医学部の研究チームによって示されています。 The Glymphatic System – A Beginner's Guide - PMC https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4636982/ Neuronal dynamics direct cerebrospinal fluid perfusion and brain clearance | Nature https://www.nature.com/articles/s41586-024-07108-6 Neurons help flush waste out of brain du
はじめに 最近、チームってどんな構成にするのがいいんだろうか?と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか? チーム間のコミュニケーション(インタラクション)をどう設計するか? 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか? チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、1つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
はてなで働くエンジニアにアンケートシリーズ第26回は、MackerelチームのSRE、id:heleeenに話を聞きました。 夢中になれるサービスの開発にしっかり参加してみたい Mackerelを普段から運用することがサービス改善のきっかけに リモートワークのコミュニケーションへ些細なことでも持ち込めるように SLIの再編であるべきSLI/SLOの姿に近づけられた 現状を改善したい気持ちを常に持つ 社内に限らず「他者へのリスペクト」が強い人が多い 夢中になれるサービスの開発にしっかり参加してみたい ── Q1. はてなidとその由来を教えてください id:heleeen です。旧姓を言い間違えられたことからついた呼び名をidにも使っています。ぱっと見で読みづらいのですが、これで「ヘレン」と読みます。ちなみに日本人です。 ── Q2. いつどんなきっかけで入社されましたか? 前職の同僚のエン
御社のミッション、ビジョン、バリューを教えて下さい 御社では、日々の業務でどのようなソフトウェアを作っていますか? 御社の主要な顧客のカテゴリーとマーケットを教えて下さい 御社の事業が、顧客にどのような価値を提供してどのように対価を集めているのか教えて下さい 御社の事業の立ち上げの経緯や意思決定や試行錯誤のプロセスについて、もしご存知でしたら、なるべく詳しく教えてください 御社の事業の今後の展望や計画について教えてください 御社の日々のソフトウェア開発で、ソフトウェアエンジニアとして、夢中になれる魅力や醍醐味を教えて下さい 御社の技術構成や開発プロセス、開発スタイルについて教えて下さい 会社のことは忘れてください あなたが最近、話を聞いたり自分で触って、驚いたり熱中したり感動したりしたソフトウェアがあったら教えて下さい あなたがこれまでの生涯でソフトウェアを開発していて一番愉快で面白くて最
いままでわたしは、「リーダー=頼りになる人」だと思っていた。 まわりが「ついていきたい」と思うような人格と能力を兼ね備え、みんなを引っ張っていってこそリーダーだ、と。 ……でももしかしたら、リーダーって、頼りにならなくてもいいのかもしれない。 頼りにならないリーダーでもうまくいった とあるゲームで、わたしはTAチームを結成した。 TAとはタイムアタックの略で、いかに早く攻略できるかを競う遊びだ。 条件が合うチームがないので自分で作ったのだが、チーム経験が豊富なメンバーに対し、わたしはチームに所属することも、ましてやリーダーをするのもはじめてという状態。 なにかを決める場面でも、 「みんなはどう思う?」 「どうしたらいいか迷うね」 「うーん、どうしよう……」 と、あたふたするばかり。 まったく頼りにならない、ダメなリーダーである。 こんなんで大丈夫だろうかと、最初は心配でしょうがなかった。
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
最近、毎日のようにEMのいくおさん( @dora_e_m )とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う(ふだんから
ひさしぶりにblog記事書きます 本エントリはカケハシ Advent Calendar 2023 Part 2の 15日目の記事に入れてもらってます。カケハシ Advent Calendar Part 1 もあり、様々な職種の方が記事を書いているので、ぜひご覧ください。といってもそもそもこのblogでは初出であるカケハシってなんだ?という話からしなければなりません。このAdventが書くきっかけになったのですが、そのあたりの近況報告も兼ねて最近こんなことをやっているというアップデート記事です。 転職していました 実際に新しい所属になったのは今年の10月1日からで、もう2ヶ月半くらい経っているのですが、本当にあっという間でした。Twitterではいろいろ投稿していたので見ていた方はご存知かも知れません。現在は株式会社カケハシというところで、ソフトウェアエンジニアとして新しい事業ドメインを起ち
UX Designチームのasakomです。今回はデザイナーの役割定義の活動の一つとして作成した、”Design Skill Map”についてお話しします。 このSkill Mapは、メルカリUX Designチームで求めるデザイナーの専門スキルを整理したものです。以前紹介したDesign Ladderは、メルカリの行動指針に基づいて作成した、デザイナーに求める態度やマインドセット。今回は専門職としてのデザイナーに必要な技術や知識をSkill Mapとしてまとめました。 UXデザイナーの役割定義や、個人の目標設定、採用の基準作りなど、チームの運用に関わる人や、メルカリのUXデザインチームが求める人材に興味のある方に、ぜひ読んでいただきたいです なぜSkill Mapを作ったかUXデザインチームの役割定義は、チームのミッション達成のために存在します。私たちのチームのミッションは、”メルカリの
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。 ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。 ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。 それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。 本家のドキュメントはこちらです。ぜひお読みになってください。 DevOps Guidance 要約と紹介 最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。 面白い一文があったので引用します。 There is no one-size-fits-all
はじめに 株式会社マイベストでバックエンドエンジニアをしています、井上周(@isaka1022)です。 マイベストの開発組織において、2023年度の後半にかけて、バックエンドのテストの書き方の方針、ガイドラインの策定のプロジェクトを担当しました。 そもそもどのようにテストの書き方を決めるのか、また、ガイドラインとして機能させるためにエンジニア全員で共通認識を持てるものに仕上げるか、など考えることが多かったのですが、なんとか形にすることができたので今回はどのようにガイドラインを策定したか、その背景や経緯をお伝えできればと思います。 ガイドライン策定の背景 mybestのアーキテクチャには近年、Ruby on Railsに加えてNext.jsが導入されました。 それに伴い、バックエンドのテスト環境に大きな変化がありました。 それまでもテストの書き方のルールが決まっていなかったこともそうですが、
半年ぶりのカキコ……ども……。気づいたらHRソリューション本部からMFBC-CTO室に異動していたVTRyoです。兼任で引き続きHR系のマネーフォワード クラウドシリーズも担当しています。 ソフトウェアエンジニアとしての経験値が増えてくると、次第にレビュー担当者になることが増えてくるでしょう。私が所属するSREチームでもTerraformの相互レビューが頻繁に実施されています。そこで、事件は起きたのです。 自信を持ってApproveしたPull Requestで次々に事故が起きてしまった 現在HR内のマネーフォワード クラウドシリーズは、モダンな開発基盤へとリプレイス作業を多く行っています。これまで動いていた基盤に感謝しつつ、新しいPlatformへと移行し、最終的に元あったリソースを削除します。 事件はこの リソース削除 で起きました。 チーム内レビュー OK リポジトリ管理者レビュー
こんにちは。DX事業部の花村(@naomasabit)です。先日の投稿でユーザーの利用状況確認のためにAWSのQuickSightを利用していると書きましたが、並行して分析ツールのRedashも利用しています。Redashの良い点としてクエリベースでの分析、監視アクション、スプレッドシートとのデータ連携が存在します。 SaaSチームの運営において、これらを活用したユースケースについて伝えていきます。 アドホックな分析クエリの共有によるコミュニケーション効率化 監視アクション設定によりデータ不整合にすぐ気づける体制整備 複数チームからのデータソース連携によるヘルススコアダッシュボード作成 最後に - Redashと他の分析ダッシュボードツールの併用について アドホックな分析クエリの共有によるコミュニケーション効率化 Redashでは、まずクエリベースでアドホックな分析クエリの共有が可能です。
ソフトウェア開発において注目されるパフォーマンス指標には、デプロイに関係するものがあります。GoogleがDevOpsの取り組みから発表したFour Keysも、デプロイ頻度のほか、コミットからデプロイできるまでのリードタイム、デプロイにともなう障害発生率とその回復時間と説明されています。 そのためデプロイできるブランチへのマージは小さく、回数を重ねることが推奨されるようになっています。一方で、ビジネス用途のSaaSなどでは顧客との関係から、新機能は適したタイミングで完成度を上げてからリリースしたいという要求もあります。 タレントマネジメントシステム「カオナビ」の開発チームでも同様の課題感を抱えており、その解決のためFeature Toggle(機能トグル)を導入してデプロイとリリースの分離を図りました。その経緯や成果について、導入を主導したCTO室の富所亮さん、サービス開発部で実際にFe
日本サッカーは三笘選手など「大卒後、トップクラスに上り詰める」選手が多い。よく「欧州と比べると珍しい」「欧州ではありえない、だから日本サッカーのレベルは低い」という話に繋げる人が居るが、ではなぜこういう事象が起きるのか解説する。 理由1:日本には欧州にはない「カレッジスポーツ」の仕組みがある何よりこれである。アメスポ文化の国ではカレッジスポーツは珍しくなく、例えば野球のMLBでは全体の4割が大卒だ。 日本もその仕組みは当然あり、高卒後即プロになってもいいし、大学を経てプロになってもいい。どちらも選択できるのだ。 一方、欧州各国にはその仕組みはない。大学進学後にスポーツを行いたいのなら、その地域の小規模クラブで趣味レベルで嗜むことしかできないのだ。 だから欧州のプロサッカー、いやプロスポーツ選手はみな高卒だし、高卒後大学に進学してその後プロを目指すと言う選択肢自体が存在しないのだ。 理由2:
「ChatGPTって何?」と聞かれたら、取りあえずこの資料を渡せば良い──2022年11月末に登場してすぐに世間を驚かせたAI「ChatGPT」。自民党もAIには注目しており、「AIの進化と実装に関するプロジェクトチーム」を開催しているのだが、そこで東京大学の松尾豊教授が提出した資料が「分かりやすい」と話題だ。 資料が提出されたのは2月17日開催の第2回会議。「AIの進化と日本の戦略」というタイトルで、大規模言語モデルの仕組みやChatGPT、今後の日本の戦略について説明するものだ。同資料は塩崎彰久衆議院議員が投稿したnote記事からダウンロードできる。 ChatGPTについては、その学習方法から、高度な会話を実現できた理由、ChatGPTでできること、利用場面や受け取られ方まで網羅的にまとめられている。 例えば、高度な会話後実現できた理由のパートでは、従来のモデルには「生成分が人間の好み
はじめに 昨今の採用現場においてはソフトウェアエンジニアは売り手市場と言われ数年が経過していますが、2023年現在においても、デジタルトランスフォーメーションの加速により、これまでのIT企業の募集だけではなく、様々な企業がソフトウェアエンジニアを募集している状況にあると思います。 知り合いのリクルーターに話を聞くと、ここ最近米国のBigTech企業や、日本初のベンチャー企業のレイオフが目立ちますが、それはごく一部であり、多くの企業では引き続きソフトウェアエンジニアの需要は最も高く、この先10年以上はこの高い需要は続くだろうと言っていました。 引用元: 【2023年最新】厳選!エンジニア採用に強い15の採用媒体比較~最新市場動向や採用戦略も徹底解説 - type 私自身が就職した10年数年前は望んでソフトウェアエンジニアに就く人は理系出身のプログラミング趣向が強い人ばかりという印象でしたが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く