nariのエンジニアリング備忘録

SRE/Devops/AWS/自動化/IaC/Terraform/Go/DDD など

SRE NEXT 2020を一運営スタッフとして振り返ってみる

f:id:st5818129:20200127002406p:plain

はじめに

こんにちは。都内でWeb Developerをやってる@nariです。

先日2020/01/25に、日本初のSREカンファレンス「SRE NEXT」が開催されました。

sre-next.dev

以下のツイートで、参加者にブログを書くまでがSRE NEXT!!とか自分で煽っておきながらお前(運営スタッフ)が書かないでどうするんだと言う感じなので、やむなしで書いている振り返り記事がこちらになります。 (参加者やスピーカーの皆さん本当に多くの参加レポありがとうございます。コミュニティカンファレンスらしい盛り上がりで最高)

今回は僕が手伝い始めてからカンファレンス当日までを、一運営メンバーとして振り返っていこうと思います。

手伝い始めるきっかけ

【増枠】SRE Lounge #10 - connpass に参加した時に、丁度SRE Lounge運営スタッフ主体でSRE NEXTというカンファレンスの開催決定が宣言されました。 運用改善や基盤への思いがずっと強かったのもあって、これは絶対に手伝いたいという思いが強すぎて気がつくとtwitterで主催者のかつひささん (@katsuhisa__) | Twitterさんに運営やらせてくださいとリプライを送っていました。

そんなこんなで8月くらいからメンバーとしてjoinさせてもらったのですが、振り返ってみると、SREでもない、しかもメンバーに知り合いもいない何処の馬の骨ともわからんやつをよくホイホイと入れたなという感じが凄いですね。katsuhisa氏の肝っ玉よ。。

で、お前は何をやれたの

途中参加の人間、しかも中には誰も知っている人がいない状態の自分がまずやるべきことは、浮いているタスクを自分で見つけてこなしていくことで信頼関係を構築することだと考えました。

手が回っていなかったTwitterなどの広報、チケットサイト、動画コンテンツ準備のタスクをひたすらこなして言ったり、必要な要件や情報を得るためにコアスタッフを捕まえてどんどんコミュニケーションを取っていくことを重視していました。

コミュニティのコアスタッフの経験が一切なかったのとガムシャラにタスクを取りすぎ+業務の繁忙期という状況になって、チケット公開でちょっとやらかしてkatsuhisaさんにフォローしてもらったり、多々粗相はあったとは思いますがある程度価値は発揮できたし信頼関係も構築できたかなと思っています。

後は、途中で僕の前職の同僚(@Buzz)と先輩(@ogady)を運営メンバー誘って、自分が抱えすぎたタスクをうまく割振れたのも爆発せずに済んだ要因だと考えています。。@Buzzと@ogadyはありがとうね

ここからは、それぞれやってことをトピックごとに少し振り返ります。

イベントチケット/参加者管理

だいたいチケット周りは一人で担当しました。 イベントチケットサイトとして採用したEventbriteのUIやシステムの不安定さには手を焼かれましたが、機能要件は完璧に満たしていたので、まぁサービス選定は間違ってなかったのかなと振り返ってみて思います。 詳しいここら辺の選定/オペレーションの話はどっかでまとめると思います。

一般参加者人数の意思決定に関しましては、とにかく参加者が快適であることを優先しました。後100人くらいにはチケットを売れたかもしれませんが、それで参加者の満足度が下がっては意味がありませんので、そこの意識は常に徹底して経理周りをすべてやっている@ogmさんなどと相談して決定しました。今回はこれでよかったと思っています。

オープニング動画/セッション紹介動画作成取りまとめ/スポンサー動画作成

当初は私がオープニング動画/セッション紹介動画も作ろうと思っていましたが、動画関連のサービスのエンジニアといえど動画制作の経験はありませんでしたので、クオリティの保証ができないということで外部に委託しました。

そこでお願いしたCrevo様並びに担当クリエイターさんには、低予算(初回なのでお金がない)にも関わらず本当によく対応していただきました。本当に感謝!

「セッション紹介動画を毎セッションの前に流す」案に関しては、発表お立ち台のない会場で雰囲気にあわないのではないか?などの意見がありましたが、僕が登壇者だったらテンション上がるし参加者としてもスペシャリティを感じてくれると判断し、作成し流すことに決めました。

こんな無理なお願いにも関わらず、本番は最高の音響オペレーションをしてくれた@okash1n,@Ryoter,@H.M,@sogaoh氏には本当に感謝しても感謝しきれません。こちらにも感謝の意を今一度表させていただきます!

結構動画系は評判良くて嬉しくて懇親会のお酒がめちゃくちゃ美味かったです。

Twitter運用

とにかく参加者の満足度が下がるようなことが起きて欲しくない一心で事前注意を繰り返し共有すること、みんなで盛り上げていこうと言う意識は徹底していました。

注意事項をひたすら繰り返しメールとともに案内する、ここはしつこいくらいの方がいいと判断し徹底して行いました。(会場、受付混雑回避施策のヨガ、チケット譲渡、QRコードの用意の案内、その他注意事項)

また、イベント開催前からイベントの雰囲気作りは始まっていると思っているので、ひたすら#srenextタグで呟いてくれるツイートは捕捉していいねリツイートしてみんなで作るカンファレンスなんだ、と言う意識を共有することは大切にしていました。

課題としてはマーケティング面で、少し絵力のないツイートばかりで、もう少しツイート構成を工夫できればよかったなと思ってます。(まぁ1ヶ月前には売り切れてしまったので、宣伝のプライオリティが落ちたと言うのもあるのですが)

あとはとにかくSRE NEXTでエゴサーチして、参加予定者がどういう所に不満を持っているかをキャッチするのは毎日やってました。そこからサイトの情報の掲載の仕方を変えたり、個別でフォローするCSライクなこともやっていました。(もちろん直接くるDMの対応も)

参加型アンケートをスポンサーブースへの誘導施策として実施

最終的に100人くらいの人に参加いただけたので、ある程度は成功したかな?(段取りの面でめちゃくちゃ反省がありますが、@saitotaq氏に救われましたありがとう。)次回があるなら、もうちょっと凝った誘導施策をやりたいですね、スポンサーのためにも。

リアクションも結構あった。

当日の反省/振り返り

細かい自分のタスクに対するKPTは多々ありますが、そちらは運営内のシートや振り返り会で細かくやりたいと思います。 自分の全体としての大きな問題としては、

  • 初の大きなカンファレンスの運営スタッフ(ボランティアスタッフは何度かやっていますが)かつ臨機応変な動きが必要となる遊撃隊という立ち位置で、度々適切でない問題提起の仕方をしてしまった(感情が丸出し、解決方法の提案とセットではない)

