Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。サイボウズの2023年度 新入社員向け研修の資料です。 本資料をもとにした書籍も発売中です：https://amzn.asia/d/2hQNEk2 Twitter：http…
NTT Com オンボーディングハンドブック
オンボーディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したオンボーディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/onboarding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『オンボーディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したリモートワークハンドブックや、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 はじめに
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算
「結果が出ない焦り」と向き合う方法｜柴田史郎
柴田（@4bata）です。連休なので、適用範囲は広いけどすぐに役立たないことを調べつつ、自分なりに言語化します。 やりたいこと「一定の経験や学習量を超えるまでは全く答えが見えず、ある日突然答えが見える経験」の言語化2019年の10月に、今働いている会社で管理部門全般の責任者になることが事実上決まった。2021年の5月現在、「やっと、担当範囲の全体像がつかめてきたぞ、あと少しで、施策の優先順位等をつけられるな」という手応えを感じている。ここまで1.5年。この前にやっていた人事職でも、2年ぐらい同じように試行錯誤をしていた期間があったので、個人的には焦りはなかった。ただ周囲を見渡してみると、「2年ぐらいは結果でないけどやってみるかー」というスタンスで仕事に取り組める人ばかりではない。なので、言語化してみたい。 よくある「努力と結果は比例しない」の説明。これも現実とは違う。よくある説明図。頑張っ
はじめに クラスメソッド株式会社で取締役及びAWS事業本部の本部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業本部の本部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって本部長を引退することにしました。 部長や本部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は本部長という役職で、事業本部の中に部があり
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
風音屋（@Kazaneya_PR）では、メンバー1人1人のスキル水準をモニタリングし、さらなる成長を促すための仕組みとして「等級（グレード）」を設定しています。プロフェッショナル人材が少しでも正当な評価とフィードバックを受けられるように試行錯誤を経てきました。 採用選考を進める中で「自分の場合はどのくらいのグレードになるのか？」というご質問をいただく機会が多々あります。この記事では、どういった考え方でグレードを設計・運用しているのかを、給与テーブルとセットで解説します。 注意事項クライアントワークを担当するAnalytics部門を想定した内容となっています。Backoffice部門の給与テーブルは試行錯誤中ですが、ベースとなる考え方は同じような形に落ち着くはずです。 人事周りのルールは今後変わっていく可能性があります。最新状況についてはカジュアル面談でお問い合わせください。 すべての人にと
マネージャー＆リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）
Henry 🤡🦊🐵 on Twitter: "スクエニが公開したPM講座。 著者は2011年当時CTOだった橋本善久氏。 氏はこの後、酷い初代FF14の立て直しに貢献し成功に導いている。 10年経っても色褪せておらず、プロジェクト管理に携わる方は必読。 画像は抜粋したも… https://t.co/qGRAg2n5q6"
スクエニが公開したPM講座。 著者は2011年当時CTOだった橋本善久氏。 氏はこの後、酷い初代FF14の立て直しに貢献し成功に導いている。 10年経っても色褪せておらず、プロジェクト管理に携わる方は必読。 画像は抜粋したも… https://t.co/qGRAg2n5q6
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design
2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/
株式会社商船三井様の社内セミナーで用いた資料です。 関係者の許諾を得て公開しています。 関連記事「DXに関する私的な殴り書き」 https://yuzutas0.hatenablog.com/entry/2020/06/02/110000 関連スライド「民間企業におけるDXの事例と課題」…
近年、何かと自走、自走って言いますよね。「自走力」とか、「自走できる人が必要」とか。すごく抽象度の高い言葉ではありつつ、社会人生活においてとても求められる力、価値のある力なのは確かなようです。 となると「そもそも自走とは」「自走できるとは」という話になります。これに関して先日、Engineering Manager Meetupというオンラインイベントで、同業の人々と話す機会がありました（Engineering Managerとは、ざっくり言うと、エンジニア組織においてピープルマネジメントを含むマネジメントをやっている人です）。 そこで挙がった「自走できる」とは、端的に言うと以下の通りでした。 総じて、「指示が必要」の反対である。 自走できる人は、 ・粒度の大きいゴールを目指して行動できる。 ・完了状態を自分で定義できる。 ・自分で勝手に成長できる。「確かになー」と。マネージャーからすると
ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ
こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 Twitterもやっているのでフォローしてもらえると嬉しいです！ こんなアイコンです 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と
なぜ休みの延期はこれ程までに辛いのか。 そう打ちひしがれる俺に、脳内でダニエル・カーネマンが語りかけてくる。 「それはこのグラフで説明できる」と。 延期となった休み 10月5日に休みをとる予定だったのだが、延期となった。俺はいつ休みをとるか年度の始めに1日単位で計画するタイプなので、半年以上前から予定していたことである。一週間以上前には上司から許可をもらっていた。しかし、様々なイベントが重なった結果、この日に休むのは厳しい状況となり、とりあえず一週間延期となったのだ。 この対応について俺は納得している。業務の観点からは10月5日という日は「特別な日」となったので出勤した方がいい。対してプライベートな観点からは10月5日という日は特別ではない。旅行の予定があるとか*1、彼女の誕生日だとか*2、そういった日ではないのだ。せいぜい時間をかけて重いブログ記事を書こうと考えていた程度である*3。 な
オープンオフィスで8分仕事を続けると発汗量34％、ストレス25％増加という研究結果に納得する感想「わかる。個人の空間が一番」
リンク GIGAZINE 間仕切りのない「オープンオフィス」では雑音がネガティブな気分を25％も増幅させるという研究結果 デスクを収納やパネルで仕切り、オフィス全体に天井までの間仕切りを設けない「オープンプランオフィス(オープンオフィス)」は、社員同士のコミュニケーションや部署の垣根を越えたコラボーレションを促進するなどの理由から、多くの企業が採用しているオフィスレイアウトです。そんなオープンオフィスについて、作業環境が認知やパフォーマンスに及ぼす影響について研究しているボンド大学のリビー・サンダー助教授が「オープンオフィスはストレスを増幅させて気分を悪化させる」と警告しています。 39 users 365 ライブドアニュース @livedoornews 3000RT：【雑音で】間仕切りのない「オープンオフィス」ではネガティブな気分が25%増加 豪大学研究 news.livedoor.co
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2022年度リクルート エンジニアコース新人研修の講義資料です
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
新規事業を加速させるリサーチ術/ Research tips for new biz creation
ビザスクさんにお誘いいただき、企業内新規事業担当者の方などに向けて、リサーチに関するお話をしました。 https://visasq.co.jp/seminar/research0728 調査、正しく使うと楽しいし、ためになるよ、というお話をしています。 30分くらいでお話したので、同じような講…
オリジナルグッズ作成・販売サービス「SUZURI」に関わるエンジニアメンバーや事業部長が登壇し、SUZURIの開発の今や、現在の課題・今後の取り組みについて話す「43万人超のクリエイターの表現活動を支える！ECプラットフォームSUZURIの開発の裏側」。ここで技術部の近藤氏が登壇。生産性をすることになった背景と、具体的な測定方法を紹介します。 自己紹介近藤宇智朗氏（以下、近藤）：では、お願いします。「生産性を可視化したい」と題して発表します。ということで、自己紹介します。私は技術部に所属している、近藤といいます。ふだん、インターネットなどでは“うづら”と呼ばれているので、お気軽にうづらと呼んでください。現在、技術基盤チーム兼データ基盤チームという感じで働いていて、SUZURIの事業部には直接所属していませんが、お手伝いという感じで今回はお話しします。 ちなみに、福岡市のエンジニアカフェとい
マネージャーの評価基準（シート・動画付き）｜長村禎庸@EVeM
はじめに約1年ぶりのエントリーになります。今回はマネージャーの評価基準というタイトルで書きたいと思います。 マネージャーを評価する基準というのはありそうでないなと、この1年色々な経営者・マネージャーの方と話す中で感じていました。 その時残すべき成果が出ていればマネージャーとしてOKとしている会社もあれば、「マネージャーとしての行動リスト」のようなものが5個〜多くて30個程度であり、その行動リストを評価とまではいかなくとも、チェックリストのように使っている会社もあります。 しかし、前者の場合は「成果が出ていれば色々な犠牲が出てもよし」となりますし、後者の場合は「行動リストのうち今必要が無いことも行動せよ」となるので、両方ともマネージャーを評価する基準としては何か違うなと違和感を覚えてました。 しかし、何を以て良いマネージャーなのか、それを判断する基準がなければ、マネージャーに何を求めて良いか
【資料公開】ステークホルダーとの付き合い方を考える
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2024年6月3日に行われたソニー主催、Forkwell共催の勉強会「TechLovers #2」の登壇資料を公開します。 プロダクト開発には、さまざまなステークホルダーが登場します。 プロダクトのフェーズや開発の状況によってステークホルダーの重要度は変わります。そしてステークホルダーごとに持っている権限の強さや権限が及ぶ範囲も違います。 これらを無視して開発を進めると、プロダクトに大きな影響を及ぼすようなことが起こりかねません（メテオフォールなるものもその1例です）。 つまり、戦略的にステークホルダーと付き合っていかなければいけません。 この資料では、フレームワークを活用してステー
プロダクトマネージャーカンファレンス2021登壇時の資料です。 https://2021.pmconf.jp/sessions/pkikYIU5
Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops #TechMar / 20211210
---------------------------------------------------------------------------------------- 【PR】一緒に働きましょう！ https://kazaneya.com/kdec -------------------…
Twitterでのつぶやきの半分以上は組織づくりやマネジメント関連なんですがどこかにまとめたこともなかったので整理の意味も含めて書いていきたいと思います。これが正解だ！なんて言えるわけもなく、個人的な経験をもとに書いていきますので後日読んでくださった方々と語らう場が設けられたら幸せだなと思っています。ですから温かい目と心で読んでくださると幸いです。 マネジメントの基本理念マネジメントの基本理念は「成功したらメンバーのおかげ、失敗したらマネージャーの責任」これに尽きると思います。基本的な役割はメンバーが保有している能力の総和を超える成果を出すことだと考えていますがそのためには上記の理念が欠かせないと思っています。 もちろん組織によって役割はそれぞれだと思いますが、ことベンチャーにおいてはとくに「成果を出すこと」と「人材を育てること」の両軸が必要であり、両立する難易度が極めて高いのですがそれで
システムの要件定義とは、そのシステム開発を行う上で実施すべき業務の内容を整理してわかりやすく文書化することです。基本の考え方や要件定義書を作成するまでの進め方、必要な準備について、IT業界経験10年以上のシステムエンジニアが説明します。 システム要件定義とは システムの要件定義とは、システム開発を行う上で実施すべき業務内容をあらかじめ想定し、わかりやすく文書化するプロセスです。 実際にシステム開発プロジェクトを進めていく上で、目的や内容はもちろん、スケジュールや開発予算、開発に関わるメンバーなど、想定しておくべきことはたくさんあります。 こうした各要素をあらかじめ具体的に想定し、文書化しておけば、プロジェクトを計画通りに進められる可能性が高まります。計画通りにプロジェクトが推進できれば、事業を成功に導くことができます。 つまり、要件定義の成否によって、プロジェクトを計画通りに進めることがで
なぜSpotifyはOKRをやめた？アジャイル組織に最適な目標管理「Spotify Rhythm」とは｜加藤 章太朗
なぜSpotifyはOKRをやめた？アジャイル組織に最適な目標管理「Spotify Rhythm」とは こんにちは、加藤章太朗（@katoshow）です。 前回のnoteでは、自律分散型の組織の1形態である「アジャイル組織」について説明しました。 今回は、アジャイル組織の代表Spotifyが採用する目標管理のフレームワーク（戦略フレームワーク）についてお伝えします。 Spotifyでは、2014年まではOKRを採用していました。Googleなどで大きな成果を上げたOKRは、日本でも昨今導入が進んでいます。しかし、SpotifyはOKRをやめ、Spotify Rhythm（スポティファイリズム）という独自の目標管理フレームワーク（戦略フレームワーク）に移行しました。 SpotifyがなぜOKRをやめたのか？そしてSpotify Rhythmとはどのようなものか？について説明していきます。 ※
Overview of The Modern Data Stack / モダンデータスタック概論
顧客に価値を届け続けられる プロダクトであるために ~B2B SaaSにおいてプロダクトビジョン・戦略を改めて 策定するまでの道のり~
不確実性の高い機械学習プロジェクトを自己組織化されたチームで健全かつ最大化されたゴールに向かうために
DMBOKに基づく「データマネジメント成熟度アセスメント」を実施してみた話 - Leverages データ戦略ブログ
はじめに こんにちは。レバレジーズのデータ戦略室の辰野です。いつの間にか5回目の投稿を迎えました。 今回は、私が2024年度上半期に注力した「DMBOKに基づくデータマネジメント成熟度アセスメントの実施」についてご紹介できればと思います。 レバレジーズでは初めての実施ということもありかなり苦労したので、これからデータマネジメント成熟度アセスメントを実施してみよう！と思われている方にとって、参考になれば幸いです。 ※ベースとなるDMBOKに関する情報は、既に多くの記事が出ているかと思いますので本記事では割愛させていただきます なぜやることになったのか 例えば、皆さまの周りでこんなことは起きていないでしょうか？ 「テーブル定義書はあるけど、実際のテーブルと内容が違う…」 「この指標の定義を知りたいけど、どこを見ればいいのか分からない…」 「このツールの使い方がどこにまとまっているか分からない…
こんにちは。ExaWizards という会社でPM（プロダクトマネージャー）をしている宮田(twitterアカウントは@miyattiです)です。エクサウィザーズ に入社してもうすぐで２年になります。いろいろやってきましたけど、最近はずっと「CareWiz 話すと記録」というプロダクトのゼロイチのPMをやっています。 今回はエクサウィザーズ でやっているプロダクト開発のプロセスの一例を紹介させていただきます。 エクサウィザーズ 自体なんの会社なの？コンサルの会社でしょ？と言われることもあったりしますが、実際は社会課題解決xAIなプロダクトを複数立ち上げていて、割と泥臭くいくつかのチームにわかれてそれぞれにPOやPdMががんばってプロダクトの企画開発をやっています。 なので、その中心となるPMによってやり方は千差万別というのが正直なところです。今回は私が担当する「CareWiz 話すと記録」
こんにちは、株式会社JADE創業者の長山一石です。今日は、「JADEがどのような考え方に基づいてWebマーケティングの戦略を作っているか」という点を、特に検索エンジン最適化 (SEO) の観点からお話ししたいと思います。 しばしば担当者から聞かれる SEO 上の悩みとしては、「さまざまな施策がアイデアとして出たり、コンサルティング会社から勧められたりするが、それらをどういうふうに優先づけするかが難しい」というものがあります。「まずはこれをやればいい」というような普遍的なものがあれば楽なのですが、あらゆるサイトに共通する優先順位というものは存在しませんから、実際には担当者がリソースと睨めっこしながら優先順位とタイムラインを決め、どの順番で施策を実行していくか決める必要があります。この時、SEO の考え方が平面的だと、優先順位の付け方がうまくできません。JADE では、できるだけ解像度を高く、
[EMゆるミートアップ vol.6 〜LT会〜 - connpass](https://em-yuru-meetup.connpass.com/event/308552/) での発表資料です。
1990年大阪大学経済学部卒業後、プロクター・アンド・ギャンブル・ジャパン（P＆G）マーケティング本部に入社。「パンパース」「パンテーン」「プリングルズ」「ヴィダルサスーン」などのブランド担当。2006年ロート製薬入社。執行役員マーケティング本部長として60超のブランドを統括。ロクシタンジャポン代表取締役、スマートニュース執行役員マーケティング担当（日本・米国）を経て、M-Forceを創業。Strategy Partners代表取締役社長 ――今のマーケターに対して感じている課題を率直に教えてください。 最大の課題は「How（方法）」への傾倒です。デジタル技術を活用したマーケティングの進化で、AI（人工知能）などによる最適化のオートメーションは進んでいますが、そのツールを使いこなすことに躍起になっています。マーケターと話していても、「Who（誰に）」や「What（何を）」が会話の中で出てこ
「マーケティングやりたい人」がマーケターに向いていない理由とは？ディノス・セシール石川氏＆WACUL垣内氏が世のマーケター像をぶった斬る！ | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
そこで記念すべき10記事目は、おなじみWACUL垣内勇威さん（@yuikakiuchi）と、その垣内さんが「この人は本当にすごい！」と太鼓判を押すディノス・セシールCECOの石川森生さんに取材の機会をいただきました！ BtoBからBtoC、大手からベンチャーとさまざまな企業におけるマーケティングを経験・支援されているお二人に、全マーケターが気になるテーマである「マーケターのキャリア」についてお話をうかがうことに。いったいどんな切れ味鋭い言葉が飛び出てくるのでしょうか……！（震） マーケターとしてスキルアップしたいみなさま、これからマーケターを目指すみなさま、心してご一読ください！ 株式会社ディノス・セシール CECO 石川森生 さん1984年生まれ。SBIホールディングス入社後、SBIナビ（現ナビプラス）の立ち上げ。その後、ファッション通販・マガシークでマーケティング責任者として、サイトリ
スクラムフェス大阪2022 https://www.scrumosaka.org/ https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16573 Rettyのエンジニア組織は、2017年頃崩壊の危機にあった時期が…
データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。 最近、社内でディメンショナルモデリング勉強会を行なったですが、なぜ勉強会を行なったのか、どのように行なったのか、勉強会を行なった結果何が得られたかについてまとめます。 ディメンショナルモデリング勉強会開催の背景 勉強会の進め方やスコープ 勉強会の参加者 勉強会で学んだ内容 Four-Step Dimensional Design Process キーの設計について 複数スタースキーマを適切に利用し、ファントラップを避ける コンフォームドディメンション まとめ: 勉強会で得られたもの ディメンショナルモデリング勉強会開催の背景 前回のエントリにまとめた通り、10Xのデータマネジメントの課題の中でも「データウェアハウジングとビジネスインテリジェンス」は優先度が
Looker Advent Calendar 2020 2日目の記事です。 この記事ではLookerの活用例を紹介します。 免責事項 正確にはLookerそのものに関する話ではなく「Lookerを含めて様々なツールを組み合わせることでビジネスを加速させようぜ！」という話です。 本稿は筆者個人の見解であり、所属組織を代表するものではありません。不適切・考慮不足だと感じさせてしまう点があれば、それは筆者個人の責任によるものですので、どうぞ筆者個人宛てにご指摘のコメントをいただけますと幸いです。 ランチ返上の突貫執筆なので気が向いたときに手直しします。 誰？ はじめまして。 ゆずたそ (@yuzutas0) と申します。 『データマネジメントが30分でわかる本』 という本の著者です。 筆者が関わっているFinTechベンチャーでは「金融事業としての品質」「ベンチャーとしてのスピード」の両立が求め
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テクニカルライティングの基本 2023年版
プロジェクトリーダーというお仕事 - Qiita
管理職のための役職引退マニュアル | DevelopersIO
失敗したエンジニア組織施策としくじりの反省｜nottegra@無職
メンバー1人1人のスキルアップを促す「等級（グレード）」と「給与テーブル」｜風音屋（かざねや）
DXを妨げる要因と実現へのアプローチ by @yuzutas0 / 20211022
どうやったら「自走できる人」になれるのか｜nacam403
なぜ休みを延期することはこれ程までに辛いのか - 本しゃぶり
「終わらなかったから次のスプリントにまわそう」なんてありえない
“生産性向上に投資するため”のデータの可視化 生産性測定から組織の仕組み作りをサポート | ログミーBusiness
Noを伝える技術 #pmconf2021
組織づくりやマネジメントについての雑記｜しげの
システムの要件定義とは 進め方や必要な準備をわかりやすく解説
AI Project Management Flow and Build Trap Review
エクサウィザーズのPMが考える最強のプロダクトマネジメントプロセス｜エクサウィザーズ HR note
検索インタラクションモデル概論-JADEが日々使うSEO分析フレームワークの話 - ブログ - 株式会社JADE
「トップ10プランナー」からはじめる目標設定
スマニューが使われなかった衝撃の理由 デジマ傾倒の落とし穴
組織の崩壊と再生、その中で何を考え、感じたのか。 そして本当に必要だったもの
ディメンショナルモデリング勉強会を実施しました - 10X Product Blog
Looker活用によるバイモーダルITの実現 - 下町柚子黄昏記 by @yuzutas0
www.agara.co.jp
l.smartnews.com
news.yahoo.co.jp
news.yahoo.co.jp
philpeople.org
www.gadget2ch.com