こんにちは。SmartHRでPM（プロダクトマネージャー）をしているadachiです。 最近、面接などで「SmartHRではどのような流れでプロダクトを作っているのか」という質問をよくいただくので、このあたりでいちど現状を整理しておこうと思い立ちました。 SmartHRでは、全社的にスクラム開発を採用しています。このブログにも スクラムに関する記事 がたくさんあるのでぜひ読んでいただきたいのですが、今回はもう少し引いた視点から、顧客から受けた要望がどのように開発されていくのかという全体の流れを取り上げてみたいと思います。 なお、開発プロセスは状況に合わせて日々更新されていますので、今回ご紹介するのは2021年6月時点での内容になります。 プロダクトの構成 SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「本体」で、もうひとつは本体にアドオンする形で使える

トップ ナレッジ North Star Metric（ノーススターメトリック）とは？成功している企業はどのように指標を設定しているのか North Star Metric/ノースターメトリック North Star Metricは企業がビジネスグロースを目指すために設定をする重要指標のことです。 North Star Metricは企業がビジネスグロースを目指すために設定をする重要指標のことです。NETFLIX、Facebook、Amazonなどの世界を代表する大手企業ではこのNorth Star Metricを設定することで、企業、製品を大きく成長させることに成功しました。 日本ではまだあまり認知されていない指標です。 この記事ではNorth Star Metricとは何か、必要性について解説しますのでぜひ参考にして、ライバルよりも一歩先を進んでください。 North Star Metr

はじめに 2021年3月、実行中のコンテナに入ることができる「ECS Exec」がリリースされました。 これがリリースされるまで、ECSでコンテナに入る方法としては、 ECS on EC2 EC2にsshした後にdocker execする ECS on Fargate そもそもできない（Session Managerを使った非公式な方法は除く） といった状況だったため、このリリースでECS（特にFargate）でのデバッグやトラブルシューティングが一気に楽になりました。 ただ、人間欲深い生き物でして、実際にaws ecs execute-commandを使い始めると、今度は、 タスクIDをマネコン等で調べるのが手間なので対話形式で選択したい ECSとローカル間でファイルをコピーしたい（scpしたい） などの欲が新たに発生してしまいます。 「探せばそういうことができるツールがあるんじゃないの

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ

失敗談ですが、非IT部門にノーコードツールを導入しても効果はなかったです。原因は、非IT部門の開発者にDBの概念がなくデータをどのように管理すべきか知らなかったから。画面を作っただけのアプリが乱立してデータは分散。結局エクセル使うのと何ら変わらなかったというオチです。

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま

事業成長を加速させたエンジニアリングのウラ側 https://medpeer.connpass.com/event/211745/

単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や

2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型

画像を実装するには、以前はimg要素にsrcで画像を指定するだけで簡単でしたが、レスポンシブ対応、Retina対応、遅延読み込み、そしてさまざまな画像フォーマットの登場により、HTMLのコードが複雑になっています。 レスポンシブ対応のwebp画像を実装するHTMLのコードの完全版を紹介します。非サポート用のフォールバックにも対応しており、コピペで簡単に使用できます。 A picture element to load correctly resized webp images in HTML by Stefan Judis 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 2021年現在、画像の主要フォーマット 新しい画像フォーマットを読み込むための取り組み 最初のステップ: picture要素でwebp画像を読み込むには 完全版

クイックサマリー ‐ 私たちは一連の短い記事で開発者とデザイナーにとって有用なツールやテクニックを紹介しており、直近の記事ではCSS監査ツールとCSSジェネレータを取り上げました。この記事ではタブやテーブルからトグルやツールチップまで、信頼性の高いアクセシブルなコンポーネントを見ていきます。 目次 以下にすべてのアクセシブルなコンポーネントをアルファベット順に記載しました。目次をスキップするか、スクロールして1つずつお読みください。 :focus styles autocomplete buttons carousels "close" buttons content sliders checkboxes color systems color palettes comics component libraries cookie consent prompts dark mode data

このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。

Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか

現役の医師が手がけるプログラミングスクールが開校。医療現場の課題を自身で解決できる人を育てる、日本初の医療者向けプログラミングスクールが開校。プログラミング初心者でも、情熱があればOK。プログラミングを学びたいという情熱を持った同じ医療者達で、楽しく3ヶ月間のプログラミング教育入院しませんか？ 医療法人社団新潮会（本社：東京都足立区、理事長 北城 雅照）は、医者や看護師などをはじめとした医療者向けのプログラミングスクール「ものづくり医療センター」を2021年6月にトライアル開校を実施し、プログラミング教育入院希望者を募集致します。 医療法人社団新潮会（本社：東京都足立区、理事長 北城 雅照）は、医者や看護師などをはじめとした医療者向けのプログラミングスクール「ものづくり医療センター」を2021年6月にトライアル開校を実施し、プログラミング教育入院希望者を募集致します。 ■医療現場の課題を自

Do you want to subscribe to the notification email? Once subscribed, notification emails will be sent to your registered email address when the insight is republished or refreshed by the scheduling.

The Modelとは、マーケティング・インサイドセールス・外勤営業・カスタマーサクセスに至るまで、「各部門の情報を可視化・数値化し、それぞれの部門の特性や専門性を最大化することで生産性を最大化する」というビジネスモデルのことです。 The Modelが生まれた背景には、2つの時代変化があります。 ひとつは、購入検討の主導権が売る側から買う側に移ったことです。インターネットの発達などによって「購買プロセスの67%は、営業が接点を持つ前に終わっている」という時代になりました。買い手側による購入前の調査・評価が重要な意思決定の要素になっていることが伺えます。 もうひとつの時代変化は、SaaS企業やサブスクリプション型サービスなどを筆頭にサービス・商品を売ってからがビジネスの始まりになったことです。買い切り型のサービス・商品と異なり、契約更新型のサービス・商品は、顧客が成果を出せなければ契約が終