フリーランスエンジニアのむしゃくしゃを書き殴る

フリーランスのエンジニアとして働きはじめてもう数年が経とうとしている。
これまでいくつものスマホアプリやWebサービスを開発したり、ライティングやデザインも納品してきた。

最初の頃は勝手がわからず、仕事をしてると、「あー、なんかむしゃくしゃするなー、モヤモヤするなー」と感じることがあった。

今、プログラミングを勉強してフリーランスになるのが流行ってるらしい。
フリーランスに成りたいと考えてる人に参考になるのではないかと、むしゃくしゃと感じた記憶を書き殴ってみたいと思う。

私の伝え間違いでした

アプリの開発途中で「こうしてほしい」と要望が来たので、素直に実装してみると「これは違う」とバグ報告されたことがある。
確認してみると「私の伝え間違えでした」と言うのだ。

その後も、「こっちを使ってほしい」と送ってくる文字や画像が間違ってることもよくあった。そのおかげで何度も私の開発労力が無駄になったのだ。

「そちらもプロならプロらしくしてくれ！」とむしゃくしゃした。

工数は、開発だけじゃない

クライアントから仕様書が送られることが多々あるが、だいたい抽象的な表現、わかりづらい文章、表記の揺れ、仕様の抜け漏れ などがあるものだ。

そうなると、仕様の確認が頻発したり、代わりに別の仕様を考えたりもすることもある。それはそれは結構な時間を奪われるのだ。
そしてスケジュールも遅れだし、遅れを取り戻すために夜中まで仕事し、「手を動かす工数しか考えてなかったな...」とむしゃくしゃしちゃうのだ。

コミュニーケーションコストも見積もるべきコストであることを忘れなければ気持ちよく仕事ができる。

引き継いだバグとの闘い

とあるアプリの機能開発を引き継ぐことになった。最初に前任者のバグをクライアントが洗い出して修正をしたのだが、開発をすすめていくと、別の前任者のバグが大量に発生。

悔しかったのは、その前任者のバグを、さも私のバグのように言われたことだった。
最初の"前任者バグの洗い出し"をクライアントは軽くしかしてなかったってことじゃないか。その時に見つかったバグ修正分しか費用をもらってないぞ。新しく見つかった前任者バグの修正は、機能開発の見積り費用の中に含まれるのか？などを考えると、怒りをどこにぶつけたらいいかわからず、むしゃくしゃしまくった。コードを読み直してみると、パフォーマンスも考えられてない雑な設計であることがわかり、さらに腹立たしくなった。

開発の引き継ぎ案件の際には、最初に自分でとことんアプリを触り、バグを洗い出し、事前にコード全体を把握しておくという基本を忘れてはいけない。

工数3ヶ月の納期は2ヶ月後

アプリ開発の依頼があり、資料も何もないままヒアリングすると３ヶ月かかりそうだったので、おおよその工数を伝えた。

詳しい要件を資料にまとめるというので待ってみるが、何度か催促して、ようやく送られて来たのは２ヶ月後だったのだ。
さらに、とある事情で２ヶ月後の納品が必須と告げられた。突如、３ヶ月の工数案件を残り２ヶ月でこなせという何題が与えられたのだ。

「難しい」とわたしが伝えると「こちらも事情がある。できてないと困ります」と返答。
開発期間に余裕がないのは自分らの都合であるにも関わらず、その負担を平気でエンジニアに押し付けようとする意識が許せず、むしゃくしゃした。

お金がなくても無理せず案件を断る勇気を持とう。

細かい作業なので一緒にお願いできますか？

文言や画像の差し替えを「小さい作業」と捉えがちだ。
だから「一緒にお願いできますか？」と言われることが多々ある。

一度これを許した私は、何度もタダでやらされたことがある。ときには、文言A → 文言B → 文言A に戻させられるなんてバカバカしいこともやらされる。

それだけだろ？と思われるだろうが、変更をする度に、WEBならデプロイ、スマホアプリならビルドして配布せねばならない。
もしかしたら、これも「それだけだろ？」と思われるかもしれない。
意外かもしれないが、これも面倒で割と時間のかかる作業だ。
一度に複数箇所の変更を依頼されるならまだマシだ。デプロイ/ビルド・配布を一度で済ませることができるからだ。だが、時間差で細切れに依頼されることが多い。"(1 + 1) × 10" と "1 × 10" では、えらい違いだ。

どんなに小さい作業でも対応可能回数を決めておこう。それ以上の要求は１回につきいくら支払ってもらうかを決めておこう。
そうすれば複数箇所の差し替え作業を一度にまとめて依頼される。

参考サイトがあっても気を抜くな

資料なく「このサイトみたいのが良い」とだけ言われた時、まずは自分でも要望を何かに落としてもらうようにしている。
すると、だいたい話に上がらなかったものや、参考サイトにないものまで出てくる。

クライアントの方がそのサイトに詳しいはずなので、初見のエンジニアでは気づけてない機能も要望に入っているはずだ。
ヒアリングして、要件定義書を作っても、後々に「このサイトにあるのだから、作られるものだと思ってた」と言われる。

それなら、まずは自分で資料に落としてもらう方がリスクが低い。資料に落とすことで、クライアント自身も言語化できてない無意識の妄想に気づけるかもしれない。
そもそも、初めて会った他人同士が、いきなり全く同じイメージを共有することなんて不可能だろう。

お休みのところすみません...

休日や深夜に電話をしてくる方は結構いる。
頭を勝手に仕事モードに切り替えられると休めなくなる。休める時にしっかりと休むのも大事な仕事だ。
休みの日や深夜には電話してくるなとちゃんと伝えよう。連絡が取れる休日があるなら事前に伝えておけばいい。

これくらいならすぐできますよね？

たまに自分の経験や感覚でこう言ってくる人がいる。では、実際に機能を作るために必要な作業を教えよう。

・あなたからの要望を聞く作業
・アイデアに抜け漏れがないか、リスクがないかを考える作業
・他のコードに影響がないかチェック
・実現させるためのコード設計を考える作業
・実装
・実装した後に、問題がないかとテストをする

これだけある。システムが大きいほど、こりひとつひとつが複雑となる。
簡単そうなものでも、いざ実装してみると複雑にならざるを得ないというのはよくあるので、エンジニアも安易に受け入れるのは良くない。

必要なコストと、なぜそれだけコストがかかるのかを説明できれば納得してくれる人は多いので恐れずに主張してほしい。もし高いと言われれば、安くするにはどれくらい妥協すればいいか伝えればいい。

テレパシーか

クライアントが深刻そうに「あれ？○○ってないんですか...？」。
はい、あなたが一度も説明しなかった、どの資料にも書かれてないものを勝手に理解して作ることは私にはできません。
テレパシー能力を身につけておくことも必要だ。

最後に

他にもいろいろとあるが、さっと書き殴ってみた。
おそらく、それぞれのむしゃくしゃに対して、もっと良い方法だったり、ちがう考え方もあるかもしれない。
こうして振り返ると、プログラミングや設計ができるだけじゃなくて、対人能力とかプロジェクトマネジメント能力とか交渉力とか、そういうのも必要なスキルだなぁと改めて思った。
コミュニケーション能力があるプログラミングができるエンジニアはやっていけるんじゃないだろうか。

現場からは以上です。