工数管理というものを理解する - Qiita
エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 はじめに 工数管理はプロジェクトの成功に欠かせない要素です。工数を正確に見積もり、管理することで、プロジェクトの遅延を防ぎ、クライアントやプロジェクトメンバーの信頼を得ることができます。 本記事では、工数見積もりの重要性とその手法、そして失敗しないためのポイントについて書きたいと思います。 「もっとこうした方が良いよ！」 や 「うちの会社ではこの様な考えで取り組んでます！」 があればぜひコメント欄で教えていただけますと幸いです。 工数とは？ プロジェクトや業務を完了するために必要な作業時間のことを指します。 「人日」 や 「人月」 と呼ばれており、1人日は8時間、1人月は160時間（1日8時間、平日20日稼働）で表現するケースが多
チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
リーダー経験ゼロのエンジニアがチームのリーダーに挑戦して、自己組織化したチームに近づいた話 - Qiita
1. はじめに 1年前の入社4年目の私は、開発チームのリーダーの経験はなく、また、スプリントの計画も立てたことが無いような状態でした。 そんな状態で、突然リーダーとしてプロジェクトの意思決定をすることになりました。 自分に務まるかとても不安で、恐怖すら感じていました。 実際にやってみると、これまでいかに作業者視点で物事を考えていたか、プロジェクト全体が見えていなかったのかを痛感しました。 現在では、マネージャーが休みや出張で不在の場合でも、私がいればうまくチームメンバと協力して開発を進めてくれると言っていただけるまでになりました。 それと同時に、より楽しく開発できるようになりました。 本記事では、私がリーダーとして振舞うことになった経緯と、その振る舞いの具体例を紹介します。 同じような開発者の方の参考や励みになればと思います。 2. チームの背景 1年前当時の私が所属しているチームは以下の
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
プロジェクトマネージャ試験に20時間の独学で一発合格した方法 - 斗比主閲子の姑日記
昨年10月にIPA（情報処理推進機構）の国家資格『プロジェクトマネージャ試験』を受験しました。 年が明けて「そういえば合格発表はいつだったっけ？」とIPAのサイトを見に行ったら、昨年12月下旬には合格発表がされていて、無くさずに持っていた受験票の情報を使ってチェックしたら、合格していたのでした。結構厳しいかと思っていたので、新年早々かなり驚いてしまい声が出たので、家族には変な目で見られました。 ※午前1は免除。午前2と午後1は60点以上で合格、午後2は4段階でAが必須 この記事では、非エンジニアの私がどうしてプロジェクトマネージャ試験を受験をしようとしたのか、どのような勉強をしたのかを紹介します。どなたかの参考になれば幸いです。 受験のきっかけ 2週間（20時間）しか勉強しなかった背景 勉強計画の策定 各試験のリソース配分 午前2（試験時間40分） 勉強時間 3時間 午後1（試験時間90分
チーム仲は悪くないのに「何となく一体感がない」時に試してもらいたい３つのこと｜こがねん / 組織開発するマン
こんにちは。こがねんです。ファッションテック企業で「組織開発」をしています。 「組織開発」とは何でしょう。これにはいろいろな定義がありますが、僕は「人の集まりが同じ目的に向かって協働するチームになるためのあれやこれやの働きかけ」くらいに考えています。 会社全体・特定部門・特定チーム・特定個人と、人・組織の課題はあらゆるレベルで起こります。その課題発見や解決を自分や自分のチームがリードして行ったり、他の人が行うのをサポートしたりする仕事。それが「組織開発」です。 そんな仕事をしている関係で、現場マネジャーからもよく人・組織に関する相談を受けます。先日も現場のマネジャーからこんな相談を受けました。 「チームの一体感が低下していて困っています。別に仲が悪いわけではないですが、リモートワークになった頃からメンバー同士の関わり合いが減ったこともあり、横のつながりが薄くなってしまったように思います。業
【フロントエンド】プロジェクト初期に手を抜かないで - Qiita
はじめに みなさんは新規サービスを立ち上げたことがありますか？ 技術選定から環境構築、諸々の初期設定。大変なことが多いですよね。 僕はこの4年で、新規サービスを3つ、新規の管理画面系を1つ立ち上げたのですが、このプロジェクトの初動で毎回のように後悔をしてます。 特に、フロントエンド領域というのはJavaScriptという自由な言語の特色を色濃く反映しているのか、非常に自由度が高く、どのようにも書けてしまいます。 そんな僕からのアドバイス。 プロジェクトの初期は最大限頑張ること。 最低限ではなく、最大限を心がけるといいと思います。 今回は、理由とともにどんなことを気をつければいいのかという話ができればと思います。 新規サービスの環境構築は最大限頑張った方がいい理由 1. 人は増える。あなたと他の人を一緒にしてはいけない。 環境構築をするのは1人でも必ずあなたではない誰かがプロジェクトにアサイ
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
プロジェクトに浅瀬を作る
はじめに プロジェクトに参加しているメンバーがうまく環境に適用できずに離脱することがあり、ともすれば、身体を壊してしまうケースもあります。これは新規メンバーに限定されず、既存のメンバーでも、プロジェクトや本人の状況、その役割が変われば発生し得ると思っています。 そういったことを回避できた状態を想像した時にプロジェクトに浅瀬があったら良いのではというイメージからこの言葉が浮かんだのだと思います。2年ほど前のメモ書きにこのタイトルが残されていて、今見直した時にすごくしっくり来ました。 メモ書きを発見したツイート この「プロジェクトに浅瀬を作る」とは、どういうことなのか、改めて深堀したいと思います。 どういうこと？ 溺れないようにするのが目的 監視員が必要のない状態が理想 溺れないようにするのが目的 溺れるというのは、闇雲に時間がかかってしまい心身ともに疲弊してしまうイメージです。不慣れなため必
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
ウクライナ発個人プロジェクトGitLabが1兆円規模のIPOへ、その4つの教訓 | Coral Capital
月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ ウクライナのソフトウェア開発者Dmitry Zaporozhets氏が2011年10月に、たった1人で開始したオープンソースプロジェクト「GitLab」。それが、ちょうど10年を経て時価総額1兆円もうかがうほどの大成功したDevOpsのSaaSプラットフォームへと進化することになると想像した人は、ほとんどいなかったと思います。GitLabのライセンス・SaaSビジネスを展開するGitLab Inc.は9月17日付けで米国証券取引委員会（SEC）に対してFORM S-1を提出し、IPOへ向けて最終段階に入りました。 開発初期か
炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上
いい加減、プロダクトマネージャーという職業に幻想を抱くのはやめよう。
この記事に関連する話題: プロダクト開発者に求められる、これからの「倫理」の話をしよう。 プロダクトマネージャー (PM) としてのこれまでの私的な経験を踏まえて、『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』を読んで思ったことをつらつらと。 （8/12 追記）冒頭で示しているように、本記事ではPM＝プロダクトマネージャーとして表記しています。後述の通りPMとプロジェクトマネージャーは異なるものであり、後者に対して略記は用いていません。 プロダクトマネージャーは本当に“魅力的な職業”か “完璧な世界”など存在しない 良かった点 「PMはミニCEOである」という言説や「PMとプロジェクトマネージャーの違いは？」というよくある質問に対する補足 「プロダクトの成功」を定義するところから始めることの重要性 PMの武器は信頼、情熱、共感、
プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から
「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画（いわゆる「予算」）、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ
ワクチン予約のシステム、納期ありきのクソプロジェクトあるあるすぎ
https://anond.hatelabo.jp/20210517201151 あれさ、少なくとも東京会場側のサイトは、最初のボタンに「認証」って書いてあんだよね。 端的に言って、認証も何もしてないんだから嘘なんだよね。 んで、取れる手立てはいくつもあると思うんだけどさ、 ドメインについて（なんでmrso.jpのドメインなのよ、厚労省のドメインじゃだめなんか）市区町村コードについて（６桁だけど、これは既知の情報で無効な番号は弾ける）誕生日について（なんで1歳でも予約できんだよ、これは後述するが弾いてるものもある）一番下のコピーライトについて（自衛隊東京 予約システムというタイトルなら、一番下にも入れとけよ）最初に書いとくと、できるチェックはしてるんだよ。 例えば、「現在の入力桁数：4桁」みたいなチェックはしてんだよ。これはわかりやすい。頑張ってる。 んでな、2月31日みたいな存在しない日
趣味プロジェクトをリードする技術 / Technology to lead hobby projects
CAMPHOR- DAY 2021で発表したスライドです。 https://camphor.connpass.com/event/206786/ 概要 趣味プロジェクトを完走するのは一筋縄では行きません。 長期休暇などのライフスタイルの変化やチームメンバー間の認識の齟齬といった様々な要因でモチベーションが削られてしまい、いつの間にか幽霊プロジェクトと化してしまった経験を持つ方は多いのではないでしょうか？ このセッションでは、「新規Webサービスのリリース」という仮想のプロジェクトに沿って、趣味プロジェクトを完走させるためのテクニックを紹介します。 テクニカルスキルというよりマネジメントスキル寄りの話になりますが、個人開発・チーム開発のどちらでも有効なテクニックなので、様々な場面で応用していただければ幸いです。 Twitter: https://twitter.com/p1ass GitHu
8社のイチオシ「Notion活用術」を大公開！採用、ナレッジ共有、プロジェクト管理まで | SELECK [セレック]
大流行中のオールインワンツール「Notion」をご存知でしょうか？ SELECKでも昨年末に、基礎編・応用編・発展編にわけて「Notionの使い方」をご紹介させていただきましたが、大きな反響がありました。 一方で、少し使ってはみたものの、その万能さゆえにまだまだ使いこなせていない…という方々も多くいらっしゃるのではないかなと思います。 そこで今回は、Notionを使いこなしている8社の事例をお届けさせていただきます！ どの企業も、アイデアと運用の工夫がすごく参考になります。自社にも役立つ活用法がきっと見つかると思いますので、ぜひご覧ください。 ＜今回ご紹介する8社の事例＞ 独自ドメインを設定！コーポレートサイトを自作 / Appify Technologies ワークスペースの「ポータル化」で必要な情報にアクセス / GMOペパボ テンプレを使った議事録作成の効率化から、振り返りまで /
![8社のイチオシ「Notion活用術」を大公開！採用、ナレッジ共有、プロジェクト管理まで | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8c79686691a9f1253de805fc73550cfbe33b1186/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2021%2F02%2F03164710%2FFrame-27.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バグを許さない、完璧なリリースじゃないと許さない風潮をやめないと日本はこれから厳しいのでは「ほんまこれ」「バグるものによる」
モノリスからマイクロサービスへのマイグレーションで学んだ７つの教訓
