毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
開発しているアプリケーションのフロントエンドの様子を見る会（フロントエンド草むしり会）を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に
自作DBを始めたい人におすすめの本 - salachike:blog
この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論
進撃のプロダクトマネジメント｜坪田 朋
僕がサービス開発で意識している心得や考え方をざっと書いてみたので、プロダクトマネジメントの参考になると嬉しいです。 プロダクトマネージャ(PdM)として意識していること先ず実行し、同時に深く考えていく 新規サービス・新機能立ち上げ期は、色んなアイディアが出てくるので、ブレがちだけど、自分のスタイルはとにかく早く作って、自分達で触って感覚掴んで、顧客に使ってもらった感想を聞くことを大事にしてる。 — 坪田 朋 / クラシル (@tsubotax) October 23, 2021 新しい取り組みの時は、先ず形にして行動しながら考えを深めるを強く意識します。 例えば、新しい機能を検討する時は、先ずデザインを起こし、ユーザーニーズを把握する時はそのデザインを見せながら意見を聞き、手触り感を重視する機能ならモックアップを作って触りながら考えを深めてく事にしている。 長い期間計画してもプロトタイプを
Team Topologies(by Manuel Pais)のキーポイント
この記事について CaSEというPodcastを時々聴いているのだけど、その最新話がTeam Topologiesの著者であるManuel Pais氏のゲスト回だった。すごく学びが多く、同じ悩みをもつ人も多いと思ったので内容や思考を整理してみたものを記事化してみた。ちなみに書籍のTeam Topologiesは読んでいません。 “two pizza” チームの挑戦 話はAmazon CTOのVerner Vogelのインタビューから始まる。2006年頃にジェフベゾスがTwo pizzaチームの話をしたのは有名だが、面白いのはAWSはまさにプラットフォームチームをX as a Serviceモードにした結果になっていて、意図的ではないにしろトポロジーを体現していたのだと思った。これは後半のプラットフォームチームの話にも繋がってくる 本題に戻ると、Two pizzaサイズで自己組織化に向かった
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
2kgから800gに激減、教科書「PMBOK」新版に何が起こったのか
「プロジェクトマネジャーの教科書」とも呼ばれる「PMBOKガイド」第7版の日本語版書籍が2021年11月1日に発売される。第6版は重量が2kgあったが、新版は800gと一気に軽くなった。プロジェクトの流れをまとめたプロセスの記載が姿を消し、プロジェクト運営を成功させる「原理・原則」が前面に出るなど構成が大きく変わったことが影響した。変化が激しい時代に対応するため、開発プロセスにかかわらず活用できるように転換した。 米PMI（Project Management Institute）が発行したPMBOKガイド第7版は、従来版とは全く異なる構成になった。翻訳作業に中心的に携わったPMI日本支部の庄司敏浩標準推進委員会委員は「プロセス中心の構成をやめた」と説明する。 第6版までのPMBOKガイドは、QCD（品質・コスト・納期）をはじめとする要求事項を満たして円滑に成果物を作り上げることを重視して
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
リモートアジャイル開発のノウハウ集 第2版を公開しました | Agile Studio
Agile Studio プロデューサーの木下です。2020年の3月に公開した『リモートアジャイル開発のノウハウ集（第1版）』に続き、このたび第2版を公開しました。こちらからダウンロードいただけます。...
マイクロマネジメントは悪か？よりよい組織をつくるためのマネジメント形態についての考察 - クックパッド開発者ブログ
レシピ事業サービス基盤部で部長をやっています、新井(@SpicyCoffee66)です。引越しを機に MtG のカードをほとんど売ったはずなのに、そのときは存在しなかったポケモンカードのデッキが手元にあります。なぜ？ 私は 2017 卒のエンジニアとしてクックパッドに入社し、様々な業務を経験した後に 2020 年の 8 月から部長となりました*1。最近はコードを書いていないので Techlife の執筆内容に迷ったのですが、今自分の中にある「優れた組織づくりについての考え方」をまとめてみることとしました。部長になる前にも、グループ長として小規模なチームマネジメントの経験があるとはいえ、それを含めても２年弱のマネージャー経験しか持っていないので、これが絶対の正解というわけではなく一つの考えとして読んでいただけると幸いです。 組織の存在理由 優れた組織づくりについて考えるために、まずは組織の存
新参者だけどバーンアウトしかけているチームを立て直す
ジョインしたばかりの組織に違和感を感じたとき、新鮮な目線で改善すると良いよという発表をしました。
プロダクトマネジメント私記
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型
アンチフラジャイルの世界
3. Cynefin Framework Chaotic Complex Complicated Simple / Obvious Disorder 問題に対する解: 1つは既知 (最良かどうかは分からない) 問題と解の因果関係: あり 問題の解き方: 把握-分析-対処 問題に対する解: 1つで既知 問題と解の因果関係: あり 問題の解き方: 把握-分類-対処 問題に対する解: 未知 問題と解の因果関係: あり 問題の解き方: 調査-把握-対処 問題に対する解: 未知 (問題も不明) 問題と解の因果関係: なし 問題の解き方: アクション-把 握-対処 解決策を得るための方向にはパ ターンがある 既知の解法から選択して適用す る (Good Practice) 既知の解法を適用する (Best Practice)行動を起こして、Complexな状 態に移行させる。 分からないことが分からな
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
10 年前に JavaScript で Flash Player を開発し買収された話
この記事は、JavaScript で Flash Player の実現を頑張った（もしくは現在進行系で頑張っている）人たちの集う Flash Advent Calendar 2020 に参加しております。 私は過去に自分が設立した会社で ExGame という HTML5 実装の Flash Player（正確には Flash Runtime Engine）を開発し、その会社ごと DeNA に買収（M&A）されました。あまり出来ない体験であるのは間違いないので、Flash が終了を迎える今、改めて振り返ってみようと思います。 Flash Player の開発 今から 10 年前の 2010 年、ちょうど iPhone が普及し始めてきてガラケーのシェアが 8 割から 6 割くらいに落ちようとしていた時期に、私は Flash Player を JavaScript で実装していました。以前この
1on1ミーティングとは？その意味と、効果的に行う方法 | Coral Capital
本連載はオープンソースライセンスの1つであるGPLの元に公開されている「The Eng Team Handbook」（エンジニアチーム・ハンドブック）を翻訳したものです。開発チームが効率的に仕事するために必要な「効果的な1on1の実施方法」「開発メンバーから開発マネージャーにポジションが変わるときの注意点」「パフォーマンス評価のテンプレート集」「360度評価のテンプレート」などが含まれます。 著者はStripeのエンジニアであるrayleneさんです。これがStripeのやり方と明示されているわけではありませんが、急成長するシリコンバレーのスタートアップにおけるエンジニアチームの取りまとめ方という意味で、日本のスタートアップでも参考にしていただけるのではないかと思います。オリジナルの英文の文書では、まだ未着手の項目もありますが、すでに書き終わってるものについて翻訳し、連載の形で5回に分けて
MVP（Minimum Viable Product）とは？実践するメリットと検証方法
Interaction Design Foundationはグローバルにデザインレベルの向上を目指す、デンマーク発の非営利団体です。 MVP（実用最小限の製品： minimum viable product）という考え方が広まったのは少し前のことです。MVPはFrank Robinson氏によって定義され、起業家であり学者のSteve Blank氏と、リーンスタートアップ（Lean Startup）を提唱したEric Ries氏という２人のプロダクトデザインの権威によって有名になりました。 MVPとは？ 簡単に定義すると、MVPとは、製品を提供する上で必要最小限の機能のみをもつ、もっともシンプルな製品です。しかし一般的には、「顧客価値があり、利益を生み出せる最小限のもの」と考えられています。 MVP戦略においては、価値基準を理解することが決定的に重要です。たとえば、車輪は車輪だけではユーザ
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
価値あるものをチームで届ける
不毛な会議を防ぐには - yuiseki
