この間、プログラミング徹夜時代を思い出した夢を見て、夜中に飛び起きてしまった、ユゲタです。
当時は昼夜問わず、ずっとパソコンの前に座って、ひたすら仕様書もない機能構築をしていたことを思い出しました。
・・・あれ？今もずっとパソコンの前にいて、プログラミングを朝起きてから寝るまでやってるぞ・・・
でも、今は何のストレスもない・・・何が違うんだ・・・
おそらく、無駄な会議も無ければ、自社の仕事として作っているサービスや、趣味で構築しているシステムであれば、誰からもせっつかれる事も無い。
これはやっぱりその環境における、エンジニアの無意味なストレスが大きかったんだろうな・・・と今更ながら感じてしまいました。
当時は一生懸命だったので、言われるがままだったんですねwww
プログラミングに指示をする営業体制
ちゃんと仕様設計を管理するSEや、ディレクションを行う担当者、などがいる会社であっても、実際の開発員に対して、色々と意見をする場面というのは、あるはずですが、
ユゲタの前に所属していた会社では、営業部門が直に開発部門に対して、案件獲得をしてくるための相談をしたり、
案件対応をストレートに行っている風潮でした。
でも、これは、ベンチャー企業であれば、当たり前の風景なので、特にこれが悪いという事は感じなかったんですが、
プログラミングがわからない人が、プログラミングを商材とした商品を販売しようとすると、何かとプログラマーに対して質問をすることが必須になります。
よくあるやりとりは、次のような感じです。
「こういうプログラム作れますか？」
「どのくらいでできますか？」
「工数はどれくらいですか？」
「難しいところはなくしてできるだけ早く作るとしたらどんな感じですか？」
毎日のようにこのやり取りをしている会社も多いと思いますが、
営業の人ってこういうやり取りをしてなんぼという事もありますが、プログラマーの人たちの本音は
「正直めんどくせーなー」
です。
だって、正直、作ったことのないプログラムって、作ってみなければどのくらいで作れるかわからないですからね。
「それを○人日で作れます」
なんて、気軽に言ってしまうと、もし、想定していた仕様漏れなんかがあったとしたら、とんでもない地獄が待っているのはわかってますからね。
そこで、ユゲタが編み出した技は、
「だいたい1週間ぐらいあれば、どんなに膨らんでも大丈夫だろう」とか、
「1ヶ月あれば、リカバリーすることも可能だろう」という風に、
バッファも含めた最大値を、出すようにしました。
結果的に、営業は売上金額があがるとともに、自分の予算消化につながるので喜び、クライアントも、決め打ちの値段で発注できるというところで、winwinに慣れたということなんですが、
中には、高額になりすぎて失注することもしばしばありましたが、それは、受けてはいけない危険な案件ということで、結果的に良しとしていました。
だって、おそらくちゃんとした金額で作業したとしても、金額が見合わないという事につながるクライアントという事ですからね。
でも、重要なのは、法外なバッファを含めた工数を算出するのではなく、クライアントが聞いて適正と思える工数を算出するというのがコツなんですよね。
コレ、結局、経験からくる、工数見積のスキルって言うことになると気がついたのは、独立をして、値段交渉を自分からするようになってからなんですけどねwww
やらなくていい指示を出す人
システム開発を依頼されて作る時に、どんな場面でも、お金を出す側の人は、
「作るのが大変だったら、簡単な方でいいですよ」
という言い方をする人がいます。
たしかに、AとBという2パターンの方法があり、どちらにするかで迷っている場合であれば、その言い方で簡単な方を選択するだけでいいんですが、
そうではなく、Aという方法しかなくて、その他の方法は、もっとしんどくなる場合にこのセリフを言われることが多いのです。
すでに簡単な方として、Aを選択したのに、時間がかかる、追加工数が発生する、または、なんかしんどそうに作業している、というような事を察して、
良かれと思って言ってくれているのはわかりますが、実はこれ、プログラマーの人にとっては次のように聞こえている場合があります。
お前のスキルじゃ、できそうにないから、もうやらなくていいよ
いや〜怖いですね。スキルの低いプログラマーほど、もっとドグつく聞こえているようですが、
一旦任せると言ったのであれば、あまり口を出さないほうがいいのかもしれませんね。
あ、ちなみに、コレは、ユゲタの後輩数人が言っていた話で、自分の経験ではありませんよ。
業務委託フリーランス必見、値段は最初に決めないテクニック
システム開発をお願いする人にとって、プログラミング関連の開発発注は、とにかく高額なお金がかかるモノとして認識しているかと思いますが、
安い値段のシステムは安いなりという事も理解しないととんでもない痛手をくらってしまいます。
そして、システムを受託する側にとっては、安い金額で契約して、終了するまで逃げられなくなるというのは、なんとしても避けたいものです。
例えば、1人月70万円で受託している開発員の人が、１つのシステム構築で1ヶ月半ぐらいでできるので、100万円で受けたとしたら、
まあまあ、いい金額なのではじめは良いかと思っていたけど、2ヶ月たっても3ヶ月たっても終わらない案件であることに、数カ月後に気がついてしまう事があります。
これはユゲタがこれまで何度も経験してきた案件なんですが、システム発注側は、見積書として一旦金額を決めてしまったら、その後完成するまで気が済むまで口を出せるような形になっていたという事なんですね。
これを防ぐためには、「仕様」が決まっていない案件は、仕様が決まるまでを１つの目処としての見積もりをして、仕様が決まってから完成までを第2フェイズとして、追加見積もりをする形にすることをオススメします。
発注側としては、おそらく2倍ちかくのコストになってしまうので、金額が高く感じてしまうかもしれませんが、
実際には、
・想定しているシステムをITで実現するためのコンサルティング
・UIを意識したデザイン
・UXを意識したデータ設計や遷移
・最終的に使いやすいかどうかを判断するユーザビリティ
これらを大きくくくって「コンサル」という感じで行う必要があるクライアントの方が圧倒的に多く、実は実際にはそういうコストは開発側がおまけとして対応しているというケースも少なくありません。
これを見分ける方法として、ユゲタとしては、「簡単なシステムだけど作ってくれない？」と言う人は、何を持って簡単なのかを説明出来ない上、大体の人がITが苦手という人が多いので、
見合わない工数でのやり取りをすることになり、結果的にお互いになんかモヤモヤした開発完了になる事が多いので、安請け合いをするなという話に繋がります。
やっぱり、人のシステムを作るよりも、自分のシステムを作る方が、自分にあっていると、朝の珈琲を飲みながら、改めて考えてしまった今日の朝活でした。
