「AKIBA.AWS #6 ネットワーク x 基礎編 – VPNとDirectConnect -」に行ってきました

AKIBA.AWS #6 ネットワーク x 基礎編 – VPNDirectConnect –

https://classmethod.connpass.com/event/84401/

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

1. 日本でAWS Direct Connectを利用する話

資料

 

以下、講演を聞きながらのメモ

想定する聴講者

ネットワークはあまり詳しくないけど、AWSを使ってみたいIT技術者

ネットワークセキュリティとその設計

Direct Connectはオンプレとクラウドを繋げるサービス

 

インターネットは怖いのでセキュリティをしなければいけない。

コンピュータセキュリティは大きく分けて2種類ある

エンドポイントセキュリティ

 → ウィルス対策ソフトを入れたり

ゾーンセキュリティ

 → 企業などが、自分の管理下のネットワークを置いて、そこで管理すること。
プライベートなネットワークのこと。

 → 組織内の人のみアクセスできるプライベートネットワーク。専用の箱を作って管理。

 → 誰でもアクセスできるパブリックネットワークとの境界を
しっかり分けて管理しましょうということ。

 → 会社の場合だと、ルータがその境界になっていたりする。

家庭のネットワークと企業のネットワークの違い

会社のネットワークは、システムの用途などでプライベートネットワークが別れている。

オフィスのLANとデータセンターで別ネットワーク。

それぞれのプライベートネットワークをどう繋ごうかと考えたりする。

拠点間プライベートネットワーク

方法としては大きく2種類ある

インターネットVPN

安価でベストエフォート

パブリックなインターネットを経由して行うが、組織内の通信を暗号化することにより実現。

インターネットを経由して行なっているので、使い勝手も特に差異はない。

IP-VPN

高価・高セキュリティで帯域保証つき

インターネットベンダーの設備を経由して、閉じた通信網のなかで行う通信。

 → 昔は、ビルとビルの間に線をつないで、、、とかやってる時代もあった。

 → いまは、ネットワークベンダーの設備を使ってやったりしている。

 

Ethernetであれば、ネットワーク通信自体の要件に違いはない。

セキュリティレベルや品質で選択する。

クラウドのネットワーク設計

いわゆる、VPCの話。AWSVPCはどういうつくりなのか?

VPCとは

AWSで使えるネットワーク機能

ざっくりいうと、AWSで使えるネットワーク機能が詰まったもの。

 

VPCの便利なところというのが、

パブリッククライドとしては、東京リージョンということで共通で使うのだが、

ユーザごとにネットワークを切って使うことができる。

 

それぞれのVPCは独立していて、閉じた仮装プライベートネットワーク。

やろうと思えば、VPC同士の接続(ピア接続)もできる。

 

本番と開発のネットワークを分けたいというような形で使われることが多い。

本番のネットワークのセキュリティレベルはあげたいが、

開発用はポコポコサーバーを建てたい、など。

 

VPCとプライベートネットワーク(社内の環境)との相互接続を実現するために

AWSが提供しているDirect Connectというのがある。

 