これがすごく反省です。こればっかりは経験値不足でしゃあないって感じですが、ケーススタディ的に色々こういう問題が起きたらどうするかを想定して学んだりはしていけるはずだし、今回で自身も成長しているはずなので次回以降はもっと柔軟に冷静に対応できるようになります。

SRE NEXTの課題とこれから

TLを追っていても肯定的なツイートが多く、イベントとしては大成功だったとは思いますが、こういう時こそ冷静に課題とこれからについて整理したいと思います。

組織の設計、あり方 

第一回ということもあり、良くも悪くも皆何でも屋で、タスクをゴリゴリ進めていくベンチャースタイルの運営方法でした。

しかし、これからの組織やカンファレンス規模拡大を考えると、この体制は再検討しなければならないと思っています。 継続的にひたすら雑多にタスクをこなすことが美となってしまうと、スペシャリティを持った人間のスポット起用といった選択肢が取りづらくなってしまいます。

ですのでコアスタッフという一律の扱いを僕はやめるべきだと思っています。ある程度Roleを明記したりそれに基づいてチーム編成を考えたり、そういった組織設計を次のステップに進む時にまず初めに考えなければならないですね。

まぁしんどい雑用もたくさんあるんで、そこは皆でやっていくしかないのはそれはそうと言うやつですし、仕事じゃないのである程度奉仕の精神に支えられているのは間違い無いので、そこをどう「俺はこんなに仕事しているのになんであいつはやっていないのだ」と言う負の感情に向かわないように仕組みを作るかが重要だなとおもっております。

カンファレンスとしての方向性

国内でどんどんTokyoだけでないコミュニティの発展を後押ししていくことを重視するのか、それともSREconが無視できない国際カンファレンスとして成長させるのか、SREcon Asia/PacificをTokyoに誘致してまずパイプを作ることに注力するのか。色んな選択肢がありメンバーそれぞれの嗜好があると思っています。ここをきちんと定めるのも、組織設計の再検討とともに初めにやるべきだと考えます。

私のこれからのSRE NEXTとの関わり方

僕のこれからのSRE NEXTとの関わり方として、マーケティングやコンテンツの責任者をやっていきたいと思っています。(海外対応のカンファレンスにしていくならそこにも尽力したい)しかしセッション選定に関しましては、僕の現在のエンジニアリング力では一切説得力がないです。

私は現在絶賛SREへ転職活動中で、1月中にはどこにいくかは決めようと思っています。 (決まったら皆様には改めて報告させていただきます。)

新天地で自分のSREとしてのスキルやスペシャリティを磨きつつ、個人でもアメリカの通信大学でCS学んだりLeetCodeひたすら解いたりして根底の力も伸ばしながら僕の目指す理想のSREになっていき、SRE Lounge/NEXTというコミュニティとともに成長しつつ還元していきたいと思ってます。

最後に

本当に参加者やスポンサーの皆様にはお世話になりましたし、おかげさまで素晴らしいイベントになったと思います。ありがとうございました!今後とも前向きに継続検討しておりますので、よろしくお願いします。

売り切れて参加できなかったよ、、と言う人は多くの人が書いていただいている参加レポや、こちらの資料まとめの記事などを参考にしていただくとどんなイベントかわかりやすいと思いますし、良質な情報ばかりだと思います!(後ほど公式からもまとめて共有します) また、全てではないですが、セッション動画公開予定なのでそちら楽しみにしていてください。

また、スタッフ(当日、コア問わず)の皆さんも言わずもがな最高でした。SREらしい柔軟な動きを皆さんができていて、皆さんのおかげで最高のイベントになったと思います!最後にめちゃくちゃCoolなスタッフの全体写真のツイートを貼ってこの記事は終わりにします。(なおこの写真には僕は載ってない笑)

メインフレームを保守するSIerからWeb Developerにジョブチェンジして、もうすぐ1年経つので振り返る

はじめに

こんにちは!都内でWeb Developerをやっているnariと申します。 現在はアーティスト支援系サービスをGo/AWS/Terraformで開発しています。

今年一年の振り返りはさらっとTwitterで済ませてしまおうと#2019年を振り返るハッシュタグに便乗して上記のようなツイートをしてみたところ、案外多くのリアクションをいただけたので別途記事でも書くかということでこの記事を書いております。

また、今年2月から現職にお世話になっていて、来年の1月末で某金融系SIに所属するメインフレームを保守するSIerからWeb系企業の開発者として転職して丸一年経つということで、そちらもまとめて振り返ってしまおうという感じになってます。(雑)

この記事で書かないこと

  • 抽象的なSIとWeb企業の比較談義

ひたすら私具体的にやってきたこと/それをやった理由を棚卸するだけの記事になります。ご了承ください。

なぜ転職したか

  • ビジネスサイド(銀行)、運用部隊(データセンター)との折衝にひたすら工数を取られる当時の状況に疑問を感じ、devopsを体系的に学びたかった
  • 当時PMとしてキャリアを積んでいく路線だったが、設計/実装/運用を知らないものにエンジニアリングのマネジメントはできないと判断し、全てが効率的に学べるのがWeb業界だと感じた
  • 現職はアーティスト支援をメインの思想として掲げており、音楽やカルチャーが大好きで演者としての人生も考えていた自分にマッチした

結果的にアプリ〜インフラ、設計〜運用まで幅広く経験することができており、ジョブチェンジして正解だったなと思っています。

今年一年で何をしてきたか

業務

GoでのAPI開発

とりあえずJava/Rubyを少し書いていたくらいで、Goが何もわからないので、簡単なWebアプリをMVCで作ってそれをClean Architectureにリファクタする中で基本のお作法を覚えました。正直DIだのDIPだのまじ意味ワカンねぇなってなりましたが、色んな文献を読み実装する中で徐々に自分の中に落とし込めた気がします。

qiita.com

OpenAPI仕様管理ツール(Apicurio,Stoplight)を比較検討を導入し、既存のAPI仕様をドキュメント管理ツールでの管理から移行したりもしました。

qiita.com

qiita.com

それからは、メインプロダクト(動画納品サービス)とショップリコメンドシステム(ポイントモール)のAPI開発を通して、実践的なGoの書き方/generater/testの書き方を学んでいきました。また、チームの流れとしてClean ArchitectureでDI可能な方向にリファクタリングしていくなかで、基本的なレイヤードアーキテクチャデザインパターンも学んでいきました。

