Featured image of post プログラマの仕事について思うこと

プログラマの仕事について思うこと

ソフトウェアエンジニアのキャリアを考えると、最近は大分変化してきているのかなと感じるようになった。 しかし一方で、変化の仕方自体には既視感も感じている。ここらで自分なりに整理してみたい。

変わり続けている仕事

年々OSやフレームワーク、プログラミング言語などが成熟するにつれて必要とされるスキルが変わってきていると思う。 ソフトウェアは積み重ねの技術だから、重なっていく程に下の層にある技術が隠蔽され抽象化が進んでいく。それこそが積み重ねる理由でもある。 そして、それが進む程に人間の思考しやすい、表現しやすい形になっていく。(もちろんそう綺麗にはいかないのだけれど)

「機械に仕事を任せて、人間はもっとクリエイティブなことをする」、という言葉はロボットやAIについてよく言われることだが、プログラミングに関する技術もこの方向へ正当進化していると思う。 コンパイラや処理系、開発環境はより人間が面倒だと思うことを吸収して自動でやってくれるようになっているし、人間より最適化がうまくなっている。 まだまだギャップはあるけど、それでも人間はより直感的にやりたいことを記述できるようになってきていると思う。

2004年に書かれた「叫ぶ!Cプログラマ」には、

現在のプログラマの仕事の眼目は「処理」を「計算」に「翻訳」することなのだ。プログラマには「処理」を「計算」として感じられる能力こそが必要なのだ。

と書かれている。

このニュアンスは今でも通用する晴眼だと思うが、現代においてはこの能力の必要性が少しずつ小さくなってきている感覚である。 計算機のように考える必要性が少なくなっている、と表現するのがこの感覚に近いだろうか。

叫ぶ!Cプログラマ―プロが説くCのカラクリと落とし穴 Amazonで見る

これは今に始まったことではないけど、やっぱりそういう傾向はどんどん進んでいっているのかなと思う。 (ネットワークとかグラフィック周りとかも含めるとまたちょっとスタックが違ったりすると思うけど、簡単のため割愛。)

より深く潜るか、より広くカバーするか

では、何が必要になってきているのだろうか? C++で有名な江添さんのブログに以下のようなSICPに関する記事がある。

Programming by poking: why MIT stopped teaching SICP | posterior science このNYC Lisp meetupの動画 で、Gerry Sussmanに対する質問として、SussmanとAbelso...
MITがSICPを教えなくなった理由

そこで引用されている「Programming by poking: why MIT stopped teaching SICP | posterior science」の記述に、

今日では、状況が変わっている。今のエンジニアは、自分が完全に理解していない複雑なハードウェアのためのコードを日常的に書いている(そして、大抵の場合、企業秘密により完全に理解するのは不可能である)。 ソフトウェアでも状況は同じだ。プログラミング環境は、多大な機能を提供する巨大なライブラリ群の集合として存在している。 Sussmanの今日の生徒は、その時間の大半を、ライブラリのマニュアルを読み、どのように組み合わせれば目的が達成できるのかを把握することに費やしている。 Sussman曰く、今日のプログラミングは、「より科学に近い。ライブラリを持ち寄って、つっつき回すのだ。プログラムを書くには、突っつき回して、どのように動作するかを観察する。 そして、「目的を達成するために改造できるか」と考えるのだ」。

という一説がある。

これは上述したような変化について述べている、と自分は解釈している。

一部で「フルスタックエンジニア」のようなトレンドが出てきているのは、こういった状況の変化を受けてのことではないかと思っている。 つまり、ひとりでできることの幅が広がっているのだ。

より広く

広がるのは技術分野だけではないかもしれない。 また古い話に戻るけど、10年くらい前にはT型人材の発展形として、π型人材とか、ナブラ型人材といった人材像の提案され始めたと記憶している。 他にも、デザインエンジニアなどのマルチスキルなキャリアが登場し、注目されるようになったのも同時期だった。

当時は斬新なキャリア像だったが、今でもその人材像は廃れてはいないだろう。 むしろ上記のような変化が進んでいることで、一層こういったマルチスキルの実現性は増しているのではないだろうか。

「デザインエンジニア」が中心となって活動しているデザインエンジニアリングファーム《takram design engineering》。デザインとエンジニアリングを分けず、両方を一人が行なうことでモノづくりのレベルを高める、という彼らのスタイルを深く理解すべく、代表の田川欣哉さんの考えに迫った。
takram 田川欣哉に学ぶ、《デザインエンジニア》の仕事と思想。[前編] | キャリアハック(CAREER HACK)

より深く

一方で、上記のような状況を支えるベースとなる技術は変わっておらず健在している。なんせ積み重ねなので。ただ、数は必要とされなくなってきていると思う。 より標準化され、再利用されるツールが増えれば、それらを開発する人数はそれほど多くは必要ない。 つまり、ハードウェアからアプリケーションまでのレイヤに人の需要を当てはめると逆ピラミッドになっていると思う。

プログラマという視点では、アプリケーションの開発から、アプリケーションを開発するためのライブラリやシステムを開発する、という方向に向かうことで深化できると思っている。

ちなみに、インターフェース 2021年2月号ではこのようなエンジニアを「フルスタックエンジニア」と紹介していた。 巷のフロントエンド+サーバーサイドの定義とは大分内容が違っているが、これもまたフルスタックの方向性ではある。(というか定義揺れなので、何かそれぞれ別のいい表現はないものだろうか)

Interface(インターフェース) 2021年 2 月号 Amazonで見る

まとめ

つまり何が言いたいのかというと、10年前にも同じような話があったんだけど、10年経って違う立場でまた同じような話に触れているなと思ったということ。

状況分析ついでに私見を書いておくとすれば、せっかく高度な技術が面倒な仕事をしてくれるようになったのに、むしろ別の面倒が増えている気もする。 人間が出すことを期待されているアウトプットが難しくなっているのかもしれない。クリエイティブな仕事というのはアウトプットが難しいものだ。

でもそれは楽しいものでもあるし、常に全員に必要とされるようなものでもない。 労働市場の外で考えてみれば、ただただできることの可能性が高まっているだけだ。これ自体は肯定できると考えている。 プレッシャーを感じるのは、今の経済社会システムのせいじゃないだろうか。

労働市場の存在意義自体、変わってきているのかもしれない。 これだけ様々なものが変わってきているのだから、社会や経済のシステムだって変わる必要があってもおかしくない。

Built with Hugo
テーマ StackJimmy によって設計されています。