プロジェクトメンバーがそろう前に行っておく事前準備 ― ＠IT情報マネジメント
プロジェクトメンバーがそろう前に行っておく事前準備：ユーザーサイド・プロジェクト推進ガイド（14）（1/2 ページ） 業務部門からプロジェクトに人を出してもらう際、その人が来るまで手をこまぬいている必要はない。先にできる準備は、システム担当部門だけで進めておくことが大切だ。 業務部門からプロジェクトチームに人を出してもらうことが決まってから、実際にその人がチームに参加するまでに、異動の事務手続きや引き継ぎなどのためにある程度の期間があります。 プロジェクトの活動は、プロジェクトチームのメンバーが全員そろうのを待って、開始しなければならないということはありません。チーム編成の完了まで、何もせずに過ごすことはもったいないことです。貴重な時間は取り戻すことはできません。 そこで業務部門からのメンバーを受け入れる前から、システム担当部署のメンバーだけでできる作業を進めておきます。この期間を有効に使
プロジェクトチームのマインドとルールを方向づけるには
プロジェクトチームのマインドとルールを方向づけるには：ユーザーサイド・プロジェクト推進ガイド（12）（1/2 ページ） システム開発の経験に乏しいメンバーからなるプロジェクトチームは、最初の“オリエンテーション”が大切だ。前回に引き続いて、オリエンテーションで話すべき内容について考察する。 業務部門に積極的に顔を出すことを伝える 業務部門をプロジェクトから遠ざけるプロジェクトチームは、全力を尽くして努力したとしても、失敗する可能性が大いにあります。出来上がったシステムは「使えないシステム」となっている可能性があるのです。 業務部門出身のプロジェクトメンバーが自身の出身職場に対して問題意識を持っていることはよくあります。このようなメンバーは実に頼もしい半面、その問題意識が独善的な場合があります。 1つの業務部門を見ても、その中には管理職・ライン・スタッフ・事務などいろいろな役割があります。こ
プロジェクトは失敗するのが当たり前！？ ― ＠IT情報マネジメント
ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16％。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16％だったという。 日本においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」（社団法人 日本情報システム・ユーザー協会）に調査によれば、システムの仕上がりに満足と回答したユーザーは10％前後に
TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして
プロジェクト管理の問題を解決します！ CCPMソフトウェア BeingManagement3 (BM3)
NEW!CCPMソフトウェア『BeingManagement3』 クラウドサービス向けオプション機能「BM Adviser」10⽉2⽇発売 〜ワンクリックで専任コンサルタントのノウハウをアドバイス〜2023年10月2日 NEW!『BeingManagementクラウドサービス』利用規約改定のお知らせ2023年9月19日 夏期休業のご案内2022年8月1日 Internet Explorerのサポート終了に伴う『BeingManagement3』の対応について2022年3月4日 年末年始の営業についてのご案内2021年12月10日 夏期休業のご案内2021年7月21日 5 月連休に伴う休業のご案内2021年4月19日 年末年始の営業についてのご案内2020年12月24日 夏期休業のご案内2020年7月27日 5 月連休に伴う休業のご案内2020年4月27日
プロジェクトキックオフ！ オリエンテーションで話すこと
プロジェクトキックオフ！ オリエンテーションで話すこと：ユーザーサイド・プロジェクト推進ガイド（11）（1/2 ページ） システム開発の経験に乏しいメンバーからなるプロジェクトチームを始めるに当たって、まずは“オリエンテーション”が必要だ。強いプロジェクトチームを作るには、最初に何を伝えるべきだろうか？ キックオフをオリエンテーションとする チームを発足する際には、まずキックオフミーティングを開催して、プロジェクトの概要、すなわち、目的、スケジュール、組織、その役割などの説明と、メンバーの自己紹介とチーム内での役割と作業の分担を決定します。 ここでは、キックオフミーティングのことを「オリエンテーション」と呼ぶことにします。 この連載では、コンピュータ・システム開発の経験があまり豊富とはいえない企業で、メンバーを業務部門から出してもらっているプロジェクトチームを想定しています。このような未経
スキルシートでいったい何が分かるのか（Page 1） − ＠IT情報マネジメント
本連載はプロジェクトの成否を握る大きな要素「人とチーム」の関係に焦点を当てます。開発プロジェクトが成功するか失敗するかは結局、開発チームを構成するそれぞれのスタッフの力量にかかっているといってもいいかもしれません。 ITプロジェクトの人集めって何だろう？ システム構築と「人集め」 プロジェクトを遂行するとき、マネージャとアーキテクチャの大切な仕事の中に「チームづくり」があります。プロジェクトの成否・効率は「人選び」によって左右されるといっても過言ではありません。 この「人選び」にも大きく分けて2種類あります。1つは「プロジェクトの命運を握る人」という意味での人選びです。「マネージャ」「アーキテクチャ」といった中心的な役割を果たす1、2名がこれに当たります。もう1つは、そういった「命運を握る人」が一連托生（いちれんたくしょう）として選ぶ「プロジェクトメンバー」です。 無論、人選をはじめとする
困難に立ち向かうリーダー、逃げるリーダー － ＠I...
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、システム開発プロジェクトにおけるリーダーシップを中心に「私の視点＝私点」を皆さんにお届けしています。 今回の内容は、リーダーシップトライアングルのLoveとCommunicationに関係しています。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を、Communicationについては、第8回「コミュニケーションはリーダーシップの
連続的で不可視の「プロジェクトX」たち - アンカテ
「プロジェクトＸ」成功の原因は、プロジェクトを描くフォーマットにあった。つらいプロジェクト、成功への道は見えない。そこで「男たちの逆転をかけたドラマ」（だいたい番組開始35〜40分ぐらいだったか。「水戸黄門」を想起させる）が始まって、めでたくプロジェクトはうまくいく。 多くの人々がこのパターンにはまり、日本PTA全国協議会は「プロジェクトＸ」を2003、2004年度の「子供に見せたい番組」に選定するまでになった。 少し考えれば、この構図が欺瞞（ぎまん）であることはすぐ分かる。「男たちの逆転をかけたドラマ」を仕掛けなければならないという時点で、すでにプロジェクト管理は失敗しているのだから。 適切なプロジェクト管理によって、潜在的な危機を事前に回避して本当に成功したプロジェクトはドラマにも研究材料にもなりにくい。従って、なかなか人の目に止まらない。 日本Rubyカンファレンス2006というイベ
「やることリスト」に基づく見積もり手法
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の１つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の１つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
実践！ 自己組織化プロジェクト
前回のまとめ ～ すべてのものを「粒」で考えてみよう 前回の「アリの生態にみる自己組織化のルール」では、プロジェクトマネジメントと一見何の関係もない、「アリ」の社会的行動が、シンプルなルールにのっとって自立的に機能している開発プロジェクトと同じ現象～「自己組織化」という現象なのではないか？ ということを述べました（比喩的に似ているのではなく、同じ現象なのではないか？ というのがミソです）。 そこで、この「自己組織化」現象をさらに推し進めるため、プロジェクトのあらゆるところで、自然のプロセスに倣い、 大きさのそろった「粒」をできるだけ増やすこと 「粒」と「粒」との連携は可能な限りシンプルにすること 「粒」と「粒」との連携方法に例外をなくすこと という、シンプルなルールを当てはめるとよいのではないか、という結論を書きました。あらゆるものを「粒」としてそろえられないか？ と考えるところがポイント
プロジェクトチームのリーダーに向く人、向かない人 ― ＠IT情報マネジメント
チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています（年功序列主義の会社ではよく見られることです）。これは、リーダーとして特別な素質がないと思われたり、思い込んだ
テストを金額にするといくら？ ― ＠IT
テスト駆動開発（Test Driven Development：TDD）。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。 テスト駆動開発（TDD）とは テスト駆動開発は一般にエクストリーム・プログラミング（XP）の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なもの
GanttProject.org - Home
GanttProject is a project scheduling application written in Java and featuring Gantt chart, resource management, calendaring, import/export (MS Project, HTML, PDF, spreadsheets). Learn more on http://ganttproject.biz Features Gantt chartResource load chartPERT chartMicrosoft Project compatibilityExport to PDF, HTML and CSV
問題解決案を導き出す「柔軟な発想力」を鍛える
株式会社リアルナレッジ代表取締役 秋池 治氏 横浜国立大学卒。メーカー系情報システム会社にてシステム企画とシステム開発に従事。その後、ユーザー系企業でデジタルビジネスの企画および社内改革に取り組む。2003年に数名の仲間とともに株式会社リアルナレッジを設立、業務プロセスの可視化やプロセスの最適化により、経験や勘に依存せず業務を遂行するためのパフォーマンスサポートを提供している。著書に『情報エキスパート』（アプライドナレッジ刊）がある。 第1回、第2回でもこの図を示しましたが、今回は「解決策の発想」にスポットを当ててお話をします。これまでの流れですが、「仮説構築」をしたら、「仮説の検証」（仮説の確認作業）を行います。ここでは、ヒアリングスキルと構造化のスキルが必要で、この前提があって、「問題の理解」という問題をつかみ上げる段階に入ります。構造化スキルにより問題をつかみ上げたら、今度はどう知恵
出動！ 火消しエンジニア 火事場では何が起きているのか － ＠IT自分戦略研究所
プロジェクトでのトラブル発生を「火が出た」、さらに悪化し収拾がつかなくなると「火事場」などと呼ぶ。そんな修羅場でITエンジニアは何を見、何を学んだのか。事態収拾を図る「火消し部隊」として燃えさかる現場に投入されたあるITエンジニアに、火消しの極意を聞く。 ■火災発生、緊急出動せよ どんな仕事場にも多少のトラブルはある。不具合は質も規模も多岐にわたるが、端的にいえば何かが「うまくいかない」。それが積み重なるとプロジェクトは制御不能な状態に陥ってしまう。 日本ヒューレット・パッカード（日本HP） コンサルティング・インテグレーション統括本部 金融アカウント第一本部 第三部 プロジェクトマネージャの田中淳一氏も、いくつかの修羅場をかいくぐってきた1人だ。通常の勤務に比べて何倍も激烈な経験だが、多くの教訓を得る場でもあるという。 田中氏はこれまでに何度か、火事場となったプロジェクトに助っ人として合
プロジェクトチームに付きまとう制約を打破するために
システム開発に不慣れなユーザー企業のプロジェクトチームには、3つの危険なタイプがある。「丸投げタイプ」「メッセンジャータイプ」「独断専行タイプ」だ。こうしたプロジェクトチームにならない方法を考えていこう。 前回「タイプ別プロジェクトチームの問題点」では、ありがちなプロジェクトチームのタイプを取り上げました。 実際のプロジェクトチームで多いのは（2）の「メッセンジャータイプ」だと思われます。まったくの（1）「丸投げタイプ」はそんなに多いとは思いませんが、時間の都合などでプロジェクトの一部分が丸投げ状態になるケースはかなりあるでしょう。（3）のタイプも含め、これらのタイプは“安物買いのゼニ失い”です。これらのタイプのチームしか組織できないところが失敗を繰り返すのです。 それでは、なぜこのようなチームしか組織できないのでしょうか。重要な原因として、プロジェクトチームに時間や人数の制約があること、
ITプロジェクトを見える化する
本稿は、ITプロジェクトポートフォリオ管理（PPM）の上位レベルの概要を解説し、プロジェクト・ポートフォリオ管理ベンダ市場全体について考察する。その後、PPMインプリメンテーションの成功率を高め、このソリューションを最大限に活用するための手順の指針を示す。 企業が効果的かつ効率的に戦うために ここ2年ほど、地域分散型ビジネスと、情報、営利活動、そして文化交流が実現するか、場合によってこれらが情報や通信技術から生まれる世界における生活の影響に関する話を定期的に聞くようになってきた。Thomas Friedmanは自身のベストセラー「The World is Flat: A brief history of the twenty-first Century」［注1］で、「もはや地理は影響しない」というもっともらしい概念を示している。Friedmanがいいたいのは、どのような規模の会社でも開拓で
「見える化」だけでは見えないもの ― ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、前回までリーダーシップトライアングルについて説明してきました。今回からは個別の題材を取り上げ、システム開発プロジェクトにおけるリーダーシップを中心に、連載のタイトルのとおり「私の視点＝私点」を皆さんにお届けしようと思っています。 各回の題材は、何らかの形でリーダーシップトライアングルと関連しています。各回の記事とリーダーシップトライアングルとの関係を明確
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
恐怖！現場の叫びでわかった嫌われるプロマネの正体｜【Tech総研】