40歳からのキャリアチェンジ

20代はエンジニア・PM、30代はWeb系エンジニア向けのキャリアアドバイザー。40代の今はフリーランスで開発含めて色々やってます。技術ネタとしてはRuby/RailsとJavaScript関連あたり

小〜中規模のWebサービスを数年運用して学んだことをまとめていきます。

Webサービスの運用

ブログや勉強会などで大規模なWebサービス運用に関する話は比較的入手しやすい一方で、小〜中規模のWebサービスついての情報はあまりまとまってないなぁと何となく感じてました。

フリーランスになってから、掛け持ちで色々なプロジェクトに関わってきたのですが、3年以上に渡ってWebサービスの開発＆運用を通じて、色々悩んだり学んだことが多くあります。

世の中に自分と同じような境遇の人が少なからずいるのかなと思い、そういう人に少しでも役に立てればと思って、これから数回に分けて学んだことをまとめていきます。

前提として

自分が関わってきたWebサービスの規模や開発体制とか簡単にまとめておきます。

  • サービスの規模：小〜中規模位
    • こういうやつの規模の定義がイマイチよくわからない
  • サービスの内容
    • BtoBtoCな感じ
    • 予約とか決済とかが絡む
    • 最初の1年位は日本人だけがターゲット。途中から多言語対応
  • 技術構成：Ruby/Rails。
    • rake statsすると以下のような感じ。
      • Model：Classesが150ちょっと
      • Controller：Classesが160ちょっと
      • app配下に、Form/Query/Policyのようなクラスも作ってる
    • 自分は詳細知らないけど、サービス当初はRails3系だったみたい。
  • チーム規模：
    • 最小：エンジニア3名＋ディレクター1名
    • 最大：エンジニア8名程度（うち1名はとても頼りになるプロダクトオーナーがいる）

これから書いていこうと思ってるテーマ

大きく分けると

という形に整理できそうです。

Webサービスの運用に関するテーマに関連することは、知識転用を上手く行えると思ってるので、なるべくこちらが手厚くなるように出来る限り情報を整理してまとめていく予定です。

※ ちなみに、1年ほど前から並行して行ってるお仕事がLaravel/PHPと全く異なる技術スタックなのですが、それまでに学んできたWebサービスの運用に関する色々なことがとても役に立ってます。

Railsに関連がありそうなテーマ

  • テストがほとんどなかった状況で、チーム全体でテスト書く習慣が身につくまでの課程
  • ドキュメンテーションどうしてきたか？
    • 社内のドキュメント管理のツール見たら3年で159個書いた。
    • これは今回のプロジェクトに限定しないけど、前任者がいたけど情報が更新されてない/うまく分類されなかったり、そもそも全く手付かずの状況で、何をどんな順番でまとめてきたのか
  • 過去一度もbundle updateしてないプロジェクトでどこから手を付けるべきか
  • RailsEngine採用したけどどうだったか？
    • 以下2点考慮して採用
      • 既存の処理を残しつつ新しい仕組みを取り入れたい要望（＝途中から多言語対応）に応えるために採用
      • 既存のView/JavaScript/CSSのメンテナンスが大変だったのでキレイにしたかった

Webサービスの運用に関するテーマ

  • 決済処理でこれをやっておかないと苦労すること
  • とにかく大変なメール送信まわり
    • 想定チーム規模だとSendGridのようなSaaSを使うと思うけど、その中で自分たちで考えないといけないこと
  • DBの寿命はアプリより長いを実感したあれこれ
    • 何も考えない statusカラムの乱発による弊害、SQLアンチパターンにある過去の状態がなくなることの弊害、その他に細かい部分含めて色々悩んでる。
  • DBのMigrationのコードレビューで意識するべきこと
    • カジュアルに index作成すると、痛い目に合う、実際のSQLを想定して、実行計画とかを一応チェックするのが無難、などなど）
  • 多言語対応固有の問題
    • チート対策的なこと（qq.comを利用した会員登録してきた等）
    • 途中から多言語対応を始めた場合の苦労とか

多言語対応色々書きたいけど、正直、こういうのをやってる人・チームって多くないので、あまり需要なさそうだからちょっと悩むなぁ・・

今年抑えたい技術領域の自己評価＆どういう状態になりたいかまとめてみた

