「フリーランスが高めるべき「価値」とは」bravesoftインタビュー【前編】

bravesoftについて

事業の特徴と開発スタイル

ー御社は実に様々なアプリやWebサービスを展開していらっしゃいますよね。

弊社はお客様から依頼されたアプリやWEBサービス開発のほか、自社製品の開発も扱っています。それぞれの良さを極めることで、お客様により良いものが提供できると考えています。
例えば自社開発だと、社内のシステムを活かしてどんなサービスが作れるかを考えて開発していますが、受託開発ではお客様にとって最善のサービスになるためにありとあらゆる技術を用いて開発を進めます。
サービスを作っていくうえではどちらも大切な視点です。

ー実際の開発の現場では、どのようなスタイルで進めていらっしゃいますか？

お客様にヒアリングする段階にエンジニアも同席し、一緒に提案をしていきます。
「マネージャーが設計書を作り、エンジニアはその指示書通りに作る」というスタイルではなく、要件定義の段階からエンジニアも参加し、お客様がビジネス面とUXを両立させるためにはどんな技術が最適なのかを一緒に考えていきます。

技術の選定について

ー使用する技術はどのように選定されていますか？

新しい技術やトレンドの技術を使っていると前衛的なイメージがありますよね。ただ、それがお客様のサービスを成功に導けるものであるかどうかを見極める必要があると思います。
弊社の独自システムであれば社内でリスクが取れるので積極的に採用していますが、最新の開発言語となると、メリットと弱点の度合いをよく検討しなければいけません。
弱点をきちんと把握せずに使用してしまうと、お客様が利用される段階で予想外のトラブルが生じることもあります。我々にとっては良い経験になりますが、お客様にとってはマイナスになりかねませんよね。
あくまでも目的は、使っていただくお客様のユーザー、つまり最終ユーザーに良いものを提供して満足して頂くことですから。

ー前例が少ない技術を用いると、安定面で不安が残りますよね。

そうですね。ただ、同じ技術だけを使っていくと、動作が安定するので安心感はありますが、そのままでは次のステップに進みにくいというデメリットがあります。
今後は新しい技術がメインで使われるようになっていくので、必ずそれにキャッチアップしていかなければなりません。
「新しい技術をどこで使うか」のタイミングの見極めが大切です。
「今後のメンテナンスコストを考えて効率的な新しい技術を使用したい」というお客様もいらっしゃいますし、「ユーザーの離脱が懸念されるので、UIでは従来の技術を使用して、管理者に近いレイヤーで最新技術の導入を検討してみたい」という方もいらっしゃいます。
そういったリスクヘッジをお客様と共有しつつ、一緒にベストなものを選定していくというスタンスが求められると思います。

フリーランスエンジニアの活用について

ーそういった技術選定や設計の部分は、主に御社内のエンジニアの方が担当されるのでしょうか？

今のところは、弊社が全て一貫して請け負うことが多いので、技術選定なども社内で行うことが多いですね。ただ、今後は業務委託の方にお願いする機会が増えると思います。
社内で全ての技術をカバーするには学習コストも時間もかかります。例えばクラウドひとつとっても、AWSにAzureやGCPがあります。しかもAWSの中にもすごく種類があるので、全てを把握して使いこなすのは難しいですよね。でも、ビジネスのスピードはすごく早いので、何とかついていかなきゃいけません。
そんな時に、それぞれの専門に特化した方に教育頂いたり、サポートを頂いたりする機会が出てくると思います。

ー実際にフリーランスの方が御社で活躍されるシーンは増えてきているのでしょうか？

そうですね。現に、業務委託の方に社員へのナレッジの共有をしてもらうことがあったり、お客様と直接折衝して頂くこともあり、「社員か業務委託の方か」といった雇用形態を意識する場面は少なくなってきた気がしますね。

ー世間でもフリーランスの方が参画する機会が増えてきていますよね。

そういう流れになってきていますよね。
社内だけで優秀な方を揃えられたらいいかもしれませんが、ビジネスの流れに追いついていくにはそこにこだわらなくてもいい気もします。これからは人それぞれの価値観に合った働き方を尊重していく時代になっていくと思うので、会社も働く人もWIN-WINになる方法で進めていけたらいいのではないでしょうか。

フリーランスエンジニアに求める力

言語の種類よりも「設計力」

ーWebエンジニアとしてこの技術は欠かせない、という言語は何かありますか？

開発言語それぞれに特徴がありますし、どういう場面でどのように使えるか、というのは現場によって変わってくるので、「この言語だけやっておけばOK」と特定するのは難しいかもしれません。
どの言語を選ぶかよりも、「とにかく実際に手を動かして設計をしてみる」ことが重要だと感じます。新しい言語にキャッチアップしていくには、とにかく書いて設計してみること。
実際に手を動かしてみて、この場面ではこういうことを考えて設計する必要があるんだ、といった実務に直結する「設計力」を鍛えることが大事なのではないでしょうか。
弊社でもそういった経験の場を増やすべく、実際にシステムを動かしてテストをするまでの一連の流れが練習できる環境を用意しています。今でいうと、AWSのようなクラウド技術の実務経験は前提レベルで求められる技術だと感じているので、AWSを使って設計していく力を鍛えるようにしていますね。

