受託開発を始めて18年が経った。気づいたら人生の半分近くをこの仕事に費やしてた計算になる。長いようで、振り返るとあっという間だったなとも思う。ただ、18年という年数は伊達じゃなくて、若い頃には絶対わからなかったことがたくさん見えてきた。今回はそのあたりを正直に書いてみようかなと思う。
受託開発の現実を若い自分に教えたかった話
20代の頃の自分は「良いコードを書けば評価される」と本気で信じていた。技術力があれば仕事は上手くいく、みたいな。でも実際はそんなに単純じゃなかった。
受託開発で一番大事なのは、コードよりもコミュニケーションだっていうことを、自分は5年くらいかけてようやく理解した。遅い。恥ずかしいくらい遅いんだけど、それが現実だった。
クライアントが本当に求めているものと、要件として書かれているものが一致しないことが多い。要件に書いてあることを完璧に実装しても、「なんか違う」と言われる経験を何度したか。最初のうちは腹も立ったし、なんで仕様通りに作ったのにって思ってた。でも今は違う。「なんか違う」が出る時は、要件定義の段階で何かがすれ違っていたんだと捉えるようになった。
要件の裏側にある「本当の課題」を掘り起こす
18年やってきて、一番スキルが上がったと感じているのは「ヒアリング」だ。コーディングじゃなくて、ヒアリング。なんかプログラマーっぽくないけど、それが正直なところ。
クライアントが「在庫管理システムを作ってほしい」と言ってきたとする。でもよく聞くと、本当の問題は在庫のカウントじゃなくて、発注タイミングの判断が属人化してることだったりする。その場合、在庫管理の画面を作るより、発注アラートの仕組みを整える方が価値が高い。
でもこれ、最初から言ってくれるクライアントはほぼいない。引き出さないといけない。そのためのヒアリング力は、正直ある程度の経験年数がないと身につかないと思ってる。
18年で変わった技術環境と、変わらなかったもの
18年前と今では、使っている技術がまるで変わった。当時はPHPとMySQLがメインで、フレームワークも今ほど洗練されていなかった。jQueryが出てきた時は「これは革命だ」って思ったし、クラウドが当たり前になった時も衝撃を受けた。最近はAIがコードを書く時代になって、また世界が変わりつつある。
変化のスピードに正直ついていくのが辛い時期もあった。40代に差し掛かってから特に。若い頃は新しい技術を覚えることが楽しかったのに、ある時期から「また覚え直しか」っていう感覚になった。これは受託開発あるあるなのかもしれない。
変わらないのは「問題解決の本質」
ただ、18年やってきて変わらないものもある。問題を正確に定義して、シンプルに解決する。これは技術が何になっても変わらない。AIがコードを書こうが、どのフレームワークが流行ろうが、「何を解決したいのか」を見極める力は人間がやらないといけない部分だとずっと思ってる。
少なくとも今のところは、そこが受託開発の仕事として残っている領域だと感じている。
お金の話を避けてきた結果どうなったか
これは正直に書く。受託開発をやっていく上で、一番失敗を重ねたのが価格設定と契約の部分だ。
若い頃は、値段の話をするのがなんとなく嫌だった。「仕事をください」という立場だったし、クライアントから「高い」と言われるのが怖かった。結果として、明らかに割に合わない案件を受け続けた時期がある。
工数を読み違えて赤字になったことも一度や二度じゃない。仕様変更が10回以上発生した案件で、追加費用を請求できずにボランティア状態になったこともある。それでも「次につながるかも」と言い聞かせてた。次につながった案件より、つながらなかった案件の方が多かったけど。
要件定義がない案件は見積もり2倍が正解
今は変わった。最初の見積もりで正直な金額を出せるようになったし、仕様変更が発生したら都度確認を取るフローを徹底している。これを始めてから、収益は安定した。
特に重要だと思っているのが、要件定義の有無で見積もりを変えるという考え方だ。要件定義書がない状態で「とりあえず作って」という案件は、最低でも通常見積もりの2倍を出すようにしている。経験上、要件定義ナシの案件は必ずといっていいほど途中で仕様が膨らむ。「そこまで想定してなかった」「やっぱりこの機能も欲しい」が連発する。2倍でもトントンになることがある。
見積もりスキルは受託開発のコアスキルだと今は思ってる。コーディングと同じくらい、もしかしたらそれ以上に。これが身につかないと、どれだけ技術力があっても受託では消耗する。
価格の話を避ける人は多い。特にエンジニア上がりの人は。でも受託で長く続けていくなら、ここは避けて通れない。
長続きする案件とそうでない案件の違い
18年で何百社かとやり取りしてきた。中には10年以上続いている付き合いのクライアントもいるし、1回限りで終わったところもある。長続きしている案件を振り返ると、共通点がある。
それは「定期的に話す機会がある」こと。納品したら終わり、じゃなくて、その後もちょいちょいコミュニケーションが続く関係のところほど長続きする。別に毎月何かを作り続けている必要はなくて、「最近どうですか」みたいな会話があるだけで全然違う。
逆に、最初の案件で「完璧に作って納品」することだけを目指すと、なかなか関係が続かない。これも若い頃には気づかなかったことで、納品クオリティを高めることに全力を注いでいた時期があった。もちろん品質は大事なんだけど、それだけじゃないんだよね。
18年やって思うこと
結局、受託開発って、クライアントの愚痴を整理して技術に翻訳する仕事なんだと思う。それを18年かけて、痛い目に遭いながら腹に落としてきた。
ヒアリング、見積もり、契約、関係の維持。これ全部、コーディングより先に身につけるべきだったかなと今は思ってる。でも若い頃の自分は絶対信じなかっただろうから、まあ仕方ない。
最後に一個だけ言っとく。要件定義がない案件の見積もりは、倍で出してみて。怒られることも断られることもあるけど、それより受けた後の消耗の方がしんどいから。