« NoSQLでもデータモデリングが必要 | トップページ | 「危ないデータモデル」の定量的判定基準 »

2019.01.13

総合プログラマではなく専門プログラマになろう

 kawaguti氏のブログ記事「業務知識とIT知識を分けて考える時代は終わったんじゃないか」が興味深い。「今どきの経営者や管理者がITがわからないようではまずい」という主張で、その点は私も同意する。いっぽうで、「IT知識を学ぶことで業務知識も学んだことになる」とIT技術者が勘違いしそうな書き方だとも感じた。「ソフトウェアが世界を飲み込む」ことは確かなのだが、IT技術者は業務知識とIT知識をごっちゃにすべきではない。わかることもわからなくなるし、なによりも業務知識の重要さを見過ごす恐れがあるからだ。

■技術要求度と専門性の2軸

 この問題を見通すためには「総合」と「専門」の違いを意識するとよい。よく知られているように商社には「総合商社」と「専門商社」がある。前者は分野を問わないモノやサービスを、後者は特定分野向けのモノやサービスを扱っている。前者は規模やグローバルなネットワークを武器としているし、後者は扱う分野の専門性を武器としている。

 この違いをIT技術者のあり方にあてはめると「業務知識」の位置づけがよくわかる。まず「総合プログラマ」と「専門プログラマ」の違いがあるとしたら、何が違っているか。「IT技術の要求度」と「専門性」の2つの軸で区切られる4象限を考えると理解しやすい。

技術要求度低 技術要求度高
専門性低 初心者(A) 総合プログラマ(B)
専門性高 専門プログラマ(C) 超一流(D)

 まず(B)は「専門性が低く、技術要求度が高い」の組み合わせ、すなわち「総合プログラマ」だ。高い技術力を用いて、依頼されればどんなソフトウエアも開発するというスタンスである。ソフトウエアの適用分野を特定しないゆえにIT技術以外の専門性は要らないが、ITに関する広く深いスキルが求められる。ソフトウエア技術にあこがれる若者の多くは、そんな技術者になりたいと思っているかもしれない。

 いっぽう(C)は「専門性が高く、技術要求度が低い」の組み合わせ、「専門プログラマ」である。ゲームソフト、業務管理システム、組み込みソフト、セキュリティ対策、ネットワークといった特定分野を担うIT技術者をイメージしてもらえばいい。どんな分野であっても、その分野なりの固有の知識体系(業務知識)や経験が求められる。その総体が「専門性」だ。

 ちなみに私自身は業務管理システム向けの専門プログラマ(C)であるが、この分野に必要な専門性は「会計」を含めた事業活動の大枠に関する知識である。ひとくちに事業活動と言っても多種多彩ではあるのだが、個々の差異を超えてシステム要件を手早く理解して仕様化するための知識体系や経験が、この分野での専門性だ。

 ではなぜ(B)と(C)を比べた場合に、(C)では技術要求度が低いと言えるのだろう。特定分野内で繰り返し開発されるソフトウエアは「類型化」するからだ。必然的に、フレームワークやDSLを用いて開発過程を合理化できる。技術上のこまごました問題は、実装基盤やライブラリ内に(程度はあるにせよ)カプセル化可能なので、技術要求度がそれほど高いわけではない。

 じっさい業務システム開発の世界では、ITによる合理化が進んだ結果、かつてのような人海戦術が要らなくなった。私自身、20年前には5~10人のチームでやっていたが、今ではひとりでシステム開発できている。「的確な仕様を構想すること」は今でも難しいが、「構想された仕様を実装すること」は拍子抜けするほど簡単になった。「実装専任要員」も「PM専任要員」も「スクラムマスター」も要らない。設計さえやれたら、ひとりで実装できてしまうからだ。

 つづいて4象限の中の、技術要求度と専門性が「低・低」、「高・高」の組み合わせ(A)と(D)を見よう。誰もがここから職業生活を始めるという意味で(A)はわかりやすい。ふつうの技術者は、(A)から(B)や(C)に駒を進め、そこで職業者として成熟することになる。いっぽう(D)のような人材が求められる分野も、少数ながら存在する。ITを駆使した金融業や科学研究などを想像してもらえばいい。それにしても(D)は優秀すぎて、ふつうの技術者が目指すモデルにはなりにくい。