VPCとプライベートネットワークを繋げる手段は3

  • VPCのインターネットVPN機能
  • EC2でインターネットVPNソフトウェアを実行
  • AWS Direct Connect (今回のメイン

Direct Connectの特徴

  • 高品質
  • 高セキュリティ

サービスとしてのSLAは未定義なため、

現状は、月のアクセスがどのくらいまで保証、というのが明示されていない。

AWSによるサービスのメンテ頻度など実績で比較する。

Direct Connectはメンテ頻度が少ないので、安定しているなど。

対して、インターネットVPNというのが、構築も簡単で手軽である。

AWS Direct Connect

日本で使えるところ。

  1. エクイニックス ty2(東京 東品川)
  2. アット東京 cc1(東京 新豊洲)
  3. エクイニックス os1(大阪 四つ橋)

AWSのリージョン(東京・大阪)とは別

コラム

Direct Connectがある場所に、日本のAZがあるの?という質問がよくある。

真実はわからないが、違うというアナウンスがされている。

Direct Connectの使い方

Direct Connectが提供してくれるのは全てではなく、

VPCから、先ほどの3箇所(エクイニックスty2、アット東京cc1、エクイニックスos1

までの通信が用意される。

 

その3箇所のところにLANの差込口があるので、そこまでは繋ぐよ。

そこから自社のネットワークまでは、自分で用意してね。っていうようになっている。

自社のネットワークまでの繋ぎ方は2種類ある

占有プラン

3つのいずれかのデータセンターと通信を自前で行なって

IP-VPN接続などをする。

自社内のプライベートネットワークの中に

3つのうちのデータセンターへの口を用意する。

メリット

ユーザが自分でいろいろ設定するので、制約は少ないというメリットがある。

 → たとえば、複数のネットワークベンダーからデータセンターに繋ぐということもできるし、

   いくつものVPCを繋げるということもできる。

デメリット

価格が高いこと

共用プラン

ネットワーク事業者が、3つのうちのデータセンターとクラウドとの接続をやっているので、

自社内からそのクラウドに対して、IP-VPN接続を行う。

メリット

占有プランと比べて、データセンターとのやりとりコストや予算などが抑えられること。

デメリット

制約が多いことと、接続できるVPC数が1つだけであること。

まとめると

  • 共用プラン:比較的手軽
  • 占有プラン:本格利用

とっかかりはどうするか?

Direct Connnectを使いたいとなったら、既存のネットワーク事業者の営業さんに相談をする。

 → 中には、Direct Connectの経験があるネットワークベンダーもある。

 → AというネットワークはIP-VPN接続でやって、
   Bというネットワークはネットワークベンダーにお願いして、というようなやりかたもある。

技術的な不明点があれば、質問したり、AWS専用線アクセス体験ラボの活用がおすすめ

おまけ

  • Direct Connect応用機能
    → 占有プランでないと使えなかったりする。
  • パブリック接続
  • Direct Connect Gateway
  • Lag

まとめ

  • Direct connectはプライベトネットワークとVPCを高品質セキュアにつなぐサービス
  • 占有プランと共有プランがある
  • 質問があればネットワークベンダーに質問してみよう。

Q & A

Q1.

メンテナンスの頻度はよくある?

A1.

Direct Connectの推奨としては、冗長構成となっているので

片方がメンテナンスになってしまっても、

もう片方が残っていればいいというような状況にしておくのがよい。



2. AWS 専用線アクセス体験ラボトレーニング参加レポート

登壇者の方(濱田さん)から。

今回の講演で、面白かったポイントを伝えたりしようと思う。

また、これを聞いた人が参加したいなと思ってもらえたらよいかなと思う。

資料

 

以下、講演を聞きながらのメモ

イントロ

濱田さんが日頃の業務をしているときに

AWSとオンプレとの接続はマスト要件」という案件がある。

そういう場合は、

Configファイルを渡して、つながったら、よしやった!と思う。

ただ、当時のイメージとしては、

お客さん側の得体のしれない機材や得体の知らないネットワークが

どのように稼働しているのかイメージがつかなかったため、

体験ラボハンズオンに参加した。

 

結論からいうと、バックエンドやVPNとかよくわからないという方にとっては

とても学びがあって楽しい。

体験ラボとは?

学べる。

ルータを使った接続の体験とかができる。

会社でネットワークの運用とかをやっている人におすすめ。

 

トレーニングは2種類あって、

ハンズオントレーニングの方をやってきた。

(もう片方は座学なのかもしれない、、、たぶん。)

 

料金が無料!!!!!!!!

 

ハンズオン会場は、AWSのビルの素敵なところで行なう。

注意:ボルダリングするところがあるが、そこの写真とると怒られる。

 

行くときは、PCAWSアカウントを用意しておく。

 

講師は、AWSの菊池さんという人。ガチガチのスペシャリストの人。

とても丁寧に教えてもらえる。

 

ハンズオン形式でテキストを進めて行く形。

 

講演の中で説明されるが、

あるWEBサイトにAWSアカウトを登録すると

自分のAWSアカウントのDirect Connect のところに

Virtual Interfaceが自動で作られる。すごい。

 

ハンズオンの中では、VGWの作成などが

こうやればできますよってテキストに書いてあって、それをやる。

 

ある程度最初に、どんなことをやるのかイメージして

ハンズオンで進めていくことで理解が深まるのでよい。

よかったこと

  • Direct Connectの設定の流れを一気通貫で学ぶことができる。
  • ルーターコマンドを体験できる。
  • 講師にマニアックな質問ができる。
    → 参加人数がそれほど多くないので、
    ネットワークスペシャリストにVPNや専用線の質問ができる!
  • テストラボトレーニングの資料がもらえる。

まとめ

これまで霧のようなイメージだったお客さん側の環境が理解できるようになった!

また、無料だし3時間くらいだし、失うものは何もないので参加すると良い!

AWS 専用線体験」で検索!

Q & A

Q1.

無料ということだったが

ハンズオン内で行うAWS料金も無料?

A1.

そこはさすがに自分持ちです。

ただ、ハンズオン内でかかる費用は50円くらい。

しかも、ハンズオンの資料がもらえるので、それを見ながら1週間くらい遊んだりはできる。

1週間くらいはハンズオン用のデモの環境を残しておいてくれるので)



3. VPN接続とルーティングの基礎

まず始めに、登壇者の菊池さんから

今回はだいぶテクニカルな内容になります。と説明があった。

菊池さんは、AWS認定を8冠しているすごい方。

資料

 

以下、講演を聞きながらのメモ

1. AWSVPN接続

いわゆる、インターネットVPN

 → インターネット上の通信でパケットをカプセル化することで仮想敵なトンネルを形成

 

実現方法によって2つの分類がある。

  • ハードウェアVPN
  • ソフトウェアVPN

ハードウェアVPN

接続に必要な部分が、AWSのサービスとして提供されている。

ソフトウェアVPN

EC2の中にソフトウェアをインストールして、そこを通してVPN接続すること。

 

この2つを比べて一番違う部分が、

ソフトウェアVPNの場合は、

VPN接続の部分を、ユーザが自分たちで保守・運用しないといけない
例えばEC2インスタンス建てたりソフトウェアをインストールしたりとかということ

今回のテーマはハードウェアVPN

ハードウェアVPN = マネージドVPN

拠点間を繋ぐIPSecVPN

2. ハードウェアVPN

出てくるコンポーネントは3

  • customer gateway
    → オンプレ側に設置するルータ
    public ipを必要とする。
  • virtual private gateway
    VPCにアタッチするゲートウェイ
  • VPNトンネル
    → CGWとVPGを繋ぐ

 

AWS上での設定はとても楽。3ステップ。

 

設定ファイルが最後にDLできる

 

設定ファイルには、

  • IPSecVPNの設定情報
    → IKE/Ipsec/TUNNEL
  • BGPルーティングの設定(動的ルーティングの場合)

が書かれており、

IKEの事前共有鍵、AWS側の接続先IPなどが書かれている。

 

AWS側では、2箇所でルートが設定されている。

  • VGW
  • VPCのルートテーブル

3. BGPによる経路交換

AWSを使うと、IPSecまでの設計はほとんどいらない。DLするConfigに書かれている。

ネットワークの経験がない人がBGPをやろうとすると、一気にハードルが高くなる。

 

BGPとは?

Border Gateway Protocol

のこと。

動的ルーティングプロトコルの1

 

AS(Autonomous System:自律システム)間で経路情報を交換する。

ASナンバーというのは、大きなネットワークキャリアとかが、他と通信するための番号。

 

TCPで接続したルータ間で経路をアドバタイズ(広報)する

 → パスアトリビュート属性を付加することで経路を制御

  → ISPとかが複数の経路を提示してくれるが、
この属性によって最短の経路が何かを示してくれる。

 

VGWVPNトンネルの間にルータが2つある。

  • CGWで設定したCIDRCGWから受け取るルータ
  • VPNCIDRCGWに送信するルータ

 

BGPでは、パスアトリビュートのパラメータが10以上ある。

AWSでよく使われているのは

  • Local_Prefence
  • AS_PATH
  • Med

ここら辺の話はとてもディープな話になるので、

また次回の勉強会でやろうかな菊池さんがおっしゃってました。

4. 設定時の注意

CGWには実績のある機器を設定しよう

 → 不具合の回避

 → 実績のない機器を検討する場合は事前検証を。

 

AWSが公式に検証をサポートしている機器もある。

そういうものを使えば、まぁ、間違いないでしょう。

その機器の中に、 Cisco とか Juniper とかある。

コラム

ネットワーク屋さんからすると、CGWVGWは同じ機種を使うのがセオリーなので

AWSで使われている、謎の機器を使うときは、サポートされているものを使いましょう。

サンプルコンフィグの注意点

CGWNAT環境にある場合。

クライアントのFireWallの奥にCGWがある場合。

その時は、インターネットからFireWallを超えてCGWにアクセスできるように設定しよう。

サンプルコンフィグを使うと、NATGWIPが記載されているので、そこの書き換えが必要。

繋がらないときのトラブルシューティング

  • Ipsecがダウンしていないか
  • BGPがダウンしていないか
  • ルートテーブルが反映されているか

まとめ

  • ハードウェアVPNはマネージドなIpsecVPN
  • BGPまたはstaticルーティング経路を設定
  • AWSが、設定は簡単

Q & A

Q1

今回話したような内容は、ネットワークベンダーさんがやってくれる?

A1

基本的にやってくれる。

Q2.

経路交換しているときに、

VPC側の経路情報が流れてしまうという話があったがルーティングの設定をすればよいのか?

A2.

そうですね。オンプレの設定だけルーティングするような設定をしないといけない。

Q3.

Direct ConnnectSLAの設定がないという話で、冗長構成が推奨ということだったが、

どういう内容があるか?

A3.

データセンサーから線を2本引くなど。どこまでお金かけるかとか、考え方とかによることになる。

Q4.

AWS側でVPN接続する際にルータが2

CGWCIDRを受け取るものと、VPCCIDRを送るもの)出てくるが、

