〜ベテランPMと学ぶ、炎上しないプロジェクトの作り方〜 対話形式で学ぶ要件定義の入門書です。 よくある要件定義の書籍だと分量が多くなりがちなので、 すぐ読めて、分かりやすくて、とっかかりやすい内容を目指しました。
【3行要約】 ・優れたマネジメントには「部下を知る」という基本姿勢が不可欠ですが、多くのマネージャーはこの点を見落としがちです。 ・田中氏によれば、理想的なマネージャーは部下について30秒から1分の「エレベーターピッチ」で説明できる状態であるべきだと指摘します。 ・マネージャーは「見る」「指示する」「関わりを持つ」という3つの行動を実践し、メンバーの特性や業務の性質に応じた適切な関わり方を選択することが重要です。 本記事では、特に反響が多くあった同イベントの2記事目を再掲します。 同じシリーズの記事はこちら 理想のマネージャーは、メンバーについて「エレベーターピッチ」で説明できる人田中直道氏(以下、田中):では次のセッションに移ります。ここからは、リスペクトを持った上で、メンバーに対して具体的にどのような行動を取るべきかについてお話しします。本日お伝えするのは、以下の3つの行動です。 「見
日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はPМ、ある時はPМОとして、お客様と問題解決に取り組んでいます。本記事では、まだPМBОKには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います マガジン:https://note.com/think_think_ab/m/m0e070db46016 アジャイル採用の背景前回第43回では、 プロジェクトマネジメントを機能させれば対応できる スコープクリーピング や 技術的な実現性 等の内部の変化要素に対して、 なぜ、 それらの対応を諦めて、アジャイルを志向してしまうのか。 というところまで考察いたしました。 ではなぜ、 スコープの決定 や 実現性確認 を諦めてしまうのでしょうか。 要件を決めきることや 採用技術の実現性確認をあきらめることは、 すなわち QCDバラ
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね?」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発
目標設定の仕方を変えるだけで社員の意欲が沸き、会社の雰囲気も変わります。会社の明暗は目標設定で決まるといっても過言ではありません。目標設定を成功させるには、その掲げた目標は誰が見ても明確であることが重要です。 私は明確に表現するために不可欠な「5つの要素」の頭文字をとった「SMART」から、「SMARTゴール」という目標設定方法の重要性を提唱しています。 目標設定に役立つフレームワーク、「SMART」とは「SMART」とは下記の全ての要素を含んだ目標設定の指標です。 ◆要素1:Specific(具体的に)誰が読んでもわかる、明確で具体的な表現や言葉で書き表す ◆要素2:Measurable(測定可能な)目標の達成度合いが本人にも上司にも判断できるよう、その内容を定量化して表す ◆要素3:Achievable(達成可能な)希望や願望ではなく、その目標が達成可能な現実的内容かどうかを確認する
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」=「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
ITプロジェクトにおける原価管理【プロジェクト原価管理とは?第1章】 公開日 2017.04.28 更新日 2025.04.11 株式会社システムインテグレータ プロジェクト管理のための知識体系としてのPMBOK(Project Management Body of Knowledge)には、プロジェクト遂行上、管理すべき9つの知識エリア(統合、スコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達)がまとめられています。 本連載では、その中でも重要性の高い、原価(コスト)管理に関して、会計的な視点も踏まえた上でPMBOK準拠であるOBPMを利用しての実運用を含めて説明をしていきます。 原価管理の目的 企業が経済活動を行う上で管理すべき要素の筆頭として「売上」「原価」「利益」が挙げられますが、その3要素の間には、 売上-原価=利益 という式が成り立ちます。この式の重要性
Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる
デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです(Slideshareはこちら)。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入&運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ~チケット管理システム大決戦 第二弾~で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
メディア 記事一覧 オルタナティブ・ブログ 用語辞典 ITmedia エンタープライズ 5分で絶対に分かるプロジェクト管理:5分で絶対に分かる(2/6 ページ) » 2008年09月17日 12時00分 公開 [今田忠博,@IT] 前のページへ 1|2|3|4|5|6 次のページへ 前のページへ 1|2|3|4|5|6 次のページへ Copyright © ITmedia, Inc. All Rights Reserved. SpecialPR 検索 メールマガジンのお知らせ 企業を変革するビジネス視点のメールマガジンを毎朝配信中!! 「それは俺じゃない」社長の一言が効く? セキュリティのプロが語った、巧妙化する詐欺を止めるヒント[セキュリティ]AIの影響を受けにくい「3割の人々」の共通点[注目ニュース] アイティメディアからのお知らせ キャリア採用の応募を受け付けています 注目のテーマ
コンプライアンス1を重視する現場で、 アジャイルなプロジェクト管理ツールが現場で必要になったときに、 外部WebサービスなTrelloやPivotal Trackerを導入しづらいことがある。 そこで、OSSのかんばん式管理ツールをいくつか探して、 色々試して感じたことをまとめておきます。 今回試した ‘かんばん式’ プロジェクト管理ツール 以下に挙げる以外にも、OSSのかんばん式管理ツールは数多く存在するが、 機能面・とっつきやすさ・導入の容易さなどに基いて、3つだけピックアップさせていただいた。 TAIGA https://taiga.io/ Wekan (旧LibreBoard) http://newui.libreboard.com Restyaboard http://restya.com/board/ 個別のサーバーに実行環境を構築したい場合 各々デモ用のURLが用意されている
概要 お願いした作業の進捗を聞くときには「進捗どうですか?」より「困ってますか?」と聞くほうが何倍も捗るよ、というお話。 タイトルの2015倍は冗談です。念のため。 「進捗どうですか?」はダメです あけましておめでとうございます。ところで皆さん進捗どうですか? ・・・いやー、流行りましたね。 この「進捗どうですか?」はtwitter上で使うと「最近どうよ、忙しいの?」程度の挨拶で面白みがあるのですが、実際に仕事で使うとなんのいいこともないと思うのです。 質問攻め いいことがないと思う理由は、「進捗どうですか?」は質問攻めになりやすいと思うからです。「進捗どうですか?」の先に待っているやりとりはだいたいこんな感じです。 こんな感じでリーダー主体の質問攻めになってる場面をよく見ます。もちろん、ほとんどのリーダーとしては現状を良くしようと純粋に質問しているだけだと思います。でもこれを詰問と感じて
こんにちは、ぎぎねっとさんとTetuさんと共に『コミュアゲ』というゲームを作っておりますハワイ長万部です。 さてさて、チーム開発と言えばオンラインレポジトリやタスク管理、円滑なコミュニケーションのとれるチャットツールが不可欠ですね。 『コミュアゲ』ではそれぞれ、GitHubと時々Dropbox(非エンジニア向け)、Trelloと時々GitHub Issue、Slackを活用しています。 さて、その中で今回取り上げるのは Trello 。( https://trello.com/ ) 『コミュアゲ』は自分にとって久々のゲーム開発ということもあって、 「 Slack の使い勝手を試してみたい」 「タスク管理ツールの Trello ってやつを試してみたい」という希望がありました。 Slack は順番前後して、結局 Kawaz全体での Hipchat からの移行が先になりましたが、 Trelloに
Supports PHP 7.4Freedom to run on almost any server!
「課題管理」「成果物管理」と並んで、プロジェクトマネジメントに欠かせない機能が「スケジュール管理」です。 スケジュール管理を分解すると、「スケジュールを立てる」ことと、「立てたスケジュール通りに進むよう管理する」ことの2つに分かれます。 2つ目の「立てたスケジュール通りに進むよう管理する」ことを、「進捗管理」と呼ぶこともあります。 「進捗どうですか?」の進捗って何? 「進捗」を辞書で調べると、このように書いてあります。 [名](スル)物事がはかどること。「工事の―状況」「仕事が―する」 (出典:デジタル大辞泉) 「進捗どうですか?」と聞かれたら、それは「どれくらいはかどってますか? どれくらい進んでますか?」という意味です。 また、「進捗管理」を辞書で調べると、このように書いてあります。 業務の進捗状況を管理すること。たとえば、システム開発の進捗管理の場合、設計、プログラミングなどの作業工
分散バージョン管理システムつかってますか? 世の中ではgitやhgなどの分散型のバージョン管理システムが流行していて、「もうsvnなんて、、、」「まだsvnつかっているの、、、」という風潮になっています。 弊社内でもgitのレポジトリが立ったり、svnのプロジェクトでも自分の環境だけはgit-svnで分散バージョン管理を使う人が増えています。 「自分の環境だけはgit-svnで」。そう、社内ではまだまだsvnを使っているプロジェクトが多いのです。「日本語のファイル名が使えない」「デザイナーさんに使ってもらうためのわかりやすいクライアントが無い」「svnからなかなか移行するコストが、、」などの理由でsvnを使い続けているプロジェクトも多いと思います。 というわけで、分散バーション管理システムではなく社内で運用されているsvnでのブランチマネジメントについて、備忘録もかねて説明します。 前提
はじめに ついにELBがアクセスログを出力できるようになりました!(Elastic Load Balancing Announces Access Logs) ということでやってみました! 設定 [Load Balancers]画面を開き、設定したいELBを選択します。画面下部の[Description]タブの一番下に[Access Logs]という項目があります! なおこの項目は新しいManagement Consoleでしか表示されません。以前のManagement Consoleを使用されている場合は、画面右上に青い吹き出しのようなアイコンが表示されていますので、クリックし「Try the new design」の[Click here]リンクをクリックすると、新しいデザインのManagement Consoleに切り替わります。 さて、[Access Logs]の[Edit]リンク
KAIZEN platform Inc. 技術顧問 伊藤直也さんの、プロダクトマネージャーに関するツイートがとても示唆に富んでいるのでまとめさせていただく。 ソフトウェアエンジニアのひとがなにかと口うるさいの、組織的な怠慢のツケをはらう羽目になるのがだいたい自分たちだから、というのはあるだろうね。ごまかしがきかない仕事だし — Naoya Ito (@naoya_ito) 2015, 10月 21 良く見る典型例は、企画とか品質を保証する仕事までエンジニアに丸投げして、エンジニア側にはその期待値がなくてお互いの思惑がずれる、みたいなケースだな。この場合にエンジニアがしょぼいものを作るから、と指を指されてるけど、問題は製品企画開発の責務を組織の中で曖昧にしてるところにある — Naoya Ito (@naoya_ito) 2015, 10月 21 たまたまエンジニアの中にそこまで含めて上手な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く