【サポーターズ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.

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

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

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

【システムを構築するときに気をつける10のこと】に行ってきました

【サポーターズ勉強会】システムを構築するときに気をつける10のこと

https://supporterzcolab.com/event/233/

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

資料

基本的に、このスライドに書かれていることをなぞって講演していただいたので

このスライドをみればだいたいイベントの内容が分かります。

ただ、口頭で説明のあった箇所などはメモをとっていたので

下記に記載します。

まえおき前提

web業界において、スピード重視でサービスリリースするような開発

アジャイル開発などを対象に今回の講演をします。

登壇者の方がよく思うことが、

サーバーサイドエンジニアから受ける質問として

「この機能作りたいんですけど気をつけることありますか?」

と聞かれることがあるのだが、気をつけることはいっぱいある。

だが、書籍とかで気をつけるべきことの情報は見つけにくい。

それで、今回ざっくり説明をしていただける。

安定稼働にはコストとリソースがかかる

設計とかで、結構時間がかかる。

オンプレで動いてたものをクラウドで動かすとかだと、

どのくらいの費用がかかるのか、どういう設計にするのが良いのかが検証してみないとわからない。

例えば、クラウド環境で冗長化するとして、

マシンを1台で動かしてたものを2台にするとかだったら、2倍料金がかかる。

1台が死んだら2台目に切り替わるという仕組み作りの検証もしておかないといけない。

運用体制コスト

誰が通知を受けて、、誰がエスカレーションして誰が対応するのか

とかとかのマニュアルが必要。

ディザスタリカバリを考え、日頃から訓練する。

オペミスとかでデータが消失したときの対策

これは結構難しい。

設計はしたけど、日頃訓練しておかないと

いざ障害が起こったときに、うまく動けないことがある。

擬似的に障害発生させて訓練しよう

システムが落ちたという報告を誰が誰にエスカレーションしないといけないのかを決めておく

例えば、上司に報告して、上司はお客さんに報告するとか。

モニタリングのメトリクスは細かく取る

こういうのを細かくとっておくと、

障害が発生したときとか、スケールするときに情報になる。

ただし、メトリクスをとりすぎると逆にマシン負荷になるので注意が必要

代表的なメトリクスはグラフにしたりしておく

また、そのメトリクスの意味を理解しておく

query/sec というメトリクスってなんのクエリなんだっけ?」とか。

システム全体がスケールできる

ネットワークのスループット

例えばデータセンターだったら、外から入って行くるのが1本だったら、それに耐えられるのかとか。

外部連携

例えばBIツールを使っているときも、外との連携でスケールできるんだっけとか。

設計/選定した技術には責任を持つ

使ったけどちょっと違ったかなというときは

ちゃんと自分で負債を返していかないといけない。

技術選定が間違っていたとかいうこともあるが

それをちゃんと返して行こう

そのためにも、採用した技術には一番詳しくなっておこう。

仕様やデータ構造の変更は必ず発生する

仕様とか技術は変わっていくので

変わってもいいように設計を考えておきましょう。

データの保管場所は塾考する

例えば、クラウドからオンプレに持って行きたいとなったときに

データ量が多いと、転送時間に時間がすごくかかるので気をつけないといけない。

データレイクというのが最近注目されている

データレイクとは、1箇所に全てのデータを集めて使えるようにしましょうという考え方。

セキュリティ対策は必要だが、コストと時間がかかる

権限管理はすごい大変

ここはちゃんと設計しておかないと行けない。

権限の設計が必要

 → しかも、変更が入るので、柔軟な設計が必要

誰が管理して、だれが付与して・・・

転職とか退職とか、人の入れ替わりがあって、権限の管理が大変

クラウドを信頼しすぎない

クラウドはだいぶ安定・安心できるが、100%の安定では決してない。

EC2の場合、メンテナンスのために強制的にシャットダウンされることがある。

だが、EC2の中でvmが動いていて、vmの中のメモリでアプリケーションが動いていて、

シャットダウンさせるには、メモリにのっているデータを退避させないといけないとかの状況の場合もある。

だが、シャットダウン日は10日後に迫っていてつらい。。みたいな状況もある。

謎のサービスレベルの低下

