ID:7914さん

## 0. このプロジェクトの記載で何が伝わってほしいか * 要件定義からリリースまで、プロジェクト全体をリードできること * これを支える前提として、フロントエンド・バックエンド両方の高い技術力と経験を有すること 以下でこれらを示します。 ## 1. プロジェクトの内容と課題 有料契約ショップ数日本一のネットショップ作成サービス「カラーミーショップ」の常時 SSL 対応。 https://shop-pro.jp/ssl/ ### チームの規模 * プロダクトマネージャー x 1名 * ウェブアプリケーションエンジニア x 5名（私はここに含まれるが、プロダクトマネージャーが兼任で多忙であったため、プロダクトマネージメントのほとんどを私が行った） * インフラエンジニア x 1名 * デザイナー x 1名 ### 課題 制約として下記があった。 (1) SSL 証明書の発行に 1分ほどかかること * ショップの独自ドメインの SSL 証明書を発行する前にフィッシングサイトチェックがある。これはグローバルサイン API にリクエストを送ることで行い、レスポンスに 10〜20秒かかる * ドメイン認証もグローバルサイン API にリクエストを送ることで行い、同じく レスポンスに 10〜20秒かかる * SSL 証明書を発行後、証明書インストールに 30秒かかる（ただしこの点については後に改善されて 1秒以内で実現されるようになった） (2) ショップ数が多いため、SSL 証明書の更新に工夫が必要 * カラーミーショップで独自ドメインを利用しているショップ数はおよそ 30,000 ショップ * SSL 証明書の有効期限は31日（毎月1回はそれぞれの証明書の更新が必要） * 独自ドメインのショップすべてが常時 SSL を利用すると、1日1000件の証明書更新処理が必要になる したがって、 * (1) の制約があっても、良い UI/UX をどう実現するか * (2) の条件があっても、運用していけるアーキテクチャ がキモだった。 ## 2. プロダクトマネージメントとして プロジェクトを通して実現したいことと、その成功を測る指標を定めた。 (1) ショップの SEO などに貢献し、カラーミーショップのプロダクトとしての魅力を上げたい。そのために「常時 SSL を利用するショップ数」を最も重視する指標と決めた (2) 「常時 SSL を利用するショップ数」が損なわれない限度に、独自ドメインショップの常時 SSL は別途利用料金をいただいて、事業の売上に貢献することに決めた (3) (2) を実現するために、価格設定には「感情価格決定法」を用いた * 参考）[一瞬でキャッシュを生む!価格戦略プロジェクト](https://www.amazon.co.jp/dp/4478502218?_encoding=UTF8&isInIframe=0&n=465392&ref_=dp_proddesc_0&s=books&showDetailProductDesc=1) プロジェクトの後半には、リリース日を重視して機能を切り捨てるか、リリース日を延ばすかの決断が求められることが多いため、「何を重視しないか」も定めた。 (1) 「常時 SSL を利用するショップ数」を上げるためには、できるだけ早くリリースして、競合よりも先にプロモーションをかけることが重要。そのためにレアケースへの対応は重視しない（5%未満のケースへは問題となったときに個別対応する） (2) ただし、お金（利用料金）が絡む問題については数が少なくても、ユーザー体験に大きく影響し、ソーシャルなどを経由して「常時 SSL を利用するショップ数」に影響が及ぶことも考えられるため、5%未満のケースでもリリース前に対応を済ませておく ## 3. UI を定義した プロトタイプを使ったユーザビリティテストをしながら UI を改善していき、SSL 証明書の発行に数十秒かかってもユーザー体験を損ねない UI を定義できた。 （プロトタイプの作成はチームのデザイナーに依頼した） また、このあたりの話をイベントに登壇して話し、会社のプレゼンス向上に貢献した。 * [第6回ペパボテックカンファレンス 〜 もっとおもしろくできる、そして……伝説の夜 〜 開催レポート - ペパボテックブログ](http://tech.pepabo.com/2016/09/27/pbtech-6th-report/) の「(2) 開発フローの中のレビューポイント」 ## 4. 全体のアーキテクチャを策定した SSL 証明書のインストールにかかる時間をできるだけ短くして、良い UX を実現したい（30秒もかけたくない）と考えたため、SSL 証明書を ngx_mruby で動的に適用するようにした（このあたりは詳細はインフラエンジニアに任せた） * [第6回ペパボテックカンファレンス 〜 もっとおもしろくできる、そして……伝説の夜 〜 開催レポート - ペパボテックブログ](http://tech.pepabo.com/2016/09/27/pbtech-6th-report/) の「(1) SSLと仲良くするやり方」で少し触れた。 SSL 証明書発行を担うサーバーから、SSL 証明書適用を担うサーバーへは API を通じてやり取りするようにした。 また、上に書いた制約のとおり、1日1000件の証明書更新処理を仮に直列で行ったとすると 1000件 x 70秒 = 19時間以上かかるという試算をしたため、利用ショップ数が増えても破綻しないようにするには、処理を並列で実行する必要があると考えた。より具体的には、 * ジョブキューに証明書更新タスクを突っ込んで、複数のジョブワーカーが並列で処理する * ジョブの粒度を適切に分解することで、証明書発行のロジックを証明書更新でも再利用できるようにする * ジョブが途中でこけた場合に、こけたジョブを再実行すれば良いようにしておく というアーキテクチャにした。 ### OSS（gem） グローバルサイン API とのやり取りを行うクライアントは、他のプロダクトでも利用する予定があったことと、できるだけコミュニティに貢献できるようにするため、OSS にした。 * [pepabo/global_sign: A Ruby interface to the GlobalSign API.](https://github.com/pepabo/global_sign) ### ドキュメント作成とテーブル定義 チーム内で共有するため、いくつかのドキュメントを作成した。 * SSL 証明書発行のシーケンス図（自分以外の人が編集できるよう [js-sequence-diagrams](https://bramp.github.io/js-sequence-diagrams/) を使った） * 主要モデルの状態遷移図（自分以外の人が編集できるよう [flowchart.js](http://flowchart.js.org/) を使った） * SSL 証明書に関わるテーブル定義（ActiveRecord のマイグレーションファイルを作成） ## 5. 実装 プロジェクトを通じて若手の成長を促進させる目的があったので、実装の主要部分は若手に任せた。私が行ったのは下記。 * gem を作成したことがない若手に gem 作成を任せた。お作法的なところや、gem を利用する側からの視点を指摘するなどした * [プルリクエストのレビューの一例](https://github.com/pepabo/global_sign/pull/1) * 上記アーキテクチャの要件（ジョブの粒度を適切に分解されているか、ジョブが途中でこけた場合に、こけたジョブを再実行すれば良いようになっているか等）が守られているかという観点からコードレビュー * 非同期処理の例外処理や UI まわり等、難易度が高い箇所のペアプログラミングまたは実装 ## 6. プロジェクト全体を通して プロジェクトを * (1) プロダクトを定義するフェーズ * (2) プロダクトをつくるフェーズ に分けたとき、「(1) プロダクトを定義するフェーズ」のほうにだいぶ力を注いだ。 その背景としては、私たちのチームが「(2) プロダクトをつくるフェーズ」は得意だと自信が持てるようになったが、「(1) プロダクトを定義するフェーズ」はまだまだ自信がもてるやり方が確立できていなかったため。そしてビジネスとして、そこがうまくできるようにならないと成功する可能性が小さいため。 自分たちのチームだけでなくペパボ全体がそうであったし、業界全体もそのような気運があったと思う（この頃、プロダクトマネージャーという用語が盛んに使われるようになったと感じている）