AWS上でインフラ全体を設計し、IaC(インフラのコード化)する経験

こちらは、ショップリコメンドシステム(ポイントモール)を構築するにあたって、新規にAWS上にインフラを構築できるということで、先輩と二人でビジネス的な要件に合わせ全体を設計し、TerraformでIaCしながら実装しました。 以下のように、この案件で非常に広範囲のインフラ構築の経験が積めました。

  • http serverをdeployするための基本的なインフラ(VPC, ALB, S3, RDS,Nginx)
  • 急激なアクセス増加に合わせて、低コストでスケールするアプリケーションサーバー(ECS on EC2,ECR, SpotInstance, CloudWatch Event, Lambda)
  • 顧客影響のあるFatalなアラート時は、Slack通知後に電話(Amazon Connect, CloudWatch Event, Lambda, SNS)
  • レスポンスタイムの要求がシビアになっていくことが見込まれていたので、マスターとは別にアプリがやりとりするデータソースとしてRedisを選択し、List/Hash/String(json)型のパフォーマンス計測で比較検討しデータ設計(Elasticache)
  • 親システムとのマスター同期のための非同期ジョブの実行管理(Step Functions)
  • AthenaでもBig Queryでも解析できるログ基盤構築(Fluentd,Kinesis firehose,S3)
  • 仮説検証を高速で行えるようなCI/CDの整備(AWS CodePipeline,Gitops)

もともと「AWS?何それわからん。。IaCなんてよりわからん。。」だったのが短期間でここまで実装し経験を積めたのは、事前にAWS SAAを取得し頭の中に目次を作り、技術書典6でTerraform入門本の名著「Pragmatic terraform on AWS」を購入しプライベートで色々いじっていたのが効いたと思います。

qiita.com

qiita.com

qiita.com

qiita.com

IaC啓蒙

サービスとして、グローバル展開をするということで従来のGUI管理では限界がきているのは目に見えていたので、自身もう上記の案件でノウハウのあったTerraformの勉強会を開催しました。

qiita.com

こちらの具体的なお話は、SRE Advent Calendar 2019の22日目に書いています。

qiita.com

これからも継続して実施していけたらと思っています。

ChatOps導入

チャットツールにインターフェースを集約し、メンバー操作の履歴をシェアするChatOpsの思想が好きで、AWSリソースを操作するのにクレデンシャルに煩わずスラッシュコマンドで呼び出せるSlackBotを作成し、導入したりしました。

speakerdeck.com

共通検索基盤事前調査・設計(Pending)

弊社のアーティストサービスでは、アーティスト/曲/リリースといったデータ検索をネイティブアプリ/Webアプリでももちろんできるのですが、双方精度とレイテンシーに問題がありました。 ですので、Elasticsearch(形態解析とユーザー定義辞書のメンテ)とGo製のAPIで双方の問題を解決するというプロジェクトをやっていましたが、USプロジェクトの方が優先度が高くなりPendingの状態となりました。

qiita.com

AWS上のステージング・開発環境のリソースのIaCとアカウント移行

こちらはterraform Advent Calendar 2019 15日目の方に詳しく書かせていただきましたので、そちらをお読みいただければと思います。

qiita.com

手動デプロイをCD as a serviceに委譲(WIP)

こちらはまだWIPの状況ですが、手動デプロイをCircleCIとGitopsのよるデプロイのコントロールに以降しようとしており、AWS Codeシリーズとの比較検証は大枠の設計は終えています。来年落ち着き次第こちらも記事にしたいと思っています。

USチームとの折衝/調整/会議のファシリテート

もともと英語のReading/Writingはまぁまぁ不自由なくできる方だったのですが、Speaking/Listeningにかなり苦手意識がありました。しかし、ここ三ヶ月ほどUSチームと週一でmeetingしたり定常的にChatでやりとりしたり、プライベートでもシャドーイングやDMM英会話のレッスンを受けたりすることでかなり苦手意識がなくなり、ビジネス上での意思疎通くらいなら不自由なくできるようになってきました。これからも継続して英語力はブラッシュアップしていきます。

技術発信支援

もともと入社当時は弊社のアウトプットはお世辞にも活発な状況とは言えなかったので、まず自身が週一でアウトプットし、社内外でシェアすることでアウトプットしていく流れを作ろうとしました。

その結果個人的には社内表彰をされたりもしました。

しかし、それだけではアウトプットの文化作りという面ではあまり上手く行きませんでした。(特に他の人がアウトプットをし始めるとかはなかった)

そこで12月からはアドベントカレンダーのチャンスを生かし、普段アウトプットしていないが書いた記事を読んでみたい人に声をかけまくって、記事を書いてもらいました。その際、アイデアが出てこないという人とは壁打ちしたり、構成に自信がないという人はreviewをしたりしながら、アウトプット/知の共有の楽しさを伝えていきました。

結果Qiita Organizationのメンバーは当初の2倍以上になり、「書いてよかったし、これからも継続して書いていきたい」という声を聞くことができました。継続的に支援し、これからも多くの人が知の共有の大切さに気がつくきっかけを作れればと思っています。

qiita.com

プライベート

1月にギークハウスに引っ越した(2020/01/02 追記)

25年間ずっと実家暮らしだったんですが、もうそろそろ外に出ないとなと思ったのもあって思い切って引っ越しました。 ギークハウスを選んだ理由は、ちょうど技術者として生きていく決意(転職)とともに住む環境もガラッと変えてしまった方がいいと思ったからです。 最初は西新宿の方に2ヶ月くらい住んで、その後代々木の方でずっとお世話になっています。

みんなで開発合宿したり、突然のLT大会で情報共有したり、おうちハックしたりエンジニアにとって最高の環境です。自分にないものを持っている人がたくさんいて、その人々と知のシェアリングができている感じが現代っぽくてとても好きです。 結婚したり同棲する人ができたりするまでは、シェアハウスでフラフラしたいと思ってます。

以下はみんなで作ったシェアハウスの鍵を開けるシステム

鍵システムの紹介と、Go/ラズパイ/Mackerelを使ったおうちハックの勧め記事 qiita.com

AWS SAA(認定ソリューションアーキテクト アソシエート)取得

入社当初クラウドなんもわからん、、チームメンバーの言ってることが全然わからん。。だったので、とりあえず冒険の地図を得る感覚でAWS SAAを取得しました。今振り返ると、入社直後にとったのは英断だったと思います。みなさん是非とってみてください。

qiita.com

