【サポーターズCoLab勉強会】客先常駐エンジニアが戦闘力を上げるN個の方法に行ってきました

【サポーターズCoLab勉強会】客先常駐エンジニアが戦闘力を上げるN個の方法

https://supporterzcolab.com/event/362/

に行ってきたので、そのレポート

※今回の講演は、あくまで登壇者の方の経験や意見です。

そもそも客先常駐って何?

  • 別の企業に出航して働く形態
  • SI系によく見られる
  • 派遣の場合もあるが、そうでない場合もある。

求人について

  • とりあえず未経験でも採用しているところが多い
  • 大手は新卒メインだが、中途は通年採用もしている
  • 前期黒字(設けている)ことを強くアピール
  • 土日はしっかり休めそうな雰囲気
  • 開発案件に携われるということを押している

実際にやる仕事

  • コールセンターだったり
  • SEサポートだったり、
  • ヘルプセンターだったり
  • テスターだったり
  • etc…

メリット

  • 大手企業で仕事をする権利がもらえる可能性がある。
  • 日頃触れないような、古い技術を触ることができる。
  • 給料は悪くないこともある。

デメリット

  • コミュ障にはやさしくない「調整業務」が発生する恐れ
  • 「まずやりたくない仕事」にぶちこまれる恐れ
  • 給料が良いとも限らない
  • 技術的モチベーションの高い人が少数派の恐れ
  • 技術的な向上が望めない場合もある

ぶっちゃけると、研修充実は怪しい

 → 十分な研修ができない可能性

なぜか

  • 教育的ノウハウがない
  • 下請け的なポジションになりがち
  • 保守的になりがち
  • リードするような人がいなかったり
  • モチベーションが低い空気

更にそれはなぜか?

  • そもそも入社する人の特徴が、休みや正社員に惹かれて来る人
  • プライベートな時間の使い方が勉強とかでなかったり
  • 自分が将来どうなりたいかとか、あまり考えてない
  • 安定を求めている
  • 技術に対するモチベーションが低い

客先にエンジニアをぶち込む人(自社の営業の人)の特徴

  • 法人向けの営業脂肪だった
  • 「ベンチャー」という言葉の響きに惹かれた
  • ITに興味がない
  • とりあえず、売り上げやノルマを達成すればいい
  • 数字や単語の組み合わせで仕事をしている
    → 「phpとは、何かサービスを作れるもの」など
    → 経験は何年で、給料はどのくらいで、ということだけを見て人を選んだりする
    → その人がどのようなことが得意か・やりたいかということは見ていない

戦闘力の上げ方

  • とりあえず勉強会に積極的に出てみよう
  • 周りのエンジニアや客先と仲良くなっておこう
  • 開発をやりたいなら自分でサービス作ろう
  • 副業やインターンに手を出してみよう
  • 自社に過度な希望をもつのはやめよう

実践できたら、次のステップ

  • とりあえず勉強会でLTとか登壇する
  • 客先から自分に会う案件を直接紹介してもらう
  • 自分で作ったサービスを人に使ってもらう
  • 異業種交流会とかで小規模な受託案件を探そう

本当の自社との付き合い方

「自社 = 自分の味方」ではないかも?

  • 敵というわけであはないが、少なくとも味方ではない恐れ
  • 敢えていうなら、自社は取引先
  • 基本的には、サポートは期待できない
  • 自社待機の社員は負債という見方も

会社の基本

  • 安く仕入れて高く売る
  • 長期的な教育よりも短期的な利益

どうしたらいいの?

  • 技術の学習はできるだけ自力で
  • 受けの姿勢よりも攻めの姿勢で
  • 副業はどんどんやろう
    → 実は、会社は副業禁止とは言えない。
    ただ、会社に不利益が怒るようなことはやってはいけない。
  • とにかく情報を集めること、集めまくること
    → 結構、常駐先の人からぽろっと聞けたりもする。

担当営業とは仲良くなろう

敢えて言うなら、担当のために働いてあげよう
→ 自分に仕事を持って来てくれる人のために働こう
会社は守ってくれないが、担当は守ってくれるかもしれない。

担当のことが信用できなくなったら終わり

担当もエンジニアが信用できなくなったら終わり

自分の会社のことを理解しよう

絶望する前に、会社に一石投じよう

居続けることもできる。辞めることもできる。

僕らは自由であることを常に頭に置いておこう。

【サポーターズCoLab勉強会】Google公式サポート!Kotlin入門に行ってきました

【サポーターズCoLab勉強会】Google公式サポート!Kotlin入門

https://supporterzcolab.com/event/360/

に行ってきたので、そのレポート

資料

以下、講演を聞きながらのレポート

 

Kotlin入門までの助走読本
https://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkWm9PODg/view

というのを、登壇者の方が去年書いた

 

2012年に最初のKotlinがリリースされた

 

KotlinはJavaScriptへのトランスパイルもできる。Babelとか使って。

 

extension functionsがKotlinがJavaと比較して実装しやすいメリットの一つだ。

 

簡単なコードを実行したかったら
https://try.kotlinlang.org/
で簡単に実行できる。

 

デコンパイル
→ Kotlinで書き出したものを、Javaのソースに変換もできる。

 

Kotlinで書いて、iOS用のコードに変換することもできる。

 

Kotlinのオススメ本

 

型を書かずに変数宣言したりしたら、ビルド時間が遅くなる?

e.g

var str: String = “moji”

ではなく、

var str = “moji”

と書いた場合に、ビルド時間が遅くなる?

 → 特に感じることはない。

 

Null安全なので、スマートキャストができる

 → 逆に、Javaではできなかったらしい。。。

 

エルビス演算子は、右辺にreturnを書き、即 return するような場面が多い。

