« October 2004 | Main | December 2004 »

November 30, 2004

方法論のその先

方法論が注目され始めてから随分と経ち、
今では、プロジェクトにおいて、方法論を用いることが一般的になってきました。

ただ、方法論をきちんと使いこなしていない例も多く見受けられます。

 - 方法論はあるものの、成果物を参照するくらいで、手順等は参照していない
 - SIベンダ側は方法論を用いているが、業務ユーザ側の理解が十分でない
   など

方法論を適用するには、
単に、方法論の体系と成果物を説明するだけでは十分ではありません。
なぜなら、方法論には全てが文字として記述されている訳ではなく、
方法論を利用するための暗黙の了解や前提条件があるからです。

そのため、新しい方法論を初めて利用する場合は、
その思想や前提条件を十分に理解する時間が必要となります。
具体的には、次のようなことが必要になると考えます。

 - その方法論を利用した経験が豊富で熟知している人がナビゲートすること
 - 方法論の必要性、適用時の課題などを関係者全員で共有化すること
 - 方法論を定着化するためにパイロットを設けること

| | Comments (0) | TrackBack (0)

November 22, 2004

意見対立は思っているよりも小さい

立場の違いや利害関係により、意見が対立することはよくあることです。
プロジェクト事務局から各チームへの依頼に対して、
事務局としては「当たり前だろう!」と思っているにも関わらず、
各チームが猛反発することもよくあります。

ただ、私の見る限り、
実は両者の主張に大きな隔たりはないことが多いように思われます。
多くの場合、感情的なもつれ。例えば、
「分かっちゃいるけど、出来ないんだ」「こっちの事情も分かってくれよ」
という気持ちが背景にあるのではと感じています。

つまり、皆、内心は「それが必要だ」と思っていることが多いのです。
別の言い方をすれば、ある人が直感的に必要だと思うことは、
表では反発するものの、他の人も必要だと認識するケースが多いということです。

そういう時は、「一緒に障害を取り除きましょう」という姿勢で歩み寄り、
感情的なものを除いてあげることが有効です。

まずは、相手の言い分をよく聞いて、問題状況を明確化すれば、
課題が実際には小さいことがわかり、
お互いに、それほど妥協しなくても、折り合えることが多いかなと思います。

| | Comments (0) | TrackBack (0)

November 21, 2004

準備作業の見積

プロジェクトのスケジュールを立案する際には、
各作業の見積を行いますが、準備作業については忘れがちです。

開発やテストそのものの作業は忘れずに見積もりますが、
開発作業に必要な開発標準・成果物サンプルの作成作業については、
忘れられていることが多いです。

しかし、準備作業は意外に工数が掛かるものです。
他のプロジェクトの成果物などを流用することが多いものの、
プロジェクト毎に事情は異なるため、
そのプロジェクトの実情に合わせたアレンジを行う必要があるのです。

また、各作業を開始するためには、
その開始条件を満たす必要がありますが、
それが明確になっていないことも多く、
開始条件を揃えるために想定以上の時間が掛かってしまうこともあります。

そのため、工数を見積もるためには、
その準備作業や開始条件を満たすための作業も含めた
見積を行うことが必須と考えます。

| | Comments (0) | TrackBack (0)

November 20, 2004

プロジェクトの目標効果

どのプロジェクトでも、最初の段階で、
システム導入による目標を定義し、実現に向けて活動を行います。

しかし、設計・開発・テストと進むにつれて、
多くのプロジェクトで、スコープの見直しがあり、
プロジェクトの目標よりも、
とりあえずシステムを運用開始することが優先されるようになります。

そして、その場合、スコープの見直しにより、
どれだけの効果が削減されるのか見極める作業は行われません。

これらを防ぐためには、
プロジェクトの効果目標を定義するとともに、
それを実現するためのシステム機能を明確化しておく必要があります。
つまり、目標効果に対応するシステム機能を紐付けておくのです。

