どこに行っても成果を出せる フリーランスエンジニアの学び方

フリーランスエンジニアがクライアントに対して提供する価値は、フリーランスエンジニアひとりひとりが持つさまざまな特徴から生み出される、ということは以前に1杯1000円のコーヒーから考えるフリーランスエンジニアの価値で説明した通りです。

一方で、「高い技術力」という特徴さえ持っていれば、ほとんどのプロジェクトで高い価値を生み出せるようになるのも事実です。

この記事では、そのような高い技術力を手に入れるために、フリーランスエンジニアならではの事情を考慮した勉強方法について考えてみたいと思います。

まずは「技術力を磨くための学び方」を考える上での、フリーランスエンジニアと会社員の違いについて整理してみましょう。

フリーランスエンジニアと会社員の違いは、大きく分けて下記の3つと考えられます。

• 一緒に学べる同僚の存在
• 将来的に必要になる技術領域
• 実践経験を積む機会

これらの違いについて、ひとつずつ確認していきましょう。

会社員には多くの場合、業務中も気軽に雑談できる「同僚」が存在します。

同じプロダクトを同じ技術で、同じ立場で開発する同僚の存在は、新しい技術を学ぼうとした時、とても助けになります。背景知識を共有し、同じ目線で議論ができることでお互いの理解度に合わせた会話が成立するからです。

一方で、フリーランスエンジニアにとってそのような存在が常にいるとは限りません。毎日同じ場所で顔を合わせ、同じ立場で会話ができる——。そんな気心の知れた仲間は、数カ月単位で案件を転々とすることも多いフリーランスエンジニアという立場では、なかなか手に入らない存在です。

そのため、フリーランスエンジニアはひとりでも効率的に学べる工夫が必要になります。

学習すべき技術領域も会社員とフリーランスエンジニアでは異なります。

会社員の場合、開発するプロダクトや利用する技術はある程度固定されています。ひとつの会社で開発をする以上、必要とされる技術や業務知識が変わることは多くないためです。

一方で、フリーランスエンジニアは数カ月単位でプロジェクトやクライアントが変わり、それに伴って必要になる技術が変わることも珍しくありません。たとえ同じ言語、同じプラットフォームの開発であったとしても、実現する機能や利用するAPI、ライブラリまでまったく同じということはそうないでしょう。

なにより、次にどのような技術が必要になるかは「実際にプロジェクトに参加してみるまで具体的にはわからない」という場合も多いでしょう。そうなると「必要になったら入門する」という姿勢では間に合わない場合も出てきます。

そのため、フリーランスエンジニアは日頃からアンテナを高くして、今仕事で使っていない技術も、ある程度事前に学んでおく必要があるといえます。

会社員の場合、初めての技術であっても「投資」という考え方で会社が給料を出しながら学習・研究する時間を与えてくれる場合があります。

一方でフリーランスエンジニアは、基本的に「その場で価値が出せる」からこそ契約が成立することが多く、「じゃあ、この1カ月月間は成果が出なくてもいいから勉強していてよ」という話になることはほとんどありません。

少なくともその技術を学んだことがあって、スムーズに開発に参加できるレベルでの理解ができていないと、参加しても足手まといになってしまいます。場合によってはプロジェクト全体の価値を下げてしまうリスクもあるでしょう。

以上のことを踏まえると、フリーランスエンジニアが技術力で価値を出すには、「ひとりで」「幅広い技術を」「あらかじめ」学べるようになる必要がある、といえるでしょう。

では、そんなフリーランスエンジニアの学び方について具体的に考えてみましょう。

大事なのは以下の2点だと考えています。

• アウトプットする
• 公式ドキュメントとソースコードから学ぶ

それぞれについて詳しく説明します。

前述の通り、フリーランスエンジニアにとって「なんでも相談や議論ができる同僚」の存在はあまり期待できません。そのため、代わりとなる存在をネット上に求めるとよいでしょう。

しかし、「ネット上で議論する」とはいっても、何の理由もなくいきなり話に乗ってくれる時間のある人なんて存在しません。そのため、議論を生むきっかけをアウトプットする のが手っ取り早い方法です。

ひとことにアウトプットといっても、その方法はいろいろあります。

• 技術記事を書く
• 開発専用のSNSアカウントを作って発信する
• サービスやライブラリを開発し、公開する
• 勉強会でLTする

