C2Cサービス開発からキャリアが始まり、その後開発基盤組織というものに長年従事して、その中でマネジメントも経験して、また普通のC2Cなサービス開発エンジニアに戻って、それも1年が経ちました。

開発基盤組織に長年従事してサービス開発にいざ戻ると「はたして自分はサービス開発をやっていけるのだろうか？」というような漠然とした不安が発生したりします。いまとなっては杞憂な話でしたが、それに驕らず危機感を持ち続けながら日々仕事をしています。

この不安というのは面白い事に、非常にポジティブです。日々の業務の中でただ「良いコードを書く」「より内部品質・外部品質の高いソフトウェアを開発をする」「よりxxxなチームビルディングに貢献する」だけであればそこに何の不安や迷いはないわけですが、長年ソフトウェアエンジニアをやってきた人間がいつまでもその目線でいて良いのか？という疑問があって、それに対して「良くないんじゃないか？」という回答をちゃんと持っているからこそ不安が生じるのです。

これは決してそうでない人を卑下するものではないです。プログラミングやソフトウェア開発の世界には幾多の課題があり、わたしもすべてを理解できてるなどとは到底いえない未熟な身ですし、引き続き「プログラマー」や「ソフトウェア開発エンジニア」としてスキルを伸ばしていく事が良い事であると信じています。これはあくまでもキャリアパスの違いで、スタッフエンジニアのカテゴリの一つだと捉えています。

ソフトウェアエンジニアにとって、ソフトウェア開発というのは甘い蜜の宝庫です。無限にリファクタリングをしたくなりますし、高速化もしたくなりますし、テストも書きたくなりますし、近年は技術にトレンドなんてものもあります。コーディングや技術スタック以外にも、開発プロセスには無限に課題があります。エンジニアは問題を解決したがる性分なので、本当に豊かな世界だと思います。

しかしながらその成果物がビジネス価値を産まなければ、生産性は「0」です。どんなに綺麗なコードでも、どんなに中ですごい事をやっていても、開発効率が向上しても、売れなければ、0です。生産性を0にしないという意味では「開発者コミュニティーへの貢献」といった話もありますが、それはこの文脈とは関係なくやっていくべき話なので省略しています。

ここで冒頭に書いた「ソフトウェアエンジニアが実装・設計・開発プロセス・チームビルディングだけに留まっていて良いのか？」という疑問が挙がってきます。この疑問には非常に多くの前提(職務分割、会社事情など)が絡んでいますが、例えば「こっちは何とかするからそっちは任せた！」「頼んだ！」として、結果としてうまく行かなかった時に、それを言い訳にするという心持ちは、同じサービス開発に携わる人間としてどうなのでしょうか。流石にEvilなのではないでしょうか。心持ち云々は抜きにしても、ソフトウェアエンジニアとして「外的要因で生産性が0になる」事があって良いのでしょうか。

例外的に「そもそも無駄な開発を回避する意味で、短期的目線で生産性が0だった」という事がありますが、それはマイナスを0にできたという事なのでプラスに捉えて良いでしょう。それを除いた場合は「あって良い訳ない」というのがわたしの現在の回答です。サービス開発エンジニアというのはそういう意味では「生産性を0にしない技術を体系化していく」所が目標の1つとして立てられるでしょう。

これはプロダクトオーナーや他職種を信頼しないという話ではありません。非常に世知辛い話ですが、サービス開発は「時の運」だったり「人類には早すぎた」だったり「約束された勝利の剣」という概念があって、どんなに優れたプロダクトオーナーが携わっていても売れなかったりビジネス価値を生むことができないという事があります。その逆も然りで、金の弾丸が全てを解決する事もありますし、金の弾丸だけではダメだった、という事もあります。

金の弾丸ではダメだったという結果は資本主義社会において目も当てられない話ですが…それはさておき、サービス開発はそのような不安定さを「継続的に」乗り越えていかなければなりません。サービス開発に携わるソフトウェアエンジニアは、ソフトウェアエンジニアとしてこれまで培った問題定義・問題解決能力を用いて 「ビジネス的価値がある(あるいは売上が十分にある)サービスを持続的に提供する確率を上げるためにできる事はあるのか？という所を詰めていく必要があります。

それをやっていくとなると「技術」のスコープが一気に広がるのは容易に想像できると思いますが、それだけでなく、視点も変えなければなりません。例えばソフトウェア開発のプラクティスとして「予測できない未来は予測しない」といった話がよく挙がりますが、継続的なサービス開発においては「予測可能な未来は予測する」「未来を予測できないのであれば未来を確定させる側になる」といった具合に視点に切り替える時もあります。 もちろん「今までと同じ開発パフォーマンス・外部品質・内部品質を短期的にも中長期的にも維持しながら」さらにやる必要があるため、爆速で設計もコーディングもテストもできる事が前提になります。

全ての技術をものにする事は人間性能的に不可能な所も出てきてしまうので、では具体的にどんなスキルがより重要なのか？みたいな話が出てきますが、キリのない話なので有料記事で…という事にしておきます。もちろん有料記事なんてものはなく、ただ面倒臭いだけなので、気が向いたら書くかもしれません。

ソフトウェア開発にゴール(完了)は定義できても、それはソフトウェアそのものの完成とはいえません。ソフトウェアのゴールも、ソフトウェアエンジニア自身では「ゴールを定義する」までしか達成できません。ソフトウェアをゴールさせるのはユーザです。使ってくれる人がいて、思い描いていた絵と重なって「ちょっとだけゴールに近づいたなあ。ありがてえな。」の繰り返し。先に寿命が尽きてしまう事がほとんどです。ソフトウェアを「完成」させる事はユーザですらできないのかもしれません。ではそこに携わるソフトウェアエンジニアが、実装・設計・開発プロセス・チームビルディングに留まっていて良いのでしょうか。さらに一歩進んでやるべき事はなんなのでしょうか。真の意味で生産性を0にしないプラクティスってなんなのでしょうか。職能横断的な活動の本質って何なのでしょうか。個人的なお気持ちとしては、エンジニアリングマネジメント・UX・データ分析以外の話が良いです。

誰かに伝えるという意味では色々と中途半端な内容にはなりましたが、意思を持って他のキャリア選択肢を選択せず、C2Cなサービス開発の現場をやり続けているソフトウェアエンジニアの、プロダクトそのものの未来や夢の話をもっと聞きたいんだよあという話をしたかったのだと思います。

人類が読むべき漫画を貼って終わりにします。

神田ごくら町職人ばなし （一） https://www.leed.co.jp/9784845861637