これには、以下の区別も付けられるメリットがあります。

 - プロジェクトの目標に直結するシステム機能(MUST)
 - ユーザの利便性などで設けられたシステム機能(WANT)

そして、スコープ変更や仕様変更があった場合には、
これらの一覧表をもとに、目標効果にどのように影響するかを試算するのです。

| | Comments (72) | TrackBack (0)

November 19, 2004

都合の良い問題提起

課題の整理に慣れていない人の中には、
自分の都合しか考えず、問題提起をする人がいます。

■よくない例

 営業システムチームから
 「設定変更を行うので、テスト環境を2時間だけ利用中止としたい」
 という要求があった。

 しかし、この要求を受け取ったテスト環境の管理者は、普段から
 「テスト環境の管理は、テストチームの自分ではなく、インフラチームが行うべきだ」
 と考えていた。

 そこで、このテスト環境の管理者は、営業システムチームからの要求を口実に、
 「営業システムチームから申請があったが、
  そもそも、テスト環境の管理は、インフラチームが行うべきだ」という説明資料を作成し、
 課題会議に付議することとした。

■よい例

 この場合、まずは、申請をしてきた営業システムチームに応えてあげる必要があります。
 テスト環境管理者がどう思っていようが、
 実態としては、各チームの窓口となっているわけですから、これに応える義務があります。

 そこで、説明資料としては、こう書くべきだと考えます。

  1. 「営業システムチームの申請により、2時間システムを止めます」
    ⇒ まずは、申請に応える (短期的対応)

  2. 「しかし、本来はインフラチームが行うべき作業であり、
    今後はインフラチームでの対応をお願いしたい」
    ⇒ 次に、常々伝えたいと考えていたことを説明する (長期的対応)

 チームの役割分担については、調整に時間の掛かる事項ですから、
 短期的には、申請に応えつつ、
 長期的に、大きな課題に対応するといった話の持って行き方が必要になると考えます。

なお、課題をきちんと整理して考えられるかは、
課題を順序良く解決するというだけでなく、
プロジェクトをうまく進めていくために不可欠な能力だと考えます。

| | Comments (3) | TrackBack (0)

November 18, 2004

総合テストシナリオの作成方法

総合テストのシナリオ作りは、システムの品質を保証する最後の砦です。
にも関わらず、人間の勘に頼ったものが多いように思います。

本当であれば、業務要件のバリエーションに基づき、
それを網羅するようなシナリオのバリエーションを用意すべきです。
しかし、大抵は、業務要件を一番押さえてそうな代表者数人により、
「これくらいやってれば大丈夫かな」といった具合に、
とりあえず思いつく限りのシナリオを洗い出してみるという場合が多いです。

その場合、シナリオの網羅性は、
シナリオ作りに参画してもらう人に大きく依存してしまいます。
小さなプロジェクトの場合は何とかなることが多いですが、
大きなプロジェクトの場合に
気の利かない人・全体を押さえていない人が担当してしまった時は、
大変な結果になると容易に予測できます。

では、どうするべきか。
業務要件定義を行う際に、なるべく業務のバリエーションが分かるように、
業務機能一覧を作成することが有効です。

 ■業務機能一覧を作成する
  1. 全社業務の概念図を描き、まずは業務プロセスを大きく分割する
  2. 分割された業務プロセスに基づき、レベル感が統一されるように業務機能を
    一覧化する
  3. 業務機能に対し、取りうるバリエーションを記述する

 ■業務シナリオを追記する
  4. 複数の業務機能をまたぐ大きな業務シナリオを洗い出す
  5. 洗い出された業務シナリオに対し、関連する業務機能をチェックしマトリクスを
    作る

 ■ユーザによる確認を行う
  6. 完成した業務機能一覧を関連するユーザにレビューしてもらう
  7. 必要に応じて、ERPなどの場合は、業務シナリオをもとにプロトタイプを実施する

上記の作業により作成された業務機能一覧により、
網羅的に業務のバリエーションを押さえることが出来ると考えます。

| | Comments (1367) | TrackBack (0)

November 17, 2004

体制の作り方

プロジェクトを推進していくためには、
体制をしっかり定義することが大切です。

しかし、多くのプロジェクトで、
「体制はこうあるべき」という考え方に縛られて、
個々の実態に合った体制となっていない事象が
見受けられます。

大切なのは、必要な機能が有効に働くような環境を
整備することです。

例えば、「仕様調整の機能」について。。

絶対にここに配置すべき!というものはなく、
プロジェクト管理事務局の直下にあるチームに置くか、
アプリケーション設計チームとして独立したチームとするか、
いくつかの選択肢があります。

個々のプロジェクトの事情に応じて、
このチームのリーダはしっかりしている、
このチームに情報が集まりやすい、などの理由で
決めるべきものだと考えます。

| | Comments (0) | TrackBack (0)

November 16, 2004

何にでも反論する人

何にでも反論する困った人は、どんなプロジェクトにも居ます。

どんなに論理的に説明しても、重箱の隅を突くような議論を吹っかけて、
滅茶苦茶にしてしまいます。

そういった人は、実は、
論理的な説明を求めているのではありません。
面倒くさいとか気に食わないとか感情的なモヤモヤ・鬱憤を
晴らして欲しいと思っているのです。

そのため、どんなに根気強く説得しても、
徒労に終わることが多いでしょう。

では、どうすれば良いのか。
古いやり方ですが、飲みに行くのが一番です。
感情的なもつれは、仕事中に解消するのは難しいものです。
職場を離れて、人と人との付き合いをすることが、
心理的な距離を縮めるのです。

| | Comments (0) | TrackBack (0)

November 15, 2004

組織文化

先日、学生時代の友人と話していて気が付いたことあるので、
ちょっと書かせて頂きます。

それは、組織文化には、それが作られる理由がある。
例えば、メーカーとサービス会社。

■文化
 ◇メーカー
  - 工場の権限が大きい
  - 工場の自発的な業務が多い
  - 工場毎に業務の流れが様々

 ◇サービス会社
  - 本社の権限が大きい
  - 支店は基本的に本社の指示待ち
  - 支店毎の業務が比較的均質

■理由
 ◇メーカー
  - もの作りが会社の基礎
  - 工場毎に作るものが異なる
  - ひとつの工場に長く勤務する

 ◇サービス会社
  - 全社でサービスが均質
  - サービスは本社で開発される
  - 本社-支店間、支店-支店間の人事ローテーション

システム導入の際には、様々な会社の文化を考慮して、
業務設計を行う必要があります。

その企業文化がなぜ作られることとなったのかを
把握しておけば、業務の把握、関係部門間の調整などに
かなり役に立つものと考えます。

| | Comments (0) | TrackBack (0)

November 14, 2004

他人の苦労は分からない

自分の仕事については、大変さはしみじみ分かりますが、
他人がやっている仕事については、
意外に、その苦労が分かっていないものです。

プロジェクトでは、チーム間・メンバ間の責任分担の狭間に
落ちている仕事がたくさんあるものです。

しかし、それを自発的にやっている人がいる場合に、
その人の苦労は、それ以外の人にほとんど伝わっていないことが多いです。

ただ、それをそのまま放っておくと、
自発的にやっている人のモチベーションを低下させてしまうだけでなく、
自発的にやっていた仕事ができなくなった場合に、
プロジェクトが、思わぬ落とし穴にハマることがあります。

そこで、そういう事例を発見した場合は、
積極的に、プロジェクトの中で公けにしておくことが重要です。
それにより、役割分担に生じた歪みを、
早い段階で調整することが可能になるのです。

| | Comments (2) | TrackBack (0)

November 13, 2004

駄目な怒り方

部下の指導の仕方は難しい、と前にも書いた気がしますが、
今回は「怒り方」について。

