| @労働

Kaizen Platform

Qiita:Team エントリのレベルが高い

CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。

SRE （インフラチーム）のレベルが高い

インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。

yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA （総務部門のドン）やってるし、 glidenote さんは SRE 業務をこなしつつも R&D して新しめの技術をどうやってビジネスにフィットさせていくかを追求したりしてる。

SaaS や IaaS をフル投入したモダンな開発体制

SaaS や IaaS を使うのはかっこいいからとかエンジニアが楽しいからではなく、その方が最終的にかかるお金が少なくて済むし、事業の圧倒的な成長に対応（スケール）できるから。詳しくは yosudo さんのスライドをご覧ください。

Mackerel meetup #7 スタートアップとSaaS

Mackerel meetup #7 スタートアップとSaaS

speakerdeck.com

コードのクオリティが高い

Kaizen Platform も 5 年目に入っているのでプロダクトのコードがレガシー化しているところがあるのは否めないけど、レガシーと言っても本当に悲惨なレガシーコードとは比較するべくもなかった。ユニットテストはちゃんと書いてあるし1、インフラは AWS だし平均的な水準が高い。メインのシステムは Ruby と Rails で構築されていたけど、一部の機能を Go lang でマイクロサービス化したり、ログ集約サーバーは Node.js で構築されていたり、場所によっては C で書いて高速化してあるところもあり、特定の技術に依存するのではなく目的、状況に応じて柔軟に使う技術を選定していくところがこれまでにない感じだった。エンジニアが Ruby しかわからないから Ruby をずっと使いますというような消極的な技術選定ではなかった。

プロダクトマネージャーがいる

プロダクトマネージャー（ PM ）がいる会社で初めて働いた。データ取りとかは PM 自身ががんがん SQL 書いて取るし Domo や Redash などの BI ツールを PM 自身が使いこなしているので「○●のデータを本日 11 時までに大至急抽出してください！！！、！（現在 10 時）」みたいなことを割り込みで依頼されるということはなかった。プロダクトマネージャーは技術、ビジネス、市場、顧客のすべてに精通していてリーダーシップがあり、ミニ CEO のような人たちだと思った。

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2 | PPTX

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2 | PPTX

The use case of BigQuery in Kaizen Platform - Download as a PPTX, PDF or view online for free

www.slideshare.net

QA チームがいる

PM のほかに QA チームの人がいて、 QA 観点で動作検証したり仕様に指摘をしてくれてめっちゃありがたかった。しかも QA チームの皆さんが優秀。エンジニアが自分で作って自分で動作検証するのではどうしても先入観が入ってしまって検証が不十分になると思う。むかし働いていたブラック企業では午後 10 時まで開発したあと午前 4 時まで自分で作ったやつを動作検証してエクセルエビデンススクショ職人業もこなしてたけどあれは本当に不毛だった。エンジニアが作ることに集中できる環境はすばらしい。

社長が近い

社長室などはなく、 CEO も普通にフリーアドレス席に座って仕事しているので CEO がすごく身近な存在で話しやすかった。会社にいる人たちも CEO に対して従順というよりは、その道のプロの人たちが集まっていて、若い CEO を助けるために一肌脱いでる感じがあった。雇われているというより雇われてやってる感じ。 CEO のことを親しみを込めて「スドケン」と呼び捨てにするし、むやみやたらに上下関係を作って序列通りにひれ伏すのはださいという雰囲気があった。

セールスが強い

こんなに強力なセールスがいる会社で働いたのは初めてだった。砂漠でこたつを売ってくる男の異名を持つ人がいたり。元リクルートの人たちを中心とした精強なセールスチームがいて、大企業からどんどん契約をとってきてた。自分はこれまで中小零細企業とか上場企業でも個人向けサービスをやってる会社でしか働いたことなかったので、こんなに大人っぽいカッチョイイセールスの人たちがいる会社で働いたのは初めてだった。

社員の趣味がエクストリーム

雪山スキーとかサーキット走行とかフルマラソンとか雨が降らない限り毎週末キャンプしてるとか鎌倉に住んで毎朝サーフィンしてから仕事とか、社員の趣味がエクストリームだった。アウトドアでなくても仏像なぞり描きと御朱印集め、囲碁、観葉植物、美食、マイル乞食、不動産運用、マンション管理組合理事など、趣味が中途半端な人がいなかった。