## 0. このプロジェクトの記載で何が伝わってほしいか フロントエンド・サーバーサイドの両方において、技術選定、設計、実装できる力を有すること。 以下でこれを示します。 ## 1. プロジェクトの内容と課題 有料契約ショップ数日本一のネットショップ作成サービス「カラーミーショップ」のカートをリニューアル。 https://shop-pro.jp/newcart/ 10年続く、このサービスの主要部分は PHP で書かれている。これを AngularJS を用いた SPA と Rails を用いた API でリプレイスするというもの。 ### チームの規模 * プロダクトマネージャー x 1名 * ウェブアプリケーションエンジニア x 5名（私はここに含まれる） * デザイナー x 1名 * インフラエンジニア x 1名 ### 課題 ネットショップのカートなので、高いコンバージョンレート（CVR）を実現することがプロダクトの価値に直結するため重要。 10年続くサービスなので、アプリケーションコード（PHP）や DB スキーマがレガシーなものになっている。これをサーバーサイドの Rails API でうまく吸収し、クライアントからは利用しやすい（RESTful な）API にする必要がある。 ## 2. 技術選定 カラーミーショップにはこのプロジェクトよりも前に API を中心にしてリプレイスしていく構想があり、Rails を用いた API の基礎はあった。このプロジェクトではそれを用いて、フロントエンドを SPA にすることにした。 それは、高いコンバージョンレート（CVR）を実現するためには優れた UI を提供する必要があり、速いレスポンスを実現できたり、複雑な仕様を実装には SPA が適していると考えたため。 また、カートはショップの商品ページ等と異なり SEO 対策する必要がなく、サーバーサイドレンダリングしなくても問題ないと判断したため。 さらに、下記の理由により AngularJS を選定した。 * フロントエンドはフォームがメインなので、フォームのバリデーションなどが実装しやすいフレームワークを選びたかった（そして AngularJS はフォームの実装がしやすい） * また、当時 JavaScript のライブラリは新しいものが出てきては消えるという時代だったので、ライブラリを次々に乗り換えなければならないということを避けたかった。したがって、AngularJS が提供してくれる公式ライブラリ群を使っておいたほうが安心だと考えた * そして、不具合によって商品が購入できない、ということを避けるため、きちんとテストコードを書きたいと考え、テストが書きやすいことも選定基準のひとつにした ## 3. 見積りと計画づくりの技術 キックオフの前後に（アジャイル開発で有名な）永和システムマネジメントから高橋健一さんが転職されてきて、チームに、見積りと計画づくりの技術を叩き込んでくださった。 したがって、下記にあるような見積りと計画づくりについては、私も他の人に伝えられる程度に身につけている。 * [第1回ペパボテックカンファレンスで見積りと計画づくりについて発表しました | けんちゃんくんさんの Web日記](https://diary.shu-cream.net/blog/2015/04/19/pepabo-tech-conference.html) ## 4. UI 定義 このあたりは私はメインではなく、デザイナーと、デザイナー出身のプロダクトマネージャーが、プロトタイプを用いたユーザビリティテストを行いながら進めていった。 先進的な UI にしたため、被験者が途中でどうしたら分からなくなって買えない、という事態が発生し、ユーザビリティテストの重要性をチームで学習した（これは「買えないカート事件」として、いまでも語り継がれている） ここで学習したことが別記「カラーミーショップの常時 SSL」の開発に役立てられた。 ## 5. 決済まわりの設計と実装 ウェブアプリケーションエンジニア 5名全員が Rails を使えるという贅沢なメンバー構成だったが、その中でも私が最も設計力が長けていたので、決済まわりの設計と実装を行った。 * 決済のシーケンス図を作成 * クレジットカードの 3D セキュアが複雑なので、その部分を特に書きたかった。それがなければシーケンス図を作成するほどではなかったと考えている * モデルの状態遷移図を作成 * テーブル定義（ActiveRecord のマイグレーションファイルを作成） 最も力を入れたのは、**決済方法が今後増えていっても、複雑になりにくい設計** にすること。 というのも、決済方法は 30 近くある。リプレイス前のコードでは、これをひとつのモデルが巨大な条件分岐のなかで行おうとしていたため、当該モデルは 1万行近くに達していた。 これを、デザインパターンのストラテジーパターンを用いて、同じように扱える決済方法モデルを増やしていく、という設計にした。 ## 6. OSS（gem） 決済方法の一部は GMO グループ企業の API を使うため、そのクライアントを gem として切り出し、再利用可能にした（他のプロダクトでも利用する予定があった） * [pepabo/active_merchant-epsilon: Epsilon integration for ActiveMerchant.](https://github.com/pepabo/active_merchant-epsilon) 私のプルリクエストの一例。 * [3D セキュア決済（クレジットカード）ができるようにする](https://github.com/pepabo/active_merchant-epsilon/pull/43) * [コンビニ決済ができるようにする](https://github.com/pepabo/active_merchant-epsilon/pull/2) * [EpsilonGateway の中をクラス分割したい](https://github.com/pepabo/active_merchant-epsilon/pull/57) 特に注目していただきたいのは、3つめの [EpsilonGateway の中をクラス分割したい](https://github.com/pepabo/active_merchant-epsilon/pull/57) というプルリクであり、プルリク冒頭に書いているとおり、ガシガシ実装するだけではなく、コードがカオスになって開発速度が落ちてしまうことを防ぐ、という働きも適宜行うことができる。 > 解決したい問題 > > 今後、決済方法を追加していっても、カオスにならないようにしたい > このまま EpsilonGateway に決済方法をどんどん追加していくと破綻する > 例えば、リクエストパラメータの組み立て（billing_params）メソッドについて、決済方法が増えると巨大な case 文が出来上がってしまう ## 7. フロントエンド 社内初の SPA 事例だった。私はプロジェクトの初期は主にサーバーサイド（前述の決済まわりの設計と実装）を担当し、途中からどちらかというとフロントエンドをメインに担当した。 チームメンバーの入れ替わりは珍しくなかったので、属人化を避けるために、できるだけトリッキーなことをしない、世の中のスタンダードであろう実装方法を心がけた。AngularJS が公式で提供しているライブラリ以外のライブラリを使うときはできるだけデファクトらしいものを選んだ（もちろん要件を満たすか否かもみる） また、新しい人がジョインしたときにも安心して開発を進められるよう、自動テストは充実させた。このあたりは AngularJS が用意してくれているテストフレームワークが便利だった（[Karma](http://karma-runner.github.io/1.0/index.html), [Protractor](http://www.protractortest.org/#/)） その他、工夫した点としては、API 側の実装が終わっていなくても、フロント側の実装を進められるように、API を [interpol](https://github.com/seomoz/interpol) を用いたスタブサーバーとして起動できるようにした。具体的には、API のエンドポイントの定義を JSON スキーマで記述して、サンプルレスポンスを返すようにした。 （JSON スキーマは API のバリデーションにも用いた） ## 8. プロジェクトの成果 > ネットショップのカートなので、高いコンバージョンレート（CVR）を実現することがプロダクトの価値に直結するため重要。 という課題に対し、旧バージョンのショッピングカートに較べて 4% 高いコンバージョンレートを実現できており、現在も引き続き改善していっている。