こういう怒り方は駄目だなあと思うものについて。

 1. 既に十分反省している人に対して、追い込むような怒り方

   失敗をした人は、その時点で結構落ち込み・反省しているものです、
   そういった人に追い込むような怒り方をすると、
   その人のモチベーションを下げてしまうだけでなく、
   かえって反発心を生む可能性が高いと思われます。

 2. 指摘が的外れな、怒り方

   指摘が的外れな怒り方は、かえって逆効果になります。
   たとえば、やる気が空回りして仕事を抱えすぎで失敗した人に対して、
   やる気が無いから失敗したと怒っても、
   有効な指摘にはなりませんし、逆に反発心を生む結果となります。

怒るということは、失敗した人や怠けている人に対して、
改善しなければという想いを深く刻むきっかけとなりますので、
極めて有効な手段のひとつだと考えます。

しかし、怒り方を失敗した場合は、逆効果となる諸刃の剣だということを
忘れてはなりません。

| | Comments (0) | TrackBack (0)

November 12, 2004

まずはやってみる

色々課題が見え隠れしているが、
各人の認識が違い、
議論しても、取りとめもなくなることがあります。

そういう時は、まず、
試行的にテストケースをやってみることが有効です。

まずはやってみることにより、
具体的な作業の手順がイメージできるだけでなく、
関連する様々な課題も鮮明になってきます。
時には、思ったほど大変でないと判明することもあります。

注意点としては、
時間や規模を限定して行うこと。

あまり一生懸命やっても、
試行的にやっているものですから、
本来すべきことから大きく掛け離れているリスクがあります。

目的は、あくまで課題を洗い出すためですから、
それに十分な程度の試行をすれば良いのです。

| | Comments (0) | TrackBack (0)

November 11, 2004

ものごとの進め方

幾つかのプロジェクトをやって思ったのは、
ものごとの進め方は、どんな場面でもほとんど同じ、ということです。

具体的には、以下の5ステップです。


 1.目標を明確にする
  ↓
 2.現状を把握する
  ↓
 3.現状と目標のGAP/課題を識別する
  ↓
 4.課題に対応するための施策を考える
  ↓
 5.施策推進の体制や計画を明確化する


ほとんどの場合で、この考え方が当てはまると思います。

しかし、多くのプロジェクトで、このような考え方に基づかず、
場当たり的な対応をしていることが多いように見受けられます。

ものごとが停滞しているなと感じた時は、
冷静になって、上記の流れに従い、
なすべきことを整理することが大事です。

| | Comments (0) | TrackBack (0)

November 10, 2004

昔ながらの部下指導

昔からずっと悩んでいることですが、
部下の指導は、どれくらい厳しくすれば良いのかは、
非常に難しいです。

近頃は、コーティングの手法が重要視されていますが、
時には、理不尽なプレッシャーや考え方の押し付けも
必要なのではと思うこともあります。


■理不尽なプレッシャーを与える

私自身もそうだったのですが、
自分が一番成長していると感じる場面のひとつは、
大変なプレッシャーの中で仕事をしている時でした。

誰の手助けも無く、
自分自身で状況を打破しなければならない状況でこそ、
「一皮向ける」「化ける」といったことは起きにくい
と感じています。

その人のキャラクターにもよりますが、
敢えてそういった場に追い込むことも必要では
と考えています。


■自分の考え方を押し付ける

また、自分の考えを無理やり押し付けることも
時には重要だと考えています。

なぜなら、自分で考えている限りは、
自分の中にない発想や思考法は習得する機会が
少ないからです。

多少偏っているかもしれないと思いつつも、
その考えを押し付けて、有無を言わせないことが、
意外に、その人の新しい面を成長させることに役立つ場合がある
と考えます。

---
プレッシャーを掛けたり、自分の考え方を押し付けたりするのは、
昔の指導方法だと言われることが多いですが、
適用する場面を間違わなければ、
意外に有効な手法だったりするのではないかと考えます。