AWSに質問した。

回答は、他で使われているインスタンスの負荷で、それに引っ張られてますとかの回答がきた。

結局、言いたかったこと

優先順位を決めよう

セキュリティが重要だったらそれからやろう。

スケールが大事だったらそれからやろう。

全部やれるにこしたことはないが、時間もないので。

Q & A

Q.どんなメトリクスで区切るとかコツはある?

A.僕(登壇者の方)の場合は低レイテンシーが求められているので、

 1msec, 4msec, 10msec, …. とかで返したクエリとかでメトリクスを切っている

 そのときのメモリの使用量とかを分析できるので、目的別でメトリクスを区切るようにしている。

 

Q. おすすめのメトリクスツールは?導入が簡単とか。

A. saasサービス

   New Relicとか。

   Datadogをリソースの管理で使っている。

   Datadogは楽。

   どちらも外部サービスなんで、アラート飛んできたらどこにいても見れるとかのメリットはある

   ただし、セキュリティに厳しい会社だとそれができないかも

   zabbixとかも、サポートが手厚い。

   

Q. 外部のメトリクスサービスを使うのではなく、逆に自分たちで作らないといけないときの条件は?

A. KVSとか、高速にクエリを処理したいときとか。

 AirSpace?というKVSと使っているがDatadogとかだと対応していなので

 分析用のシェルを自分でつくって、それをDatadogに投げるとかのことは自分でしないといけない。

【サポーターズCoLab勉強会】20代エンジニアのキャリア論に行ってきました。

【サポーターズCoLab勉強会】20代エンジニアのキャリア論

https://supporterzcolab.com/event/168/

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

1万人のエンジニアと話した非エンジニアが伝えたい5つのこと】

1. 自らの希少さを知ろう

ITエンジニア/労働者 の割合は0.3%

300人に一人の希少人材

誰にでもできる仕事じゃない。

需要は右肩上がり(非IT領域全てが対象に)

 

(主催者の方の予想)

プログラミングを学習に取り入れようという動きもあるが、

総エンジニア人口はそんなに増えないと思う。

なぜなら、

英語も教育に取りれられているが、英語話せる人は日本でも少ない。

同じように、プログラミングが学習に取り入れられ、

プログラミングができても、hello worldくらいで、

実務に活かせる人はそんなに増えないだろう。

2. 年収の話。

年収が上がると幸福度が上がるが、

ある一定の値を超えると比例しなくなって(それ以上幸福度があがりにくくなって)くる。

その値はどのくらい?

A. 600

参考記事

https://tensyoku-assist.com/annnual-income/854

そしてそのくらい稼げたら、更にその先の自分が打ち込みたいことが見えてくる。

600万くらい稼げるエンジニアになろう。

3. 自分の位置を知ろう

エンジニアをすごい順に並べたとき

上位5%

上位6%~10%

上位11%~20%

それ以外

あなたはどこに位置するだろう?

 

20%までに入れれば、きっと人生は楽しい

(キャリアを選べるようになるので)

 

10%までは、努力でいける

4. 新卒&3年目&30歳はまじで分岐点

転職活動をするときは

  • 転職は1つ上のレベルの会社を目指す
  • その会社の中間より下でいい(エース待遇は微妙。その後の伸びが小さくなる)

また、

エンジニアのレベルをあげるためには、勉強会に参加するだけではいけない。

何かしらそこで学んだことをアウトプットしないといけない。(ブログでも勉強会講師でも)

5. もし僕(主催者の方)がエンジニアだったら

起業 or スタートアップ

エンジニアは起業かスタートアップをしたほうがいい。

ただし、新卒の時期に上位5%に入っているか、3年目の時期に上位10%に入っている人が好ましい。

なぜなら、起業・スタートアップはとてもしんどいから。

Q&A

Q. インプットしか日頃していない人に、「アウトプットもしないといけない」と言ってもなかなか難しいと思う。どうすればできるようになるか?

A. アウトプットしても恥ずかしくないようになる。rubyのまつもとひろゆきさんも言っていたが、空気を読まないようにする。

こんなことアウトプットしても大したことないんじゃないか。批判を食らうんじゃないかということは棚にあげて、気にせずアウトプットをする。