## 1. プロジェクトの内容と課題 日本初の Vue.js のカンファレンス「Vue Fes Japan 2018」の開催。 ### チームの規模 コアスタッフは私を含めて 20人ほど。当日のボランティアスタッフが 40人ほど。 ### 課題 開催主体の Vue.js 日本ユーザーグループがまだ一度もカンファレンスを開いた経験がなかったこと。 ## 2. やったこと Vue Fes のコンセプトを決めるところから、Web サイト作成、当日の司会などを行った。詳細は下記にまとめた。 - [Vue Fes Japan 2018 ふりかえり - 彼女からは、おいちゃんと呼ばれています](https://blog.inouetakuya.info/entry/2018/11/30/221934) ## 3. 同様の課題を抱えるコミュニティに対して Vue.js 日本ユーザーグループとして Vue Fes Japan 2018 は初のカンファレンスだったので、一体何から準備を始めたら良いかとても不安だった。同様に、カンファレンスを開いてみたいんだけど、躊躇しているコミュニティの人たちに対して、私たちが得た知見を共有することで背中を押したかった。 という背景があり、カンファレンスの主催についてのナレッジを交換するというイベントを開催した。 - [カンファレンス主催 Casual Talks 1 を開催した - 彼女からは、おいちゃんと呼ばれています](https://blog.inouetakuya.info/entry/2019/01/30/204335) ## 4. Vue Fes Japan 2019 [Vue Fes Japan 2019](https://vuefes.jp/2019/) を 2019年10月開催に向けて準備中。 Web サイト班のリーダーとして活動しているが、属人化を防ぐために、できるだけ自分はコードを書かずにプロジェクトマネジメントやコードレビューに注力している。

