ソフトウェアエンジニアの成長カーブ（5）

ソフトウェアエンジニアの成長カーブは、横軸が10年、20年、30年となっており、縦軸がソフトウェア・スキル・インデックスのレベルです。この図に欠けている軸として人数の軸が考えられます。つまり、横軸と縦軸の開始点での人数を100としたら、時間経過とともにその人数がどのように減少していくかということです。

おそらく、横軸の10年頃の時点でかなりの人数が減っているのが現状だと思います。つまり、ソフトウェアエンジニアとしてのキャリアを進んでいる人がかなり減るということです。これは、ソフトウェア開発組織によって大きく左右されます。100人いたソフトウェアエンジニアが10年後には、ほぼ全員が開発をしていないような組織もあるかと思います。たとえば、自分で手を動かしてソフトウェア開発することは、給与が安い若い人や下請けがやるものだと思っている組織では、そうなってしまうと思います。

横軸の10年前後から20年にかけて管理する側に回って、現場を離れるという意味で、この成長カーブの対象にならない人が増えてきます。おそらく、20年前後では、多くの開発組織ではほぼゼロに近いのではないのでしょうか。

会社が成長を続けない限り、全員が管理職になるのことはありません。その結果、今後は、エンジニアの成長カーブの対象として見なされるエンジニアが増えていき、横軸の10年、20年、30年の右肩下がりの赤線に該当する人数が増えてくるかと思います。

私自身は、来年の3月で、社会人となって丸30年となります。大学一年生からプログラミングしていたことを考慮すると、36年となります。私にとっては、横軸が30年となっているのは、何の不思議もありませんが、日本の多くのソフトウェア開発組織にとっては、横軸は10年で十分なのかもしれません。

ソフトウェアエンジニアの成長カーブ（4）

最近、キャリア（中途）採用の面接をしています。面接に先立って、書籍の一覧が書かれた調査表に記入してもらいます。目的は、どれだけ本を読んでいるかと継続的に技術書を読む習慣を身に付けているかを知るためです。

社会人となって5年から7年経過して、経歴書上は経験を積んでいるように記述されている人でも、その人が業務で使用し習得していると述べられている技術に関連する書籍をほとんど読んでいない人は、技術的なことをほんの少し深く聞いても答えられない人が多いです。

ただし、新卒としてだったら、採用して育成し直すことができるレベルなのにと思う人も多いです。しかし、すでに、社会人となってから、5年以上経て、技術書を読む習慣を全く身に付けていない人は、急に勉強するようにはならないと思います。

「ソフトウェアエンジニアの成長カーブ（２）」に掲載しているイメージ図を拡大してよく見ると、15年以上の右肩下がりとなっている赤い線に次のような注釈が付けてあります。

新たな技術を習得する必要があるが、学習習慣を失っているため、学習しない。

まあ、実際に業務で必要なら全く勉強しない人はいないかと思いますが、「業務を遂行するのに最低限必要なことを業務時間内に勉強する」程度ではないでしょうか。

イメージ図の注釈における「学習しない」の反対である「学習する」は、私としては、「積極的に学習する」ということです。新たな技術や新たなプログラミング言語を使用するのではあれば、関連する技術書として何を読むべきかを自分で調べて、購入し、プライベートな時間に学習および練習（「Practice, Practice, Practice」）することです。決して、「業務を遂行するのに最低限必要なことを業務時間内に勉強する」ではありません。何か分からなければ、よく勉強している若い人に聞けばよいということでもありません。

しかし、成長カーブのイメージ図をよく見ると、そのような「積極的な学習」は、社会人5、6年の頃に終わっています。その後は、次の注釈が書かれています。

学習しなくても開発業務がこなせるので、学習習慣を失う。

積極的な学習をしなくても、開発業務をこなしている対象領域（ドメイン）の経験年数だけは積み上げられていき、ドメイン知識だけは確実に増えていきます。そして、そのドメイン知識の量が、ソフトウェアエンジニアとしてのレベルであると開発組織も本人も勘違いしてしまうかもしれません。

2000年の頃、ある会議で、私と同じ年齢のエンジニアと（複写機の）コピーアプリケーションのためのAPIを議論しようとした時に、基本的な考え方を単純化して説明したら、「コピーはそんなに単純じゃない」と怒られて全く技術的議論にならなかったのを覚えています。彼は、複写機のコピーアプリケーションの振る舞いについてはドメイン知識は豊富なのですが、ソフトウェアエンジニアとしては、相変わらずフローチャートを部下に書かせているような人でした。当然、オブジェクト指向もC++も知らないというレベルです。私自身は、1993年から1996年に、C++でマルチスレッドプログラミングをしたデジタル複合機の開発に従事している（「C++とメモリ関連エラー」）ので、コピーアプリケーションが単純でないことは十分知っていたのですが、技術的議論は全く噛み合いませんでした。

私の経験から言えるのは、ドメイン知識は開発を通して習得することはできます。しかし、「積極的な学習」態度は、一度失うとなかなか取り戻すのが難しくなります。なぜなら、それは、生活習慣だからです。

（「ソフトウェアエンジニアの成長カーブ（再掲載）」）

無知の領域を減らす

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

• 作者: Dave H. Hoover
• 出版社/メーカー: オライリージャパン
• 発売日: 2010/07/08
• メディア: 単行本（ソフトカバー）

