ymmooot

プログラミングは手段という話

このツイートを受けて、自分のスタンスを書く。

「ソフトウェアエンジニア」とは何者なのか

まず前提として、ここでは事業会社やフリーランスで働くソフトウェアエンジニアのことを書く。教育者や、言語の開発者、研究者などは含まない。


職業としてのソフトウェアエンジニアの仕事は単純で、プログラミングによってソフトウェアを作り、プロダクトを現実にして、ユーザーに価値を提供することだ。その内容はプロダクトの機能実装、バグ修正、パフォーマンス改善、セキュリティ対策、インフラ構築やコスト削減など多岐にわたるが、いずれも「企業が存続可能な状態で、ユーザーに価値を提供する」ことが目的である。
コードを書き、デプロイし、誰かがそれを利用し、その結果として企業が利益を上げ、その一部がエンジニアの給料として支払われる。実に単純な構造だ。


当たり前に、自分が書いたコードが自分に支払われる報酬以上にお金を稼ぐかコストを削減しないと、企業にとっては意味がない。中期的、長期的に結果が出るものもある上に、すべてのコードが利益に直結する訳ではないため、実感が湧きにくい部分もあるが、この事実は変えられない。


エンジニアの属する企業の大きさや、プロダクトの規模が大きければ大きいほど、この感覚は得られにくいと思う。


自分は、会社員をやめてスタートアップの創業メンバーになったり、フリーランスとして株を持ちながらスタートアップの立ち上げの仕事を受けたりしている。それらの仕事は、企業の売上とエンジニアの給料の距離感がとても近い。自分が書いたコードが利益を生み、自分が構築したインフラがコストとなる。自分がデプロイしなければ計画は1歩も前に進まず、自分が先回りしてコードを書けば事業は加速する。


この金銭感が、あくまで「プログラミングは手段」であるということを、自分に強く意識させる。

「プログラミングは手段」であれば、プログラミングの内容はどうでもいいのか

自分にとって、エンジニアの任務は「企業が存続可能な状態で、ユーザーに価値を提供する」ことだと思っている。上の句が重要で、企業が存続可能な状態を維持しなければならない。企業が生き残り続ける要素の一つにスピードがある。世の中に必要とされているものを、素早くデプロイしていく必要がある。デプロイを重んじる話はこちらにも書いている 👉🏼 スタートアップにおけるプロダクト戦略とエンジニアリング


そして、良い技術や良いコードは、そうではないものに比べて圧倒的に開発のスピードが出せる。より良い設計・より良いフレームワーク・より良いコード・より良いテストなどは、変更や追加実装が容易で、破綻しにくい。ここに、技術力の価値がある。長年運用されたコードに触れたことがあるエンジニアなら誰しも経験があると思うが、技術力の低い先人が書いた無秩序なコードは容易に破綻する。機能を一つ変更したり追加するだけで、壊れてないところがないか入念に精査し、検証する必要がある。こうなるとスピードは出ないし、実現が不可能にさえなり得る。


ドメインに深く入り込み、丁寧にモデリングをし、事業の方向性を見極め、適切な設計をする。その設計の上で、開発が容易で、変更への耐性をもち、パフォーマンスも犠牲にしないコードを書く。これこそがエンジニアに求められていることだ。


「プログラミングは手段」であることは、エンジニアが技術力を向上しない言い訳にはならない。

「プログラミングが目的」であることも許容したい

エンジニアはプログラミングが好きな人が多い。優秀であればあるほど、そのような人が多いだろう。周りの優秀なエンジニアは余暇時間にコードを書く方ばかりだ。このような人はプログラミング自体に楽しみを見出している。それはいいことだと思う。


企業はこの楽しみを、エンジニアからなるべく奪わないように務める必要がある。なぜならその方が「企業が存続可能な状態」を保てるからだ。エンジニアは「プログラミングは手段」であることを頭では理解して業務にあたり、企業はエンジニアが「プログラミングが目的」となる瞬間があることを忘れずに業務をさせる。企業はエンジニアに、常にやりたいことだけをやらせることはできなくても、なるべくやらせてあげるよう努めれば良い。それができなければエンジニアが辞め、「企業が存続可能な状態」から遠ざかる。


一方で個人的に試したい技術を、砂場遊びのように会社のプロダクトに持ち込んだりしていないか、その選択が本当に存続可能な状態を保てるのか、エンジニアサイドは気をつけなければならず、それを会社に咎められ子供のように駄々をこねても意味がない。こういった遊びや研究の余地は企業やチームの余裕によって大きく異なり、所属している企業にそれが可能かどうかは、エンジニア自身が判断しなければならない。今は余裕があっても数年後に余裕がなくなった時に、その選択が凶と出る可能性もある。(その時に自分が所属していなければ関係ないと切り捨てることが、プロとして相応しいかどうかは各々が考えれば良い。)

心構えの問題

楽しくないものはどう頑張っても楽しくない。ひどいコードはひどい。頭が痛くなる。目の奥に来る。エディタを見たくない。しかし、楽しいコードだけ書きたいというのは虫が良すぎるし、そのようなスタンスでいると、結局どの職場でも長続きしない。


エンジニアは、事業を存続する上で「プログラミングは手段」であることを念頭に置くことが、エンジニア自身の精神を助けることになる。あくまでそのスタンスの中で技術力を身につけ、それを発揮できているか、楽しく働けているのかを職場に求めて行くくらいがちょうどいいのではないか。

余談

自分は「車道を作る」という表現をよく使う。要件を分割してコードに落とし込み、設計し、雛形を作った時点で、その後そのプロダクトに携わる人の、コードへの関わり方が大きく異なってくる。作った車道の上で分担してコードを書いていく。車道が良ければ車は早く走れるし、車道が悪ければ、エンジニアが何人集まっても渋滞が起こるだけだ。チームの人員が増える前からチームのスケーラビリティはある程度決まってしまう。


そして、こういうことを全エンジニアが意識できるチームは強い。自分の持ち場の足元だけ見るのではなく、事業の行く先を見据え、技術力で力強くその走りを後押ししていくような取り組み方をした方が、結局のところ仕事も楽しいのではないかと思っている。

Share on