私は自慢では無いですがプロジェクトを炎上させたことがありません。 （炎上案件に途中から突っ込まれたことはありますが） 炎上案件の経験や上司からのアドバイス、書籍からの学びによるものが大きいです。 ただ、しっかり言語化して自分のものにしたいと思い、整理しようと考えました。 これを他のPLやメンバーに共有することで炎上プロジェクトが減っていくことを期待したい。 プロジェクトマネジメントする上で、意識していること、大事にしていること 小さな火を消し続ける → 課題管理の徹底、朝会でメンバーと課題を共有し、期日と優先順位を決めて通常タスクより優先して取り組む。 やらないことを決める → 顧客が求めてないこと、成果物に直結しない作業を極力やらない。（とくに過剰な品質管理、プロジェクト管理資料の作成など） 受注前の見積もりの段階で、案件リスクを見極めて、リスクを下げるか受注しない対応をとる → 見積も
What is Pomofocus? Pomofocus is a customizable pomodoro timer that works on desktop & mobile browser. The aim of this app is to help you focus on any task you are working on, such as study, writing, or coding. This app is inspired by Pomodoro Technique which is a time management method developed by Francesco Cirillo. What is Pomodoro Technique? The Pomodoro Technique is created by Francesco Cirill
最初に プロジェクト管理ツール うまく使いこなせてますか？ システムの保守・維持管理業務でプレーイングマネージャをやっている皆さんこんにちは。 システムの保守・維持管理のプロジェクト管理用にRedmineやJira等のプロジェクト管理ツールを導入し、 ITILとかPMBOKを参考しながら運用ルールを作って、チケットを使ってタスクや課題、工数の管理をやり始めてみたけど、 なんかうまくいかないみたいな経験ありませんか。 例えば ・Excelやメモ帳での管理を脱却してredmine、Jiraに移行してみたけど、結局Excelの方が楽で管理もうまくいってた ・チケットは作成しているけど、忙しくて中身を確認しきれず、結果 長期間放置されている謎の塩漬けチケットが大量 ・チケットの種類の決め方、項目の書き方が人それぞれ入力内容や形式がバラバラで、結果どこに何が書いてあるのかわからない。 などなど・・・
おすすめの工数見積もり方法についてのお話です。 （前置き）ストーリーポイントと相対見積もりについて 本題の前に相対見積もりとストーリーポイントについて少し触れましょう。 私は人日／人月などの絶対見積もりは使わず、相対見積もりによってストーリーポイントをつけています。 ストーリーポイントは、ユーザーストーリーやフィーチャーの規模感を表す単位です。 そして、基準となるユーザーストーリーのストーリーポイントに対して、どれくらい大きい／小さいかを見積もるのが相対見積もりです。 本エントリの見積もり単位もストーリーポイントを使用して説明します。 2点見積もりとは 「最小工数」と「最大工数」の2つを算出して見積もる方法のことです。 見積もるプロジェクト規模が大きい、あるいは不確定要素があるという時に効果を発揮するでしょう。 hirokidaichi さんの記事に、2点見積もりのことがさらに詳しくまとま
もうかなり前の話だ。 ある会社で、「会社案内・パンフレットのリニューアルをする」と言うプロジェクトが持ち上がった。 社長は一人の人物をプロジェクトマネジャーとして任命し、予算を付け、 「後はよろしく」 と、仕事をまかせた。 ところが半年後、ようやく社長は気づいた。 全くプロジェクトが進んでいないことに。 「どうなっているのか」とプロジェクトマネジャーを問い詰めたところ、彼は外注に丸投げしたまま、何もしていなかった。 外注側も、仕様が固まらず、プロジェクトは完全にスタックしていた。 社長は彼に話を聞いたが、彼は「外注から返事が無くて」の一点張り。そこで、社長は彼に要求した。「資料を出せ」と。 ところが彼は「出せない」という。 何か隠しているのではないか、おかしいのでは、ということで、皆でメールのやり取りや資料などを調べると、実質、彼が事実上、「外注に依頼をし、あとは本当に何もしていない」こと
はじめに こんにちは！ 先日、社内の個人カリキュラムでWebアプリケーションを一人で作るという課題がありました。 以前、アプリケーションを作る過程で期限を守りながら開発をする上で大切だと個人的に感じたことをこちらの記事で書かせていただきました。 その中で、大切なことの一つに極力精度の高いスケジュールを作るということをあげました。 今回は僕が社内の個人カリキュラム中に実践していたスケジュールを作成・管理する際の方法について紹介したいと思います。 スケジュール作成・管理に悩む方へ少しでも参考になれば嬉しいです。 記事の流れ なぜスケジュールを作る必要があるのか プロセスを具体化する 見積もり時間を決める 重い順に並び替える スケジュールに落とし込む 進捗管理する 順番に行きます。 なぜスケジュールを作る必要があるのか それは開発前にどんなリソースを投入するか、プロセスで実施するかを検討したり、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前提 主にプロジェクトを始める前に意識/確認しておきたいことが参考になったため、それらを中心にまとめている 今後意識していきたいこと 部分最適の集合体は全体最適にはならない 各部門の努力の投資対効果を最大化するためには全社最適を考える チームと組織の目標を合わせる やりたいことがあるからプロジェクトを発足させるのでなく、中長期で考えて全体で必要と判断したものをプロジェクトとする マトリックス組織(専任でなく兼務でやる場合)の場合、そのメンバーの占有率をの計画段階から決める プロジェクト開始の段階で以下やっておく フェーズ分け ステークホ
部下に仕事を指示をするとき、個々の具体的な作業をお願いしてませんか？ そんな指示の仕方をしていては、時間がいくらあっても足りません。 個々の作業よりひとつレイヤーを上げて「どの作業をすべきか」を考えるところから、任せてしまいましょう。 仕事をまるごとお願いしないと、部下は成長しない 丸投げとは、目標と納期だけ与えて「後は自分で考えて業務を遂行してください」ということです。 「仕事」と「作業」はまったく異なります。個々の作業ではなく、その一つ上のレイヤーの仕事も任せてしまいましょう。 個々の作業をお願いしてしまうと、上手くいかない時は、その都度「どうすればよいでしょう」と対応しないといけません。自分でやったほうが速い状況になってしまいます。 一つレイヤーを上げてお願いしておけば、細かい判断も任せることができます。 仕事はまるごとお願いしないと、部下は育ちません。責任も合わせて委譲することで、
リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする
CTO室 相談室でCARTAの各部署の技術メンター・コーチをしている前田@brtriver です。 自分の仕事内容を説明するのが難しいですが、スタッフエンジニアでいう右腕です！ いろんな部署のサポートをしていると開発要望タスクのリストを確認する場面がよくあります。 そして、その中の「優先度」という項目で正しく優先度をつけることができていない現場が多いと感じます。 そこで、今回はどのように「優先度」を考えればよいかについて私自身が意識していることをまとめてみるので、ぜひ一緒に考えてみましょう。 優先度が「高」だらけになってしまう チケット管理において優先度が「高」だらけになってしまう現象を目にしたことはありませんか？ チケットは困ってる本人が書くため、基本とその優先度は「高」が多くなります。 チケットに残すために書いたとしても、優先度低いタスクはそもそもやらないという判断されることが多く、そ
ビジネスにおいて「解像度が足りない」という言葉が使われるようになりました。この解像度という概念を、深さ、広さ、構造、時間の4つの軸で整理して、それぞれでどうやって解像度を上げれば良いのかについて解説しています。 このスライドを使った
著：ケネス・ブランチャード、ウィリアム・オンケン・ジュニア、ハル・バローズ たくさん働いているのに仕事が終わらない！！ その理由がわかります。 本のまとめや概要、感想・評価・レビューをしていきます。 あらすじ上司は時間に追われて、部下は時間をもて余す……これってどうして!? 現場では優秀だった社員が昇進して管理職となったとき、陥りやすい状況がある。 「働いても働いても仕事がなくならない」「がんばっているのに成果が上がらない」などがそれだ。 自分がプレーヤーだったころは良かった、もしかしたら自分は管理職に向いていないのだろうか、管理職は思ったよりラクじゃない、とお悩みのマネジャーも多いことだろう。 だが、実はそれはあなたがやるべきでない仕事をしているせいだとしたらどうだろう。 概して、プレーヤーとして優秀な人ほど、部下に仕事を任せられずすべてを自分で処理しようとしてしまうものなのだ。 管理職
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
10案件を同時進行するディレクターが編み出したタスク管理術【完全保存版】｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG こんにちは、株式会社GIGのLeadGrid事業部でディレクターとして働く水嶋です。 複数のプロジェクトに関わる仕事をしている方なら、誰しも「タスクが多すぎて、タスク管理がうまくいかない」や「緊急のタスクに追われて、今日やらなければいけなかった仕事が終わってない！」と悩まれたことがあるのではないでしょうか。 タスク管理や優先順位づけの正しい方法を理解すれば、その悩みの解決に一歩近づきます。 本記事では、常時10〜13案件のプロジェクトマネジメントをしている筆者が、どのようにタスク管理・優先順位をつけて、日々の業務に取り組んでいるかを解説します。まずは、筆者がどのように日々のタスクを管理しているかを説明したうえで、どのような思考で対応しているのかを解説できれば
プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。 1. プロジェクト概要1-1. 背景プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。 1-2. ゴールゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。 1-3. 目的プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5
第三世代が特徴的で、１分単位でスケジュールを管理し、時間に沿って行動をする「電極家」のような存在です。このスケジュールは最初の２日程度であればなんとかこなせる人もいると思いますが、「スケジュールに動かされている」だけであり、「主体的」ではなくなっている可能性があります。 そんな管理方法をしている中で、「自分の人生ってなんだっけ」と問い直すことになり第二世代や第一世代に戻ってしまう、という選択に戻ってしまうのです。だからこそ、第四世代をベースに時間管理を行い、「自分がやりたいことをやる」ために管理していくことが重要なのだと分かります。 Atomic Scrum 株式会社ゆめみの社長である片岡さんが公開している自己管理の資料です（ここでは自己定義も含めて自己実現と言われています） 根本的な考え方は同じであり、自分自身もこの資料がスタートで色々模索し始めた背景もあるので、参考として見ていただける
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
「仕事で成果を出す人」と聞いて、どのような特徴を思いうかべますか。 才流はコンサルティング会社であり、ビジョンとして「メソッドカンパニー」を掲げています。顧客へ価値を届けるにあたって、営業やマーケティング、新規事業などの専門知識はもちろん、ベースとして強固な「仕事力」が欠かせないと考えています。 本記事では、社内で実際に活用している仕事の進め方マニュアルの中身をテーマ別に厳選し、チェックリスト形式で紹介します。 ※本記事が多くの方々に読まれていることもあり、このたび内容を最新版にアップデートしました。 ビジネスパーソンの心得1. ビジネスの原理原則を理解するビジネスで価値を提供するためには原理原則が存在するビジネスの原理原則とは、相手＞自分であり、顧客＞外部パートナー＞自分であること具体的に表すと「顧客や社会、チームメンバーに価値を提供する→顧客や社会からお金がもらえる→自分たちの給与が出
Qiitaに一度書いた内容ですがアカウント削除とともに消えた内容です。 Redmine絡みのイベントで書いた記事だったはず。 手元のメモから出てきたのでこちらに記載。 背景 メンバーの一部がスムーズに情報共有できるチケットが書けず苦戦しており、 相談を受けた時に色々言った内容を書き起こしたもの。 チケットというより、情報共有のための文章の書き方が正しいかも。 前提 業務ツールとしてチャット、Redmine、Wikiを使用していた。 チーム内の連絡や相談はチャットがメイン。 チャットで会話して相談・整理・調整する。 タスク、課題はチケット化して管理。 ナレッジはWikiに書いて共有。 業務内容はシステム開発と運用保守でソフトウェア開発ではない。 Redmineをタスク・課題管理に使用している環境で 以下のような考えを元に各ツールを使用し業務を行っていた。 ・チャットは流れる情報（フロー情報）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
