About Me

フリーランスになって結構長く経つけど振り返る事もなくやってきたので、少しだけ振り返りながら今後の事も含めても記録しておこうと思う。

Masatoshi Fukunaga

すこし前の事

２０００年からフリーランスのソフトウェア開発者として活動している。ソフトウェア開発者と言っても主なフィールドは Web 系が基本。そのさらに以前にプログラミングを趣味の延長で始めた当初は Classic Mac OS 上でのアプリケーション開発をしていたので、それから２０年以上経った現在の Web フロントエンドや Node.js 等のサーバサイドの主要なプログラミングモデルもコールバックベースのイベント駆動型プログラミングなので違いはあまり無いとも言える。

もちろん、最近は Go や OpenResty の様な軽量スレッドを利用した手法ですごくシンプルに書けるようにはなってきているけど、経験が少ないと逆に複雑性が増すような設計にしてしまう事も多いので　Structured Concurrency モデルが成熟してメインストリームに浸透した時に本当に変わった感じる様になると思う。

Structured Concurrency

ちなみに、DBA（Doing Business As）——個人事業主として活動する際の登録—— の手続きをしたのが２００１年だったので、表記上では２００１年からと書いている。

それから、２００８年末の帰国を期に UI デザインやインタラクションデザインがメインのフロントエンドの仕事をやろうと思い、JS/SPA で写真管理サービスのデモを作って初めての就職活動をしてみたのだけれど、その当時はどこへ行っても SPA なんか知らないし楽天のようなデザインじゃないと通用しないとの事だったので諦めてフリーランスを継続。@Osaka

これまでの事

東京にきてからは DMM.com での仕事がメインになっていて、Web API の設計と実装から始まり、アクセス制御やコンテンツ変換等のゲートウェイやインメモリ KVS の提案や設計と実装、それから近頃は、教育支援や都度都度に壁打ちの相手や提案・プロトタイピング等をしている。

今の仕事自体に不満は特にないのだけれど、フリーランスで１社だけの仕事では明らかに良くない。そこで、もう１〜２社ほど探そうかと考えて見たものの、個人的な伝手がまるっきり無い状態でこちらに住みはじめたおかげもあって方法は次の３択になる；

  1. 求人している会社に連絡する。
  2. 勉強会等のコミュニティに参加して人脈作りから始める。
  3. 専門のエージェントに登録をする

フリーランスを開始した当初は１番目の手法で営業をしていたので、何だかすごろくの「ふりだしに戻る」感があってすごくアレ……。

２番目については興味のある勉強会であれば参加して見たいとは思う。例えば、「Backends For Frontends の設計と実装のベストプラクティスを探求する会」や「省資源で行うリアルタイムモニタリングの世界」、「細かい事を追求する低レイテンシ・コンピューティング」なんてテーマで片手にわいわいディスカッションしてブラッシュアップして、ついでに GitHub にリポジトリ作ってコミュニティベースで実装までしてしまうようなコミュニティには参加したい。まぁ、きっとそんな勉強会コミュニティは存在しない。

個人的には評価ボードすら持ってないけど FPGA のイベントはすごく行って見たい。

FPGA エクストリーム・コンピューティング

最終的には、手軽な事もあって３番目の専門のエージェントに登録してみた。

ソフトウェア開発者に対する面談について

専門のエージェントといってもソフトウェア開発を知らない、または表面的な知識しかない人間がどうやってマッチングするだろうと思ってはいたけれど、実際に何というか、エージェント自体が色々雑すぎたり、出向いた先でもジョブ・ディスクリプションも無く——ジョブ・ディスクリプションが大事だと謳っている所でも同様に——ふわっとした話ばかりで結構うんざりしたのでエージェントとの関わりは止めてしまおうかと思っている……。

たまに所謂 GAFA と呼ばれる会社のリクルーターから連絡が来る時の内容はすごく明快で、GitHub のリポジトリの中身を把握していた上で連絡している旨や Roles and Responsibilities と Requirements が明記されていて分かりやすい。

日本国内では、色々出来る人が良いよねとポジションと無関係なスキルセットを盛り込んで論理的に破綻した業務内容だとか、課題があやふやなまま流行りのフレームワークや開発手法が散りばめられて「ヒップスター募集中」としか読めない内容を良く目にするけれど、ソフトウェア開発に真摯に取り組んでいる人間からは怪文書にしか見えないと思う。

明確な課題があって「ソフトウェア・エンジニアリング」で解決する人材を必要としているのであれば、ミッションや課題や責務、必要と想定されるスキルセットを明示した上で直接連絡して面談の場を設けた方が良いと思う。

これからの事

ここ何年か教育支援をやってみて、プロダクトの定義の仕方や実現のための課題の捉え方やより良い解決策を得るための議論の方法、基本的な設計や実装のベースとなる考え方やアプローチの手法、実際にペアプログラミングをする事で具体的な進め方等を根気よく教えた結果、着実に成長してくれた感触は掴めたけれど、底上げされたその能力を最大限発揮できる受け皿を備えた組織に行かれてしまったので、仕事としてはあまり良い結果ではなかったと思える。

結局のところ、どれだけ教育をしても「エンジニアリング組織」としての受け皿がなければ人材が残ってくれないという課題がある。この課題の解決にはプロダクトや組織に対するエンゲージメントが大きく関係する上に、それ自体がチャレンジングな仕事なので「エンジニア組織」ではなく「エンジニアリング組織」作りに関わってみたい気もする。

それから、もう一つ。個人的な志向としては、国や人種や年齢性別に関わらず「エンジニアリング」によって毎日の生活が少しだけ便利になるようなサービスに関わりたいと思うけれど……どうなんだろ。