性善説とアンチマイクロマネジメント

社員は悪いことをしないという前提で会社が動いているように思った。承認システムみたいのがあるにはあったけど、新しい SaaS を使いたいときには CTO に相談すればよかった。マイクロマネジメントを嫌う風潮もあり、休みをいつ取るかなどは自由だった。細かいマネジメントをする方が無駄にコストがかかるし、そもそもマイクロマネジメントが嫌いで大企業を辞めてきた人たちで構成される組織だった。

求められる水準が高い

マイクロマネジメントされない一方で、求められる水準は非常に高い。四半期ごとの目標設定と評価面談では、目標として設定したことをこなすだけではマイナス評価となる。目標を達成するのは当然で、求められていること以上の成果を出すことができたかが評価軸だった。

採用フローで期待されていることを説明される

自分が受けた頃は採用にとても時間をかけていて、これこれこういうことを期待しています、ということを丁寧に説明された。 2 回くらい現場の人と面接して最後に重役と面接して「お、キミいいネ、採用！」という感じではなかった。むしろ最初に CTO と話して次に CEO に口説かれ、あとから将来同僚となるエンジニアやプロダクトマネージャーと話すという感じだった。採用フローでポジションや求められる役割について説明があり、入ってから「俺はマネージャーだったのに平で雇いやがって」というような期待のミスマッチが起こりにくかった2。

情報が閉じられていない

会社の売り上げ、状況は公開されていた。毎週金曜朝から行われる All Hands で数字の共有があり、目標に届いていないなどのアナウンスがあった。また隔月で行われる全社合宿（合宿だけど日帰り）でも会社と事業の現状について説明が行われ、社員全員で今後の方向性についてディスカッションを行う文化があった。

仕事をしていく上で、会社の経営状況について知らされていることは重要だと思う。かつて働いていたブラック企業は顧客が自分たちにいくらお金を払ってくれているかを教えなかった（教えたら自分たちが搾取していることが従業員にばれるため）。お客さんがいくら払ってくれているかを従業員が知らないと払ってくれている金額に応じた仕事をすることは難しいと思う。

厳しいなと思うところもあるけど、意欲がある人には機会が与えられる職場だと思う。総じてパワーのある会社だった。

なんでこんなことを書くのかというと、実は Kaizen Platform を先月で退職していた。すべて自分の能力不足が原因で、決してペパボを辞めたときのような積極的な退職ではなかった。前回の退職は前進だったけれども今回の退職はまさに撤退という言葉がふさわしい。なので退職日に合わせて記事を書くことができなかった。

Kaizen では入社早々に障害を起こしてしまったり、アサインされたプロジェクトを頓挫させてしまったりで在籍期間中に大したバリューを出すことができなかった。

ただ Kaizen Platform で働いた 1 年 11 ヶ月は自分にとって非常に貴重な時間だったと思う。リモートワークのおかげでこれまでにない生活をすることができた。家族が忙しいときに家事をしたり子どもの幼稚園の送り迎えをしたり。普通のお父さんではできないようなことができた。

なにより通勤がないのが素晴らしかった。通勤は実際に移動してる時間は 30 分でも家を出る前の身支度が必要だったり、なんだかんだで朝晩に 1 時間ずつ時間を取られてしまう。家族がいる人の場合はこれが自分だけでなく家族の負担にもなる。通勤に取られる 2 時間があれば洗濯や炊事ができる。この 2 時間が生活にゆとりをもたらしてくれていたと思う。

ダイエットにも成功した。糖質制限をして減量したけど、普通に朝から出社して働いていたら食事の準備に時間をかけられず、摂取しやすい炭水化物中心の食事を続けていまもデブのままだったのではないかと思う。

半日休む必要はないんだけど、昼間数時間だけ自分のことに時間を割きたい、用事が終わったらまた仕事しよう、というようなことができたのがとても良かった。病院通いがとても捗った。

こういうの、ワークライフバランスと言ってしまえばありきたりな感じがするけど、ちゃんとワークライフバランスを保つのは尊いことだと思う。