フリーランスで、Ruby/Rails&JavaScript＋AWSの各種サービスみたいな構成でWebアプリケーション開発のしてますが

  • 現在使ってるけど何となくふわっとした理解のもの
  • 仕事をしてる中で「あー、こういう場面だときっとxxxの技術（サービス）使うことでもう少し良い構造になりそう」

みたいなことが最近増えてきてるなぁと感じてます。

特に、前者のふわっとした理解のものが最近すごく気になってててるので、そこを解消するために

  • 2019年に抑えておきたい技術領域を書き出す
  • 書き出した技術について自己評価＆どういう状態になりたいか？

という感じで以下にまとめていこうと思います

2019年に抑えておきたい技術領域

Ruby/Rails&JavaScript＋AWSの各種サービスみたいな構成でお仕事をして来てるので、今後抑えておきたい技術領域を個別にまとめていきます

フロントエンドのWebアプリケーション開発

最近半年位は

  • TypeScript&Angular6/7
  • Vue/Vuex
  • Nuxt＆TypeScriptを少し

という感じだったので、それを踏まえて優先順位が高い順に

  • TypeScript
  • Vuex

を抑えます。

バックエンド寄りのWebアプリケーション開発

  • そこそこの規模のRails環境で結構大きめのRailsアップグレードも経験出来た
  • 決済とか売上関連の処理をずっと書いていた

というのを踏まえるとさらにRailsを掘り下げるのがオーソドックスな考えかと思います。

それなりの規模を経験出来たことで

  • これから直面しそうな問題
  • その問題解決にあたって、自分が出来る・すぐには出来ない領域がある程度見えてる

という感じで、それに加えて Nuxt.js (TypeScript) on Netlifyの良さを広めたいを読んでて、Nuxt.jsとNetlifyが気になっており、SSR なものを1つ抑えておきたいなぁとぼんやりと考えていた のでNuxt.jsとNetlifyにします。

次点というわけではないのですが、このスライド見てたら、AWS Amplify も気になってるので一応書き出しておきます。

ちなみに、バックエンド寄りというくくりで考えて、ここ数年色々悩まされてきた問題解決の手段として、データベースのリファクタリングを抑えたいんですよね ただ、そこは実際運用してるサービスを通じてでないと中々知見が得られない領域なので一旦保留😅

AWS 関連

基本AWSサービス（EC2/S3/RDS/VPC/ELB など）の構成でお仕事をしてますが

  • 開発環境の一部
  • CirceCI 1.0 →2.0 への移行など

を通じて徐々にDocker化進んできた自分のお仕事環境を踏まえると

あたりを抑えておきたいと思ってます。

なぜTerraformとかLambda with Rubyなのか？

自分がこれまでお手伝いしてきた位の規模だとAWSの構成についてしっかりと情報がまとまってなかったりするので

  • せっかくなのでコード化しておく
  • 既存構成をベースに、何か改善したくなった場合の検証などの作業やりやすさ

なんかを考えて、Terraform を抑えておきたいかなと思ってます。

ちょっと前にTerraform使って、ALB＆VPC（public/privateなサブネットに分割）みたいなものを作れるようにしていたベースがあるのでそこをもう少し掘り下げたいなぁと思ってます

書き出した技術について自己評価＆どういう状態になりたいか？

項目 自己評価 どういう状態になりたいか？
TypeScript そもそも静的型付けの言語経験がないので、型についての理解が甘い 型定義ファイル( d.ts )とかが読み書きできる
Vuex mapGettersとmapActionsの理解が甘い 最近のお仕事経験も踏まえるとドメインの複雑さをstoreにうまいこと集約できるような設計ができる
Nuxt.js ちょっと触った程度なので自信がない アプリが書けるのはもちろん、本番環境での運用を踏まえてトータルで
Netlify そもそも触ってない状態 ひとまず説明ができて、サンプルアプリならサクッと動かせる
AWS Amplify そもそも触ってない状態 ひとまず説明ができて、サンプルアプリならサクッと動かせる
Amazon ECS そもそも触ってない状態 EC2ベースのホストからの移行みたいなシナリオでどういう手順でECSに持っていけるか自分の考えを持てる
Terraform ALB/EC2/VPCとかは作れる 既存のAWS構成をTerraform化するようなシナリオの時にどのような手順で作業できるか自分の考えを持てる
API Gateway＆ AWS Lambda（Ruby） ちょっと触った程度 EC2/Railsみたいな構成でcron使ったバッチ処理を AWS Lambda（Ruby）で置き換える時の勘所がつかめてる

