プロジェクト・マネジメントの能力は何で決まるか | タイム・コンサルタントの日誌から
先週からまた、大学で行う週一回のプロジェクト・マネジメントの講義が始まった。準備にはそれなりに手間がかかるが、それでも、授業自体は楽しい仕事だと思う。わたしはなるべく、大学の講義をインタラクティブにやろう、と心がけている。単なる一方的な講義形式では面白くないし、自分が学生だった頃のことを思い出してみても、そうした授業で頭に残った事は少ない。 教育とか研修は、それを受けた後で、自分自身の行動が変わらなければ、ほとんど価値がない。学びとは、自分の能力を高めるために行うものだ。単に知識が増えただけで、自分の行動に変化がなければ、何かを学んだことにはならない。だから、せめて授業の間は、なるべく学生に考えてもらい、また、手を動かしてもらうようにしている。インプットだけでなく、何かアウトプットしてもらうことで、相手の理解も測れるからだ。 そしてもちろん、一番良いのは、質問をしてもらうことである。ただ、
プロジェクト・コミュニケーションのベーシック 〜 情報のトレーサビリティを確立する | タイム・コンサルタントの日誌から
英語のCommunication と、日本語の「コミュニケーション」という言葉には、微妙なニュアンスの違いがある。わたし達が会話で「コミュニケーションが良くなった」などと語る場合、ふつうは双方向の意思疎通を意味している。「前の課長は向こうが一方的に命令してくるだけだったが、今度の課長はちゃんとコミュニケーションができるよな」という風に。もっと柔らかい言い方をすれば、『ふれあい』みたいな、感情面での同調というニュアンスを含む。 ところが英語のCommunicationは、原則として情報の伝達を意味している。それは、たとえ一方向でも成立する。だから、TV局が電波で大勢に向けて一方的に情報を発信する様な仕組みを、英語ではMass Communicationとよぶ。これは日本語でマス・コミュニケーションとなり、いつものように発音しやすい4文字言葉化して「マスコミ」になった（口頭では、コミュニケーシ
B2B企業にイノベーティブなITは可能か | タイム・コンサルタントの日誌から
あなたは、ある中堅SIerの開発部長だ。会社は受託システム開発をなりわいとしており、有名ではないが堅実な経営を続けている。そんなあなたはある時、突然社長に呼ばれて、こう言い渡される。 「君には明日から、わが社のCIOになってもらいたい。これまで外の顧客の仕事をずっとしてもらってきたが、明日からは経営者の一員として、わが社の情報システムを見てもらうつもりだ。紺屋の白袴じゃないが、我々の社内IT利用は、十分とは言えない。君には是非とも、これまでの外販の経験を活かして、イノベーティブなITの仕組みを作ってもらいたい。単なる業務の効率化だけではなく、新しいビジネスを生み出せるようなITの仕組みを、だ。」 経営者の一員、すなわち役員に抜擢された訳だ。とても誇らしい気持ちになる。しかし社長室を出て自分の席に戻ると、あなたはだんだんと大変な役回りを引き受けたらしいことに、気づき始める。わが社にとってイノ
トラブルには技術的原因と、マネジメント的原因がある | タイム・コンサルタントの日誌から
トラブルの原因分析について、このところ2回にわたって考えてきた（「熱気球の浮上、または原因分析のシステムズ・アプローチについて」・「経験から学びすぎることの危険 ～ゆらぎある事象の原因分析について」 ）。原因分析の手法にこだわっているのは、それが「学び」と「成長」の鍵だからである。自らの能力を向上させ、成長するためには、仕事の結果（成果）から学ぶべきだと、わたしは信じている。個人も、組織集団も、である。 仕事の結果としてトラブルが生じたら、そこから素直に学ぶ。成功からも学べるが、失敗から学ぶ方が、記憶に強く残るからだ。そして（当然ながら）すべてに成功できる人なんていない。あの本田宗一郎だって、「自分は失敗ばかりしていた」と言っているくらいだ。他人から見たら成功でも、自分ではそこに足りない点を見る、というのがこの経営者の卓越した点だったのだろう。 さて、繰り返すが、『根本原因』Root Ca
プロジェクトにおけるスケジュールと費用のトレードオフを考える | タイム・コンサルタントの日誌から
9月にスケジューリング学会で「プロジェクトにおけるスケジュールと費用のトレードオフを考える」というタイトルの講演発表を行った。わたしがこの何年間か個人的に続けている『リスク基準プロジェクト価値』（Risk-based project value = RPV）分析の手法を用いて、スケジュール・リスクのコスト化という問題に初めてくさびを打ち込んだ研究の発表である。サイトに書くにはやや理屈っぽい話であるが、小さな学会でもあったので、ここにその要旨を（数式は極力飛ばして）再録する。 =================== 日揮株式会社の佐藤です。本日は「プロジェクトにおけるスケジュールと費用のトレードオフを考える」というタイトルで発表させていただきます。 皆さん、ちょっとこういう問題を考えてみてください。皆さんはあるプロジェクトのプロマネです。このプロジェクトは全体納期に対して、1日10万円の遅延
JUAS『ソフトウェアメトリックス調査2014』を読み解く | タイム・コンサルタントの日誌から
「何だこのグラフ。点がバラバラに散らばってるだけじゃないか。」 －－そんな反応が多いだろうと思う。一応斜めに直線を引いているけれど、点はその線上から、ほとんど倍半分のいきおいでずれている。無理やり引いているだけで、法則性があるとはとても言えないな。誰だよこんなグラフ作ったの・・。 だが、このグラフ、わたしはとても面白いと思う。これは、「一般社団法人 日本情報システム・ユーザー協会」、通称『JUAS』が独自に行った調査の結果をグラフにしたものだ（JUAS発行「ソフトウェアメトリックス調査2014」p.66よりスキャンして引用）。グラフの横軸は情報開発プロジェクトの全体工数。単位は人月だ。そして縦軸は、プロジェクトの全体工期（＝期間の長さ）で、単位は月数である。図上に散らばった多数の点一つ一つは、個々のプロジェクトを表す。 なお、よく見ると横軸は一定間隔ではない。10の隣が100、一つおいて5
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
