カテゴリー「マネジメント」の記事

2016年12月 6日 (火)

技術者としての能力と管理職としての能力

 前回の続きである。この記事には、こんな記述もあった。「優秀なエンジニアほど早々と管理職になってしまうが、優秀な管理職になるとは限らない。」
 難しいところだ。私は、古い体質のメーカー勤務だったので、若い頃は、当然管理職を目指すものだと思っていた。そして、管理職になった。
 管理職として、出世はしなかった。優秀な管理職でなかったのだろう。では、技術者のままであったらどうだったのだろう?若い頃は、若い技術者としては優秀だった。でも、そのままベテラン技術者になったときに、ベテラン技術者というカテゴリーでも優秀だったかは、正直言ってわからない。

2016年12月 5日 (月)

技術者のキャリアの最大の課題:管理職にならないと給料は上がらない

 10人のIT部門が消滅~ひとり情シス顛末記 - [第7回]最大のリスクが顕在化、長期休養でIT担当者が不在に:ITproを読んで身につまされた。「管理職にならない限り、どんなにエンジニアとして努力し結果を出しても、評価されないのである。」
 最近では、IT系ベンチャー企業などでは、優秀な技術者を技術者のままで高給で優遇している場合もあるようだ。でも、普通の企業のIT担当者(いわゆる情シス担当)は、そうはいかないようだ。
 そして、それは、組み込み技術業界でも同じである。組み込み技術というのは、いわゆるメーカーの社員である場合が多い。メーカーというのは、古い体質という意味ではトップクラスである。ソフトウエアハウスの社員であっても、組み込み業界のソフトウエアハウスは、発注先であるメーカーと同じように、古い体質のところが多いように思う。
 組み込み技術というのは地味な技術なので、トップ技術者というのが育ちにくい分野だという側面もあるとは思う。しかし、給料が上がらない理由の第一は、管理職にならないと給料が頭打ちになる給与システムである。

2016年2月11日 (木)

特許とシェア確保の関係:「知財戦略のススメ」より

 技術と知財で勝る日本がなぜ世界で勝てないか、というのは、よく言われる疑問である。でも、この疑問は間違いで、技術と知財で勝る日本がなぜ世界で勝ち続けることができないか、というのが正しい疑問のようだ。
 つまり、最初は、日本が世界で勝っているのに、シェアが急落するというのが問題なのである。そして、技術と知財で勝る日本が世界でなぜ勝てないのか - 技術経営 - 日経テクノロジーオンラインは、その疑問にこたえてくれる。
 理由は簡単である。基本特許と改良特許が存続している間は、シェアを守れる。だが、ある時点で、さらなる改良特許は製品化には不要になる。つまり、普及帯の製品を作るだけなら、その時点で特許の切れている技術だけで作れるようになるというのだ。その時点でも、日本企業は大量の知財を持っている。でも、それは高級機種を作るためには必要でも、普及品にはもはや不要なのである。
 言われてみれば当たり前なのだが、今まで気づかなかった。基本特許が切れた後の知財というのは、費用の割りに効果が今一つなのだ。

2016年1月31日 (日)

プロマネの教科書は「扱える領域」だけをカバーしていると捉えよ:日経ITproの記事より

 教科書で勉強するというのは大切なことである。前にも書いたが、プロマネの仕事も教科書ができてから、昔ほどの混乱はなくなってきている。少なくとも、プロマネに関する用語が定義され、それが共有されているだけでも、昔に比べるとはるかに進歩している。
 一方で、教科書通りに進まない話もある。仕事は人間がするからである。(5/7)脱出! 暗闇プロジェクト - 方法論は正しくなくてよい、大切なのは「使えるかどうか」:ITproの指摘は、本当にその通りだと実感する。
 プロマネで最もやっかいなものの1つは、ステークホルダーマネジメントである。ステークホルダーマネジメントは、人間的側面が大きく出てくるものだからだ。人間的側面の大きな課題については、結局は経験がものを言う。その経験の中には、実績という側面が含まれている。人間的側面では、何が正しいかよりも、誰が言っているかの方が重要になるからだ。つまり、実績がものを言う領域なのだ。
 技術屋にとっては、最も苦手な領域だ。こんなことに関わりたくなかったから技術屋になったのに、と思うことも多い。でも、誰かがやらないと、技術屋だけの集団では、プロジェクトはうまくいかない。

2016年1月 6日 (水)

