多くのプロジェクトは、計画段階ですでに失敗している
多くのプロジェクトは、計画段階ですでに失敗している：情報マネージャとSEのための「今週の1冊」（38） 確実に目標を達成するためには、“PDCA”の“P”で考えるべきことがたくさんある。検討すべき項目を一つ一つ丁寧に扱い、もっと慎重にプランニングを進めるべきだ。 数年前、ある自治体のプールで、幼い少女が浄化設備の吸水口に吸い込まれて亡くなる事故があった。マスコミは「現場の危機管理に問題があった」と報じたが、それは間違っている。「問題は、『事故が起きたときの危機管理』ではなく、『ずっと前から吸水口の金網がはずれていた』という日ごろの管理にあったのだ。日本人は“危機管理が苦手”なのではなく、“管理自体が苦手”なのであって、危機的状況になるとそれが『バレる』だけなのである」――このように言われると、国や企業、さらにはプロジェクトチームまで、あらゆる組織のマネジメント、全てに当てはまるような気がし
危機コミュニケーション覚え書き - レジデント初期研修用資料
未知状況で安心を伝える 原発災害の当初、情報が錯綜して、不安になった。そんな頃に発信された、日本の原発についてのお知らせ という、英国大使館の現状に対する見解をまとめた文章を読むことで、大きな安心感が得られた 「ワーストシナリオとその対策を語る」こと、「今公開されている情報を吟味して、そこから導かれた見解を述べる」こと、「今までに発生した「本当の最悪」との比較を行ってみせる」ことが、未知の恐怖におびえている状況を安定化させるのだと思う 「大丈夫だ信じろ」という言葉では、安心感が得られない。「ワーストはこうだ。対策はできる」と言われると安心できる 「安全な最小値」と比較して何倍、という表現は安心につながらない。「本当の最悪と比較して何分の一」という言い回しは、同じ大きさを表現するにしても、安心感がある 根拠を示さずに「大丈夫です信じて下さい」を繰り返す人は信頼されない。すでに公開されている情
管理職になったときから気をつけていたこと - フジイユウジ::ドットネット
いや、異動したときに気をつけていたこと -今日のニッパウ という名エントリを読んだので、触発されて書いてみます。 あ、さらにタイムリーなことに リーダーが押さえておくべき１０箇条 -モチベーションは楽しさ創造から というエントリが出てますねｗ（12/17追記） 日々、部下に支えられ、、、というか支えられていないと転んじゃう僕なのですがｗ、人間的にも仕事人としてもイケていない僕を支えてくれる部下に恵まれております。 気をつけていることを「初心忘れるべからず」ということで書いておきます・・・とニッパウの小越さんの真似して書きたいところですが、実際は「管理職になる前から部下はいたけど、気づかいをできるようになったのは管理職になってから」だから、あんまり「初心」じゃないのです。 昔の部下の人、色々ごめんよ。ありがとう。 管理職になったときから気をつけていたこと （1）. 僕が「それをやる理由や意味
一流の研究者のマネージメント、２１の鉄則
一流の研究者の「先生」がいつも懐かしく語る、先生のさらに上のボスの話があります。戦後間もない時代に、学位を取ったばかりの先生を見いだしてアメリカに引き抜き、自由に研究をすることを許した、これまた伝説的な研究者です。先生はいいます： 「年度が終わる頃になると、彼は私に『今年お前が使ったコンピュータの利用料だ』とレシートを渡してくれたものです。年に２億円は使っていたでしょうか！」 これはケネディ大統領時代の話ですので、当時としては今以上に大変な金額です。当時世界にいくつも存在しない最新のコンピュータを、先生は独占的に利用でき、そのおかげで輝かしい業績が次から次へと生まれたのでした。 「しかしボスは一言も文句を言わないんですな。予算をとってくるのは自分の仕事。お前たちは研究をしろ、というわけでした。今の私がいるのも、あの人のおかげですな！」 科学者の世界も、お金と、権力と、事務作業と無縁ではいら
欲しいのは、PDCAサイクルが短い人 ― ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。 今回の内容は、リーダーシップトライアングルのManagementに関係します。Managementについては、連載第9回「ソフトウェアは目に見えない」を参照いただければと思います。 ■人材争奪戦争？ 私事ですが、このたび転職をしました。 新会社での私の役割の1つに、業務拡大に向けた人材採用があります
目的によって会議の進め方は違う。 5つの会議の進め方 - モチベーションは楽しさ創造から
コンサルタントの一番の仕事は「会議に出席すること」です。書類作成の時間を除けば、この作業時間が一番多いですね。クライアントさんの会議、お役所の審議会等を含めて、たくさんの組織の会議に出席する機会が非常に多いんです。 そんな中で、「会議上手の会社」と「会議下手の会社」というのが確かにあると思います。 「会議上手の会社」は短時間でテキパキと物事が決まっていき、「会議ヘタの会社」は時間ばかりが長くて、結局、何が決まったのか分からない形で終わってしまいます。会議上手の会社の会議では、終了後に、みんな充実した顔で、次の作業へのモチベーションアップを感じられます。一方、会議下手な会社の会議では、イスに座っているだけで、徒労感で社員さんのモチベーションが下がってきているのを感じます。「くだらない会議に付き合ってられないよ」と思う気持ちもよく分かります。 この２つの組織の最大の違いをあげろと言われれば、「
真髄を語る：重要なソフトは外注せず自分で作る
ソフトウエア開発の経験が全くない素人集団を率いて、100％外注に頼っていた、基幹業務を支えるソフトウエアを内製に切り替えるプロジェクトに取り組んだ。この時の経験から言うと、ゼロからのスタートであっても、5年間真剣に取り組めば、ソフトウエアを自社内で開発・維持する体制を構築できる。現在、本業そのものを支えるソフトウエアに関してまで安易な外注が進んでいる。基幹部分は他人任せにせず、当事者が自らの手で内製できる力を持つべきである。 「交換機を作っているコンピュータ・メーカーに、交換機のソフトウエアを自分たちの手で作りたいと言ったら、『我々が手を引いたらNTTなんて成り立ちませんよ。お分かりなんですか』と脅されたよ。頭に来たな。石井君、どう思う。今のままでいいのか」 日本電信電話公社の真藤恒総裁は初対面の私にこうまくし立てた。電電公社が民営化され、NTTになる直前のことである。大阪の現場にいた私は
真髄を語る：ソフトウエア開発の基本は不変
ソフトウエア開発の経験が全くない素人集団を率いて、100％外注に頼っていた、基幹業務を支えるソフトウエアを内製に切り替えるプロジェクトに取り組んだ。よいと言われる方法は色々試したが結局は「作業日報」を使う原始的なやり方が一番効果的であった。ソフトウエアの世界は日進月歩であるが、事業の根幹を支えるソフトウエアをきちんと作るには、オーソドックスに開発実績をきちんと把握することが基本である。内製化プロジェクトを通じて編み出したソフトウエア開発のポイントをまとめてみた。 ソフトウエアの特質およびソフトウエア開発に求められる要件についてポイントを整理してみた。いずれも、かつて筆者がゼロからソフトウエア開発に取り組んだ結果、得たものである。まずOS（基本ソフトウエア）といわれる「システムソフトウエア」と、直接顧客が利用する「アプリケーション（応用）ソフトウエア」に大別し、その要件をまとめておく。 シス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記