わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
開発環境を学ぶということ (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 先日、稚北東京サテライトで客員教授会があったのですが、テーマの1つが「システム開発を学ぶ」というものでした。 すぐに気づくのは言語や実装方法を教えるだけでは足りないということです。Java開発を覚えるのであれば、Java言語を覚えるとかJavaEE（JSP、Servlet）とか、あるいはStrutsやSpringといったフレームワークというのは大きな一歩ではありますが、それだけでは足りません。 RUPにおける作業分野定義 RUPのdiscipline（作業分野）では、次の9つが定義されています（WikipediaのIBM Rational Unified Processより）。 Engineering Disciplines: * Business modelin
[ThinkIT] 第3回：プロジェクト進捗状況を「見える化」する (1/3)
見える化がなぜ必要かを語った第1回、アイデアや思考をどのように見える化するのかを語った第2回、続く第3回ではプロジェクトの現状を把握する「プロジェクトの見える化」について解説する。第1回でシステム開発現場における混乱の原因の1つとしてあげられている「ソフトウェアの開発状況（進捗）が目に見えない」ことを解決するための見える化手法である。 タスクかんばんやバーンダウンチャート、にこにこカレンダーについては、第1回でも触れられているが、より詳しくそれぞれの目的と効果を解説する。 タスクかんばんは、タイムボックスマネジメントという考えに基づいて作られている。開発に限らず、プロジェクトには必ず存在する何らかの期限（顧客への納期、製品リリース日、広告の出稿期限など）を一定期間（タイムボックス）を単位として区切り、タイムボックスごとに、進捗を見極め調整をはかるチェックポイントを置く。 チェックポイントを
ウノウラボ Unoh Labs: チームリーダーが心掛けるべき10のポイント（テストチーム編）
こんにちはー！ やまもと＠テスト番長です。 現在ウノウのテスト専任のスタッフは自分一人です。 いわば一人親方（建設業界用語）状態なのですが、 前職では総勢6人のテストチームを組織しておりました。 その頃心掛けていた、チームリーダー心得を書いてみたいと思います。 1.聞き上手になる 組織はコミュニケーションが命です。 話しにくいリーダーだと、必要な情報がうまく伝わりません。 気軽に相談を受ける・噂話が耳に入ってくるようでなくてはいけません。 そのためには聞き上手に徹すること。特に批判的な態度は控えることが重要です。 そんな相手には、誰も何も相談しないでしょう。 2.「おいしい仕事」を独り占めしない。 重要な判断や、やりがいのある仕事はなるべくメンバーに廻すようにします。 一見、重要な仕事はリーダーがこなすべき事のように見えますが、 その裏で他のメンバーがつまらない仕事ば
「技術トレンドのおさえ方」を開発の現場に寄稿 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 開発の現場 vol.006（2006年10月発売）の特集「はじめての開発リーダーToDoリスト」において、「技術トレンドのおさえ方」を寄稿しました。 つけていただいた副題は、 3つの力「見極める」「説明する」「活用する」で"使えるもの"を的確に把握しよう 少しだけイントロを。 優れた新しい技術をたくさん知っていれば技術を「おさえる」ことができるようになるのでしょうか。それは残念ながら違います。それに、それだけの技術情報をすべてチェックすることは難しいでしょう。 自動車業界を例に考えてみましょう。優れた最新の技術を結集したものの代表といえばF1カーが思い浮かびます。F1カーで使用する優れた技術を知っているというのは良いことです。膨大な労力をかけて得たその知識は大変貴重な
「ソフトウェア開発の名著を読む」を読む
「めいちょ」と銘打たれるとなかなか手が出せないもの。大著であることも多いし、何より難しそうなイメージが先行してしまう。さらに、たいていは「古典」…なので、書店で平積みになってる賞味期限 1 年のハウツー本みたく目に入ってこない（←こちらからアプローチをかけないと手に入らない）。 というわけで敬遠していた方へ朗報。「ソフトウェア開発の名著を読む」で手軽に「めいちょ」の品定めができる。この手のカタログ本だと、「コンピュータの名著100冊」が有名だが、これはたったの8冊の紹介、しかも新書なので30分で読める。 しかも、言語は問わない。もちろん FORTRAN や Pascal といった「古語」のコードが出てくるが無問題。伝えたい何か、例えば「プログラミング作法」や「よいコードを書くための習慣」を表現するための、レトリックとしてのコードなのだから。 とどめは、昔から、誰からでも、何度でも指摘されて
プロジェクトは失敗するのが当たり前！？ ― ＠IT情報マネジメント
ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16％。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16％だったという。 日本においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」（社団法人 日本情報システム・ユーザー協会）に調査によれば、システムの仕上がりに満足と回答したユーザーは10％前後に
プロジェクトマネジメントとプロジェクトコントロール (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと前の記事ですがnikkeibp.jpの"マネジメントとコントロールは違う"が面白かったです。 プロジェクトコントロールとは失敗しないようにすること 企業のリスクマネジメントの話なのですが、次の マネジメントの意味は、do right things、正しいことをする、である。これに対し、コントロールは、do things right、事を正しくする、である。 話を思い切り単純にして進めれば、マネジメントは企業が成長していくための活動であり、コントロールは企業が失敗しないための活動である。アイデアをうまく育て、売れる商品を作り出した企業は、マネジメントされていたことになる。逆に、製造現場をうまくコントロールし、高品質の商品を作ったとしても、それが顧客に受け入れら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ザ・プロジェクトマネジャーズ
TRICHORD