[{"content":"テクノロジーが進むたびに、「何が価値として流通するか」は入れ替わってきた。 印刷は知を複製し、放送は注意を集め、Webは発見を加速し、SNSは信頼を媒介にした。 そして生成AIは、これまで個人の頭の中に閉じていた“考えるプロセス”を、外に取り出して配れる状態にした。 ここで言う「流通」は、他人が持ち運べて、再利用できて、別の文脈に接続できることを指す。 結論だけでなく、問いの立て方、比較の仕方、仮説の分岐、判断材料の並べ方——そういう中間生成物が、いよいよ市場に出てきた。 その結果、価値の中心は「完成品」から「思考の質（と、それを扱う設計）」へ寄っていく。\n価値の形の変遷 価値はざっくり言うと、次の2つで決まりやすい。\n希少性：手に入れにくい、再現しにくい 交換のしやすさ：運べる・複製できる・見つけられる・比較できる テクノロジーは、この両方を継続的に動かしてきた。 複製が安くなれば、複製されるもの自体は希少ではなくなる。そのとき希少になるのは、別の何かだ。\nたとえば情報の複製コストが下がると、情報そのものよりも「どれを信じるか」「どれに時間を使うか」が希少になる。 さらに生成AIが“考える手順”まで出力するようになると、希少なのは次のようなものになる。\n良い問い（何を解くべきかの切り出し） 妥当な仮説（どの前提で、どこまで言えるか） 判断のセンス（リスクとリターンの見積もり、捨てる勇気） 価値は「結論」から、「結論に至るまでの思考の質」へ移っていく。\n価値として流通してきたこと テクノロジーは、価値の“運び方”を変える装置でもある。整理するとこんな対応になる。\n印刷（紙・出版） → 情報（複製可能な知） 放送（ラジオ・TV） → 注意（同時性による集中） インターネット（Web・検索） → 発見性（アクセスと探索） SNS（タイムライン・アルゴリズム） → 信頼／関係性（人を介した推薦） スマホ（常時接続） → 即時性（「今ここ」への接続） 生成AI → 思考（推論・文脈・判断の候補） 後ろに行くほど、「完成品」よりも「プロセス」に価値が寄っているのが分かる。 なぜなら、複製や配信が簡単になるほど、完成品は平均化しやすくなるからだ。\nAIが生み出すものは“思考” 生成AIが生み出すのは、知識というより“思考の途中経過”に近い。\n問いの立て方（何を比較するか、何を前提に置くか） 比較の軸（評価項目の整理） 仮説の分岐（Aならこう、Bならこう） 判断候補の列挙（選択肢とトレードオフ） 重要なのは、これを「答え」として受け取るより、「部品」として扱える点だ。 誰かの推論を起点に、別の人が続きを書ける。別の条件を足して作り直せる。 接続と編集ができるとき、思考は“流通可能な資産”になる。\n一方で、思考は文脈が欠けるとすぐ壊れる。\n目的が違う 前提が違う 判断基準が違う だからこそ、思考だけを単体で回すのではなく、「この思考が成立している条件」もセットで流通させる必要がある。\n転換点：AIがもたらした質的変化 AIは単なる検索や要約ではなく、次のような“思考の動き”を、即時に、何度でも生成する。\n推論（筋道を作る） 仮説生成（可能性を枝分かれさせる） 視点の切り替え（別の評価軸を持ち込む） これは「情報の自動化」というより、思考の量産化に近い。 ここで言う「思考」は、人間の内面そのものではない。 問いの立て方、比較、仮説の分岐、判断候補の並べ方といった中間生成物を指している。 正しさや主体性はさておき、外に出て、再利用できる形になったことが大きい。\n流通単位の変化 流れはこう変わる。\nBefore：情報 → 人が考える → 意思決定 After：思考（候補が大量に出る） → 人が選ぶ → 意思決定 考えるコストがゼロに近づくほど、相対的に重くなるのは次の2つだ。\n選ぶこと（どれを採用するか） 責任を持つこと（その選択の結果を引き受けること） 流通速度と量の非対称性 AI以後の特徴は、だいたいここに集約される。\n流通速度：ほぼ即時 流通量：理論上無限 品質：平均化・最適化されやすい（それっぽい答えが増える） 結果として起きやすいことはこうだ。\n「よく考えられた平均解」が溢れる 独自性は結論より出発点（問い・前提・目的）に宿る 価値は「生成」から「編集・検証・選別」へ寄る 思考が流通する条件 思考を資産として扱うには、最低限のインフラがいる。少なくとも次が揃っていないと、ノイズとして消費される。\n出所が分かること：誰の思考か／どこから来たか 条件が分かること：目的・前提・制約・判断基準 検証できること：根拠にアクセスできる／再現できる 再利用できること：自分の文脈に合わせて編集可能 この条件に最も近い形で流通してきたのが、プログラム（コード）だと思う。 コードは前提や手順を固定し、入力と出力の関係を他人にも再現可能にする。 ウェブアプリはそれを公開し、誰でも同じ条件で試せる場を作る。 OSSはさらに、改変できる形で積み重ねられるようにして、思考の流通速度を跳ね上げた。\nこの条件が満たされるほど、思考は「気の利いた文章」ではなく、再配布できる価値になる。\n人間が握る価値のパラメータ 思考が流通する時代に、人間側に残る価値は何か。自分は主にここだと思う。\n問いの設定：何を解くべきかを定義する 採用の決断：どの思考に賭けるかを選ぶ（＝責任を取る） 文脈・経験：前提を見抜く／違和感に気づく／外れたときの損失を見積もる AIは思考を大量に生成できる。 でも、どれを採用し、どう運用し、結果を引き受けるかは人間に残る。 だから価値は、「思考を作ること」よりも、思考の流通を設計し、質を保証し、文脈を接続できる人に集まっていく。\n組織体制の再定義：少人数・高生産性が成立する理由 思考が流通する時代、組織の在り方も根本から変わる可能性がある。 従来の分業体制が前提としていた「職能の固定」「工程の分断」が、思考の流通によって再編されるのではないだろうか。\n従来の組織モデル 日本の典型的な開発チーム（7〜10人構成）は、次のような職能分担を前提にしていた。\n職能 人数 PM / PjM 1名 エンジニア 4〜6名 デザイナー 1〜2名 QA 1名 合計 7〜10名 この構造が生む問題として、次のようなものが考えられる。\n思考が分断される（誰も全体を握れない） 調整コストが膨張する（伝言ゲーム） 責任の所在が曖昧になる（誰が最終判断を下すのか） 新しい組織モデル：職能の再定義 思考が流通する前提では、職能そのものが次のように再構成される可能性がある。\n新職能 役割 思考設計者（Planner / Architect） 目的・前提・完了条件を定義する 実行オーケストレーター CLI / AI / 外部ツールを繋ぐ 検証・責任保持者 実行結果の評価と判断を下す 従来の「エンジニア」「デザイナー」「PM」といった職能は、ここでは役割として溶けていくと考えられる。 なぜなら、実装やデザインの大半は自動化・外部化できる一方で、 「何を作るべきか」「どこまで作ればOKか」「失敗とは何か」を定義できる人が決定的に重要になる可能性が高いからだ。\n最適なチームサイズ このモデルでは、1チーム2〜4人が最適になると考えられる。\n5人を超えると、思考の共有コストが跳ねる 思考が分散し、調整が再び必要になる 意思決定の速度が落ちる 重要なのは、「人を増やす＝チームを増やす」ではなく、 「思考パッケージ」×「小さな実行チーム」を複製することだ。\n組織自体がプロダクトになる。 チームを増やすとは、思考の設計と実行の単位を再配布することに等しいと言える。\n職能の変化：消えるもの、残るもの 消える職能\nコーディング専業 ワイヤー専業 テスト専業 これらは自動化・外部化の対象になる。\n残る／進化する職能\n判断を下す人 完了条件を定義できる人 失敗を限定できる人 人は減るが、1人あたりの責任は重くなると考えられる。 思考が流通することで、「考える」コストは下がるが、 「選ぶ」「決める」「責任を持つ」コストは相対的に重くなるだろう。\nスケールの仕組み 従来の組織では、案件が増えると人を増やし、チームを肥大化させる傾向があった。 その結果、調整コストが指数的に増え、スピードが落ちるという問題が生じやすい。\n新しいモデルでは、次のようにスケールする可能性がある。\n思考パッケージを作る（目的・前提・判断基準・完了条件） 小さなチームで検証する（2〜4人） 再利用可能にする（ログ・テンプレート・フレームワーク） 別チームが同じパッケージを使って並行実行する 人が増えずに案件が増える構造を作れるかが、組織設計の核心になるのではないだろうか。\n補足 「注意」という言葉について ここで言う注意は心理用語というより、誰の時間と視線がどこに集まるかという意味で使っている。 マスメディアは同時性によって関心を一点に集め、その集合的関心が広告や影響力として価値化された。 「集合的関心」「同時体験」と言い換えてもほぼ同義。\nプラットフォームビジネスについて Web以降、プラットフォームが強くなったのは、接続コストが下がり、ネットワーク効果とデータ最適化が極端に効くようになったから。 「場とルールを用意して取引や交流を促す」構造自体は昔からあるが、Webはそれを桁違いにスケールさせた。\nOSS的な流通の派生 OSSの作法（issue化、共有、フォーク、改善）をなぞる形で、アイディアや事業構想を“再編集できる部品”として扱う動きも出てきた。 思考が流通単位になると、このOSS的な流通は自然に派生しやすい。\n","permalink":"https://konumaru.com/202512/%E6%80%9D%E8%80%83%E3%81%8C%E6%B5%81%E9%80%9A%E3%81%99%E3%82%8B/","summary":"\u003cp\u003eテクノロジーが進むたびに、「何が価値として流通するか」は入れ替わってきた。\n印刷は知を複製し、放送は注意を集め、Webは発見を加速し、SNSは信頼を媒介にした。\nそして生成AIは、これまで個人の頭の中に閉じていた“考えるプロセス”を、外に取り出して配れる状態にした。\nここで言う「流通」は、他人が持ち運べて、再利用できて、別の文脈に接続できることを指す。\n結論だけでなく、問いの立て方、比較の仕方、仮説の分岐、判断材料の並べ方——そういう中間生成物が、いよいよ市場に出てきた。\nその結果、価値の中心は「完成品」から「思考の質（と、それを扱う設計）」へ寄っていく。\u003c/p\u003e","title":"“思考”が“流通”する"},{"content":"ことの発端 AIめっちゃ発展してきているし、会社を全部AIで回そうと思ったらどういう構成になるんだ？と思って、いろいろ作ってみていた。それに伴ったドキュメンテーションなども整え始めていた。\n「あれ？会社ってどういう構造だ？」ってなったので、ちょっと調べてみた。（ことをまとめる）\n会社の構造 会社 ├─ ビジネス構造 │ └─ 事業 → プロダクト → プロジェクト ├─ オペレーション構造 │ └─ 業務 → 手順 → 作業 ├─ 組織・ガバナンス構造 │ └─ 部門 → チーム → ロール ├─ テクノロジー構造 │ └─ 基盤 → システム → 機能 └─ コーポレート構造 さらにビジネスだけフォーカスるると、 会社 └─ ビジネス（価値と収益の設計） └─ 事業（市場単位の価値提供） ├─ 新規事業（立ち上げフェーズの事業） │ └─ プロダクト（提供価値） │ └─ プロジェクト（開発・検証） └─ 既存事業 ├─ 事業前提（Understanding） │ ├─ 市場定義 │ ├─ 顧客モデル │ ├─ 競争環境 │ └─ 制約条件 ├─ 事業戦略（Design） │ ├─ 価値仮説 │ ├─ ポジショニング │ ├─ 成長仮説 │ └─ 撤退条件 └─ プロダクト └─ プロジェクト あえて組織・人の話を切り分けて、ビジネスの構造にフォーカスしてみた。このほうが個人的に好み。\n","permalink":"https://konumaru.com/202512/%E4%BC%9A%E7%A4%BE%E3%81%AE%E7%B5%84%E7%B9%94%E6%A7%8B%E9%80%A0%E3%81%A3%E3%81%A6%E3%81%A9%E3%81%86%E3%81%AA%E3%81%A3%E3%81%A6%E3%81%9F%E3%81%A3%E3%81%91/","summary":"\u003ch2 id=\"ことの発端\"\u003eことの発端\u003c/h2\u003e\n\u003cp\u003eAIめっちゃ発展してきているし、会社を全部AIで回そうと思ったらどういう構成になるんだ？と思って、いろいろ作ってみていた。それに伴ったドキュメンテーションなども整え始めていた。\u003c/p\u003e","title":"会社の組織構造ってどうなってたっけ"},{"content":"この記事の狙い SaaSの新機能や新規プロダクトを企画・探索していると、MVPの試作や顧客ヒアリングで得られる現実の気づきが増えるほど、方向性が発散して「何に収束すべきか」が分からなくなることがよくあります。\n本記事は、その収束を助けるための「テンプレート」を短く紹介するものです。あくまでテンプレート（書式）そのものの紹介であり、プロジェクトごとの深掘りドキュメントではありません。チームで同じフォーマットを定期的に見直すことで、仮説検証の学びを一本の製品方向性へ束ねることを意図しています。\n今回は、Zendeskが紹介している「ポジショニング・ステートメント（Positioning Statement）」の構造を利用します。\n使うテンプレート：Zendeskのポジショニング・ステートメント 以下は、よく知られたポジショニング・ステートメントの構造を日本語の記入ガイド付きで示したものです。空欄に埋めるだけで、ターゲット・課題・カテゴリ・主要価値・代替・差別化を一枚に収められます。\n顧客への価値を中心に伝えたいとき（Zendeskの構造） 出典: https://www.zendesk.co.jp/blog/positioning-statement-examples/\n[対象顧客] にとって、 [製品・サービス名] は [製品カテゴリ] であり、 [顧客の課題] を解決します。 その結果、顧客は [製品がもたらす具体的なベネフィット] を得ることができます。 記入例（例示） 競合比較型：\nリモートワークに課題を感じる中小企業 にとって、 TeamSync は チームコラボレーションツール です。 社員のタスク管理とコミュニケーションを一元化し、生産性を向上させます。 Slack と異なり、私たちの製品は 進捗管理機能が標準搭載されている のが特徴です。 顧客価値型：\nリモートワークに課題を感じる中小企業 にとって、 TeamSync は チームコラボレーションツール であり、 チーム内の情報共有不足を解決します。 これにより、社員がよりスムーズに協働し、業務効率を高めることができます。 いつ・どう使うか（最小の運用） タイミング：MVPの初版〜顧客ヒアリングの1〜2サイクルごとに更新。 オーナー：PM（または企画責任者）が編集責任を持ち、週次でレビュー。 評価：変更履歴を残し、直近2週の学びが反映されているかを確認。 よくある失敗と回避策 失敗：対象が広すぎる → 回避：採用した/失注した具体顧客の共通点で狭める。 失敗：価値が曖昧（早い/安いなど抽象）→ 回避：数値/行動で表せる結果に置き換える。 失敗：カテゴリが独自語 → 回避：既知カテゴリに寄せ、独自性は差別化で表現。 失敗：差別化が機能列挙 → 回避：ユースケースと成果に翻訳して一言で言い切る。 このテンプレートは、議論を「何のために、誰に、どんな価値を、どう勝つか」に収束させるための最低限の骨子です。詳細な市場調査やPRDの代替ではなく、それらを束ねる“方位磁針”として運用してください。\n","permalink":"https://konumaru.com/202510/%E6%96%B0%E8%A6%8F%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%81%AE%E6%96%B9%E5%90%91%E6%80%A7%E3%82%92%E5%8F%8E%E6%9D%9F%E3%81%95%E3%81%9B%E3%82%8B%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88zendesk-positioning-statement/","summary":"\u003ch2 id=\"この記事の狙い\"\u003eこの記事の狙い\u003c/h2\u003e\n\u003cp\u003eSaaSの新機能や新規プロダクトを企画・探索していると、MVPの試作や顧客ヒアリングで得られる現実の気づきが増えるほど、方向性が発散して「何に収束すべきか」が分からなくなることがよくあります。\u003c/p\u003e","title":"新機能/新規プロダクトの方向性を収束させるテンプレート（Zendesk Positioning Statement）"},{"content":"AI/MLプロジェクトの技術検証（PoC）は、多くの企業で行われているものの、その成果が属人的になりがちで、組織の知識資産として蓄積されないケースが散見されます。せっかく時間とコストをかけて実施した検証結果が、担当者の頭の中だけに残り、チーム全体の学びにならないのはもったいない話です。\n本記事では、技術検証を確実に資産化するための実践的なアプローチとして、実験計画書テンプレートの活用方法と、R\u0026amp;Dフェーズごとの考え方を紹介します。これにより、検証プロセスの標準化と知識の組織的な蓄積を実現できます。\nなぜテンプレートが必要か 技術検証を始める前に、実験計画書のテンプレートを使うことには以下のメリットがあります。\n手戻りの防止 実装に着手してから「そもそも何を検証したかったんだっけ？」となることを防げます。最初に目的と成功基準を明確にすることで、無駄な試行錯誤を減らせます。\n関係者との合意形成 技術検証の成果は、エンジニアだけでなくビジネスサイドにも影響します。事前にアウトプットイメージを共有し、期待値を揃えることで、後々の認識齟齬を防げます。\n事前の価値検証 手を動かす前に「この検証で本当に価値のある結果が得られそうか」を確認できます。必要なデータが取得可能か、技術的に実現可能かを事前にチェックすることで、リソースの無駄遣いを防げます。\n明確な成功基準の設定 「どんな結果が望ましいのか」「どんなファクトが欲しいか」を事前に定義することで、検証の成否を客観的に判断できるようになります。\n実験計画書テンプレート 以下は、技術検証を開始する前に記載すべき項目をまとめたテンプレートです。このテンプレートを使うことで、検証の目的から結果の考察まで、一貫性のあるドキュメントを作成できます。\n# 実験計画書（PoC） ## 1. 背景 \u0026lt;!-- このPoCを行うことになった背景を書いてください。 - この取り組みの起因となったモチベーション - なぜPoCが必要か - どのような業務に関係しているか --\u0026gt; ## 2. 目的 \u0026lt;!-- PoCの目的やPoCを通じて何を明らかにしたいかを書いてください。 - ビジネスへの貢献仮説 例：「カスタマーサポートの問い合わせ分類作業を自動化できる可能性を検証」 例：「商品レビューから改善点を自動抽出し、分析業務を効率化できるか検証」 例：「需要予測モデルにより在庫管理の意思決定を支援できるか検証」 - 成功基準 例：「問い合わせ分類モデルが実用レベルの精度を達成すること」 例：「レビューから抽出した改善点が人手での分析結果と概ね一致すること」 例：「予測モデルの精度が現行の経験則による予測を上回ること」 --\u0026gt; ## 3. サマリー（実施概要） \u0026lt;!-- PoCの全体像を簡潔にまとめてください。 - 使用データ - 技術検証の評価概要 - 技術的なアプローチ - 成果物の想定（例：モデル、レポート、可視化など） --\u0026gt; ## 4. ビジネス仮説 \u0026lt;!-- ビジネス/業務視点での仮説を書いてください。 目的の例に対応する仮説： - 問い合わせ分類の場合 例：「問い合わせ内容の8割は定型的なパターンに分類できる」 例：「件名と本文の最初の数行で、問い合わせカテゴリを判定できる」 - 商品レビュー分析の場合 例：「ネガティブレビューには具体的な改善要望が含まれている」 例：「同じ改善点は複数のレビューで繰り返し言及される」 - 需要予測の場合 例：「過去の販売傾向と季節性から、将来の需要を予測できる」 例：「プロモーション実施時期と売上には明確な相関がある」 --\u0026gt; ## 5. 分析仮説 \u0026lt;!-- ビジネス仮説を確かめるために、どのようなデータのファクトを積み上げるかを書いてください。 - 問い合わせ分類の仮説を確かめるために 例：「過去1年分の問い合わせデータをカテゴリ別に集計し、上位10カテゴリで全体の何割を占めるか確認」 例：「テキストの文字数と分類精度の関係を分析し、最初の何文字で判定可能か検証」 - 商品レビュー分析の仮説を確かめるために 例：「星評価別にレビューテキストの長さと具体性を分析し、低評価ほど詳細な記述があるか確認」 例：「頻出キーワードをクラスタリングし、同じトピックが複数回出現しているか定量化」 - 需要予測の仮説を確かめるために 例：「過去2年分の日次売上データから、曜日・月次の周期性を時系列分析で確認」 例：「プロモーション実施日の前後2週間の売上変化を統計的に検定」 --\u0026gt; ## 6. 技術的アプローチ \u0026lt;!-- 分析や予測の方法を具体的に書いてください。 - 問い合わせ分類の場合 例：「TF-IDFでテキストをベクトル化し、Random Forestで多クラス分類」 例：「BERTで文章埋め込みを作成し、コサイン類似度でカテゴリマッチング」 - 商品レビュー分析の場合 例：「感情分析モデルでネガティブレビューを抽出後、LDAでトピック抽出」 例：「GPTを使った要約で改善点を自動抽出し、頻出度でランキング」 - 需要予測の場合 例：「Prophet を使った時系列予測で、トレンドと季節性を分解」 例：「XGBoostで特徴量エンジニアリング（曜日、月、プロモーション有無）を行い予測」 --\u0026gt; ## 7. 実験内容 \u0026lt;!-- 実際にやること・ステップを書いてください。 - 問い合わせ分類の実験ステップ 例：「Step1: 過去6ヶ月分の問い合わせデータ（約10,000件）を収集」 例：「Step2: データを8:2で訓練/検証に分割し、カテゴリラベルを付与」 例：「Step3: 複数のモデルを比較し、最も精度の高いものを選定」 - 商品レビュー分析の実験ステップ 例：「Step1: 直近1年分のレビューデータ（星1-2の低評価500件）を抽出」 例：「Step2: 手動で50件をサンプリングし、改善点を人力で抽出（正解データ作成）」 例：「Step3: 自動抽出結果と正解データを比較し、精度を評価」 - 需要予測の実験ステップ 例：「Step1: 過去2年分の日次売上データとプロモーションカレンダーを統合」 例：「Step2: 直近3ヶ月をテストデータとして、それ以前で学習」 例：「Step3: 予測精度をMAPEとRMSEで評価し、現行手法と比較」 --\u0026gt; ## 8. 実験結果 \u0026lt;!-- 得られた数値・成果を記載してください。 - 問い合わせ分類の結果例 例：「分類精度85%を達成、上位5カテゴリで92%の精度」 例：「処理時間は1件あたり0.5秒、バッチ処理で1000件/分が可能」 - 商品レビュー分析の結果例 例：「改善点の自動抽出精度は75%（人手の抽出結果との一致率）」 例：「同一トピックの集約により、改善点を20項目から5項目に要約成功」 - 需要予測の結果例 例：「MAPE 15%で予測可能（現行の経験則では25%）」 例：「プロモーション期間の予測精度が特に改善（誤差率30%→12%）」 --\u0026gt; ## 9. 考察 \u0026lt;!-- 結果から分かったこと、意味のある気づきを書いてください。 - 問い合わせ分類の考察例 例：「仮説通り8割以上のパターン化が可能で、業務の大幅な効率化が見込める」 例：「誤分類の多くは複合的な問い合わせで、これらは人手での対応が必要」 例：「次ステップ：3ヶ月間の試験運用を経て、本番導入を検討」 - 商品レビュー分析の考察例 例：「ネガティブレビューから具体的な改善点を抽出でき、仮説は概ね正しかった」 例：「月次レポート作成時間を8時間→2時間に短縮可能」 例：「次ステップ：リアルタイムダッシュボード化を検討」 - 需要予測の考察例 例：「季節性とプロモーション効果を適切にモデル化でき、予測精度が大幅改善」 例：「在庫切れリスクを30%削減、過剰在庫を20%削減できる見込み」 例：「次ステップ：商品カテゴリ別のモデル構築で更なる精度向上を目指す」 --\u0026gt; このテンプレートを活用することで、検証の全体像を俯瞰的に把握でき、抜け漏れのない技術検証を実施できます。特に「ビジネス仮説」と「分析仮説」を分けて記載することで、ビジネス視点とデータ視点の両面から検証を設計できる点が重要です。\nただい、テンプレート内に記述している例はあくまで例なので、実務ではより具体的な内容を言語化する必要がある。\n技術検証のフェーズを理解する AI/MLプロジェクトのR\u0026amp;Dは、単一の「技術検証」として扱うのではなく、以下のようなフェーズに分けて考えることが重要です。各フェーズごとに期待するアウトプットと成功基準が異なるため、現在どのフェーズにいるのかを明確にすることで、適切なリソース配分と期待値調整が可能になります。\n1. デスクリサーチ 最新の論文調査や先行事例の収集を行うフェーズです。技術的な実現可能性と、業界のベストプラクティスを把握することが目的です。\n2. ユーザーリサーチ 実際のユーザーニーズを把握するフェーズです。ユーザーヒアリングやデータ分析を通じて、解決すべき課題の本質を理解します。\n3. オフライン検証（技術検証） 実際にモデルを構築し、過去データで性能を検証するフェーズです。本記事で紹介したテンプレートは、主にこのフェーズで活用されます。\n4. オンライン検証（A/Bテスト, PoC） 実環境で小規模に検証を行うフェーズです。オフライン検証で良好な結果が得られたモデルが、実サービスにどうすることで実際のビジネスインパクトを生むかを確認します。\n5. サービス化 検証結果を踏まえて、本番環境への実装や既存サービスへの組み込みを行うフェーズです。スケーラビリティや運用面の課題解決が主な焦点となります。\nまとめ AI/ML技術検証を組織の資産として蓄積するには、実験計画書テンプレートの活用と、R\u0026amp;Dフェーズの明確な理解が不可欠です。これらを実践することで、属人的な知識を組織知に変換し、チーム全体の技術力向上につなげることができます。\n技術検証は一見コストに見えるかもしれませんが、適切に管理・蓄積すれば、組織の競争力を高める重要な資産となります。ぜひ、今回紹介したアプローチを活用して、効果的な技術検証の実施と知識の資産化に取り組んでみてください。\n","permalink":"https://konumaru.com/202508/ai-ml%E3%81%AE%E6%8A%80%E8%A1%93%E6%A4%9C%E8%A8%BC%E3%82%92%E8%B3%87%E7%94%A3%E5%8C%96%E3%81%99%E3%82%8B/","summary":"\u003cp\u003eAI/MLプロジェクトの技術検証（PoC）は、多くの企業で行われているものの、その成果が属人的になりがちで、組織の知識資産として蓄積されないケースが散見されます。せっかく時間とコストをかけて実施した検証結果が、担当者の頭の中だけに残り、チーム全体の学びにならないのはもったいない話です。\u003c/p\u003e","title":"AI/MLの技術検証を資産化する"},{"content":"Function Storeとは Function Storeは、\nなんらかの単一の処理やAPIエンドポイントを「Function」として提供し、\nユーザーが目的を定義すると、\nエージェントが必要な「Function」を組み合わせることで、\nその目的を達成することができるプラットフォームです。\n主な特徴：\nプロンプトやコードで作成されたEndpointを持つ単一の処理をFunctionとして提供 プロンプトが書ければ誰でも開発者になれる低い参入障壁 ユーザーにはFunctionの利用量に応じた従量課金システムを採用 開発者には開発されたFunctionの利用料に応じた報酬システムを採用 なぜ必要か 開発者エコシステムの拡大 プロンプトという誰でも作れるアプリを流通させるマーケットを作る イノベーションの加速 課題定義 → 開発 → 実現のプロセスを誰でも高速に実現できるようにすることで、イノベーションのジレンマを潰す コスト効率の向上 LLMに対する多様な処理を集約することで、個々の利用に比べてハードウェア、ソフトウェアの両面からコスト効率化を目指す ビジネスモデル graph LR A[開発者] --\u003e|Function開発・提供| B[Function Store] B --\u003e|Combined Function（Agent）の提供| C[ユーザー] C --\u003e|利用料支払い| B B --\u003e|報酬支払い| A C --\u003e|目的定義・利用| B 類似サービスの問題点 AppStoreの課題 高い参入障壁 アプリ開発には専門知識と多大な時間投資が必要 審査プロセスが厳格で時間がかかる 固定的な価格設定 柔軟な料金体系の設定が困難 小規模な機能に対する適切な価格設定が難しい 大規模アプリ偏重 小規模な機能や特定のニーズに特化したソリューションが埋もれやすい 検索の困難性 多様性が上がりすぎて、マーケットからアプリを見つけることはできない ランキングも流動性が悪く、参考にならない Zapierの課題 複雑な自動化設定 非技術者にとって高度な自動化の設定が困難 限定的な統合オプション 特定のサービスやアプリケーションに依存 スケーラビリティの制限 大量の処理や複雑なワークフローへの対応に制限がある 利用者側にメリットがない 基本サブスクでコストを払うのみで、リターンはない GPTs（OpneAI）の課題 利用者がテック寄りの人間に偏ってる ニッチなニーズが生まれない GPTs開発者への報酬がない 競合はあるか まだわからない。\nAppleは頑張ってくれたらいいなって思ってる。Siri + ショートカット機能がユーザーのニーズには近いと思っている。\nFunction Storeの具体的な使用例 1. 不動産業者向け物件写真最適化システム ユーザー：中小規模の不動産会社 目的：「物件の写真をアップロードし、自動で色調整、不要物の削除、ウォーターマーク追加を行う」 使用するFunction： 画像アップロード Function 自動色調整 Function 不要物検出・削除 Function（AI画像生成技術を使用） ウォーターマーク追加 Function 結果：プロ級の物件写真を簡単かつ迅速に作成でき、物件の魅力を高められる 2. 飲食店向け口コミ分析ダッシュボード ユーザー：個人経営の飲食店オーナー 目的：「Google Maps、食べログ、インスタグラムの口コミを収集し、感情分析を行い、トレンドをグラフ化する」 使用するFunction： Google Maps口コミ取得 Function 食べログ口コミ取得 Function インスタグラム投稿取得 Function テキスト感情分析 Function トレンド分析 Function グラフ生成 Function 結果：複数プラットフォームの口コミを一元管理し、客観的な店舗評価とトレンドを把握できる 3. 多言語カスタマーサポートチャットボット ユーザー：グローバル展開を目指すEコマース企業 目的：「顧客からの問い合わせを自動で言語検出し、適切な言語で回答を生成。必要に応じて人間のオペレーターに引き継ぐ」 使用するFunction： 言語検出 Function 機械翻訳 Function（入力を英語に統一） 意図分類 Function（問い合わせ内容を分類） FAQ検索 Function 回答生成 Function 人間オペレーター引継ぎ判定 Function 翻訳 Function（回答を元の言語に翻訳） 結果：24時間体制の多言語サポートを低コストで実現し、顧客満足度を向上 4. 個人投資家向けAI投資アシスタント ユーザー：副業で株式投資を始めた会社員 目的：「指定した銘柄の財務データと市場動向を分析し、投資判断をサポートする」 使用するFunction： 株価データ取得 Function 財務データ取得 Function ニュース記事収集 Function センチメント分析 Function（ニュース記事の感情分析） テクニカル分析 Function ファンダメンタル分析 Function 投資判断生成 Function 結果：プロ並みの分析と判断材料を得られ、個人投資家の意思決定をサポート Appendix: Function Store 構想の一枚絵 作：unsu0707\n","permalink":"https://konumaru.com/202505/functionstore%E6%A7%8B%E6%83%B3/","summary":"\u003ch2 id=\"function-storeとは\"\u003eFunction Storeとは\u003c/h2\u003e\n\u003cp\u003eFunction Storeは、\u003c/p\u003e\n\u003cp\u003eなんらかの単一の処理やAPIエンドポイントを「Function」として提供し、\u003c/p\u003e\n\u003cp\u003eユーザーが目的を定義すると、\u003c/p\u003e\n\u003cp\u003eエージェントが必要な「Function」を組み合わせることで、\u003c/p\u003e","title":"FunctionStore構想"},{"content":"概要 SpreadsheetでLLMを使えるようにした Crawlerと組み合わせることでwebページの要約、情報抽出ができる Prompt Engineering頑張るとかなり使えた なぜ作ろうと思ったのか 元々はChatGPT in Google Sheets™ and DocsというChrome拡張を使っていて、Open AIのAPI Keyさえあれば便利に使えた。\nのだが、最近独自の課金体系を設けるようになってしまったので、それはちょっと、、と思って自作することにした。\nただし、独自の課金体系があるくらいには機能が充実しているっぽく、いろいろなユースケース向けのプリセットやGoogle Docs, Google Slidesにも対応している。 あとはユーザーがAPI Keyを不要にすることで、利用する敷居を下げている。\n自作GPT関数の作り方 作り方といってもSpreadsheetのスクリプトエディタにコードを書くだけである。\nAPI KeyはOpenAIのサイトで取得し、GASのスクリプトプロパティに設定する。\nfunction GPT(prompt, temperature=1.0, maxToken=1024) { //スクリプトプロパティに設定したOpenAIのAPIキーを取得 const apiKey = PropertiesService.getScriptProperties().getProperty(\u0026#39;API_KEY\u0026#39;); //OpenAIのAPIで利用するモデルとしてgpt-4oを設定 const model = \u0026#39;gpt-4o\u0026#39;; //GPTのAPIのエンドポイントを設定 const apiUrl = \u0026#39;https://api.openai.com/v1/chat/completions\u0026#39;; //GPTに投げるメッセージを定義(ユーザーロールの投稿文のみ) const messages = [ {\u0026#39;role\u0026#39;: \u0026#39;user\u0026#39;, \u0026#39;content\u0026#39;: prompt} ]; //OpenAIのAPIリクエストに必要なヘッダー情報を設定 const headers = { \u0026#39;Authorization\u0026#39;:\u0026#39;Bearer \u0026#39;+ apiKey, \u0026#39;Content-type\u0026#39;: \u0026#39;application/json\u0026#39;, \u0026#39;X-Slack-No-Retry\u0026#39;: 1 }; //GPTのモデルやトークン上限、プロンプトをオプションに設定 const options = { \u0026#39;muteHttpExceptions\u0026#39; : true, \u0026#39;headers\u0026#39;: headers, \u0026#39;method\u0026#39;: \u0026#39;POST\u0026#39;, \u0026#39;payload\u0026#39;: JSON.stringify({ \u0026#39;model\u0026#39;: model, \u0026#39;max_tokens\u0026#39; : maxToken, \u0026#39;temperature\u0026#39; : temperature, \u0026#39;messages\u0026#39;: messages}) }; //OpenAIのGPTにAPIリクエストを送り、結果を変数に格納 const response = JSON.parse(UrlFetchApp.fetch(apiUrl, options).getContentText()); return response.choices[0].message.content; } function test() { console.log(GPT(\u0026#34;test\u0026#34;)); } 以下の部分で様々なPrompt Engineeringを行うことができる。\n例えば、テーブル分析に向いてる関数、要約に向いてる関数、質問応答に向いてる関数など作ることができると思う。\nconst messages = [ {\u0026#39;role\u0026#39;: \u0026#39;user\u0026#39;, \u0026#39;content\u0026#39;: prompt} ]; Spreadsheetでの使い方 使い方は簡単で、セルに=GPT(\u0026quot;hogehoge\u0026quot;)と入力するだけである。\nその他のセル情報を活用したい場合は、\n=GPT($B2\u0026amp;\u0026#34;から\u0026#34;\u0026amp;C$1\u0026amp;\u0026#34;を簡潔に取得してください\u0026#34;) のようにすることで、セルの情報を活用することができる。\nまた、以下のコードと組み合わせることで、webページのテキスト情報を抽出し、要約や情報抽出ができる。\n=ARRAYFORMULA(TRIM(REGEXREPLACE(TEXTJOIN(\u0026#34; \u0026#34;, TRUE, IMPORTXML(A2, \u0026#34;//body//text()[not(ancestor::script)][not(ancestor::style)][normalize-space()]\u0026#34;)), \u0026#34;\\s+\u0026#34;, \u0026#34; \u0026#34;))) 使い方のイメージは以下の通り。\n使い方 Tips Webページごとに情報構造が異なるので、Crawlerの設定を変えることで、情報抽出の精度を上げることができる。 抽出したい情報に併せてGPT関数内のプロンプトをカスタマイズすることで、より適切な情報抽出ができる。 e.g. =GPT($B2\u0026amp;\u0026quot;から\u0026quot;\u0026amp;D$1\u0026amp;\u0026quot;をYYYY年mm月dd日（月）形式で該当部分の年月日、曜日のみを出力してください\u0026quot;) おまけ Perplexity version function Perplexity(prompt, temperature = 0.2, maxTokens = 2048) { // スクリプトプロパティに設定した Perplexity AI の API キーを取得 const apiKey = PropertiesService.getScriptProperties().getProperty(\u0026#39;PERPLEXITY_API_KEY\u0026#39;); // Perplexity AI の API で利用するモデルを設定 const model = \u0026#39;llama-3.1-sonar-small-128k-online\u0026#39;; // Perplexity AI の API のエンドポイントを設定 const apiUrl = \u0026#39;https://api.perplexity.ai/chat/completions\u0026#39;; // API に送信するメッセージを定義 const messages = [ { \u0026#39;role\u0026#39;: \u0026#34;system\u0026#34;, \u0026#39;content\u0026#39;: \u0026#34;You are a helpful assistant.\u0026#34;}, { \u0026#39;role\u0026#39;: \u0026#39;user\u0026#39;, \u0026#39;content\u0026#39;: prompt } ]; // API リクエストに必要なヘッダー情報を設定 const headers = { \u0026#39;Accept\u0026#39;: \u0026#39;application/json\u0026#39;, \u0026#39;Content-Type\u0026#39;: \u0026#39;application/json\u0026#39;, \u0026#39;Authorization\u0026#39;: \u0026#39;Bearer \u0026#39; + apiKey }; // API リクエストのオプションを設定 const options = { \u0026#39;muteHttpExceptions\u0026#39;: true, \u0026#39;headers\u0026#39;: headers, \u0026#39;method\u0026#39;: \u0026#39;POST\u0026#39;, \u0026#39;payload\u0026#39;: JSON.stringify({ \u0026#39;model\u0026#39;: model, \u0026#39;messages\u0026#39;: messages, \u0026#39;max_tokens\u0026#39;: maxTokens, \u0026#39;temperature\u0026#39;: temperature }) }; // API リクエストを送信し、結果を変数に格納 const response = JSON.parse(UrlFetchApp.fetch(apiUrl, options).getContentText()); // レスポンスから生成されたテキストを返す return response.choices[0].message.content; } ","permalink":"https://konumaru.com/202411/spreadsheet%E3%81%A7%E8%87%AA%E4%BD%9Cgpt%E9%96%A2%E6%95%B0%E3%82%92%E4%BD%BF%E3%81%86/","summary":"\u003ch2 id=\"概要\"\u003e概要\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eSpreadsheetでLLMを使えるようにした\u003c/li\u003e\n\u003cli\u003eCrawlerと組み合わせることでwebページの要約、情報抽出ができる\u003c/li\u003e\n\u003cli\u003ePrompt Engineering頑張るとかなり使えた\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"なぜ作ろうと思ったのか\"\u003eなぜ作ろうと思ったのか\u003c/h2\u003e\n\u003cp\u003e元々は\u003ca href=\"https://workspace.google.com/marketplace/app/chatgpt_for_google_slides_docs_sheets/451400884190\"\u003eChatGPT in Google Sheets™ and Docs\u003c/a\u003eというChrome拡張を使っていて、Open AIのAPI Keyさえあれば便利に使えた。\u003c/p\u003e","title":"Spreadsheetで自作GPT関数を使う"},{"content":"はじめに ダッシュボードを作って、 定量的な意思決定をして、 データドリブンに業務を進めるたい！と言ったら誰もが素晴らしい取り組みだと言ってくれると思う。\nでも実際にはデータがない、ダッシュボードがを作れる人がいない、なんとかダッシュボードを作ったがでーたが更新されない、ついにはダッシュボードを見なくなった。ということがよくある。\n目を通したい記事・資料 デジタル庁のダッシュボードデザインガイド デジタル庁 政策ダッシュボード一覧 正直デジタル庁の資料を読んで、その通りに実施すれば間違いないと思う。\nダッシュボードつくるときの目的 組織で現状、目標を共有する 目標達成のための改善点を見つける 利用者と要件定義するときの心構え どんなデータがみたいか どんなグラフにしたいか からコミュニケーションをしない。\n目標はなにか ダッシュボードのトップの左上に設置する 誰が、どんな意思決定をしたいか ひとごとにダッシュボードページを分けて、 意思決定から逆算した必要なデータ、グラフを選定する 誰と共有したいか 見れない人がいるツール、設定だと困るので最初に確認する ","permalink":"https://konumaru.com/202410/%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5%E3%83%9C%E3%83%BC%E3%83%89%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AB%E3%81%BF%E3%82%8B%E8%A8%98%E4%BA%8B/","summary":"\u003ch2 id=\"はじめに\"\u003eはじめに\u003c/h2\u003e\n\u003cp\u003eダッシュボードを作って、\n定量的な意思決定をして、\nデータドリブンに業務を進めるたい！と言ったら誰もが素晴らしい取り組みだと言ってくれると思う。\u003c/p\u003e","title":"ダッシュボードつくるときにみる記事"},{"content":"GASを使ってスプレットシートのデータをテーブル風に操作したら便利だった。 そのときのコードのメモ。\npandasのような集計、集約などはGASでやるのはしんどそうなので、そこはスプレットシート側の機能を使うのがよさそうだった。 GASはあくまでCRUDに使うのがよさそう。\nGAS Insert function insert(sheet, id, record) { sheet.appendRow(record); return id; } Update function update(sheet, id, record) { const data = sheet.getDataRange().getValues(); for (let i = 1; i \u0026lt; data.length; i++) { if (data[i][0] == id) { console.log(record.length); sheet.getRange(i+1, 1, 1, record.length).setValues([record]); return true; } } return false; } Upsert function upsert(sheet, id, record) { if (update(sheet, id, record)) { return id; } else { return insert(sheet, id, record); } } ","permalink":"https://konumaru.com/202410/gas%E3%81%A7%E3%82%B9%E3%83%97%E3%82%B7%E3%82%92%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E6%93%8D%E4%BD%9C%E3%81%97%E3%81%9F%E3%81%84/","summary":"\u003cp\u003eGASを使ってスプレットシートのデータをテーブル風に操作したら便利だった。\nそのときのコードのメモ。\u003c/p\u003e\n\u003cp\u003epandasのような集計、集約などはGASでやるのはしんどそうなので、そこはスプレットシート側の機能を使うのがよさそうだった。\nGASはあくまでCRUDに使うのがよさそう。\u003c/p\u003e","title":"GASでスプシをテーブル操作したい"},{"content":"転職をきっかけに新しいパソコンを買う機会がやってきた。\nずっと自分のLaptopが欲しかったの買うことにした。\n買ったのは、ThinkPad X1 Carbon Gen 12 だ。\nスペックは以下の通り。\nプロセッサー: インテル® Core™ Ultra 7 プロセッサー 155U OS: Windows 11 Pro 64bit (日本語版) メモリ: 32 GB LPDDR5X-7500MHz (オンボード) ストレージ: 1 TB SSD M.2 2280 PCIe-NVMe Gen4 ディスプレイ: 14\u0026quot; 2.8K OLED (2880 x 1800), 400 nit, 120Hz グラフィックス: 内蔵グラフィックス カメラ: IRカメラ、1080p FHDカメラ 本体カラー: ブラック キーボード: バックライト付、英語配列 指紋センサー: あり グラボが乗っているものを買おうか迷ったが、自宅にデスクトップがあるし、eGPUも気になっているし、今回は内蔵グラフィックスで我慢することにした。それに持ち歩くことを考えると消費電力なども気になった。\nお値段は33万円とお高かったが、まあ仕方ない。妥協するとまたいいものが欲しくなる。\n","permalink":"https://konumaru.com/202407/%E4%BA%BA%E7%94%9F%E5%88%9D-windows-laptop-%E8%B3%BC%E5%85%A5/","summary":"\u003cp\u003e転職をきっかけに新しいパソコンを買う機会がやってきた。\u003c/p\u003e\n\u003cp\u003eずっと自分のLaptopが欲しかったの買うことにした。\u003c/p\u003e\n\u003cp\u003e買ったのは、ThinkPad X1 Carbon Gen 12 だ。\u003c/p\u003e","title":"人生初 Windows Laptop 購入"},{"content":"はじめに この記事ではクーポン配布施策について書いていく。\nこういった施策をやるよ、となったときに自分なりのテンプレートがあるのであとで思い出せるように残しておこうと思った。\nクーポン配布の背景と目的 クーポン配布の目的はさまざま考えられるが、この記事内では以下のような目的とする。\n売り上げを伸ばしたい 予算を使い切りたい １は、主に新規ユーザーの獲得や１人あたりの購買単価を上げることが考えられる。\n２は、配布したクーポンをユーザーが利用することで予算が消費される。\n過去データから考える 最終的に決定するディスカウント条件については、話をシンプルにするために今回は「X円以上の購入でY円割引」という形で考える。ここから先ではこのX, Yを決定する。\n過去の適当な期間を対象に、ユーザー１人あたりの購買単価をヒストグラムを見ることから始める。 適当な期間とは、直近1ヶ月や3ヶ月など適当な期間で良い。さらにサービスのドメイン知識があるならユーザーが離反する期間を考慮するといい。\n大体こういうのは下図のようなロングテールのグラフになるだろ、という仮定でデモデータを生成した。 X軸は１人あたりの購買金額、Y軸はその金額を購入したユーザー数を表している。\nこのグラフは左側であるほど無課金・低課金ユーザー、右側であるほどが重課金ユーザーとなる。\n結論から言うと売り上げを上げるポテンシャルがあるユーザーは左側のユーザーであり、クーポンの配布対象のユーザーとなる。\n仮に右側のユーザーにクーポンを配布したとすると、彼らはすでに買いたいものが明確であり、クーポンがなくても購買行動をする。そのため事業者側からするとただ値下げをしているだけであり、売上を伸ばすことは難しい。\n昔聞いた「行列ができるラーメン屋の行列にトッピング無料券を配布しても意味ないでしょ？」と言う例えがわかりやすかった。\nしかし無課金ユーザーのみだとそもそも欲しいものがなかったり、サービスから離反しきっている可能性がありディスカウント件を配布しても期待される効果が薄い。\nつまり、どこにディスカウント条件設けるといいかというと、程よく欲しいものがあり、サービスを離反していないユーザーがいそうなところに基準（＝X）を設けるとよい。\n最初は以下のように大体でいい。大体でいんです、最初は。\n生成されたサンプルデータから 今回はX=1,000円, Y=20%という条件でディスカウントを適用することにする。 わかりやすくいうと「1,000円以上の購入で200円割引」ということ。\nユーザーに価値が伝わるUXを考える せっかくお金を配って、ユーザーにとってメリットもあるはずなのに、それが伝わらないと意味がない。 またユーザーがそれを受け入れやすいような意味づけをすることも重要。\nとはいえ難しい話ではなくて、以下のようなことを指している。\n見せ方で言うと、1,000円以上の購入で200円割引、2 Buy 1 Get 1 Free、10,000円以上で送料無料、などがある。\n動機付けで言うと、誕生日、初回購入、時間制限付き\nとにかくユーザーがメリットを感じるかを確認することが重要。\nレポーティングの雛形 Outlineは、\nディスカウント条件の決定理由 ディスカウント条件の詳細 X円以上の購入でY円割引 有効期限 適用条件 配布実績 配布ユーザー数 クーポン利用率 平均購買単価の変化 購買UU数の変化 ディスカウント条件の変更案 大体こう言うことを書いておけばよくて、クーポン配布後の購買単価の分布は大体以下のようになる。\n「データ分析の力 因果関係に迫る思考法」では、集積分析という名前で紹介されている。\nちなみに、今回のサンプルデータでは以下のように変化した。\n通常時 平均購買単価: 916 円 累計購買金額: 91,618,703 円 クーポン適用後 平均購買単価: 963 円 累計購買金額: 96,305,593 円 平均購買単価が、約5%上昇したことになる。\nあとは先ほど決めた、X,Yやユーザーへの伝え方を変えるABテストを繰り返すことで、より効果的なディスカウント条件を見つけることができる。\nマニュアルが機能する前提条件 ここまでみてもらったことが再現するにはいくつか条件がある。\n購買単価の分布がロングテールになっていること ディスカウント条件がユーザーに伝わっていること ユーザーが自身の購買単価を操作可能であること ← これが一番重要 まとめ 平均購買単価のヒストグラムを見て、ディスカウント条件を決定するといいよ ディスカウント条件はユーザーに伝わるように工夫するといいよ レポートの雛形は作っておくといいよ X, Yを操作する、ユーザーへの伝え方を変えるABテストをするといいよ ABテストができない環境でもヒストグラムのBinごとの平均購買率の変化を見るといいよ ユーザーが自身の購買単価を操作可能であることが重要だよ 余談：時限式クーポンについて 「ユーザーへの伝え方」の文脈で、時限式クーポンについて触れておく。\nこの記事で最初においた目的として「売上を伸ばしたい」というのがあった。\n実は時限式クーポンは、ユーザーの意思決定を早める効果は期待されるのだがトータルの売上を伸ばす効果はあまり期待できない。なぜかというと明日買おうと思っていたものを今日買うようになったとしても、トータルの売上は変わらないからだ。\nただしクーポン使用率が高かったり、瞬間的な売上を伸ばす効果はあるためレポーティングではその実態を把握できることは少ない。わかりやすく今日の売り上げは伸びるから。\n長期的にみて意味のあることかも意識しないといけないよね、と思ってる。\nその他これについて個人的に思うことは以下の通り。\n時間制限は短ければ短いほど効果がある 効能としてはユーザーの意思決定を早める効果がある 予算消化したいとき、KPI達成したいとか便利 見せ方は派手などよい 1ヶ月とか1年とかの有効期限はなんなの？ 配る側は忘れることを期待してる 事業会社が合法的に発行できる通貨であり、失効条件も握っているためクーポン使用率を操作したいときに便利 そのため見せ方も目立たない方がいい Source Code User Class\nclass User: def __init__(self, user_id): self.user_id = user_id self.max_purchase_amount = 10000 def generate_purchase_amount(self): purchase_amount = np.random.pareto(a=2.0) * self.max_purchase_amount / 10 purchase_amount = min(max(purchase_amount, 0), self.max_purchase_amount) return purchase_amount def apply_coupon( self, purchase_amount, coupon_threshold: float = 1000.0, discount_rate=0.2, ): if purchase_amount \u0026lt; coupon_threshold: probability = 1 - (coupon_threshold - purchase_amount) / coupon_threshold if np.random.rand() \u0026lt; probability: purchase_amount += coupon_threshold * discount_rate return purchase_amount 通常時の購入金額の分布\nnum_users = 100000 users = [User(user_id=i) for i in range(num_users)] purchase_amounts = [user.generate_purchase_amount() for user in users] plt.hist(purchase_amounts, bins=100) plt.xlabel(\u0026#39;Purchase Amount (Yen)\u0026#39;) plt.ylabel(\u0026#39;Number of Users\u0026#39;) plt.title(\u0026#39;Distribution of Purchase Amounts\u0026#39;) plt.show() クーポン適用後の購入金額の分布\nusers = [User(user_id=i) for i in range(num_users)] coupon_threshold = 1000 purchase_amounts = [] for user in users: amount = user.generate_purchase_amount() amount = user.apply_coupon(amount, coupon_threshold, discount_rate=0.2) purchase_amounts.append(amount) plt.hist(purchase_amounts, bins=100) plt.vlines(coupon_threshold * 0.95, 0, len(users) * 0.15, colors=\u0026#39;r\u0026#39;, linestyles=\u0026#39;dashed\u0026#39;, label=\u0026#34;coupon threshold\u0026#34;) plt.xlabel(\u0026#39;Purchase Amount (Yen)\u0026#39;) plt.ylabel(\u0026#39;Number of Users\u0026#39;) plt.title(\u0026#39;Distribution of Purchase Amounts with Coupon Applied\u0026#39;) plt.legend() plt.show() 平均購買単価\nfrom typing import List import numpy as np def purchase_statistics(purchase_amounts: List[float]): average_amount = np.mean(purchase_amounts) total_amount = np.sum(purchase_amounts) users_between_1000_1500 = len([amount for amount in purchase_amounts if 1000 \u0026lt;= amount \u0026lt;= 1500]) print(f\u0026#34;平均購買単価: {average_amount:.2f}\u0026#34;) print(f\u0026#34;累計購買金額: {total_amount:.2f}\u0026#34;) ","permalink":"https://konumaru.com/202406/%E3%82%AF%E3%83%BC%E3%83%9D%E3%83%B3%E9%85%8D%E5%B8%83%E6%96%BD%E7%AD%96%E3%81%AE%E9%89%84%E6%9D%BF%E3%83%9E%E3%83%8B%E3%83%A5%E3%82%A2%E3%83%AB/","summary":"\u003ch2 id=\"はじめに\"\u003eはじめに\u003c/h2\u003e\n\u003cp\u003eこの記事ではクーポン配布施策について書いていく。\u003c/p\u003e\n\u003cp\u003eこういった施策をやるよ、となったときに自分なりのテンプレートがあるのであとで思い出せるように残しておこうと思った。\u003c/p\u003e","title":"クーポン配布施策の鉄板マニュアル"},{"content":"導入 ML Eng -\u0026gt; PdM というキャリアを進んでいる背景もあり、なんか機械学習を使ったいい感じの企画をしてくれよ、という話は多数耳にする。\nとあるスカウトサービス経由でカード発行もやっているクレジットカード事業でそのような需要があることを耳にした。スカウトが来ただけなので働いてはいない。\n率直に「何に機械学習を使えるのだ？」と思ったので少し考えてみたくなって記事を書くことにした。\n市場を眺める クレジットカードの発行も含んだ私が使ったことあるサービスは以下の通り。\nKyash, B4/3, Revolut, LINE Payカード\nどれも物理的なカードが発行でき、相互送金ができ、B4/3のみは複数ユーザーでの利用ができる。\n実際に使ってみた所感としては、クレジットカードのスケープゴートができたような感覚であり非常によかった。具体的には、\n紛失時にアプリから利用を停止できる クレジットカードからのチャージによるポイントの二重取得 送金機能 クレカ変更の影響の軽減(メインで使うカードは変わらないという意味) このように個人としての利用経験もよかった。\n昨今はカードレスクレジットカードやhogehoge Pay、QR決済なども増えているが、物理のクレジットカードの発行はまだまだ需要があると考えられる。 特に日本ではなぜかわからないが、クレカのタッチ決済が機能していない店舗が多数ある。\nまた昨今のこのような事業においては家計簿アプリとクレカが連携しているものも多い。 今回も上記にフォーカスして思考を巡らせてみる。\n事業への理解を深める ビジネスモデルとしてはシンプルだと思っていて大体以下の２点に落ち着くと思ってる。\n発行したクレカの利用料金から手数料を取る 有料プランがある場合はその料金を取る 要は、発行したクレカを使ってもらうことが事業の成長に繋がる。 また、付加価値としてついている家計簿機能も使ってもらうことが事業の成長に繋がる。 さらにいうと、付加価値があることでクレカの利用を促進することも事業の成長に繋がる。\n想定するサービスの前提 これはこの後機械学習の活用方法について検討するにあたる前提を揃える。\n想定されるサービスは、\nプリペイド式のクレジットカードを発行できる サービスが提供するカードを使うと家計簿が記録される オプション機能 送金機能 複数人での利用管理 ポイント付与 ユーザーが求める価値を言語化してみる（サービスが提供したい価値とも言える） 「機械学習が事業に貢献するなら」という話をするために、ユーザーが求める価値を言語化してみる。\n支出を管理できる 複数人で財布をシェアできる 安全性が高い（カードをアプリから即時に止められるなど） 「価値」の定義が正として、機械学習の活用方法を模索する 私は今回「支出を管理できる」という価値にフォローカスして機械学習の活用方法を模索することにした。 きっと手札をもっと多く持っていたり、他の方が考える価値を見つけることもできる人もいるだろうと思う。\n今回は１つ目の価値を「支出を管理できる」 = 「浪費を抑え貯金できる」 と捉え直す。\nまず前提としてこれを提供するために以下のようなグラフをユーザーが見れるようにするべき。\n前提を踏まえた機能案 1. 累積節約額 （ = 貯金額 ） の予測 上記に挙げたグラフを単純に回帰予測したグラフで十分\n現状と何も変わらずに将来に発生する利益を見るだけで人間は嬉しくなると思う。\nこれだけでこのアプリをみることが楽しくなると思う。少なくとも私はwealthnavi, meneyforward, bitflyerなど資産が記録されてるアプリが右肩上がりになっているのを見て嬉しくなるし意味もなくアプリを見てしまう。\n2. 節約プランの提案と違反した場合のアラート これは機械学習？というかデータ活用の見せ場になると思う。\n下図のように PlanA , PlanB という節約プランを提案し、ユーザーが違反した場合にアラートを出す。\nPlan毎には支出管理データをもとに、より安価な購買商品の提案、浪費を指摘などを行う。\nユーザーにとっては行動の結果が明白であり、それを実行するモチベーションが明快になる。\n機械学習が活用されることによる事業の展開の拡張 定期便サービスとの連携によるまとめ買いシェア 消耗品の相乗り買い（そういうサービスとの連携があるといい） 節約額（貯金額）のNISAや仮想通貨の自動投資 貯金額で旅行を提案したっていい（アフィリエイトが美味しい） 予想貯金額と実際の貯金額の相関をみたくなってデータを渡したくなるはず ユーザーのバジェットを知れるとやれることも増えるだろうと思う 所感 「節約が楽しくなる」感情にさせたら色々うまくいく 節約=貯金の構造が直感的にさせるUI/UXの設計はキモに思える 思考停止での節約活動をさせたらインフラになる（それ使ってないだけで損するよ？という風潮が作れたら良い） MLが創出する価値により、ユーザーがデータを差し出す構図は理想 支出の分類精度を上げよう！とかはわかりやすいが、事業の価値に連動するプランが欲しくなる それとこんなことを書いておいて、\n金をもらっていないのに何をしてるんだ、という気持ちもありつつこういうのを考えるのは楽しい その反面、こういうことを考えるだけの仕事があったら非常にやりたい ","permalink":"https://konumaru.com/202405/%E3%82%AB%E3%83%BC%E3%83%89%E4%BB%98%E3%81%8D%E5%AE%B6%E8%A8%88%E7%B0%BF%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%ABml%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%97%E3%81%9F%E3%81%84%E3%81%A8%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6/","summary":"\u003ch2 id=\"導入\"\u003e導入\u003c/h2\u003e\n\u003cp\u003eML Eng -\u0026gt; PdM というキャリアを進んでいる背景もあり、なんか機械学習を使ったいい感じの企画をしてくれよ、という話は多数耳にする。\u003c/p\u003e\n\u003cp\u003eとあるスカウトサービス経由でカード発行もやっているクレジットカード事業でそのような需要があることを耳にした。スカウトが来ただけなので働いてはいない。\u003c/p\u003e","title":"カード付き家計簿サービスにMLを活用したいと言われて"},{"content":"念願の仮想通貨botを運用開始できたので、ここまででやったことをざっとまとめる。\nTL;DR バックテストでは利益が出るbotを作れた それをGCPを使って実運用させられた CryptoBot開発をkaggleのような問題設定に落とし込めた 今後は強化学習モデルも取り入れていきたい Botを作ろうと思ったモチベーション NISAをやって放置してお金が増えるっていいなと気づいた 自分で資産運用Botを作ったらもっと楽に稼げるのでは API使えそうな仮想通貨でやってみよう と、安易に始めた。\nそういったモチベーションから始めたので、botのコンセプトは「放置して儲ける」とした。\nつまり、大きな価格変化を掴むような作戦ではなく、ちまちま金を増やす高頻度取引をするbotを作ることにした。\n無知なので、まずは本を読む 覚えている範囲で、以下の本を読んだ。\nファイナンス機械学習―金融市場分析を変える機械学習アルゴリズムの理論と実践 Pythonではじめるアルゴリズムトレーディング Pythonで学ぶ強化学習 日給300万円のSS級トレーダーが明かす botterのリアル 最後だけ毛色が違うが念のため読んでみた。\n特にファイナンス機械学習は、網羅的な知識をインプットできたので読んでおいてよかった。\nやったこと 雑に順番に書くとこんな感じ。\n価格データを定期的に取得する ランダムに取引を行うbotを作る 取引実績を評価する環境を作る 機械学習モデルを導入したbotを作る w/ ChatGPT ランダムエージェントとの比較を行う ローカルで実際に取引する 取引実績を毎日discordに配信 動くことを確認したら、クラウドで運用する 日々監視して心が落ち着かなくなる←ｲﾏｺｺ 実際に最後までやりきるには大体1~2か月くらい必要だった。 でも、CICD整えたり、TraderAgentの抽象クラスの考えたり、いろいろと自動化しながらやれてだいぶ楽しかった。\n最終的にはkaggleのような問題設定まで落とし込め多と思っていて、このあとの取引エージェントの改善はシンプルになってきたのでいろいろと試せると思う。\nシステム構成 システムはGCPで動いている。\nDBはお高いので節約のために、GCSで乗り切っており、 Traderが必要とするデータの取得が限界に来るまではこのままでいいかと思っている。\ngraph TD A[Subscriber] --\u003e|Get Price, Assets| B[Storage] C[Train ML Model in local] --\u003e |Upload ML Model| B B --\u003e|Get Price, Assets, ML Model| D[Trader] D --\u003e|Trade Order| E[Bitflyer] D --\u003e|Notify| F[Discord] 諸々思ったこと めちゃくちゃ簡易的なMLOpsを味わえた気分になった 実際には大規模データを使ったり、ML部分でマネージドサービスを使うことになるのだと想像できる 失っても大したことない金額とわかってても資産の上下に心動かされる 育てたやつがちゃんと働いたか気になる気持ち インフラ面 こういうちょっとした開発はGCPを使いたい 別で作ったGPTを使ったチャットbotもそうだが要らなくなったらプロジェクトごと消せるのが安心する Botについて 書籍やコンペサイトなど調べて、回帰モデルにしたが、強化学習で取引を決定するイメージを持てた 初手で強化学習をするにはおそらくデータ量が足りないうえに、内部的に持っている予測モデルのお気持ちもわからなかったとおもう。 kaggleとの違い お題に期日がない モデルの精度のお金が増えることに相関を持たせることが大変だとわかった（できので自分を褒めたい） モデルだけでなく周辺システム、クラウドサービスなどを含むも作れるの良い 時間のピタゴラスイッチは難しい データは1分おきで、Traderは5分おきで、実行に数分かかるから、、などなど。 時間の表現は今後統一しよう created_at_utc ","permalink":"https://konumaru.com/202403/%E4%BB%AE%E6%83%B3%E9%80%9A%E8%B2%A8bot%E3%81%A4%E3%81%8F%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/","summary":"\u003cp\u003e念願の仮想通貨botを運用開始できたので、ここまででやったことをざっとまとめる。\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eバックテストでは利益が出るbotを作れた\u003c/li\u003e\n\u003cli\u003eそれをGCPを使って実運用させられた\u003c/li\u003e\n\u003cli\u003eCryptoBot開発をkaggleのような問題設定に落とし込めた\u003c/li\u003e\n\u003cli\u003e今後は強化学習モデルも取り入れていきたい\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"botを作ろうと思ったモチベーション\"\u003eBotを作ろうと思ったモチベーション\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eNISAをやって放置してお金が増えるっていいなと気づいた\u003c/li\u003e\n\u003cli\u003e自分で資産運用Botを作ったらもっと楽に稼げるのでは\u003c/li\u003e\n\u003cli\u003eAPI使えそうな仮想通貨でやってみよう\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eと、安易に始めた。\u003c/p\u003e","title":"仮想通貨botを作ってみた"},{"content":"CommonLitのコンペに参加したので振り返り\nコンペ概要 promptが与えられ、その中にはquestion, title, textがある。\nそれを生徒？が要約した内容に対し、content, wordingというスコアを着ける。\nコンペではそのcontent, wordingのスコアを予測する。\n取り組んだこと 詳細はリポジトリにある。 ここでは簡単にまとめる。\ndebertaでprompt_question, summary_textを入力にし、content, wordingを予測 上記の予測値とテキストを基にした特徴量を合わせて、XGB, LGBMで予測 XGB, LGBMの予測値をアンサンブル これでは全く上位には届かなかったので、上位解法見ていく。\n上位解法 2nd place solution debertaの入力値を'Think through this step by step : ' + prompt_question + [SEP] + 'Pay attention to the content and wording : ' + text + [SEP] + prompt_textとした prompt enginneringがこんなところでも・・・ SEPで囲まれた部分はmaskさせる 別コンペで学習させたモデルの予測値をつかった？ モデルの最大長は1280~2048 最終的には2048で学習？ GroupKFoldで0.4581 アンサンブル deverta-large mean pooling, lstm pooling deberata-base mean pooling, lstm pooling OpenAssistant/reward-model-deberta-v3-large-v2 mean pooling 3rd place solution prompt_question, summary_textを入力にし、content, wordingを予測 似ているサマリ文章同士で単語の置換を行った（これ思いついたのすごすぎ） 上記でData Augmentationをした deberta poolingには、cls tokenとmean poolintを使った token_type_idsを使って、prompt, question, textを区別した（token_type_idsってこういう使い方するんですね） max_lengthは1500 4th place solution 大量のモデルのアンサンブル deberta large, base layer freeze max_length 1500 ~ 868 poolings cls, mean GBDTを使ったアンサンブルを使っていたが、最終的にはcvが低かったのでアンサンブルはしなかった 自分の場合途中結果のcvを比較可能にしていなかったのでこれは反省点\u0026hellip; 5th place solution summary, question, title, prompt_textを使用 deberta largeとlgbmのアンサンブル deberta large max_length 1,536 最初の18layerをfreez content, wordingを同時に学習 lgbm public notebookをほぼ同じ（テキスト統計量を中心にしたものだろうか？） アンサンブルは加重平均 GroupKFold まとめ deberta largeを使う max lengthは1500程度と長めにする poolingをcls token, lstm, mean poolingなど多様性を持ったモデルをアンサンブルさせるのが効いた stackingよりもbest single modelを追い求める方が重要 と勝つために必要だったことを並べてみると、rtx3060とkaggle notebookだけでは戦えなかった気がする。\ndeberta largeは試したが、4fold学習しようとするとtimeoutになるし。。\n今回は縁がなかったコンペだった。早めに撤退するべきだった。 いいグラボを手に入れた時にまた頑張ろう。\n","permalink":"https://konumaru.com/202310/commonlit2023%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/","summary":"\u003cp\u003eCommonLitのコンペに参加したので振り返り\u003c/p\u003e\n\u003ch2 id=\"コンペ概要\"\u003eコンペ概要\u003c/h2\u003e\n\u003cp\u003epromptが与えられ、その中にはquestion, title, textがある。\u003c/p\u003e\n\u003cp\u003eそれを生徒？が要約した内容に対し、content, wordingというスコアを着ける。\u003c/p\u003e","title":"CommonLit 2023 振り返り"},{"content":"PdMとしての経験が増え、管理するチームが10人を超えそうになったとき、マネージメントのコストが急増して大変になるのを防ぐ方法を試みました。この記事ではその時の経験を共有し、どのように問題を回避したかを記録として残しています。\none team one pizzaの思想のもの動いていたが上記の体制じゃお腹いっぱいになれない。 ということでどうやってチームを分割して、その動きを制御するのかを考えた結果になる。\n特に今回はスケーラブルな組織となることを目指している。\n導入 PdMの役割は事業目標にコミットしつつ、あらゆる手を使って製品のあるべきを模索することだと私は思っている。\nただし、会社によってはチームをマネージメントすることも求められることもあると思います。そう言ったときPdMの役割を果たしつつ、チームが最も機能できる状況を作り出すためにはどうすればいいのかを考えた。\n本来ならEM, Scrum Masterなどの役割の人たちと協力して組織形成をやりたいところだが、今回はそういった役割の人がいないものとする。\n組織体制の想定 大体こんな感じ↓\ngraph TD; A(Board) --\u003e B_Top(PO) B_Top(PO) --\u003e B(PdM) B_Top(PO) --\u003e B_dash(PdM) B(PdM) --\u003e T1(TeamA) B(PdM) --\u003e T2(TeamB) B(PdM) --\u003e T3(TeamC) PdMのポジションが自分であり、TeamA, TeamB, TeamCのPdMを兼任しているという想定。 またTeamが増えることを許容することでスケーラブルであると仮定している。\nTeamは3~5人程度の小規模なものを想定している。\nタスク管理の目的 タスク管理の目的は、このままいけば事業計画から逆算されたチームが到達するべき目標を完遂することができるか、そうでない場合そのチームの目標の方向修正が必要かを判断するためコミュニケーションを円滑にすることである。\n上記を達成するためPdMがチームや上位下位レイヤー間のコミュニケーションをする際に自分の頭で考え整理できるように情報を俯瞰できる必要がある。\nそのインプットがあることでタスクの進展や情報、見積りのアプデート、リソース配分の再検討などの提案をチームや上位レイヤーに提案することも可能になる。\n決して「進捗管理」をしたいのではなくPdM \u0026lt;-\u0026gt; Team間で事業目標を達成するために今何をするべきうかを一緒に考えるためのものと考えたい。\nここからはぼやきだが、そうしないとPdMが事業成長の限界値になってしまいかねないし、PdMは自己投資する時間を非常に取りにくい。（すごい人は違うのかもしれないけど）\n実践的なタスク管理方法 前提として以下を設ける。\n先半年から１年分くらいの事業計画はすでに存在するものとする 半期の事業目標の明確に決まっているものとする Teamの目標管理はOKRの形式で運営されている OKRについては、googleのre:workやOKR（オーケーアール）という書籍がわかりやすい。\nEpicの考え方については、AtlassianのブログやGitlabのブログが参考になった。j\n後述するがEpicはユーザーストーリー形式ではなく、機能単位で設定した。\nOKRとEpicの関係性のイメージは、KRはチャレンジングな目標数値が設定されており、EpicはそのKRを達成するための手段として設定される。\nEpicを完結させるためのSprintを計画する ざっと調べた感じ基本的にEpicという考え方はスクラムの文脈でしか語られてなかったので、チームはスクラムのような形式をとっているものとする。（そうでないならスクラムに変えよう。）\nEpicを完結させるためには、Epicを分割してSprint Backlog Itemを作成し、それを完結させることでEpicを完結させることができる。チームはこれを継続するだけで良くなる。\ngraph TD; A(Parent Epic) --\u003e Epic(Epic) Epic(Epic) --\u003e TaskA(Task) Epic(Epic) --\u003e TaskB(Task) Epic(Epic) --\u003e TaskC(Task) TaskA(Task) --\u003e BacklogItemA(Sprint Backlog Item) TaskC(Task) --\u003e BacklogItemB(Sprint Backlog Item) TaskC(Task) --\u003e BacklogItemC(Sprint Backlog Item) またEpicは以下のようにガントチャートにすることで体外的にスケジュールを公開することもでき、軌道修正するときに「EpicA_2が2週間ほど遅れそうですー」と言った時の影響範囲なども説明しやすい。\ngantt title Epic Timeline dateFormat YYYY-MM-DD section Parent_EpicA EpicA_1 :a1, 2025-04-01, 14d EpicA_2 :a2, after a1, 9d EpicA_3 :a3, after a2 , 42d section Parent_EpicB EpicB_1 :b1, 2025-04-01, 21d EpicB_2 :b2, after b1, 14d section Nan_Parent EpicC :c1, 2025-04-14, 7d EpicE :d, 2025-04-21, 14d EpicF :e, 2025-04-21, 28d また、Epicをユーザーストーリー形式にするか、機能名にするかという議論がある。\n個人的にはザッと情報を把握したいときには機能名のほうが見やすいので少なくともタイトルは機能名にしたい。機能名出ないにしても短く完結な表現をしてほしい。\nちなみに機能単位でロードマップを公開している企業をいくつか参考にした。\n参考：unreal engine, GitHub public roadmap, B4/3\nEpicの項目テンプレート Epicは大体これくらいの項目があると良いと思う。\n# タイトル ## 概要 （概要を記述してください） ## 背景 （何が問題であるか、なぜその問題が生じたか、なぜそのタスクが重要なのかなどの背景情報を記述してください） ## 関係者 （タスクに関係する人や組織を記述してください） ## 期間 （タスク完了にかかる見積もり期間を記述してください） ## タスク （epicを完了するために必要な具体的なタスクを記述してください） ## リスクや障害 （タスクを完了するために、リスクや障害物が発生する可能性やどのように対処するかを記述してください） ## 完了後の成果物 （タスクの完了後にどのような成果物が得られるかを記述してください） ## 成果指標 （Epicによって事業観点からの成果指標を記述してください） ## 期待する事業への影響 （新規事業の立ち上げ、売り上げ向上、PV数の向上、etc） ## 参考情報 （その他の情報や注釈があれば追加してください） まとめ 今のところ自分がチーム運営のキャパが溢れそうなときに取った対策をまとめた。\nまだまだEpicの粒度のバラツキや事業設定をOKRに落とし込むときの難しさなどを感じてはいるが、チームとPdMが認識を合わせたり少し将来の話をする難易度がグッと下がっているのを感じる。\nそう言った意味でもチームを管理や制御をしたいのではなくコミュニケーションを取りたいのだというスタンスを持つことが大事だと思った。\n","permalink":"https://konumaru.com/202308/%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A8%E5%8A%B9%E6%9E%9C%E7%9A%84%E3%81%AA%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3-pdm%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%BF%E3%82%B9%E3%82%AF%E7%AE%A1%E7%90%86/","summary":"\u003cp\u003ePdMとしての経験が増え、管理するチームが10人を超えそうになったとき、マネージメントのコストが急増して大変になるのを防ぐ方法を試みました。この記事ではその時の経験を共有し、どのように問題を回避したかを記録として残しています。\u003c/p\u003e","title":"スケールするチームと効果的なコミュニケーション: PdMのためのタスク管理"},{"content":"熊とワルツをという本を読み、リスク管理方法のフォーマットを作ったのでメモ用に記事にする。\nリスク管理の目的 「熊とワルツ」によるとリスクと利益は切っても切れない関係にある。らしい。\nリスクのあるプロジェクトだからこそ利益を産むし、自分の能力を伸ばすチャンスでもあると言っていて自分としても納得感がある。\nまあなので、何かおっきい仕事をするときに無視できない対象であり、乗り越えないといけないものなので管理しましょうね、くらいのモチベーションであると理解した。\nリスク管理の項目 リスク管理の方法として、以下をspreadsheetで管理したらいい感じだった。 何か思いついたら書き込み、誰かに説明したいときはここから参照できた。\nカラムの説明 説明 No リスク番号 Date 記入日 Title タイトル Research Document リスクに関する調査ドキュメントへのリンク Metric リスクを検知するための指標。精度よりも最も早く検知できることが望ましい Cost リスクが発生した場合、回避に要する概算相対工数 Exposure Rate (%) 現状わかっている主観的なリスク顕在化率 Is Exposed リスクが発生したか Action Type 軽減、対応、容認に分類する Action Plan 設定したMetricに従いリスクが発生したとき対策方針 Feature (Issue, crowi, etc) 該当機能にリスクに見合った価値があるかを比較するための参照リンクなど ","permalink":"https://konumaru.com/202308/%E3%83%AA%E3%82%B9%E3%82%AF%E7%AE%A1%E7%90%86%E3%81%AE%E6%96%B9%E6%B3%95/","summary":"\u003cp\u003e\u003ca href=\"https://www.amazon.co.jp/%E7%86%8A%E3%81%A8%E3%83%AF%E3%83%AB%E3%83%84%E3%82%92-%E3%83%AA%E3%82%B9%E3%82%AF%E3%82%92%E6%84%89%E3%81%97%E3%82%80%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E7%AE%A1%E7%90%86-%E3%83%88%E3%83%A0%E3%83%BB%E3%83%87%E3%83%9E%E3%83%AB%E3%82%B3/dp/4822281868\"\u003e熊とワルツを\u003c/a\u003eという本を読み、リスク管理方法のフォーマットを作ったのでメモ用に記事にする。\u003c/p\u003e\n\u003ch2 id=\"リスク管理の目的\"\u003eリスク管理の目的\u003c/h2\u003e\n\u003cp\u003e「熊とワルツ」によると\u003ccode\u003eリスクと利益は切っても切れない関係にある。\u003c/code\u003eらしい。\u003c/p\u003e\n\u003cp\u003eリスクのあるプロジェクトだからこそ利益を産むし、自分の能力を伸ばすチャンスでもあると言っていて自分としても納得感がある。\u003c/p\u003e","title":"リスク管理の方法"},{"content":"コンペ概要 hogehoge\n解法 1st code GBDT + NNのアンサンブル XGBoost Treeliteで推論高速化 1dcnn transformerを試したが、同じスコア+軽量だったため1dcnnを採用 閾値は0.625で固定 閾値は個別に設定するとモデルの堅牢性が低かった 特徴量の数は、各level_groupで 663、1993、3734 indexをソートしたものと、元の順序の両方のモデルを作成 cv=0.705 2nd 単一のLightGBMで予測 level_groupごとにモデルを分けていない 5-fold cvで評価、予測用に全データでモデルを学習 特徴量生成にはnumba, Cを使った level=1の回答に費やした時間？が効いた 特徴量は1,296個 閾値は0.63で固定 3rd levelごとにモデルを学習（18個の2値分類モデル） GBDT + NNのアンサンブル Catboost * 2, xgb * 2 transformer + lstm ローデータをsession_idごとのindexでソート 特徴量の数は、1,000個、2,000個、2,400個 前のlevel_groupからの経過時間 過去質問の予測確率（自分の場合は効かなかった） permutation importanceで特徴量選択 cv=0.702 4th Transformer, XGB, Catboostのアンサンブル 3 seed, 5 fold 線形モデルでアンサンブル indexでソート後、hover行を削除し再度indexを作成した level_groupごとにモデルを学習しているが、nnモデルの共通部分の定義がうまい cv=0.704 異なる閾値（0.60, 0.62, 0.64）の最終提出３つを選んだ 結果的には0.61が最もprivate scoreが高かった 7th level_groupごとにモデルを学習 予測時間短縮のため、levelごとにモデルを分割しなかった 評価時はcv分割したが、推論用には全データで学習したモデルを使用 特徴量 集約キーはlevel、name、event_name、room_fqid、fqid、text 集約キーごとの前のイベントとの時間差、カウント event_name=notification_clickのレコードが重要だった（？） 集約キーの組み合わせが多いため、出現回数が低いものは除外した モデリング 高い学習率(0.1)で学習し、特徴量重要度(gain)が低いものを除外 低い学習率(0.02)で再度学習 cv=0.7034 閾値は0.625で固定 金圏との差分 特徴量の数が足りなかった Leakを考慮した特徴量重要度を用いた特徴量選択ができなかった 全foldで特徴量重要度を平均して選択するのはダメ 検証用データの特徴量重要度を知ってしまう状態になってしまう foldごとに特徴量重要度を平均し、評価する必要があった jackさんの解法では、最後にcvを切らず全データを使った学習をしているがそのときはfoldごとの特徴量重要度を平均したものを使っている 閾値を固定していない GBDT + NNのアンサンブルを試していない ","permalink":"https://konumaru.com/202307/psp%E3%82%B3%E3%83%B3%E3%83%9A%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/","summary":"\u003ch2 id=\"コンペ概要\"\u003eコンペ概要\u003c/h2\u003e\n\u003cp\u003ehogehoge\u003c/p\u003e\n\u003ch2 id=\"解法\"\u003e解法\u003c/h2\u003e\n\u003ch3 id=\"1st\"\u003e\u003ca href=\"https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/420217\"\u003e1st\u003c/a\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/420332\"\u003ecode\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGBDT + NNのアンサンブル\n\u003cul\u003e\n\u003cli\u003eXGBoost\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/dmlc/treelite\"\u003eTreelite\u003c/a\u003eで推論高速化\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e1dcnn\n\u003cul\u003e\n\u003cli\u003etransformerを試したが、同じスコア+軽量だったため1dcnnを採用\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e閾値は0.625で固定\n\u003cul\u003e\n\u003cli\u003e閾値は個別に設定するとモデルの堅牢性が低かった\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e特徴量の数は、各level_groupで 663、1993、3734\u003c/li\u003e\n\u003cli\u003eindexをソートしたものと、元の順序の両方のモデルを作成\u003c/li\u003e\n\u003cli\u003ecv=0.705\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2nd\"\u003e\u003ca href=\"https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/424329\"\u003e2nd\u003c/a\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e単一のLightGBMで予測\n\u003cul\u003e\n\u003cli\u003elevel_groupごとにモデルを分けていない\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e5-fold cvで評価、予測用に全データでモデルを学習\u003c/li\u003e\n\u003cli\u003e特徴量生成にはnumba, Cを使った\n\u003cul\u003e\n\u003cli\u003elevel=1の回答に費やした時間？が効いた\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e特徴量は1,296個\u003c/li\u003e\n\u003cli\u003e閾値は0.63で固定\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3rd\"\u003e\u003ca href=\"https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/420235\"\u003e3rd\u003c/a\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003elevelごとにモデルを学習（18個の2値分類モデル）\u003c/li\u003e\n\u003cli\u003eGBDT + NNのアンサンブル\n\u003cul\u003e\n\u003cli\u003eCatboost * 2, xgb * 2\u003c/li\u003e\n\u003cli\u003etransformer + lstm\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eローデータをsession_idごとの\u003ccode\u003eindex\u003c/code\u003eでソート\u003c/li\u003e\n\u003cli\u003e特徴量の数は、1,000個、2,000個、2,400個\n\u003cul\u003e\n\u003cli\u003e前のlevel_groupからの経過時間\u003c/li\u003e\n\u003cli\u003e過去質問の予測確率（自分の場合は効かなかった）\u003c/li\u003e\n\u003cli\u003epermutation importanceで特徴量選択\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003ecv=0.702\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"4th\"\u003e\u003ca href=\"https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/420349\"\u003e4th\u003c/a\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eTransformer, XGB, Catboostのアンサンブル\n\u003cul\u003e\n\u003cli\u003e3 seed, 5 fold\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e線形モデルでアンサンブル\u003c/li\u003e\n\u003cli\u003eindexでソート後、hover行を削除し再度indexを作成した\u003c/li\u003e\n\u003cli\u003elevel_groupごとにモデルを学習しているが、nnモデルの共通部分の定義がうまい\u003c/li\u003e\n\u003cli\u003ecv=0.704\u003c/li\u003e\n\u003cli\u003e異なる閾値（0.60, 0.62, 0.64）の最終提出３つを選んだ\n\u003cul\u003e\n\u003cli\u003e結果的には0.61が最もprivate scoreが高かった\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"7th\"\u003e\u003ca href=\"https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/420119\"\u003e7th\u003c/a\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003elevel_groupごとにモデルを学習\n\u003cul\u003e\n\u003cli\u003e予測時間短縮のため、levelごとにモデルを分割しなかった\u003c/li\u003e\n\u003cli\u003e評価時はcv分割したが、推論用には全データで学習したモデルを使用\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e特徴量\n\u003cul\u003e\n\u003cli\u003e集約キーはlevel、name、event_name、room_fqid、fqid、text\u003c/li\u003e\n\u003cli\u003e集約キーごとの前のイベントとの時間差、カウント\u003c/li\u003e\n\u003cli\u003eevent_name=notification_clickのレコードが重要だった（？）\u003c/li\u003e\n\u003cli\u003e集約キーの組み合わせが多いため、出現回数が低いものは除外した\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eモデリング\n\u003cul\u003e\n\u003cli\u003e高い学習率(0.1)で学習し、特徴量重要度(gain)が低いものを除外\u003c/li\u003e\n\u003cli\u003e低い学習率(0.02)で再度学習\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003ecv=0.7034\u003c/li\u003e\n\u003cli\u003e閾値は0.625で固定\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"金圏との差分\"\u003e金圏との差分\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e特徴量の数が足りなかった\u003c/li\u003e\n\u003cli\u003eLeakを考慮した特徴量重要度を用いた特徴量選択ができなかった\n\u003cul\u003e\n\u003cli\u003e全foldで特徴量重要度を平均して選択するのはダメ\n\u003cul\u003e\n\u003cli\u003e検証用データの特徴量重要度を知ってしまう状態になってしまう\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003efoldごとに特徴量重要度を平均し、評価する必要があった\u003c/li\u003e\n\u003cli\u003ejackさんの解法では、最後にcvを切らず全データを使った学習をしているがそのときはfoldごとの特徴量重要度を平均したものを使っている\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e閾値を固定していない\u003c/li\u003e\n\u003cli\u003eGBDT + NNのアンサンブルを試していない\u003c/li\u003e\n\u003c/ul\u003e","title":"PSPコンペ振り返り"},{"content":"コンペ概要 コンペページはこことは\nドイツ最大級のオンラインショップOTTOを題材に特定のユーザがどの商品に対し、クリック、カート追加、注文するかを予測する。\nデータはアイテム数180万、ユーザ数1200万人、インタラクション数2.2億が与えられる。これらのデータは４週間のインタラクション履歴からなる。 3週間分をtrain, 残り1週間をtestとして扱う。また、train, testでユーザの重複はない。\n評価は、各インタラクション（click, cart, order）ごとにRecall@20の重み付き平均和で計算される。\n解法の概要 Model Candidate Generation (Recall) Rerank CV Strategy 5%のユーザを使う 上位解法 1st place solution Candidate Generation NNでEmbeddingを作成 session embedding aid embedding 学習時は上記を使って、positive, negativeサンプリングをそれぞれ行いRerankerが学習するデータを選出 cos similiarityが (avg + min) / 2 以上のものをpositiveとする？ Reranker LGBMRanker Feature session * aidを使ったcandi まとめ ","permalink":"https://konumaru.com/202305/kaggle-otto%E3%82%B3%E3%83%B3%E3%83%9A%E8%A7%A3%E6%B3%95%E8%AA%BF%E6%9F%BB/","summary":"\u003ch2 id=\"コンペ概要\"\u003eコンペ概要\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.kaggle.com/competitions/otto-recommender-system/overview\"\u003eコンペページはここ\u003c/a\u003eとは\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.otto.de/\"\u003eドイツ最大級のオンラインショップOTTO\u003c/a\u003eを題材に特定のユーザがどの商品に対し、クリック、カート追加、注文するかを予測する。\u003c/p\u003e\n\u003cp\u003eデータはアイテム数180万、ユーザ数1200万人、インタラクション数2.2億が与えられる。これらのデータは４週間のインタラクション履歴からなる。\n3週間分をtrain, 残り1週間をtestとして扱う。また、train, testでユーザの重複はない。\u003c/p\u003e","title":"kaggle OTTOコンペ解法調査"},{"content":"何を作ろうと思ったのか ひとことで言うと「マッチングアプリに変わる恋愛シュミレーションAI」を作りたかった。\nChatGPTを使ってみたところかなり自然に会話をしてくれたので、まるで人と話しているかに感じることができた。 それを受けてプロンプトで人格を定義して、シュミレーションゲーム風にして人と話すことを目的にしているマッチングアプリユーザをリアルの人と関わることによるストレスから解放できないかと思いつくってみることにした。\nついでにStripeを使って有料化しようと思ったが、そこまでの品質にはならなかった。\n出来上がったもの 詳細はGithubを参照してください。\n正直人と話ている状態とはほど遠く、実験的に作った４択形式のインターフェースが楽ではあったがリアルから離れすぎてしまった。\nアーキテクチャはこんな感じ\nプロンプトエンジニアリングの難しさ GPT3.5だったのもあったが、出力を安定させるのが非常に難しかった。\njsonで出力されることが担保されるならMessaging APIで提供されているクイックリプライを使いたかった\nまた、口調を人っぽくするだけなら簡単だったがなんとも言えない会話の成立のしなさが解決できなかった。 必ず返答をしてくれるのだが、会話が堂々巡りしてしまったらだらだらとやり取りが続いてしまう。\nあとは動作テストをChatGPTでやっていたが、実際にはLangchianを使って実装している。 今回はやらなかったが、Langchianをつかうならいくつかの役割にBotを分離させて並列に複数の処理をさせることで\n記憶の単純化 レスポンス速度の向上 プロンプトの簡略化 などを期待できたかもしれないと思った。\nLINEというインターフェースの良さ 簡単にいくつか上げると\n簡単にリッチなUIが使える 使い慣れているインターフェースなので受け入れられやすい 友達と飲んでいる時にちょっとこれつかってみてよ。がやりやすかった GPTのデメリットであるレスポンスの遅さがLINEだと意外と自然 とはいえ、連投とかされると困った LINEのデメリット 唯一デメリットは、動作テストのしにくさだった。\nngrokでローカルにエンドポイントを立てる LINE Messaging APIにエンドポイントを再登録 function frameworkでCloud Functionのローカルサーバを立てる 手元のデバイスでLINE使って動作テスト などやっている間にデプロイしてしまったほうが楽だったりした。\n完成までの反省点 遅い。シンプルに納得がいくところまで作り終えるのが遅かった。 動かすだけなら一晩で作ることができきたが、プロンプトエンジニアリングが難しかった。\nインフラ面では、始めにタイムアウトを気にしてCloud Runを使っていたが、結果的にはCloud Functionで動かすことにしてことで開発が二度手間になった。\n開発過程で取り組んで良かったこと 以下の企画書を書いたのはよかった。 目的決めて、期日、撤退ラインなどを事前に決めておくのは本当によかった。\n# 企画書 ## サービス内容 ## 証明したいこと ## 実現可能性 ## リリース目標 ## インフラ ## 実装方針 ## お金回り ## 撤退ライン ## 広める方法 ","permalink":"https://konumaru.com/202305/gpt-3.5%E3%81%A7%E4%BD%9C%E3%81%A3%E3%81%9F%E6%81%8B%E6%84%9B%E3%82%B7%E3%83%A5%E3%83%9F%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3ai-chatbot/","summary":"\u003ch2 id=\"何を作ろうと思ったのか\"\u003e何を作ろうと思ったのか\u003c/h2\u003e\n\u003cp\u003eひとことで言うと「マッチングアプリに変わる恋愛シュミレーションAI」を作りたかった。\u003c/p\u003e\n\u003cp\u003eChatGPTを使ってみたところかなり自然に会話をしてくれたので、まるで人と話しているかに感じることができた。\nそれを受けてプロンプトで人格を定義して、シュミレーションゲーム風にして人と話すことを目的にしているマッチングアプリユーザをリアルの人と関わることによるストレスから解放できないかと思いつくってみることにした。\u003c/p\u003e","title":"GPT-3.5で作った恋愛シュミレーションAI ChatBot"},{"content":"概要 教師なし学習を使った異常検知をやってみたいと思い 、Pythonではじめる教師なし学習を読んでいたらちょうど いいお題があったのでやってみることにした\nここではサンプルデータを対象にPCAを使った異常検知を行う\nなぜ検出できるのかという理論的な内容についてはここでは触れない。（というかわかっ てない）\nアプローチ PCAについて はこのPDFが 詳しく書いてあった\n前提として、なんらかの理由で訓練データに異常標本が混ざっており、教示データを用意 できないこととする。\n（専門家の方には怒られてしまう表現なのは重々承知で、）\n上記の資料ではPCAは以下のように説明されている\n多次元データのもつ情報をできるだけ損わずに低次元空間に情報を縮約する方法\nこの性質を使って、\n異常標本が混ざっている多次元データ 1のデータをPCAで次元圧縮し、固有値ベクトルを取得 1と2のデータを使って一度次元圧縮し、復元した逆変換データを作る 元データと逆変換データの差分が大きい値を異常標本として検出する 上記のような処理をすることで、一度PCAをした際に正常なデータの方が多いことが想定されるため、Fitされるベクトルが正常標本に偏りと思われる\nその性質を利用して、逆変換をした際に異常標本は正常データに偏って変換されるため元データとの差分が正常標本よりも大きくなると考えられる\nPCA を使った異常検知の実装 実装したscriptはこちら\n２値分類のサンプルデータを生成 from pyod.utils.data import generate_data X_train, _, y_train, _ = generate_data( n_train=2000, n_test=0, contamination=0.1, # percentage of outliers random_state=42, ) X_trainとy_trainの中身\nX_train: (2000, 2) [[6.43365854 5.5091683 ] [5.04469788 7.70806466] [5.92453568 5.25921966] [5.29399075 5.67126197] [5.61509076 6.1309285 ]] y_train: (2000,) [0. 0. 0. 0. 0.] 以下は入力データの分布の画像だが、特徴量を見ても別のデータとして視認できそう PCA を使ってデータを逆変換 import numpy as np from sklearn.decomposition import PCA def fit_and_inverse(data: np.ndarray, n_components: int = 2): pca = PCA(n_components=n_components) reduced = pca.fit_transform(data) inverse = pca.inverse_transform(reduced) return inverse raw = X_train.copy() inv = fit_and_inverse(raw) 元データと逆変換データの差分から閾値を決定 mse = ((raw - inv) ** 2).mean(axis=1) # NOTE: # 今回は10%が異常データとして生成してるので90percentileで閾値を設ける # 実際には想定される異常値の割合や期待する再現率などから設定すると考えられる threshold = np.percentile(mse, 90) 以下の画像が標本ごとのMSEの分布と閾値になる\n分布からはこれが良い閾値なのかはわかりにくいと思った\n分類結果 precision recall f1-score support 1.0 0.91 0.70 0.79 200 0.0 0.97 0.99 0.98 1800 まとめ PCAを使った異常検知の手法ということで、ラベルデータがない環境下でも取れる手段としていい知見になった。\n使っている手法がPCAになるのでカテゴリカルデータや元データの次元数が多い時などさまざまな場面では制約になることがあるのかなあとか思った。\n","permalink":"https://konumaru.com/202210/pca%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E7%95%B0%E5%B8%B8%E6%A4%9C%E7%9F%A5/","summary":"\u003ch2 id=\"概要\"\u003e概要\u003c/h2\u003e\n\u003cp\u003e教師なし学習を使った異常検知をやってみたいと思い\n、\u003ca href=\"https://amzn.to/3eM9dfF\"\u003ePythonではじめる教師なし学習\u003c/a\u003eを読んでいたらちょうど\nいいお題があったのでやってみることにした\u003c/p\u003e\n\u003cp\u003eここではサンプルデータを対象にPCAを使った異常検知を行う\u003c/p\u003e","title":"PCAを使った異常検知"},{"content":"コンペ概要 ざっくりの概要はサッカーの試合動画(45min * 2) から特定のフレームで Challenge, Play, Throwin の３つのイベントを予測するというもの\n（合っているか不安だが、）サッカー業界の事情としては、ユース、プロ、セミプロなど は手厚い指導を受けられるが、それ以外のプレイヤーは質の良い指導を受けられるほど人 材は充実していない。\nこれを画像処理の技術によって試合中の選手の活動状況を把握することで少ない人的コス トで選手に有益なアドバイスをできないか、という取り組み。\n評価指標 公式の説明 はここ\nsubmission file は以下 Columns を必要とした csv ファイルを提出する。\nvideo_id: 動画の識別子 time: event が発生した動画内の時間 event: challenge, play, throwin の内、発生したイベントを１つ score: イベントが発生した確率（後に Average Precision を算出するときに使う） このコンペの評価を簡単に説明すると以下のような計算を行います\n各 event について Average Precision を計算 その際に下記の Tolerances (許容度)に従い、正解ラベルとの time の誤差以内であれ ば正解とする つまり１つのラベルで time の誤差０であれば５回予測できたとする 最後に３つの event の Average Precision の平均値を評価指標とする # Tolerances Challenge: [ 0.30, 0.40, 0.50, 0.60, 0.70 ] Play: [ 0.15, 0.20, 0.25, 0.30, 0.35 ] Throw-In: [ 0.15, 0.20, 0.25, 0.30, 0.35 ] 本コンペで難しいと感じた部分 データが動画 動画によってカメラの画角が捉えてる範囲が異なる 客席も映像に入ってる コードコンペだったので CPU/GPU 共に 9 時間の制限がある Discussion の情報が乏しい（画像処理の経験が浅いのでつらかった） （ここの言語化ができてない時点で負けている感がある\u0026hellip;.）\n自分が取り組んだ内容 当時のRepository\n(Private にしていると思うので見れません。)\nYolov7 で ball, person の x,y,conf を取得 時系列テーブルデータとして特徴量エンジニアリング ball の xy 座標と confidence 予測対象フレームの-20~20 のフレーム前後の ball の xy 座標と confidence 予測対象フレームの-20~20 のフレームで rolling した ball の xy 座標と confidence の統計量 予測対象フレームの-20~20 のフレーム間で ball が移動したベクトルの内積と角度 検出された person 全員の座標の統計量 XGBoost で学習、損失関数は LogLoss Group=game_id(video_id から前半後半を統合), k=3 の GroupKFold で評価 結果は、ローカルで 0.2 と戦えるスコア出なかった\nplay だけは 0.7 近く予測できたが、challenge と throwin は 0.02 程度だった\n上位解法 1st Solution 4 つの動画を固定で検証用に使った 1024*1024 のグレースケールで前後のフレームを使った 3 チャンネルの画像を使用 処理速度を考慮 efficientnetv2_b0, efficientnetv2_b1 を使用 3dcnn は pooling 前の最終ブロックと最後の畳み込み層のみ 小さいデータセットに対して過学習することはすぐに分かった 損失関数は３つのカラムで BCE ダミーデータはどうしてたんだろう？ マルチスレッド化して推論を高速化 １つの video で 25 min であり、モデルを 2 つしようしたので 50 min 最終的には全体で 5 hours 2nd Solution オプティカルフロー オプティカルフローを予測？ RAFT というアイデアを使ってる ボールの検出 対象フレームの RGB、前後のオプティカルフローのブレームの RGB の合計 9channel を使用 検出された Ball のヒートマップの内、上位 10 に厳選 ボール軌道のコスト最小化 N フレームを対象にボール検出で厳選された 10 の ball から軌道を考慮すると尤も らしいものを選定 イベント分類 ボール周辺の画像をトリミングしたものを使用 2D CNN + Ball 軌道特徴量 -\u0026gt; 1D CNN -\u0026gt; 4 Event Class Prediction（短期予測？） Stacking 51 フレームの簡易的な特徴量から中間の７フレームを対象に予測（長期予測？） 後処理 Play\u0026amp;Pass については７フレームの内？予測値が peek の time を採用 Challenge についてはノイズが多かったので予測値にガウシフィルターを適用後同様 の処理でイベント発生 time を選定 3rd Solution EfficientNet + Simple 1D UNet input=(1, 64, 3, 360, 640) 前後に 64 フレームも使ってる！？ 64 フレーム中で score が peek のフレームを採用 Backbone をフリーズさせることで学習を高速化 ボール検出の pretraining そのまま学習するとオーバーフィットする ボールの位置を教えることで解決 ボールの位置は自分でアノテーションした（自分でアノテーションは頭になかった \u0026hellip;） ラベルデータの加工 正解ラベルを中心に緩やかに正解にする(0~1 のグラデーションを持たせる) 正解ラベルの周辺フレームは event に近い動きをしているはずなのでそのニュア ンスを表現することでモデルの FalesNegative を抑制してる？ Augmentation RandomHorizontalFlip, RandomRotation, ColorJitter, etc Loss Function は、Focal Loss Challenge と Throwin はデータが少ないので weight を設定することで調整 推論 imutilsで video のデコードを MultiTread 化 これをつかって動画読み込みむだけで早くなるってことなのか？ 後処理 NSM の閾値に[12, 6, 6] for [challenge, play, throwin]と言ってるがどういう ことなのだろう 5th Solution グレースケール、size=(1024,576), crop_center(960,512) 前フレームとの差 前後 5 フレームの effecientnet_b1 による 3 クラス分類 5 モデルのアンサンブル(CV したモデル) ラベルデザイン σ=20 フレームのガウス分布 前後 20 フレームについてガウス分布にしたがって緩やかにラベルを付与したって ことだろうか 上位を取るために そもそも NN を使うということ Efficientnet, UNet について要復習 入力の３次元は RGB の color channel だけでなく、時間軸にも使える 検証データを固定した試行錯誤の時間の削減 最初は画像サイズを小さくなども ガウス分布を使ったラベルの重みづけ 動画読み込みの並列化による推論の高速化 既存のライブラリやモジュールを活用したスタートラインを高く持つ志 諸刃の剣かもしれんが、少なくとも画像コンペにおいては\u0026hellip;？ お気持ち 「知っていて出来なかったこと」と「知らなくて出来なかったこと」があったように感じ た\n知っていてできなかったことは、今回の問題と紐づかなかったのでどうすればよいのか難 しいが、少なくとも知らなかったことは知っているに変えたい\n","permalink":"https://konumaru.com/202210/kaggle%E3%82%B3%E3%83%B3%E3%83%9Adfl%E5%8F%8D%E7%9C%81%E4%BC%9A/","summary":"\u003ch2 id=\"コンペ概要\"\u003eコンペ概要\u003c/h2\u003e\n\u003cp\u003eざっくりの概要はサッカーの試合動画(45min * 2) から特定のフレームで Challenge,\nPlay, Throwin の３つのイベントを予測するというもの\u003c/p\u003e\n\u003cp\u003e（合っているか不安だが、）サッカー業界の事情としては、ユース、プロ、セミプロなど\nは手厚い指導を受けられるが、それ以外のプレイヤーは質の良い指導を受けられるほど人\n材は充実していない。\u003c/p\u003e","title":"kaggleコンペ DFL反省会"},{"content":"これを読んで得られるもの PM, Desingner, Developerの間で、何を、何故作るのかの共通認識を作るための手段\nPRD とは 「プロダクトマネージャー本人も含めて、常に立ち返るべき方針」をドキュメントにしたもの ブレの無い意思決定をするため 開発終盤に入り期日も近づいた時の取捨選択を判断する基準 「何を」を説明することを目的にしており、「どのように」は説明しない より詳しい内容については及川さんというかたが公開されているはじめてのPRDがとても参考になる\nPRD のテンプレート 以下はProduct Huntのものを参照している。\n合わせてnoteに投稿されていた記事も非常に参考になった。\n# Title ## Intro \u0026amp; Goal 私たちの目的は、 XXXをYYYにとってZZZなツールにすることです。 XXXはhogehogeなツールになります。 ## Product Vision ## Who\u0026#39;s it for? ｜誰のためにあるか 1. ユーザー - XXXを利用するユーザー ## Why build it?｜なぜ創るか ## What is it?｜どういうものか ### Glossary ｜用語 ### User Types ### UI/Screens/Functionalities ｜ UI/画面/機能 ## Brainstormed Ideas ｜その他アイデア ## Competitors \u0026amp; Product Inspiration ｜競合 ## Seeding Users \u0026amp; Content ｜初期ユーザーと獲得戦略 ## Mockups ## Tech Notes PRD を書くステップ PRDの作成ステップについては以下の記事がとても参考になった。\nProduct Templates: Product Requirements Document (PRD)\n素案を書く Good Ideaをプライベートドキュメントに書いてみる 言語化の過程で自らが間違っていたことに気づくかもしれません Backgroud, Objective, metricsは最低限欲しい さらに、ユーザーが利用するシナリオ、主要機能を言語化できると素晴らしい 上長の承認を得る 上司の考えやフィードバックを入手するのが目的 自分よりもドメイン知識を豊富に持っている人の意見は貴重です また情報の透明性にも繋がります デザイナーと共有 エンジニアリングについて語る前にユーザーに触れさせるのが懸命です デザイナーの意見を積極的に仕様に反映させましょう エンジニアと共有 （理想的には）デザイナーとエンジニアのリーダーと PRD を共有し、フィードバックを得ます 技術的に実現可能なものを見つけ、大まかな時間・難易度の見積りを行う プロダクトチーム全体に共有 この時点で正式に会社のwikiにPRDを移動 チームから得た質問や情報をPRDに記録していきます プロダクトチームから良きアイデアが出た場合、初期に実現しないとしてもここにメモします 会社に共有 必要に応じて、プレゼンテーションの材料とすることができます ","permalink":"https://konumaru.com/202209/prd---what%E3%82%92%E6%B1%BA%E3%82%81%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/","summary":"\u003ch2 id=\"これを読んで得られるもの\"\u003eこれを読んで得られるもの\u003c/h2\u003e\n\u003cp\u003ePM, Desingner, Developerの間で、何を、何故作るのかの共通認識を作るための手段\u003c/p\u003e\n\u003ch2 id=\"prd-とは\"\u003ePRD とは\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e「プロダクトマネージャー本人も含めて、常に立ち返るべき方針」をドキュメントにしたもの\u003c/li\u003e\n\u003cli\u003eブレの無い意思決定をするため\u003c/li\u003e\n\u003cli\u003e開発終盤に入り期日も近づいた時の取捨選択を判断する基準\u003c/li\u003e\n\u003cli\u003e「何を」を説明することを目的にしており、「どのように」は説明しない\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eより詳しい内容については及川さんというかたが公開されている\u003ca href=\"https://www.slideshare.net/takoratta/prd-192302662\"\u003eはじめてのPRD\u003c/a\u003eがとても参考になる\u003c/p\u003e","title":"PRD - Whatを決めるためのドキュメント"},{"content":"経緯 諸事情により、PC を新しくしたところ hugo server がローカルで起動しなくなった よく確認せずに Github Actions へビルドしたら CI は通過したのでローカル環境の問題だと推測した エラーメッセージ hogehoge\n❯ hugo server -D Start building sites … hugo v0.102.3+extended darwin/amd64 BuildDate=unknown WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for layout \u0026#34;archives\u0026#34; for kind \u0026#34;page\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;term\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;term\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;page\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;term\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;term\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;page\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;term\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;home\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for layout \u0026#34;search\u0026#34; for kind \u0026#34;page\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination. WARN 2022/09/13 10:56:07 found no layout file for \u0026#34;HTML\u0026#34; for kind \u0026#34;taxonomy\u0026#34;: You should create a template file which matches Hugo Layouts Lookup Rules for this combination 対応 原因は、サブモジュールを初期化\u0026amp;更新する必要があった\n\u0026gt; git submodule update --init --recursive 更新するだけでなく、初期化が必要な部分でつまづいた。\n","permalink":"https://konumaru.com/202209/hugo-%E3%83%93%E3%83%AB%E3%83%89%E3%82%A8%E3%83%A9%E3%83%BC%E5%AF%BE%E5%BF%9C/","summary":"\u003ch2 id=\"経緯\"\u003e経緯\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e諸事情により、PC を新しくしたところ hugo server がローカルで起動しなくなった\u003c/li\u003e\n\u003cli\u003eよく確認せずに Github Actions へビルドしたら CI は通過したのでローカル環境の問題だと推測した\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"エラーメッセージ\"\u003eエラーメッセージ\u003c/h2\u003e\n\u003cp\u003ehogehoge\u003c/p\u003e","title":"202209時点で起きたHugoビルドエラー対応"},{"content":"「クリストファー・アレクサンダーの思考の軌跡 - デザイン行為の意味を問う」を読んだ感想をまとめる\n形は機能に従う、機能は形に従うのではない 「形は機能に従う」\nこれがこの本の中で最も重要だった言葉だと感じました。\n様々なニーズを満たすものの形は、そのニーズを満たすような機能が先だって定められ、その機能を満たす形がおのずと決まる。ということを言っている。\nデザイナーと自然科学者の対比 本書では扇風機の説明の仕方を例にその違いを対比していた。\nデザイナー観点での扇風機の説明\n扇風機はその前にいる人を涼しくするという機能を持っている\nクリストファー・アレクサンダーの思考の軌跡 - デザイン行為の意味を問う | 長坂 一郎 (著)\n自然科学者観点での扇風機の説明\n扇風機は羽を回転させて（最近は翅のないものもあるが）、一定の風速の空気の流れを発生させるという機能を持っている\nクリストファー・アレクサンダーの思考の軌跡 - デザイン行為の意味を問う | 長坂 一郎 (著)\nこの２つの「機能」の説明は全く異なり、デザイナーの観点からは扇風機が作られた目的が説明されている。\n自然科学者の観点からでは「機能は形に従う」説明になっている。機能に先だって形が存在していることになる。\n例えば、「キリンの高いところにある葉を食べる（機能）から首が長い（形）のだ」のようになる。 （キリンは高いところにしか葉がないから首が長くなったのではなかっただろうか。）\nこの「機能」の捉え方がデザインにとって最も根底にあることだと思われる。\nデザイナーにとっては、形に先だって機能があるという考え方によって再現あるよいデザインをすることができるのではないかとこの本では言われている。\nデザイナーの仕事 デザイナーの仕事は、この「機能」が目的としている「ニーズ」を定義し、分析することにある。（と読み取れた。)\nここでの「ニーズ」は～を求めている。ではなく、～をしようとしている。などの傾向のことを言う。\n本書では「ニーズ」＝「人々がしようとすること」と概念を置き換えている。\nデザイナーはこの「人々がしようとすること」が何らかの理由で実行できないとき、それを様々なモノの粒度や関係性を変えることで、ユーザが実行できる状況を作り出すことが仕事になる。\nこの目指す状況の違いに特定の人、デザイナーならではの個性が現れるのだと思われる。\nオーダーメイドっていいもんなんだな、 この本を読んでオーダーメイドというは、このプロセスをひとり占めできるのだからそれは贅沢なものなのだと気づいた。\n他の誰のためのものでもなく、自分だけのためにニーズを分析して、形を作る。\nこのプロセスを経て作られたものがいいものでない訳がない。\n","permalink":"https://konumaru.com/202207/%E5%BD%A2%E3%81%AF%E6%A9%9F%E8%83%BD%E3%81%AB%E5%BE%93%E3%81%86/","summary":"\u003cp\u003e\u003ca href=\"https://amzn.to/3oh6CeM\"\u003e「クリストファー・アレクサンダーの思考の軌跡 - デザイン行為の意味を問う」\u003c/a\u003eを読んだ感想をまとめる\u003c/p\u003e\n\u003ch2 id=\"形は機能に従う機能は形に従うのではない\"\u003e形は機能に従う、機能は形に従うのではない\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e「形は機能に従う」\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eこれがこの本の中で最も重要だった言葉だと感じました。\u003c/p\u003e\n\u003cp\u003e様々なニーズを満たすものの形は、そのニーズを満たすような機能が先だって定められ、その機能を満たす形がおのずと決まる。ということを言っている。\u003c/p\u003e","title":"形は機能に従う"},{"content":"目標設定のフレームワークとして OKR を採用することにしたので、OKR 導入のために必要な基礎的な知識をまとめる。\nOKR とは 目標の設定・管理方法の１つで、Objective と KeyResults の略称\n勉強のために読んだ本によると、\n第一の原則は、みんなのモチベーションを高めて最高の仕事をしてもらう方法、 第二の原則は、有意義な形で進捗を測る方法と言える\nOKR（オーケーアール） | クリスティーナ・ウォドキー (著)\nとも書いてあり、それぞれ Objective と KeyResutls を表していると思われる\nまた OKR は、スタートアップのような小規模のチームから Google のような大企業まで活用することができる目標設定のフレームワークである。\nOKR の決め方 会社のミッションを確認する 世界を変えたいと思って起業された会社にはミッションがあるはずだ。\nミッションを言語化するにあたり以下のようなものが使える\n私たちは、[価値提案]によって、[市場]における[問題を取り除きます/生活を向上させます]\nOKR（オーケーアール） | クリスティーナ・ウォドキー (著)\n上記の本では会社を 5 年間支えてくれるようなミッションを設定してね、と言われてる\n市場の変化や会社の方針などによって色々在るが 5 年間は頑張ろうという意味でもあるのかな。\nObjective と Key Results の理解 これはとてもシンプルで前述している通り、Objective と KeyResults のみからなる。\n各項目は以下のような性質を持つ\nObjective 定性的でチームのテンションが上がるような１文にまとめる チームが独立して実行できるものにする 達成のための期間を設定する、例えば四半期や半期などを考えられる KeyResults Objective で設定した感覚的なことばを定量化する 達成するのが困難だが、不可能ではないものを設定する Objective と KeyResults の設定 実はこれの決め方についてはあまり紹介されている書籍やブログなどが見当たらなかった。\n一方で実際に OKR をやってみて思うのは、「実行するチームが Objective を深く理解すること」が最も重要なことだと思った。\nいろいろなワークショップ手法や雑談など何でもいいが、チームが OKR をやることを心から納得していて、設定された Objective を自分にとって達成したいと思えるものに言い換えることができればあとはなんでもよい。\nあとで Good/Bad などまとめるが、それよりも上記を達成することに力を注いだほうが絶対にいい結果になる。\nちなみに会社のミッションの設定から OKR の設定まで 4 時間ほどで完了できたら順調くらいの温度感。\nOKR Tree これは必要な組織のみやれば良い\nまずは会社のミッションから経営層などが OKR を設定し、その KeyResults を下位組織の Objective を同等の関係性になる\nイメージはこんな感じ、\nMission 会社の Objective 会社の KeyResults KeyResult 1 (= 部署 1 の Objective) 部署 1 の KeyResult 1 部署 1 の KeyResult 2 KeyResult 2 (= 部署 2 の Objective) 部署 2 の KeyResult 1 部署 2 の KeyResult 2 OKR の Good/Bad とその例 Good \u0026#x1f44d; Objective は若干気後れするくらい高いレベルに設定する KeyResults は評価を単純にするために数値化して測定する OKR を組織全体に公開する 会社に来ることが楽しみになるような目標になっている Bad \u0026#x1f44e; 個人を評価するために使う タスク管理のために利用する OKR の運用 毎週月曜日に１週間の仕事を計画し、金曜日にその達成を祝う。というのが基本のリズム\n月曜日の計画でやること 今週の最優先事項の設定 今後 4 週間 OKR の自信度状況の更新 健康・健全性指標の確認 水~木曜日 ここでは計画したことを実行\n金曜日に Win Session 月曜日に計画したことの達成有無を確認する\n達成のためにやったメンバーの素晴らしい仕事や助けられたことなど些細なことでもお互いに褒める\nあまり書籍などには書かれていないが、逆にそうではないことを指摘する場にもなるといいと思う。 （これが褒めることが目的になって馴れ合いっぽくなって改善されないこともあるので）\nOKR を振り返る OKR ははじめ失敗することが当たり前とされている\n最初に設定した期間が終了した時点でその間どうだったかを振り返る\n設定した Objective は本当に野心的だったか 難易度が低く達成できてしまった 抽象的すぎて日々意識することができなかった etc 運用方法について KeyResults が計測できる形でなく進捗を計測できなかった 毎週 Objective に近づけるタスクを立てられなかった etc 正直この当たりは実行した組織によっていろいろ在ると思う。\nこれをしっかり運用できるか、失敗を前提としてチームが振り返ることができるかが重要だと感じる。\nなぜ OKR は失敗するのか 参考にした書籍には、OKR 導入の最初は失敗するものだと明言されている。\n実際はわからないが、チームが合意できてなかったり、会社のミッションと関係性が作れていなかったりなどあるだろうが、いずれにしてもそれを四半期で振り返り、改善することができなかったら成功することは無いと思う\nまとめ まずは正式なフレームに沿って運用するべき 最初は失敗するのが前提 設定した期間が終了したら OKR を振り返り改善することを必ずする あたりを守っておけばひとまず運用はスタート出来るんじゃ無いかと思った\nあとは Google re:works のブログなど見ると良さそう\n","permalink":"https://konumaru.com/202206/okr%E3%82%84%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AB%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84%E3%81%93%E3%81%A8/","summary":"\u003cp\u003e目標設定のフレームワークとして OKR を採用することにしたので、OKR 導入のために必要な基礎的な知識をまとめる。\u003c/p\u003e\n\u003ch2 id=\"okr-とは\"\u003eOKR とは\u003c/h2\u003e\n\u003cp\u003e目標の設定・管理方法の１つで、Objective と KeyResults の略称\u003c/p\u003e","title":"OKRやるときに知っておきたいこと"}]