それが別れているのはなぜか?

A4.

AWS側が冗長化のためにやっている。

メンテナンスの際は、片方がとまるが、片方は生き残ったままというような形になる。

勉強会に行ったら友達作りとアウトプットをしよう

私が勉強会に足を運ぶようになって

よかったな、これからも続けたいなと思うことです。

友達作りをしよう

勉強会に来ていた他の方々と仲良くなりましょう。

 

もしそこで、何かしらのコミュニティに参加できるようであれば

積極的に参加するようにしましょう。

ある程度コミュニケーションがとりやすく、学べることが多い

同じ勉強会に来ている時点で、すでに同じことに興味を持っていることが分かっています。

更に、同じことに興味を持っているような人は、自分と同じような状況やスキルセットになっていることが多いです。

 

「最近どんなことやっているんですか?」という会話から、

共通の話題でコミュニケーションをとることが比較的容易だと思います。

 

親密感が出て来たら、自分が悩んでいることや、人の意見を聞きたいような話題を振って見ましょう。

自分と同じような悩みを持っていたり、解決する術をその人は持っているかもしれません。

良いライバル意識が生まれる

似た状況、似たスキルセットの人が多いので、

自分に足りないもの、身に付けないといけないと思っているものを持っている人が多いです。

 

そういった人と自分を比較することで、

