【補助線】今年はプロジェクトマネジメントの仕組みを撤廃します
本ブログは移転しました。こちらをご覧ください。 ◆今年はプロジェクトマネジメントの仕組みを撤廃します 年明け早々、ある中堅機械メーカのＨ社長からメールが届いた。人とおりの近況報告の後に、こう書かれていた。 ===== 今年はプロジェクトマネジメントの仕組みを撤廃することを決心しました。好川さんも、責任があるんだから手伝ってくださいよ。 ===== この企業は弊社のというより、好川の個人事務所（技術士）のクライアントで、８年くらい前に産業用機械の開発プロセスにプロジェクトマネジメントの仕組みを導入するお手伝いをした企業である。 年賀メールにこんなことを書いてきたのは、おそらく、半年くらい前に１冊の本を紹介したところに始まるのではないかと思う。その本とは、米国のコロンビア大学ビジネススクールの教授が技術ジャーナリストと一緒に書いた エリック・エイブラハムソン、デイヴィッド・フリードマン「だらし
Chirstmas メッセージ－－運命共同体として | タイム・コンサルタントの日誌から
私の勤務先は70-80%が海外向けの仕事だ。20年以上前に入社したときから、この比率はあまりかわっていない。ずっと、世界市場で直接の競争を生き延びてきた。しかし、仕事のやり方はそれなりに変わってきたと思う。一番の変化は、海外企業との共同プロジェクトが増えたことだ。昔は一社単独で元請けになり、国内や海外のメーカー・工事業者をつかうやり方だった。いまでは半分以上のプロジェクトが、海外のエンジニアリング会社との共同遂行で行われている。 こうなった理由はいろいろある。プロジェクトの規模が大きくなりすぎて、単独で請け負うにはリスクが大きくなりすぎたのも一因だ。プラントの値段はこの10 年間で２倍以上にはね上がり、１案件2000億円以上のジョブが珍しくなくなってしまった。それ以外に、日本人エンジニアのマンアワー単価が高いため、南欧や中進国の比較的安価な会社と組んで価格競争力をねらう、という面もある。
WBSを書く、エクセルのひな形 - sunatomohisa.com
Webの仕事も半分くらいはシステム開発系の仕事方法と重なるもので、職場でも「仕事はすべてプロジェクトとして設計してからとりかかる」というのが重要なポリシーになっています。デキるビジネスマンの第一歩も段取り上手なわけですが、勘と経験でタスクやスケジュールを設計するよりも、ＷＢＳ、ＰＥＲＴを勉強するのがオススメです。 ＳＥな先輩に入門本を1冊教えてもらいました。 エンジニアでなくてもわかるレベルで書かれていると思います。 おおまかな考え方で参考になったのは次の3つあたり、 詳細はボリュームも控えめなので「とりあえず読む」のがオススメです。 ・階層の考え方は レベル０はプログラム レベル１はプロジェクト名そのもの レベル２がプロジェクト単位の最初のブレイクダウン 同じような仕事であれば だいたいレベル３くらいまではパターン化できるものである。。 ・ブレイクダウンの考え方は プロジェクトのタイプを
完結：ブラック会社に勤めてるんだが、もう俺は限界かもしれない:ハムスター速報 ２ろぐ
第一部 http://urasoku.blog106.fc2.com/blog-entry-217.html http://urasoku.blog106.fc2.com/blog-entry-218.html 第二部 http://urasoku.blog106.fc2.com/blog-entry-223.html 第三部 http://urasoku.blog106.fc2.com/blog-entry-224.html 第四部 http://urasoku.blog106.fc2.com/blog-entry-239.html 第五部 http://urasoku.blog106.fc2.com/blog-entry-242.html 8 ：以下、名無しにかわりましてVIPがお送りします。：2007/12/10(月) 00:56:44.57 ID:a8l335.0 「僕は前スレは眼
ITサービス会社の営業と開発に大変革を迫る「工事進行基準」
システム・インテグレータなどITサービス会社は間もなく，トップマネジメントから現場の営業，開発に至るまで抜本的な変革に迫られる。これは「そうしなければ勝ち残れない」といった類の話ではない。2009年4月にも予定される会計基準の変更がITサービス業を直撃するためで，顧客との厳格な契約と正確な原価見積もり，精緻なプロジェクト管理などが実践できない限り，事業の継続自体が不可能になりかねないのだ。 今回の会計基準の変更では，SI（システム・インテグレーション）案件などで「工事進行基準」による会計処理が事実上義務づけられる。現行の「完成基準」は，システム開発が完了し検収書を受け取ってから売上を計上する。これに対して，工事進行基準はプロジェクトの進ちょく状況に合わせて売上を“分散計上”する。一見すると，単なる会計処理の方法の変更だが，営業担当者やSEの業務にも多大な影響を及ぼすことになる。 工事進行基
ロードスターに見る、プロジェクトマネジメント6つの秘密
「大成功した車の2代目は、たいてい失敗している。これは困ったな、と」 23年にも渡って新車が登場しなかったオープンツーシーター市場。そこに突如として現れ、全世界で大ヒットしたマツダの初代ロードスター。そんなロードスターの2代目、3代目を担当したのが貴島孝雄氏だ。 自動車の技術的な話と思うなかれ。日本が世界に誇る物作りの現場には、すべての仕事──プロジェクト進行につながる試行錯誤と伝統が詰まっていた。10月24日に行われたサイボウズのプライベートイベントにて、貴島氏が「ロードスター開発秘話」を披露した。 “開発秘話”を話せるように記録を付けておいた この開発秘話講演には、実にたくさんの写真や資料が登場する。800人を超える開発担当者の写真や、各部門で行われたテスト、分析なども豊富な写真と合わせて語られた。 「実は、開発中からできるだけたくさん写真を撮るようにしていた。記録を紡いでいった」 そ
MRI | 情報システム構築におけるリスク管理
大変申し訳ございません。 お探しのページまたはファイルは見つかりませんでした。 URLが正しく入力されているかどうか、もう一度ご確認ください。 正しく入力してもページが表示されない場合は、ページが移動したか、削除された可能性があります。 お手数ですが、下記より目的のページをお探しください。 The page or file you were looking for could not be found. Please check again if the URL is entered correctly. If the page does not appear, the page may have been moved or deleted.
[Think IT] 第2回：MOYAで行う分析領域定義 (1/3)
MOYAによる要求定義を行う際に、顧客と共同で「何を分析しようとしているのか？」「分析を行うのは何のためなのか？」といったことの共通認識を得るため、つまり要求定義のスコープを決めるために、「分析領域定義」というタスクを実施します。 なお「分析」という言葉は開発者の視点のように感じられるかもしれません。しかし、ここでは顧客の方も含めて「要求をみつけようとしている／分析している」という意図で「分析」としています。 このタスクでは「分析領域を定義する」としていますが、注意しなければならない点があります。それは「要求定義を行う段階において、そもそも分析の領域というものは最初から固定されているものなのか？」という疑問です。 この点についてMOYAでは、ある段階までの分析領域は、その領域の位置が流動的だったり、領域の大きさが伸縮したりするものと考えています。 つまり、最初に分析領域を定義したからといっ
人と人をつなぐ技法「チームビルディング」
「チームはできるものではなく、つくるもの」。この視点はありがたい。チームをまとめる立場なら、この視点+技法は必須。プロジェクトチームから町内会まで使える。 好むと好まざるとにかかわらず、社畜でいるかぎり、三十路も後半になると、一匹オオカミでいさせてくれない。「面倒みてやれ」という暗黙のメッセージとともに、何人か付けられる。たいていは、数回の毎朝ミーティングでチームらしくなってくる。 これが10人、20人のプロジェクトチームになると話が違ってくる。さらに、「思惑」「肩書」パラメータが追加されると厄介だ。以前のわたしは、アイスブレイクをいくつかと、赤ちょうちんぐらいしか知らなかった。仕事を通じてチームは形成されるものだと思っていた。 ところが、本書では、チームをつくる方法があるという。短期間で活性化したチームとして機能させるためのメソッドが紹介されている。[アジャイルレトロスペクティブズ]がチ
プロジェクトマネジメントの理論と実践
この連載では，ITエンジニアにとって必須のスキルと言ってよいPMの基礎知識と情報システム開発への適用方法を，事例を織り交ぜながら解説していく。 第1回 PM実践体系--重要性増すPM,そのシステム開発での実践体系を知る 第2回 プロジェクト計画--システム開発プロジェクトの「計画」を作成する 第3回 品質管理計画--プロジェクト全体を通じた品質基準や方針を策定する 第4回 見積もりとコスト計画--開発負荷を見積もり，プロジェクトのコスト計画を策定する 第5回 マスター・スケジュール プロジェクト全体を見通す，実行性のあるスケジュールを作る 第6回 組織・要員計画--プロジェクトを効率的に推進できる組織・要員計画を作る 第7回 問題管理と変更管理--プロジェクトで生じた問題と仕様変更をコントロールする 第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り
プロジェクト管理ツール比較表 (でぃべろっぱーず・さいど)
なんかこのエントリが好評だったので、みなさんプロジェクト管理ツールに興味があるのかと思い、とりあえずTracとredMineの比較表を作ってみました。 Google Docs & SpreadSheet で作ってますので、間違いがあったらちょいちょい修正するかもしれません。 ↓sheetのURLはこちら http://spreadsheets.google.com/pub?key=piV-xE0pxQrgxSmrLXZf_ZA PJで実際にTracを使った経験と、redMineを触ってみた感触から考えると、Tracはプログラミング中心のチーム向きで、redMineは作業系のタスクが多いチーム向きなのかなぁと思います。 後は、自分でごりごりカスタマイズしていきたい人はTrac、プラグインのインストールとかめんどくさいって人はredMineという棲み分けもあるかも。
Railsで作られたプロジェクト管理ツール"redMine" (でぃべろっぱーず・さいど)
redMine - project management and issue tracking Rubyで作られたプロジェクト管理ツールです。 GanttチャートやMyページなど、Tracにはデフォルトで備わっていない機能が付いてますね。 デモサイトはこちらです。 Tracよりも使いやすいのかしら。 サイトに書かれている特徴には以下のものが挙げられています。 ・Multiple users/multiple projects →多様なユーザ／プロジェクトに対応 ・Fully customizable role based access control →アクセス制御によるカスタマイズ可能な権限管理 ・Issue tracking system →問題課題追跡システム（トラッキングシステム） ・Fully customizable workflow →カスタマイズ可能なワークフロー ・Doc
第16回 ドキュメント管理の要はPMOが握れ
プロジェクトで作成するドキュメントは、メンバーが増え、時間が経つと急激に増えていく。ドキュメント管理規定があっても、周知徹底は意外に難しい。シンプルなルールを定めた上でチームの裁量を認め、ドキュメント管理の要所をPMOが握るようにするとよい。 高橋信也 マネジメントソリューションズ 代表取締役 「9月3日の役員プレゼンで使った資料はどこにあるの？」 「8月27日の進捗会議の議事録はどこにいれた？」 「プロジェクトの共有フォルダの構成がぐちゃぐちゃじゃない！ 何がどこにあるのか分からないから、分かるように整理してよ！」 このようにプロジェクトマネジャから突然言われても、一度始まってしまったドキュメント管理の混乱は一朝一夕に収まるものではありません。 “魔窟”と化したドキュメント・フォルダには、手を付けたくない 本来、プロジェクトで作成する膨大なドキュメントは、ドキュメント管理規定に基づいて分
プロジェクトマネジャは独りぼっちじゃない
「確かにプロジェクトマネジメント（PM）を持ち上げる記事を沢山書きましたよ。PMって，前向きな話だと思っていたのですが…」。 信頼がおける人，あるいは敬意を抱いている人から面と向かって，「あなたが悪い」「責任は重大だ」ときっぱり言われると正直な話，かなり落ち込む。こうした人には会わないようにすればいいのだが，色々と教えて欲しいことがあり，しばらくしてまたお目にかかると，同じ批判を繰り返される。 何の話かと言うと，PMについてである。もう6年くらい前になろうか，日経コンピュータの副編集長をしていた時，PMについて特集記事をまとめたり，専門家に寄稿を頼んだり，ITproにコラムを書いたり，セミナーを主催したり，本を作ったり，と実に色々なことをした。そうした活動の集大成が日経コンピュータ2002年4月22日号に掲載した特集記事「プロジェクトマネジメントが日本を救う」であった。 この雑誌が出版され
「小手先のソリューション改革の愚」
衰弱堂の栞をはじめて、ある程度決まったニュースソースをチェックするようになったのだが、日経BP社のNBonlineの記事の濃さは目を瞠るものがある。同じ日経BPでもITProあたりはリリースの垂れ流しや駄記事が多いのだが、NBonlineは執筆者や題材、記事のスコープなど全体的にレベルが高い。明らかに編集能力の差を感じるわけで。 で、はてなブックマークではほとんどコメントがついていないのですが、「宮田秀明の『経営の設計学』」という連載の9/7の記事「年金問題が象徴する日本社会の大いなる課題」はぼくにとって非常に示唆に富む一編だった。 例えば、年金の徴収業務を民間へ、強制徴収の業務を国税庁に委託しようとしているらしい。しかし、社会保険という公共サービスのビジネスモデル自体が破綻寸前というのに、根本的な問題には手を加えないで、徴収という、一番末端の「ソリューション」を変えれば、なんとか生き返る
4つのステップで作る webサイト開発のスケジュール作成 : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 webディレクターという仕事は色々な職種の方たちの間に入って調整をすることが多いのですが、一口で「調整」といっても結構難しいものです。webサイト開発に限らず、「言われたまま、言われた順にこなしている」という人が担当だと予定通りに物事は進みません。そこで今回は、webサイト開発時に頻繁に用いられるスケジュール作成方法についてお話してみたいと思います。 山ほどあるタスク、どれから手をつけるべきかを考えるためのヒントになれば幸いです。 ■ステップ.1 タスクに優先順位をつける まずはそれぞれのタスクに優先度をつけ、種類を決めて考えます。 ・クリティカル・パス (絶対に遅らせてはならないもの。最優先として認識すべきもの) 参照記事：プロジェクトマネジメントＯＳ本舗 ・やらなければいけないこと (バグ解消、トラブル対策で必須なもの、社外との交渉など) ・やっておくといいこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【補助線】仮説を共有する
【補助線】カップヌードルの開発で「ラーメンの父」安藤百福の果した役割
http://www.e-research.biz/column/colweb/002314.html
オンラインプロジェクト管理ツール「Zoho Projects」が日本語化