| | Comments (0) | TrackBack (0)

November 09, 2004

ふたつの簡素化

今日ふと思ったこと。。

簡素化にはふたつあります。

 1. 複雑なひとつの処理を簡単にすること
 2. 数多くのパターンの処理を集約すること

例えば、出荷処理について、製品出荷のパターンと材料出荷のパターンがあり、
製品出荷は2ステップで、材料出荷は1ステップで処理できるとします。

 1.の視点に立てば、
 少しでも個々の業務処理を簡素化するため、
 製品出荷は2ステップ、材料出荷は1ステップと設計します。

 2.の視点に立てば、
 なるべくパターンを集約するために、
 製品出荷は2ステップ、材料出荷も2ステップと設計します。

どちらの視点が正しいとは言えず、
臨機応変に利用することが大切です。

| | Comments (0) | TrackBack (0)

November 08, 2004

進捗管理

プロジェクトにおいては、
通常、各種作業を行う前に、進捗管理のための指標を設けます。

指標は、たいてい以下の2つを用いて把握されます。

 1.作成すべき成果物
  例)業務機能定義書、プログラム概要設計書

 2.成果物のタイトルを一覧化した文書
  例)業務機能一覧、プログラム一覧


業務機能一覧を例にとると、こんな感じです。

 ■作成すべき成果物(例)
    「業務機能定義書①<受注>」
    「業務機能定義書②<出荷>」
    「業務機能定義書③<請求>」
    「業務機能定義書④<入金>」
    ・・・
    ⇒ N個のドキュメントが作成される

 ■成果物のタイトルを一覧化した文書(例):
    「業務機能一覧」
    # この中に、①受注、②出荷、③請求、④入金...
    # というように、業務機能定義書のタイトルが
    # 一覧化されている
    ⇒ ドキュメントは1個しか作成されない

 ■進捗管理指標(例)
   業務機能定義書作成率
   = 業務機能定義書の作成枚数/業務機能一覧上のタイトル数


大事なのは、「××一覧」をきちんと管理できるかどうか。
進捗管理は、この「××一覧」のタイトルのうち、
どれだけが作成されたのか、課題があるのかで把握するからです。

ただ、多くのプロジェクトで、
この一覧が、成果物の作成前でなはく、
成果物の作成後に作られています。

しかし、その場合は、
進捗管理をするための母数を把握することができず、
有効な進捗管理ができなくなります。

| | Comments (0) | TrackBack (0)

November 07, 2004

中途採用者のぶつかる壁

11/6の記事で、SEとコンサルタントの違いについて書きましたが、
この違いを理解できるかどうかが大きな分かれ目になることもあります。

SE出身でコンサル会社に来る方は、
なまじ過去の経験があるだけに、
ついつい個別のソリューションに目が行きがちです。
また、SEという職業上、大雑把に大局を見るというより、
漏れを見逃さない細かい視点を持っています。

そのため、システムの詳細には関心の無いユーザのマネジメント層に対し、
望まれる対応をすることができないケースが多々見受けられます。
マネジメント層は、自分が望む業務の姿が得られれば、
システムはどんなものでも良いのですが、
SE出身の方は、なかなかそれに気づかないのです。

私の会社でも、それに気づくかどうかで、
その後の伸びが大きく違うように思います。

気づかない人は、なかなかマネージャにはなれませんが、
気づいた人は、プロパーの人には無い様々なSE経験を武器に
大きく成長しているように思います。

| | Comments (0) | TrackBack (0)

November 06, 2004

SEとコンサルタント

最近、中途採用を手伝うようになって、
ベンダのSEからコンサルタントになりたいという方にたくさん会うようになり、
そういった方の考えるコンサルタント像って、
どういうものなんだろう?と考えることが多くなりました。

私自身も、SEからコンサルティング会社へ転職した一人なので、
SEとコンサルタントの違いについては、よく考えるテーマです。