プロジェクト管理は以前ほど難しいものではなくなりつつある:そうかもしれない・・・

 追い詰められるIT部門 - 追い詰められるIT部門[第9回]~遮断されるコミュニケーション(上):ITproという記事を読んでいて、えっ?と思った内容が書いてあった。少し引用する。


 システム開発の方法論が発達したおかげで、プロジェクト管理は以前ほど難しいものではなくなりつつある。プロジェクトに参加するメンバーのコミュニケーションをサポートするようなITツールも多く存在している。


 プロジェクト管理は難しいものである、という固定概念が抜けなかったのだが、よく考えてみると、この指摘は当たっているのかもしれない。
 20年以上も前、組み込み関係の製品開発プロジェクトのリーダーをやったことろは、プロジェクト管理のいい教科書もあまりなかった。そもそも、プロジェクト管理という概念そのものが、開発メンバーの間でも共有されていなかった。開発線表は書いていたが、WBSという考え方すら知らなかったし、上司も同じレベルだった。
 今では、プロジェクト管理という言葉を知らない開発者はいないだろう。良い教科書もあり、講習会も充実している。20年前とは違う。もちろん、昔に比べ、組み込みといえどもソフト規模が大きくなり、プロジェクトの人数も多くなり、納期はさらに厳しくなっている。でも、開発メンバーで共有できる手法があるというのは、そうでない状態に比べると雲泥の差である。
 今後も、プロジェクト管理の難しさは存在しつづけるであろう。それは、開発を人間が担当している限り永遠の課題に違いない。でも、ITツールや手法が進歩することで、難易度は下げていけるはずである。時間外労働の連続で疲れ果てるというデスマーチが少なくなることを期待したい。

2015年12月20日 (日)

若手の覇気を奪うパワハラ:自戒が必要だと気づいた

 最近の若者は、という永遠の愚痴を私も言うことがある。でも、どうして残業禁止が“新型パワハラ”なのか? (4ページ目):日経ビジネスオンラインによれば、実際には、昔と違って、最近の学生たちは真面目で、成長意欲が高い人が多いらしい。最近の学生ではなく、昔の不真面目で成長意欲の低い学生であった中高年は、パワハラといわれるのを嫌って、変に若者の覇気を奪うような発言をすることが多いようだ。
 前にも書いたが、数値目標必達とか、どちらかといえば厳しい発言をする私も、実は、そんなに頑張らなくてもというようなことを言ったりすることがあるように思う。
 後ろ向きの発言で、部下の覇気を奪うことがないよう自戒しなければならない、と決心した。

2015年6月26日 (金)

ヒアリングの際に「なぜ」は禁句:日経ITProの記事より

 (6/7)脱出! 暗闇プロジェクト - 情報は「質」より「量」、ヒアリングで「なぜ」は禁句:ITproの記事の、ヒアリングの際に「なぜ」は禁句は、意外な盲点である。要求分析の際に、担当者が現場に「なぜこの資料を作成するのですか」と質問したら、「F部門から作成指示が来たから」という言葉が返ってきたという。担当者は、その資料作成の目的を聞きたかったのに、そういう回答にはならなかたのである。これは、「なぜ」という言葉を使ったからだという。少し引用する。

 担当者が知りたかったのは「誰のために」「どのような目的のために」「どのような価値を生み出すために」その資料を作成する必要があるのか、である。ところが「なぜ」と尋ねたところ、相手の回答は「目的」ではなく、その作業の「原因」に関するものだった。


 こういう話はよくあることである。使う言葉を選ぶというのは重要なノウハウだ。これと同じようなことで思い出したのが、以前書いたどうして「質問形式」で叱ってはならないのか?:日経ビジネスオンライン記事である。叱るときに「なぜ」という言葉を使うことで、叱られる方が言い訳をしたくなるという。
 なぜ、という言葉は、自分が振り返る場合に使うのはいいが、人と話をするときには、曖昧な言葉なのかもしれない。

2015年4月12日 (日)

どうして「質問形式」で叱ってはならないのか?:日経ビジネスOnlineの記事より

 どうして「質問形式」で叱ってはならないのか?:日経ビジネスオンラインという記事は、自分の叱り方を反省するいい機会になった。少し引用する。

  「どうして君はそんなこともできないのか」「なぜもっと早く報告してくれなかったのか」。このように質問形式で相手を叱ってしまうことがあります。
 しかし「どうして」「なぜ」と質問されると、正しいかどうかは別にして、無意識のうちにその理由を考えてしまいます。つまり、相手に言い訳をさせてしまうのです。
 叱っているにもかかわらず、言い訳をされると腹が立ちます。感情的になって叱っても何も解決しません。質問形式で叱る癖のある人は気をつけなくてはなりません。

 どうすれば、そんなことになるのか、ということを知りたくて、つい質問することがある。自分としては、本当に不思議でしかたないので、つい質問をしてしまうのである。でも、この状況をふりかえると、何も考えていなかったから、そんなことになってしまうことが多いのだ。つまり、質問しても、相手にも答えはない。なんとなくやってしまったことが、大きな失敗につながっただけである。仕事の上で、言い訳を聞いている時間などない。叱り方というのは難しい。

