サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては
久しぶりに転職をした。 理由は「上司がクソ・年収も上がらない」という至極単純なもの。 自分は人手不足と言われているエンジニア業界でも、人が居ないと嘆かれている言語のエンジニアである。 正直に言って、今までは求人に乗っかればそれなりに内定を取れたので、そんな感じでいくだろうとタカをくくっていた。 ところが、今回の転職はめちゃくちゃ難航した。 受けたカジュアル面談は20社近く。 約半数の選考に進み、スキルチェックで落とされたのが3社、面接で落ちたのが2社、内定獲得したが辞退したところが3社。 打率3割は高いと思うかもしれないが、経験者なら誰でもOKのSESなので自慢にならないんだ。すまんな。 最終的には良さげなところを見つけ転職は幕を閉じたが、かけた期間はおよそ6ヶ月。 それをぼちぼち忙しい業務の合間と土日に行っていたので、もう身も心もすっかり摩耗した。 ようやく落ち着いて新しい環境にも慣れた
今やあらゆる場面で必要とされるプロジェクトのノウハウを、300件以上成功させてきたプロフェッショナルがこっそりお伝えします。 先日、仕事で関わっている方から、「結局、プロマネって何ができないといけないんですかね？」という質問をされたので、その場でざっくり洗い出してみました。 世の中には PMBOK や ITSS, PRINCE2 などのスキル標準を定めたものはありますが、これらは大規模システム開発を志向しており、概念として抽象度が高いためベースの知識として利用できる環境は残念ながら非常に少ないという現実があります（もしこれらを利用できる環境にいるならとても幸せなことです）。 少なくとも日本で実施される一般的なプロジェクトは PMBOK や ITSS を元に共通認識を整備するどころか、「限られた予算で1年でクライアントのシステムを刷新する必要がある」とか、「社長の思いつきで何も決まっていない
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
出世する、より上位の管理職に上がって行くというのは、マネジャーとしての力量や適正も必要だけれど、「どこまで奉仕できるか（どこで降りるか）」によるところが大きいのだろう。その奉仕水準でどこまで行くか／どの辺で止まるか均衡するのだと、会社で仕事をしながらつくづく感じるこのごろ。 ポジション上昇の基本路線 新人→中堅社員→係長→課長→部長→……とポジションが上がるに従って、受け取る仕事の粒度が大きくなってくる。 重要度や影響度から正確にリスクを抽出して優先順位を決められる。 大きな仕事を適切に分割して相互関係を理解できる。 期日から逆算して分割した仕事にマイルストーンを割り当てられる。 情報を整理して他者に状況を正確に説明できる。 自分にない力量を持つ他者・他部門に割り振れる。アウトソースできる。 といった管理能力がより高度に必要になってくる。 逆に言えば、こうした技術・能力が高い人をより高いポ
タイトルは、ポール・グレアム氏（Yコンビネーター）の「メイカー（作り手）のスケジュールとマネージャーのスケジュール」(Maker's Schedule, Manager's Schedule) からの引用です。 マネージャーは多くのミーティングをこなすなど、1時間単位でタスクにあたりますが、エンジニア（プログラマ）は最低でもまとまった半日単位の時間を作業に必要とする、と書かれています。 paulgraham.com 日本語訳 note.com エンジニア上がりのプロダクトマネージャーとして開発もプロダクトマネジメントも並行してこなしてきたのですが、意思決定のためのミーティングスケジュール、自身が開発を行うためのスケジュールをやりくりするバランスに腐心していました。 自身のタイムマネジメントで特に感じた点として、ミーティングとミーティングの間に1時間が3コマある時の開発生産性と、3時間まとま
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 本稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。 本稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。 なお、本稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。 発表資料と発表動画はコチラ 2. 施策の効果 私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。 あまり
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
デブサミ2020夏の発表資料となります。 当日発表しなかった資料についても参考資料として最後に追加しております
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう！ スプリントの期間延長は絶対NG 大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン
マネージャーは「面倒なことをやってくれる人」なのか 最近マネージャーな方を「面倒なことをやってくれる人」として認識されていることがあります マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ？」って言われることもあります なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります マネージャーは「面倒なことをやってくれる人」なのでしょうか 「面倒なことをやってくれる人」と思われる背景と影響 「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな？と思いました 自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です 結果としてメン
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数
たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算
管理職とは、企業において、部門・チームをまとめ、部下の育成を担う役割。従来、多くのビジネスパーソンにとって、管理職になることは出世と成功への道であり、将来の目標でした。 しかし近年は、「苦労に見合った給与がもらえない」「責任が重くなる」「プライベートの時間が減る」といった理由から、「管理職はコスパが見合わない」「管理職になりたくない」と考える人が増えているようです。将来、今の職場で管理職になるかどうかを迷っている人もいるのではないでしょうか。 今回は、管理職の定義や役割、必要なスキル、管理職になるメリット・デメリットなどの基礎知識を確認したうえで、管理職にならないという選択肢についても考えてみましょう。 ＜INDEX＞ ・管理職の定義 ・管理職の役割と仕事内容 ・管理職に必要なスキル ・管理職に向いている人と向いていない人 ・管理職になるメリット ・管理職になるデメリット ・管理職になりた
これは、以前別のエントリに掲載した当時の自分のカレンダーの様子である。 マネージャーは油断するとカレンダーがこうなる（今はまだだいぶ余裕を保てているが）。 この図を掲載したときは、定例会を整理したという記事を書いた。 daiksy.hatenablog.jp この記事で書いた当時の自分の文章は、今読んでもおもしろい（おもしろくない）。 このように、10時から16時までのコアタイムは定例ミーティングで埋め尽くされている。これに、採用面接であるとか、突発的な相談ごと、四半期ごとのミーティングなどが数少ない隙間をさらに埋めていく。 ミーティングによって生じるコンテキストスイッチに脳は破壊され、ミーティングの合間の30分間はお手洗いや次のミーティングの準備、あるいは脳を休めるためのTwitterによって無為に消費される。マネージャーとして、組織を改善する施策やアイデアを時間をかけて練ったり、メンバ
パブリテック事業部プロダクトチームの所属のたけだです！ この記事はトラストバンクAdobent Calender 2024の記事です。 qiita.com 何を話すか 何を話さないか パブリテック事業部と私 LeSS実践者トレーニング（CLP）を受けて スクラム開発（LeSS）組織におけるマネージャーの役割とは Go See 開発を管理するのではなく、より高い提供価値のために改善する スクラムガイドに「マネージャー」というポジションが一切登場しない背景 DoD（DONEの定義）はチームの能力を表す コンポーネントチームではなくフィーチャーチームにする 自己管理化された組織づくり マネージャーはスクラムチームの中に置かない 個人の成長なくしてチームの成長はしない 社員採用にチームを巻き込む 個人だけで達成するような評価対象となる業績目標を設定しない リソース思考に囚われ過ぎない チームがオー
bookmarks.devは開発者向けに作られたオープンソースのオンラインブックマークツールです。 よくある（一時期に比べればかなり減りましたが）オンラインブックマークサービス同様、任意のWebサイトをタグやコメント付きでブックマーク、管理できる他、コードスニペットの管理も可能で、コメントもMarkdownを使えるようになっています。 スニペットはワンクリックでコピー可能で、通常のブックマークとは管理フォルダもブックマークレットも別になっており、混在する事はありません。 ブックマークツールにスニペット管理機能が付いただけと言われればまぁそうなんですが、あまり見かけませんでしたし、OSSなので自身でカスタマイズも可能な点は割とメリットな気がします。その場でコードを実行テストできるようにしたら捗りそうですね。 ライセンスはMITとの事です。 bookmarks.devOn Github
プログラミング言語を自前で創っていると，パッケージマネージャが欲しくなってくるものだ．既存パッケージマネージャやそのラッパーによる配布で事足りることも多いが，自前言語の要件とうまく合わなかったりして，真に自分で実装せねばならないこともある．そうした場合，パッケージマネージャをどんな設計にすべきだろうか？ 言語固有の都合には触れずになるべく一般に考慮すべき事項を洗い出し，簡単な設計例も提示してみたい． なお，本稿はパッケージマネージャの設計に焦点を当てたものであり，効率的に依存制約を解消するアルゴリズムなど実装の詳細については解説しない．実際例えばOCamlでは 0install-solver というOPAMの裏でも使われているパッケージを利用すれば制約解消アルゴリズムそのものに踏み込まずとも制約解消処理を実装でき，（それ自体に興味があるときを除けば）必ずしもアルゴリズムを理解する必要はない
The Password Manager Resources project exists so creators of password managers can collaborate on resources to make password management better for users. Resources currently consist of data, or "quirks", as well as code. "Quirk" is a term from web browser development that refers to a website-specific, hard-coded behavior to work around an issue with a website that can't be fixed in a principled, u
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに こんにちは。弁護士ドットコム株式会社エンジニアの砂川です。 社名と同じ弁護士ドットコム事業本部の開発部でエンジニアリングマネージャをしています。 弁護士ドットコムではいくつかのプロジェクトチームに分かれてそれぞれのミッションに取り組んでいます。 その中で今回は掲題の Working Agreement 1 2 を作成しながらチームビルディングをしていった話をご紹介します。 はじめに 導入 Working Agreementってなに？ 導入の背景 導入の流れ 実践 導入初期 追加されたルール例 導入から3か月 追加されたルール例 導入から半年 追加されたルール例 導入から一年 追加されたルール例 まとめ 導入 Working Agreementってなに？ Working Agreement とはチームで仕事をするときの約束事を書いたものです。会議をいつ行うのか、流れはどのように実施
好著である。まず、題名がうまい。「そうか、君は課長になったのか」というタイトルからは、課長というマネジメント職の仕事の心得を書いた本、というメッセージが自然に伝わってくる。おまけに、この口ぶりは上から目線だから、書いた人は会社社長か、少なくとも経営層の一員であることが分かる。それも、大企業のだ。 なぜ、大企業か。それは、君（たぶんかつての部下）が課長になったことを、著者が知らずにいて、気付かされたことを示すからだ。それは大きな会社でないと起こり得ない。経営者が部課長の顔と名前まで、すべてそらんじているような会社は、（売上や上場にかかわらず）中小企業と呼ぶべきなのである。著者は、大企業の経営層にいる。これが、読者に無意識な信頼度を与える。 本書は、「石田君」という架空の相手に向かって、アドバイスを送る形式になっている。文体は、「ですます調」だ。これも好ましい。ていねいな文体、漢字とかなの比率
この記事は Retty Advent Calendar 2022 Part1 の14日目の記事です。昨日は今井さんの『ストーリーポイント定規を作ってみた』でした。 今年も Part2 があるのでこちらもよろしくお願いします。自分は Part2 の16日にも記事を書きます。 はじめに aqua について チュートリアル 1. aqua のインストール 2. ツールの追加 2.1 Registry とは 2.2 aqua.yaml の生成 2.3 aqua generate によるツールの追加 3. ツールのインストールと実行 aqua のここが便利！ バージョンの指定、切り替えが簡単にできる バージョン切り替え時の挙動について バージョンの指定について aqua generate -s の利用 aqua.yaml による設定の共有ができる 設定ファイルの読み込みについて Renovate に
思い出すのも恥ずかしい黒歴史の塊なのに、今でもたまに見てしまうネットのページがある。 笑顔の大学生たち、楽しそうに練習する動画などありふれたコンテンツだが、このページを見るたびに恥ずかしくてどうしようもなくなる。 同志社大学のアルティメットチーム「Magic」のツイッターサイトだ。 そして、取り返しのつかない失敗をしたことや寂しさなどが入り混じった複雑な感情がよみがえり、胸の奥が痛くなる。 実はこのチーム。 1992年に私が、友人と2人で始めた小さなサークルだった。 相方の名前を、仙田とさせて頂く。 当時大学1年生だった仙田と私は、とにかく時間と情熱と体力を持て余していた。 大学に入ったはいいが、つまらない授業とバイトとメシを食べるだけで過ぎていく毎日は、退屈で仕方なかった。 大学生らしい無意味な野心や根拠のない自分への特別感もあり、何か大きなことをしたいとバカな妄想ばかりでいつも盛り上が
このエントリでは、僕がこの2年弱で読んだ約300冊のマネジメント関連本から、100冊を選んでカテゴリ別に紹介します。 背景 2014年8月に、それまで前々職から現職に至るまでいちエンジニアとしての経験しかなかったところから、総勢70人を越えるエンジニア組織のマネジャーになりました(参照: GMOペパボ株式会社の技術責任者に就任いたしました)。 僕は、決して地頭がいいわけでもなければ、コミュニケーション力に長けているわけでもなく、他人以上に努力をして初めて人並みに近づけるかもしれないというぐらいの人間です。それに加えて、冒頭に書いた通り、エンジニアとしては多少の経験は積んだものの、マネジメントについては完全に門外漢。経験に頼るわけにもいきません。諸先輩方にOJTしてもらいつつ身に付けるにも、既にマネジメントの業務は始まっているわけです。 「さて、どうしよう？」と考えた時、まずはとにかくマネジ
Format support: EPUB (.epub) PDF (.pdf) DRM-free Mobipocket (.mobi) and Kindle (.azw3, .azw) Plain text (.txt) FictionBook (.fb2) Comic book archive (.cbr, .cbz, .cbt, .cb7) Rich text (.md, .docx) Hyper Text (.html, .xml, .xhtml, .mhtml, .htm) Platform support: Windows, macOS, Linux and Web Save your data to OneDrive, Google Drive, Dropbox, FTP, SFTP, WebDAV, S3, S3 Compatible Customize the source
Psono is an open source and self-hosted password manager to help keep your data safe. It stores your credentials encrypted and only you can access your data. Access can be shared encrypted with your team. As an open source password manager, Psono comes with a variety of features to manage your data and access your passwords more easily than ever before.
管理職って、いろんな意味で「見えない負担」を抱えがちだ。 チームの成果を出すためにメンバーを支える 目の前のトラブルを解決しながら、将来の戦略も考える 上からの期待と、現場のリアルな状況の間で調整する 採用や評価、育成など、やるべきことが多すぎる このあたりの仕事は、誰かがやらなければいけない から、 結果的に「管理職がやるのが当たり前」となってしまうことが多い。 でも、これが続くとどうなるか？ 管理職が疲弊して、「もう無理だな」 となる。 そして、気づいたら 「管理職が次々と辞めていく組織」 になってしまう。 これって結構、根深い問題だと思うので、まとめてみる。 1. 「全部やるのが当たり前」になると、負担が限界を超える管理職の仕事は、基本的に「見えづらい」ものが多い。 メンバーのサポートや調整業務は、「うまく回っているときほど気づかれない」 ことが多い。 たとえば、 チームの方向性を整
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