これまで言われてきたSEとコンサルタントの違いは、
以下のようなものだったと考えます。

 SE :システムをユーザの定義した仕様通りに作ることができる人
 コンサルタント :より望ましい業務の姿をユーザに対し逆提案できる人

しかし、最近は、コンサルタントに対して、
更なる要求が突き付けられているように思われます。

 今までのコンサルタント
     :プロジェクト推進については、あくまでシステム構築について責任を負う
 これからのコンサルタント
     :ユーザ企業内の利害関係を調整し、プロジェクトを推進する

システム構築が、部門毎であった時代から、
全社システム構築の時代へ移り変わった結果、
プロジェクトの推進上、各部門の利害関係を調整することが不可欠となってきました。

しかし、取りまとめ役となる情報システム部門では、
社内の利害関係を調整することができない場合が多く、
その調整役としての機能を、
社外のコンサルタントに求めることが多くなってたように思います。

つまり、様々な障害を乗り越えてプロジェクトを推進していく力が、
これからのコンサルタントには求められているのです。

| | Comments (0) | TrackBack (0)

November 05, 2004

ERPにおける単体テスト

今日は、ERPの構築において、
単体テストはどこまですべきかについて少々。。

一般的には、ERPの標準機能については、
ERPベンダにより保証されているので、テストはせず、
追加開発された部分のみ単体テストを行う、
ということになっています。

ただ、多くのERPにおいて、標準機能となっているものについても、
実際動かしてみると動かないものが数多くあるのが実情です。
そこで、私は、標準機能においても、
何らかの形でテスト(検証)すべきではと考えます。

単体テスト不要論者としては、
通常ERP構築の場合は、プロトタイプを行って、
標準機能については一通り検証しているので、
大丈夫だという意見もあるでしょう。

しかし、プロトタイプは、ユーザの時間が取れないことから、
大雑把なレベルでの確認に留まることが多く、
細かい全てのパターンを検証する訳ではありません。
それ故、全てのパターンについて、機能の一覧表や検証の結果が、
ドキュメントとして残ることは少ないと考えます。

ただ、標準機能について単体テストをしよう、
というプロジェクトは無いのが実情ですが。。

| | Comments (0) | TrackBack (0)

November 04, 2004

気の緩み

最近は体調を崩しがちなんですが、
やっぱり気の緩みなのかなあ、と実は感じています。

フェーズの切れ目で、自分のチームの仕事も一段落しそうなので、
張り詰めていたものが切れ掛かっているのかと思います。

長いプロジェクトでは、
ずっと緊張しっぱなしでは身体が持たないですし、
仕方のないことかと思います。
また、気持ちが擦り切れないよう、
敢えて意識的に気を抜くことも必要だと考えています。

しかし、その程度が難しい。。
いったん気が緩んでしまうと、止め処もなく緩んでしまうことがあります。
そうなると、周りの真面目に働いている人のモチベーションを下げかねません。

そういった時は、思い切ってまとまった休みを取って、
一気にリフレッシュすることが良いように思います。

| | Comments (0) | TrackBack (0)

November 03, 2004

出来の良い部下

昨日は、部下に仕事を任せることについて話をしました。
ただ、それは、部下が自分よりも能力が低いという前提でした。

しかし、実際の場面では、
自分より能力の高い部下が下に付くことも多いです。

プロジェクトは、毎回、内容やメンバが異なるため、
どんなに経験を積んでも、新しい分野に挑む必要があります。
そのため、自分がそんなに詳しくない分野について、
責任を負わなくてはいけないことがあります。

そういった時は、自分の知識・スキル不足を補うために、
その分野に詳しい部下を付けることになります。

私の身の回りにも、そういったケースをよく見かけます。
ただ、うまく行っているケースとそうでないケースがあります。

うまく行っていないケースは、
以下の2つが原因ではないかと考えています。

 1. 分からない分野だからと部下に全て任せてしまっている
 2. 半ば素人の自分のやり方を部下に押し付けている