2015年2月12日 (木)

どうして「てっきり」を社内禁止用語にすべきなのか?:日経ビジネスOnlineの 記事より

 IT技術者向けの記事と、営業向けの記事とで、言葉は違えど同じような指摘があった。
 まず、IT技術者向けの記事プロマネに役立つ「内省術」 - 「暗黙知」を問題解決の糸口に、「書く」ことで見える化する:ITproから引用してみる。

 「これだけのアクセスが一時期に集中するとは思わなかった」「このようなリスクは容易に想定できるので、対応策もすでに準備できていると思っていた」<中略>といった思い込みだ。
 システム現場でのトラブルは、こういった思い込みが原因で発生することが多い。自分の立場でしか物事をとらえていないと、大きなトラブルを引き起こす恐れがある。しかも、何度も再発することになる。

 営業向けの記事どうして「てっきり」を社内禁止用語にすべきなのか?:日経ビジネスオンラインからも引用してみる。

○営業課長:「戦略シートはどうなっている」
●部下:「それは……てっきり、課長がやるものだと……」
○営業課長:「なんだって」
●部下:「いや……。課長ではありませんよね。まず誰かがたたき台を作らなくては、という話になっていましたから」

 表現は違うが、同じ現象を指している。営業向けの記事では、これを端的に、「『てっきり』を社内禁止用語にすべき」と表現している。
 てっきりXXXだと思っていた、というのは、要は思い込みである。ちょっとした確認を忘れただけの思い込みから、部署間での常識の違いから来る思い込みのように根の深い思い込みもあるが、こうした思い込みが仕事の障害の大きな部分を占めるということは、その通りだ。
 「てっきり」といいかけたら、その時こそ、自分の思い込みの傾向を分析し、再発防止につなげるべきであろう。社内禁止用語にするのではなく、自分の気づきのトリガにすべきである。「てっきり」XXXとなぜ思い込んだのかの分析が重要なのだ。

2015年1月28日 (水)

なんでも可視化すればいいわけではない

 ミッションと可視化が、大メーカーをダメにした(page 4) - リアル開発会議 - 日経テクノロジーオンラインを読みながら、「そうだ。その通りだ。」と激しく同意した。少し引用する。

 今、大手企業では先に分かっていることだけで経費の概要を想定して、予算化して、それを使いましたという形になりがちです。逆に言うと、予算化していないことに使う資金はないわけです。そうすると、もう新しいことはできなくなる。一度そうなると、前年度との比較で新しい年度の予算が決まる。既得権益のような形で継続するだけになると、さらに新しいことには手を出せなくなる。

 その通りである。何かやるにも、まず予算化されているか否かが問題になる。内容ではない。しかも、その予算というのは、少なくとも何か月か前に計画されたものである。たとえば、4月からの新年度の予算は、1月には決まっているだろう。この技術の進歩の激しい時代に、何か月も前の予算を執行することが重要というのは、時代に合わない。その原因の1つが、可視化であるという。少し引用する。

 ミッションという名前の下に予算がすべて可視化されちゃって、経理担当の若手に全部見られてるわけ。20代の経理担当者から「この経費は何ですか」と50代の本部長がいじめられたりする。

 つまり、個々の予算のミッションが全て決まっていて、これが経理から丸見えなのである。昔も予算制であったことは同じなのだが、その執行は本部長の裁量だった。今ほど可視化されていなかったので、予算時の申請と異なることにも費用を使えたのである。
 ただ、私がもっと危惧しているのは、ヒトの可視化である。そのミッションに誰が充当されているのかを厳密に管理したがるスタッフがいたりする。開発費に人件費を含めて、それぞれのミッションにどれだけの総費用がかかっているかを計算したがるのでる。
 一見正しい意見のように思えるが、ヒトを人件費換算することから組織の劣化が始まっている。新しいことを始めるフェーズで一番大切なのは個人だ。Aさんだからできる、という仕事があるのだ。1人月=XXX円という計算式に入れたがることそのものが新しいものを生み出す土壌を妨げているのである。
 まあ、そういう計算をするスタッフは、大した付加価値を生まないから、その連中の仕事は人月で計算すればいい。そんなバカなことをやりたがるスタッフをクビにすれば、人件費も浮くことだろう。 

より以前の記事一覧

2017年9月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

公告

  • Google Adsense
無料ブログはココログ