モデリング会立ち上げ

ちょうどチームとしてもClean Architectureでリファクタしていくという流れだったのもあり、そもそもの根本のモデリングを学びたくモデリング会を立ち上げました。

geekhouse-shinjuku.connpass.com

fukubaka0825.hatenablog.com

非常に得るものも多く常に定員の2倍くらい応募のくるイベントでしたが、3回ほど行った後Developer Productivity/IaC/SREという領域に興味がかなり移行してしまい、しばらく行えていません。 どこかで再開したいと思っています。。

Gopher道場卒業

Gopher道場とは、Go Conの主催者でもあるtenntenn氏が定期的に開催している体系的にGoをみっちり学べる勉強会です。 課題を提出し無事選考を通り1ヶ月講義と課題をこなし、最後にLTをしてGopher君Tシャツをもらい卒業しました。

gopherdojo.connpass.com

qiita.com

結果、Table Drivenテストやエラーハンドリングについて特に理解を深め、現場にも持ち帰り導入できたし、何よりGoを学ぶ熱量が高い仲間ができたので非常に有益でした。

技術書典7で技術同人誌初執筆

私はギークハウス新宿というシェアハウスに住んでいるのですが、仲良くさせてもらっている住人(@wamisnetや@samuraikun(元住居人))など技術書執筆経験者が非常に多く、技術書典6に参加し感化されたのもあって技術書典7に参加し技術書を頒布することとしました。

非常に多くのトピックを扱いすぎたり、なかなか執筆のエンジンがかからなかったりで非常に苦労しましたが、住人のサポートのおかげで記事のアウトプットでは得られない経験がたくさんできたので非常によかったです。

fukubaka.booth.pm

note.com

技術書典8は出られないですが、技術書典9では何かしら書くつもりでいます。

SRE NEXTの運営メンバーに加わった

9月に参加したSRE Lounge #10でSRE NEXTなる日本初のSRE Conferenceが開催されるということ知り、昔からdevops/基盤に関する関心が強かったこともあって居てもたっても居られず、気がついたら主催者のkatsuhisaさんTwitterのリプで「是非お手伝いさせてください!」と送っていました。 そうして、運営メンバーとして参加させていただくこととなりました(何処の馬の骨かわらない僕を入れてくれたことに感謝!)

sre-next.dev

私が具体的に何をやっているかというと、Twitter運用/ブログ記事作成/イベントチケット管理/動画制作の取りまとめ などなどをやっていっています。

ちなみにSRE NEXT 2020は2020/01/25開催ですが、もう一般チケットは全てSOLD OUTしてしまっています。

しかし非常にハイレベルはセッションばかりなので、参加できない方も後からスライドをチェックしたりしながら活用していただければと思います。 参加者の方はスタッフ一同、急ピッチで準備進めており、素晴らしいイベントにしますので当日はよろしくお願いいたします。

記事をたくさん書いた

数えたら、はてなブログ、Qiita、note、medium合わせて今年で54記事書いていました。Qiitaで何個かバズったりして、合計2000いいねを超えたりしました。

f:id:st5818129:20191231184833p:plain

一方、アウトプットが散らばってしまいとても見辛い状況になってしまったので、年末に自身のキャリアとアウトプットを集約したポートフォリオサイトを整備しました。

www.fukubaka0825.dev

来年も質を向上させながら継続していきます。

来年一年何をしていきたいか

業務

SRE/Platformerとしての経験を積みたい

現在はいちWeb Developerとしてアーリーな時期のプロダクトにSREの種を植えていっている(IaC,CDなど)状態ですが、片手間ではなく体系的にSREを学び実践していきたいと考えています。(弊社だとこれからUS展開などで開発の方により一層リソースを割かざるおえない)

というのも、もともとドラマーであることも起因しているのか、ビジネス成功可能性を最大化する基盤/開発者の生産性向上への興味関心が何よりも強く、DeveloperとしてというよりSREのスペシャリストとして勝負していきたい思いが強くなったからです。

ですので、グローバルサービスのSREを募集している企業様がありましたらぜひお声がけください。必死でキャッチアップし食らい付き、お役に立つ自信はあります。

プライベート

OSS活動を活発に

最近Goで一つツールを作ったり、terraform-aws-providerやtfnotifyなどへコントリビュートしたりしていますが、この流れをより加速させていきたいです。

qiita.com

qiita.com

具体的には、OSSへのコントリビュートは最低月1で、OSSツールは2ヶ月に一回作成し、50スター以上の皆に愛されるツールを最低1つ作ることを目標とします。

アウトプット改善

質を高める

社内ではreviewしたり壁打ちしたりしている立場ですが、正直自分のアウトプットに関して少し限界が見えているなと思っています。 ですので、この機会にカックさん(有名なブログメンター)のメンタリングを受けたりしながら一旦自分のスタイルを再構築したいと思っています。

英語のアウトプットを増やす

現状、英語用のtwitterアカウントも英語記事用のmediumもうまく活用できてるとは言えないので、これからmediumには最低月2回記事を載せ、twitterも日常の勉強内容をつぶやいていこうと思っています。

登壇を増やす

今年の登壇回数は二回と、お世辞にも多いとは言えませんでした。 記事を量産できたのはいい点ですが、アウトプットの場としてこちらの割合も上げていきたいです。(最低でも月一回LTする)

また、大型カンファレンス(Go Con,SRE Con,SRE NEXT)などのCFPにもプロポーザルをどんどん出していきたいです。国際的なカンファレンスでの登壇を目標に頑張ります。

CS (Computer Science)力の強化

文系卒developerあるあるですが、CSの素養がきちんとあるとは言えない状況です。 将来的にはCSの学位か博士を取っていきたいですが、当面はまずアルゴリズムとデータ構造は螺旋本、ネットワークに関してはネスぺを取得するなどなど書籍や資格勉強で補填していきながら、業務の中でブラッシュアップさせていきたいと思います。

最後に

Global ServiceのSREを募集している企業様、是非お話を聞かせていただきたいです。TwitterのDMからご連絡お待ちしております。

読まれやすい文書を書く/継続して記事を書くコツ

はじめに

どうもお久しぶりです。fukubakaことnariです。

7月に、技術発信を評価され、社内表彰していただきました!(そこからも必ず週1のQiita投稿はキープできている)

その際のfeedbackのなかで、 「どのようなことを意識して記事を書いているのか」 という質問がありまして、Qiitaの限定公開の社内のみで共有していたものをはてブで社外にも共有しようと思い、こちらにも転載しております。