【ネットワーク技術者ではない方々向けIPv6セミナー2】に行ってきました

【ネットワーク技術者ではない方々向けIPv6セミナー2】

https://connpass.com/event/69423/

に行ってきたので、そのときの雑多なメモ

IPv6最新動向 ~世界共通語で最適化が進むインターネット~

資料

メモ

英語に例えると、

何かを(翻訳とか)介して人は対話をする

ipに関して,

3つの波があると思っている。

今日は、世の中のクラウドかによって、v6化が進んでいるという話をする。

v4は、いまだとオークションで売られたりもしている

/18

というのが、2千万円とかでやりとりされてたりもする。

/16

いまでは、1億円前後

海外におけるv6

googleには、20%くらいv6アクセス

日本からは18%くらい。

平均値くらい。

アメリカのモバイル回線の話

アメリカはすごい

アメリカの事業者は進んでいる。

appleのような先進的な会社で、v6を押している

AWSv6対応している。

などなど、そのように対応している会社はたくさんある。(買いてたらキリがない)

MSasurev6対応

MSは車内はv6対応している。

なぜか?ソースのURLがあるので、それを見てもらったらいい。

Dual stack はニーズに合わない。

そんな時代になっているという紹介。

facebookのような大きな会社も、ほぼv6対応している。

すごい。

load balancerが通訳の役割。

世の中的に、v6が世間一般になったら、この翻訳(load balancer)の部分がいらなくなるという仕組みになっていると読める。

IETFでもv6で行くぞという流れになっている。

RFCでも新しいドキュメントになった。

世界の流れという意味でも、このような流れがある。

V6は危ない?

globalからglobalなので危険?

フィルタの昨日があるので、

v6が危ないのであればv4も危ないという同等の考え方ができる。

NATテーブルに足跡が残る。

海外に置けるV4の話

サービスとかコンテンツって何か?

簡単にいうと、v6の中にv4を入れれば、v4はv6のコンテンツになる。という考え方。

経路数が増加しているので

みんなのルータをリプレイスリプレイスしないといけなくなる。

ipv4ipv6の足し算

ipv4ass

の考え方、一部のルータだけが頑張ればいいようにする。

他は安っちいルータでいいようにする。

(ここまでのまとめ)

  • 世の中のマップがこのようになっていると思える。
  • 端末は、v4のものを探すのが大変なような世の中になる。
  • 大手コンテンツ業者がv6をやろうとしていて、NW事業者もv6対応をやろうとしていて、上から下まで全部がv6のような世の中になろうとしている。

国内のv6の話

長い黎明期があったが、2011年からv6対応になってきた。

それでもしばらくかかっているほう。

46スライド

このようなやり方で、v6の普及率がバーンと上がった。

56スライド

9月の時点では40%超えてるんじゃないかなぁという予想

現在のVNE社の数は7

64スライド

V4の共有が始まっている。

この問題は

日本ですぐに直結するわけではない。

家庭&小規模オフィスのブロードバンドとIPv6

資料

メモ

家庭で導入するには何が必要?

契約さえすれば、v6対応はできる。

フレッツ光・光コラボサービスが、いろいろと癖があるらしいので、それの話をする。

光コラボというのはフレッツがやっているわけではない。

プロバイダーがやっている。

14スライド

契約の違いが、我々(みなさん)がv6したいときにあとあと尾をひいてくるところ


v6ってインターネットが早くなる?

もちろん誤解だけど、なぜそういう話がでてきたのかの話をする。

ipv6を使えば早くなるということの説明の1つが

IPoEの話がある。

IPoEだと、もう終端装置を使わない。

結局もう終端装置が混雑しているので、そこを経由しないので早くなる。

26スライド

日本のインターネットは遅いままなのか?

というのに対しての打ち手が

IPv4 over IPv6

【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略に行ってきました

【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略
https://supporterzcolab.com/event/141/
に行ってきたので、その時のレポート

生き残るには

死なないこと(冗談ではなく)
生き残るのは大変
エンジニアとして成功するのは非常に難しい。

私たちは、戦略を立てて生存していかないといけない。

