プロジェクト管理の現場で使用される、分かりにくい表現10選
プロジェクトを成功させるには、マネージャーやチームメンバー、利害関係者の間にしっかりとしたコミュニケーションが確立されていなければならない。そのためには、本記事で紹介している表現が本当に意味するところを押さえておくべきだろう。 コミュニケーション能力は、雇用者が従業員に求める資質として常に上位に挙げられている。しかし（筆者の経験によると）そういった資質はマネージャーに対してはそれほど厳しく要求されておらず、彼らの中には、一歩間違うと問題につながるようなスラングや、耳にのみ心地よい言葉を多用する者もいる。 相手の言葉を額面通りに受け取るのではなく、その言葉の本当の意味を理解する能力は重要である。以下では、プロジェクト管理の現場で使用される、分かりにくい表現を筆者自身の調査や経験に基づいて10個選び出し、解説する。 ＃1：余白を管理する（manage the white space） 「余白」
そして後ろから撃たれる
コンピューターは大好きだった。 学生の頃からサーバーとかプログラムをやってたおかげで、SIの会社に入社してからはちょっとしたヒーローだった。 寝る間も惜しんで働いて、案件を片っ端からざくざく片付けた。 元々スケジュールも厳しいので納期優先だ。みんなそれを望んでた。 適材適所に合わせて効果的な言語、環境、フレームワーク、ライブラリを選んで組み合わせた。 ライブラリやフレームワークにバグがあれば自分で直した。OSS万歳だ。 本もばりばり読んだし、勉強会にもたくさん顔を出した。 結果を残してきたつもりだった。 これがSEの生きる道だと信じてた。 そうして何年かが過ぎて、案件の山が落ち着いてきたころに異変が起きた。 周りが一斉に今まで構築したシステムが保守できないと言う。うわ。顔がマジで怖い。 遊び半分でシステムを作られても困ると言う。デザインパターンやフレームワークは趣味ですか。そうですか。 一
実務能力というのは段取りのうまさなんだと思うんだ - やまもといちろうBLOG（ブログ）
取りまとめなど一人でやる仕事って、土曜日が一番はかどる。連絡をすることもされることもなく、考えることに没頭できるから。 仕事を進める上で、とりわけ多くの人が関わる事案というのは、仕切る際に結構進め方にコツのようなものがある。これが分からないと厳しいと思うのだが、実際にはあまりそういうのに無頓着で、ただ単に金が儲かればいいとか、サービスが期日どおりリリースできればいいと考えるマネージャーも多くて困る。自分のことを棚に上げていうけどさ。 でも、立場も役割も機能も違う人たちを集めて、何がしかの結果を出さなければならない仕事というのは実に多い。取りまとめる際に、利害は対立するし、共通の認識は違うし、問題に対する考え方も違う。これはしょうがないのだけれども、そこにプロジェクトがあって、人が集うからには方法論をある程度ノウハウ化しておかないと話を進められないと思うんだけどね。 ちなみに、私がそういう事
RedmineやTracを上手に活用する6つのポイント
photo credit: Mackトラ ソフトウェア開発プロジェクトの現場では課題やバグ、タスクを管理するために、RedmineやTracなどのIssue Trackin System(課題追跡システム。以下ITSと表記)を使っていることが多いと思います。 ITSを使えばこれらの情報を一元化しプロジェクトメンバ間で共有できるため、うまく使えばとても役立ちますよね。 しかし、あまり深く考えずに導入すると、 「入力が大変だし余分な手間が増えただけだよ…」というメンバーからの不満の声 「この課題って本当に終わってるの？」といった疑心暗鬼 「このタスク、誰も進めてなかった！」という驚愕の事実が期限前日に判明 などといった状況に陥りがちです。 ここでは、いくつかのプロジェクトへ導入した経験から得た、ITSを運用する上で重要(と考える)な6つのポイントを紹介します。 ポイント1 チケット項目はマ
Redmineをスムーズに使うちょっと良い話 - komagataのブログ
Redmineのタスクの更新メール、自分に関係あるものだけ届くようにしてるんですが、複数のプロジェクトが平行して動いているのでいかんせん数が多い。（ミーティングが多い日などは１日でいきなり１００通超える） Gmailでj,kを使ってどんどん見て行くんですが、最近高速に処理するコツが分かって来た。 チケットメールを素早く処理するコツ 基本、（HTMLメールにした場合）このhr線から上だけを見て行けばサクサク処理できる。 ハマってるところで知ってることがあったら「たしかxxxってブログに乗ってましたよー」とか書く。 チケットの内容がよくわからない場合は「イミフ」とだけ書くと、チケット作成者が内容を見直すという合意をしておく。 チケット作成で繰り返し起きるコミュニケーションミスを減らすコツ 新規チケットを作る時にテキストエリアにデフォルトのテンプレを設定しておくと書かなきゃ行けないことがわかりや
デッドライン ソフト開発を成功に導く101の法則
正しい管理の四つの本質・適切な人材を雇用する。 ・その人材を適所にあてはめる。 ・人々の士気を保つ。 ・チームの結束を強め、維持する。 （それ以外のことは全部管理ごっこ） 安全と変更・変更は、あらゆるプロジェクトの成功のために（ほかの大抵の物事についても）必要不可欠である。 ・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。 ・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。 ・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。 負の強化・脅迫は、結果を上げさせる手段としては不完全である。 ・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。 ・さらに悪いことに、目標を達成できなければ、脅迫の内
プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ - プログラマの思索
随分前だが7月初めにPFP関西WS#19が開かれた。 ワークショップの内容は「ファシグラ」。 【1】ファシグラはファシリテーショングラフィックの略語で、議論の見える化を目的として、A4用紙又は模造紙へプロッキーを使って議論を描いていく手法。 ワークショップでは西河さんの解説がとても分かりやすく、実際に描きながら試すことができた。 議論の内容を議事録にまとめたり、内容をまとめて更に議論を深彫りしていくのは難しい。 議論が白熱すると、あらぬ方向へ議論が行って本来の問題解決につながらなかったりする。 アイデアを出しながら企画を組み立てようにも、アイデアがなかなか出ない雰囲気だったり、アイデアが散発的でつながりが見えにくかったりする。 そんな時にファシグラはすごく有用だ。 僕が改めてファシグラの威力を感じたのは、えと～さんが実際にファシグラを使っている場面を見た時だ。 ミーティングで到達すべきゴー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