反面、リモートワークにはつらい面もあった。何をやればいいかが明確ではない状態でのリモートワークはとても難しい（参照: リモートワーク）。チームメンバーの意識が統一されていない状況にもフィットしない。何をやるべきかを自分で明確にできる人、遠隔でもリーダーシップを発揮できる人でないとリモートワークはこなせないと思った。自分にはその両方が欠如していた。誰からも管理されない状況で自分でやるべきことを明確にし仕事をしていくのは自分で自分を律することのできる人でないと難しい。サボろうとしているわけではないのに時間だけが経過していくのは非常にもどかしかった。小さい頃から親や学校の先生に「次はこれをやりなさい」、「あれをやってはダメ、これをやってはダメ」と指示監督されてきた人間が突如として管理されない状態で働くのはきつい。管理されて働いているときは管理者に対して不満を持ちつつも、管理されないと全く何もできない自分の不甲斐なさが露わになるばかりだった。

全体として、自分に足りない部分がわかった 1 年 11 ヶ月だった。上に挙げた、リモートワークをうまくやっていくための資質（何をやるべきかを自分で明確にできる、リーダーシップがある）は、オフィスでより良い仕事をしていく上でも必要なものだと思う。また自分のやりたいことに貪欲であるべきことを学んだ。エンジニアだけでなく、セールスやカスタマーサクセスなど違う職種の人と話をしていて感じたことだった。やりたいことがあるのに黙ってもじもじしててもやりたいことは回ってこない。やりたければ相応の準備をした上でやりたいと手をあげないとやらせてもらえない。空気を読まず、遠慮をしないことが良い仕事をしていくために必要だと感じた。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。

  1. むしろテストコード多すぎて CI が遅くなるのが問題だったけど CircleCI に重課金してテストを並列実行して凌いでた。 ↩

  2. ただしたまに逆のパターンが起こってた ↩

| @労働

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。

良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。

技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかもしれないが、技術的に秀でた人が必ずプロマネ力が高いわけではない。技術力さえ磨けば良いエンジニアになれると誤解してしまいがちだが、技術力だけ磨いてもみんなから求められる良いエンジニアにはなれないだろう。

ではなぜ技術力に加えてプロマネ力が必要なのだろうか。

一般に、コードを書かずに問題を解決できるならその方がよい。相手に言われるままにコードを書くよりも、コードを書かずに問題を解決できた方が時間も金もかからずみんなハッピーだろう。もしコードを書くとしても最小限の変更に抑えられるのが良いエンジニアなはずだ。技術力が高いだけではこういう発想は出てこないだろうし、真の問題が何なのかを見極め、解決策を考える能力が求められる。

良いエンジニアには先を見通す力も必要だろう。依頼された機能を開発するためにはどんな作業が必要か、どのくらい時間がかかりそうか、誰と調整しないといけないか。

関係者に働きかけ、周りを動かす力も必要だろう。理不尽な依頼が振ってきたときに、その依頼に対して反論し、相手を説得して実現可能なやり方を受け入れてもらわないといけない。

誰かに指示されるのを待たず、自ら動くことが出来る力も必要だろう。仮にプロパーのプロジェクトマネージャーがいたとして、プロマネの指示ばかり待ってコーディングしかしないようでは良いエンジニアとは言えないだろう。

このような、プロジェクトをコントロールし推進する力が良いエンジニアには必要なのではないかと思う。

そんなに何でも出来る人はいないのだから、スクラムをやれば良いのでは、という意見もあるだろう。確かに並エンジニアの集団ではスクラムが有効そうに思える。卓越したエンジニア一人で開発するよりも、数人の並エンジニアによるチームで難しい問題に立ち向かうストーリーの方がおもしろいだろうし個人的には好きだ。

しかしそうやって並エンジニアを寄せ集めても、そこから良いエンジニアは育たないのではないかと感じる。

スクラムチームでエンジニアは、スクラムマスターとスプリント計画、プロダクトオーナーとの「合意」により保護される。自分一人で問題に向き合い、問題を解決する能力がつきにくい。