戦略は、人によっては違う。
成功した人と同じことをやっても、成功できるとは限らない。
成功した人と同じことをやってもダメ、同じ戦略を立ててもだめ。

だが、戦略の建て方などを自分に当てはめて、参考にして考えることはできるかもしれない。
成功した人の例を一段抽象化して考える。

成功者の得意なこと

数学が得意とか英語が得意とかでなくて、
成功者に共通して得意であることが、「パターン認識」をする力。
成功するパターンがわかるという力。

バタフライ・エフェクト
成功した人と同じことをしても同じ結果がでるとは限らない。
違う背景・違う環境・違う時代…で同じことをやっても同じようにはならない。
具体的な内容よりも、パターンを学んで自分に当てはめることが大事。

今回のMatzの講演も、パターンをみつけられるようにしよう。

Matzさんの背景

幼少期

親が買ってきたBasicの実行環境をいじって遊んでいた。

学生の時代

Pascalの本を購入
Basicに比べてPascalはいろんなことができるすばらしい言語だ。
当時はコンパイラは別で20万円ほどで買わないといけないものだった。
お金がなかったので、頭の中でコンパイルして実行していた。

そのとき思ったこと
「世の中には自分の知らないプログラミング言語があるんだ」
「そしてそのプログラミング言語は、何かをデザインしたものなんだ」
「自分でプログラミング言語を作ってみてもいいな。。」

当時は、プログラミング言語を作るための知識を身につけるまでには至らなかった。

大学時代

大学でプログラミングができる学科に進学
プログラミング言語研究室に入る。
これでプログラミング言語づくりができる!!
研究で自分がつくったプログラミング言語の発表を行う。

就職時期

東京で働きたくないと思った。
通勤の苦痛を味わいたくなかった。
本社は東京だが浜松支社がある会社に就職。

バブル期だったので同期は200人
コンピュータサイエンスを学んだことがある人はMatzさん含めてたった6人
200人中6人しかすぐに動けるひとがいなかった。
鶏口牛後である。
そこで、いち早くソフトウェア開発の仕事に就くことができた。

当時は、ソフトウェア開発といえば、
すでに決められたものと形にするだけのような一面があった。
だが、Matzさんのところは、自分たちに裁量権があって、
「どうあるべきか」を決められることができた。

就職先でのある日

その日は大掃除だったのでスーツじゃない服装だった。

いつもは、スーツをきて仕事をしている。
スーツであることは特に規則ではないけど
みんながそうしているからそうしているだけだった。

研究所だし、お客に会うわけでもないのに
なぜスーツを着る必要があるんだろうと疑問に思った。

その次の日からカジュアルな服装で出勤するようになった。

そこで得た教訓は
「”みんながやっているから“は我慢の理由にならない」
ということ

「会社って苦痛が伴うものだから」
という固定観念は考えなおしてみるといいかもしれない。

プログラマ3大美徳

  • 怠惰
  • 短期
  • 傲慢

一般的な美徳そうな言葉

  • 勤勉
  • 寛容

勤勉の悪

我慢して耐えることが美徳のような思想
なんとなくそういうものだと思ってやっていると
自分の意思がない。
我慢の理由にならない我慢になる。

そうではなく、結果を出せば良い。

だが、日本にありがちなものとして、

  • 生産性より忍耐という風潮
  • 社会的圧力
  • 空気を読む
  • 理不尽を拒否せずに我慢する。

というのがある。

理不尽は積極的に拒否しなくてはならない。

苦痛に耐えていると、苦痛に強くなる。
そして、苦痛に対して鈍感になる。
だが、「致死量」は変わらない。
ある日、致死量に達してしまう。

仕事は大事だし、自己実現のためにも耐えることは大事だけど
命よりも大事なのだろうか?

みんながやってないけどやってもいいこと

やってはいけないと書いてないけど、できること。
裏技
少しの労力で楽をする。
我慢しない。
空気を読まない。
目的を明確化する
→ 自分がやりたいことはなんなのか?目的はなんなのかを明確にする
→ そうすると限られた目的の中で競争するので、競争率の波に飲まれることがなくなる。
don’t work hard

どうやって一所懸命働くことを「拒否」するか