非常に簡易なものですが、どなたかのお役に立てれば幸いです。

読まれやすい文書を書く3つの方法

1.まず大枠のプロット(目次)を打ってから書き始める

## TL;DR
## はじめに
## そもそもxxって?
## どんな人にxxはおすすめか(リコメンドじゃないなら想定読者とかでもok)
## なぜxxをしようと思ったか
## どうxxしたか
### 1.yyyy
### 2.xxxx
### 3.zzzzz
## 終わりに

2.結局5W1Hが重要なので意識して書く

WHOM

  • 誰に向けた記事なのか明記す

WHAT

  • 作った系ならまず何を作ったかを出す
  • 長くなりそうならTL;DR(Too long; didn't read.)を要旨として最初に書く
  • 取り扱うトピックについて、そもそもの説明は最初にサクッと入れる(間口を広げる)(ex:そもそもAWSアーキテクトって? CIって?)

WHY

  • なぜ作ったか、そうしたか、記事を書いているかはなるべく書く

WHEN

  • いつ時点の情報なのかを意識してかいておく(後日訂正の時は特に)
  • 時間軸を意識する 過去の話、今の話、未来の話
  • 未来の話はできれば入れる 今後どう発展させていくか、fixするか

WHRER

  • どういうシーン、どこで起きたことなのかをできれば書く これはおまけ

HOW

  • HowはStepsに分けて書く(ex:1.手を洗う 2.材料をきる 3.鍋にぶち込む)

3.図を多用する

  • 必ず1枚でいいので入れると読者が読みやすくなる
  • draw.io なんかでシステム関係図を起こして載せる
  • マインドマップで事象の紐付きを整理して掲載

継続して記事を書くコツ

  • 完璧主義をやめる 不完全なものをまず出してから、ブラッシュアップしていくスタンスへシフト
  • 自分の思考を整理することになり、feedbackをもらうチャンスになるため、結局自分が得することを知る
  • 一回かいてみて、誰か一人の役に立つだけで嬉しいことを知る
  • とりあえずを増やす ex:だるいけど、とりあえずプロットだけ打とう

モデリングがやりたすぎて、アーキテクチャ勉強会を立ち上げてみた話

はじめに

ご無沙汰してます。 nariです

この度、アーキテクチャ勉強会を発足し、初回はモデリングハンズオンのイベントをconnpassにて立ててみました。

すると、、、、

geekhouse-shinjuku.connpass.com

結構な反響で、今回のイベントの会場であるギークハウス新宿というシェアハウスのキャパがゆうに超えてしまう応募がありました。

 

参加型の設計イベントを探している自分のような人間が他にも沢山いるのではないかという憶測はあながち間違ってなかったみたいです。

  当日のイベント資料はこちら↓

www.slideshare.net

アーキテクチャ勉強会発足のきっかけ

1.モデリングを定期的にやりたい欲が爆発した

上記のツイートのように、BIGLOBEさんの本を技術書店で買い、たまたまその後参加したモデリングハンズオン がBIGLOBEさん主催で、定期的にモデリング会やりたい欲が止まらなくなったためです笑

また、今後はDDDやマイクロサービアーキテクチャなど広範な設計の勉強をしていきたかったため、 このような名前で発足しました。

2.自分の住んでいるシェアハウスが活発にイベント開いていく流れを作りたかった(外向けにも)

私はギークハウス新宿というエンジニアが共同生活するシェアハウスに住みはじめたのですが、思った以上に 勉強会や知の共有がされていない、、

せっかくギークハウス住んでいるんだから、各々が刺激しあいアウトプットしていく集団にしていきたいなという 話を、同じく住人の wami さんと話していて、その契機になればいいなと思ったのも一因です。 (アウトプットするところに知識は集まっていくと思っています。)

当日のイベントの概要

  • テーマは「会議室予約」
  • 言語はGolang
  • 4(5)人一つのチームで別れる(A,B)

私が以下のようなUsecaseドキュメントの準備まで済ませ、そこから名詞や動詞を抜き出して、 ドメインモデルを作っていく流れにしてみました。

# 会議室予約api仕様
## 会議室(マスター)
スサノオ
アマテラス
ツクヨミ
## 予約単位
1h(ex. 1400~1600)
## 予約可能時間
900~1800
## UseCase
- 会議室と時間を指定して、会議室を予約できる。
- 予約に成功すると、予約の詳細が帰ってくる
- 時間可能範囲外の時間帯に予約がくると、エラーを返す
- すでにその時間帯に予約があって予約ができなかった場合、すでに入っていた予約のリストを返す
## test前提
- 5/27 スサノオ 1200-1300,5/27 アマテラス 1300-1500,ツクヨミ 1200-1300と1400-1600の予約が入っている
- 上記の4件だけ入ってる想定で
## testケース
- 5/27 スサノオ 1300-1400の予約は成功し、その予約の詳細を返す
- 5/27 アマテラス 700-800の予約は失敗し、エラーを返す
- 5/27 ツクヨミ 1200-1500の予約は失敗し、1200-1300と1400-1600の予約
## issue
- 予約者マスターができて、adminの人だけツクヨミを予約できるようにする

今回のUseCase外の仕様の話が出てきたら、各チーム別でissueとして管理することで、 議論の発散を防ぎました(issueは追加要件として後日採用)

当日のイベントの予定

  • 自己紹介(1810~1820)
  • ユースケースの確認(1820~1830)
  • モデリング開始 名詞と動詞を抜き出す 状態遷移図 クラス図(1830~1930)
  • 現状のモデルシェア、チームでfeedback(1930~40)
  • testcase通る想定まで実装とモデリング行き来(1940~2040)
  • KPT(2040~2050)
  • KPTとissueの共有(2050~2100)
  • 懇親会(2100~2200)

当日の様子と各チームモデルとKPT

Aチーム

f:id:st5818129:20190528015441j:plain f:id:st5818129:20190528015805j:plain

Bチーム

f:id:st5818129:20190528015754j:plain f:id:st5818129:20190528015836j:plain

それぞれのissue

f:id:st5818129:20190528015825j:plain

(他にも状態遷移図や業務フローなど色々図を作成したのですが、写真を撮り忘れました、、)

反省点

  • それぞれのDDDの理解段階が違うことを顧慮すべき。最初にそもそもDDDとは、モデリングってどの層の話か、頻出単語集くらいは共有すべき
  • testcaseやdomain層以外の実装を終わらせておいて、スムーズにdomainと実装を行き来できる状況が作れなかった
  • 少しスケジュールを詰めすぎた 休憩をもうけるべきだった
  • 図で表現する力の弱さを実感した 積極的にUMLや状態遷移図などで表現する癖をつけるべき

終わりに

初回は色々と反省点も多かったですが、こういった性質のイベントは長い目で見るべきなのかなとも思いました。

そして、やっぱりみんなでわいわい設計を実際しながら議論するのは楽しい!!!
(僕やその他酒好きは、懇親会に先立ち酒駆動設計してました笑)   

ここから実装や仕様追加しながら、みんなで仕様変更に強いdomainを育てる感覚を養っていきたいと思います。 (とりあえず、会議室予約システムというお題は継続する予定。簡単そうで意外と考慮すべき点が多く、かつ会議室と予約どっちをコアドメインにするかで違いが出る、良いお題でした。)

次回以降もレポ書いて、モデリング力を磨いていく仮定を記録していこうと思いますので、今後ともチェックしていってください。  

2週間に一回やっていく予定なので、参加型の設計イベントに参加してみたい、あなたのご参加もお待ちしております !  

現状少人数ですが、知見が高まれば将来的に大勢で会議室を貸し切って、モデリング布教活動もやっていきたいですね。    

1週間でLPICの基礎が学べる本 書評

目次

はじめに

どうもご無沙汰してます。
服バカエンタメエンジニアのnariです。
最近は、GolangデビューしたりAWSアーキテクトのアソシエイトとったりしてました。

さてさて、今回はというと、

kuwana-kb.hatenablog.com

この書評が素敵だったので、私も真似して自分の学習の記録として始めることに
(kuwanaさんみたいに、概念の説明とかは多分書いていかないかな?)

www.amazon.co.jp

1行で言うと

1週間でlinuxOSの歴史と仕組み、linux環境作成、基本操作などについて一通り学ぶことができる本

経緯

アプリ開発などでざっくり一通りコマンドは抑えたが、漏れや理解が不十分なところがたくさんあったので 会社にあったこれをサクッと一周終わらせることに

内容紹介

良かった点

  • 全体的に1ページの情報量が多すぎず少なすぎないため、学習時の負担が少ない
  • 図もふんだんに入っているため理解が進みやすい
  • 注釈の説明がしっかりしているため、なぜが常に解消された状態で知識を落とし込める

改善点

  • コマンドライン引数、ストリーム、HTTPサーバなどのお話も少しあるとより良い
  • ShellScriptに関してもう少しだけ踏み込んでくれると嬉しかった

こんな人にオススメ

  • なんとなくでコマンドを叩いてしまっているサーバーサイドビギナーエンジニア
  • 他の学習との兼ね合いで、まずはlinuxに必要最低限の部分だけにリソースを割きたい人

逆にがっつり原理原則からLinux学びたいんじゃ!って人は以下の本がオススメらしいよ(先輩に聞いた)

標準テキスト CentOS 7 構築・運用・管理パーフェクトガイド

新しいLinuxの教科書

得られたもの

  • ディレクトリのtmpとかbinとかvarとか、ふわふわした認識でいたが、役割を整理(FHSの学習)
  • homeとルートディレクトリをフィーリングで区別して作業していたが、ここで確固たる理解
  • ハードリンクとシンボリックリンクを差別化できた rmがiノード番号との関係性を断ち切っているだけだと理解
  • アクセス権とパーミッションについて整理
  • viコマンドの整理
  • リダイレクトとパイプを理解
  • 環境変数とシェル変数の違い、プロセスとジョブの理解
  • シェル、パッケージ、ファイルシステムの基礎

今後

コンパクトにサーバサイドの人間の必要最低限のlinuxに関する知識がつく一冊で、とてもオススメ。
学習していてもっと深くリナックスが学びたいなあと言う思いが募った。

得た知識をベースに、カーネルやOSの仕組みの理解を深めていくこともしたいが、
とりあえずはShellscriptの勉強を進めて実務中心に具体の部分に多く触れて精通していきたい。

時期が来たら、入門UNIXシェルプログラミング やって、 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 もやっていってシェルやカーネルのもう少し深いところまで学んでいく
すぐに取り掛かるわけではないけど近々必ず !
ギークハウスの住人がどっちも持ってたのでやってみるという感じ)