一方でスクラムを採用していない荒野のような環境では、エンジニアはチームに頼れず、自力で要件を定め、関係者の合意を取り、自らプロジェクトを推進していく必要がある。そのような厳しい環境に身を置くことで、上に挙げたようなプロマネ力が身についていくのではないかと感じる。

これまでの自分のキャリアを振り返るに、以前勤めていた職場はまさに「荒野」といえるような環境だった。誰も何を作るかはっきり分かっていないんじゃないか、いきなり一人で工数見積もりやれといわれても出来るわけないだろう、こんなウォーターフォール開発はやめてアジャイル開発がしたい、こんなクソ会社辞めたい、といつも思っていた。

しかしつらかったのは自分にプロマネ力がなかっただけなのでは、と最近思うようになった。その後入った職場では、つらいこともありはしたものの、スクラム開発のおかげで個人が一人で抱え込んで苦んだりすることなく、チームで協力して開発することが出来た。その中で自分は自分自身の能力を過信したのかもしれない。実際には大してエンジニアとしての力は身についておらず、チーム開発やスクラムをやらない組織で働くことになったときに、自分の能力のなさを思い知らされたのだった。

本題に戻る。自分が良いエンジニアになるためには、技術力も当然足りていないと思うのだけど、プロマネ力を上げていかなければならないと思っている。来年の目標はそのあたりに置きたい。

Shut the fuck up and write some code.

はい。

| @労働

杖立の赤い吊り橋

転職してリモートワーク始めて 5 ヶ月たった。 Basecamp （旧 37 Signals ）の本で読んで夢にまで見てたリモートワークだけど、始めてみると理想と現実は違った。

良かったところは？

リモートワークだと通勤時間がないとかがよくあげられる。しかし自分の場合は福岡に拠点がある東京の会社に雇われていてそこで一人で仕事してるので通勤時間ゼロにはなってない。家で仕事する日もあるけど大体毎日片道40分くらいかけて通勤してる。必要なミーティングさえ外さなければ病院行ったりとか子どもの面倒見たりとかできるのはよい。あと午前中家で仕事して、昼間の空いてる電車に乗って座って仕事しながら出社できるのも良い。ただ仕事に時間の区切りがなかったり家で仕事できるということは、気になる仕事を夜や休みの日に家でやってしまって、フルタイムの社畜に成り下がってしまうリスクを伴うので注意が必要。

さみしいのか？

さみしいとか思うことはほとんどない。所帯持ちなので家に帰ったら嫁さんと子どもいるから全く孤独ということではないし、適度に前職の同僚の人たちと昼飯食いに行ったり酒飲みに行ったりしてる。ただ人と話すのに金かかるようになったの結構痛い。人と会うときは常にどっかに飯食いに行ったり酒飲みに行ったりという感じなので、交際費的な名目で毎月 2 万円くらい飲食にお金使ってる気がする。小遣い実質ゼロ円なので毎月子どもの頃に貯めたお年玉貯金を切り崩してしのいでる。

つらいか？

つらいかと言われればつらい。仕様の確認とか。毎日顔をつきあわせて仕事してたら簡単なことがリモートワークだとかなり難しい。 Slack や zoom などのコミュニケーションツールはあっても、姿が見えないのでいつ話しかければ良いかが分からない。大海原に一人で放り出された感がある。リモートワークできる人は限られてくると思う。

これらの経験を通して、大事だなと思ったことをまとめてみます。

大事なこと（道具編）

道具がリモートワークの質を左右する部分がある。インターネットの回線とかマイクとかカメラの品質を侮ってはいけない。

1. 良いインターネット回線

インターネットの回線悪いと会議してるときに聞こえないことあっても、大人数対一人でやってるとなかなか聞き返しづらい。なので回線はできるだけ太くて安定したやつを使うのが良い。よく分からない Public な共有 WiFi とかはネットを見るのには良くてもミーティングとかには使えない。インターネット回線は独自のものを使い、 WiFi は IEEE 802.11ac が望ましい。 Apple の AirMac Extreme が 50 デバイスまで接続できておすすめです。

2. 良いマイク