自分の意に沿わないことは積極的に拒否をしよう。
拒否してもなんとかなると思って。
上司の言うことを完璧にこなすことで、私たちはvalueを届けているわけではない。
私たちは自分の働きによってvalueを届けている。

あと、拒否したら意外と通ることが多いと思う。
大抵の人は拒否する前に空気を読んでしまうけど。。。

7つの習慣の話

「7つの習慣」という本がある。
そこに書かれていることだが、
私たちが何かと付き合っていくとき、
長続きする付き合いかたは

  • Win-win
  • No-Deal

の2種類。
(場合によっては)逃げてもいいんだ
死ないために。

みなさんに伝えたいこと

  • 我慢に価値を置かない
  • 自分を知る
    自分のスキルセット、やりたいこと、目的についてもう一度考えてみよう。
    自分の武器になることを見つけられたら、それを伸ばして行こう。
    そしてそれを続けることが大事だ。
    「こっちにいけば幸せになりそう。」という方向に進もう。

プログラマーの仕事は問題解決

  • 問題把握
  • 問題解決
  • ソリューション提案
  • ソリューション実装
  • テスト
  • 改善

プログラマーの仕事の大半は、コードを書くのではなく
問題解決をしている。
これが本質である。

これと同じ原則を人生に適用しよう
人生の問題解決も同じようなプロセスで大体の問題が解決できる。

  • 問題把握
  • 問題解決
  • ソリューション提案
  • ソリューション実装
  • テスト
  • 改善

プログラマは問題解決能力がとても訓練されている
我々は人生の勝ち組になりやすいのかもしれない。

コントロール意識

エンジニアは叱られると生産性が60%低下すると言われたりもする。
強制されると生産性が低下する
逆に言うと、自分をコントロールする意識が生産性を高める。

生産性が高まると良いことが多い

  • 生産性を高めて疲れないようにする
  • 生産性を高めて早く帰れてリフレッシュする

など

万能感

我々がプログラミングしていて楽しいと思えるのは
万能感があるからではないか。
なんでもできそうな感じ。
0から1を生み出す感じ。
アマチュアの人が少し学んでもプロの人と遜色ないレベルまで行きやすい。

コンピュータに仕える奴隷にならない。

私たちは、コンピュータをちゃんと動かすための行動をしている
「コンピュータにちゃんと動いてほしい」という感情が強い。
するとだんだん、コンピュータのほうが自分より立場が上なんじゃないかと感じるようになってしまう。
「コンピュータに仕える自分」という関係になってしまう。
これを、”アルファシンドローム“という。
自分の人生の主人公はコンピュータではなく、自分にならないといけない。
あくまでコンピュータを仕おう。

インプット・アウトプット

インプットは大事
だが、差別化要因になりにくい。

アウトプットは差別化要因になりやすい。
だが、アウトプットはしんどい
面倒・羞恥心

例えば、高収入芸能人だったり、高収入ユーチューバー
「あんなの誰でもできる」という感情は半分本当
彼らのすごいところは、心理的障壁を超えているということ
大抵の人は、「はずかしい」「チャンスがない」ということを理由にやらない。

冷静に考えると
クオリティは棚上げにしてとりあえずやってみるのが大事。
人間の可塑性にかける

立場が変わることによって、人間は考え方が変わったり成長できたりする。
心理の怖さを克服することが大事。
心理的側面に興味をもとう。

我々の仕事に当てはめると、

  • クライアントの心理
  • 自分の心理

など

まとめると

  • 理不尽に打ち勝とう
  • 我慢しなくていいことを我慢しなようにしよう
  • やってもいけないことでないことはやろう
  • 問題解決能力を身につけよう
  • コントロール意識
  • コンピュータを仕う側になろう。
  • 心理的側面に関心を持とう。

質疑応答

Q. 100人レースの1位と10人レースの1位のどっちを目指すのに価値がありますか?
A. 10人レースの1位の方。「1位であること」に価値があることもある。
競争率の少ない10人レースでしっかり1位をとることが大事。

Q. Matzさんのライフチェンジンクになるような名著はありますか?
A. 「達人プログラマー」最近複版したやつ
あと、「バベル17」