「自分ももっと頑張ろう」と思えることができます。

 

会社の同期等でもそれができるかもしれませんが、

私の場合は、会社の同期はやっていることが全然違ってライバル関係になるのが難しかったり

同期という意識から、敵対視はするけどお互いを高め合う関係が難しかったりしたので

こういうところで出会える人は本当にありがたいと思います。

気軽に質問ができる

会社だとどうしても立場や印象を気にしてしまって

「こんなことも分からないの?」と思われたら嫌だということがありますが(本当はそういうことを気にしないのが良いですが)

そういうことを気にしなくてもよいので、気軽に質問ができます。

 

また、相手から質問された場合でも

「会社だと間違ったことは言えないし、ちゃんとよく知らないから答えられない」

という気持ちになりがちかもしれませんが、勉強会友達だと

「間違っているかもしれないけど、自分はこういうところまで知っているよ」

ということが言いやすいと思います。

新しい友達ができる

これは当たり前と言えば当たり前ですが、新しい友達ができます。

しかし、ただ友達という訳ではなく

自分と似た状況に苦しんだ経験があったり、共通の話題が生まれやすい存在であることが多いです。

うまくいけば、会社の人には話せないようなことを話せる、大事な存在ができるかもしれません。

一期一会を大事にしていきましょう。

※ただ、勉強会のつながりを利用して変なことを考えている人もいるらしいので、友達選びは気をつけましょう

アウトプットをしよう

得た知識を更に固めることができる

勉強会に参加すること自体、とても良いことだと思います。

ただ、参加してなんとなく頭の片隅に入った、くらいだと勿体無いと思います。

得た知識をアウトプットしようとすることで

記憶に強く残ったり、勉強ではなんとなくしか分からなかった部分も分かるようになったりします。

実はとてもアウトプットしやすい

勉強会で聞いている内容は

ありがたいことに、すでに「誰かが学びやすいように」作られたものです。

 

学んだ内容をそのまままとめるだけでも

それは誰かが学びやすいような形に近いです。

スライドの順番やレイアウト・補足説明など、アウトプットに向けた労力も大分削減されているでしょう。

 

「こんな内容アウトプットしても誰も興味を持たないかもしれない…」なんて思わず、

とりあえず学んだことをまとめただけのものをアウトプットするだけでも十分良いことだと思います。

 

自分で勉強会を開くのも良いですし、

ブログに書くだけだったら特にマイナスはなくてプラスしかないと思います。

自分が興味を持っていることを周囲に知らせられる

勉強会で「こんなことが面白いと思った」「勉強になった」

ということを周りに知らせることは、とても良いことです。

 

例えば会社などでアウトプットをすると、

「この人はこんなことに興味を持っていて勉強会に行って来たんだ」

と思ってもらえるので、運がよければ良い仕事を任せてもらえるかもしれません。

もしくは、社内で同じ興味を持っている人と話ができるかもしれません。

 

また、プライベートな時間を使って勉強しているということを伝えられるので

それだけでも好印象を持ってもらえるかもしれません。

まとめ

勉強会に参加してそこで終わるだけではとても勿体無いので

積極的に友達作りやアウトプットをしていきましょう。

何か良いきっかけができるかもしれません。

気分がのらない・やりたいことが見つからない時の対処法

日頃生活していて、「なんか気分がのらない」「したいことがない」

という状態がありませんか?

 

そういう状態のときは、どうすればいいのか考えても

なかなかアイデアが浮かばないものです。

 

気分がのらないとき

私が行なっている対処法としては、

テンションがあがった状態のときに、今何をしているかをメモしておくことです。

 

そこでメモした内容、例えば「ここのカフェに行くとテンションがあがった」ということを

気分がのらないときにやってみると、気分がのるようになったりします。

 

なんか分からないけど気分がのらないが、どうしたらいいか分からない

という状態のときは、一種の自分が分からなくなっている状態だと思っています。

そんなときにはメモを見て

自分はどんなときに気分がのる人間なんだと、分かることができます。

例えば私の場合は

  • アニメソングを聞く
  • 落ち着いたピアノの音楽を聞く
  • カフェに行く
  • 好きな服装をする
  • プログラミングをする
  • 溜まっていた調べごとを片付ける(前もって、時間ができたときに調べようと思ったことをメモしておく)
  • 家事をしたり、部屋を綺麗にしたりする
  • 運動をして帰ってお風呂に入ってから何かをする

ということをメモしていたりします。

また、実行するときは

疲れてしまわないように適度に休憩を入れながらやるのが良いと思います。

やりたいことがないとき

これも、気分がのらないときと同じでメモをします。

「時間ができたらこれをしよう」「休みの日をつかって○○に行こう」

ということを、やりたいことが思いついたときにメモをしておきます。

 