■総合プログラマの危うさ

 このように説明すると、(B)や(C)のあり方が個々人の好みや自由な選択によるまっとうな結果であるように思えるかもしれない。しかし私は、現実の職業生活における(B)の危うさを警告したい。IT技術者は総合プログラマを目指してはいけない。

 なぜか。人は誰でも歳をとるからだ。体力は言うまでもなく、吸収力や記憶力や意欲といったいわゆる「流動性知能」も20歳そこそこでピークを迎え、衰えてゆく。我々に出来るのはそれらが衰える速度を抑えることくらいだ。総合プログラマとして働き続けるためには、自分よりずっと若い技術者の知力・体力と伍して新技術を身につけていかねばならない。組織の管理者にでもならない限り、立場は厳しいと言わざるを得ない。

 いっぽう、専門プログラマに求められる専門性は「結晶性知能」に分類される。上述したように、各分野で求められる専門性には知識だけでなく実務経験が含まれる。一朝一夕で身につくものではないが、学び続け、実務をこなし続ければ着実に身につく。結晶性知能というのはそういうもので、歳を重ねることはむしろ味方だ。言い換えれば、結晶性知能の利点を生かすには、なるべく早く特定分野に参入しなければいけないということでもある。

 「その種の専門性は、プロジェクトに起用されたドメインエキスパートが補完してくれる」といったアジャイル派からの異論があるかもしれない。しかし、ドメインエキスパートがIT技術者と組むとして、かれが専門プログラマと総合プログラマのどちらを選ぶかといえば、前者なのである。後者の圧倒的な技術力は、ITに疎いドメインエキスパート(*1)には理解されにくいからだ。競合すれば、「スゴさがよくわからない総合プログラマ」は「話のわかる専門プログラマ」に負けてしまう。たとえば、どんなにアジャイルやドメイン駆動に関する造詣が深くても、「移動平均単価」を知らない総合プログラマは業務システム開発の世界ではなかなか信用されない。

 ただし、専門性を武器とする専門プログラマとして働くからといって、新技術の学びや適用に消極的であってはならない。分野固有の専門性といえども、新技術との相互作用で刻々と変容してゆくからだ。古くはコンピュータを利用することで会計の枠組みは抜本的に変わった(本ブログでの参考記事)。最近ではICタグやスマホが普及したので、業務の現場も大きく変わった。このようなことは今後も不断に起こり続ける。それをフォローし続けるためにも新技術の学びが欠かせない。

 また言うまでもないが、専門プログラマであればIT技術者として安泰ということではない。分野を選んでそこにコミットすることは、その栄枯盛衰につきあうということだからだ。だから分野選定には慎重になったほうがいい。たとえば「ビッグデータ」や「データ・サイエンティスト」の専門分野があるとすれば、それを選択するのはビミョーかもしれない。現在もてはやされている「AI」の研究者たちも、2~3年後にはブームが去ると達観しているそうだ。流行りモノの分野には先行者利益があるが、適用分野としての実績評価が定まっていないゆえの危うさがある。

 リスクはある。それでも、自分の相場観にしたがって早めに分野を選択したほうがいい。とくに若い技術者は有能であるほど新技術に魅了されがちなので、専門性を深めることを後回しにしがちだ。技術の魔力を侮ってはいけない。次から次に新技術を渉猟するばかりで、中年になって自分に結晶的な蓄積が欠けていることに気づくようではまずい。分野選定に失敗しても、若いうちなら河岸を替えられるし、複数の専門性を獲得することさえ可能である。

 まとめよう。IT技術者は学びをITに限定してはいけない。オブジェクト指向だのデータモデリングだのアジャイルだのテスト駆動だのAmazonナントカだのホニャララだのを学びたければ学べばよい。しかしそれらのIT系学習課題の外側に、プログラマとして本当に学ぶべき事柄が広がっている。他でもない「ソフトウエアに飲み込まれる世界」に関する知識だ。それを取り込み、その分野での経験を深めよう。何のためか。プログラマであることを一生楽しむためだ。


*1.ドメインエキスパートにITの素養があるなら、彼らだけで開発できる。少なくとも総合プログラマを起用する必要はない。

|

« NoSQLでもデータモデリングが必要 | トップページ | 「危ないデータモデル」の定量的判定基準 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 総合プログラマではなく専門プログラマになろう:

« NoSQLでもデータモデリングが必要 | トップページ | 「危ないデータモデル」の定量的判定基準 »