## 0. このプロジェクトの記載で何が伝わってほしいか やっていきの力があるということ。 以下でこれを示します。 ## 1. プロジェクトの内容と課題 リブセンス全社のチャットツールを HipChat から Slack へ移行させること。 ### チームの規模 私を含めて 5人。社内の有志にて構成。 ### 課題 社内に Slack へ移行したいというニーズはあったが、エンジニア以外の職種の人で、新しいツールへの移行に心理的抵抗（不安）を抱えている人が多い（ただし、人から聞いた話だったので、自分で確認できていない） ## 2. ドキュメントと説明会の実施 HipChat から移行 Slack へ移行することのメリットやデメリットを整理して、全社のドキュメントにまとめた。 移行のスケジュールと、移行の前後でどのようにフォローアップするかを、数回の説明会を実施して伝えた。 このようにして、社内の心理的抵抗が減少するように努めた。 ## 3. HipChat のメッセージデータの移行 HipChat でやり取りしたメッセージのデータを Slack へ移行するニーズがあった。 HipChat のデータを移行するためのツールを、OSS ツールとして作成して対応した。 - [livesense-inc/hipchat-exporter: Export the history (messages) of rooms from HipChat.](https://github.com/livesense-inc/hipchat-exporter) なお、なぜツールを作らなければならなかったのかは下記にまとめた。 - [なぜ本ツールを作成するのか？ · Issue #1 · livesense-inc/hipchat-exporter](https://github.com/livesense-inc/hipchat-exporter/issues/1) ## 4. プロジェクトの成果 Slack 上で賞賛されるべきアクションが報告されたら、それに対して、然るべき絵文字でリアクションされ、よい行いに対するモチベーションが高く維持されたらよいと考えていた。 （HipChat は絵文字をメッセージとして投稿することはできるが、メッセージに対して絵文字リアクションはできない） また、絵文字リアクションにより会話が盛り上がり、メッセージ数の増加によるコミュニケーション増も期待していた。 Slack へ移行して「メッセージ数 + 絵文字リアクション数」の経過を 3か月間観察したところ、移行前に較べて 3倍になったことを確認できた。