まとめ

自分が抑えておきたい技術領域を書き出してみたら、

  • フロントエンドのWebアプリケーション開発
    • TypeScript
    • Vuex
  • バックエンド寄り
    • Nuxt.js
    • Netlify
    • AWS Amplify
  • AWS 関連
  • Amazon ECS
  • Terraform
  • API Gateway＆ AWS Lambda（Ruby）

という感じでかなりのボリュームになって正直これを全部やるのはツラいかな😫

ただ、可視化というか言語化したことで、課題が見えて来たのはすごく良かったので、書き出して正解でした ✌

AngularでRxJSが使われる理由がわからず色々調べたら腹落ちした

javascript

はじめに

ここ半年ほど、とあるWebサービスの管理機能をAngular6/7系で書いてます。

AngularでサーバーサイドのWebAPIと連携する処理を書く時に以下のようなロジックになるかと思います。

import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';

export class SomeService  {

  find(id: number): Observable<any> {
    const url = `/xxxxx/${id}`;
    return this.http
      .get<any>(url)
      .pipe(map(response => response.data.product));
  }

上記のSomeServiceクラスの中で行われてる処理は以下のようなことになるのですが、個人的に当初疑問に思ったことがあったので以下で詳しくまとめていきます

  • findメソッドの戻り値は Observable objectを返す
  • Observable objectに対する操作は色々ある
    • 上記のコードの場合にはpipe()メソッドでmap()オペレータを適用している。
    • 詳しいことは以下の引用文を参考

RxJS 6では、オペレータはpipe()メソッドの引数に渡さなければなりません。このメソッドそのものは、バージョン5.5で備わったものです(「Operator pipe syntax」)。けれどこのときは、Observableのメソッドとしてオペレータを呼び出すバージョン5の書き方もできました。それがpipe()メソッド一択になったということです。 RxJS 6: オペレータをつくってみる

そもそもRxJSとは何？

関数型プログラミングの文脈で出てきそうなmapなどの名前が出てきてるので、やってる処理は何となくイメージは付いていたのですが、そもそもRxJSって何だろうというベースがわかってませんでした。

そんな理解の中で

  • serviceクラスの中で必ずと言って良いほど出てくるのでサーバーサイドとの通信処理など、非同期処理の結果を適切に処理するためにRxJSが利用されてるっぽいなぁ
  • AngularJSの時代なら$http や$resourceなどを利用するコードだったけど、その時はRxJS相当のロジックはなかったけど何故こんなことをするんだろうか 🤔
  • 単に非同期処理をスッキリ書くだけなら別のアプローチもありそう

という感じで、他の人が書いた実装を読んでいたのですが、ふと

「最後の非同期処理をスッキリ書くだけならPromise使った書き方でも良いのかな？」

と思ったのでそこを少し掘り下げてみました

非同期処理するだけなら、ES6のPromise使った処理でも良いのでは？

let getURL = (URL) => {
  return new Promise((resolve, reject) => {
    let req = new XMLHttpRequest();
    req.open('GET', URL, true);
    req.onload = () => {
      if (req.status === 200) {
        let result = JSON.parse(req.responseText);
        resolve(result);
      } else {
        reject(new Error(req.statusText));
      }
    };
    req.send();
  });
};

【ES6】Promiseクラスの基本的な使い方より上記コードは引用してますが、ざっくりとやってることを書くと

という流れになるかと思います。

ES6/7の時代なので、こういうPromise使った処理でも良いのではと最初思ってました。

とあるQiitaの記事でObservableの位置づけがよくわかった

「Angular Promise Observable 」みたいなキーワードで適当にググってた中で、少し古いのですがAngular2のHttpモジュールを眺めてベストプラクティスを考えるのPromise v.s. Observableという記事に行き当たり、こちらの記事を読んでいて、何故Observableが登場してきたのか時代背景みたいなものを考えた時に、すごく腹落ちできました。

Promise ではなく、Observableを使うポイント

上記のQiitaの記事に書かれてるように、最近のWebアプリケーションで非同期処理が必要な場面はいくつかあると思います。

記事中では6つに大別してましたが、自分の最近の仕事では

