【中級】今こそ見直す 開発と運用の連携術 第2回
役割分担や責任範囲を明確にしても，その履行に必要な情報を得られなければ絵に描いた餅になりかねない。 旭化成情報システムの開発担当者はかつて，サーバーに新規ジョブを追加し，動作スケジュールを適切に設定したにもかかわらず，ジョブが動かないというトラブルを経験した。原因は，新規ジョブを追加するという情報が運用担当者にきちんと引き継がれなかったことにあった。運用担当者が該当サーバーをメンテナンスしたときに，見慣れないジョブに気づいて，動作しないように設定を変えていたのだ。 こうしたトラブルを防ぐには，開発と運用の間で情報を確実に引き継ぐことが肝心だ。情報を引き継ぐ主な方法には，開発と運用を“一体化”することで情報の欠落を無くす方法と，逆に相互監視を強化して引き継ぎ漏れをチェックする方法がある。 開発と運用で一つのチーム ミサワホームの開発担当者と運用担当者は，情報の欠落を無くすためにシステム設計な
ウノウラボ Unoh Labs: チームリーダーが心掛けるべき10のポイント（テストチーム編）
こんにちはー！ やまもと＠テスト番長です。 現在ウノウのテスト専任のスタッフは自分一人です。 いわば一人親方（建設業界用語）状態なのですが、 前職では総勢6人のテストチームを組織しておりました。 その頃心掛けていた、チームリーダー心得を書いてみたいと思います。 1.聞き上手になる 組織はコミュニケーションが命です。 話しにくいリーダーだと、必要な情報がうまく伝わりません。 気軽に相談を受ける・噂話が耳に入ってくるようでなくてはいけません。 そのためには聞き上手に徹すること。特に批判的な態度は控えることが重要です。 そんな相手には、誰も何も相談しないでしょう。 2.「おいしい仕事」を独り占めしない。 重要な判断や、やりがいのある仕事はなるべくメンバーに廻すようにします。 一見、重要な仕事はリーダーがこなすべき事のように見えますが、 その裏で他のメンバーがつまらない仕事ば
全員が「明るい、楽しい」と感じるチームにしたい ― ＠IT情報マネジメント
前回「優秀なプロマネはメンタルな働きかけもうまい」から少し間が空いてしまいましたが、第2回目の今回は、リーダーに求める心の在り方をお伝えしたいと思います。といっても、1回目をご覧いただいた方であればお分かりだと思いますが、道徳的な話をするつもりはありません。結果として道徳的な話と同じ内容となるかもしれませんが、心理的な裏付けによって、チームのパワーを最大化するために必要な心の在り方にフォーカスしています。 2つのコミュニケーション コミュニケーションは、コミュニケーションを取る相手の違いから2つに分類されます。1つは、他者とのコミュニケーション。もう1つは自分自身とのコミュニケーションです。 前者については、ビジネス書などでも「説得術」「販売テクニック」「リーダーシップ」といったキーワードを基に書かれることが多いので、普段からなじみがある方もいると思います。一方で後者は、どちらかというと、
産学連携コラボレーションマネジメント（2）参加学生はSEになりたいと思うだろうか？
前回ご紹介した教育プロジェクトで不思議だったのは，IT企業から参加した見習いプロジェクトマネジャ(PM）が常駐ではなかったことです。メールとか週1回程度の参画だけで，プロジェクトが本当に回っているかどうか分かるんだろうか？私だったら，絶対できません。プロジェクト参加者の顔色を見たり，レビューでのしゃべり方を聞いたりしないと。成果物を前にしない進捗会議なんて無意味です。 IT企業から参加したPMは，PMBOKやEVMS(earned value management system)にこだわリ過ぎているように感じました。そんなメソッドが，本当に効果的なのか？こんな小さいプロジェクトにEVMSが効果を発揮するとは到底思えない。 開発規模が小さければ，問題は圧倒的に少ないのです。開発規模が大きくなると，要素の関係による複雑性は幾何級数的に増加します。だからできるだけ疎なサブシステムに分割します。そ
「走れ！プロジェクトマネージャー！」 > WBSと作業工数 : ITmedia オルタナティブ・ブログ
「新聞」とテレビを見なくなって１０年で、私が「失ったもの」、「得たもの」。（けんじろう と コラ…） 【休日ネタ】どこのどなただかわかりませんが、誠にありがとうございました。（抱き込め！ユーザー、…） 【休日ネタ】どこのどなただかわかりませんが、誠にありがとうございました。（抱き込め！ユーザー、…） 58冊＋α ～ オススメしたい本 COMPLETE（事務局だより…） 58冊＋α ～ オススメしたい本 COMPLETE（事務局だより…） Twitterを使っているとブログが書けなくなるのか（『ビジネス2.0』の…） 【ミッション】あの人にオススメしたい、この1冊 ～ 番長と遊ぼう！＝『GOOD to GREAT ビジョナリー カンパニー２ 飛躍の法則』 なのですが・・・（1/2）（破壊的イノベーション…） 【140文字】 Twitter つぶやきなのに 書き直し…お粗末（中村昭典の、気まま
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
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その1）
ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。 曰く、 この無駄な成果物を作らされているのはウォーターフォールだから あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから スケジュール後半になって追い立てられるのはウォーターフォールだから いつまでたっても品質が向上しないのはウォーターフォールだから 赤字プロジェクトが垂れ流されているのはウォーターフォールだから このプロジェクトがデスマってるのはウォーターフォールだから 偉大な（?）グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。 仕事ができないのは道具が悪いと
PMノウハウを組織的に共有する方法を考える ― 1/2 ― ＠IT情報マネジメント
株式会社プライド 執行役員 チーフ・システム・コンサルタント 大上 建（だいじょう たける）氏 前職で上流工程を担当する中、顧客の利用部門は必ずしも「開発すること」を望んでおらず、それを前提としないスタンスの方が良いコミュニケーションを得られることに気付き、「情報の経営への最適化」を模索することのできる場を求めてプライドに入社。株式会社プライドは、1975年に米国より社名と同名のシステム開発方法論の日本企業への導入を開始して以来、これまで140社余りの企業への導入支援を通じて、情報システム部門の独立自尊の努力を間近に見てきた。 前回の勉強会では、PMノウハウのえぐり出し、体系化、拡充会議を体験しました。PMノウハウが体系化できたら、それを組織的に共有していきます。組織的な共有方法の1つとして、有能者を早期に育成する手法があります。 最初は、関係者の間で合意形成を行います。関係者に、「PMノ
プロジェクトマネージャは社長――統合マネジメント
プロジェクトマネージャは社長――統合マネジメント：プロジェクトマネジメントスキル 実践養成講座（11）（1/2 ページ） 前々回「第9回 丸投げは失敗の始まり――調達マネジメント（1）」と前回「分からないまま進めない――調達マネジメント（2）」と2回にわたり、調達マネジメントの勘所を解説した。 そのポイントは、ベンダ任せではなく、発注者側もその選定・作業管理に積極的に関与していく「丸投げからの脱却」である。これは、一朝一夕に果たせるものではない。技術領域の細分化、複雑化する現在のプロジェクト環境、および、現業を抱える発注者側メンバーの時間的な制約など、さまざまな理由が考えられる。 しかし、ベンダに泣かされるのが嫌なら自分たちがしっかりするしかない。このことを忘れず、いま以上に一歩踏み込んでベンダマネジメントに取り組んでいただきたい。 統合マネジメントとは？ さて、当連載もいよいよ今回で最終
自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
プロジェクトメンバーを育てる3つの手法を極めよう ― ＠IT自分戦略研究所
■コーチングで引き出し、ティーチングで伝える ケーススタディは、システム開発プロジェクトにおけるOJTの場面を取り上げる。まずはプロジェクトの状況を確認することにしよう。 ・某金融機関の合併に伴う基幹システム統合プロジェクト。設計フェイズが終わり、これより開発フェイズに移行する。 ・スケジュールがタイトなため、開発メンバーとしてA君、B君の2人が増員されることとなった。 ・A君は新人研修を終えたばかりで現場に出るのは初めての経験。B君は3年目の若手社員で、今回が2つ目のプロジェクトである。 では、ある日の進ちょく確認の場面を見てみよう。 出来杉先輩 「では今週の進ちょくを報告してもらえるかな。そういえば、今日は○○モジュールの完成予定日だったね。これはほかの開発作業にも影響するので気になっているのだが……」 と、出来杉先輩の切り出しで始まった進ちょく確認において、○○モジュールの開発作業が
PMノウハウとは何か？──組織的ノウハウ共有の事例から ― 1/2 ― ＠IT情報マネジメント
株式会社プライド 執行役員 チーフ・システム・コンサルタント 大上 建（だいじょう たける）氏 前職で上流工程を担当する中、顧客の利用部門は必ずしも「開発すること」を望んでおらず、それを前提としないスタンスの方が良いコミュニケーションを得られることに気付き、「情報の経営への最適化」を模索することのできる場を求めてプライドに入社。株式会社プライドは、1975年に米国より社名と同名のシステム開発方法論の日本企業への導入を開始して以来、これまで140社余りの企業への導入支援を通じて、情報システム部門の独立自尊の努力を間近に見てきた。 会社の業務やプロジェクトの中で秀でた成果を上げる人がいますが、一般的な人と表面的に大きな差があるわけではありません。しかし、成果に違いがあるわけです。 どこが違うのかというと、各界有能者は、秀でた成果を上げる「ノウハウ」を持っているのです。短い言葉で表現され、絶大な
プロジェクトマネジメント技術を補う“ノウハウ”とは？
プロジェクトマネージャが足りない──。PMBOKなどのプロジェクトマネジメント技術は広まってきたが、逆にそれだけではプロジェクトを切り盛りしていくことができないことが指摘されるようになってきた。そのすき間を埋める“PMノウハウ”とは？ 深刻なプロジェクトマネージャ不足 IT化人材の不足を嘆く声はユーザー企業でもよく聞かれるが、当のIT業界でも有能なプロジェクトマネージャが少ないことがクリティカルな問題になっている。苦労して受注した数十のプロジェクトが稼ぐ利益を、たった1つの失敗プロジェクトの大赤字が吹き飛ばすことは珍しくない。また、失敗プロジェクトはITベンダの収益問題だけでなく、ユーザー企業にとっても収益機会喪失や顧客満足低下などを引き起こす重大な問題である。 従来、エンジニアリング業界の占有物と思われていた“プロジェクトマネジメント（PM）”についても、ここ数年IT業界でもPMBOKな
＠IT：明日からできるプロジェクト管理（3） ビルド管理を楽にするオープンソースツール一覧
プロジェクトマネージャ（＝PM）の石出さんは今日も悩んでいます。 開発チームのスタッフからさまざまな問題が石出さんの元に集まってくるからです。例えば、こういう感じで……。 「コンパイルができません。ライブラリが違っているようです。でもライブラリはちゃんとあるんです。なぜでしょうか？」。調べてみると単純なバージョンの問題だった。このような問題は最近多い気がする。オープンソースのプロダクトを利用し始めてから特に多い気がする……。 「その障害は最新バージョンでは修正されていますよ」あるいは「その障害はいまのバージョンでは再現しないので大丈夫だと思います」というスタッフがいる。このような状況ではまともに品質を管理できない。どうしたらよいのだろう。 こういうやりとりもある。 「○×機能が実装されていませんよ」「（担当している）Aくん、どうなっているの？」「すみません。最新のコードにしていませんでした
@IT:要求管理ツールの賢い使い方(要求管理ツールとWord&Excelとの違い)
これまでの連載では、ソフトウェア要求管理の基本を理解していただくことを目標にして、RUPにおける要求管理の成果物とワークフローを取り上げ、要求管理の基本を解説してきました。今回はいよいよ最終回です。本連載の締めくくりとして要求管理ツールについてお話ししたいと思います。 ［注］ 要求管理ツールを説明するに当たって、要求タイプ、要求属性、トレーサビリティといった用語が出てきますので、もしこれらの言葉がぴんと来ない場合は、まずは、過去の連載を読み返してから、今回の記事をお読みになられると分かりやすいと思います。 要求管理ツールとは？ 一般的に、要求管理（requirement management）ツールというと、開発チーム内で一元的に要求を登録、編集でき、その際に、変更履歴や変更理由を記録することができるツールを指しています。また、それらの基本的機能に加えて、要求ごとに、優先度・リスク・担当者
bpspecial ITマネジメント
今回は人物評価方法「STAR手法」を説明します。STAR手法とは、人間はとっさに過去の出来事を聞かれた場合、比較的うそをつく確率の少ない性質を利用して、近い将来のその人の行動パターンを予測する手法です。米国で、転職に伴う年俸を決めるために発達したものです。人間の性格は一生変化しないため、過去の行動パターンは同じ状況下で将来も繰り返されるということ、つまり、「人間、死ななきゃ直らない」を利用した方法です。 ちなみに、STARとは、Situation Theme Action Resultの頭文字で、過去のどういう状況下（S）でどんな行動テーマ（T）を見つけて、具体的にどう行動（A）して、結果（R）はどうなったか、の情報をもとに将来の行動を予測するというわけです。 次の図にその概念を示します。 人間は将来のことはいくらでもうそをつけますが、過去の事実は世間話として正確に聞き出せることが多いので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第6回：プロジェクトマネジメントにおけるリスクアセスメント (1/3)
[ThinkIT] 第2回：EVMの基本値から導出される値の説明と練習問題 (1/4)
http://www.keyman.or.jp/cgi-bin/navi/30001575/A18D0C/00900600/00900600/HUWZX3y2d/