## 0. このプロジェクトの記載で何が伝わってほしいか フロントエンドに関して中期的な視点で改善するためのロードマップを作成し、それを実行に移せること。 以下でこれを示します。 ## 1. プロジェクトの内容と課題 別記のプロジェクト「カラーミーショップの新しいショッピングカート」で使っている AngularJS（1.x）を Angular（2.0 以上）へ移行させること ### チームの規模 * ウェブアプリケーションエンジニア x 2名（私はここに含まれる） ### 課題 ネットショップのカートなので、高いコンバージョンレート（CVR）を実現することがプロダクトの価値に直結するため重要。CVR を上げるためには UI の改善が必要。 良い UI については、下記で自分の言葉で整理した。 * [良い UI をつくる - 彼女からは、おいちゃんと呼ばれています](http://blog.inouetakuya.info/entry/2016/12/07/195754) 良い UI の実現のために、下記を行う必要があり、 * 初期ローディングを速くする * ユーザーのアクションに対する応答を速くする その手段のひとつが Angular への移行（もうひとつ HTTP/2 導入も別途やる） ## 2. 中期的なロードマップ Angular への移行準備として TypeScript を導入したり、Webpack を導入するが、これらの導入を単発で行うと、周囲の人からはその効果が見えにくく、開発リソースの確保が難しい。 そこで、中期的な視点に立ったロードマップを作成し、これからやっていくことの意義がまわりの人に伝わりやすいようにした。 その結果、勢いのある若手が名乗り出て TypeScript の導入を進めてくれるなど、まわりの人を巻き込むことに成功した。さらにその過程でチームの技術力の底上げにも繋がったと考えている。 ## 3. プロジェクトの成果 TypeScript を導入したり、Webpack 導入までは完了しているが、肝心の Angular への移行はまだ道半ば。いままさにやっているところである。