  • Ajax
    • Promiseで対処できる
    • ただし Promise使った場合にキャンセルできないためレスポンスを待っている間にページが切り替わっても中断は不可 という欠点がある
  • DOM Event
  • Animations

という3つがひとまず対象になるのでそこだけで考えたとしても、Promiseが対処できる箇所は少ない上に、Promiseの特徴として

  • 連続した非同期処理の結果を扱えない
  • 遅延実行できない
    • 即実行され、resolveした直後にthenが実行される

という点があるためにAngularではRxJSを利用した処理になってる。

逆にRxJSを利用することで

  • 上記のような非同期処理はすべて対処できる
  • ストリームという概念を導入してるので、Ajax＆DOM Eventなど異なる非同期処理を集約＆連続して扱える

などのことが行えるため、色々な種類の非同期処理を同じように扱えるRxJSを使うのがベストという結論になるっていうので、点と点のような状態だった自分の理解がようやく1つにつながりました 😉

まとめ

単にAjaxな処理だけするならPromiseでも良いかもしれないけど、最近のWebアプリケーションではユーザーイベント（例：テキストボックスの入力内容や状態）を検知して、ある状況になったらサーバーサイドにリクエストを投げる・・・といった色々な種類の非同期処理が連携する必要が出てきます。

PromiseはそもそもAjaxな処理しかカバーしてない上に、連続した非同期処理の結果を扱えないことも考えるとAngular2でRxJSを利用する処理が採用されてそれが今に至ったんだなぁーというのがすごく納得できて腹落ちしました✌

アラフィフWebエンジニアの生存戦略について考える

キャリア

あと数年で50歳という年齢が現実的になってるのでアラフィフWebエンジニアの生存戦略考えてみました。

noteの方にも書いたのですがこっちはちょっとだけ加筆してみました

本題に入る前に自分の経歴をざっくり

ざっくりといいつ、それなりに年齢重ねてるので、文字数多くなってすみません・・

20代：

一応就職活動したけど、何となくしっくり来ないので、2年ほどフリーターで、早朝にサーフィンしてから、仕事するみたいな生活をしていた。

フリーター時代にWindows/MS Access & VBAを独学で覚えたのをきっかけに、派遣社員として働くようになって、とある外資系企業で当時としてはかなり大規模なネットワーク環境の中で色々なことを経験させてもらったので

  • TCP/IPのL3-L7辺り
  • WindowsのWMIを通じてネットワーク越しにクライアントPCを集中管理するために必要なこと

など色々学びました。

30代：

20代でアルバイト＆派遣しか経験してない負い目があって、正社員を志すも挫折して、もとの派遣先に戻って色々経験させてもらう。

外資系企業で何故かプロジェクトマネージャーの役割をさせてもらえので、必然的に英語を嫌でも勉強しないといけない状況だったので、スキルアップになったし、そのままそこの正社員っていう道もあったけど、色々考えた末に、人材派遣会社に入社。 人生初の正社員になって、キャリアカウンセラーとして色々やった

40代前半：

キャリアカウンセラーとして、色々な人の人生を垣間見てきたことで、色々考えさせられることが増えてきて、1社に雇用されててその1社からの収入に全てを依存することに怖さを感じていたので8年ほど勤めた会社を退職してフリーランスになりました。（詳しいことは昔にブログに書いてるので興味ある方はこちらを）

退職後は