次の書評予定

みんなのGo言語【現場で使える実践テクニック】 を予定

今の所最高に面白く、かつためになります。

== 追記 2019/03/24 ==

私の大学の学部の先輩からのアドバイス!みなさま参考にしてください

Wano株式会社に入社しました

どうも、服バカことnari (@ fukubaka0825) です。

 

この度、2ヶ月弱の転職活動の末、

2019年1月31日付けで

新卒で入った某大手金融SIer会社を退職し、

Wano株式会社

お世話になることとなりましたので、そのご報告となります。

(Wanoはtunecore Japanなどの自社開発サービスで、サブカルチャー全般の 表現者支援を行っている、グループ全体で90人くらいの恵比寿のWeb系ITベンチャーです。 )  

 目次

まずなぜ転職

一言で行ってしまえばモダンな環境で手を動かしたいから、なのですが

詳しくは、以下のブログ記事をお読みくださいませ。

fukubaka0825.hatenablog.com

どう転職成功させたのか

上記のツイートに集約されます。

  • 25歳、IT系企業からの転職である

  • SIerからの転職は、「完全脱SIerマニュアル」など再現性の高い情報が豊富

である事から、正直Web系への転職活動で苦戦はしませんでした。 (準備段階から合わせて2ヶ月弱で自社開発サービス会社3社から内定いただきました。)

途中でQiitaがバズったりしました

qiita.com

基本的にProgateなどのサービスは一切しようせず

活動を始めた2日目にポートフォリオを作り始めました。 (当然全然わからないので、調べまくりながら作成)

これが最短で転職成功した一つの要因かなと思ってます。

その際は以下の健太さんの動画を参考に作成しました。

www.youtube.com

当初は自分の転職活動をnoteにまとめようと思っておりましたが、

SIerからの転職において再現性の高い有益な情報が溢れている今、

noteで大げさに体験談をまとめるという事へのニーズを正直感じなかったため、やめました

下記のツイートも参考にしてください。

転職活動は、自分のできる事、やりたい事、価値観や軸の部分を整理する方が大変で、

自分にとって重要でもありました。

転職活動の軸 

モダンな環境でプログラミング、設計が行える

自分自身の成長のためにも、わくわくしながら働き続けるにも

この要素は必須でした。

エンジニアの範疇を超えて、企画立案の部分から関われる

まずは一部の機能でもいいので、自分で0から提案して

