プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

ガイドの視点 今回のテーマはコミュニケーションについて。仕事をスムーズに進めるにはコミュニケーションは欠かせない。これは、至極当たり前のことだ。クライアントやチームメンバーとのコミュニケーションが不足しているようでは、うまくプロジェクトが進行するわけがない。 とはいえ、自分のコミュニケーション能力不足のせいで、プロジェクトの進行が思わしくないと認めたくはないし、そのことに気づくのも困難だ。では、コミュニケーション下手なプロジェクトマネージャーが直面する問題とは何だろう。筆者は5つのポイントを挙げている。自分のプロジェクトが抱える問題と比較してみよう。 各関係者の期待のズレ 予想外の変更 誰にもわからないプロジェクトの進捗状況 ぎりぎりになってからの告知 自分が何をすべきか分かっていないチームメンバー 自分の頭の中にある納品物とクライアントの思っている納品物のイメージが一致していない。予想外

WebSig勉強会「Webサイト構築のためのプロジェクトマネジメントスキル」感想：PMにおける「承認プロセス」と「全社視点」など Posted on 2007年9月20日. Filed under: WebSig24/7 | タグ: Project Management, WebSig24/7 | 先週末の3連休の初日、9/15日(土)はWebSig会議第15回「Webサイト構築のためのプロジェクトマネジメントスキル」でした。 第15回 WebSig会議「Webサイト構築のためのプロジェクトマネジメントスキル」を開催 (WebSig24/7) http://websig247.jp/press/000059.html 講演者は「このテーマなら」と最初から決まっていたビジネスアーキテクツの森田雄さん、そして野村総研グループのNRIネットワークコミュニケーションズで多くの部下を率いている松岡清

著者プロフィール 本田 佳武人 大手外資系企業にてプロジェクトマネージャとして活躍中。製造、金融、物流等、数多くの大規模システム開発プロジェクトの経験を持つ。 ここでは、プロジェクトマネージャを志望している人たち向けに、プロジェクトマネージャとはどんな仕事で、どのようなスキルを要求され、今後どのようにキャリアを積んでいけば一人前のプロジェクトマネージャになれるのか、について説明して行きます。本章では、プロジェクトマネージャの仕事について説明します。 第1回　プロジェクトとＰＭの役割 #プロジェクトマネージャー プロジェクトとは プロジェクトとは、ある期間内に、何か新しいもの、この世に存在しない何かを造り出すことを目的として実施される一連の活動のことです。造り出すもの、つまり成果物は「新しい建造物」、「新しい製品の試作」、「ITを利用した新しいシステム」などで今まで存在しなかった何か新しいも

プロジェクトマネジメントは、生まれつきの才能が求められるアートなのだろうか、それとも学ぶことができる科学なのだろうか。その両方である、というのが真実だ。 プロジェクトマネジメントのアート的側面には、リーダーシップ、人材育成、動機付け、コミュニケーションなどが含まれる。アートの才能を持ったプロジェクトマネジャーは、優先すべき業務が変化したときにチームをうまく導き、問題が生じたときにそれを巧みに解決し、いつ誰にどんな情報を伝えるべきかを正しく判断することができる。 プロジェクトマネジメントの科学的側面には、業務の計画、見積もり、測定、管理などが含まれる。さらに「いつ、誰が、何をするのか」という問題も含まれ、ツールとテクニックを用いて管理する堅実なスケジュールと予算が要求される。その最終的な目標は、以下のようなプロジェクトに関するスポンサーの4大疑問に答えることである。 プロジェクトはどこまで完

皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。 甘い計画でプロジェクトをスタートすると 日本の社会は「委託者の地位が異常に高い」という特徴を持っている。委託者は納期はしっかり押し付けるにもかかわらず、要件定義ではなかなか結論を出さなかったりする（出したがらない）。このつけは、プロジェクトマネージャに回される。人のよいプロジェクトマネージャは、これを何とかしようとして、最初から無理な計画を立ててしまうことになる。これが失敗プロジェクトへの道の第一歩である。 プロジェクトにリスクは付きものである。従って、このリスク

プロジェクトの開始から完了までに必要な作業をすべて洗い出し，それらを順序付けたものがマスター・スケジュール。どの作業が最もクリティカルで，どの作業が枝葉か。これが明確になったマスター・スケジュールが作成できれば，プロジェクトは成功に近づいたといっても過言ではない。 布川　薫／日本IBM 前回説明した工数見積もりとリスク査定が終わると，いよいよプロジェクトのマスター・スケジュールの作成に入る。 マスター・スケジュールとは，プロジェクトの開始から完了までを見通した「基本計画」のことだ。以降に作成するすべての作業スケジュールの基準となるだけに，プロジェクトのリスクや要員のスキルなどを加味して，十分に実行可能なものにする必要がある。プロジェクトに必要な作業を見通せるのはプロジェクト・マネジャーだけなので，マスター・スケジュールは必ずプロジェクト・マネジャー自身の手で作成しなければならない。 スケジ

最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開

こんにちは、livedoor Blog を担当しています佐々木です。 「livedoor Blog」プロジェクトの定例会議は、検討する議題が山積みで関係者も多く、いつも20名を超すスタッフが集まります。ですが、長時間の会議はデメリットしか生みませんので、“会議は週に1回1時間だけ”と制限を決めて、そのなかで効率的な会議の方法を試行錯誤しています。 そこで今回は、「アジェンダの作成方法」に焦点をあて、“ライブドア流”会議術の一端をご紹介したいと思います。 【01】アジェンダは前日のうちに関係者にメールする 会議で使用するアジェンダは、前日のうちに関係者にメールして目を通してもらい、補足がある場合には事前に受け付けます。 そうすることで、参加者が予習をするようになり、会議での話がスムースになります。また、アジェンダの内容によって「今回は欠席する」という判断がしやすくなるのもメリットで、参加して