Forkwell Press | フォークウェルプレス

SHARE

目次

目次

SHARE

エンジニアの軌跡

「良いプログラマーは、短気で、傲慢で、怠惰であるほど、大きく成長できる」吉村拓人(カラビナテクノロジー)~Forkwellエンジニア成分研究所

topの画像

カラビナテクノロジー株式会社にて、『顧問エンジニア事業』に取り組む吉村拓人氏に35歳で転職をした実体験やエンジニアに必要な3要素「短気・傲慢・怠惰」を中心に伺いました。

記事の終わりには吉村氏から転職者に向けたメッセージもいただいておりますので、転職を考えている方は是非とも参考にしてください。

お客様と一緒にサービスを作り上げる

――現在の業務内容を教えてください。

吉村拓人(以下、吉村) 現在は、今年から立ち上げた『顧問エンジニア事業』に取り組んでいます。社内にエンジニアを抱える中規模以上の企業さまやより人員の少ない企業さまを対象に、得意分野が違う3名編成の1チームでお客様のIT面をサポートするのが事業内容です。

設計書に基づいてコーディングしたり、開発した製品や設計書を納品することは基本的にやっておりません。お客様のやりたいサービスを伺いながら、アジャイルで「こういうシステムが必要なのでは」というモックアップを作ったり、実際に動くものを作りながらお客様と一緒にサービスを作り上げる業務です。

東京より小さい経済圏である福岡で始めたので、比較的、小規模事業のお客様が多いですね。福岡市自体がスタートアップ支援に力を入れていますから、そういった部分をサポートしたい思惑もあります。

現在の業態を選んだ理由

――普通の制作会社ではなく、この業態を選ばれたのはどういう理由があるんですか?

一定の事業規模が求められる

吉村 1つは、通常の制作でやろうとすると、お客様にも一定の事業規模が求められるためですね。完成形がある程度見えていないと、そもそも請け負うことは難しいですし、こちらとしても「いつまでにこういうものができます」と言えないんですね。

そういう理由もあって、我々は請負ではなく、月額サービスとしてやっています。事前に完成形と費用を決めてしまわないので、完成までの期日を早めたければ「じゃあこの機能はつけずにシンプルにやりましょう」といった方針変更を柔軟に取ることができます。

システム開発は失敗するケースが多い

もう1つは、システム開発は失敗するケースが多いことです。これは、エンジニア側というか開発会社側の事情ですけども。僕は以前大規模なSIerにいたんですが、本当に儲かるプロジェクトって一部だけなんですね。ほかは、赤字プロジェクトが結構な数あるんです。予算と納期だけは決まっているようなプロジェクトが。

ITプロジェクトの管理手法自体、ビル建設工事にならって進行や予算決めがされているところもあります。なので、ちょっとそのやり方は、小規模だったり、システム開発が初めてのお客様には、無理があるな、と。アジャイルで小刻みに作っていきながらリスクを減らそうという現在の時流もあり、「料金体系もそれにならった形にすべきだよね」ということで、このやり方を採用しています。

1枚目の画像

35歳で転職、スキルアップを実感する日々

――今まで、顧問エンジニア事業のような仕事をされていたことはありますか?

吉村 いや、全くないですね。経歴の話をしますと、去年に大きな決断をして、同じITエンジニアではあるものの、転職をしました。もともとは経済学部卒で、情報工学系の出身ではないんです。学校の授業で受けたプログラミングが面白かったので、大手SIerの子会社に入社し、研修を受けて、銀行の勘定システムを8年間ほど開発しました。家の事情で、福岡にUターンした後は、大手のSIerで証券システムで金融系システムを作っていました。

ただ、「SIerあるある」だと思うんですけど、年次が上がるにしたがって、プログラミングよりプロジェクトのマネジメントを求められるようになったんですね。基本的には、夜まで会議に出て、その後少しだけ開発する…みたいな生活になってしまって。

1年足らずで退職した経験も

また、その大手SIerは、全国企業だったんですが、社内で東京と地方の格差みたいなものも感じたんです。そういうところに不満を感じ、「もう一度、プログラミングをしていた頃の仕事に戻りたい」と思ってベンチャーに転職しました。ただ、その会社もあまり合わなくて(笑)。1年足らずで辞めてしまい、前職の先輩がご存知だったカラビナテクロジーに転職して現在に至ります。

現在は3人1組のチームで、基本的には1本のシステムをやっています。メインはバックエンドなんですけど、フロントエンド、基盤、設計、開発からテスト、保守、運用まで全員できる状態を目指しています。大手SIerの仕事と比較すると、だいぶ違いますね。