## 0. このプロジェクトの記載で何が伝わってほしいか * 400万PV/日のプロダクトをゼロから作り上げ、運用した経験を有すること * これを支えるバックエンド・インフラの技術力を有すること 以下でこれらを示します。 ## 1. プロジェクトの内容と課題 アダルト動画共有サービスの開発と運用。 * [オシャレエロサイトをリリースして、10万PV/日を捌くためにやったこと](http://blog.inouetakuya.info/entry/20120410/1334058296) ひとりで開発してリリースして、2015年の6月にクローズするまで運用した。リーンの考え方を用いてサービスを拡大し、クローズ時点では 400万PV/日 まで成長させた。 ### 課題 アクセス数が多く（10万PV/日 -> 400万PV/日）これを常時 200ms 以下で捌くのに苦労した。 動画の検索機能がよく使われていたため、検索精度がプロダクトにとって重要だった。 ## 2. 負荷対策 [オシャレエロサイトをリリースして、10万PV/日を捌くためにやったこと](http://blog.inouetakuya.info/entry/20120410/1334058296) に書いたように当たり前のことをやった。 * 負荷テストを行ったり * 画像を CDN に移したり * サーバーをスケールアップ・スケールアウトさせたり [【Rails 高速化】ペパボのフリマアプリ「kiteco（キテコ）」の API を高速化したときのことを詳しく書いてみた](http://blog.inouetakuya.info/entry/2014/02/08/221438) に書いたことと共通するが、 * ボトルネックとなっている箇所を特定し * インデックスを適切に張ったり * SQL の結果をキャッシュさせたり * ビューのレンダリングの結果をキャッシュさせたり ということを行った。 また、高負荷時にすぐにサーバーの台数を増やせるように、Puppet で構成管理をしていた。 ## 3. 検索精度を上げる Elasticsearch の analyzer 設定について地道にデバッグをしながら改善を繰り返した。 * [Rails + Elasticsearch で analyzer 設定をした後のデバッグまとめ](http://blog.inouetakuya.info/entry/2014/11/24/203210) * [elasticsearch-rails を使っているときの custom analyzer 設定の書き方](http://blog.inouetakuya.info/entry/2014/11/16/190649) 設定を変更することでデグレードが起きてしまうことを防ぐためにテストを書いて CI で実行していた。 * [Rails から Elasticsearch を使っているときのテストの書き方（elasticsearch-rails, RSpec）](http://blog.inouetakuya.info/entry/2014/11/03/191059) * [Rails + Elasticsearch + kuromoji のテストを Wercker で実行する](http://blog.inouetakuya.info/entry/2014/11/09/192006) ## 4. プロジェクトの成果 自分の、高負荷への対応力を成長させることができた。また、このプロダクトで積極的に新しい技術を試し、その経験を仕事に活かす、というフローが確立されていた。その意味でもとても役立った。

