受託開発の難しさも知った上で、それでも面白いと思う理由
エンジニアにとって、自社開発は魅力的な仕事の一つです。グッドローカルもいつかは自社サービスをつくりたいと考えています。
一方で、受託開発ならではの面白さがあるのも確かです。自社サービスに憧れている人たちは、もしかするとその面白さが見えていないのかもしれません。
今回は、受託開発歴15年の僕が感じるクライアントワークの魅力を伝えたいと思います。
成長せざるを得ない環境で仕事ができる
「納期が厳しい」「自分たちのつくりたいものをつくれない」など、受託開発に対してネガティブな意見を耳にすることがあります。スケジュールやプロジェクトの内容を自分たちで決められない点に、息苦しさを感じる人もいるのでしょう。
また受託開発のマイナス点として、経営的なリスクもあります。案件ごとに契約を結ぶので、受託開発は収入に波が生まれやすい。売り上げを確保するための営業は必要ですが、受注しすぎると今度は自社のリソースが不足してしまいます。事業のバランスを保つのが大変なのです。
ですが、こうした一見デメリットに思えることは、営業方法やお客さまとの付き合い方、契約方法などを工夫することで回避できます。リスクや大変な点があるのは事実ですが、それ以上に得られるものが大きいのです。
まず、クライアントワークでは幅広いスキルが身に付きます。
自社開発で特定のサービスをつくり続けていると、基本的に使用する言語や環境、ビジネスモデルはすぐに変わったりしません。一方、受託開発はプロジェクトによって必要な技術や環境が変わってきます。色々な手法を駆使しないといけないので、おのずとスキルが身に付き、成長できるのです。
少し昔のことですが、自社サーバーをAWSに移行するプロジェクトに携わったことがありました。プロジェクトを進行するには、AWSについてある程度知っておかなければなりません。お客さまやエンジニアと話をするために、自然と勉強することになりました。
こうして得た知識は、プロジェクトが終了した後も役に立ちます。例えば、別のお客さまがAWSを使用していたときや、AWSについて質問を受けたときなどです。
サービスの立ち上げに何度も関われる点も、クライアントワークならではの魅力でしょう。この業界にいる人たちの多くは、新しい技術やトレンドが大好きです。受託開発なら、担当プロジェクトが変わる度に、最新のトレンドをインプットする機会に恵まれます。
複数のプロジェクトに関わるため、スキルや経験値が溜まりやすく、それらを活かすチャンスも多いのが受託開発の特徴です。
自社のスケールを飛び越えたビジネスに携われる
受託開発の仕事を面白いと思えるかどうかは、お客さまのビジネスにどれだけコミットできるかに比例していると思います。言われたシステムをただつくるのではなく「ビジネスの課題を一緒に解決するんだ！」という姿勢で臨むほど仕事が楽しくなるはずです。
様々な業界・業種の大規模なビジネスに触れられるのは、お客さまのおかげです。
だって、考えてみてください。グッドローカルは、湘南にある僕一人の会社です。
10畳ほどのオフィスに、たまに時短勤務のアルバイトさんが出社するくらい。そんな小さな会社が、大手自動車メーカーであるダイハツさんのプロジェクトに携り、全国規模のアプリ開発をしているのです。すごいことだと思いませんか？
また、たくさんのユーザーにつくったものを届けられるのも大きな魅力です。
前職のアベリオシステムズでは、HONDAさんのスマホアプリを開発していました。サービスを提供するのはHONDAさんなので、リリースした途端に100万人規模のユーザーが使用してくれたんです。
もし、同じ内容のアプリを自社サービスとして開発していたらどうでしょう？ ユーザーに認知され、ダウンロードしてもらって、実際に利用してもらう。道のりは長く険しそうです。
自社の規模を超えたプロジェクトに関われるのは、この仕事の一番楽しいところだと思います。
「あったらいいな」にどれだけ応えられるかが腕の見せどころ
お客さまのビジネスにコミットするためには、ご用聞きにならず、対等でいることが重要です。
僕は仕事でもプライベートでも、お金を払うほうが偉いとか、何かをしてあげるほうが上だとは思いません。どちらかが上下関係を持ち込むと、対等な関係性が崩れてしまいます。お客さまを立てようとして、こちらが下手に出るのもよくないのです。
クライアントワークにおける「対等」とは、何も偉そうに振る舞うことではありません。受託開発に苦手意識を抱いている人は「お客さまの意向は絶対だ」と思い過ぎているのかもしれません。
お客さまの要望は吸い上げるけど、忖度はしない。無理難題を言われたら「それは無理ですよ」と伝える。それだけです。
ただし「難しそうなものは断ろう」という意味ではありません。お客さまが提示した難題をいかにして解決するかは、PMやエンジニアの腕の見せどころです。
要件定義をする際、僕は要望を「MUST（絶対に必要）」と「WANT（あったらいいな）」に振りわけてもらいます。MUSTを実現させるのは当然のこと。その上で、WANTにどれだけ応えられるかが楽しみだったりします。
このWANTをどうとらえるかが分かれ道です。「お客さまの要望だから、無理してでも全部なんとか実現しなくちゃ」とプレッシャーに感じるのか、「必須じゃないけど、実現できたら喜んでくれるな。誰も疲弊せずにしっかり達成できるラインはどこだろう」とワクワクするのか。
僕は後者で臨みます。そのほうが楽しいですし、お客さまにも喜んでもらえます。
PMの仕事にゴールはない。今も模索中
僕は便宜上PMを名乗ってはいますが、「PMだから」とか「PMとしてこうあるべき」とはあまり考えていません。
というのも、世の中にはPMを生業にしたものすごく優秀な人たちがたくさんいるからです。分析や経営戦略に長けた彼らと比べると、とてもじゃないですが「PMです！」と胸を張って言えません。
自分の肩書きを自由につくれるなら「ホスピタリティを強みにした、システムが得意な人」でしょうか。近所にいるITに詳しいお兄さん、くらいの立ち位置がしっくりきます。
ただ、職種にこだわりがないからこそ、興味のあるものは何でも学んで取り入れてきました。Webデザインやプログラムは独学で身に付けたものです。システム開発まわりの技術を幅広く習得したことは、結果としてお客さまの要望を吸い上げて形にするPMの仕事に活きています。
思い返すと、僕は子どものころからとにかく手を動かして覚えるタイプでした。PMの仕事も同様で、ずっとスクラップ・アンド・ビルドをしています。
技術は日々進歩して、僕たちを取り巻く環境も変化します。自分なりの仕事術を確立させようとしても、そもそも仕事像が完成する日はこないのかもしれません。
でも「これで完成だ」と思ったらそれ以上の成長もない。だからきっと、これからも理想の仕事像を模索し続けるのだと思います。
＝＝＝＝＝＝＝＝＝＝＝
今後、定期的に更新していきますので、ぜひこちらのアカウントをフォローいただけるとうれしいです。この記事へのスキもお待ちしています！
またグッドローカルや僕に少しでも興味を持ってくださった方は、TwitterのDMからご連絡ください！
▼現在募集中の職種は下記に掲載中
この記事が気に入ったらサポートをしてみませんか？