SI業界の今後と技術者のキャリアを真剣に考える2今後の技術者のキャリア構築(この記事は前回の続きです)プログラマーの地位向上とは、ユーザーから見えない単純作業者を卒業し、ユーザーから見えるクリエイティブな技術者になるということです。これを実現するためには、プログラマーのスキル構築を見直す必要があります。ユーザーに認知されるクリエイティブな技術者になる古い体質のSIの組織では、技術者は、PG→SE→PMという流れでキャリアを積み重ねるものと考えられています。かみ砕くとこういうことです。・まずは単純作業に近いコーディングを担当できるようになる。(PG)・次に、上流工程を担当できるようになる。(SE)・その後に、管理者になる。(PM)このキャリアパスは、多重下請け構造を前提として考えられているように感じます。この考え方に従って役割を決めていくと、プログラマーがユーザーと接する機会がなくなってしまいます。そのため、プログラマーはユーザーの声を直接聞くことがないために、ここに溝ができてしまうのです。これでは、ユーザーにとって何が大事なのか技術者が汲み取れないので、クリエイティブな発想も生まれてきません。そこで、仕事の仕方を変えてみてはどうでしょうか。プログラマーが設計検討の会議に必ず参加するようにするのです。会議で一言も話さなくても、議事録を取るだけで良いのです。大事なのは、ユーザーが何を考えているか、何を大事にしているかを自分で感じ取り、感性を磨くことです。ここで、今後のIT技術者のスキル構成について、私の考え方を紹介します。上記の図は、3つスキルを満遍なく身につけたケースを表しています。外側の三角形は、それぞれのスキルのエッジ(俗にいう”尖っている”感じ)を表しており、この三角形の面積が大きいほど仕事力が高いことを意味します。上図では、満遍なくスキルを構築していますが、このような人はPMに向いているスキル形成と言えるかもしれません。<技術力を中心にしたスキル構成の例>この例では、Javaを中心にした技術力で尖っているケースを記しています。業務知識が不足しているために、三角形の面積は小さくなっています。これは、言い換えると技術力に頼っているとも言えます。この先のキャリア形成をどうするか。技術力をさらに高めていくことも、業務知識やコミュニケーション&推進力を高めることも考えられます。これは個人の意思と選択によって決まります。尖っていきたい人は、三角形の面積を大きくするためには、最先端の技術や現場で使われている枯れた技術の設計/実装力をとことん追求し続ける必要があります。アプリケーションアーキテクトのイメージです。今で言うと、例えば分散処理系のOSS(HadoopやSpark等)に関する技術や、これらをエンタープライズシステムに導入するために既存システムのアーキテクチャに関する知見を有していることが求められています。業務知識と技術力をバランスよく磨き続けることで、ビジネスアナリストとして活躍することが期待できます。ビジネスアナリストは、コミュニケーション&推進力を磨くことも重要ですが、プロジェクト全体の作業計画や管理タスクはプロジェクトマネージャに任せて、業務と技術の2本の柱で分析と設計、実装の完遂に責任を持ちます。コミュニケーション&推進力の中では、コミュニケーション&推進力を最も重視してスキルを構築することで、例えばPMOの役を担うことができます。技術力と業務知識も一定以上のレベルにならないと、本当の意味で活躍することは難しいです。3つのスキルをバランスよく磨くことで、プロジェクトマネージャを目指すことができます。これらのタイプに当てはまる形でスキルを形成していけば、今後も仕事に困ることはないでしょう。良い意味でチャレンジングな仕事を受け持つチャンスに恵まれやすくなるでしょう。一方で、このような特色を打ち出せない技術者は、クラウド化やオフショア化や作業の自動化といったコスト削減の流れの中で苦しい立場になっていくことが予想されます。技術者が自分の将来像を描きながらキャリア構築に関する意思を持ち、その考えに従って仕事を選択するようになると、今自分が所属している組織に居続ける必要性は下がっていきます。なることで技術者の人材流動性が高まっていけば、日本のSI業界を変える一つの力になるかもしれません。多重下請け構造というSI業界の商習慣を個人の力で変えることは事実上不可能ですが、それに比べれば個人が変わることは難しいことではありません。多重下請け構造の商習慣を理由にして自分自身のキャリア構築を諦めず、小さな開拓者になった気持ちで、社内・社外を問わずに仕事を取りに行くことが、技術者に必要な要素になってきているのだと考えます。して、個々人のキャリア構築の意思と、日々の自己研鑽と、開拓者マインドとでも呼ぶべき仕事を自ら取りに行く姿勢が、プログラマーの地位を向上させるのです。個人がこのように変わり、人材の流動性が高まることで、会社の側も今までの考え方では人材を確保できなくなります。して、後追いであったとしても業界全体が変わり、良くなっていくことを期待したいところです。最後に、前述のスキル構築モデルを組織的に活用する方法を紹介します。コミュニケーション&推進力)が、開発プロジェクトにアサインしたメンバー全員で十分賄えているかという検証を、各工程の開始前に実施します。これにより、プロジェクトのQCD問題の発生リスクを減らすことができます。プロジェクトチーム組成時に、組織力チェックというアクティビティを導入し、そのプロジェクト組織がどのような特性を持っているかを判定するのです。この時点で、ビジネスアナリストが足りないのか、テクニカルアーキテクトが足りないのか、はたまた管理メンバーが足りないのかということを洗い出します。そのためには、3つのスキルをさらにブレイクダウンして、プロジェクトにどのようなスキルが必要なのかを明らかにする必要があります。プロジェクトマネージャやITコンサルタントには、このようなことを見抜く力が必要だということです。