  • 前職で趣味と多少実益を兼ねてバックエンドとiOS/Android向けアプリをつくったりしてずっとコードを書いていて、知り合いの会社でエンジニアがいなくいというので、そこでWebアプリケーション開発、運用、その他何でもという感じで仕事を開始
  • それがフリーランス最初の仕事で、過去何人もの人が関わってきたRuby/Rails＆AngularJSという構成で1人で色々見るのはそれなりに大変だった
  • その後は、基本的に自分で営業したり知り合い経由でお仕事の相談を受けて、基本は2社かけもちする形でお仕事

という感じで気づいたら5年近くフリーランスでWeb系のエンジニア＋αな仕事をしてます。

本題の生存戦略について考える

普通のWebエンジニアとして生きていくと思ってます。

普通っていう言葉の意味合いがどのようにでも解釈できてしまうと思いますがジャンルが違うけど

相手は普通の男がいい、というあなた。会話力・ルックス・身長・清潔感・ファッションセンス・学歴・年収がすべて普通の男なんて、たったの0.8％！　
普通のダンナがなぜ見つからない？っていう本より

みたいな感じをイメージしてるのですが、流石にこの引用だけでは伝わらないんので、掘り下げてみます。

仕事をする時に期待されそうなことを3軸程度で自己評価してそれぞれが「普通」に出来ることをイメージ Web系のエンジニアとして仕事をしていく場合に複数名のチーム（私は2名〜8名位規模がほとんど）体制で仕事をするのが一般的かと思います。

付け加えると技術情報について調べるのに一定の英語スキルというのも問われてくるケースがあるかと思うのでそのため仕事をこなすスキルとして

  • ベースのWeb関連の技術スキル
  • チーム開発の中で目標達成に向けてのマネジメントスキル
  • 読むスキルを中心とした英語

という3軸で表現できるかなと思ってます。

3軸を自己評価

Web系の技術：

Ruby/RaisベースのWebサービスでおそらく5年位運用してる会社のお手伝いをしてます。 そこはModel/Controllerとも100を超えてて、色々手を入れづらい状況だったのでコツコツとテスト書いたり、業務固有の概念をPORO（Pure Old Ruby Object）でFatModel/Controllerの状態をちょっとづつ解消していき、gem のアップデート（含むRails本体）なんかもこなせます

フロントエンドの方は管理画面系の処理を書くことがほとんどですが

  • 4年位前に関わったとある案件で、かなり肥大化して＆たまに謎の挙動するjQuery＋αのやつをChromeDeveloperToolsを毎日眺めつつ既存実装読み解
  • jQueryメインだったフロントエンドを徐々にVueを採用
  • AngularJS（つまりは1系）の既存実装をちょっとづつAngular6/7＆TypeScriptに書き換える みたいなことも対応

マネジメントスキル：

立場的に自分がチームの運営を主体的にすることはないのですが、基本的に複数案件をこなしてるので、セルフマネジメントの必須スキル「タスクばらし」そのポイントで触れられてるタスクばらしは常に行ってます。

「タスクばらし」とは、読んで字のごとく、仕事をタスクにバラすことである。仕事に取り掛かる前に、その仕事の要素を分解し、どのように進めるか道筋を立てることで、どれくらい時間がかかるか、リスクは何か、見通しを得ることができる。

基本的に2つ（一時期は3つ）仕事を掛け持ちしてるので

  • それぞれの仕事の現状やらないといけない作業をバラす
  • だいたい1時間単位になるようにする
  • 開発のお仕事でだいたいSprint単位でやることが決まるので、その枠組みの中で、タスクばらしされた内容の中で、難しいそうなやつとか緊急度高そうなものを自分のピークタイムに実施する
    • Sprint始まりにそういうのを集中させる
    • 平日だいたい5時頃から仕事してるので、そういうのは朝一番に着手する

という感じで日頃自分のやることは処理してます。

あとは、長くお手伝いしてる所だと、なるべく情報・状況を自分だけに属人化しないように、ペアプロとかペアオペでこまめに情報共有してるので、そういう作業を差し込めるように他の人の進捗なんかも気にしながら作業は日々行ってるので、30代でプロジェクトマネージャーしてた経験が今になってだいぶ役に立ってますね

英語：

昨年からイギリスの人と一緒に仕事をするようになりました。その人は日本語は話せるけどエンジニア未経験だったので、GitHubのIssueとかPRレビューとかはなるべく英語で説明していました。 ※ちなみにここ最近3ヶ月間くらいは、毎朝zoomでその人と英語80％位の割合で話してます

3軸を可視化するときっとこんな感じ

f:id:h5y1m141:20190125064330p:plain

それぞれの軸で、自分よりももっとデキる人を何人も知ってるのですが、3軸を満遍なく見た時には、そんなに悪くない所に自分はいるかなと思ってます

私は、フリーランスでお手伝いする立場なので、最終的な意思決定はする立場にはないけれど意思決定をしてもらう上での状況を整理して相手の知識や経験を踏まえて言語化・可視化して、みんながやりたがらない雑多なことを拾うのは、割と好きだったりします。

なので相手の人/会社にとって都合よく使ってもらえるような普通のWeb系エンジニアとして生きていくのが自分なりの戦略かなと思ってます

2018を振り返りつつ、2019年の目標

すでに、年明けてますが、昨年を振り返りつつ、今年の目標を簡単に書いておこうかなと思います。

2018年のサマリー

プライベートな部分とお仕事（エンジニア的な要素）でざっくり振り返ろうと思います。

プライベートな部分