ー「組み立てる力」を鍛えることが大切なんですね。

言語については、何か不明点があっても今はネットで調べればいくらでも解決策が出てきます。それはそこまで高い技術が無くてもできることですよね。それよりも、システムをきちんと組む設計力は、いつの時代でも求められる技術ですし、差別化できるポイントだと思います。
後から変更を加えやすい仕様になっているか、バグが出にくい設計になっているかで現場の負担は変わってきますが、実際にそれを実現するにはなかなか難しいですから。

ーそれは業務に主体的に取り組むことでも得られるスキルですよね。現場の開発環境や技術選定についても「指示されたから使った」というのではなく。

実際の現場では、効率性や耐久性など様々な視点を考慮して選定する必要があっても、「スピーディーに進められるから」といった理由で技術を採用してしまうこともあるかもしれません。
開発環境や技術について質問したりする機会が無い現場もあるだろうし、「会社でその技術を使っているからそれに従いました」という方がいても無理ないと思います。
ただ、「この現場ではなぜこの技術が使われているのだろう？」とか「もっと効率的なやり方はないのかな？」といった視点をもってみると、よりプロジェクトを俯瞰して見られるよようになりますよね。

トラブル回避に必要な「興味」と「論理的思考」

ー主体的に参画していると、より効率的な方法や改善策が提案できるようになるかもしれません。

それには、エンジニアが技術に強い興味をもっていることが大事です。
技術が大好きな方は、自主的に深堀りして疑問点を追求していってくれるので、トラブルが生じたときにも原因と解決策を論理的に解明してくれます。
どうしてもスピードが重視の現場では、問題が生じてもネットで載っていた解決策で対処してしまおうとしがちです。実際にそれで解決することも多いですが、それでは根本的な解決には至ってない場合があります。
同じような問題が何度も起きる可能性もあるし、違う問題も頻発するかもしれない。それを防ぐには、きちんとトラブルの根本を突き詰める必要があります。どういう仕組みのどこでトラブルが生じたのかというロジックを立てて考えなければなりません。
技術に興味があって追求してくれる方は、問題が生じたロジックを解明して根本的な解決策を掲示してくれるので説得力がありますし、その後は本当に不具合も生じにくくなるので現場の負担がグンと減ります。

ートラブル対処に時間を費やすことも多いのでしょうか？

むしろコードを書いている時間よりも、バグを修正したり不具合に対処したりすることの負担の方が大きいです。
そのため、開発のスピードや効率性を高めていくには、「そもそもトラブルを起こさない仕組みにするにはどう設計すればよいのか」を考えなければいけません。
社内でも、問題に対して「本当にその解決策で大丈夫？」と深堀りし合う習慣は付けていますし、外部の方にもこういったトラブル対処の経験の有無は伺うようにしています。

ー実際は、問題が起きない現場の方がまれですもんね。

その通りです。開発をしていて何かしら問題は起きるので、エンジニアの方がその問題にどう対処してきたのかは、気になるポイントです。
実際の面談で話していると、その方がどのフェーズまで改修に関わってきたのか、メインの開発の部分まで関わって来られたかどうかが浮き彫りになってきますね。

経験が少ない分野に参画するには

ー製造や保守だけしかやってこなかったという方も少なくありません。

確かに、同じようなフェーズしか経験してこなかった方もいるかもしれませんね。
ただ、以前関わって下さった業務委託のエンジニアの方は、修正が必要になったときに設計フローをご自身でまとめてこられて「こういう作りの中でこのように進めていけば修正不要だと思います」と論理的に説明してくれた方がいました。
このように積極的に提案してくださる方は、それまで設計や上流の経験が無かったとしてももっと上の部分をお願いしてみようかな、と思いますよね。

ー積極性が大切ですね。ただ、やはり経験が浅い方は、要件定義や上流を扱う案件に関わりたくてもそもそもチャンスに巡り合えない、というケースも多いです。

企業のカルチャーによっても変わってくるところですよね。
「上流の経験を積みたいです」と言われたとき、社員であれば会社にとっても長期的に見て教育する意義が高いと感じますが、短期間で関わる業務委託の方の場合は躊躇してしまうかもしれません。
でも、企業にとって何かメリットがあると感じられたら経験が浅くてもお願いすることがあると思います。例えば、「開発効率を上げられる技術の経験を御社に活かしたいので、上流に関わらせてもらえませんか？」と提案して下さったりしたら、「経験が少なくてもちょっとお願いしてみようかな」と思います。
ただ、今後はさらにエンジニアへの需要が高くなり、社員の募集にも苦労する時代になってきているので状況は変わってくるかもしれません。良い関係性を築けて長くお付き合いできる方であれば、会社の経営視点でのメリットが大きいので、外部の方にもどんどん開発のメインの部分をお願いする流れになっていくと思いますね。

後編はこちら

スペシャル一覧へ