Rebuild.fm の初期エピソードと最近のやつを聞き比べて欲しい。 miyagawa さんがマイクにこり始めてからのエピソードの方が圧倒的に聞きやすい。会社でイエティマイクを買ってもらって使ってて、高いからもちろん高性能なのだけど、意外と良いのが iPhone についてくる Apple 純正イヤフォンマイク。高級イヤフォンつけてる人よりも Apple 純正の安いイヤフォンマイク使ってる人の方が声聞き取りやすかったりする。

3. 良いカメラ

カメラ、安いやつ使うと画質ひどい。変なエフェクトかかって真面目な話してるのにふざけてると思われたりして損な感じ。実はこれも MacBook Pro についてる Apple の標準カメラがかなり画質良い。

4. 良いビデオ会議ツール

Zoom というサービスを会社では使っている。複数人通話も無料で使えて Skype よりも便利。画面の共有も簡単。ユーザーアカウント作る必要もない。ほかにエンジニア同士だと appear.in というブラウザだけで完結するサービスを使ったりもする。

良い道具を使うことで避けられる問題は金で解決するのが一番です。

大事なこと（心構え編）

リモートワークをこなす上での心構えと、どんな人に向いていないかについて書きます。

1. 顔つきあわせて話す機会必要

全然人間的な関係が構築できていない状態でいきなりリモートワークやれっていうのは無理がある。人間は対面で話していると表情や身振り手振りなどで相手が冗談を言っているのか怒っているのかわかるものだけど、ビデオ通話越しだとその辺のことがとてもわかりにくい。なのでこの人はこういうとき冗談を言う人だとか、この人はとても怒りやすいとか、そういうパーソナルな情報を対面のコミュニケーションで補完する必要がある。自分は入社して最初の一ヶ月間、東京で仕事してある程度会社の人たちと仲良くなって、そのあとも月一回は東京に行って一週間ほど東京で仕事してる。ようやく最近同僚感出てきた。

2. オフィスにいる人たちの理解

リモートワークをする本人の能力が高ければ当然のことのようにリモートワークできるというわけではない。オフィスにいる人たちの協力がないとリモートワークは成立しない。たとえば職場では、ミーティングにリモートの参加者がいるときにはオフィス内にいるメンバーも全員ビデオ電話越しに話して同じ状況でミーティングに参加し、オフィス内のメンバーだけで議論が進まないように配慮している。リモートで働く人、オフィスで働く人お互いが協力して初めてリモートワークは成立する。

3. コミュニケーション不全を受け入れる

ビデオ電話で会話できるとはいっても、対面で話してたらすんなり頭に入ってくることも、ビデオ電話越しだとなかなか理解出来ない。人間は表情とか身振り手振りでのコミュニケーションが割合に多いということがよく分かる。思ったこと、考えていることを 100% 伝えられないかもしれない、という前提のもとで仕事する必要ある。なので確認はしつこいほど行った方がよい。

まえリモートワークつらい、みたいなことを Twitter に書いてたら、フリーランスで受託開発してる人だったら、顧客企業の担当と十分にコミュニケーションできないとか当たり前だし、リモートワークなんて余裕だと思う、という反応があった。確かにそうかもしれない。人から指示が来るのを待っているだけだと全然仕事が進まない。分からないことがあったらこちらからがんがん聞きにいって、自ら積極的に行動しなければならない。言われたことだけをやるという感じだと普通の会社でも使えない人みたいな烙印押されるけど、リモートワークだとその傾向が顕著になる。自分はこれまでの人生完全な指示待ち人間だったので普通の人以上にリモートワークをつらく感じるのだと思う。

このように圧倒的な当事者意識や頻繁な声かけなど、人間力の高さがリモートワークには求められると感じる。一人で誰とも話さずに仕事するのに逆説的な感じするけど、人とコミュニケーションとるのがいやな人にはリモートワーク向いてないと思う。

ここまで書いたところであらためて Basecamp の『強いチームはオフィスを捨てる』を読み直してみたら、自分が書いてきたことと同じことが書いてあった。リモートワーク、最近はニュースでも取り上げられたりしてサイコーみたいな扱いが多いけど、やっぱりつらい部分もあって、彼らもそのことについて触れていた。詳しくは「リモート時代のマネジメント」の章を読んでください。