  • 約1年位前から家族のことで色々考えることが続いてて、自分のことではないだけに、どうして良いのかわからないというのが正直な所
  • 上記に加えて、母が昨年7月に突然亡くなり、仕事しつつ、各種手続きを秋位までずっとやっていた
    • 現在は実家（一軒家）の整理中。
    • 大きな問題なければ、2019年4月ごろに売却手続き完了する見込み
  • 2,3年位前から体力維持の目的で水泳してるけど地味に泳ぎが上手になった

プライベートな部分で色々時間を取られることが多く、結果、対外的な活動（自分で企画するイベントとかはもちろん、イベント参加とかも）はほぼ自粛していた感じですね

エンジニア的な要素

開発言語の組み合わせが増えたのが今年最大の変化だったかも。

  • これまで
  • 最近
    • PHP（Laravel）とAngular6
    • Railsの方はフロントエンド側にVue/Vuex使うようになり、年末からVue/Vuex→Nuxtな組み合わせの開発も関わり始めた
    • あと念願の静的型付け言語の開発始めた
      • TypeScript

という感じ。

あと、SRE的な要素とくくっても良い気がするけど、昨年はそっちも結構色々やっていました。

  • 2年近くお手伝いしてるWebサービスで1年以上かけてRails4系の最新版にアップデート出来た
    • サービス自体はRails3系の頃から開始してる＆過去にbundle updateを定期的にしてきてない状態だったのですごく大変
    • Rails本体よりも、主要gemのアップデートが大変だった
  • サービス負債の1つであるAWSの構成見直しのためにTerraform使った新規環境構築検証
  • 以前作ったログ分析基盤の改善
    • メール送信のSendGridログを有効活用するためにAWS Kinesis経由で適切に取り込める仕組み構築中
  • （地味だけど）多言語対応してるサービスなのでGDPR対応してた

という感じのことを地味にやってました。

経歴とか実績として書く時に派手な開発じゃないけど、Webサービスを運営していく上で考えないといけないことを昨年は一通りやったかなと思ってます。

エンジニア的な要素のおまけ

  • スプリント計画/振り返りのミーティングのファシリテーター
  • 働く人が外国籍の人が何故か急に増えてきて、英語を使う頻度が激増

という感じのおまけもありました。

2018年のアウトプットを振り返ると？

ブログも書いてないし、Qiitaも書いてないので、対外的なアウトプットは激減したけど、お手伝いしてる開発案件の

  • GitHubのcontributions数
  • QiitaTeamとKibelaへのドキュメント数

はかなりの量になってるし、実際2017年と2018年のGitHubのcontributions数はこんな感じ。

f:id:h5y1m141:20190104093930p:plain
2017年のGitHub

f:id:h5y1m141:20190104093911p:plain
2018年のGitHub

あとは、2年近くお手伝いしてるWebサービスで、長年謎だった機能の全面リニューアル時に

  • これまで謎が多かった業務フローを適宜ヒアリング
  • 聞いた内容＋現在の実装をふまえて一旦全部ドキュメントにまとめる

みたいないことをやっていて、他の人にもしっかり共有できるレベルで各種情報がまとまったので、アウトプット自体はそこまで減少してたわけではないなぁというのが実感ですね。

2019年に関して

昨年は、プライベートな部分で色々考えることが多かったけど、色々考えても、なるようにしかならないなぁという気持ちに最近なってきたので、今年は対外的なアウトプットを意識して増やしていこうと思ってます。

ネタは

という感じで色々あるので、年間40（月に3,4つ）を目指して書きます！

1人仕事に限界あって、昨年取り組んだことを振り返る

キャリア フリーランス

なんとなくブログを書くモチベーションがなく気づいたら1年近く放置してたのですが、数日前に

「1年前に書いたことを振り返りませんか？」

というはてなからのリマインダーメール（？）が来たので久しぶりに更新します。

約1年前に書いたことを振り返る

1年前に書いたのはこれ↓ですが http://h5y1m141.hatenablog.com/entry/2017/04/17/140327

要点は