自分の知らない分野をコントロールするのは大変難しいです。
丸っきり任せてしまっては、
それがプロジェクト全体の目標に沿っているのか確認できません。
逆に、下手に指示を出しても、
それが間違った指示となっては意味がありませんし、
部下のやる気を削いでしまう可能性も高いです。

ポイントは、3つだと思います。

 1. プロジェクト全体の目的・動きを把握し、部下に伝える
 2. 部下のスキル・経験を正確に理解し、足りないところを把握する
 3. 部下同士の役割分担・育成を考える

自分と部下の違いは、そのポジションです。
部下はどんなに優秀であっても、その立場により、
プロジェクト全体の目的・動きについては、疎くなります。
そこで、部下の動きをプロジェクトに沿うよう
コントロールすることが重要な役割となります。

また、その分野に強い部下といっても、
全てに完璧な人材ではないはずです。
部下に足りないところを理解し、
部下の得意なところは思い切って任せ、
足りないところをフォローしてあげるようにすることが
部下との関係をうまくする秘訣です。

さらに、自分の部下が複数人いるときは、
負荷が平均化されるよう、また、他の人が育成されるよう、
チームマネジメントをする必要があります。
いくら優秀な部下でも、能力的にも工数的にも、
ひとりで全てはできません。
チームマネジメントは、
上司として最も大切な仕事のひとつだと考えます。

| | Comments (0) | TrackBack (0)

November 02, 2004

仕事を任せる

今日も風邪であまり仕事がはかどりませんでした。。

で、思ったことがあります。
『下の人に任せられる仕事は普段から積極的に任せるべきだ』

今日は、周りの人がいつも通りに仕事をしてくれたので、
私が風邪を引いても、ほとんど支障はありませんでした。

仕事を任せるというのは2つの意味で難しいと思います。

 1. 自分でやった方が早くて・正確だと感じてしまう
 2. 自分の活躍する場面が減ってしまう

「1. 自分でやった方が早くて・正確だと感じてしまう」ことについては、
多少心配でも任せていかないと、下の人は育ちません。
下の人が育てば、自分自身も、
更に上のレベルの仕事をすることができるようになります。

ただし、そのためには、
育成の観点から、下の人へ目標やガイドラインを示すとともに、
継続的なレビュー・指導が必要となります。
また、多少危なっかしくても見守る度量が必要となります。

「2. 自分の活躍する場面が減ってしまう」ことについても、
任せきる度量が必要となります。
自分のアピールのために、下の人の出番を奪ってしまっては、
下の人のモチベーションを下げてしまうだけでなく、
任せられているという意識を削いでしまいかねません。

もし、下の人に完全に仕事を奪われてしまうのなら、
そのポジションに、その人は必要ないのだと思います。
ただ、それは悪いことではなく、
その人が更に上のレベルの仕事をするためには、
必ず必要となることなのです。

| | Comments (0) | TrackBack (0)

November 01, 2004

モチベーションの維持

今日は風邪を引いて、早退してしまいました。。

前職時代は、風邪なんて滅多に引かなかったのに、
今の会社に入ってからは、風邪を引きやすくなってしまいました。

理由としては、以下の3つだと感じています。

 1. 激務で身体に無理な負担が掛かっている
 2. プレッシャーやストレスが大きい
 3. モチベーションの維持が難しい(気持ちが乗らない)

転職経験者の私としては、
「3. モチベーションの維持」が一番大きな要素であると考えます。

目的や目標がある時は、がむしゃらに頑張れるのですが、
そうでない時に黙々と頑張るというのは、非常に難しい。
特に、いつも選択肢に転職が頭にあるので、
面白くない仕事に対するモチベーションを維持するのが難しいのです。

これに関しては、まだ私も試行錯誤で、
明確な解決策を持っていません。

| | Comments (0) | TrackBack (0)

« October 2004 | Main | December 2004 »