Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

退職エントリ

14年勤めたソフトウェアベンダーを今月末で退職します。私が入社したころは新卒が3年で辞めるという話があって、漠然と自分も似たような感じになるのかもと思っていたので、まさかここまで長く在籍することになるとは想像していませんでした。お世話になった皆様、ありがとうございました。

職場近影(2018年1月)

一生に何度もあるイベントではないので、14年前に立てた入社目的を満足できたのかと、14年を経て自分の何が変わったのかを書いてみます。

私は誰?

手広く働いてきたジェネラリスト寄りのITエンジニアです。研究開発、性能改善、製品開発、要件発掘、品質保証、テクニカルライター、OSPO、セキュリティ、SREなどを色々やってきました。「何やってる人なんです?」と言われてうまく説明できた試しがありません。

OSSプロジェクトではクラスファイル解析ツールSpotBugsSLF4J向け静的解析ツールのメンテナ、actions/setup-javaのdependency cacheの実装もしています。

入社理由は満足できたのか

私が今の会社に入社した理由は3つありました。そしてそれらはこの14年間を通じて満足できたと思います。

  1. ユーザ数が多く、得られるフィードバックの質と量が期待できた
  2. 製品を持ち、それが社会に与える影響が大きいと思えた
  3. 経営陣が提唱する理屈・哲学に納得・共感できた

私は何がやりたいのか、あるいは何がやりたくないのかという話 - Kengo's blog

1について。ソフトウェア提供の形がパッケージソフトウェアからウェブアプリケーションに広がり、リーン開発手法の浸透やクラウドの普及、可観測性(Observability)技術などを通じてソフトウェア開発者が得られるフィードバックは大きく変化しています。一方でソフトウェアの向こうに人がいるのは変わらない事実であり、多くの顧客を抱えつつも個別の顧客と深く関わる機会もあるBtoBビジネスを経験できたのはとても幸運でした。顧客とのコミュニケーションを通じて得た経験は、アルゴリズムやデータ構造に関する知識のように今後のキャリアを長く支えてくれると思います。

2について。ソフトウェアには短いライフサイクルを持つものもありますが、私は自分が思っていた以上に長いライフサイクルを持つものが好きみたいです。レガシーと呼ばれるシステムもそうですし、FindBugsみたいなOSSもそうなんですが、長い実績を持つシステムに手を入れて品質を向上し長持ちさせるための工夫を考えて実行するのが性に合っていました。その点では請負開発やコンサルティングではなく、製品を抱えて育てるパッケージソフトウェアはとても適していたと思います。社会的課題の解決に貢献できている実感も定性的定量的に得られ、長期的にモチベーションを保つ支えになりました。

3について。創業経営者から色々学べたのは事実ですが、上司や同僚からも多くのことを学びました。これは当時の自分の想像を大きく越えた体験でしたし、「組織は人」という価値観を醸成するには充分すぎる体験でした。駐在員も経験し、世代や文化や価値観の違いに起因するコミュニケーションの難しさにも幾度となく直面しましたが、この多様性が多様な市場やコミュニティとの交流において価値を生むこともバズワードではなく体感として理解できた気がします。魚座の星占いでよく「清濁併せ呑む」ってワードが出てくるんですが、アレが組織の競争力と魅力の源泉として必要になる時代なのかなとか思います。

仕事に対する解像度が上がった話

この14年で趣味プログラマからプロプログラマ、そしてプロ開発者へと自己認識が変化したと感じています。

まず趣味プログラマからプロプログラマに自分の意識を変えることに、のべ2年はかかった気がします。プログラミングにおけるアマチュアとプロの大きな違いとしては例外処理や保守性、運用容易性への意識がよく語られます。私の場合は、コーディングをする際に機械だけではなく人にも目を向ける必要があるのだという気付きが大きなきっかけとなりました。コードを勝手にフォーマットしてコミットして迷惑を掛けるとか、コメント内容が古いシステムの発掘をするとか、なんでこんなログがここにあるんだと過去の自分に苛立つとか、めちゃくちゃ性能保守両面が考えられている実装に出会って感激するとか、そういう経験が大切でした。一応社会人になる前から他者のコードを読んだり自分のコードを公開したりはしていたはずなんですが、仕事として成果にコミットすることが私には学習効率を上げるために必要だったのでしょうか。フリーソフトなら「気に入らなきゃ使わなくていいよ」と言えてしまいますし、機能性や互換性よりも書き手の手間を減らすことに注力しがちだった気もします。

そして保守性や運用容易性に気を配るプロプログラマになれてさらに数年、自分の仕事がプログラミングでもシステム構築でもシステム運用でもない、課題解決なのだということに改めて向き合う精神的余裕が出てきました。業務におけるマネジメントの割合が増えてきたこととも無関係ではないと思います。

システム実装はミケランジェロが言う「余分なものを取り除くだけで理想の像が現れる」プロセスとは大きく異なります。似たシステムでもチームが違えば理想も変わりますし、要件が同じでも使える資源や技術が変われば自然と適用する技法も変わります。特に重要な特徴は、チームや資源、技術といったこれらの条件がすべて「時間」を変数としていること、つまり「常に正しい正解」が存在しないということでしょう。以前紹介したトリさんのスライドがとても参考になります。

よって「どのようなシステムを目指すのか」「何が余分なものなのか」をチームで議論することは依然重要ではありますが、それ以上に「よし!私達はこれで行く!プランBはこれ、プランCはこれ!いっちょやってみっか!」という自信と勢い、間違ったときに即時修正するための評価判断手段こそが必要です。そしてこれらは目標設定と戦略と迅速性によって、すなわちリーンな組織と情報公開(組織の可観測性)そして迅速に価値を届ける開発体制によって生み出されます。

この体制の実現はマネジメントとかリーダーシップとかソフトウェアエンジニアリングとかが噛み合うとてもおもしろい課題領域なのですが、この「課題と現状をすべて卓上に並べて明らかにし即時対応する」働き方はとても疲れるのですよね。GitLabのHandbookとかAmazonのWorking BackwardsとかGoogleのデザインドキュメントとか、コミュニケーションを円滑化かつ非同期化する手法はいろいろ知られているのですが、この「疲れる」ことに対する心理的抵抗感をいかに下げるか・チームとして越えるか、言い換えるといかに他のチームひいては顧客の信頼を獲得するかが大切なのだな、そしてプログラマやマネジメントとしての知識や技術そして自分自身の生き様が信頼獲得の武器になり得るのだなということが見えて、初めて「プロの開発者」になれた気がします。

まとめ

技術による社会課題の解決にこだわる会社に新卒入社して多くの学習の場を経験できたことが、自分の人生の大きな財産になりました。 関係各位におかれましては、至らぬところの多い私にお付き合いいただき、ありがとうございました。 新しい職場においても、自らの成長と社会課題の解決に向けて工夫して参ります。