## 0. このプロジェクトの記載で何が伝わってほしいか OSS の利用と貢献を循環させるということの実践。 以下でこれを示します。 ## 1. プロジェクトの内容と課題 * ユニバーサル Vue.js アプリケーションをつくるためのフレームワーク Nuxt.js の公式ドキュメントの日本語訳。 https://ja.nuxtjs.org/ ### チームの規模 私ひとり。 同僚のひとりが、一緒にやってくれる旨を申し出てくれたが、彼が実際にジョインする前に終わらせてしまった。 ### 課題 2017年になっても SEO やソーシャルネットワークへの対応やパフォーマンス向上のため、サーバーサイドレンダリングが必要な場面が多くあり、そこに役立つ Nuxt.js はとても価値があると考えていた。 しかし、日本国内ではウェブ上や Vue.js コミュニティの Slack 上であまり話題に上らず、コミュニティにとって損失だと考えた。 Vue.js コミュニティはドキュメントが翻訳も含めて整備されている傾向があり、それが人気の要因のひとつであると考えている。Nuxt.js も公式ドキュメントを翻訳すれば、日本での利用者が増えると考えた。 上でいう日本での利用者の中には社内の同僚も含み、いずれ Nuxt.js を社内のプロダクトで導入するときに共有や開発がスムーズになると考えた。 ## 2. 翻訳 70 〜 80 ページを翻訳した。時にソースコードを読んで動きを確認したり、手元で動かしてみたりしながら作業を進めた。 * [Japanese translation by inouetakuya · Pull Request #36 · nuxt/docs](https://github.com/nuxt/docs/pull/36) 大半をおよそ2週間かけて翻訳し、残りは訳のブラッシュアップなどにあてた。 ## 3. 他の OSS 翻訳と知見を共有 Nuxt.js は Vue.js エコシステムのひとつなので、Vue.js の公式ドキュメントの翻訳の作法と大半を合わせた。 * [Nuxt.js 公式ドキュメントの翻訳スタイルの紹介](http://blog.inouetakuya.info/entry/2017/02/26/202148) * [Nuxt.js 公式ドキュメントの翻訳スタイルをアップデートした](http://blog.inouetakuya.info/entry/2017/04/23/203134) * [Nuxt.js 公式ドキュメント翻訳完了のお知らせと、結城浩さんへの謝辞](http://blog.inouetakuya.info/entry/2017/03/26/203925) また翻訳スタイルを公開することや、ツールを共有することは他の翻訳コミュニティにとって有益だと考えたのでブログに書いた。 * [Nuxt.js と Vue.js 公式ドキュメントの翻訳を GitLocalize でやっていきランチ](http://blog.inouetakuya.info/entry/2017/06/05/203354) ## 4. Vue.js コミュニティの Slack での活動 誰かのメッセージ中に `Nuxt` が含まれていたら通知が来るようにしており、Nuxt.js 関連の質問には、これまでほとんどすべて回答している。 ## 5. プロジェクトの成果 2017年3月の [Vue.js Tokyo v-meetup="#3"](https://vuejs-meetup.connpass.com/event/48462/) で Nuxt.js が解決してくれる問題について発表した。 * [Nuxt.js とは何か / What is nuxtjs // Speaker Deck](https://speakerdeck.com/inouetakuya/what-is-nuxtjs) そのときは Nuxt.js を知っている人は会場の 2割程度だったが、2017年7月の [Vue.js Tokyo v-meetup #4](https://vuejs-meetup.connpass.com/event/58071/) では会場の 7割以上の人が Nuxt.js を知っていた。 他の発表者も Nuxt.js を導入した事例を話していたし、確実に広まってきている感がある。

## 0. このプロジェクトの記載で何が伝わってほしいか * OSS の利用と貢献を循環させるということの実践 * 会社全体の問題の解決に向けてやっていく力 以下でこれらを示します。 ## 1. プロジェクトの内容と課題 ペパボテックカンファレンスの Vue.js 特集を2017年8月下旬に開催する（告知はまだ行っていない） その発案と準備、運営。 ### 課題 (1) Vue.js コミュニティを React コミュニティと較べて感じるのは **仕事の、特に大規模なプロダクトで Vue.js が使われている事例** を目にする機会が少ない、ということ。 事例を見聞きする機会が少ないと、自分たちのプロダクトで採用して良いのか不安になることがあると思う（少なくとも私はそう）。逆に事例が多くアウトプットされると、そうした不安が軽減され、ますます事例は増えていくと考えた。 そこで、ペパボではいくつかのプロダクトが Vue.js を採用しているので、隗より始めよということでペパボテックカンファレンス Vue.js 特集を開催することにした。 ### 課題 (2) また、ペパボはサーバーサイドやインフラの技術力に較べて、フロントエンドとネイティブアプリが強くないという課題を抱えている。 そこで「Vue.js やるんだったら、ペパボ」と印象づけることで、Vue.js コアライブラリのコミッタークラスの人にペパボにジョインしてもらい、ペパボのフロントエンドを強くしたい、という目的もある。 ## 2. テーマ * お仕事で Vue.js 使っているペパボの事例を話す * LT ではなく 20 〜 30分枠で数本話す ということまでは決めている。 ## 3. プロジェクトの成果 まだ開催していないため未知数だが、今後、Vue.js の事例が増えていけば嬉しい。またこれをきっかけにペパボの採用活動が促進されれば嬉しい。