2024年8月15日のブックマーク (5件)

  • 『スキル機能』プロダクトゴール設定からリリースまでの道のり

    はじめまして、tebiki現場教育PdM/POをしている中屋です。今回は、春リリースされた新しい「スキル機能」のプロダクトゴール設定からリリースまでの道のりについて軽くまとめてみたいと思います。 新機能のスクラム開発を行っている皆様の参考になれば幸いです。 私について私はTebiki株式会社に2023年5月にPdM/POとしてジョインしました。前職では、スクラムマスターやエンジニアとして、B to Bのソフトウェア開発をしていました。 プロダクトについて現在Tebiki株式会社では、業界を問わない現場の人材教育にまつわる課題解決のためのプロダクト「tebiki 現場教育」を開発しています。 この度、この現場教育プロダクトに人材のスキルやその評価を管理できる「スキル機能」が追加されました。スキル機能では、従来のスキルマップで可視化されていたスキルの評価と教育コンテンツを紐づけて一元管理する

    『スキル機能』プロダクトゴール設定からリリースまでの道のり
  • 実装する前にきちんとドキュメントを読んだ方が良い、という話 - Qiita

    どうも、初めまして。 tokeと申します。 今回は自分の失敗談を話したい、と思います。 実装する前にドキュメントを読まないと、最後になってゴールに辿り着けない可能性がある そういう経験をしたのでご紹介します。 例えば、自社で集めた顧客のデータを活用し、Marketoにデータ連携したいとします。 marketoのAPIドキュメントを調べると、顧客の情報を登録する手段では以下の2パターンがあります。 POST /rest/v1/leads.jsonを使うパターン 以下のドキュメントにあるPOST /rest/v1/leads.jsonを使って、顧客のデータを送信し、連携する事ができます。 https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/lead-database/leads [※Marketoで

    実装する前にきちんとドキュメントを読んだ方が良い、という話 - Qiita
  • 『アジャイルチームによる目標づくりガイドブック』を読んだ。脳内にいくおさんをどうぞ。 - Mitsuyuki.Shiiba

    開発部全体を見てるあのすごい人が、ある1つのチームのマネージャだったらどんな感じなんだろうなぁ?仕事がやりやすいんだろうなぁ?って考えることがある。それが今、僕のいるチームで起こっている。 VPoEの経験もあるいくおさんと、カケハシの同じチームで仕事をしている。いくおさんが1つのチームのエンジニアリングマネージャとしてついてくれているのって、とても贅沢だなぁと思っている。実際に仕事はめちゃくちゃやりやすいし、それだけじゃなくて、僕やチームみんなの心の支えになってくれている。 いくおさんが書籍を出した そんないくおさんが書籍を出した。このがとてもいいなので、みんなに読んでほしい。どうしていくおさんと一緒だと仕事がやりやすいのか、なぜ自分の持ってる力が引き出されるのか、その理由がこのには書かれている。 www.shoeisha.co.jp いやー目標って苦手なんだけど・・・ 目標って聞く

    『アジャイルチームによる目標づくりガイドブック』を読んだ。脳内にいくおさんをどうぞ。 - Mitsuyuki.Shiiba
  • ウォーターフォールを見直して自チームに最適化した開発フローを構築する - カンムテックブログ

    エンジニアの佐野です。バンドルカードではポチっとチャージという後払いの機能を利用する際に年齢確認が必須となりました。通信キャリアや銀行との連携等によって年齢確認ができるようになっています*1。今回はこの機能の開発を題材に普段開発でどのようなことを考えて開発し、機能の開発ではどのようなフローを構築して進めていったかを書きます。 少し概要を書くと、件についてはウォーターフォールモデル "のような" 開発フローで行いました。事業上の理由でビッグバンリリースが必要でした。要件をしっかり決めてステップバイステップで開発を行いすべての機能を同時にリリースする...案件の性質を考えるとウォーターフォールが開発フローの候補の1つだと思っていたためです。ただそのまま一般的に思われているウォーターフォールを導入するのではなく、その欠点や面倒な点を解消しつつ、認識齟齬なしに設計と実装を行い、納期を死守しつつ

    ウォーターフォールを見直して自チームに最適化した開発フローを構築する - カンムテックブログ
  • ネストオブジェクトの罠 RE: TypeScriptで「選択肢」の定義をEnum的な定数にまとめる

    この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra

    ネストオブジェクトの罠 RE: TypeScriptで「選択肢」の定義をEnum的な定数にまとめる