第22回 スキルや経験より大切なもの
野村隆(eLeader主催)
2007/1/18
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点=“私点”からそれらの悩みの背後にあるものに迫り、ITエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップトライアングルにおける位置付け
この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点=私点」を皆さんにお届けしています。
今回の内容は、リーダーシップトライアングルにおけるLove、 Management、Capabilityに関係します。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を、Managementについては、第9回「ソフトウェアは目に見えない」を、Capabilityについては、第11回「信頼は河原の石のように」を、それぞれ参照いただければと思います。
![]() |
| 図1 リーダーシップトライアングル。今回は「Love」(ココロ)、「Management」、「Capability」に関連する内容について解説する |
■パッケージシステム導入プロジェクトでの人材採用
ここ数年間、IT業界において、SAP、Siebelといったパッケージソフトを活用する事例が増えているように思います。私の身の回りでもパッケージソフトを導入するプロジェクトが多く、私自身もここ4〜5年間は、何らかの形でパッケージソフトを活用するプロジェクトに配属されています。
パッケージソフトを中心とするプロジェクトで話題となるのは、プロジェクトに配属するスタッフを選定するとき、そのパッケージソフトの経験者にこだわるかということです。
当たり前の話として、経験者は、経験のない人と比べて生産性が高く、プロジェクトで活躍する可能性がとても高いです。従ってスタッフの選定において、活用するパッケージソフトの経験者を集めるよう努力します。
しかし、プロジェクトが小規模で2、3人のスタッフ選定ならまだしも、数十人のスタッフを集めるような大規模プロジェクトでは、経験者だけでスタッフを構成しようとしても限界があります。
■経験者優遇?
こんなときのプロジェクトマネージャの行動パターンとして、以下の2通りをよく見ます。
1つはあくまでもパッケージソフト経験者にこだわるパターンです。この行動を取るプロジェクトマネージャは、ほかのプロジェクトから無理に経験者を引き抜こうとしたり、協力会社さんに無理なお願いをして経験者を探したりします。確かに、プロジェクト成功のための近道ではありますので、その方法は否定しません。むしろ、精力的に経験者を集める努力は継続すべきです。
一方で、パッケージソフトの経験者は探すけれど、同時にJavaやC/C++といった一般的な言語の経験者で優秀なスタッフ、または、別のパッケージソフトを用いた設計・開発の経験者で優秀なスタッフをプロジェクトメンバーとして迎える。そして、活用予定のパッケージソフトのトレーニングを受けてもらうというパターンを取る人もいます。
ほかの言語や開発環境で一定の経験があれば、プロジェクトで活用予定のパッケージ特有の言語の研修を受けてもらうことで、戦力化できるという考え方です。
どちらが正しいとも一概にはいえませんが、どちらの方式を取るかは、プロジェクトマネージャ各人の過去の成功体験に大きく依存するように思えます。
過去にパッケージソフトの経験者を集めて成功した経験のある人は、パッケージソフトの経験者にこだわる傾向にあります。一方、ほかの言語や開発環境の経験者を活用して成功した経験のある人は、経験者にあまりこだわらないようです。
■アウトプットを求める算式
上記のような議論を見るに、私が以前にある人から聞いた以下の考え方を思い出します。
(実際のアウトプット)=(スキル+経験)×意欲
この算式のポイントは、スキル、経験は足し算であり、意欲が掛け算となっているということです。
つまり、スキル、経験のまったくない人は、どんなに意欲があろうが、この算式に従うとアウトプットがゼロなわけです。ですから、特定のパッケージソフトのスキル・経験がまったくない人は、どんなに意欲があろうとも、それを活用するプロジェクトにおいてアウトプットはゼロになるでしょう。
ただ、ほかの言語や開発環境での経験をベースに、パッケージソフトの研修を受けたスタッフであれば、パッケージソフトに関するスキルと経験の和がゼロではなくなります。意欲が大きい人はそこに意欲を掛けた結果、実際のアウトプットが大きくなります。
また、スキルと経験の和が大きい人、つまり特定のパッケージソフトでスキル、経験のある人であっても、意欲が低ければ、実際のアウトプットは低くなります。
例えば、Siebelの経験は豊富にあるが、Siebelのプロジェクトで失敗した人や、SAPの経験は豊富にあるが、SAPのパフォーマンスに悩まされた人は、「このプロジェクトはうまくいくはずがない」と最初から後ろ向きの態度でプロジェクトに参画します。
こういう人は、パッケージをよく知っていることがかえってアダになって、上記の算式でいうところの「実際のアウトプット」が低いことが多いのです。
■Teach them how to fish
この算式を使った考え方と同時にこちらも考慮に入れたいという考え方を紹介します。よくいわれることですが、“Teach them how to fish”という考え方です。
空腹の人に魚を与えると空腹は満たされるが、魚を食べてしまったらそれでおしまい。空腹に逆戻りです。しかし、魚釣りのやり方を教えてあげたらどうでしょうか。釣りを教わった人は、継続して魚を得る方法を知るのですから、空腹に逆戻りすることはありません。
パッケージソフトの研修を受けさせる。これはあくまでも魚を与えることに近いと思います。もちろん、しないよりはずっといいですし、その場の不足を補うことができます。即効性があるといえます。
しかし、パッケージソフトの研修をしたからといって、永遠に経験不足から逃れることはできません。例えば、SAPを使うプロジェクトに配属され、SAPの研修を受けても、次にSiebelを使うプロジェクトに配属されたら、今度はSiebelの研修を受けなくてはなりません。
このように、対症療法を繰り返しても、いつまでたっても経験不足に悩まされます。
こういった対症療法への私の意見として、システム開発プロジェクトにおいて、“Teach them how to fish.”という考え方を援用すべきだと思います。
先ほどご紹介した算式をもう一度見てみましょう。
(実際のアウトプット)=(スキル+経験)×意欲
この算式の本質的に重要なポイントである「意欲」を教えること、学び、体得すること。これが、システム開発プロジェクトにおける“Teach them how to fish”という考え方の解釈といえましょう。
■意欲が大切ということを教える
今回の内容をまとめましょう。
パッケージソフトのスキル・経験がある人を求める、という事例を通じて、「(実際のアウトプット)=(スキル+経験)×意欲」という数式の考え方をご紹介しました。
また、“Teach them how to fish”という考え方、つまり、目先の利益になることを教えるのではなく、長期的に利益になることを教えることの重要性を解説しました。
プロジェクトマネージャとして、プロジェクト運営において考えたいことは、プロジェクトメンバーに対して「長期的に利益になることを教える」ということだと理解しています。
いい方を変えれば、この連載の第1回「WhyとHow、どちらで悩みますか?」でご説明した「Whyの軸」につながります。連載第1回から以下を引用します。
| IT業界におけるWhyは、例えば、システム開発プロジェクトを成功させよう、パッケージ開発事業を成就させよう、企業の成長に貢献するシステムを作り上げよう、という意識、つまり、ITビジネスを成功させるための前向きな考え方です。なぜかというと、ビジネスの視点からすると、ITの手先の技術はあくまでも手先の技術であって、ビジネス成功のための手段でしかないのです。ITビジネスを成功させるという意識を持っていないと、手先の技術が目的となってしまい、目的と手段を取り違えてしまいます。目的と手段を取り違えてしまうと、いつまでも本質的なことが理解できません。 (中略) 経験を重ねるに従い、いつかのタイミングで、Howだけでなく、Whyに気付いて、Whyの方向に向かって自分のキャリアを積むよう志向しなくてはいけません。ITの研究開発に従事するごく一部の純粋なITエンジニアを除き、ビジネスマンとしてIT業界に身を置くITエンジニアは、経験年数を積むに従い、How以上にWhy、つまり、手先の技術よりもITを活用したビジネスの成功への意識付けを持たなくてはなりません。換言すれば、そういう意識改革がなされれば、Whyを求めるという方向性が明確化されるので、ITエンジニアとしての将来への悩みは解消されるでしょう。 |
今回は、上記の個所を、「(実際のアウトプット)=(スキル+経験)×意欲」という算式と、“Teach them how to fish”という考え方で再整理したといえます。
プロジェクトにおいて、「スキルや経験を積むこと」や「意欲」は定量化と評価が難しいですが、非常に重要な視点だと思います。この視点を持ち、プロジェクトのスタッフ選定のみならず、プロジェクト運営に役立てていただければ幸いです。
次回も「私の視点=私点」を皆さんにお届けします。
| 筆者プロフィール |
| 野村隆●大手総合コンサルティング会社のシニアマネージャ。無料メールマガジン「ITのスキルアップにリーダーシップ!」主催。早稲田大学卒業。金融・通信業界の基幹業務改革・大規模システム導入プロジェクトに多数参画。ITバブルのころには、少数精鋭からなるITベンチャー立ち上げに参加。大規模(重厚長大)から小規模(軽薄短小)まで、さまざまなプロジェクト管理を経験。SIプロジェクトのリーダーシップについてのサイト、ITエンジニア向け英語教材サイト、人材派遣情報サイトも運営。 |
ITエンジニアを続けるうえでのヒント バックナンバー
- 第1回 WhyとHow、どちらで悩みますか?
- 第2回 なぜ「決めただけではダメ」なのか?
- 第3回 失敗を恐れず行動しよう
- 第4回 現場で学び、将来への不安を減らす
- 第5回 リーダーシップは生まれつきの才能ではない
- 第6回 正しい行いは将来を変える
- 第7回 中心は「ココロ」、リーダーシップトライアングル
- 第8回 コミュニケーションはリーダーシップの基礎
- 第9回 ソフトウェアは目に見えない
- 第10回 正しいことをし、行動力を発揮するココロ
- 第11回 信頼は河原の石のように
- 第12回 「見える化」だけでは見えないもの
- 第13回 プロジェクト成功につながる100年の杉苗
- 第14回 「もっとスキルを」が引き起こす問題
- 第15回 困難に立ち向かうリーダー、逃げるリーダー
- 第16回 自分を陥れた人に感謝する理由
- 第17回 苦境でも人を恨んでいる暇はない
- 第18回 スペシャリストはリーダーになれない?
- 第19回 プロジェクト運営で重要な「リアリティ」とは
- 第20回 その「リアリティ」はプロジェクトに不必要
- 第21回 石につまずいて怒りますか?
- 第22回 スキルや経験より大切なもの
- 第23回 最近、あなたは職場で人を褒めましたか?
- 第24回 人を育てるためには我慢して待ちましょう
- 第25回 やる気を重視すれば将来は明るい!?
- 第26回 筋の通ったプロジェクト運営を目指そう
- 第27回 最後まであきらめないココロ
- 第28回 デキる技術者になるためのちょっとした心掛け
- 第29回 議論すべき会議とそうでない会議
- 第30回 せきばらいで会議をコントロールする?
- 第31回 なぜか、頑張らない人たちの行く末
- 第32回 欲しいのは、PDCAサイクルが短い人
- 第33回 朝令暮改は悪いこと?
- 第34回 オフショア成功に必要な「ある特性」
- 第35回 何でオフショア開発しなくちゃいけないの?
- 第36回 「面倒」なオフショアを、それでも行う3つの理由
|
|
| スキルアップに役立つ問題を無料で出題 | |
| ITスキル研修4000件、最新情報の検索できます |



公認会計士試験合格者数がさらに削減へ、金融庁が「一層抑制的に」