「無知をさらけ出す」（p.39）からの抜粋です。

専門性は、私達が歩む長い道のりの副産物ですが、目的地ではありません。旅をしながら、職人は数知れない技術と領域に取り組みます。必要があったり、興味があったりして、それらの技術の1 つ以上、職人が徹底的に調べる（Dig Deeper）ことを行い、専門性を獲得したらなおさら良いです。 マラソンのトレーニングを行っている走者がより強い脚力を作り出すのと同じように、専門性を獲得するのは期待されていることです。走者は、強い脚力になるようにトレーニングしているのではなく、走るトレーニングをしているのです。やる気のある開発者が2 年間Pythonのプロジェクトで働いた後にPython に関する深い知識を獲得するように、マラソン走者の強い脚力は手段であり、目的ではありません。

専門家によっては、自分の学習、実践、プロジェクトの範囲を狭めて、単一の領域に執着するために自分でできることをすべて行う人もいます。一方、職人は、不慣れな技術を選んだり、新たな領域を学ぶ際に、自分の専門性を脇に退けて、白帯を締める勇気と謙虚な態度を必要とします。

職人が持てる最も重要な特徴の1 つは、無知な領域を特定して、そのような領域を減らすことに努めながら学習する能力です。知識の種を栽培することで、庭の何も無い区画を減らすように、無知の領域を減らすことができます。実験、実践、読書を通して種に水をあげてください。それらの何も無い区画の大きさを恥ずかしく思い、日の光から隠し、自分のプライドを守るために、それらを覆うという選択もあります。あるいは、自分自身やあなたに依存している人達に対して正直であり、助けを求めながら、それらをさらけ出すという選択もできます。

見習い期間が終わるまでには、2、3 の技術について強い知識の糸を持つことになります。それらの糸で、少ない数のプラットフォームや領域上に頑強なソフトウェア・アプリケーションを紡ぐことができます。熟練職人は、無数の糸からタペストリーを紡ぐ能力を持っています。熟練職人は、好きな糸や組み合わせを持ち、糸の数は膨大で、広い範囲の技術環境に対応できます。長い道のり（The Long Road）があなたを導く先は、そのような熟練職人になることです。能力があるように見せかけるよりも、あなたの無知をさらけだし、無知を正面から見据えることで、持っていない糸を素早く紡げるようになります。

『アプレンティスシップ・パターン』（p.39）

高度な仕事を任せられる人になる

プログラマー”まだまだ”現役続行 (技評SE選書)

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2010/09/04
• メディア: 単行本（ソフトカバー）

第11章「若い人たちへ」からの抜粋です。

高度な仕事を任せられる人になる

　長年ソフトウェア開発を行って業務をこなしている人の中には、新たな技術を習得しなくても、あるいは英語が読み書きできなくても、与えられた仕事をこなすことができていると勘違いしている人がいます。
　たとえば、Ｃ言語しか知らなくても、Ｃ言語だけで仕事はこなせると勘違いしている人がいます。なぜそのような勘違いが起きるかというと、その人は新しいことを学習もしないし、Ｃ言語しか知らないし、新しいことをやらせようとしても、「経験がない」とか「知識がない」とかできない理由を並べるため、最後には、Ｃ言語しか知らなくてもできる仕事を、マネジメントが探してきて与えるからです。
　つまり、その人でもできる仕事だけしか与えられていないので、できるのは当たり前なのです。しかし、本人はそんなこととは知らず、年数を経ても何の成長もしないのです。
　仕事を与える立場からすれば、仕事を与えることで本人が成長し、何とか遂行してくれるだけの能力を持っていると判断した場合には、多少新しいことや難易度が多少高めの開発をさせます。そして、それを何とかうまくやってくれたら、次はもう少し難易度の高い開発業務を与えます。
　一方、駄目だと判断されている人の場合、そのような難易度の高い開発業務をさせることは、リスクを高めることになるため、担当させなくてもすむ方法や、他の選択肢を考えます。
　　つまり、同僚より困難な業務が与えられたとしたら、自分の能力が高く評価されているということです。

『プログラマー”まだまだ”現役続行』（p.231）

MacBook Airを購入

普段、外出時に翻訳作業に主に使用していたVAIO X（2009年12月購入）が時々不安定になってフリーズしてしまうようになり、この際ということで、MacBook Air （11インチ）を購入しました。

Macを初めて購入したのは、1991年だったと思いますが、Macintosh LC IIでした。2台目がQuadra 800です。その頃は、プログラミングも覚えようと『Inside Macintosh』シリーズも購入して持っていましたが、今は、捨ててしまいました。

Quadra 800以降は、新たにMacを購入することなく、Windows PCを使用していたのですが、2007年末にMacBookを購入しました。2009年9月に転職するまでは、フレックスだったので、朝は自宅で翻訳作業をすることがほとんどでした。そのため、外へ持ち出す必要はありませんでした。しかし、転職後は、通勤電車のラッシュを避けるためもあって朝早く家を出るため、どうしても、外で作業ができるようにとVAIO Xを購入しました。

MacBook Airに翻訳作業のためのLaTeX環境も再構築したので、今後は、外出時も自宅でもMacBook Airで済ますことになりそうです。Windows環境は、VMWare Fusion 6 + Windows 7の組み合わせで使用できるようにしてあります。

今まで古く遅い環境を使い続けていたので、今度はかなり快適な環境となっています。