今の案件内容と獲得経路
Javaをメインにフリーランスエンジニアをしている、いろふ（@irof）です。システム開発の仕事は10年以上、フリーランスとして独立して4年目になります。
会社員をしていた頃は主に企業内で使われる基幹システムの開発に携わってきました。フリーランスとしてはシステム開発だけでなく、Javaに限らない技術支援やチームビルディングのサポートなどいろいろさせてもらっています。コミュニティ活動として関西Javaエンジニアの会などをやっています。
▲JJUGでの直近の登壇資料
今回は、フリーランスとしての案件を紹介した後に、Javaのトレンドから考えるフリーランスとして必要なスキルについて考えていきたいと思います。
どんな内容でもまずは声をかけてもらうことが重要
実際にやっている案件は、もちろんJavaのシステム開発もありますが、それだけに限りません。たとえば、システム構成の検討やデータベース設計、モデリング、CI/CDなどで、これらの案件ではJavaを採用しないこともあります。
フリーランス向けの案件情報サイトや会社間の情報共有では「SpringBootを使用したXXXシステム開発」などをよく見ると思います。これらは広いコンテキストで募集するため、どうしても似たり寄ったりに見えてしまうでしょう。
私は案件情報サイトなどは使用しておらず、これまでの案件はすべて紹介で頂いています。経路はコミュニティ活動を通じての知り合いや、以前仕事でご一緒した方、Twitterやブログを見て声をかけてくださるものもあります。
▲運営中のブログ「日々常々」
こうしていただくお話は私に向けたものなので、ピンポイントの問題にフォーカスしたものであったり、逆に焦点が定まっていないふわふわしたものであったり、多種多様なものになります。話をいただく段階では案件の確度も高くなく、実際半分以上は具体化しません。それでも声かけ頂けることが重要だと考えています。
Javaの変化が案件に与えた影響は軽微
Javaと言えば、リリースモデルの変更に伴ってさまざまな憶測が飛び交いました。とくに「無償でなくなる」などのセンセーショナルなキーワードは目を引きましたが、たいして影響はなかったと言うのが実情です。本件に関する落ち着いた情報は以下を参照してください。
出典：Javaは今も無償です
憶測とともに「Javaはもう使われなくなる」「これからは（何か別の言語）だ」などと言われ、実際現場でも「Javaをどうしようか」と相談されることもありました。
しかし、この件でJavaの仕事が減るようなことはなく、Javaから他に置き換える話が具体化されることはありませんでした。もちろん私が関わる範囲というバイアスはあるかとは思います。
トレンドとしてJava案件は増えている
他言語のシステムをJavaに移す揺れ戻し傾向
言語が生まれて25年を数えるJavaはすでに古い言語と見られ、新規採用は減っているような印象を持たれているかと思います。しかし、1年くらい前から他の言語からJavaへの置き換え案件が増えてきました。
多くはRubyやPHPで構築された現行システムをJavaで再構築したいと言った話で、性能や保守性に重点を置かれています。中にはScalaからJavaと言う話もあり、単に静的型付け言語を求めているだけでもないようです。これらも、もちろん私の関わる範囲というバイアスはありますが、Javaの変化は「Javaを避ける理由にはならない」と判断されたのでしょう。
Javaが選択される理由はいくつか考えられますが、強いてあげるならば言語自体の安定性と、実行基盤であるJVMの強さがあると思います。
言語自体の安定性は後方互換性を指しています。Javaで過去のコードがコンパイルできなくなるのは限定的ですし、実行できなくなることはほどんどありません。20年前に作られたものが最新の環境でもごくごくあたりまえに使われていて、それが問題にならない。そういう安定性があります。
その後方互換性を支える大きな役割を担っているのが実行基盤であるJVMです。大規模かつミッションクリティカルなシステムで使われてきたJVMは、さまざまな課題に晒されて洗練され続けています。その成果を最大限享受できるのは大きな利点になります。
安定技術としての大規模なリプレイス
Javaへの置き換えが実際行われるにしても、システムの形も先祖返りするわけではありません。以前はJavaで構築されたシステムと言えば、多くのコンピュータリソースを確保してアプリケーションサーバーの機能を活用するのが一般的でした。
現在はクラウドプラットフォームやコンテナを活用し、小さい処理をうまくするものを組み合わせて大きな処理を行うことも増えてきています。どちらを一般的と言うかは難しいですが、選択肢として両方選べる必要があります。
先に挙げたようなJavaへの置き換えが検討されるような案件では、安定した技術が期待されます。Javaで構築されるシステムは大規模で堅実なものも多く、そのイメージを期待するようです。実際Java経験者は重要なデータを扱うデータベース設計を経験している人も多いため、大きく外してはいないと思います。
これからの重要性を増していくと考えているスキル
新旧情報の見極めと適用判断に使える自動テスト
Javaをメインとしていく上で必要と考えているのは、新旧情報の見極めと適用判断に使える自動テストです。歴史があることに加えてバージョンアップの速度が上がったJavaは、新旧の情報が混在しています。
そのような状況で新しい情報をキャッチしつつ、その適用可能性を確実かつ高速に検証できるスキルが必須です。もしアドホックに最新版を追いかけて問題を起こせば、安定性の期待を大きく外すことになってしまいます。
この辺りは2015年のJavaDayTokyoで話した内容から変わりません。当時はJava20周年。Java8がリリースされ、Java9以降加速していくと言われていた頃です。
想像していたよりもバージョンアップの速度は早くなりましたが、LTSで見れば大きく違いはありません。
シンプルなユニットテストでJavaのバージョンによる動作可否は確認できますが、性能面などを踏まえるとCI/CDを設計・運用できることの重要性が増しています。これらは数年前までは持っていることが強みだったのですが、そろそろ活用できないと厳しいのではないでしょうか。
幅広い知識を持っていることが大切
Javaだけに閉じると選択肢は限られます。Javaの動作するJVMの世界でほとんどが解決するシステムであればそれでもよかったかもしれませんが、昨今はJavaだけですべてを賄おうとするのはナンセンスです。
かと言って、他言語での実装やクラウドサービスを選択するのが絶対的な正解でもありません。必要な要件を見極め、案件に合う合わないの判断を下す。そのために幅広い知識が必要になってきます。
他言語からの置き換えでは現行システムの技術を多少でも知っていなければ「Javaにしないほうがいい」という提案はできません。実際、Javaに置き換えずRubyのまま進めた案件もあります。
言語や技術は単純な良し悪しで決定できません。プロダクトの性質や保守体制なども踏まえての、合うか合わないかです。
すべての技術を修得しているのは実現不可能な話です。特定分野に限っても本当にたくさんの選択肢があります。とは言え、他の何にも似ていない技術は滅多にありません。
技術は振り子や螺旋に例えられますが、自身の知っている何か他のものと照らし合わせて似ている点と違う点を見つけられると把握できる速度が上がります。似た技術があったとしても、別のものとして存在する以上、必ず差分はあります。その差分が今回関係するかを見極めて判断していく必要があります。
そのために広さと深さが重要になってきます。
いろいろな人の知見/現場の揺れ
このような広さと深さを、知識だけで得るのは難しいと感じています。書籍や記事を読んだりセッションを聞くと、広い知識は得られます。ここにはたくさんのキーワードがあります。最新の技術や自分が思いもよらなかった使い方、世界が見れて知的好奇心は満たされるかもしれません。
しかし、これらのキーワードを現場に適用するのは難しいです。書籍などの一般化された意見は綺麗すぎてどこから手をつけたらいいかわからなくなります。セッションなどの経験談の多くは包括的でありませんし、直面している現場とはコンテキストが異なります。知っていると使えるは違います。
なので現場経験が重要です。現場と一口に言っても千差万別で、同じ現場はひとつとしてありません。その中で得た知識を実践することで、ようやく使えるようになります。しかしひとつの現場で上手くいったからと言って、それがそのまま他の現場でも役立つ物ではありません。現場ごとの差異を見つけて、適用するかしないかを検討する。検討材料は現場での実践経験が非常に有用だと感じています。
パターン化・言語化
フリーランスはひとつの会社やひとつの案件に注力する働き方ではありません。必然的に広いコンテキストで得られた知識や経験を狭いコンテキストに適用することが求められます。
似た技術を使った案件があった、同じような悩みを抱えている現場があった、こう言う解決をしたらこんなことが起こった。そう言った経験をそのままにせず、自身の中でパターン化して道具箱に入れておくと便利です。
現場で活用しようとすると現場の人に説明する必要があるため、言語化が強制されます。言語化すれば自身でも見直せますし、話せばフィードバックが得られるかもしれません。こうして話すだけも、現場での実践のひとつだと考えています。実際にその技術をシステムに組み込むことだけが実践ではなく、現場のコンテキストに合わせて考えるだけでも、道具は洗練させていけられます。
いかに道具を揃えるか、選択するかが大切
システム開発は存在しないものを作る仕事です。道具は現場のさまざまな制約の中で使えなければ意味がありません。知っているだけでは使えませんし、持っているものを使うだけでは新しい選択肢を得られません。
新たな情報に触れ、実際に振るいながら使えるようになって選択肢広げる。そうして揃えた道具から現場にあった最善の道具を選択するのが、フリーランスの技術者に必要なことかなと思います。