  • フリーランスのエンジニアな仕事をしてる人に割とよくあることだと思うけど、目先の仕事に注力してしまってこの先必要な技術習得を疎かにしがち
  • 急がないけど今後自分にとって重要になりそうな技術検証を誰かにやってもらえば良いのでは？
  • お弟子さんとなる人にその辺りを頼む

ということを考えて、実際昨年の今頃にそれをやっていました。

1年経過して今はどうなってる？

2017年1月〜2018年3月までの1年少しの間、お仕事を頼んできましたが、その人とはひとまず2018年3月末までで契約は終了しました。

なぜお弟子さんとの契約終了にしたのか

  • 私：
    • 自分の案件内容を少し入れ替えたい気持ちが昨年末ごろにあった
    • 技術検証をしてもらいたい項目は相変わらず多いんだけど、Docker+αなどインフラのベースの知識を持ってないと説明が多くなりすぎてしまうものが増えてきた
  • お弟子さん：
    • 自分でもやりたい開発領域が割りと明確になってきたタイミングで、ご自身の条件にマッチする案件を自分で見つけられた

ということで、互いにちょうど良いタイミングだったので契約を終了することにしました。

元々この取組を始めるタイミングで意識していたこと

私自身はもちろん、仕事をしてもらう人の両方がwin-winとなるような形にしたかったので

協力してもらう人にとってのメリット これまでの自分の経験を最大限還元しながらフォローしていくので仕事で必要なスキルが身につくようになるかと思います 〜中略〜 仕事をする上で必要となる技術以外のスキル

というスタンスで、やっていました。

お弟子さんとなる人は自分がやりたい仕事を見つけたくなる時期が来るだろうし、そういう時に自分が出来ることはどんな形でも良いので何か支援したいというのが根底にはずっとあります。

Web系のエンジニアな人が仕事を見つける時に、どういうことが出来る・知ってるのかを相手に理解してもらうための手段として

などいくつかあると思っており、いざそういう時（＝自分がやりたい仕事を見つけたくなる時期）になった時に、すぐに見せることが出来るものがあることで、自分が思い描くキャリアにつなげやすいかなと思って、定期的にQiitaに記事を書いてもらうようにしてました。

実際、そういう記事が仕事探しに役立ったのかどうかは正直な所わからない 😅 ですが、一緒に仕事をしていた間に身に着けた（身につけてもらった）ことを振り返ることが出来るものとしては十分役に立ったのかなと個人的には思ってます。

今後に向けて

諸事情あって今すぐは無理なのですが、おそらく今年の夏位にはこういう↓感じの人を想定して新たにお弟子さんとなる人を次は見つけたいと思ってます。

技術的な興味・関心事 勤務条件
例えば
  • 平日に1〜3日で1日4時間〜8時間位働ける人
  • 週1回Co-Edoで打ち合わせ（それ以外はリモート）

ズバリこんな人をイメージしてます

  • 業務委託で仕事をしてるけど今後に向けて上記のような技術領域に興味・関心がある人
  • 今は、専業主婦（主夫）で、AM10時〜午後3時か4時くらいまで時間は取れそうな人

参考までに：こういう感じの人はちょっとイメージしてません。

本業を持ってて平日夜や週末時間を利用して副業したい人はちょっと想定していません。

理由は私自身が

  • 基本的に朝型
  • 週末は原則家族との時間を優先してる

で人間関係がまだ確立されてない状況での時差のあるリモートのコミュニケーションは、すごく難しいのは経験済で、この状態だと双方にとってWin-Winにならないかなぁと思ってます。

1人仕事に限界あるので今年から取り組みはじめてること

フリーランス キャリア

Co-Edoでエンジニア・webデザイナー飲み会『健康的にお酒を飲んでわいわい交流しよう！』というイベントに参加してきたので、そこでこんなLTしてきました。

元々ブログに書きたいと思っていたネタなので、スライドの内容を補足する形で久しぶりにブログにまとめておこうと思います。

最初に前置き的なこと

スライドでも触れてますが、2014年７月〜フリーランスになったので、気づいたら3年弱経過してました。

1人で仕事やってるので