運用の部分までワンストップで面倒を見る経験がつめる環境を求め、

自社開発サービスを持つベンチャーを中心に、Wantedlyでエントリーしていました。

なぜWano株式会社か

そもそもWanoってどんな会社

「日本から世界へと発信する」

「独創的なプロダクトとサービスを生み出し続ける」

この二つをミッションに、Webサービスサブカルチャー表現者支援を中心に行う会社です。

www.wano.co.jp


多くの自社サービスを展開していますが、代表的なのはTunecore Japanというサービスです。

このサービスの内容としては、誰でも自分の楽曲を世界中のストアで販売・配信できるというもので、

iTunes、AppleMusicなど40以上のストア、120カ国以上に一括配信が可能みたいです。


私は、このサービスの動画版であるVideo Kicksのエンジニアとして採用されました。

現在は、Tunecore Japanのサードパーティとして、楽曲のMV(ミュージックビデオ)

を上げる事ができるサービスとして提供されていますが、将来的には独自のプラットフォームとして

映画などの長編のコンテンツもあげられるサービスになっていくようです。

軸である2つを満たす

私が入る事になるVideo Kicksチームは、aws各種サービスなど新しい技術をガンガン使っていき、

go言語でマイクロサービス開発を行っているようです。

(プルリクレビュー、テストを書く文化もきちんとある)

また、

  • 自社開発サービスを複数もち、VCからの出資を一切うけていない

  • 自分が関わるVideo Kicksというサービスは立ち上げから1年程度しかたっていないアーリー期である

以上から、自由にサービスを企画の部分から作っていける環境があると感じました。

とにかくWantedlyのスカウトの文章が素敵だった

   実は、1月中旬までは別の会社に行くつもりでした。

他社の内定受諾返答期限が迫る中、

ある日WanoからWantedlyにてスカウトメールが届きました。


私はWantedlyで20通ほどスカウトメールをいただいておりましたが、

正直その多くがテンプレート文で殴ってくるタイプのくそ◯ファッキン企業ばかりでした。


ですので期待せずにWanoからのメールを読んでいると、どうやら他のスカウト

とは違い、自分のブログや経歴を読み込んで送ってきてくれているようでした。

しかも、わたしのこれからやっていきたいが、Wanoであればどう実現できるか

まで具体的にサジェストされている、それはそれは素敵で心揺さぶる文章でした。

こんな文章が打てる人間と仕事がしたいと、考えるより先に会いたいと返信していました。


そこから翌日にお会いし、他社の回答期限も迫っているということで

すぐに技術テストを受け、週明けには内定を貰う

というかなりスピーディーな採用過程で、そこにも好感を抱きました。

海外常駐経験が積める可能性が高い

Video Kicksは海外展開していく事がほぼ確定しているため、

自身が前職から望んでいた海外拠点常駐の経験を積む事ができるというのも

大きな要素でした。

カルチャーに貢献していける

自分も傾倒してきたファッション、音楽、映像といったサブカルチャー

に、表現者支援サービスなどを通して貢献していけるというのは

自分のルーツのベクトルも生かしていけるということで

かなり心惹かれる要素でした。

今後Wanoでなにをしていきたいか

実装力、設計力をとにかく高める

Web系業界の経験がない状況なので、とにかく

goやtypescriptを中心に業務の中で実装力を磨き、

設計が技術選定の部分も低レイヤーの部分から、アプリのUIの

部分まで面倒がみれるエンジニアになっていきます.

(まずはバックエンド)

video kicksの機能提案および新プロダクトの提案

アーティストからの生の声から、こんな機能あったらというものを

提案していったり、確実にニーズがあると思えるサービスを

ボトムアップで提案していけるような、ビジネスサイドの感覚も

あるエンジニアになっていきます。

海外展開支援、拠点に常駐

ロサンゼルスを放浪していた時、副業として自己表現を行っている

(Uberの運転手はだいたいバンドマンとか役者でした)人間の

多さに驚きました。日本国内でなく、そういった人々も支援していけたらなと思っています。

Wanoに優秀なエンジニアが入ってくるエントリーポイントになる

Wanoの仲間になって数日しかたっておりませんが