今特にやりたいと思っていなくても、過去に自分がやりたいと思ったことなので、

腰をあげて実際にやってみると、楽しくてのめり込めることもあります。

ポイントは「やらなければいけないこと」ではなく「やりたいと思ったこと」です。

 

例えば私の場合は

  • ○○の映画を見る、録り溜めたドラマを見る
  • 自転車で長距離を走る
  • 書こうと思っていたブログを書く
  • マッサージを受けに行く
  • 久しぶりに友達に会いに行く
  • アプリ開発をやる

ということをメモしたりしています。

 

どうしても「今回は面倒だから、また次回でいいか」と思ってしまう場合は

期限をつけてメモをしておくことも効果的だと思います。

大切なのは、「どうしても今しなきゃいけない訳じゃないけど、とりあえずやってみるか」という

最初の腰をあげる部分だと思うので

そこさえ頑張って乗り越えてみたら、以外と充実した1日を送れると思います。

電車の遅延情報をslackに投稿するbotをつくりました

githubに公開しています。

使い方は REAME.md に書いてあり、特に難しいことをしなくてもいいのですぐに使えると思います。

github

https://github.com/acchanAlexander/notice-train-delay-to-slack

 

チャットワーク用はこちら

ブログ:電車の遅延情報をチャットワークに投稿するボットをつくりました。

github:https://github.com/acchanAlexander/notice-train-delay-to-chatwork

 

【サポーターズ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のいない案件は基本的に受けないです。

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

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

【サポーターズCoLab勉強会】【iOS】今更聞けないMVPとMVVMの違いに行ってきました

【サポーターズCoLab勉強会】【iOS】今更聞けないMVPとMVVMの違い

https://supporterzcolab.com/event/339/

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

資料

以下、講演を聴きながらのメモ

MVPMVVMの違いについて

iOSアプリ開発におけるMVPについて

View

presenterからデータをとって表示したり

Presenter

データを持ってるものからデータを取得する

PresenterはViewの参照を持つというのが、

他のアーキテクチャ(MVVM)とは違うところ

 

Viewでタップされたら、

Presenterが必要なロジックを用いてデータをModelとかから取得する。

PresenterからViewに値を渡す役割はViewControllerが担う。

iOSアプリ開発におけるMVVMについて

ViewModelviewの参照をするわけではなくて、DataBindingによってViewが値を参照する。

Viewは、DataBindingで画面に反映させる。

 

ボタンがタップされたときなどに

タップされたことをViewModelに伝えて、

ロジック処理をしたあとに、プロパティ(DataBindingしている値)を更新する。

 

MVVMでのユニットテストについて

referenceを持っているのは、

VMからModel側のみ

 

NotificationCenterは自前でインスタンス化すれば

そのインスタンスを知っている範囲内のみで通知することができる

NotificationCenter.defaultというものがよく知られいるが

それはアプリケーション全体に通知してしまう。

Q & A

Q1.

アーキテクチャ選定の際はどのようにしている

A1.

AbemaTVでは、MVPMVVMFLUXも使っている

利点として、変更とかあっても、大人数で行なっているときに、コンフリクトしにくいとかがある。

どのアプリケーションについてもこのアーキテクチャが良いというのはなくて、

こういうアプリケーション設計にしたいから、ということを考えて

MVPMVVMなのかとかを考えて行く。

Q2.

自前でやるときとライブラリを使うときの基準は?

A2.

開発体制や作りたいアプリによるところがあるのだが、

副業とかで何かアプリを作成しているときに

ライブラリのインストールとかも承認してもらったりとかあるんだったら

自前で作ったりとかもする。

本当はRxとか使ったりするのがいいかなとも思っている。

【CDN Study (Akamai/Fastly)】に行ってきました

CDN Study (Akamai/Fastly)

https://http2study.connpass.com/event/81469/

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

イントロ

資料

まず、jxckさんから

CDNの変遷(変化)

edgeの数こそ正義

そのあと

edgeの数よりは同じurl使ってることが良いよねってなった

jqueryのダウンロードを他のサイトでやってたらキャッシュされるよねとか

さらに

cloud cdnが出てきて敷居が下がった。

ただのファイルだけじゃなくて、

imageを最適化してくれるとか

ddosに強いとか

さらにedgeの中でいろんなプログラムが動いてたらいいよねとか

cdnが前提になりつつある今

パフォーマンスやセキュリティの面から

edgeが正義という感じではなくなってきた。

縁の下の力持ちという感じではなく、

もっと前へ前へと出てきている感じがする。


Akamaiの方(岡本さん)の話

悪魔で個人(登壇してくださった方)の見解です

資料

CDNの過去と現在

各CDNベンダの歴史を見てみる。

一応、CDNですと言って出てきたのは1995年にAkamaiが初

そのころ、今のインターネットはコンテンツ配信が中央集権的なものになってしまって

限界があるだろうと言われていた。

 

http://as2914.net/

というサイトで、インターネットの地図が見れる。

すごい

このサイトからも分かるように、インターネットはとても複雑な網目状になっているのに対して