――どの辺りが大きく違うところですか?

吉村 大手の仕事、特に金融系だとITの歴史も長いので、いろいろ厳しい条件があるんですね。付随する品質確認やいろいろな手続きが決められています。ITエンジニアとして、手を動かして開発する以外に、そういう決まりごとに対応していくのが業務の大半を占めるんですね。

いまはそういったものは基本的に何もなくて、ある意味自己責任です。今まで自分がやってきたテスト手法を実践しなければ即障害につながりますし、3人1組であるにせよ、完全に独立したエンジニアとしてシステム開発をやっていくということが、大きな違いですね。用意された環境の上で動くプログラムを作るという形から、性能の見積もりまで含めて、全部自分でやる、といった形に変わりました。

――ということは、今は日々、スキルアップしている実感があると。

吉村 そうですね、35歳で転職に踏み切った一番の恐怖感みたいなところはそこでしたね。求められるスキルが、ITではなくなっていく実感があったんです。調整力みたいなものは確かに必要ではあるんですが、そもそも「プログラミングって面白い」と思って、この世界に飛び込んだわけなので。新しい技術を若い子に任せて自分は調整役に回るうちに、どんどん置いていかれる感がありました。

天国のような現在の環境

そう考えると、今は完全に天国ですね。十年来、Java中心でしたが、Elixirという新しい言語で開発も行っています。チームの中では、一番年長ですけど、日々すごく刺激を受けながらやってますね。

Elixirを使い始めた当初は、大量データでも耐えられる性能や並行性に着目していたんですが、直近では「いかに楽にバックエンドを実装できるか?」が、Elixirで叶っている領域で、だいぶ省略化できていますね。

またElixirは、業務で使っているだけで無く、福岡発のElixirを広めるコミュニティ「fukuoka.ex」の運営メンバーとしても、日々、研究・研鑽を積んでいます。

2枚目の画像

隔月で開催しているMeetUpでは、だいたい私がトップバッターで登壇していますが、もともと人前でスピーチするのは得意では無くて。ただ、もう1年近く、fukuoka.exでトップバッターをやってきたので、だいぶ登壇にも慣れました(笑)。

最近は、大規模ユーザトランザクションのシステムだと、よく詰まってしまうDBサーバをボトルネックにせず、アプリケーションサーバを増やせばスケールアウトできるライブラリをオープンソースとして開発しました。

これは追々、我々の業務が拡大した際にも活用しますし、他社の大規模システムやElixirを活用する企業でも使って欲しいな、と思います。

世の中の「企業もオープンソースを作る」という流れの中で、我々もオープンソースを提供する会社である、というブランディングとして打ち出していければなぁ、という風に思っています。

こんな感じで、業務とプライベートの両面で、成長を実感できる毎日です。

4枚目の画像

大事にしている2つの言葉

――業務を行なう上で、大事にしているモットーや好きな言葉があれば教えてください。

『データオリエンテッドアプローチ』

吉村 『データオリエンテッドアプローチ』という言葉があります。データを中心に設計にアプローチするという考え方です。

僕は、最初に入社した会社の頃から、データベースやデータ設計が好きで、その頃は言語としてはJavaが主流でした。その後に、アスペクト指向とかサービス指向などが出て来たんですけど、僕の中ではデータが中心であり、「お客様の業務がデータモデルとして、どういう構造なのか」というところは病的なまでに突き詰めますね。

ITエンジニアに必要な3要素「短気・傲慢・怠惰」

もう1つは「短気・傲慢・怠惰」ですね。キリスト教の「7つの大罪」でいうところの3つが入っています。

――飽きっぽかったり既存のサービスに満足しない方が、開発意欲が湧くと。

吉村 そうですね。『怠惰』は、単純に同じことをずっと頑張ってやる人って効率化しないので、良いプログラマーにならないんです。ラクをしたいと思うから、システム化するわけで。『短気』は、早くレスポンスが返ってこないとイライラする人がどんどんレスを早くし、気長な人より結果としてパフォーマンスが上がることが多いと。そして『傲慢』は、自分に自信がないと、そこそこの仕事で満足してしまうので。お客さんに対して「何くそ」と見返してやるぐらいの人の方が、良いプログラマーだという話だったと思います。