Q. 日々の情報収集の仕方を教えてください。
A. あまりたいしたことはしてない。twitterのrssリーダーを上から見て行ったり。
1日の結構な時間をrssリーダをみている。
hacker newsというのをよく見ている。
次代の技術に使われるような内容が得られる。

Q. 大学でコンピュータサイエンスをやってない人が今からでも始めるには?
A. 大学では体系的な勉強をするが、卒業してから体系的な勉強をするのは現実的ではない。
ボトムアップ、自分で勉強しながら分からないことが出てきたら都度調べるというような
芋づる式で調べていくのが良いのではないかと思う。

Q. Matzさんは講演などよく行っているが、自分は自由だと思いますか?
A. やっていることの期限などがもちろんあるが、理不尽な要求を飲まないといけないことなどがないので
そういう意味でいうと自由だと思う。

Q. あるネットの記事をみていると、海外からの日本エンジニアの評価のようなものがあった
ざっくり言うと、日本人は最新技術に疎いという評価だった。
Matzがいるじゃん!という反論をしたが、「Matzは多様な価値観を持っているから」ということだった。
キリスト教の宣教師をやっていたそうだが、多様な価値観が役立ったことはあるか?
A. キリスト教の宣教師の価値観が役立ったことはあまりない。
英語のコミュニケーションに少し役立ったくらい。
ただ、多様な価値観を持っているのは、今日話したようにいろいろなことを考えることができる。

Q. 最後にMatzさんから一言
A. 私たちは組織に属しているが、組織のほうが上の立場であるという固定観念は持たないようにしよう
同じ対等の立場、むしろ自分のほうが立場が上だというくらいの気持ちでいよう。
会社から理不尽な要求をされたら「No-Deal」付き合わない選択肢も考えよう。

ソフトスキル第3章まとめ

未来について考える。あなたの目標は何?

目標を決めなければいけない

目標を決めなければ、ズルズルと日常に流されてしまう。

自分が数年後、数十年後どのようになっていたいかの目標を決めなければ、目標に向かって進むこともできない。

目標を決めるのは恐いことではある。

自分の進む道が間違っていたらどうしようとか、進んだ先が気に食わなかったらどうしようとか。

だが、自分で目標を決めなければ、良いチャンスが舞い込んでこないかと棚からぼたもちを期待するだけの人生になってしまう。

むしろそのままでは、今の会社に解雇されるまでポストにしがみつくだけの人生になってしまう。(会社に居続けるのが悪いわけではなく、その中で目標があるのならよいと思う。)

目標がなければ、いますぐ立ち止まって目標を決めなければいけない。

目標の設定方法

目標を設定する必要があることを認識したら、目標を設定しよう。

だが、目標を設定することは難しい。

まずは、長期的な大きな抽象的な内容で良いので、遠い数年後の目標を立てよう。

大事なのは、目標達成の方向に向かっているか、逆の方向に向かってしまっていないかを判断できるようになることだ。

大きな目標を小さないくつもの目標に分割しよう

大きな目標が決まったら、次はそのためのステップを考える。

大きな目標は大きな一歩で達成できるものではなく、小さな一歩一歩の積み重ねによってなし得ることができる。

例えば、上級レベルのプログラマになりたいのであれば、いくつもの技術書を読まないといけないだろう。

その中で、今年一年でこの本をマスターしようなど、そういったことが一歩一歩になる。

小さな目標を設定することは、日々の生活に落とし込める

小さな目標を設定すると、毎日の生活でしなければならないことに落とし込むことが容易になる。

例えば、今年一年で技術書を一冊マスターしたければ、1日何ページこなさなければいけないかなど

小さな目標にすることは、日々のモチベーション維持にも繋げることができる。

大きな目標だと達成するのに何年もかかるかもしれないが、

小さな目標だと頻繁に達成感を味わうことができる。

大きな目標に一歩一歩近づけているという充実感もある。

また、小さな目標を設定していれば、大きな目標への軌道修正もしやすくなる。

目標の再設定をする期間を設けよう

「目標に向かって進んでいるつもりでいたが、気がついたらしばらく間違った道を進んでしまっていた、とうような」ことは避けたい。

定期的に目標を再設定する期間を設けよう。

