OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics

プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。

OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics

はじめに こんにちは、京セラコミュニケーションシステム　西田（@kccs_hiromi-nishida）です。 いつもは技術的な内容を投稿していますが、今回は技術Blogを毎月書くために心がけていることを投稿しようと思います！ 毎日投稿！とか毎週投稿！とかはちょっとハードルが高いな、けど継続して投稿したいと思っている方の一助になれば幸いです。 この記事の対象者 毎日Blog書くのはハードルが高いけど継続して投稿したいと思っている方 月に1本くらいはBlogを書きたいと思っている方 前置き 継続して書いているといっても月1記事程度なので、それほど参考になるかはわかりません。 そして、私に合った方法というだけで、皆さんに合うかはわかりません。 ただ、こんなやり方もあるよ！というのを見ていただき、少しでも誰かの参考になれば嬉しいです。 まずは記事の骨組みを作ろう！ 記事を作るとき、いきなり上から

LayerX 部門執行役員・AI・LLM事業部長 中村龍矢 2024/5/8 生成AI Conf

CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?

Octo STS は GitHub Access Token をよりセキュアに発行する Security Token Service です。 GitHub App と GitHub Action が公開されています。 CI などの自動化で用いる GitHub Access Token の管理を改善することが出来ます。 Octo STS はまだ非常に若いプロジェクトなため実用には時期尚早かもしれませんが、今後の発展が楽しみなプロジェクトです。 公式ドキュメントがまだ整備されておらず、日本語情報も皆無なため、この本を執筆しました。 この本では Octo STS とは何か、なぜ Octo STS が必要なのか、現状 Octo STS にどういった課題があるのか、どうやって使うのか、どのような仕組みで動いているのか、などについて紹介します。

最近、LLMにWeb Backendを書かせて遊ぶ、Hanabiというサービスを作っています。その開発過程で、前に試したLLMをAPIとして振る舞わせるアプローチを再検討したので、記事としてまとめました。 一年ちょっと前、私はChatGPTをWebフレームワークにしようと試みました...が、残念ながら全く実用的ではありませんでした。しかし、あれから一年、LLMは目覚ましい進歩で進化を遂げました。価格は下がり、速度も上がり、記憶容量の増加やRAGの発展など、もはや別物レベルで進化しています。 いまならもうちょっと実用的なヤツが作れるんじゃねってことで、色々な手法を面白がった再検討したまとめです。 余談ですが、一年前はLLM=ChatGPTという状況でしたね...懐かしい。ちょうどvicuna13Bが出た頃ですかね? ↓去年の記事(できれば読んでほしい)↓ 出来たもの 全部プロンプトに入れちゃ

ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design

Web開発において、ページの読み込み速度は非常に重要になります。 そのためにもブラウザのキャッシュは効率的なWebサイト運営に不可欠な機能です。 ブラウザのキャッシュには次のHTTPヘッダを設定することができます。 Expiresヘッダ Cache-Controlヘッダ Last-Modifiedヘッダ ETagヘッダ これらのキャッシュには強いキャッシュと弱いキャッシュで分類が可能です。 「Expires」「Cache-Control」は強いキャッシュであり、「Last-Modified」「ETag」は弱いキャッシュに分類できます。 強いキャッシュと弱いキャッシュ 強いキャッシュは設定された期間内は完全にローカルキャッシュを利用して、サーバーへのリクエストを行いません。 一方で弱いキャッシュはキャッシュされたリソースの検証が必要であり、ETagやLast-Modifiedヘッダを利用して

これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main

こんにちは、PdM（プロダクトマネージャー）の shu です。 最近は暖かくなり、散歩が気持ちよくなってきた季節ですね🌸 自分のおすすめの散歩コースは、日比谷駅付近から丸の内方面へ歩いていくコースです。 b8ta Tokyoでおもしろい製品を見て・試してみたり、KITTE の屋上から普段とは違う角度で東京駅をみてみたり、皇居の近くで桜を見てみたりと、「都会と自然」両方を楽しめるコースになっているのでおすすめです。 さて今回は、プロダクトマネジメントチーム（以下PMチームと略します）が取り組んでいる「Product Ops」についてご紹介します。Product Ops は、PMチームが抱える組織課題に対する実践的なアプローチです。その目的は、PMチームの生産性と開発品質を確実に高めていくことにあります。 本記事では、Product Ops の具体的なアプローチや進め方を、できる限り分かりや

SOLID原則を学び、完全に理解した！になるための本

最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力

電車内での「前リュック」にはアンチも多い 電車内でこんなアナウンスを耳にしたことがある人は多いだろう。「リュックサックなど大きなかばんをお持ちのお客さまは、手にさげてお持ちになるか、座席上の荷物置きをご利用ください」。学生のみならずビジネスシーンでもリュック利用者が多くなり、電車では「リュックは前に抱える」のがマナーとして定着しているかと思いきや、そのような案内はない。不思議に思い、鉄道会社に話を聞くと“前リュック”にNOを突きつける利用者が一定数いるのだという。SNSでも論争が巻き起こる、「電車内での正しいリュックの持ち方」を考えてみた。 【写真】外国人観光客のマナー違反に怒るスナックのママはこちら ＊　　＊　　＊ 混雑した電車内でリュックを背負ったままでいると、背後の通路をふさぎ、他の利用者にぶつかるなどしても気づきにくいため、一般的には前に抱えることがマナーとされている。記者は通勤の

NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2

こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに

エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する

概要ローカル LLM 初めましての方でも動かせるチュートリアル 最近の公開されている大規模言語モデルの性能向上がすごい Ollama を使えば簡単に LLM をローカル環境で動かせる Enchanted や Open WebUI を使えばローカル LLM を ChatGPT を使う感覚で使うことができる quantkit を使えば簡単に LLM を量子化でき、ローカルでも実行可能なサイズに小さくできる 1. はじめに大規模言語モデル（LLM）の数は数年前と比べてたくさん増えました。有名な LLM を使ったチャットサービスとして、OpenAI の ChatGPT や Anthropic の Claude、Google の Gemini などがありますが、これらのサービスの中で利用されている大規模言語モデルは公開されていません。 現状、様々な評価指標により LLM の性能が測定されていますが、