自己紹介
はじめまして、榎本（@plus_one_masaki）と申します。
もともと情報系の工業高校を卒業後、接客業や営業職を点々としていました。30歳手前で一念発起してエンジニアになり、3年ほど前からフリーランスで活動しています。
今は少人数な案件（主に中小企業の案件）を好んで受けており、LaravelとVue.jsをメインに扱っています。今回は少人数案件の魅力と注意点についてご紹介したいと思います。
※ここでいう少人数案件とは次のようなプロジェクトを指します。
- プロジェクトメンバーが3人以下
- プロジェクト期間が3ヶ月未満
▲運営中のブログ。フリーランスのWEBエンジニアについて不定期で情報発信中
少人数案件の魅力
もちろん例外もありますが、少人数案件の魅力として感じているのは次のような点です。
- スピード感が早い
- 自分がプロダクトを作っている実感を得やすい
- 裁量を持ちやすい
- 設計から実装まで、一貫して関われるチャンスが多い
- 規模が小さい案件ほど最新のフレームワークやAWSなど、モダンな開発環境が選ばれやすい
まずはスピードの早さですね。少人数なので開発自体サクサク進みますし、そもそも開発期間も数ヶ月なので、本当に必要な機能を短期で集中して作り上げる案件が多いです。
大きな案件になると関係者が増え、開発以外のことに時間を取られたりしますが、そういうことが無いのは大きな魅力です。せっかちな私にとってはぴったりです笑
また、プロダクトを作っている実感を得やすいことも魅力の一つです。私自身、「うちの会社がすごいプロダクトを作ったんだ」という実績を得られるより、「自分がこのプロダクトを作ったんだ」という実感を得ることが好きなので、関わる範囲が大きい少人数案件の方が向いています。
3つ目に「裁量を持ちやすい」ということがあります。少人数で早く開発することが多いので、細かな仕様まで詰めるのではなく、各人のやり方が尊重される現場が多い気がします。
仕様や技術選定に際しての提案をしやすく、プロダクトの上流から関われるチャンスも多いです。機能についての提案が求められることもあります。
また、少ない人数で効率的な開発が常に求められるので、モダンな開発環境が選ばれやすいという特徴があります。少人数案件自体、実験的な側面もあることも原因の一つです。
そのため、モダンな技術で実績を作りたいという人には少人数な案件は向いている場合が多いのではないかと思います。
少人数案件で気を付けること
さて、メリットばかり強調してきましたが、少人数案件のメリットを享受するために特に意識していることが3つあります。
1つ目は、能動的に仕事を作っていく、巻き取っていく姿勢を忘れないこと。
メリットの「裁量」の裏返しなのですが、個人の裁量が大きい分、仕事を作っていく姿勢が期待されます。自分から進んで仕事を定義して、積極的に案件に貢献できないと厳しいでしょう。
2つ目はクライアントにいち早くアウトプットを見せて安心させることです。これができなければ信頼を得られないどころか、クライアントの不安から裁量を制限されていくことにも繋がってしまいます。
特にフロントエンドでは次のような点を意識しています。
- 環境構築は最優先で行う
- ページ単位で細かく成果物を提出
小さな機能/画面でも、アウトプットとして出せるようになった段階ですぐに共有するようにしています。
3つ目に関係者とは密なコミュニケーションを取ることを心がけています。少人数案件では各々「よしなに」実行していくことが求められます。ただ、各々がよしなに実装する部分が多いと、担当者同士の認識違いが自然と生じてしまいます。
そのため、特に他機能との連携が発生する箇所では、他の担当者と密にコミュニケーションを取り、認識をすり合わせていくことが必要になります。
例えば、バックエンドとフロントエンドの領域で、どこまでをフロントエンド側が担当して、どこからバックエンド側で担当するのか、ということを意識的にコミュニケーションを取って、はっきりと明文化しておく必要があります。
▲2018年の10月ごろにリリースしたポートフォリオページ。キャラクターが話しかけてくるゲーム風のデザインでプチバズり。
よくあるトラブル
メンバーが辞めてしまったり、能力の不足があったりすると、担当されていた機能の開発部分の追加開発のために残りのメンバーの負担が跳ね上がってしまうことがあります。もともと、一人ひとりのメンバーへの依存度が大きいプロジェクトの場合、何らかの理由で離脱した場合のインパクトが大きいのです。
正直、こういったことは何度か経験がありますが、完全に防ぐことはできていません。直近だと、少しでもそういったリスクを小さくするため、開発メンバーに1度働いたことがある人が少なくとも1人いる、という条件で案件を受けています。
一緒に働いたことのあるメンバーだと、コミュニケーションも取りやすいですし、お互いの技量や仕事の進め方も把握できているため、事故案件になるリスクが大幅に下がります。
見積もりのときの注意点
少人数な案件だからこそ、クライアントは予算のズレにとても敏感です。
そのため、見積もる時に必ずヒアリングして、クライアントからの要望をそのまま受け取らないようにしています。
これは本当にクライアントにとって必要な機能なのか、もっと簡単なやり方があるのではないかと常に考えながら、提案していくことが大切です。
この際、選択肢は2つに絞って、クライアントが迷わないようにして提案していくとスムーズです。
炎上することもあるがやりがいがある
もともと僕は次のような願望があって少人数案件を好んで受けるようになりました。
- 新しい技術を学ぶのが好き
- 少人数で調整工数が少なく、スピード感のある開発ができる環境
- みんなで一つの大きなものを成し遂げるより、一人または少人数で、ユーザーからもクライアントからもフィードバックが返ってきやすく、価値が実感しやすい環境で作りたい
ただ、基本的には中小企業がクライアントになるので、報酬が支払われず泣き寝入りすることも、案件が大炎上してしまうこともあります。
それでも少人数でスピード感を持って開発していく案件はスキル的にも鍛えられますし、なにより楽しいです。
ミニマムな開発体制で開発することの楽しさが伝わっていれば幸いです。