まとめると、リモートワーク、本人の適性のほかに、会社自体がリモートワークを受け入れる準備ができていることが重要だと思う。また人とのコミュニケーションが好きではない人には向いていないと思う。むしろコミュニケーション能力高い人じゃないとつとまらない。

休みの日にゼータガンダム見てて、ニュータイプだったらリモートワークをうまくこなせるだろうなって思ってしまった。物理的に離れていても感覚で相手のことが分かるあの感じ。「この感覚、アムロ・レイか」。逆にいうとリモートワークをこなしていくことでニュータイプ特性を開花できるかもしれない。結論としてはリモートワークしたい人はゼータガンダム見てください。君は刻の涙を見る。

この記事はリモートワーク Advent Calendar 2015 の 23 日目の記事だけど二日遅れで書いています。遅れてすみませんでした。

| @雑談

IMG_1893

この記事は地方在住ITエンジニア（元・地方在住も可） Advent Calendar 2015 - Adventar 6 日目の記事です。地方在住ウェブエンジニアの著者が思ったことを書きます。

自己紹介

熊本出身で大学生の頃は東京に住んでいました。いまは福岡市に住んでいて、東京のインターネット企業に雇ってもらってます。リモートで仕事してます。

福岡のことを書かない理由

最初は福岡での暮らしについて書こうかと思ったのですけど、福岡在住の著名 IT エンジニアはきしだなおきさんや新井俊一さんなど以前からたくさんいらっしゃって情報発信しておられますし、最近では前職でご一緒させていただいた、昼に寿司を食べた舌が乾かないうちに夜焼肉を食べたりしている金満エンジニアで、天気の話からでも HashiCorp プロダクトの話に結びつけるうずづらさんや、女性ファン急増中のプラチナ貴公子スーパー Go lang プログラマーモノクロメガネさんなど雨後の竹の子のようにいて情報発信しておられますし、また福岡について書いたら最終的に「福岡便利ですよ、移住してみませんか」みたいな結論になりがちですし、加えてほかの皆さんの記事を読む限り福岡は地方には含まれなさそうなので、福岡にやってくる前に住んでいた熊本県阿蘇地方での生活を綴りたいと思います。

キャリアの始まり

僕が最初ウェブ開発を生業にしたのは熊本県の過疎地域、阿蘇地方でした。元々学生時代にコンピューターサイエンスを学んでいたわけではありませんでしたし、プログラミングというより HTML マークアップと雑用担当としてウェブ開発業界に潜り込みました。

地方のつらみ

ギャラが少ないことと勉強会に参加できないことがつらかったです。

ギャラが安い

実家暮らしだったので何とか生活できていましたが、年収200万に満たなかったです。地方にもインターネット関係の仕事がないわけではないのですけど、まともな賃金が支払われる仕事がないと感じます。地方でのシステム開発は、自治体が都会の SI 会社に発注する数千万円から数億円規模の仕事か、商店のホームページのアクセスカンター設置みたいなやつしかなくて、後者に対する報酬はとても少ない。一年と少ししか働いていませんでしたが、このまま歳をとるとやばいな、という危機感はありました。

勉強会に参加できない

田舎にいると勉強会的なものに一切参加できないのもつらかったです。勉強会がしばしば開催されている福岡に引っ越してきて何度か勉強会に参加してみたけれど、勉強会は参加するだけでは無意味で発表する側にならないと得られるものが少ない、ということがわかって勉強会渇望症みたいのはなくなりました。いまにして思えば隣の芝生は青い状態なだけだったという感じがあると思います。勉強会とかなくても学ぼうと思えば学べるはずです。ただし勉強会で発表しまくって目立ちたいとかそういう人は都会に住んでないとダメでしょうね。

相談できる相手がいない

職場に質問・相談できる相手がいないのが心細かったです。常に一人で考えて試行錯誤を重ねる必要がありました。それはそれで良い経験にはなっていたと思うけど、知っている人がいてヒントを出してもらいながらステップアップしていく方が断然効率的だったと思います。もし『情熱プログラマー』でいわれるところの師匠なような存在がいたら、今頃もっとよいエンジニアなれていたのではないかと自らの怠慢を棚に上げ思います。

街の灯火が遠い

