(1年前の)転職エントリ

1年ほど前の話になりますが、株式会社ワンモアに転職しました。今回はなんで転職したのかという動機を書きたいと思います。

そもそも僕は、70歳でも80歳でも、体が動く限りは市場からみて価値のある人間でありたいと思っています。定年退職なんて論外ですし、それまでに市場から退場させられることを最も恐れます。そう考えたときに、エンジニアとして働き続けるのは現実的じゃありませんでした。これはエンジニアの35歳定年説がどうこうという話ではなく、ひとつの職種で50年間働くこと自体が時代にそぐわないだろうと。50年後には50年後に必要とされている職種があり、その職種は今はまだ存在していないと考えるのが妥当です。きっとエンジニアという職種は50年後にはありませんし、今ある他の職種も同様でしょう。唯一、50年後も残っていると思う職種があるのですがそれはまた別の記事で。

ではどうすればいいのか。一言でいえば、「適応」することです。ダーウィンが言うように、生き残るためには変化しなければならない。その時代に求められている職種に、自分を変えていかなければいけない。そういう視点から見たときに、自分には変化する経験が足りていないと思いました。僕は、短期間で大きく稼いでリタイアしたいという考えは持っていません。80歳でも現役でいること。そのためには、5年、長くても10年おきくらいで自分を別の職種に移していかなくてはいけません。これはいわゆる出世のような軸とは全く別の話になります。

もちろん、10年後を見据えて、どんな職種が市場から求められているのか、そして自分に適性があるのかということを考えることは重要ですが、それ以上に重要なのが、自分を次の職種に適応させていく力と経験でした。当時30歳のタイミングにおいて、次にどんな職種を選ぶのかより、職種を変えることそのものが重要だったのです。

なので、当時の僕の狙いとしては、「エンジニアではない、別の職種に移る」ということで、それを実現するためにCTOとしてワンモアに転職しました。とはいえCTOってエンジニアじゃんという話で、進捗としてはまだ半分です。個人的には早く僕がCTOをやらなくても開発が回る組織を作ってしまい、僕はサービスそのものの成長に力を注げるようになっていければと思っています。そこまでできてようやく、職種を変えることができたと言えるのでしょう。

CTOには、自分ががんばる、みんなでがんばる、文化を作るの3つのフェーズがあるなんて聞いたことがありますが、2つ目のフェーズの形はできてきています。僕の名刺からCTOの肩書が外れるときが、転職の目的が本当に達成されるときということになりますし、そのときには今よりももっとビジネスに貢献できるようになっているんじゃないかなと思います。

CTOとしてもまだまだ未熟なうちからCTOのあとのこと考えてるなんて鬼に指さして笑われそうですが、こんなことを考えながらやっております。これからもよろしくお願いします。

プログラマは棋士である

昔、こんなことを言っている人がいました。

プログラミングなんて、しっかりロジック立てて、
その通りに書くだけだろ?

もちろんこの人はコードなんて書けません。自分は自分の領域をプロとしてこなすから、お前はお前の領域をプロとしてこなせというタイプ。そのポリシー自体は別にいいのですが、こんなこと言う人とは絶対一緒に仕事したくないと思ったものです。

確かに、ロジック立ててコード書くだけなんですが、それは例えば将棋だって同じことです。敵味方合わせても駒は40しかなく、動き方が決まっているのですから、ちゃんとシミュレーションすれば勝てるはずですね、羽生善治にだって。でも実際は勝てないんですよ。そんな暴論を振りかざすには人間の頭は処理速度もメモリも足りなくて、じゃあ紙と時間があれば良いのかと言ってもどうせどこかで間違えるんです。

全部の手を読む余裕はない。だから必要そうな手だけを読むわけですが、これはもうスキルや経験の世界であって、「だけだろ?」なんて言えるものではありません。

そして、プログラマが音楽を聴きながら仕事をしていたり、夜間など人がいない時間に仕事をするのも、プログラマが棋士だからです。将棋を指すのは、和室だったり縁側だったりしますが、それは決まって静かな場所です。

図書館のような環境を、とまでは言いませんが、もしプログラマの部署があったなら、その部屋くらいは電話を置かなくてもいいのではないかなと思います。

WEB業界にいるのに、今からプログラミング始めるのは気が重いあなたへ

もちろんすべての仕組みを理解する必要はないと思うが、仕組みを理解する必要がある場合は、理解しないと損をするし、そんな人が多いと社会的に危険ですらある。なので、その気になれば理解できる、くらいの科学体力のようなものは持っておくべきだ。

科学と向き合うの発展とも言えるが、WEB業界の中におけるプログラミングに対しても同じことが言える。英語だ、ファイナンスだ、マネジメントだ、大いに結構だが、WEB業界においてはプログラミングのほうが実用的だと思う。多少は自分で知識と経験を持てば、ある程度プログラマの力量を見定め、タスクの難易度がわかるようになる。プログラムが聖域になってしまうと、プログラマを神か下僕かの両極端でしか見れなくなり、双方にとって不幸だ。

続きを読む

期間契約

タスク単位で外注すると6人月と見積もられたタスクは、2人常駐の期間契約にすればきっと1か月で終わる。しかも、見積もり上の駆け引きや、受け入れのわずらわしさとおさらばできる。 発注して作りながら3カ月も経つころにはもっと良い案が浮かんでいるのが当たり前で、そんなのをいちいち仕様変更とか交渉するなんて労力の無駄。 タスク契約と期間契約で何が違うかというと、キックオフ時に書いた青写真への執着度が違う。積極的に朝令暮改していくには、契約書は逆に足かせになる。

カプセル化

下請けの健康状態を把握していない東電は無責任なのか?少なくともSIerなんてのは、下請けに過労死した人が出ても気づかなそうだし、病気で休んだり退職したりしたら文句すら言いかねない気がする。 頼んだ先の中身ことはわからないというのは、プログラミングではカプセル化と言ってむしろ推奨される。誰だって把握できる範囲には限界があるから、他に任せることで負荷を軽くする。 まぁ、東電もSIerも無責任というのが実際のところだろうけど、規模で言ったらたぶんSIerの方が大規模に無責任。ビルの建築中の事故とかあるだろうから、デベロッパーとかもなのかな?という風に、キリがない。