【サポーターズCoLab勉強会】副業/フリーランスことはじめに行ってきました

【サポーターズCoLab勉強会】副業/フリーランスことはじめ

https://supporterzcolab.com/event/361/

に行って来たので、そのときのレポート

今回話す内容

  • 仲介会社を使わず、コミュニティで仕事を見つけて行く方法
  • 業務委託でやっていくにあたっての基礎知識と落とし穴・塞ぎ方
  • 辛いところなどの雑談

フリーランスと副業の違い

フリーランス

業務委託契約

特定の業務処理についての契約

業務委託

労務を約束し、報酬支払いを受ける契約

フリーランスのはじまり~終わり

はじまり

  1. クライアントから業務についての説明
  2. 秘密保持契約を結ぶ
    こういう情報は外に出したらいけないよという内容の約束
  3. githubとかでソースみたり構成を聞いたりして見積もり
  4. 見積もり額をクライアントに提示、金額と期間の交渉
  5. 金額と期間、進め方の承認
  6. 業務委託契約書を結んでGO

おわり

  1. 業務、成果物をクライアントにもらう
  2. 修正依頼が契約範囲内か確認、やるやらの相談
  3. クライアントから1についてokもらったら請求書発行
  4. 入金確認後、終わり

契約の種類

主に2つ種類がある

準委任契約

コミットに対して支払いが発生する

    → e.g. 作る人はいるけど、それを手伝う

デメリット

しれっと契約範囲外の依頼が飛んできてしまう。レビューなど。

メリット

コミットベースなので、事故っても働いた分だけ請求ができる。

請負契約

成果物に対して、支払いが発生する。

 → e.g. 作る人がいないから丸っとお願い的な

デメリット

これは納品に値しないと、無限に修正依頼がきてしまうリスク

  → 自分の資金が尽きてしまう。

メリット

期間が長いものだと労働単価が高い。

期間よりも短く終わらせたら、その分単価が上がる。

契約書のテンプレ(オフレコ)

オフレコでサンプルを見せてもらいました。

死にかけた話

請負の死にかけた案件

仕様がザルで、クライアントが銀行からなんとか借りてきたお金でなんとかできない?とか言われて始まった

「いい感じにやっといて」とか言われる

納期遅延した結果、「減額しないけど、キリのいいところでいいよ」で終わった…(なんだったのだろう)

請負の死にかけた案件2つ目

製品マニュアルのデータが散らかっているので、新しく乗せ替えるという案件

DB設計はあとで渡すからと言われたが、永遠に渡されず、

こういうことしてもらえませんか?という当初とは違うことを言われる毎日、更に迫る期日。

からの、「間に合わなかったから減額」ということを言われて喧嘩をしたりした。

準委任の死にかけた話

いま外注してるエンジニアがやばい(良くない)から手伝ってと、以前の友達から言われ仕事を受けた。

友情によるしれっと依頼がよく見られるが、友人関係からの「バイブスでOKと答える男気」のスタンスでいた

こういうことをしていたため、圧倒的赤字になってしまった。

ただ、運用フェーズで大きな責任を任せてもらえたりしたので、いい機会ではあった。

炎上や揉め事を防ぐ契約書パワー

落とし穴はだいたい契約書で防げる

契約範囲外のことは、改めて見積もりするよという話

自分の単価を守って行くために

  • 仕事をした分だけお金をもらうという当然のことを守るために契約書は不可欠。
  • 自分が案件をこなしきれないものは受けないようにする。

単価ってどうやって決めるの?

正社員の人の時給を計算してみよう。

 → 月給を160割った値。
→ そこに20~35%上乗せすると、相場っぽくて美味しい。
→ 準委任(コミット契約)はこれでOK

請負は、納期に関するブレが最初期ほど大きいので

最大60%ほど値段を多めに、納期を120%ほど多めにすると良さそう。

例えば、

人月100万の人の時給:6250円

人月80万の人の時給5000円

人月60万の人の時給:3750円

ちょっと高くない?

正社員では定期的に給料があるが、

フリーランスでは次がある保証は一切ない

いい仕事をして、その分の信頼とお金をゲットしよう。

会社によっては、フリーランスに出したほうが安くつくところもある。

どうやって案件を見つけるのか?

例えば、

  • エンジニアの友達が起業し、(3年くらいたったらエンジニアがやめていって)一時的に手が足りないという場合
  • 「同じ会社の文脈で」知り合いづてに連絡がくる
  • 副業やりたいなって、周りにアピールする
  • 昔趣味で一緒にコードを書いてた人と一緒に

やってはいけないこと

酒の席で知り合った人とその場で条件を出し合うこと

 → 再現性のないことを酒の席で言うことはできない。

NOといいつつ請求書を発行する勇気

大事かつ、めちゃくちゃ難しい

契約通りの仕事をしたが、追加でこれもお願いできない?という依頼が来たら、

 → 「無理です、請求書を送ります」と言おう。

相手が困っていることに自分も付き合ったら、自分が困る。

Q & A

Q1. 

自分のキャパを超えないようにということがあったが、

例えば「作ったあとに脆弱性が見つかって、それの対応が自分のキャパを超えてしまう」など

予期せぬことが起きた場合のために、何か気をつけていることがあるか。

A1.

まず、もちろん自分でも色々なパターンでテストをする。

検品の時点で請求書発行できるとか、後から見つかった瑕疵についてはまた別ですとかいう契約を結ぶようにする。

Q2.

契約書のテンプレはどこから入手する?

A2.

ググって用語調べたり、テンプレ見つけたりして、自分に不利のないように編集したりする。

Q3.

危ない案件の見分け方は?

A3.

PMのいない案件は基本的に受けないです。

現場のエンジニアがいて、情報がちゃんと聞けてって状況がよい

そうでないと、炎上する。