2016年から副業を本格的にスタートさせて早3年になる。3年経ってようやく慣れてきて、炎上することなく一定の品質のものを出せるようになってきた。収入的にもおいしい。仕事をくれるクライアント様方には本当に頭が上がらない。いつもありがとうございます。
副業を続けてきて思ったのが、エンジニアの副業はメリットだらけだ。収入的にメリットがあるとかそういう話ではなく、キャリアとしてメリットがある。その辺りの話をしていく。
目次
どんな副業をやっているか
僕はWordPressのテーマカスタマイズやプラグイン制作。スクレイピングツールなどのWebアプリケーションの受託開発もやっている。
都度クライアントさんから「こんなことをやりたいんだけど」的な依頼が来る。それに対して時間で見積もりを出し、スケジュールを引き、納品するという流れ。
時給は¥2,100 – ¥2,500 程度で、クラウドソーシングの契約エンジニアよりは高いがフリーランスエンジニアとしては安い。
稼働は月に2 – 3人日程度に抑えるようにしているため、大きな開発はしない。これ以上働くと、育児参加がおろそかになったり疲労で本業に支障が出たりするからだ。
なぜエンジニアの副業はメリットしかないか
副業のメリットを語る前に、まずソフトウェア開発に必要な作業とは？ アジャイルだとかウォーターフォールだとかエクストリームだとか色々な開発手法があるが、そういう話ではない。もっと基本的な流れ。
どんな開発であれ、だいたい下記の流れを汲む。
- 要求分析
- 要件定義
- 見積もり
- 仕様策定
- 開発
- テスト
- クライアントのフィードバック
- 納品
ウォーターフォール的だが、アジャイルだってこれを細かくスプリントで回すだけで同じである。
個人が受託で仕事を行う際に大事なもの
前述の8つの作業の中でもっとも大事な作業は何だろう。全部大事？ 開発に使うFWは何にしますかとか？ JIRAやConfluenceを導入して効率アップさせよう？ nginxとapacheどちらにするかとか？ 継続的インテグレーション？ テスト駆動開発にドメイン駆動開発？ 違う。そうじゃない(鈴木雅之)。お前らは何でいきなり細部から入るんだ。PHPのバージョンとかユニットテストの話はどうでも良い。落ち着け。
もっとも大事な作業工程、それは「3. 見積もり」だ。
個人受託開発の見積もりは生活をかけた必死の見積もりである
まず当たり前の話だが、3日でできるだろうと見積もった作業が、1ヶ月かかった場合、生活が終わる。昼夜問わず仕事をし、次々と襲いかかる無理難題を解決しながら、家族にさんざ迷惑をかけた挙句、できたソフトはバグだらけのクソみたいなヤツだ。
ここで重要なのは自分の生活が終わるだけではなく、クライアントのソフトも終わる点だ。おまけに自分も3日分の工賃しかもらえないので、嫁さんはマジでキレる。追加発注をいただきたい、みたいな話もここまで見積もりと乖離が出ると厳しい。向こうからしたらウンコみたいなソフトを渡された挙句追加でお金だあ〜？ みたいな話。全員が不幸になるのだ。
お前が要求分析も要件定義もろくにせずに、無考えに「ああ、そのぐらいなら3日でできますよ」と口にした瞬間、色々な方面の不幸が決まるのである。
なので、実生活にダイレクトに影響する「3. 見積もり」。これは無茶苦茶厳密にやらざるを得ない。見積もりが厳密にできるということは、タスクが厳密に細分化できているということだ。要するに
- 要求分析
- 要件定義
の時点でかなり精度の高い情報が揃っていることになる。お前らがよく言う、「お客さんが全然要求を出してくれない」とか「要件定義がクソだから開発が進まない」とかそう言うのが全部解決されている状態。するとどうなるか。
精度の高い見積もりが出せる=炎上しない=品質が上がる=クライアント喜ぶ=適切なお金がもらえる=みんな幸せ である。
見積もりまでの作業を必死にやるとソフト開発の全てがうまくなる
「1.要求分析」、「2.要件定義」、「3.見積もり」までの間でプロジェクト品質のほとんどが決まることになる。ここをミスると終わりである。個人受託でこれをやる場合、生活がかかっているので必死にやる。圧倒的当事者意識だ。
大企業で上流かなんかをやっている人。自分はなんとなーく見積もりを出して、線も適当に引いて、実質手を動かすのは孫孫請けのSESとかであれば、要求分析も要件定義も見積もりもうまくなるわけがない。当事者意識がないからだ。だって自分がやるわけではないし、炎上したってせいぜい報告のために休日出勤してずっとチャットツールの前で報告を待ってるとかそう言うようなもんだろう。手を動かし考え血反吐を吐くのは孫孫請けの職業訓練学校卒業して3ヶ月の哀れな素人エンジニアである。
自分に被害が被りそうになった時に初めて人間は本気を出す。その点個人受託は全てが自分の責任で進む。本気を出さざるを得ないのだ。
で、その後の開発フェーズに行ったとして。いくら厳密に見積もりを出したとしても、見積もりと実績値に乖離が起きる時が必ずくる。そこで色々なことに気づくわけである。実は環境構築に時間がかかっているなあとか、このFWまだよく理解できてないなあとか、テストに時間かけすぎじゃない？ とか思うのである。もしかしたらここをもっとうまくやればもっと生産性は上がるかもなと。
すると自動テストやってみるかとか、VagrantとかCloud9でいろんなローカル環境用意しとこうとか、UdemyでLaravel入門でもやるかとか対策を打つようになる。知らぬ間に開発の力も上がっていく。それは自分が立てた見積もりを意識し、生産性を本気で高めたいが故に自然に湧き上がってくる行動だ。生産性を高める=お金に直結するのである。お金がかかると勝手に技術力もついていく。
本業に役に立つ
本業でもどこかの会社でソフトウェア開発をしている場合、良いことずくめである。なにせ個人でお客さんと要求を詰めたり、交渉をしたり。仕様検討をし、スケジュールを立て。開発してテストをし。炎上せずにクローズさせる。こう言う経験を1人でやった個人が、会社でチーム開発をした場合。個人でできたことをチームに応用するのは比較的簡単である。
他人の開発レベルをあげるのは容易ではない。が、見積もりはできる。やばいスケジュールをあらかじめ察知できる。待ったをかけ、適切な品質が保てる見積もりに補正できる。チームが炎上しにくくなる。つまりは成果物の品質が上がる。副業での成功体験が本業でのチーム開発に生きる。そのテコ作用は半端じゃない。
写経やチュートリアルをしてる場合じゃない、副業せよ
開発のレベルを上げたい場合、練習に励むのも結構だが、金をもらう仕事をした方が圧倒的に成長が早い。そこで本気の要求分析、要件定義、見積もりをしてみることだ。見積もりの失敗は自分の生活の崩壊なので手抜きができない。一度お金を手にするまでを経験すれば、自分の技術力を上げるとお金に直結することが体験として自覚できるので、自然に勉強するようになる。
気をつけるのはあまりレベルの高すぎる仕事は受けないことだ。自分ができないことはやってはいけない。授業料をクライアントに支払わせている点で明らかに間違っているからだ。いきなりチャラい仕事をするな。最初は考えなくてもできるような仕事にすることだ。
(補足)ソフトウェアの見積もり方法がよくわからない場合
見積もり大事って言ったけど、そもそも見積もりってどうやんのって話。要件を決めたらそれをざっくりとした仕様に落とす。その後仕様一つ一つをタスク分解してそれをhour単位で見積もるに尽きる。
具体的なやり方は、Joel on Software にだいたい書いてある。Microsoftでエクセルのプログラムマネージャーをやっていた人の書いた技術エッセイである。仕様の書き方みたいなのも載っているのでとても良い。