配信箇所が一箇所だと、渋滞が起きてしまうだろう。

 

1998年にstar warsの映画の予告編が公開された

これが、「インターネット最大のダウンロードイベントだった」と、スティーブジョブズが言っていたらしい

このように、コンテンツが一気に様々なところからDLされるということがあり

このままではインターネットは壊れてしまうと予想された。

世界で動画を配信するような設計に、インターネットはなっていなかった。

このようなことからCDNの必要性が出てきた。

CDNの基本的な考え方

ユーザーの近くに必要なファイルのコピーがあればよいではないか。

akmaiの仕組み(ほんの一部)

Akamaipop(edge)が他のCDNベンダーと比べてダントツで多い(桁が1桁違う)

世界中に数多くあるのがAkamaiの特徴

ただ、数が多いと大変という話

ユーザーをどうやって最適なedgeに誘導するのか

 → DNSの名前解決の時点でアクセス元によって応答を動的に変える

  → 実は、これはAkamaiの特許(2019年で特許が切れる。)

Google Public DNSとAkamaiが相性が悪いという話

 → 全てが8.8.8.8からきてしまうと、区別がつかない

  → 今は別に相性が悪くなくなっている

最適なエッジサーバー群とは?

CPUバウンドやネットワークバウンドなどいろいろな要因があるなかで最適なedgeを探すのは難しい

 → 安定結婚問題、gale-shapleyアルゴリズムを当てはめている

Akamaiedgeサーバーの構成

  • 高機能な独自開発httpサーバー
  • xmlベースのdlsでロジックを組む
  • 膨大な機能があるため、したいことは現場のエンジニアレベルで大抵できる
    → なので、この問題はUSに問い合わせないとということがあまりない。

せっかく近くにいるのだから、もっと高度な処理をしたいよね

例えば、セキュリティ対策など

岡本さんがCDNでしたかったこと、していること

  • ddos対策
  • waf
  • スクレイピング対策
  • 画像動画htmlなどを自動的最適化
  • webサイト全体
  • apiをキャッシュから出して応答を速く
  • 静的ファイル配信はまかせたい
  • sslセッション数が多すぎるので対処
  • インターネットの経路の不安定さを解決

CDNのもともとの名前の意味としても

現状は大分変わってきている

Akamaiの動き

bot managerimage managerをリリース

最近だと、2018年にedgeで動作するjavascriptを開発中。

Akamaiの方(塲田(ばだ)さん)の話

資料

Akamai も標準化へ参加している

CDNがどんどん進化していくのも必要だし、ブラウザもどんどん進化する必要がある。

CDNベンダーもブラウザと共通言語で話せる必要がある。

新しいプロトコルを使いたいとなった場合もブラウザの対応が必要になる。

Akamaiによるhttp2

ユーザからhttp2でリクエストをしてもらい、Akamaiで受け、http1.1webサーバーに流すなど

real user monitorRUM

 → このページを見たユーザはこのページも見そうだから、
このcssjsを送るようにしよう
というアルゴリズムを作ったりしている。

QUIC

https://blogs.akamai.com/jp/2017/05/udpquic—akamai-media-acceleration.html

TLS1.3

draft21もしくは23に対応したopensslを使えば、AkamaiとTLS1.3で通信ができる

CDNの未来

edgeはどこか?
→ 今後、もっとedgeがユーザの近くになるのではないか
携帯電話会社なのか、電柱なのか、スマホの中なのかとかとか

edge computing がくるぜ!っていう論文もある。

The Emergence of Edge Computing
http://elijah.cs.cmu.edu/DOCS/satya-edge2016.pdf

  • コンテンツ予測配信
  • 携帯電話専用回線網
  • デバイス間コンテンツ共有
  • などなど、、、

webガバナンス強化のためのCDN

様々なドメインでサービス配信してる時に、メインサービスは脆弱性対応しているが、全てのサービスに手が回ってないとか

自分の会社のサービスはどこが守れていてどこが守れていないのか

どこがcipher suite しているのかしていないのか

そういうことを管理できるようにしよう。

取り入れられそうなこと

開発後にチューニングとしてCDNを取り入れるのではなく

CDNを最初から考え、どの程度のTTLなら許容できるのか、キャッシュはどのようにしようかなど設計しましょう。

cacheabilityの観点からのアプリケーションのモデリングをしよう

  • キャッシュの時間設定などが、ボトムアップだったり、良い設計ができていなかったりする
  • キャッシュの生存時間を変更できるようなアプリケーション

Let’s Encrypt

Akamaiを使えば、Let’s Encryptとの連携も比較的簡単にできるよ!

 → Let’s Encryptをそのまま使うとなると、 cert bot などちょっと癖があるが、
そういうのを簡単にできたりするよ。

Q & A

Q1.

cacheabilityに関して、

それを取り入れるのが難しいと思うが、

webアプリケーションフレームワークの中にcacheの機構を持たせるようなことができたらハードルが下がりそうではないか?

A1.

たしかに、その視点はなかったが、それは良さそう。

Q2.(岡田さんから)

Multi CDN の話とかがあるが