以下のようにエンジニアにとってかなりいい環境だと思います。

  • 開発環境の要望をかなり聞いてくれる

    僕は27inchの4Kディスプレイのデュアルモニター環境を要望していたら

    入社日には必要な周辺機器が全て揃っていました。

  • フリードリンク(コーヒーも淹れ放題)

    前職からは考え(以下略

  • 新しい技術をどんどん投入していける環境である

    aws各種サービスをガンガン投入し、slackで集中管理している様は

    わくわくしましたし、これからが楽しみです。


video kicksをエンジニアサイドとして発信し、

優秀でカルチャーフィットする技術者がはいってきてくれれば

技術的刺激もいっそうもらう事ができ、技術的課題も一緒に解消していけ、

結果としてより良いサービスで世の中を面白くしていけると思います。

(動画データのエンコーディング手法や、扱い方のベストプラクティスの

探求が課題のようです)


これからWano,Video Kicksチームで働く事の

魅力や課題を、自分自身で経験しながら発信していけたらなと思っています。

今後個人としてなにをしていきたいか

  • 多言語の実装力、設計力、インフラ及びsreに関する知見を身につける

  • 英語力を高める

  • 自主プロダクトで自己表現支援

  • 様々なコミュニティで交流、発信、LT

  • 都内ギークハウス移住の勧め

  • 技術書典で本も出版

などなど語りだせばきりがないですが、これは入社エントリなので、一つだけ詳しく語っていきます

SIモデルの檻の中の住人を、外の世界につなぐ

なぜやるか

転職するにせよしないにせよ、転職活動を通して視野を広げ、自身の

歩んで来た道、スキル、価値観や考え方を相対化し、整理と可視化しておくというのは

SIモデルの問題点を中から解決していくにあたっても有効だと考えているからです。

(終身雇用モデルが破綻し、個の時代に突入した現代においてはなおさら)


気づいた頃には歳的にもスキル的にも転職できないところまで来ていた、、なんて

人が一人でも減るよう、SIerやSESの人々の視野が広がり、価値観が

社内の文化に染まりきってしまわないようにしていきたいです。

どうやるか

まずは周りの同期の悩み相談からやっています。

既存のSIモデルの問題点と向き合い、なにかしらのアクションを

起こし、多くの人が納得いく幸せなキャリアを送れる世界

そんな世の中への一助となればと、悩める周囲の人間から

変えていっています。

また、転職LTや、SNSで相談に乗るなどの活動も地道にやっていきます。

すでに退社パイオニアとして、相談してきた同期数名を

社外の世界の景色へとつなぎました。


ただし、知った後どうするかは本人次第ではあります。

僕はあくまで、新卒の時になんとなくでSIerに入ってしまった自分の

ような人間の視野を広げるきっかけ作り、環境を変えたいのなら

その背中を押す事をしていければと思っています。

終わりに

Webサービスで、エンターテイメント業界をよくしていきたい、

人々の生活を豊かにしていきたいと言う同士や企業の方

いらっしゃいましたら、情報交換がてらお話できれば嬉しいです。


また、Wano株式会社では、絶賛エンジニア募集中ですので

エンターテイメント業界をよくしていきたい、カルチャーが大好きな

エンジニアの皆さん、気軽にオフィスに遊びに来てください。

(興味があれば気軽に私のツイッターまでリプ・DMください)


また、海外エンジニアと交流できる場も求めています。

おすすめのコミュニティがありましたら教えてください。


転職相談も、Twitterのリプ・DM等でお待ちしております。

Video KicksやWeb系転職に関するLTの依頼もどしどし募集しておりますので、

よろしくお願いいたします。

話題のフィンテックサービス「VALU」小川代表が語る、仮想通貨の未来とこれからのエンジニアキャリア に参加してきた

仮想通貨、ブロックチェーンの未来について、

株式会社VALU取締役の小川さんのおはなしを聞いて参りました。

去年の12月のイベントですが、おそばせながらまとめさせていただきます。

 

graspy.jp

 

目次

 

 

1.VALUの話

VALUって?

夢を追いかける人を支援するがコンセプトの新しいフィンテックサービス

自分のトークンコインを発行でき、資金調達できる(トークン発行、売買)

ビジネスモデルは売買手数料、分轄手数料、投げ銭手数料

ローンチは2017年5月

大炎上、しかしやめようと思わなかった

継続企業の前提がない、本源的価値がない(人間は死ぬ)として炎上

それでもVALUEをやめようと思わなかった

  • なぜか?

  現状

  1.日銀お金の供給をコントロール→お金をすりまくっている
   →しかし、所得は上がってない、分配されていない
  2.r > g   資本収益率>経済成長率
   →いまの時代は金融商品に投資するのが一番効率的
   →金融街にのみお金が集まる

  この現状に対して、VALUで富の再配分がしたい

  • どうやって?

  現状

  ・信用を資金にできるライン:上場から 

  それを下げた!個人でも上場

  →下げた領域で、何か生まれるんじゃないか(ex.地方のコミュ、NPOなどの信用をトレードすることが生まれてくるんじゃないか)

  →信用を資金化する手段を増やすことで、富の再配分をする

  クリプト経済!問題は多いが、楽しんでいきましょう 

これからやっていきたいこと

  1.  VAは情報発信していくことで変動する。ここのレパートリーを増やしていきたい。 (exストーリーとか)
  2. 多く持つことと長く持つことの設計がない(株式にはある)⇨色をつけたい VA持ってないと得れない体験の創出

 

2.VALU発足に至るプロセス

VALU CEO小川さんのバックボーン

 お金の仕組みに興味があった。

    お金は人類最大の発明

  ・価値や信用を代替できるもの

       ・1970年〜 国の信用力で決まる

 ビットコインと出会う

 発行元がない仕組みに心酔。フリーランス

 →しかし仕事が少ない!年収半分へ

 →2016年、年収戻す 渋谷に引っ越す

 →しかし、クレジットカードも作りにくい 信用がない

これからは個の時代

今の信用=大企業に勤めているetc

しかし、これからは個の時代

    この時代のお金、信用を考える→VALU発足

3.エンジニアの将来

目標を立てる、現在の能力の把握、目標達成のための武器が得れるところへ行く の繰り返しをすべし

以下は小川さんが進んできた具体的なキャリア

 

将来起業したい、シリコンバレーに行って観たい(ソーシャルネットワークの影響)

→ しかし、ビザ問題およびCS出身じゃない問題

→まず日本の会社でエンジニアになろう(グリーとかDENA入って海外展開目指す)

→手持ちは新卒ブランドのみ、なので日報にSFに行きたいって毎日しつこく書き続けた

→上の人々の議題に乗り、なんとかSF赴任!

→4億のアプリの運用(リードバックエンド・エンジニア)

 お偉いさんとのコネを得た

→ラブホ事業の立ち上げ(リードバックエンド・エンジニア)

 →コネフル活用 堀江さんとPARTYと知り合って、VALU発足

一番怖いのは途上国の海外勢、どう戦っていく?

 1.日本人の武器はゲームの経験値 UIUXに強い

 海外の人はUIUXを伝えるの難しい(発展途上国)

 先進国が勝ってるのそこくらい

   2.先行者利益を狙う

  仮想通貨・ブロックチェーン・AI・ VR ・ARとか

  思いっきり飛び込むのも手なのでは?

 (ブロックチェーンめちゃくちゃUXがあるのが課題、

  プロトコル戦争の時と同じ?)

4.質疑応答

VALUどうなっていきたいか

 VALUはアマゾンになりたい

 グーグルとアマゾンは使いやすくしただけ、ユーザー思考がより大事に

  資本主義への懐疑とユーザー思想

 →どんどんラップしていけば良い。ユーザーが使うかが大事、長期のUX 理想の姿を追求

未経験がブロックチェーンエンジニアになるには

walletを1ヶ月を作る、中小企業に売り込む→1年か2年本気で働く

そのスキルをもとに頑張る!

どうVALUスケールさせたか

3つの要素が勝因

1.運

2.ビットコイナーに受ける仕様にした

3.インフルエンサーに広めてもらえた

ブロックチェーンが普及する分野は

今まで価値がつかなかったもの 定量的にあらわせなかった分野

(ex環境価値)

可視化されなかった価値を可視化していくと思う

ICO案件についてどう思うか

詐欺案件が減っていくには以下の二つしか手段がない

1.規制

2.個人のリテラシーをあげていく

 

AIの力などでよりパワフルになるのでは?

(アマゾンを個人が評価とか)

5.感想、参考になったこと

個人的に日本人の武器はゲームで培ったUI,UXの視点というのは目から鱗だった。

(小学校の頃は毎日ゲームしかしていなかったので、そのルーツに少し目を向けてみようと思う)

資本主義へのアンチテーゼと圧倒的ユーザー主義。

この両輪でスケールしていくVALUにはこれからも着目していきたい。