吉田将之
吉田、ISAOを辞めるってよ
この度、ビジネスコミュニケーションサービス「Goalous」のリードエンジニアである私吉田将之は今年いっぱいをもちましてISAOを退職することとなりました。 控えめに言ってとても良い会社でしたが、学生の頃から思い描いていた挑戦の為にISAOを飛び出します！ 退職エントリー記事はISAOでは初めてとのことです。 記事を書く経緯は、自分の退職が非常にポジティブな理由であり社内でもオープンに説明をした後、広報から退職エントリー記事執筆のリクエストがあったのがきっかけです。 なぜ辞めるのか、ISAOに入社し何を学びどのように成長したのか、Nextチャレンジについて語っていきます。 なぜ辞めるのか 教育・福祉業界で技術のアプローチによる変革に挑戦する為です。 実は大学時代に社会福祉を専攻していて、その頃から「旧態然としたこの業界の悪循環を改善するためにはITによるアプローチが必ず必要になる」と考えていました。 ただ当時はIT音痴でそもそも具体的な構想を描く為の知識・技術は全く無かったので、まずはエンジニアとして様々な現場で知識・技術を磨くことにしました。 これまでの社会人経験の中で特にISAOでは人間としてもエンジニアとしても成長し土壌が出来たので、将来いつか自分がやりたかったことを「今」挑戦すべきだという思いに駆られ転職を決意しました。 ISAOへの入社 ISAOに入社したのは2016年夏。 入社した理由はISAOの特徴である「バリフラット」というとてもフラットな組織のあり方に惹かれたこと、またMVS(ミッション・ビジョン・スピリッツ)への共感が挙げられます。 将来もし会社の組織づくりを行う際にフラットな組織を経験しておくことは貴重な糧になると思ったのです。 ただ最後入社を決意したのは代表の中村圭志さんのおかげです。 最終面接で圭志さんともう一人の面接官とひとしきり話した後、逆質問で「MVSの研修があると伺ったのですが、具体的にどのようなものですか？」と質問をしました。 すると圭志さんはすっと立ち上がり、「じゃあ今から実際に行いますね」と言いそこから何と30分以上も掛けて実際のMVS研修が実施されました。 (もう一人の面接官は巻き込まれると思ったのか始まる前に退室していました苦笑) 僕は圭志さんの良い意味での「ヤバさ」そして「情熱」に惹かれました。 というのも、仕事をする上で最も重要な要素の一つが「情熱」だと考えています。 なぜならそれが無ければ周りの人を巻き込んで大事を成し遂げることは出来ないからです。 人を一つの方向に向かわせる為の原動力は利と情熱両方が必要であり、圭志さんに自分の考えと近しいものを感じました。 ISAOで何を遂げたか 〜学び・成長〜 入社後、組織の目標進捗を共有できるビジネスコミュニケーションサービス「Goalous」開発にコアメンバーの一人として参画しました。 しかし参画時には、既にGoalousのアプリケーションは非常にレガシーな状態でした。 ただ機能開発を優先せざるを得なかったので時間を絞り出し、安定性と拡張性を高くする為の仕組みを随時導入したり、パフォーマンス改善やコードリファクタリングを実施しました。 レガシーなフレームワークで不本意ながらもとことん頑張ってみた 事件は起こった そうして入社から約1年が過ぎた時、大きな転機が訪れます。 当時のGoalous開発のリードエンジニアが他プロジェクトに転属することが決定し、リードエンジニア後任として僕が務めることになりました。 それだけに留まりません。 ほぼ同じタイミングでそれまで日本人だけだった開発チームに、日本語を全く話せないアメリカ人エンジニアの参画が決まりました。 僕達にとってまさにそれは「襲来」と言ってもいい事態でした。 なぜなら開発チームの中に英語をまともに話せるメンバーが一人もいなかったからです。 しかしアメリカ人エンジニアを日本語のコミュニケーションで置いてけぼりにすることは出来ません。 チーム内でコミュニケーションについてどうするか話し合い、最終的にチャットや全員でのMTG等ほとんどを英語に変更しようと決断しました。 当時の回顧については採用サイトにも記載されていますのでご覧下さい。 https://recruit.isao.co.jp/engineering/ 一つ言っておきたいのは普通の企業ではこの事態はあり得ません。 なぜなら英語を話せない開発チームに日本語を全く話せないエンジニアを放り込んだら開発効率が著しく落ちるのは明らかだからです。 が、ISAOには世界で通用する為にグローバルな人材が必要であるという方針があります。 つまりは将来的に社員全体が英語で仕事が出来なければなりません。 その将来に向けた実験の一つとしてGoalous開発にアメリカ人エンジニアを参画させることが決定しました。 またほぼ同時期にブラジル人エンジニアも加わり、一気に国際色豊かになりました。 当時を振り返ってみると、英語でのコミュニケーションがかなり辛かったのを覚えています。 加えて日本人と外国人で考え方が違うことにも戸惑いました。 しかしそれが結果的に自分を大きく成長させてくれた要因でもあったのです。 当時の僕は開発について頑固な面があり、外国人エンジニア達の反発を招く時もありました。 このままではいけないと思い、他人の考えを否定から始めるのではなく多様性を認めることを意識するようになりました。 そうすると状況は少しずつ好転し、メンバーの方から「こういうコードはどうですか」「開発を**のように改善したいです」という積極性が徐々に生まれ始めました。 その時になって気づいたのです。開発において積極性が大事だとメンバーに謳っておきながらその積極性を阻害していたのは自分だったのだと。 正直穴があったら入りたい思いでした。...そうだ、HTTP/2に移行しよう(実践編)
こんにちは、エンジニアの吉田です。 前回そうだ、HTTP/2に移行しよう(OpsWorks編)の記事を執筆しましたが、今回はその続編となります。 (前回から時間が経ってしまい申し訳ないです汗) 前回はHTTP/2に移行する為にAWS OpsWorksを用いたChef12スタックでの シンプルな環境を構築するところまでお伝えしました。 しかし実際はChef12スタックは、Chef11以前のスタックと違い それまでのレシピの運用方法を変えなければなりません。 今回は、現場でのOpsWorks Chef12スタックにおける課題の解決にフォーカスした実践編となります。 実践編 その1. OpsWorksのChef12スタックでコミュニティクックブックを利用したレシピを実行する Chef12スタックで最も注意しなければならない点は、レシピを実行する際に 利用するコミュニティクックブックの参照が自動的に行われなくなったことです。 試しにコミュニティクックブックを利用したレシピをそのまま実行しようとしたら 「コミュニティクックブック?そんなの見つからないよ！」と怒られます。 なので解決方法としてはコミュニティクックブックを含んだクックブックアーカイブを事前に作成し s3にアップロードした場所を参照するようにします。 コミュニティクックブックを含んだクックブックアーカイブを作成 [前提条件] アーカイブ作成にはBerkShelfをインストールしている必要があります。 もし無い方はChefDKをインストールするか、もしくはGemでBerkShelfをインストールしてください。 ChefDK: https://downloads.chef.io/chefdk Gem: gem install berkshelf [手順] 1. ローカルでクックブックのディレクトリに移動する 2. berks packageコマンドを実行してアーカイブを作成する デフォルトだとcookbooks-1506749951.tar.gzといったタイムスタンプ付きのアーカイブが出来上がります。 もしファイル名を指定したい場合はberks package {ファイル名}.tar.gzのようにコマンドを実行します。 3. アーカイブを格納する為のs3バケットを作成する 4. 手順3で作成したバケットにアーカイブをアップロード AWS CLIのS3コマンドが便利です。 aws s3 cp cookbooks.tar.gz s3://{バケット名}...そうだ、HTTP/2に移行しよう(OpsWorks基本編)
こんにちは、チーム活性化サービス「Goalous」のリードエンジニアを務めている吉田です。 今回はGoalousがHTTP/1.1からHTTP/2に移行した経緯と実際にどのように移行したのかをお話します。 なぜ移行したか 僕達は先月までサービス全体の大規模なパフォーマンス改善を1ヶ月半以上かけて行っていました。 Goalousは以前からレスポンスの悪さがかなり目立っていて、「表示速度が遅い」という意見が多く寄せられていました。 開発チームとしてはユーザーのストレスを軽減してサービスの使い心地を向上させたい、 「サクサク動かせるようにしたい」という思いが前々からありましたが ただ機能追加・改善がどうしても優先的になってしまい手をつけることが出来ずにいました。 しかしサービスを有料化する前にはどうしても対応したかったこともあり、 今年5月にチームの総力をあげてサービス全体のパフォーマンス改善に取り組むことが決定しました。 HTTP/2への移行はそのパフォーマンス改善の一つの取り組みです。 HTTP/2のメリットの詳細は今回は省略しますが、詳しく知りたい方はこちらを参照下さい。 HTTP/2への移行を決めたのは、リクエストとレスポンスの多重化等のメリットを享受したかったのと、他にもう一つ僕達にとって重要な理由がありました。 それはAWSの問題です。 GoalousではAWSのOpsWorks(Chefを使用してクラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービス)を使用しています。 OpwsWorksはOpsWorksスタックとOpsWorks for Chef Automateの二種類があり Goalousで使用しているのはOpsWorksスタックです。 OpsWorksのスタックはChefのバージョンが11か12によって明確に区別されます。 僕達はずっとChef11のスタックを使用していましたが、もうそろろそろChef12にバージョンアップしたかったので 今回のHTTP2/移行が良い機会となりました。 あとはロードバランサーがELBではなくALBじゃないとHTTP/2を使用出来ないので思い切って Chef12+ALBの全く新しいスタックを作ることに決めました。 どう移行したか GoalousのChefのレシピは残念ながら公開出来ないので、本記事においてはあくまで OpsworksのChef12スタックとALBをどう構成してHTTP/2を実現するか に焦点を絞り、サンプルのChefレシピを使ってミニマムな構成の手順を説明します。 参考：Use Application Load Balancers with your AWS OpsWorks Chef 12 Stacks Step1.ALB作成 基本的にはAWSの公式ドキュメントに沿って作成します。 ただしステップ 5: ターゲットグループのターゲットを設定するはスキップしてください。 インスタンス作成とターゲットグループへのターゲット登録はOpsWorksで行います。 Step2.OpsWorksスタック作成 OpsWorksのダッシュボードページで、スタック追加ボタンをクリックします。 スタック追加ページに遷移後、まずChef12 Stackを選んだ上で、...React Hot Loaderで開発をさらに加速する
こんにちは！ Webエンジニアの吉田です。 先月16日にReact.js meetup × React Native meetupという180人ものエンジニアが集まる大規模なReact関連のイベントにてLT枠トップバッターで発表を行いました。 その時行った発表の「React Hot Loaderの導入」についてこれから詳しく説明します。 React Hot Loaderとは 従来のフロントエンド開発においてはBrowsersyncが一般的に用いられてきました。 Browsersyncはファイルの変更を監視して、自動でブラウザリロードを行い変更を反映させることができます。 しかしReact Hot Loaderはその利便性をさらに一歩前に進めます。 React Hot Loaderはファイル変更を監視して、stateを保持したままReactコンポーネントの変更をブラウザリロード無しで即座に反映する強力なロードモジュールです。 GitHub.io:React Hot Loader stateを保持したままReactコンポーネントの変更を反映をするということがピンと来ないかもしれませんので、まずは以下のデモ動画をご覧ください。 テキストボックスに入力した文字をstateに設定し、その下に表示するだけのシンプルなReactアプリケーションです。 左側のブラウザでテキストボックスに文字を入力した後、右側のエディターでcomponentを修正して保存します。 するとブラウザリロードが発生せずに即座に変更が反映されていることが分かります。 かつテキストボックス下の文字列は残ったままなので、stateの情報は保持されています。 もう一つデモをご覧ください。 今度は親コンポーネントが二つの子コンポーネントを持った状態で、色々とコンポーネントを変更してみます。 stateが保持されているので、子コンポーネントを一旦削除した後復元してもテキストボックスに入力した内容が表示されています。 このようにReact Hot Loaderはstateに依った処理を修正する際に非常に便利です。 なぜならブラウザをリロードすれば当然stateの内容は消えてしまうので、修正した箇所をテストする為にまずstateに設定するための手順を踏まなければいけません。 複数のパターンで修正をして確認したい時は余計に時間が掛かります。 React Hot Loaderを使用すればその手順は不要になるので、よりスピーディーに開発することが出来ます。 React Hot Loaderを導入してみよう では実際に導入してみましょう。 前述したようにReact Hot Loaderはあくまでロードモジュールです。 従ってWebpackなどのビルドツールでロードして使用することが前提となります。 今回紹介するのはgulp+Webpack+Browsersyncを組み合わせて実現する一例です。...MeetUpを開催しました！「Web APIの現場あるある解決特集〜こうして僕たちのAPIは使いやすくなった〜」
こんにちは、Webエンジニアの吉田です。 先日11/30に弊社にて第7回目のMeetupを開催しました。 その様子をご報告させていただきます。 イベントページはこちらのconnpassページにて 今回は私がメインスピーカーとして 「Web APIの現場あるある解決特集〜こうして僕たちのAPIは使いやすくなった〜」 のテーマで発表いたしました。 内容 今まで様々な現場の開発で利用してきた良い/悪いWebAPIと、それらを改善した知見をケーススタディ形式でデモを交えてお話ししました。 懇親会の様子 今回も多彩な領域のエンジニアの方々とお話しでき、有意義な交流会となりました。 当日は、遠いところ足を運んでいただいた参加者の皆様、本当にありがとうございました。 次回Meetupは来年1月開催予定なので、今回参加できなかった方も是非遊びに来てください。 おわりに 弊社は今後も社外へ向けた勉強会を引き続き開催していく予定です。 勉強会テーマについても、参加者の皆さんのご意見を反映して幅広いジャンルにしていくつもりです。 connpassのISAO Meetupグループに是非ご参加ください！！ http://isao.connpass.com/ 最後になりますが、ISAOでは一緒にサービスを作ってくれるエンジニアを絶賛募集中です。 ご興味を持っていただけましたら、まずは気軽に弊社に遊びにいらしてください。 https://www.colorkrew.com/recruit/...