A2.

あんまり凝ったことをしたいわけではないのなら、singleでやったほうがいいと思う。

Q3.

server pushってクライアント側の情報がわからないと難しいと思います。

cacheダイジェストなどもあるが、Akamaiさんの中でどのくらいserver push が使われていて、どのくらい早いのかとか教えてほしい。

A3.

アルゴリズムの際に、機械学習などを利用しているという風に、岡田さんは聞いている。


Fastlyの方(奥さん)の話

悪魔で個人(登壇してくださった方)の見解です

資料

Fastlypop設計

キャッシュヒット率を高めたい。

  • コンビニモデル
    → ユーザの近くにたくさんのpop
     → メリット:底レイテンシ
  • スーパーマーケットモデル
    → ixの近くに巨大なpop
     → メリット:cacheのヒット率をあげることができる。

Fastlyは主にスーパーマーケットモデルを採用している。

popのキャパ

1Tbpsクラスのネットワーク

32台のクラスタ

Fastlyはルータレス、ルータを使っていませんよ。

32台のサーバーがルータも兼ねている

ロードバランサ

大量のリクエストをさばくにはコストが高い。

ECMPという技術

 → これも問題がある

  → 外すタイミング問題

   → ステートレスロードバランサというやり方をしている

    → クラスタの応用、ノードにあるサーバが知っている通信は別のサーバに流さないし、知っていない通信は別のサーバに流す。

他社と比べて

http2も早い

まとめ

FastlyはAkamaiとは違い、スーパーマーケットモデル
 → そのために、スケールアップ・スケールアウトの仕組みをソフトウェアを使って実装している

VCLについて

VCLができること

  • リクエストのルーティン具
  • リクエストの書き換え
  • レスポンスヘッダの書き換え
  • リクエストの再送(回数制限あり)
  • etc…

パージ

  • URLを指定してパージできる
  • キーを指定してのパージ
    → 特定のキーがついたキャッシュをまとめてパージできる
    → 例えば、jscssのファイルを一気にパージしたいとき、特定のキーを持たせておいて、それをパージさせる
    → メリット:url単位での参照、パージができる

ヒット率の高いキャッシュ率を実現するには

  • 大容量のキャッシュ
  • インスタント・パージ
  • shielding

他には

  • waf(web application firewall)
  • ddos対策
    → ddos対策をしながらも、他のお客さんにも迷惑がかからないような仕組み
  • edge-side includes(Akamaiでもやっているし、Akamaiからの移行もしやすそう)

CDNの歴史とこれから

  • プロトコル上の制限がボトルネックに
  • スマホの普及
  • スノーデン事件
    → 大規模な情報を管理する上で、プライバシー保護について厳しくなった

このようなことから、インターネットとプロトコルが進化してきた。

プロトコルの進化の方向性

  • 全ての通信の暗号化
    → ルータとかでの通信の硬直化をしないようにしよう
  • 迅速なセットアップ
    → リンクを端末にpushし、それがブラウザ上にあるか確認したりする
  • ネットワークをまたいでも途切れない通信
  • 劣悪な環境でも粘り強く通信をするように
  • DNS over https
    → DNSからのクエリなのか、CDNからのクエリなのか分からなくなるので、セキュア
  • cache diggest http
    → オリジンの処理中にCDNからアセットを配信
  • server timing
    → 配信タイミングをjsで取得
  • secondary certificates
    → 1本のTLS接続で複数の証明書を使う
  • short term cert
    → ある国では、証明書は政府で管理しましょうとなっているところもある。
    できるだけ秘密鍵が漏れたときの影響を少なくしよう。
  • variants
    → varyのキャッシュ爆発の問題を対策

QUICの目標

  • 1個目のパケットが処理できなかったとしても、2つ目3つ目のパケットを処理できるようにしたい。
  • 進化を続ける通信プロトコル
    → tcp first open という機能は、8年間実装にかかったりした。
    それは、アップデートを邪魔をするルータがいたりしたため。
    → アップデートに妨げられないプロトコルが必要
  • 相互接続試験をやりながら、各社プロトコルを実装している。
    → googleはGquicというものを使っているが、だんだんIquicというものに近づけている。
    そのような動きもある。
  • Fastlyもプロトコル標準化に参加している

まとめ

CDNとしてのミッション

  • より安く、より速くコンテンツを配信
  • 全世界的な分散kvs
  • edge cloud
  • プロトコル進化の促進

Q & A

Q1.

web packagingについてどう思いますか

A1.

ampの問題などがあるが、web packagingのような技術が標準化されるのはいいと思う。

Q2.

ネットワーク回線も問題になりがち。配線や回線について工夫しているところはあるか?

A2.

私はsoftware engineerなので言えることは少ないが、

弊社はコンテンツ配信の一点特化なので、それに合わせた設計をしている。

例えば、ルータレスルーティングとか。

Q3.

Fastlyvarnishが元になっていたりして、edgeのほうにバグが発生することも考えられるが

そのようなものに対してテストをやるための仕組みはあるか?

A3.

お客さんがテストするような仕組みはちょっと分からないです。開発の中でもテストはあると思うが。