そうすることで自信を持って前に進むことができる。

前進できているか、何か調整が必要かを確かめるためにも、短期的目標と長期的目標で達成できたことを振り返ってみよう。

ソフトスキル第2章まとめ

スタートから派手に行こう!誰もがするようなことはするな

あなたは、空高く打ち上がり綺麗に爆発する花火だろうか。

それか、空高く舞い上がるも不発して落ちていく花火だろうか。

自分のスキルを事業として、自分を事業者としてとらえよう

世の中のソフトウェア開発者は自分のキャリアをビジネスとしてとらえておらず、それが大きな誤りだ。

私たちはコードを書いて世の中を渡り歩く世界にいるので、中世の街で店を準備している鍛冶屋と同じだ。

私たちはスキルによって取引をしていると考えてよいだろう。

自分のが自分のキャリアビジネスの事業者だと考えると、自分という事業のために優れた判断を下せるようになる。

会社から給料をもらうだけという考えをしてしまっていると、ただの従業員という思考になってしまう。

そうではなく、渡したちは会社という顧客に対してビジネスを行っているととらえないといけない。

自分を事業とする考え方

自分を事業として考えただけでは大した意味はなく、その意味を考えなければいけない。

自分はビジネスは製品を売って成り立っている

私たちが売る製品というのは、「ソフトウェア開発」というサービスを売っている。

そしてそれは、「ソフトウェアを開発するスキル」を売っていることにもなる。

自分のスキルというサービスの売り方を考えよう

私たちはスキルを持っているだけでは不十分である。

世の中の一般的なサービスはしっかり売り方を考えてマーケティングしている

同じように、私たちは世の中にゴマンといる開発者と比べられるように、その売り方をしっかり考えなければならない。

たとえば、

自分が提供するサービス(スキル)を向上させる

顧客(会社やクライアント)のニーズにあった売り方をする

このように考えると、一般的なサービスのマーケティングと、私たちのキャリアをマーケティングすることはとても近しいことが分かる。

自分は自分のキャリアの事業主だと認識し、顧客へのサービス(スキル)の提供の仕方をや提供するサービス(スキル)についてよく考え、いいキャリアを築いていこう。

Cybozu Meetup #7 セキュリティに行ってきました。

イベントページ

https://cybozu.connpass.com/event/63652/

イベントの趣旨(引用)

サイボウズでは製品セキュリティの品質向上をミッションとして PSIRT( Product Security Incident Response Team ) が活動しております。
PSIRT では 2014 年 6 月より、「脆弱性報奨金制度」を運営しております。 ご報告いただいた脆弱性情報を適切に評価し社内にフィードバックしております。

脆弱性報奨金制度のインパクトが大きいために他の活動はあまり目立っておりませんが、実は報奨金制度の運営以外にも様々な取り組みを行っています。
この Meetup では、実際にサイボウズの PSIRT がどのような取り組みを行っているかをお伝えしようと思います。

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

もしかしたらところどころ間違っているかもしれないので

その際はご指摘ください

講演1つ目

PSIRT の取り組み

講演者:ヤマニシさん

品質保証部に所属している

脆弱性評価などを日頃やっている方

CY-PSIRTとは?

製品のセキュリティ品質向上を目的にしたチーム

脆弱性情報の受付、評価、公開を行なっている。

脆弱性の検出について

  • 社内検証
  • 外部検証
  • 外部監査

が主にある。

ソフトウェア属性情報管理

扱っているサードパーティ製品の情報をDBにまとめている。

→サードパーティ製品に脆弱性があった場合に製品担当に連絡できるようにしている。

kintoneのアプリで脆弱性情報を集約している。

情報の公開

脆弱性認定ガイドラインを定めている

サイボウズで利用しているサードパーティ製品に脆弱性が見つかった場合に

サイボウズは問題ないですよという情報を発信している。

脆弱性検査のために

本番環境とはネットワークを分離した環境を用意している

セキュリティテストの実施

各製品の試験期間中にアクセス権が正しいかなどのセキュリティテストを取り入れている

社内検証はどのようにやっている?

試験仕様書を用意している

セッション・リクエスト・パラメータ等で網羅的に検証を実施。

