システム開発トラブルを防ぐには、現場からの警告を受け付ける窓口を
開発トラブルを未然に防ぐ最も効果的な対策は、適切な人材を、適切な役職に就けることだ。業務システムの要件定義では、業務知識や業務管理知識を持つ人材の登用がカギを握る。現場からのアラートを受け付ける組織を設け、人格面で優れた人材を当てる工夫も必要だ。優れたプロジェクトチームを作ることが、トラブル防止のなによりの処方箋になる。 心血を注いだ開発プロジェクトが遅延し、赤字になり、裁判沙汰になったのでは担当者は立つ瀬がない。連載の最終回ではトラブルを防ぐノウハウを、プロジェクトの人選を中心に紹介しよう。 業務管理知識を持つ人材を探す 第1回でも言及したが、システム開発トラブルで最も起こりがちなのは、業務知識と業務管理知識の重要性をユーザー企業とITベンダーがともに認識していない場合だ。 ITベンダーの選定プロセスには、「要求書に書いてある言葉の奥深さを知らないITベンダーの見積もり額が最も安くなる」
もしも童話「おおきなカブ」がITのデスマプロジェクトだったら
渋谷の雑居ビル。 ホワイトボード前に置かれたパイプ椅子にイヌ、ネコ、ネズミが一触即発の雰囲気で座っている。 扉が開き、慌てた様子の青年が入ってくる。 孫「お疲れ様です、すいませ――」 ネズミ「遅えよッ！！」 ネコ「！！」 イヌ「……ネズミさん、怒鳴るのはやめましょうって……」 ネズミ「……チッ」 孫「あの、本当、すいません。11時からって、皆さんにお約束してたのに……」 イヌ「ま、まぁ。とりあえず、ミーティングの報告をお願いします。もう２時間も押してるんで」 孫「は、はい！ すいません、ではこちらの資料を…… あっ」 イヌ「どうかしましたか？」 孫「印刷した資料が１部たりなくて。……じゃあ、はい！ 僕のは大丈夫なんで、業務委託の皆さんで、どうぞ！」 ネズミ「ッ……！」 イヌ・ネコ「……」 孫「はい、では皆さんお手元に資料ありますかね、お疲れ様です！」 ネズミ「……」 イヌ・ネコ「……お疲れ
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
なぜ時間がないのか？2つの対策をGoogle社の分析結果から考える。 - プロジェクトマネジメントの話とか
やあ、よく来てくれたね。 この絶望に満ちた、何の救いもない「日常」という灰色のキャンバスに、一つ一つ色を重ね少しずつ彩りを灯していく。ここはそんなブログです。 すみません、いま思いつきでテキトーに書きました。wiz7です。 さて、早いもので2016年も目前ですね！時間の流れはこれからも容赦なく加速していきます。 「もう年末！？今年やりたかったことの半分しかできてない！」 「いつも気づいたら休日・連休が終わってるんだよね……」 「やっと3時間連続でデスクワークの時間が確保できたものの、不完全燃焼のまま、いつの間にか残り15分！？」 なぜ、このようなことが起こるのでしょうか？ 誤解を恐れずに言えば、「人は時間を馬鹿にする生きもの」だからです。 一般的に、我々には家計簿をつける習慣はあるものの、時間簿をつける習慣はありませんよね。 コレって、よく考えたらおかしな話だと思いませんか？僕らはお金に対
書籍『Webプロジェクトマネジメント標準』を全文PDF無償公開 | News&Column | 株式会社ロフトワーク
書籍『Webプロジェクトマネジメント標準』を全文PDF無償公開 ロフトワークは、書籍『Webプロジェクトマネジメント標準』全文をPDFデータで無償公開します。 ロフトワークは、2002年という早い段階からWebとクリエイティブの領域に世界標準のプロジェクトマネジメントの知識体系「PMBOK（ピンボック）」を導入し、Webプロジェクトのフレームワーク確立やリスクの軽減などに努めてきました。その過程で得た知識や経験を体系化、Webの制作現場につながるように編綴し、2008年に技術評論社より書籍『Webプロジェクトマネジメント標準』（共著=林千晶・ロフトワーク代表取締役、高橋宏祐・富士通グループWebサイト統括（*1））を出版しました。 『Webプロジェクトマネジメント標準』は、プロジェクトの課題が個人の能力・努力の問題であると苦しんでいる方々にこそ読んでいただき、制作側・クライアント側の双方が
開発マイルストーン
マイルストーンは一つの指標です。 プロジェクトでは、達成したい目標へ向かってまずステップごとに段階を分け、計画を立てて実施します。 その結果の検証をして、これをもって修正された新たな計画を立て再び実施を行います。 このようなサイクルでプロジェクトを進めていく上で重要な指標がマイルストーンです。 ツール「開発マイルストーン」は、システム開発などで必要なプロジェクト管理をサポートするためのツールです。 MicrosoftExcelを使用して、簡単に入力でき、かつグラフィカルに表現することができます。 無料で使える工程管理ソフト 「開発マイルストーン」は、MicrosoftExcelが利用できる環境であればどなたでも利用できます。 また、本機能以外にもExcelに備わっている豊富な機能をそのまま利用できるため、専用のアプリケーションよりも柔軟性に優れています。 実用に十分な機能 開始日と日数を入
「大きなかぶ」に見る開発プロジェクトにおける教訓、あるいは猫は何故ネズミを呼んだのか: 不倒城
「大きなかぶ」というお話をご存知だろうか。 「大きなかぶ」は、ロシア民話を元に描かれた絵本である。主人公であるところの「おじいさん」は、畑にかぶの種をまく。その株はめったやたらに大きく育ち、喜んだおじいさんはかぶを抜こうとするのだがなかなか抜けない。 おじいさんはおばあさんに救援を頼むのだがそれでも抜けない。おばあさんは孫の少女に、少女は犬に、犬は猫に、猫はネズミに、それぞれ救援を頼んで皆で引っ張ることで、ようやく株は抜ける。「うんとこしょ、どっこいしょ、それでも株は抜けません」の繰り返しが印象的な童話である。 さて、実はこの「おおきなかぶ」というお話は驚く程示唆的であって、われわれはこの「株の引き抜き」をシステム開発案件に見立てた時、二つの教訓を得ることが出来る。 1.往々にして、「人手が足りないから」ということで救援を頼むと、現行人員よりもパワー不足の人員がアサインされる。あるいは、協
IT業界で高く評価される10のソフトスキル
現代のITプロフェッショナルには技術的な専門知識とソフトスキルの双方が要求される。このようなことはずっと昔から言われ続けている。しかし、そういったソフトなスキルに対するニーズはどんどん膨らみ続けているのである。 IT技術のスキルとしてどういったものが必要になるのかは、企業によって異なっている。しかし、ほとんどのIT企業に共通するニーズがある。それがソフトスキルというわけだ。こういったニーズが求めらるのは今に始まった話ではない。30年ほど前にも、企業のIT部門は文系の学生を採用し、ビジネスアナリストやシステムアナリストへと育成することで、プログラマーとエンドユーザーの間に横たわる「コミュニケーションギャップ」を埋めようとしていた。また、最高情報責任者（CIO）の経歴を見てみると、ほぼ半数が文系出身となっている。 では、現代の企業がITプロフェッショナルに求めるソフトスキルとは、どういったもの
プロジェクト管理の現場で使用される、分かりにくい表現10選
プロジェクトを成功させるには、マネージャーやチームメンバー、利害関係者の間にしっかりとしたコミュニケーションが確立されていなければならない。そのためには、本記事で紹介している表現が本当に意味するところを押さえておくべきだろう。 コミュニケーション能力は、雇用者が従業員に求める資質として常に上位に挙げられている。しかし（筆者の経験によると）そういった資質はマネージャーに対してはそれほど厳しく要求されておらず、彼らの中には、一歩間違うと問題につながるようなスラングや、耳にのみ心地よい言葉を多用する者もいる。 相手の言葉を額面通りに受け取るのではなく、その言葉の本当の意味を理解する能力は重要である。以下では、プロジェクト管理の現場で使用される、分かりにくい表現を筆者自身の調査や経験に基づいて10個選び出し、解説する。 ＃1：余白を管理する（manage the white space） 「余白」
「もしもの時どうなさるのですか」――分割発注への疑問に答える
システム構築を分発注で仕事を進める際、個々の仕事をどのようにつなげるのか不安を感じる向きもあるようだ。しかし日常の仕事をどのようにこなしているかを考えれば、解決策は見えてくる。 口頭での指示とメモ付きの支持 前回のコラムでも書いたが、長崎県庁の発注手法である「ながさきITモデル」では、分割発注が要なのだが、「どうやって分割したらいいのか分からない」とか「分割したら、それぞれの仕事をつなげるのが大変なのではないか」などの質問が寄せられる。 回答を書く前に、仕事をどのような感じでやっているか、改めて考えたい。例えば、住所が変わったり、家族が増えたりすると手当の申請を行うが、どうやっているだろう。システム化以前は、次のような手順で行っていた。 （1) 本人が申請書(通勤経路変更届、家族状況変更届)を書く。 （2) 課内の庶務事務担当者が基本的なチェックを行う。 （3) チェック完了後、課長に決裁
Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」
Windows、Mac、Linuxのいずれでも動作が可能で、JRE1.5以上がインストールされていれば問題なく利用できるのがこの「OpenProj」。ガントチャート、ネットワークダイアグラム、WBSとRBSチャート、レポートの印刷とPDFによる出力、コスト計算などなど、プロジェクト管理に必要なほとんどの機能が備わっています。 また、Microsoft Projectのファイルを開いたり保存することも可能です。ただのビューワーではなく、実際に編集できるのでかなり便利。メニューなどはほとんど日本語化されており、抵抗なく使うことができます。 ダウンロードとインストール、実際の表示などは以下から。 Home | Serena Open Source and Hosted Project Management Software http://openproj.org/ 今回はWindows用を使うの
［進捗管理編］人月を入れ替えてはいけない
システム開発プロジェクトでは規模を表す単位として「人月」という単位がよく用いられる。これは技術者一人が1カ月労働することを意味し，人を数える助数詞「人」と，時間を数える単位「月」を掛け合わせたものである。数学的な見地から見ると「人」は分離量であり「月」は連続量である。この分離量と連続量の違いとは，例えば計算機について考えれば，分離量はデジタル計算機であり，連続量は計算尺である。つまり，「人月」とは分離量と連続量を掛け合わせた特殊な単位であり，どちらかというと「概念」に近い。 この「人月」という概念を「人」×「月」という単純な数式で考えると大きな失敗を犯す。例えば，プロジェクトの後半で問題が発覚し納期遅延が発生しそうな場合，あとどのくらいの工数が必要かを算定し，追加要員を投入して遅延を挽回しようとすることがある。 これは，遅延挽回対策として非常に危険な方法である。遅延を挽回できるどころか，当
破たんした見積もりはプロジェクト失敗への近道
建築業界では、ほとんどの工事は見積もり額の－10～＋10％に入るといわれており、多少誤差があるが、このPMBOKの定義とほぼ一致している。これに対しシステム開発では、最終的にはどのくらいの見積もり精度なのだろうか。感覚値だが、たぶん、－20～＋100％ぐらいになっているのではないだろうか。 それでは、なぜシステム開発においては、見積もり精度が出ないのであろうか。これには、いくつかの理由が考えられる。 （1）機能の洗い出しが不十分 確定見積もりを算出するためには、プロジェクトで開発するシステムの機能とその難易度が分からないといけない。しかし、見積もりを算出する段階で、そもそも機能は明確になっているだろうか。機能が明確でないのに見積もりを提出しているとすれば、その精度はそもそも期待できなくて当然である。 （2）見積もり技術が確立していない システム開発においては、見積もる人によって金額に倍の開
システム化範囲がぶれていれば失敗する ― ＠IT自分戦略研究所
プロジェクトの失敗例で多いのは プロジェクトの失敗で、一番多いのはシステム化範囲（スコープ）がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである。 このようなプロジェクトは昔から後を絶たないのであるが、その対策が十分に取れているとは思えない。今回は、このシステム化範囲がぶれる問題を考えていきたい。 なぜ、システム化範囲はぶれるのか システム化範囲がぶれる理由はいろいろあるが、その代表的なものを挙げてみる。 （1）「ｘｘシステム一式」という契約書は意味があるのか そもそもシステム化範囲は明確になっているのであろうか。最近私が関与した会社で、ベンダから送られてきた契約書を見せてもらったが、そこに記載された委託内容は「生産管理システム一式」という文言が1行書かれているだけであった（図1。この契約書は、一体どういう意味を持っているのであろう。確かに金額や一般的な責任は
はじめてのRFP――発注時に意思疎通をスムーズにする提案依頼書の作り方 | 安く!早く!を実現するサイト制作の発注マニュアル
発注の基本はRFP作りから 発注をマスターしてベストな提案を引き出す いちから覚える提案依頼書の作り方 制作会社など外部の業者に対して、具体的になにをしてもらいたいかの提案要求を伝える際に必要となるのが提案依頼書（RFP：Request for Proposal）だ。場合によっては、口頭の打ち合わせベースで仕事を進めることもあるかもしれないが、RFPを作ると作らないでは仕事の進め方に大きな差が出る。ここでは、RFPを作るときに必要な基本の要素を紹介しよう。 取材・文：編集部 協力：高橋 宏祐（富士通株式会社 コーポレートブランド室 担当部長） 富士通でエンジニア職を経験した後、1998年より富士通のウェブマスターとしてウェブ戦略を企画実行。2002年6月に富士通ウェブ・アクセシビリティ指針を公開し、日本のアクセシビリティ普及をリードする。2003年にFUJITSUウェブ・ユニバーサルデザイ
MOONGIFT: » ブラウザベースの高性能プロジェクト管理「Epiware Document Management」:オープンソースを毎日紹介
仕事をする時には情報は一箇所に集中しているのが良い。そしてプロジェクトで必要な要素といえば、タスクの管理とカレンダー、ドキュメント管理などではないだろうか。 ドキュメントはエクスプローラで、細かなことはWikiで、カレンダーはグループウェアで…そんな情報の散在は非効率的だ。ぜひこれを導入検討しよう。 今回紹介するオープンソース・ソフトウェアはEpiware Document Management、高性能プロジェクト管理ソフトウェアだ。 Epiware Document Managementではプロジェクト管理ソフトウェアとして、カレンダー、タスク管理、フォーラム、チーム管理等の機能がある。しかしそれだけでは収まらない魅力がある。 まずWiki機能がある。そしてドキュメント管理機能があり、チェックインすることでバージョン管理もできるようになっている。Wikiもファイルとして管理されるのでバー
情報処理技術者(AN/PM/AE)に電子レンジを買わせてみる - uessay
情報処理の秋の申し込み期限が8月20日なのですが、いろいろ迷ってます。今まではシステムインテグレータ的な仕事だったのでシステムアナリスト(AN)を目指していたのですが、開発寄りの職場に転勤になったので、アプリケーションエンジニア(AE)の方が向いてるだろうか。それともプロジェクトマネージャ(PM)？ 午前問題も共通だし、論文も似たようなものなので、去年までANを勉強していた私（とある事情で受験しませんでしたが）がAEもしくはPMを目指してもなんとかなるんじゃないかとも思うのだけど、果たして大丈夫だろうか。 とりあえず思考実験で、それぞれの役目(AN/PM/AE)になりきって「妻に電子レンジを買いにいくよう頼まれた男」を書き分けてみます。 システムアナリスト(AN)のお買い物 まず、あってもなくても将来計画を明確に。妻は電子レンジでクッキーを焼いたりするだろうか。卵と牛乳を買った時点で、クッ
ウノウラボ Unoh Labs: ベンチャー流Webサービスの作り方(開発チーム編)
尾藤正人(a.k.a BTO)です 前回はWebサービスを作るときの企画の部分について書きました (ベンチャー流Webサービスの作り方(企画編))。 今回はWebサービスを作るときの組織作りについて書いてみたいと思います。 僕がウノウに入って始めたのがフォト蔵の開発でした。 当初は開発が僕、ディレクションが代表の山田という二人体制でやってましたが、 組織が大きくなるにつれてだんだんと人数が増えていきました。 現在は僕も山田もフォト蔵からは離れて新しいチームで開発を行っています。 二人体制から始めて、少しずつ人数を増やしていって、 立ち上げメンバーが開発から離れるまでいろいろ経験しながら 自分が感じた事を簡単にまとめたいと思います。 ・最終決断は一人で 何をするのか、戦略はどうするのか、方向性は何なのか、最終的な決断はリーダーが一人で行います。 個人の主張を尊重しすぎて、各々が好きな事を始め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のプロジェクト管理入門
営業の押し込み案件は失敗への扉