ちょっと他の人に聞いてほしいです。すみません。

Q4.

標準化の中でデータを公開する話とかどうなってますか。

A4.

そこがやはり議論になっていて、何を見せて何を見せないかっていうのをちゃんと考えている。

例えば、うっかりルータから見えてはいけない情報が見えたりとか。

なので、何を見せるのか、見せない代わりに何か別のものを見せるとか、そういうのを明文化している。

Q5.

CDNwafとかddosの話も出ている。

ただ、動的なコンテンツを配信しているwebサーバもあり、どこまでを通すのかというのが難しいと思う。

どこが適材適所なのかという意見とかあるか。

A5.

FastlyはCDN会社なのでCDNでやってほしいと思うが、どうしても共用サーバであることの制約とかもある。

どうしても処理の重いこととかは、別なサーバーでやったほうがいいなどトレードオフはあると思う。

【サポーターズCoLab勉強会】プログラミングを初めて1年でフリーランスになる超具体的な戦略に行ってきました

【サポーターズCoLab勉強会】プログラミングを初めて1年でフリーランスになる超具体的な戦略

https://supporterzcolab.com/event/325/

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

そもそもフリーランスとは

特定の企業に属さず活動する人

給料が高い

何回も面接とかいらない

 → 面接1回とか、結構カジュアルに採用される。

税金とか自分でしないといけない。

社会的立場が弱い。

 → 賃貸物件の契約ができなかったり、クレジットカードが作れなかったり。

どうやってフリーランスになったか。

1.2ヶ月独学でアプリ作る

ドットインストール

progate

rails tutrial

unity

2.1年インターン

サーバサイド rails

フロント unity

やばいところで働いていた

 → pmがいつも体調崩してる

 → 16時間働いて、換算してみると時給500円になる。

 → 夜中3時のコミット

3.フリーランス

勉強会で知り合った社長にアプリ作ってよと言われた

月収30万くらい

エージェントに聞いて見た。

プログラミング経験1年でフリーランスになれるか?

 → なれます。

 → このアプリでこういう部分を作ったとかの実績が言えれば心象も良い

 → SES は難しいかも

フリーランスになるための戦略

1年間の実務経験 + 成果物を、どう作るか。

実務経験を積みたいのに、要実務経験とかが求められている

 → 正社員は難しい

 → おすすめはインターン採用

新卒2,3年目はうまくスキル感を引き出せない。

自分で何かアプリを作ってみる。

 → 実績ベースを軸にして、自分のスキル感を伝えられる。

 → 自分で何か作ってみた人って、驚くほどいない。

実際フリーランスってどうなん?

税金はすごい大変です。

 → 希望年収の1.5倍くらいもらわないと、税金で引かれるので、割にあわなくなる。

信用ないです。(フリーランス1年目に限る)

 → 家も借りれない。

  → 母親に保証人になってもらって、やっとできた。

 → 楽天カードも作れない。(審査甘いのに。)

まとめ

1年くらいインターンをして、

何か成果物を作って、それを軸に自分を売り込むことでフリーランスになれる。

Q & A

Q1.

エージェントを使うと、買い叩かれてしまう恐れとかは?

A1.

エージェントによる。

そういうところもあるし、

自分の取り分はどのくらいになりますよって教えてくれて安心できるエージェントもある。

Q2.

割と一社だけに絞ってフリーランスするのか?

複数社いくのか?

A2.

複数社行ってるのは、(登壇者の方の)周りでみると少ない。

Q3.

フリーランスは在宅と常駐のイメージがあって

1年目だと常駐が多いイメージがある。

レバテックはどちらが多い?

A3.

常駐が多いイメージがある。

ただ、信頼を得られたらリモートになったりする企業もある。

最初からリモート可っていうところもあるっちゃある。

Q4.

geek city はどのようにマネタイズしている?

A4.

まずはユーザーを集めて、

その後、協賛とかでマネタイズかなと思っている。

Q5.

契約を結ぶときに、契約書でここはよく見た方がいいとかありますか?

例えば、この項目は慎重に読まないと自分が痛い目をみるとか。

A5.

実は、僕(登壇社の方)はあまりよく読んでない。

その中でも読むところは、

xxx ~ xxx時間 働いたらxx万円の報酬とか書いてあるが、

それが自分が現実的に可能かどうかというのを考えたりしている。

Q6.

フリーランスって成果物にシビアかなというイメージがある。

このくらい働いたら報酬をもらえてそれで終わりとか、

バグがあったら瑕疵担保を負わないといけないとかあるイメージがあるが

現場ではどうなのか?

A6.

そのあたりはエージェントが間に入ってくれる。

エージェントから請け負うときは、成果物がどうこうじゃなくて

xxx 時間でいくらみたいな仕事のもらい方をする。

Q7.

フリーランスになる前にしておけばよかったことって何ですか?

A7.

住宅とクレジットカードはやってたほうがいい。

あと、フリーランスになったらフリーランスになりましたって周囲に言ったほうがいい。

声をかけてくれて、仕事の話をしてくれたりする。