ブックマーク / brevis.exblog.jp (30)

  • 埋没コストの原理、または撤退の判断はなぜ難しいか | タイム・コンサルタントの日誌から

    前回は、落雷で止まってしまった電車の中で、再開を待ち続けるか別のルートを探しに行くべきか、という状況に絡めて「ストップ・ロス・オーダー」という概念を紹介した(「ストップ・ロス・オーダーと撤退の知恵」参照)。じつは、この言葉を知ったのは古いけれども、別に株式投資FXをやる訳でもないわたしにとって、しばらくは縁の薄い概念だった。あらためてこの問題を気で調べ始めるようになったのは、プロジェクトの撤退判断、すなわち『Go or no-go問題』を考えるようになってからである。 エンジニアリングや受託開発のSIerなど、受注型プロジェクトに主に従事している会社にとっては、プロジェクトの中断撤退判断など、通常は問題にならない。赤字を出そうが納期に遅れようが、歯をいしばって何とか最後の納品までたどりつくのが当然の事だ、とみな信じている。なぜなら、納品できなければ支払も得られないからだ。仮に今、予算

    埋没コストの原理、または撤退の判断はなぜ難しいか | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/09/09
    RT 『埋没コストの原理』とは、すでに使ってしまったコストは、現時点での判断に組み入れるべきではない、という経済学上の原理である。もはや過去という時代に埋没したコストは忘れて、この先の事だけを見て判断する
  • ストップ・ロス・オーダーと撤退の知恵 | タイム・コンサルタントの日誌から

    渋谷から東横線の各駅停車に乗った。たしか都内での研究会か何かの帰りだったと思う。ふだんは急行か特急に乗るのだが、その夜は何だかくたびれていたので、多少すいていた各停で座って帰ろうと思ったのだ。ところで、渋谷では穏やかな夜空だったのに、電車が5つめの都立大学駅に着く頃から、雷とともに急に激しい雨が降り始めてきた。折りたたみの小さな傘しか持っていない。でも、初夏の夕立だろう、いずれすぐやむにちがいない、と高をくくっていた。 しかし、電車は都立大の駅に停車したまま、ちっとも動き出さない。ホームに降り注ぐ雨は、しぶきとなって開け放たれたままのドアから車内にも吹き込んでくるようになった。しばらくしてから車内アナウンスで、「信号系統への落雷のために、全線がストップしております。復旧作業中ですが、まだしばらく時間がかかる見込です」という。外は相変わらずのひどい雨が続いている。ほんの通り雨という感じではな

    ストップ・ロス・オーダーと撤退の知恵 | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/09/07
    日頃の練習が大事 RT ある方針を決めて、それで動けた事が良かったのだ。もし結果が失敗だったら、それが何回も続いたら、ストップ・ロスの基準を見直せばいいのである
  • 新任リーダー学・超入門(2) マネジメントとリーダーシップというコトバに気をつけよう! | タイム・コンサルタントの日誌から

    Sさん、丁寧なご返事ありがとうございます。おっしゃるとおり今日の企業は、規模の大小を問わず、設計・製造工程のいろいろな部分を外注に頼っていますね。だから、新人の頃から「人を使う」立場で動かざるを得ない--Sさんのお言葉を借りれば、“技術を極めることを最初から半分あきらめざるを得ない技術者”である訳です。じゃあ最初から「人を使う」マネジメント職として育ててくれるかというと、そうでもない。とても中途半端な育て方じゃないかと憤懣をもたれるのも、当然かもしれません。 前回の『新任リーダー学・超入門』にも書きました通り、「リーダーシップ」というのは、くせ者の言葉です。そして最近流行りつつある「マネジメント」も同じくらい危ない言葉でしょうね。サン=テグジュペリの「星の王子さま」には、たしか“言葉とは誤解を生み出すもと”だ、といったセリフがあると思うのですが、とくに外国生まれの言葉には気をつけた方がいい

    新任リーダー学・超入門(2) マネジメントとリーダーシップというコトバに気をつけよう! | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/06/17
    実務翻訳のお供に
  • 「責任」には三つの意味がある | タイム・コンサルタントの日誌から

    震災の後の4月に、知人たちと話していた時のこと。話題はおのずから福島原発の事故処理のことになった。原因は何か、どうクールダウン処理すべきか、また地域への被害をどうするか。そのうち、一人がこう発言した。「東京電力は法規則どおり原発を建てて運転し、地震後も政府の指示どおり対応したんだから、全責任を負えというのは無理がある。」 しかし当然ながら反論・異論も相次いで、議論はホットになっていった。政府(省庁)の過去の責任はどうか。あるいは政治(閣僚)の責任の軽重はどうあるべきか、いや、そもそも電力会社の過失はどこにあったのか、等々。ただ、話しているうちに、当の発言者の論点は、地域への賠償問題だということがはっきりしてきた。国も共同責任で補償すべきか、プラントのメーカーは責任がないのか、ということだ。すると、この分野に詳しい同僚が一言、「原子力賠償制度は無過失責任ですよ。」と発言した。 無過失責任とは

    「責任」には三つの意味がある | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/06/10
    RT 三種類の責任概念は、英語ではそれぞれ別の言葉で表される。それが、Responsibility, Accountability, Liabilityである
  • 生産スケジューラ(APS)はERPと併用するべきか | タイム・コンサルタントの日誌から

    最近、二人の方からよく似た質問を、別々の機会にいただいた。内容は、生産管理システムと生産スケジューラの連携についてである。10年前に「革新的生産スケジューリング入門」を上梓し解説した自分としては、なぜ今さらこの質問、と思わないでもない。だが近年、生産管理関係の書籍や情報は、トヨタ生産方式やジャスト・イン・タイム(JIT)流の現場カイゼンの解説が全盛だった。経済ジャーナリズムも、基的だが地味な生産システム関係の話題はあまり扱わず、マクロな経済不況への嘆きか、ミクロな現場の職人技の賛美を報じたがる。生産システムはマクロとミクロの中間に位置するメゾスケールの問題のため、実務経験のない文系記者達には扱いにくい題材なのだろう。だから、こうした、ある意味でいろいろな製造業に共通する問題が見えなくなっているらしい。 その質問の内容だが、知人のコンサルタントからいただいたのは、「APSはMRPとともに用

    生産スケジューラ(APS)はERPと併用するべきか | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/05/31
    この人の専門分野の話。S/Wに引きつけて理解する際には、やはり注意しないといけない。
  • 新任リーダー学・超入門 その1 | タイム・コンサルタントの日誌から

    Sさん。昇格おめでとうございます。お知らせをいただいたのに返信が遅くなって申し訳ありません。 いよいよ「リーダー」格になられたわけですが、この1ヶ月間のご感想はいかがですか。思ったより面白い、とか、思ったほど仕事の中身は変わらなかった、とか、感じ方はいろいろあると思いますが、ともあれ「マネジメント」職に一歩、踏み出されたわけです。 それにしても、「リーダー」という職名は不思議なものです。わたしの業界では「リード・エンジニア」という言い方をしますが、まあ実質は同じです。課長とかマネージャーではない。でも、責任ある立場で、後輩をまとめる仕事を任されます。小さな案件ではプロジェクト・リーダーとして、直接顧客と折衝する必要にも迫られる。つまりリーダーとは、管理職手当の付かない、しかも残業代はしばしばサービスさせられる立場に与えられた名前だ、と皮肉混じりにおっしゃりたくなる気持ちは分かります。 リー

    新任リーダー学・超入門 その1 | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/05/26
    マネジメントを否定するつもりはないけれど、欲しい結果だけを指示する人という言葉の単体での響きはなんとも... RT 「そんなことは自分で考えなさい。貴女はプロの女優なんだから。」--これが「マネジメント」の答
  • トラブルの「技術的解決」と「マネジメント的解決」はどう違うか? | タイム・コンサルタントの日誌から

    マネジメントとは「人に仕事をしてもらう」ことであり、その仕事の最小単位を『アクティビティ』と呼ぶ、ということはすでに何度か書いた。アクティビティを規定する要素としては、アウトプット、インプット、リソース、完了条件(納期)、そして指示情報と報告情報がある(「仕事の最小単位--アクティビティの構造を学ぶ」参照)。また仕事をちゃんと動かすために、コスト(Cost)、時間(Time)、リソース量(Resources)の3種類を、基的なパフォーマンス指標として用いるべきことも説明した(「仕事の最小単位(2)--アクティビティのパフォーマンスを測る」)。 さて、仕事をマネジメントするためには、もう一つ必須の事柄がある。それが問題解決である。どんなお仕事にも、問題の発生する可能性はつねに存在する。アクティビティで問題が発生した時、頼まれた側がすべて自分で即刻解決できればベストだ。だが、そうも行かない場

    トラブルの「技術的解決」と「マネジメント的解決」はどう違うか? | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/05/22
    モデルケース過ぎてちと格好よすぎる。「技術的バックグラウンドの強い人ほど、どんな問題も技術的に解決しようとしてしまう」なのは自戒も込めて。でも裸の王様問題は残るよねぇ。
  • 仕事のレポートはこう書こう | タイム・コンサルタントの日誌から

    ときおり、大学教育の意義は何だろう、と考える事がある。昭和の時代には大卒はホワイトカラー、高卒その他はブルーカラーという区分があったが、この境目は平成以降、次第に曖昧になってきている。それでも大学を出ることで、出なかった者と何ほどかの違いがあるとしたら、どのような点だろうか。まさか専門知識の有無ではあるまい。工学部を出たってすぐ設計はできないし、法学部や文学部で学んだ知識を企業が期待しているは思えまい。それでも、青年期の4年間を大学で過ごすことで、教育上得るものがあるとしたら、それは何か。 もしかしたら、それは多少なりともちゃんとした長さのレポートを、何度も繰り返し書かされることかも知れない。期末レポートや中間レポート、実験レポートから卒論まで、大学ではずいぶんレポートを書かされる。そして企業では、大卒の人間はそれなりに「考える仕事」を要求される。その“考える”ことの大事なプロダクト(成果

    仕事のレポートはこう書こう | タイム・コンサルタントの日誌から
  • 安全第一とはどういう意味か | タイム・コンサルタントの日誌から

    ある時、友人がやってきて「車を2,3日貸してくれないか」という。小規模な引越をしたいので車が入り用なのだという。レンタカー代ほどではないが借り賃も払うから、といって謝礼を菓子折と一緒に置いていった。 さて、数日たって友人が返しに来た車を見て驚いた。フェンダーから左のボディにかけてへこみが入り、サイドミラーも折れている。どうして、と聞いたら「左折時に不注意で障害物に引っかけてしまって」という。そして、「すまんすまん。でも、車両保険には入っているんだろ? たいしたことはないから、すぐ直るよ。事故は一定の確率で起きるもんなんだ。」・・そんな風に友人が言ったら、あなたなら、何と答えるだろう? 「いや、車なんか大丈夫。それより君に怪我がなければ、何よりですよ。」こう答えられるほど、寛大な度量はわたしには、無い。たぶん頭に来て、「馬鹿野郎! 人の車を事故っておいて、その言いぐさは何だ。確かに保険にゃ入

    安全第一とはどういう意味か | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/04/04
    情けは人のためならず、みたいな話、RT 安全第一とは、借りたリソースは可能な限り無傷で返せ、という意味である
  • 「ITって、何?」 第16問 ITビジネスの成長のパターンってどうなっているの?(2/2) | タイム・コンサルタントの日誌から

    ・IT産業界の構造 「なんだかため息が出てきちゃった。長々と生態学をご説明いただいたけれど、だから結局何なのよ?って感じ。話の筋道が見えないんですけれど。」 --これからが題さ。 ここで、IT業界の企業ランキングを調べてみる。2009年度の情報サービス業のランキングで上位20傑を選び出して、横軸に順位を、縦軸に売上高をプロットしてみたんだ。ちょっとそこの書類鞄あけてみてくれる? うん、その一番上にあるやつ・・つまり、こういうものだ。 <図15-1 情報サービス企業の売上規模と順位の関係> 「なにこれ・・変なグラフねえ。横軸が1から始まってるのに、その次の目盛りが2じゃなくて10になってる。そのつぎが100だわ。縦軸もなんだか10倍刻みね。だいいち、これって横軸にゼロがないじゃない?」 --こういうのを両対数グラフというんだ。まあ、あまり理科系で実験をやる人以外は使わないだろうけど、ふつう

    「ITって、何?」 第16問 ITビジネスの成長のパターンってどうなっているの?(2/2) | タイム・コンサルタントの日誌から
    nakagawamakoto2007
    nakagawamakoto2007 2011/02/25
    RT IT作りはどこか建築によく似ている。しかし、産業の構造を見る限り、両者には明らかな違いがある。片方は分岐増殖型で、片方は弱肉強食型のモデルになっている