脆弱性検証用のアプリを用意していて、それを元にテストを実施している

 (聴きながら思ったこと)AppScanのようなものを自前で用意しているのだろうか?

webアプリケーション診断ガイドラインというものが世の中にある

https://www.owasp.org/index.php/Pentester_Skillmap_Project_JP

今後はそれに合わせて脆弱性検査用アプリの内容を設定しようとしている。

外部検証について

社内とは別で、社外に検証を委託している

サイボウズのHPの検証は外部検証を行なっている。

外部監査について

外部の監査期間に、攻撃者の視点で脆弱性をつけないか監査をしてもらっている。

→(聴きながら思ったこと)監査結果を、パブリックに公開している?

CY-PSIRTの工夫

情報の管理

管理する情報が多い。

  • バグハンターの人からの問い合わせ
  • 報奨金の用意

などなど、やることが多い。

そこで、kintoneを使っている

脆弱性の情報は、脆弱性boxというアプリを使っている。

どこから報告された脆弱性か、脆弱性についての詳細などを書いている。

そこから、CVSSという計算機をつかって脆弱性を評価

業務内容

業務の内容が多いので、アプリを使って管理している。

  • 主担当やフロー
  • ドキュメントの場所など

そうすることで、誰が何をやっていて、誰に聞けば良いかというのが管理しやすい。

→(聴きながら思ったこと)画面を見せてもらったが、アーカイブ機能に優れていそうなツールだった。

業務の提案

品質向上のための取り組みをいろいろやりたい

自動検証ツールや、報奨金がといった要望があるが

そういった要望に対してサイボウズは割とすんなり通る社風

思いついたらとりあえずやる風潮

気軽に取り組める環境が大事

→(聴きながら思ったこと)そういう風潮が社内に根付いているのは、行動を起こす上でも、周りの理解を得る上でもとても大事だと思った。

ただし、人員不足がネック

調整事が多い

製品に対する決定権を持っていないので、プロダクト側との調整が大変。

脆弱性情報をいつ公開するか、など

バグハンターからの問い合わせも、問い合わせ管理アプリを使っている。

 問い合わせ管理アプリの画面見せてもらったが、写真などのシェアはNGだった。ただ、記載することなどが、あとから見てもとても明瞭になるような工夫がされているなと感じた。そういったやりとりのエビデンスを残す場所は、何をどう書くかを明確にしているととても書きやすそうで分かりやすいと思った。

メールのやりとりはメールワイズ。

どこで誰と調整するかを明確にする。

調整して、どこを折衷案とするかを考えるのが大変。

質疑応答

質問

社内検証・外部検証などはいつやるか?

答え

新機能を出すたびにやります。
ただ、外部監査については定期


講演2つ目

報奨金制度の近況

講演者:オオツカさん(オオツカさん不在のため、1つ目の講演のヤマニシさんが代わりに登壇)

報奨金制度を主に担当している。

2014年に報奨金制度スタート

現在で4年が経った

バグハンター合宿なども実施している。

延べ、240名が参加

年を追うごとに、システムは堅牢になりつつある。

最近、報告件数が減っているので、報奨金を上げている(5倍に上げている)

報告された内容が緊急レベルのものだと、50万くらいもらえる。

報奨金ランキングを見えるようにした。

ハッシュタグ:#CybozuBugBounty

制度の英語化をしている

海外バグハンターへのアピール

脆弱性評価の裏側

着信→受付→評価→クローズ連絡→クローズ

評価の流れ

CVSS V3に基づいて評価→レビュー→社内告知を作成→告知レビュー

今後について

バグハンターにとって魅力的な制度に保つ

質疑応答

質問

脆弱性報告件数が少なくなったなった理由だが、製品が堅牢になったと評価できる?

答え

そう思いたいが、きっとそうではない。
社内検証でもたまに出てくる。
また、報奨金を上げたら報告件数も上がった。

質問

バグの報告があって、クローズまで、平均どのくらい?

答え

最短だと1週間以内。長いと、1ヶ月とかかかる。1ヶ月かかるのはひどい話。

質問

アクティブなバグハンターはどのくらい?

答え

計測していないので分からないが、おそらく直近だと10~20人くらい。


公開された資料