ほかの人の記事を読むと通勤時間が長いと書いてる人が多いですけど、当時の職場は家から車で 10 分のところにあったので通勤時間に関しては不満はなかったです。この辺はたまたまが職場が家から近くてラッキーだっただけだと思います。ただ仕事のあとに映画を見たいとか本を買いたいと思っても、田舎過ぎて仕事帰りに何かするというのが無理だった（そもそも仕事が終わるのも遅かった）のはつらかったです。

田舎にいて良かったこと

自然

当時の職場が森の中にあって、職場から阿蘇山の景色を望むことができました。また昼休みに職場の周りを散策すると、小川があったり農家に引かれて道を歩いてる牛とすれ違ったりして毎日がちょっとしたハイキングみたいでした。疲れたときに窓から阿蘇の山々を眺めると癒やされましたし、毎日昼に散歩すると頭がすっきりする感覚があってよかったです。キャリアのスタート段階だった、独身で時間を自由に使うことができた等様々要因はありますが、当時はよく学ぶことができていたなという感じがして、これら自然環境が少なからずよい影響を与えていると思います。

無双

ギャラが少ない一方で上司が非技術者なのでやりたい放題できるというメリットがありました。課題に対して自分の好きなとおりに解決策を考えて解答を出すことができました。以前、社内 SE は無双できると書かれている記事を読みましたが、まさにそんな感じです。信頼さえ得てしまえば無双できると思います。

結論

  • 莫大な遺産があって働かないでも食っていける
  • スタートアップで働いていたが上場してストックオプションで億単位の金融資産を得た
  • 独身、あるいは妻子に逃げられて養うべき家族がいない（慰謝料とか養育費も払わなくてよい）

等々で収入が多くなくてもかまわないなら、田舎で仕事するのも良いのではないか、と思います。特にキャリアのスタート期を終えて一定程度のスキルを身につけている状態で、働き口さえあれば、地方に引っ込んでもそれなりに楽しくやっていけるのではないでしょうか。ただし地方に引っ込んでも最新技術へのキャッチアップを怠らないことなど、意識を高く持つことは大事だと思います。

勤務先を地方に求めず、リモートで東京の仕事を請け負う、というやり方もありますが、東京の会社に雇用されて福岡でリモートワークしている僕個人の考えでは、リモートワークというのはやはりなかなか難しくて（リモートワークアドベントカレンダーで書こうと思います）、特に業務委託などでフリーランスの人が仕事を受けながら働くのは、受け手が相当の熟達者か、発注者と受け手が元同僚であるとかでないとディスコミュニケーションが発生してお互いつらい気がします。正規従業員として雇用されている僕も月一回程度東京に行って、膝をつきあわせて仕事しています。

役所が都市部のハイエナ SIer に発注するような仕事以外にも、地方在住のエンジニアがローカルビジネスのオーナーから請け負って価値を提供できるような場所はあるのではないかと思っています。以前田舎で働いていたときに、もう少し自分にスキルがあってお客さんにも意欲があれば、もっとウェブ技術を使って便利にできるのになぁと思うことがしばしばありました。ウェブサービス作ってユーザーめっちゃ増やしてドカーンだけがエンジニアリングの使いどころではないと思いますし、地方出身者が都市部に吸い寄せられていくだけでは先祖代々の墓は誰が守れば良いのか分かりません。何年先になるか分かりませんが、隙あらば地元に帰って何かしてみたいです。

跋文

最後に福岡で働くことについて一言書いておきますが、福岡はブラック企業が多い街という印象を受けます。街がコンパクトで皆歩いて帰れる範囲に住んでいるせいか、終電の概念が崩壊しており、平気で午前 2 時、 3 時まで働いている会社があります。なので福岡最高、福岡便利、福岡手榴弾！！、！などといった甘言に惑わされず、移住を検討する際にはまともな勤め先を確保した上で断行してください。僕は福岡で最初に働いた会社が本当にひどかったです。以上です。

この記事は地方在住ITエンジニア（元・地方在住も可） Advent Calendar 2015 - Adventar の 6 日目の記事でした（一日遅れて書いてます）。今日の担当は飲み会後、歩いて帰れる距離でも必ずタクシー帰宅をキメる @h_demon さんです。お楽しみに。