このうち、『怠惰』はすごく実感しますね。受験勉強とか頑張ってきたタイプの子が力技で徹夜で頑張ってたりするけど、それは仕事としてどうかな、と思ったり。ちょっとしたコードを書いたら、その仕事、10分で終わるんだけどな…みたいなケースはあるんですよね。ITエンジニアは、自身のリソースを突っ込んで頑張るのは、本当に最後の手段と考えないと効率は上がらないと思いますね。

事業のローカル性を大事にしたい

3枚目の画像

――ここからは、吉村さんが働く上で大切にしていることについて、「事業内容」「仲間」「社畜度(会社愛)」「お金」「専門性向上」「働き方自由度」の6つの項目から合計20点になるよう、点数を振り分けていただきます。

専門性向上 4点 「専門性と効率を高めていきたい」

システム開発における効率化はつまり「過去の資産の再利用」なので。今は人と人とをつなぐサービスに特化していきたいと思ってます。突き詰めるとシステム開発手法も、作ったものを広めるグロースハック手法、マーケティング手法も再利用できると思いますね。そういうところにアプローチして、専門性と効率を高めていきたいですね。

仲間 4点 「刺激を受けて助け合えるエンジニアがたくさんいる」

最終的にフルスタックエンジニアを目指したいのですけど、単純に量としても1人でできることには限界があります。刺激を受けて助け合えるエンジニアが周りにたくさんいるのは、すごく重要だなと思っています。

お金 2点「最低ラインの収益性を担保したい」

事業の収益性もあるんですけど、2って僕の中で最低ラインです。最低ラインのものがないと仕事を選べなくなってしまって、良くないものでも作らなくてはいけなくなったり、見切り発車しないといけなくなる。がっぽり儲けたいというより「最低ラインの収益性を担保したい」というところで2ですね。

事業内容 5点 「ローカル性を大事にしたい」

興味があって有意義な事業に対して力を注ぎたいですし、事業内容に包含される要素として地元福岡でやりたいというのがあったので。事業内容の内容の一つとして重要視しているところです。

――地元を選ばれた理由はどのあたりにあったんですか?

吉村 単純に地元が好きなこともあるんですが、日本って一極集中型だと思うんですよね。東京に集中してて、保育園がないとか通勤がしんどいけど「仕事がないから東京に行かざるを得ない」みたいな話はよく聞きます。でも、今はテレビ会議で三者別のところにいてもインタビューができる。もう、場所に縛られる時代じゃないと思ってるんですよね。

実はチームの全員が常に福岡にいるわけではないんです。彼らはローカルな北九州の案件に食い込んでいったり、地元の人脈を広げる活動もしているんですね。私も事業内容として、ローカル性を大事にしたいなと思っています

働き方自由度 5点 「ネットがあればどこでも仕事できる」

今日も僕は家から繋いでリモートしていますし、究極的には福岡の都市部すら出たいんです(笑)。出身は都市部なんですけど、福岡の中でも田舎に住みたいですね。あるいは、広島の離島だったり。ネットがあればどこでも仕事できる、という部分を実践したいです。

社畜度 0点 「会社のために頑張ったら給料が上がる」発想はない

僕にとってはITエンジニア、システム開発者という職業が重要であって、その職場がどこであるかはさして重要ではないんです。弊社カラビナテクノロジーは、社長の福田がすごく先進的な考え方をしていて、いわゆる封建的な組織ではなく、家族経営的な方向から、もう一歩進んだ「ティール組織」を目指しています。こういう組織が、最も強いと感じています。お金のところでも触れたのですが、自由な職場を維持するために会社の収益を挙げなきゃ、という順番であって、「会社のために頑張ったら給料が上がる」みたいな発想はないですね。そういう意味ではゼロです。

転職者に向けたメッセージ

5枚目の画像

吉村 我慢しないで、自分が楽しいと思える現場を探してほしいと思います。知人に「社内SE募集」というので入社したら、IT関連の仕事がなくて、全然ちがう外回りとかやらされている人がいるんです。こういう職種詐欺みたいなのって、日本ぐらいしかないじゃないですか。海外なら確実に訴えられると思うんです。日本の社会人は変なとこ真面目で我慢しすぎかなと。

ITの開発分野ってまだまだ尽きないですし、面白い仕事は転がっていると思うんです。大企業の部長・課長クラスで無くても、普通にお子さんを育てるぐらいの年収はいける業種でもある、と思うんですよね。本当に転職するかはともかく、小さくても面白い会社はたくさんあると思います。

――お忙しい中、ありがとうございました!

 

ライター:澤山大輔

ForlkwellPress ロゴ画像

フォークウェルプレス編集部

Follow

記事一覧へ

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。