昔、新製品開発プロジェクト係といういかにも期間限定っぽい名前のチームに参加して製品開発をしていたのだが、目の前の製品ができるころに、

「あー、これができたら、自分どうなるのかな」

という漠然とした不安があった。当時いた会社の製品は、カタログ製品として売ると同時に、カスタマイズベースになるものなので、大きい顧客で要求される特殊仕様に適応させる仕事というのがあって、そういう運用的な仕事に取りかかるのかなぁと思っていた。

しかし、一度、新製品開発のプロセスに参加して、割と自由な仕事をしてしまうと、どこか特権のような意識を持ってしまい、日常の運用仕事に対して、自分がグレードダウンしてしまう感じというのが否めなかったのではないかと後から考えると思う。

割と開発だけをひたすらやってきたエンジニアであれば、そういう意識は割とありがちなんじゃないかなと思ったりする。

まぁそういうタイミングをきっかけとしてWebの世界に転職したので、そう思ったことは間違いではなかったのかもしれない。

その後、受託ビジネスのエンジニアとして仕事をしていた。当時の会社は新規の案件が多かったので、ある意味、毎日が新規開発の仕事だったのだが、少し、自分が成長してくると、考え方が少し変わってきて、ひたすら新しいコードを書き続けることよりも、既に存在するコードを継続的に改善していくことで、具体的なお客さんがハッピーになる姿というのを見たくなるようになってくる。

技術、技術と追っかけるのではなく、技術をツールとして活用し、例え毎日同じような技術しか使わなくても、ビジネスに貢献しつつ、サービスを改善していけることこそが、インターネットっぽいのではないか？ということに気がついてくる。

そう思ったので、Webサービスの企業に転職した。

一度そういうことに気がつくと、プロダクトの完成というのは、実はゴールでもなんでもなくて、スタートでしかないということに気がつく。

特にWebサービスにおけるエンジニアの価値というのは、その後の成長にどれだけ寄与したか？どれだけ頑張って改善に頭を使ったのか？ということにこそ価値があることに気がついてくる。

たとえその人が業界のスター選手だったとしても、アプリやWebサービスができたら、すぐに終わった気になって会社辞めそうだよねって人は、あんまり元のチームから評価されていないと思っても差支えはないと思う。ただ、それはそれで高度な技術のブースト的意味合いで求められる部分もあるのだろうが、ソースコードの運用を考えると、そういう人に依存してしまうのはリスクが高くて、あまり効率的ではない。

最近でこそグロースハックという言葉で、僕が2006年ごろにペパボに転職した時にやりたかった「継続的改善」という試みに、素敵な役割や役職名ができているので、こういうのは既に当たり前になっているのかもしれないが、受託で新規案件続きで慣れてきてしまった人や、冒頭に書いた15年前の僕ぐらいの立ち位置でやってきた人は、知らない可能性があるので、少しメモとして書いてみた。

あくまでもプロダクトは完成した時点がスタート。そのプロダクトを原資としてビジネスを推進していくわけだから、そのPDCAを如何に回せるか？ということに頭を使っていかないと、実際のところフロントエンドのソフトウエアはあまり作った意味がなかったりする。（少し極論だが）

ソフトウエアが完成して終わりであるならば、受託の会社さんにお願いすればそれで済むはずなので、投資を受けたら、そのお金を持って受託の会社さんにお願いすれば、ビジネスがうまく行くはずだ。でも、実際はそうじゃなくて大抵のケースで内製で作ってるわけで、それは完成後のソースコードの運用も最適化することを前提としているのは忘れないでおいて欲しい。

ただ、冒頭の僕がそれを偉そうに言える立場ではないので、終わった気になって会社をやめてしまわないように、ちゃんと先々の道筋を提示することは上司の仕事としてはマストかなとは思う。気をつけましょう。

【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください