中堅エンジニアのための経営戦略入門 | タイム・コンサルタントの日誌から
Kさん、お久しぶりです。ご無沙汰しておりましたが、何年ぶりかで本社に戻られたとのこと。お元気そうで何よりです。 普通の人なら「本社にご栄転」おめでとうございます、という言葉遣いをするところでしょうが、それでは工場より本社の方が「上」である、という意味になりますね。わたしは本社も工場も企業組織の一部であって、それぞれ役割が違うだけだと考えているので、あえてそうは申し上げません。それに、本社への異動が栄転なら、以前Kさんが工場に移動されたのは左遷だったということになってしまい、ますます不適当ではありませんか。 まあそんな事はともあれ、本社の製品企画部門に移られて、あらためて「製品戦略とはいったい何か？ 何をどう考えるべきか？」という、真ん中直球の問いが頭の中に生まれた、というあたりが、とてもKさんらしいと感じました。たしかにおっしゃる通り、戦略立案が本社の重要な機能であることは多くの人が感じて
見えない非効率 ー 今、動いているんだからいいじゃないか | タイム・コンサルタントの日誌から
新任の取締役が、あるとき担当する事業部の支社を見に行った。一通り見学し、支社長らと懇談した後、かえろうとしたら、ある部署だけ灯りがついているのを見つけた。現場仕事はもう終業しているのに、管理部門の1セクションだけ、忙しそうに机にむかって仕事している。 「何をしているの？」と彼がたずねたところ、「本社に送る書類を作成しているんですよ。毎月、数字をまとめて送らなけりゃいけないんで、残業になるんです。」との答えだ。資料を見て、さらにたずねる。「本社は、この統計資料を見てどう役立てるんだろう？」「・・存じません。本社にたずねてください。」 その取締役は本社に戻ると、早速、送付先の企画部門にいって、その書類のことをきいてみる。すると、「ああ、その書類ですか。工場が毎月送ってくるんでね、ファイルして保管しているだけです」という。「でも、なんで工場はその書類を送ってくるのかな？」「さあ・・。」 いろいろ
トラブルには技術的原因と、マネジメント的原因がある | タイム・コンサルタントの日誌から
トラブルの原因分析について、このところ2回にわたって考えてきた（「熱気球の浮上、または原因分析のシステムズ・アプローチについて」・「経験から学びすぎることの危険 ～ゆらぎある事象の原因分析について」 ）。原因分析の手法にこだわっているのは、それが「学び」と「成長」の鍵だからである。自らの能力を向上させ、成長するためには、仕事の結果（成果）から学ぶべきだと、わたしは信じている。個人も、組織集団も、である。 仕事の結果としてトラブルが生じたら、そこから素直に学ぶ。成功からも学べるが、失敗から学ぶ方が、記憶に強く残るからだ。そして（当然ながら）すべてに成功できる人なんていない。あの本田宗一郎だって、「自分は失敗ばかりしていた」と言っているくらいだ。他人から見たら成功でも、自分ではそこに足りない点を見る、というのがこの経営者の卓越した点だったのだろう。 さて、繰り返すが、『根本原因』Root Ca
マネジメントとリーダーシップはどう違うか | タイム・コンサルタントの日誌から
大学でプロジェクト・マネジメントを週1回教えていることは前にも書いたが、授業は毎回必ず、前回の復習と、学生から出た質問への答えからはじめることにしている。出席シートに質問欄を設けて、そこに気になったことへの質問をかいてもらうのだ。むろん授業でも最後に「質問は？」ときくのだが、だいたいの学生はなぜかその場では質問せずに、紙に書いてくる。 いろいろ出た質問の中から、いつも「本日のBest Question」を選出し、その質問者の名前を明示してほめることにしている。良い質問を考えることは、単に回答を考えるよりも、ずっと価値があるからだ。一般に、マネジメントの問題には正解がない。正解がない中で、自分で考えて決めていかなくてはならない。これは、たくさんの正解を覚えてどれだけ早く答えるかを競ってきた東大みたいなところでは、とくに大切だ。 さて、「マネジメントとは何か」という授業をやった後で、面白い質問
決めない人々 | タイム・コンサルタントの日誌から
請負契約の仕事を長年やっていると、プロジェクトの成功・不成功はかなりの程度まで、顧客の性格に左右されるなあ、という感想を持つようになる。性格と呼ぶのは不正確かもしれない。個人個人の人柄の問題というよりも、顧客が組織文化として持っている性質である。それは端的には、「タイムリーに決断できる」か、「なかなか決断できない」か、という違いだ。 なかなか決断してくれない顧客に当たると、大変である。プロジェクトでは判断に迷うケースがいくらでも出てくるからだ。どんな設計も完全ではないし、市場の環境条件は変化するし、ユーザニーズも変わるし、法規制だって変わりうる。「ライバルが革新的な技術を出してきた」「現状を調べてみたら昔の設計図とかなり違っていた」「製品の販売予測が計画当初よりも弱気になってきた」「エンドユーザが操作法の変更に強く抵抗している」・・・『では、どうするべきか？』というのが、プロジェクト遂行途
顧客の顧客を知り、上司の上司になって考える | タイム・コンサルタントの日誌から
『顧客の顧客を知れ』－－これは、わたしの敬愛する大先輩である、経営コンサルタント・今北純一氏から、何年も前にうかがった教訓だ。自分の顧客が誰かは、誰でも一応知っている。顧客が何を望むか、そのニーズや要求も、直接・間接に伝わってくる。だが、顧客がなぜ、それを求めるかについては、必ずしも理解できていないことが多い。 しかし、顧客も、彼ら自身にとっての顧客からの要望になんとか対応すべく、いろいろ考え、悩み、そして動いているのだ。だから、『顧客の顧客』をよく知れば、自分の直接の顧客のニーズをつかむのに役立つ。たいていの人は、顧客の顧客までは考えた事がないが、そこまで視野と想像力を広げられるかで、競争力は大きく変わりうる。 たとえば、今北さんは自著「Carpe Diem － ビジネス脳はどうつくるか」（文藝春秋、2006）で、工場の立地問題について、こんな例をあげられている。鉄鉱石を産出する資源会社
タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない
さる8月、翔泳社主催の「PM Conference 2008」に招かれて講演をした。テーマはプロジェクト・コントロールの技法論で、私が長い間、エンジニアリング業界とIT業界の二足のわらじを履いてきた経験から、両者の比較を論じたものだった。最近のIT業界における「プロジェクト・マネジメント」の認識の普及進展はめざましいものがある。これに対して、エンジニアリング業界は過去10年以上、EVMSの徹底化以外とくに主立った進歩はない。にもかかわらず、両者の違いはいまだ歴然としたものがあり、それはとくにプロジェクト・コントロールの基本であるWBSやコントロール・リストなどの使い方で明瞭だ、というのが論旨だった。 ところで、この講演の中で、「工程表のガントチャートをExcelで書いてはいけない」と強調した点が、どうも多くの聴衆の注意を引いたらしい。終わってからのアンケートでも、そこに関する感想が少なくな
社長で会社は決まる、のか？ | タイム・コンサルタントの日誌から
以前から読まれている方はお気づきのことと思うが、このサイトでは個別の会社批評や経営者論は、まったく書かないことにしている。本サイトの記事は、外部からは「経営」とか「ビジネス」に分類されることが多いが、特定の会社や経営者の批評をしない点が、たぶん他との一番の違いかな、と思う。ついでにいうと、ビジネスマンの居酒屋トークでもっとも好まれる話題の一つは、よその経営者批評だろうが、懇親会や飲み会で人と話すときも、その種の話題のときは、わたしはずっと黙って聞き役に回ることにしている。 数ヶ月前、昔からの友人と一緒に飲んだときにも、日本を代表する超有名企業S社の業績不振が話題になった。というのも、彼はその会社に長らく勤めた後で、少し前に辞めたばかりだったからである。抑えた口調だったが、業績悪化の理由は経営者にあった、と彼はいう。かつて自分が勤め、また好きでもあった会社を、外人社長がいかに壊していったか、
プロジェクト・マネジメントの教育について | タイム・コンサルタントの日誌から
先日、わたし自身が主査を務める研究部会で『プロジェクト・マネジメントの教育について』という講演をさせていただいた。過去何年間かにわたり、 大学・大学院・自社・他企業などで試行してきたPM教育カリキュラムの内容と課題について、ディスカッションしたいと考えたからだ。当日は普段の倍以上の方が来場され、この問題への関心の高さがあらためてうかがえた。遠くは岩手から参加された方もいたが、都合の合わなかった読者もおられると思い、ここにその一部をご紹介しよう。ちなみに、会の名称は「プロジェクト＆プログラム・アナリシス研究部会」といい、スケジューリング学会の下部組織だが、とくに学会員でなくても自由に参加できるオープンな組織である。 当日の発表内容は、前半が「大学におけるPM教育の実践例から」ということで、主にカリキュラムの内容の話、後半が「PM教育のあるべき仕組みを考える」で、わたしの今の考えを述べたもので
ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 | タイム・コンサルタントの日誌から
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 －－だとすると、日本のSI業界というのは将来性があるのでしょうか？ わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情
進捗管理とは何か？ | タイム・コンサルタントの日誌から
「進捗（しんちょく）管理」は広く使われている用語だが、じつはかなり誤解されている仕事でもある。製造業の基本はＱＣＤ（Ｑ＝品質、Ｃ＝コスト、Ｄ＝納期）であり、それぞれをきちんと管理していかなければいけない。Ｑを対象とするのが品質管理であり、Ｃが原価管理（コスト管理）で、Ｄつまり納期を守るために進捗をきちんとコントロールすることが、進捗管理の任務である、と。まあそこまでは良いだろう。 ところが、この『進捗』なる概念がくせ者なのである。これほど誤解されやすいものはないのだが、わたしがそう言うと、不思議そうな顔をする人もいる。作業がどこまで進んだか、それが進捗ではないか。とてもシンプルだ－－そう思う人は、次の例を考えてみていただきたい。 これは国策である「北海道開発プロジェクト」にまつわる話である。ご存じないかたも多いだろうから解説しておくが、戦後まだ間もない昭和25年に『北海道開発法』という法律
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