  • 忙しい時に仕事の依頼が来てやむなく断ってしまう
  • 目先の案件の仕事ばっかりになってしまってこの先必要な技術習得を疎かにしがち

ということが、時々発生してました。

やむなく断ってしまう場合にも出来ることはやっておく

忙しい時に仕事の依頼が来てやむなく断ってしまうという件については、仕事内容、先方の雰囲気などを踏まえて誰か良さそうな人がいないか周りの人に声をかけてみるということをしてます。

手間はかかりはするのですが

  • 仮にうまくマッチングしてくれれば、ひとまず関係性が作れる
  • 将来自分の仕事が空いてしまった時に、そういう関係性ある所を少しでも作っておくことで、そこでの仕事につながるかもしれない

という感じでちょっと先のことを見据えると、こういう一工夫でどうにかなるかなと思ってます（実際ここ最近でこういうマッチングを数件こなしてました）

この先必要な技術習得を疎かにしがちにしてしまう件

これについては、どうにも良い方法が思いつかず、これに関連するようなことをこの1年位ずっとあれこれ考えていた気がします。

解決策を思いついたので、お弟子さんとなる人を見つけた

フリーランスエンジニアをやるのではなく, 開発会社をつくった理由というmediumの記事を年末に読んで、2年位前に書いていたことを改めて思い出してひとまずお弟子さんとなる人を見つけることにしました。

色々縁があって、そういう人を年末に見つけて、年初から実際に仕事をお願いしてます。

頼んでる仕事内容は技術検証っぽいこと

自分が関わってる仕事を再委託は基本的にはやらないようにしようと思ってます。

理由は以下３つ

  • 契約上の問題（案件によっては再委託出来ない場合もあるし）がある
  • 目先の仕事だとどうしても緊急性が問われる場合があるので、そういう内容は頼みづらい
  • ちょっと先を見据えた場合に、自分の中では重要になりそうな領域とか技術要素があるのでそういう検証をしっかりやってもらうほうが結果的に双方プラスになる

実際頼んだこととしては

  • フロントエンドに詳しくない人が脱jQueryに向けてどういうアプローチを踏むとよいかというのか、ある種実験台となってもらってました。
  • ある程度の規模になったRailsベースのアプリケーションを分割する
    • 個人的に作ろうとして途中まで結構頑張って開発していたRailsアプリを使う

ということをやってもらっていました。

技術検証の作業を依頼することを通じて自分も知見が貯まる

  • Slackの分報使ってカジュアルにコミュニケーション
  • 結構細かくフィードバック・コードレビュー
  • 作業意図がうまく伝ってないと感じられた場合にはこんな感じで絵も使って依頼内容を補足
    • f:id:h5y1m141:20170417140317p:plain

という感じのことを日頃行ってるのですが、こういうフィードバックをする過程を通じて自分の中でも知らないこととか、理解が甘いところが明確になり、擬似的な技術検証をしてるのと等しい感じがしてます。

定期的にPRのレビュー（時には細かくサンプルコード書いてあげたりして）しながらやったおかげでJavaScript初心者がriot.jsを使い始めるまでという記事を書いてもらえる程度には理解してもらうようになったかと思ってて、この経験を踏まえて、JavaScript苦手意識ある人のハマり所をリアルタイムに見てきたのでどういうアプローチをすればいいのかという部分もそれなりには知見がたまった気がします

協力して貰う人と私自身とそれぞれにとってwin-winとなるような形

技術検証用のために作った自分のGitHubのプライベートリポジトリでこんなことを↓書いてるのですが、双方にとって今のところwin-win な形でうまく作業ができておりある程度の手応えを得ています。

f:id:h5y1m141:20170417140255p:plain

最後に

気づいたら2年位同じようなことを考えていて、なかなか行動に移せなかったのですが、ようやくはじめの一歩を踏み出せたので、これをゆるく長く継続できるようにしていきたいと思ってます！

※関連して色々考えてることがあるのでそれはまた違いうちに書こうと思います