アウトプットを続けていれば、必ずそれを目にした誰かがフィードバックをしてくれます。

例えば記事を書けばコメントが、SNSで発信すればリプライが、ライブラリをGitHubで公開すれば世界中の開発者によるフィードバックがissueとして返ってきます。それを元に議論して理解を深める、というわけです。

例えば私の場合は、 QiitaやZennに記事を投稿し、開発用のTwitterで技術的な発見を発信し、crop_your_imageというFlutterパッケージを公開しています。いずれもそこそこの数のコメントやissue がつき、そのたびに新しい発見や自分では出せなかったアイデアを得られています。

これらのことを実際にやっていて思うのは、このようなアクションを起こすのは特に難しいことではないということです。ほかの誰かが書いた記事と同じ内容の記事を書いてはいけないルールはありませんし、規模の小さいコードを公開してはいけないルールもありません。そして多くの勉強会ではLT初登壇の方を待っています。

つまり、自分が得た知見や作ったものをほかの人に見せるとき、「ほかの人が何をやっているか」は関係ないのです。あるのは自分が「やる」か「やらない」か、最初の一歩を踏み出すかどうかの違いだけです。

まずはひとつ、学んだことや作ったものを自分のやりやすい形でアウトプットしてみましょう。反応がなければもう一度試してみればいいだけです。それだけでも新しい学びが期待できます。

ひとりで技術を学んでいて一番リスクになるのが、「間違った知識のまま定着してしまう」という点です。ひとりで学んでいて誰かにその知識をアウトプットする機会が少なければ、誤解や偏った解釈を訂正される機会も少なくなります。

そこで必要になるのが、信頼できる情報源、つまり公式ドキュメントやソースコードを読むということです。

公式ドキュメントには、その技術がなぜ現在の設計や実装になったのか、内部的にどのような仕組みで成り立っているのか、という「原理原則」が開発者の言葉で説明されている場合が多くあります。

そのような原理原則をおさえておくことは、正確で質の高い理解につながるだけでなく、学習の効率化にもつながります。

一般的にプログラミング学習において、「使い方」をひとつひとつ覚えることは効率の悪い学び方です。プログラミング言語にせよ、フレームワークにせよ、バージョンアップによって具体的な使い方は簡単に変わってしまうためです。また、ひとつひとつの機能や API の使い方まで覚えようとすると、情報量が膨大すぎて頭がパンクしてしまうでしょう。

一方で原理原則となる仕組みは、その技術で一貫している基礎的な部分と言えるため、それさえ理解してしまえば個別の機能やAPIの理解に応用できます。また、その基礎はバージョンアップ等による変更でも変わらないことがほとんどですので、それによる学び直しも発生しません。

このような基礎が理解できていれば、個別の具体的な「使い方」は必要になったときに調べる程度で十分対応できるでしょう。このような学習方法は、脳のキャパシティや学習時間の節約にもつながり、限られた時間で幅広い技術をおさえることが可能になります。

会社員とフリーランスエンジニアでは、技術の習得のための環境や必要になり得る技術範囲、経験する機会の有無という点で大きな違いがあります。

特に「一緒に試行錯誤ができる仲間がいるかどうか」という点は、学習効率を左右する大きな問題です。外に向けたアウトプットを意識的に行うことで、そのような仲間を見つけるのも、フリーランスエンジニアにとって大事な行動となるでしょう。

エンジニアファーストでは、フリーランスエンジニア同士のつながりを広げる取り組みも行っていますので、これを利用して一緒に新しい技術を学習できる仲間を見つけるのもよい選択肢です。

また開発だけでなく、営業や契約、お金の管理も自分でやらなければならないフリーランスエンジニアにとっては、限られた時間でより多くを学ぶための学習効率も重要です。

読みやすいからといって、誤った内容を含むリスクのある技術記事ばかりを読むことや、その技術の「使い方」ばかりを調べてサンプルコードが動いたら満足するのではなく、信頼できる公式ドキュメントからその技術の根幹となる仕組みや思想を理解することを意識してみてください。最初は難しいことも多く理解に時間と根気を必要とするかもしれませんが、そこで得た知見は必ずその後の効率的な学習につながるはずです。

どの現場でも技術力で価値が出せるフリーランスエンジニアを目指し、よりよい学習方法を探してみましょう。