おおばログ

おっさんプログラマーのブログ。

キーボードとかスキャナの会社を退職しました

f:id:tworks:20180629224006p:plain

キーボードとかスキャナの会社を昨日退職しました。フリーランスの頃から勤務していて途中なんやかんやあって正社員になり、2000年から勤務していたので18年ちょっとお世話になったことになります。せっかくの節目なので、ログにまとめてみたいと思います。

何やってたの

システムインテグレーター(SI)を担当するシステムエンジニア(SE)でした。ざっくりいえば受託開発を行っていて、クライアントからオーダーメイドのシステム・アプリの開発を受注し納品するお仕事です。受注したあとは、社内リソースで開発するかリソースが足りない部分は外注(してマネジメント)するパターンが多かったです(よく聞く多段請負や外注さん丸投げはやらない主義)。

18年の中で、プログラマー → サブリーダー → リーダー(単一クライアント) → リーダー(複数クライアントかけもち)みたいな王道パターンを経験しました。

気づきのきっかけ

サブリーダーをやっていた頃、サブシステムの設計をすることが増えましたが、引き続きコードもよく書いていました。頃合い同じころに id:tmyt がグループ会社に入社してきて、グループ会社WANのIRCで相談に乗ってもらったりで助かっていました。そんなある日 id:tmyt がチャットでこんなことを書いたのです。
「おおばさんは開発者じゃないしなー」
何気ない id:tmyt の一言が俺を傷つけた?いいえ、彼はいつも忌憚のない意見をくれていたのでこのセリフも真正面から受けざるをえませんでしたし、その頃自分でも「開発者としてセンスがないな」ということに気づいていました*1。じゃぁどうしようか...コードを書くセンスを磨くか?他を目指すか?など、いろいろ考えるきっかけになりました。

どうしたか

コードセンスを磨くことをスパっと諦め*2、立ち位置を変えることにしました。id:tmyt のようなセンスの塊みたいな開発者が居たとして、彼らのパフォーマンスを最大限引き出し楽しく仕事ができるようにしようと、そこに対して自分ができることをやろうと考えを切り替えました。

具体的になにしたか

開発環境を良くする

開発環境=開発マシンを良くすることが手っ取り早いです。開発マシンの購入は人件費とくらべたら安いものですし、そもそも経費にできるので難易度が低いんですよね。その頃は自分で企画・提案書を作成してクライアントからの受注を伸ばしていたので、自分の意見が比較的通りやすい状況になっていました。そこを利用して半年に1回は新規マシンを購入し、自分のチームメンバーは3年くらいで最新スペックのマシンにローテーションできるようにしました。

開発者に丸投げしないことを肝に命じる

どんな開発者でも神様ではないので、決まっていないものに対して開発することはできません。でもこの業界、ときどき理不尽の風が吹きます。
「何もきまってないけど、スケジュールが決まっているから、開発走らせよう」
それは開発者にしわ寄せしているだけであってはならないことです。だから開発をお願いするまでに、次のことはキッチリやることにしました。

クライアントのことを透過的に伝える

このシステムを作る明確な理由・動機、機能の必然性・優先順位など、クライアントときっちり握ったあと、チームメンバーに丁寧に説明することを心がけました。誰しも開発するなら良いものを作りたいと思うのが自然で、そうであれば何が優先されるかを把握したいというのは心情ですよね。また開発側の提案や課題などをクライアントに説明し、必要な調整を行うようにしました。

設計に対するPoCと見積り

要件をもとに設計を行うわけですが「絵に描いた餅」の設計にならないように最低限の検証コードは自分で書くようにしました。自分でコードを書くことで、設計の勘所や課題が見えてきたりスケジュール感の根拠も作れるメリットがあります。センスが無いなりにでもコードが書けてよかったなと思いました。あとはインフラ設計(AWS/Azure)も出来るよう日々勉強しました。

信頼関係を築くことに手を抜かない

同じ会社のメンバーであっても社外のメンバーであっても所詮は他人同士。お互い信頼関係がなければいい仕事はできないと考えています。ですので彼らを常にリスペクトし、彼らの意見にできる限り傾聴し建設的に議論することを心がけました。

そのほか

外部設計をきっちりやる、詳細設計も開発者と相談して必要であればやる、スケジュールが想定とずれてきたらクライアントと調整する...当たり前のことを守ることを頑張りました。

結果どうなったか

某社のエースと仕事をして、そのプロジェクトが終わったとき
「これまでで一番仕事がしやすかったです」
という一言をもらうことができました。
f:id:tworks:20180630001858p:plain
自分のアプローチが少なくとも間違ってなさそうだな、と本当に嬉しい一言でした。

あれ?じゃぁなんで辞めちゃうの

受託開発が窮屈になってきたからです。次の「デメリット」の方を強く感じるようになったからですね。

受託開発のメリット

  • 自社プロダクト開発のように、特定テクノロジーにロックインされることが少ない
    • クライアントの数だけ新しいテクノロジーに触れるチャンスがあり、そこに挑戦することで、開発側の経験や知識を増やしていくことはできると思います(できました)。
  • 面白案件に関わるチャンスがある
    • 自分の場合、World WideなNDA案件に多数関わることができました。某DRMを使ったシステム開発で国内最初の人になれたりとか。

受託開発のデメリット

  • クライアントの望む以上のことができない
    • 予算にしてもスケジュールにしてもクライアントの都合が最優先されます。これは時にBestよりBetterな(もしくはそれ未満の)戦略を取ることがあるということです*3。開発側からみた場合、妥協したプロダクトが出来上がってしまうことが時にあるということです。
  • チームメンバーが固定しにくい
    • 案件によって規模や期間が異なるため、その都度メンバーを組み替えることが多かったです。これはアジャイルなどを用いたチーム成長をやりにくくする状態になります。

経験とともにキャリアプランが変化した

そうして経験を積んでいくうち
「固定されたチームを持ち、そのチームを成長させつつ、そしていいプロダクトを出し続けたい」
そんな気持ちが強くなったわけです。それは今の会社では実現できないため辞めることを決意しました。キャリアプランのミスマッチが出てきたわけですね。それが敵うであろう次の会社はすでに決まっていまして、来週からJOIN予定です。お約束の「試用期間」がしばらくありますので、そこが終わったあたりで状況をお伝えできればなと思っています。

謝辞

この場を借りて、転機のきっかけとなった id:tmyt と某社のエースさんに、御礼申し上げます。

おまけ - 上司や仲間に退職を伝えた時の反応

快く送りだして頂けた上司に感謝。

  • 上司A「そうか...新天地でも活躍期待してるからな!」
  • 上司B「今回は本気やな?」
  • 同僚A「お!ついにですか!」
  • 同僚B「えーーーーーっ!!!独立するんじゃなかったんですか...」
  • クライアントC「うちじゃないんですかイヤーーーーーーッ!」

*1:id:tmyt と比較すると "並の開発者はすべてセンスなしレベル" になるという話もある。

*2:いまもコードは書き続けていますが、チームビルディングなどの別の役割に時間を割くようにしました。

*3:ほとんどが政治的理由なもの。どうみても使いにくいUIに対し「これ絶対使いにくいのでこうこう変えた方がいいです」と提案しても、クライアント上層部が「OKこれで!」ってなると、クライアント企業のパワーバランスによりそのまま行くことが往々にあります。ここは何とかしたかった悔いの残るところです。