個人的なメモ。 EA(Erectric Arts)流のPM(Project Manager)の仕事の進め方(タスク管理のノウハウ)を岩崎啓眞氏が実に明快にツィートしていらっしゃったので、まとめました。 確かにこの方式で仕事を進めてくれるPMがいたら、純粋に仕事に集中できそうです。こんな環境欲しいなぁ…。
![EA流のPMのタスク管理の仕方](https://cdn-ak-scissors.b.st-hatena.com/image/square/f849dca8fdd0581519bb89cca02beb80b946f334/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F7f7cadefa4169dce5abde3926d719874-1200x630.png)
NavalPlanはエンタープライズクラスに向いたのJava製のプロジェクト管理システム。 NavalPlanはJava製/Webベースのオープンソース・ソフトウェア。企業規模によってプロジェクト管理に求めるものは変わってくる。小規模な組織であれば個人の裁量が大きく、コミュニケーションも活発なのでWeb上でまとめる情報はそれほど多くなくても良いかも知れない。 ガントチャート しかし何百人とプロジェクトに関わる人が増えてくるとそうも言っていられない。適切に管理を進めなければいざという時に大変なことになってしまう。そこで使えるのは大規模プロジェクト向けのNavalPlanだ。 NavalPlanはガントチャートが基本になるプロジェクト管理だ。WebベースなのでWebブラウザさえあれば誰でも見られるのが利点だ。一つのプロジェクトだけでなく、複数のプロジェクトを全体的に見ることができる。各人員のリ
短期連載(要求仕様のボトルネックを探る)では、ITプロジェクトにおける“要求”というものにフォーカスし、高品質な要求開発と、その要求を管理することについてお話ししました。今回の連載では、構成管理(SCM:Software Configuration Management)について見ていきたいと思います。 読者の中には、構成管理といわれると「ソースコードのバージョン管理のことでしょ」ということで、主にライブラリアンと開発者が気にするものという認識の方も多くいらっしゃるのではないかと思いますが、本当にそうでしょうか? 数人のチームで、1カ月程度で作り上げるようなシステムや、オープンソースではうまくいっても、ある程度の規模の受託開発や、製品開発ではそれだけではうまくいかないことが多いのです。そこで今回は、まずは構成管理の概要をつかんでいただきたいと思います。 プロジェクトの現場で見られる問題点
「小学1年生」と銘打っているのは、うちの娘が小1になったからなんです。 最近の小学校は、8月末までの夏休みではないそうで、中途半端に8月20日頃(正確な日付は忘れました)から2学期が始まります。 まぁ、それはさておき。 夏休みの宿題を8月末まで引っ張らないためには、【計画を立てて】そして【計画通り】に実行する、というのが定番ですが、プロジェクトの考え方で言うと、全く駄目です。絶対に遅れがでます。なので計画通りに終わることはありません(計画に忠実な、妙に厳しいマネージャ=親がいれば別ですけど)。 そんな訳で、アジャイルに、と言いますか、TOC で、と言いますか、私が小学生の頃にやっていた方法を公開します。 # 基本的な方法は、今でも変わっていなかったりして。 以下が、今回の計画の手順。 1.夏休みの宿題が全体で、どれだけなのか確認する。 → 朝顔の観察が3枚 → 絵日記が2枚 → 夏休み帳が
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ~チケット管理システム大決戦 第二弾~で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
開発期間やリソースは限られているのに、やらなければならないことが増えてしまいがちな開発プロジェクト。しかし、少し考え方を変えると、効率化の大きな可能性が見えてくる。 「業務プロセスを完全に正しく分析して、そこからシステム機能要件を完全に正しく抽出し、完全に正しく定義する」。そうすれば「下流工程で追加や変更は起こらない」――開発プロジェクトに携わっている人なら、このような一文を読んだ瞬間に文句を言いたくなることだろう。できればとっくにやっていると。だがプロジェクト関連に限らず、書籍やインターネットに溢れているハウツーには、セオリーだけを述べて、実践に役立つ情報までは示してくれないケースが多い。その点、本書「プロジェクトを変える12の知恵」はそうした言いっ放しの作品とは異なり、冒頭の一文にこう続けるのだ。 「でもそんなのムリですよね? 確かに『完全に正しい要件定義』は理想形の一つだと思います。
要件定義工程はさまざまなことが決まっていない混沌とした状態にあります。このような状況の中で、洗練化などの繰り返し作業の方法と上位のステークホルダーの意向にあわせて軌道修正する進め方を説明します。そのポイントはマイルストーンごとにテーマを決め、そのテーマに基づく作業とレビューを行い、軌道修正しながら成果物を洗練化することです。 レビューを計画の中心におく レビュー駆動で進める プロジェクトオーナーなど上位のステークホルダーはプロジェクトに責任を負うので、プロジェクトに対する軌道修正や中止などの大きな権限をもちます。従って要件定義段階では上位のステークホルダーの意見を十分に配慮し、適切に要件を組み立てる必要があります。 そのために上位のステークホルダーが参加するレビューを計画の中心に据え、要件定義以降に大きな方針転換が起こらないように計画を組み立てます。 例えばレビューが月1回行われるようであ
7 Common Project Management Problems (And How to Solve Them) [ad#ad-2] 下記は各ポイントをピックアップしたものです。 曖昧な要件 プロジェクトがある程度進行しないと、クライアントがどうしたいかはっきりしない場合は、マイルストーンを設定するようにします。明確なステップを設定することで、プロジェクトの最初から最後までが綿密に計画されるようになります。 もし途中で大きい修正や変更が入る場合は、それに必要な工数をクライアントに明確にし、請求の必要があれば行うようにします。 コミュニケーションによる遅延 クライアントの返答待ちで、プロジェクトを進めることができないことがあります。これはちょっとしたことで、クライアントの返答を早くもらえるようにする戦略があります。 それは、「Yes」か「No」で返答できるように質問することです。これ
::mound::はTwitterライクな機能がついたプロジェクト管理システム。 [/s2If] ::mound::はPHP製のオープンソース・ソフトウェア。システム開発はとても面白いものだ。デジタルの世界においても、一からモノを作り形作っていくのは楽しい。それを生業としたときでも同じく、楽しさを維持しなければならない。 ステータス だが数あるプロジェクト管理システムはプロジェクトの遂行にのみ観点がおかれ、開発する楽しさが感じられる代物ではない。その意味で若干毛色が違うのではないかと思うプロジェクト管理ソフトウェアが::mound::だ。 ::mound::はプロジェクトごとのタスク管理、バグ管理をメインとしている。リリース計画を作り、その中にタスクを登録して漏れてしまったものについてはバックログとして管理されていく。そしてタイムトラッキング機能やワークフロー管理がある。 メッセージ そし
ProjectForgeはJava製/Webベースのオープンソース・ソフトウェア。プロジェクトに関するデータは一元管理されているのが理想だ。とは言え必要と無用の線引きは曖昧で難しい。開発者にとって無用でもバックオフィスでは重要というデータもあるだろう。 カレンダー そうしたことを考えず、全てのデータを登録してしまおうという考えもある。アポイント情報、タスク、ドキュメントなど全てだ。そうした様々なデータを見やすく一元管理してくれるのがProjectForgeになる。 ProjectForgeは左側にメニューが並んだプロジェクト管理だ。ガントチャート表示、タスク管理、タイムシート、カレンダー、予定表、アドレス帳、給与を含めた損益管理、メッセージ管理、ドキュメント管理など多数の機能が提供されている。 システム設定 何でもかんでも扱うことに対しては賛否がありそうだが、中途半端に扱うなら全て登録して
わたしがまだ新人プログラマだった頃、キックオフミーティングで渡された仕事の割り振り表のメンバーの欄に「X」と書かれていたことがありました。 「Xって誰ですか?」と尋ねると「そのうち現れるであろう誰か」という答えが返ってきました。要するにエンジニアを確保するつもりはあるんだけど見つかっていないということです。「ホントに現れるのか?」とわたしは疑っていましたが「X」は現れました。 ていうか、わたしでした。 リーダーから「X」と命名(?)された先輩とわたしは2人でその担当分を片づけることに(もちろん本来の担当分も片づけた)。 「結局見つからないんだったら、最初っからXなんて書かなければいいのに」とグチったら、一緒に担当分を増やされた先輩に「上の人間もぎりぎりまでがんばって探してたんだよ。いないものはいないんだから仕方ない。いる人間でがんばって片づけよう」と諭されました。 その後、さまざまなプロジ
プロジェクトを成功させるには、マネージャーやチームメンバー、利害関係者の間にしっかりとしたコミュニケーションが確立されていなければならない。そのためには、本記事で紹介している表現が本当に意味するところを押さえておくべきだろう。 コミュニケーション能力は、雇用者が従業員に求める資質として常に上位に挙げられている。しかし(筆者の経験によると)そういった資質はマネージャーに対してはそれほど厳しく要求されておらず、彼らの中には、一歩間違うと問題につながるようなスラングや、耳にのみ心地よい言葉を多用する者もいる。 相手の言葉を額面通りに受け取るのではなく、その言葉の本当の意味を理解する能力は重要である。以下では、プロジェクト管理の現場で使用される、分かりにくい表現を筆者自身の調査や経験に基づいて10個選び出し、解説する。 #1:余白を管理する(manage the white space) 「余白」
JSGanttはJavaScript製/Webベースのオープンソース・ソフトウェア。多人数、または複数社が関わるプロジェクトでは一つのタスクの結果が別なタスクに関わっていることが多々ある。そうした時の遅延はプロジェクト全体の調整が必要であり、滞りなく進めるのは至難の業だ。 JavaScriptでガントチャートを生成 そのためタスク間のスケジュールや関わり方を示すのにガントチャートがよく使われる。これまでのガントチャートは画像出力型が多く、生成後の再利用性が今ひとつだった。そんな不満を解消してくれるのがJSGanttだ。 JSGanttはその名の通りJavaScriptによるガントチャート生成ソフトウェアだ。縦にタスクが並び、横に日程が並ぶ。各タスクごとにスケジュールが帯になって表示され、その結果が別なタスクに線でつなげられる。タスクの関連性が見いだせるはずだ。 折りたたんだり表示範囲を変更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く