毎年、春と秋の２回は、過去１年及び半年間の活動結果・実績を振り返り、フォローするとともに、次の年度及び半期毎の個人目標の設定をします。この目標設定と合わせて、ＩＴＳＳ（IT skill standard：ＩＴスキル標準）に基づくスキル・レベルの再確認と、今後のキャリアパスについての個人面談を実施しています。
ＩＴＳＳによるスキル領域及びスキル熟達度の判定は、面談を受ける個々のＩＴエンジニアにとっての関心であるとともに、その判定結果と過去の仕事ぶりに基づいて今後のアサイン・・しばらく現状のポジションで頑張らせるか、それとも、サブリーダやチームリーダに抜擢してみるか、を考えることが必要になるため、現場のプロマネにとっても気になる存在です。
ＩＴプロジェクトのプロジェクトマネージャの立場としては、プロジェクトを構成する主要なチームのチームリーダや、プロマネとしての自身をサポートしてくれるプロジェクト内ＰＭＯに優秀な人材が欲しいのはいうまでもありません。
また、複数のプロジェクトを統括し、大規模プロジェクトを推進するプログラムマネージャの立場としても、個々のプロジェクトをグリップしてくれるプロジェクトマネージャやチームリーダの存在が、プロジェクトの成否に直結していることが骨身にしみてわかっているし、そもそも適正なスキルのメンバーが揃うかどうかによって、プロジェクトの体制が組成できるか否かも決まってきます。
ここ数年、若手のＩＴＳＳのスキル熟達度を見ていて気になることがありました。
アプリケーションスペシャリストとして、レベル４からステップアップしてレベル５の評定を申告していたものが、１〜２年経ち、再びレベル４に逆戻りするケースがあります。数名のメンバーを率いてプロジェクトを成功させた若手を、次のプロジェクトにおいてサブリーダやチームリーダに抜擢してみたところ、結果は芳しくなかったという理由によります。
ＩＴスキル標準は、「産学におけるＩＴサービス・プロフェッショナルの教育・訓練等に有用な「ものさし」（共通枠組）」として提供され、ＩＴサービスの分野１１職種３８専門分野ごとに，最高７段階のスキル・レベルを設定しています。
最新版の「ＩＴスキル標準V3 2008」では、スキル領域毎に「スキル熟達度」が定義されているのですが、上記のケースで挙げたアプリケーションスペシャリストの「プロジェクトマネジメント」領域の「スキル熟達度」のレベル４とレベル５の記述はこうなっています。
レベル４ 「ピーク時の要員数３人以上のアプリケーション開発プロジェクトにて、開発チームリーダとして、プロジェクトマネジメント職種と協業し、プロジェクト計画策定と実施、変更管理等のプロジェクトマネジメントを遂行できる。」
自分を含め、３名から９名以下のメンバーを指揮して、業務分析や設計・開発を推進できる中核のエンジニア、プロジェクトチームの中では、サブリーダ的な位置づけを担います。
レベル５ 「ピーク時の要員数１０人以上５０人未満のアプリケーション開発プロジェクトにおいて、開発チーム責任者として、プロジェクトマネジメント職種と協業し、プロジェクト計画策定と実施、変更管理等のプロジェクトマネジメントを遂行することができる。」
レベル４は、自分も含めて１０名以下のメンバーで推進する、目が届く範囲・・オフィスの座席でみると「一島」＝１０席〜１２席に収まる世界です。
ところが、レベル５になると、物理的に「一島」を超えます。レベル４までであれば、配下のメンバーの全作業内容を把握し、その結果も頑張りさえすれば全部確認することも可能であったかもしれませんが、レベル５以上は不可能になります。
レベル４とレベル５の間には、ＩＴエンジニアとしてのプロジェクトマネジメント業務におけるパラダイム転換が存在しています。
・個人プレーから、チームプレーへの転換が必要となる。
それまで（プロマネやリーダーがお膳立てしてくれていたため）意識しなかったチームとしての仕事のスコープの範囲や、チームメンバー一人ひとりの役割や仕事の範囲や、チームメンバー間のコミュニケーションや、チーム間のタスクの調整などを行うことが、仕事のスタート時点で必要となります。
また、メンバー数が１０名・・オフィス内の一つの島という、目が届く範囲を超える場合、メンバーが文字通り一つのチームとして機能するよう、朝会・夕会等のコミュニケーション・ルールを決めるだけではなく、生産性・品質をあわせて、かつ、向上させるために、業務プロセスの内容・手順の整備と共有化が必要になってきます。
これを「ＩＴＳＳレベル５の壁」または「一島の壁」と個人的に呼んでいますが、同様なことは中堅やベテランにおいてもあります。レベル５の下位と上位の壁もあり、また、その後には、レベル５からレベル６になって５０名以上の大規模プロマネへの壁が控えています（笑）。
前回、新人・若手がいかに学べばよいか、学ぶための心得として「教わる技術」を紹介しましたが、基本的には、中堅・ベテランにおいても必要な心得であると思っています。
プロジェクトマネジメントにおいても、レベル３からレベル５の入り口までは、ＰＭＢＯＫを中心としたプロジェクトマネジメント知識を習得する研修が有効であるし、社内外の研修も充実してきています。また、レベル５以上のエンジニアについては、ＰＭコミュニティにおいて情報交換やセミナーによって実戦的な知識・知恵を共有することが推奨されています。
しかしながら、一定の基礎知識を得て次のステップに進もうとしながら「壁」の前で苦戦している若手から中堅のエンジニアにとっては、「教わる技術」とは別の発想が必要だと思っています。
竹内日祥『企業再構築の仕掛け』（＊）の中で、パラダイムの壁を乗り越えて、より高位のパラダイムにシフトする方法として、「アンラーニング」＝学習棄却ということが提案されています。
『科学革命の構造』で、パラダイム論を提唱したトーマス・クーンの言葉に、
≪人間はパラダイムに支配された人生しか生きることができない宿命がある≫
というものがあります。
人は、自分にとってのパラダイム・・思考法や感受性、過去に得てきた様々な価値観や知識が位置づけられた世界観に基づいて、行言動している。だから、このパラダイムを、より高いものにすることで、自分の生き方そのものをより良いものにすることができることになります。
たとえば、極端な例になりますが、プロジェクトの中に、優秀なエンジニアではあるが、
≪現在所有している自分のパラダイムは、過去に学んだ学習の成果です。私達は、過去に学んだことに囚われ、学んだことから自分のパラダイムに支配されています。≫
したがって、一エンジニアとしての過去の成功体験とそこで得た知識が、行動のよりどころになっているのは間違いありません。過去に得た知識によって、日々円滑にすごすことができ、様々な局面で遭遇するピンチにおいても救われ、助けられてきたのは間違いないと思います。
しかし、一人の優秀なエンジニアから、プロジェクトやチームを指揮する立場に変わるように、自分のおかれている環境や立場が大きく変わり、自分の果たすべき役割も大きく変わる場合、過去の成功体験とそれに基づく価値観や知識をあえて捨て去る必要があります。新しい知識や価値観を受けいれるために捨てる、この過程が、アンラーニング＝学習棄却になります。
ただし、棄却といって、過去に身につけたものをすべて捨ててしまうことではありません。これまでより高いレベルの知識と価値観に基づいて、従来の低いレベルの知識と価値観を、再構成することが大切になります。
・捨てるべきものは捨てる。
・残すべきものは残す。
・空いたスペースに新しい知識・考えを取り入れる。
ＩＴＳＳのレベル４からレベル５への移行におけるアンラーニングとは、たとえば、「仕事は全部自分でやらなければならない」「全て自分の目でチェックしないと気がすまない」「人に教えるより、自分がやった方が速い」「自分の範囲だけきちんとできれば、責任は果たしている」等という発想を捨てることから始まるのかもしれません。
そうではなくて、「自分がやらなくても、仕事が上手く回るようにするにはどうすればよいか」「人に仕事を任せるためには、どのような条件が揃えばよいか」という視点に立つ必要があります。
それには、自分がこれまでやってきた仕事がどのような要素とプロセスから成り立ち、どのようなスキルや体制が必要であったかを、振り返ることが大切だと思います。この振り返りの作業の中で、自分がこれまで一生懸命やっていたことに加えて、新しい作業に気づく。自分の仕事ができるための仕事の段取りや環境を、周りのメンバー（顧客や上司や他のメンバーや他チーム）が準備していたこと、どのように整えてくれていたのか等に気づくことができます。
竹内さんは、≪捨てられない人は、学んだことによって成長が止まってしまいます≫と指摘されていますが、怖い指摘です。
ラーニングとアンラーニングを交互に繰り返すことで、パラダイムをより良いものにしていく、というのが、中堅以降の学習の基本になると思います。
ところで、アプリケーションスペシャリストから、プロジェクトマネージャへの「壁」については、あまり深刻になる必要はない、と思っています。
ＩＴエンジニア全員にとって、プロジェクトマネジメントの意義や内容の基本的理解は必須であると思う一方、メンバー全員がプロマネを志向する必要はありません。ＩＴエンジニアとしての知識・経験を積んできたのであれば、アプリケーションスペシャリストからＩＴアーキテクトや、業務コンサルタントとなって活躍するケースも多いのも事実です。また、現場のプロマネからしても、プロジェクトやプロジェクトマネジメントのこともわかっているＩＴアーキテクトや業務コンサルタントと協働で仕事をする場合、役割分担が円滑にでき、お互いの長所がより活かせることが多いです。
最後に、クーンの『科学革命の構造』の一節を紹介します。
≪・・新しいパラダイムの基本的発明を遂げた人は、ほとんど、非常に若いか、
パラダイムの変更を促す分野に新しく入ってきた新人かのどちらかである。≫
後世畏るべし・・旧人よりも、新人の大化けに期待しよう、と日々楽しみにしています。また、それとともに、その新人や若手からパワーや新しい気づきを得ながら、中堅やベテランも含めて、一緒に成長できる組織にしたいと思っています。
（＊）竹内日祥『企業再構築の仕掛け バリュー・マネージメント―激動の乱世、変革への挑戦』現代書林 ２００６年刊