 Howtelevision

はじめにGraphQL Fragments とはMondでの導入背景導入して良かったことFragmentsの落とし穴multiple definitions for fragmentオーバーフェッチ今後の取り組み最後にこんにちは、知の共有プラットフォーム Mond 開発チーム所属、新卒エンジニアの id:chima91 です。最近は空気がかなり乾燥してきたので、風邪を引かないよう体調管理に気をつけています。運動・睡眠・食事、あとはお風呂上がりの保湿ケア、どれも欠かせないですね。皆勤賞を取るんだ、くらいの気持ちで頑張っております。はじめにさて、MondではデータのCRUDにおける手段の一部としてGraphQLを使用しています。GraphQLでは既存のクエリに影響を与えることなく、取得するフィールドを追加したり削除したりすることができるため、APIを柔軟に保守することが可能です。今回はそのGraphQLにおいて、複数のクエリやミューテーション間でフィールドを共有するための、Fragmentsというロジックを導入した際の学びと落とし穴について紹介したいと思います。GraphQL Fragments とはQueries and Mutations | GraphQLFragments let you construct sets of fields, and then include them in queries where you need to.GraphQLのドキュメントでは、Fragmentsは必要な時にクエリに含めるフィールドのセットであると定義されています。単純に言い換えると、Fragmentsは変数のようなものだと思います。関連付けられた型（Mondでいうと、TopicやCommentなど）に関するフィールドの固まりを予め定義しておき、それをTopicオブジェクトやCommentオブジェクトを参照するクエリやミューテーションに含めて利用します。fragment commentFields on Comment {  id    status  content_length  content_html  created_at    updated_at}query Hoge(  $limit: Int = 30) {  topic (    limit: $limit  ) {    id    content    comments(      where: { status: { _eq: active } }    ) {      ...commentFields    }  }}query Fuga(  $sub_comment_id: String!) {  sub_comment_by_pk (    id: $sub_comment_id  ) {    id    content    comments {      ...commentFields    }  }}異なるクエリ間で同じデータ構造を要求する場合に、その構造を一貫して保つことができます。これにより、クライアントサイドのキャッシュ管理が容易になり、データの取得効率が向上する可能性があります。Mondでの導入背景Mondでは、同じ型に対する複数のクエリで共通のフィールドを取得している場合でも、これまではFragmentsを使用していませんでした。各クエリでバラバラに、必要であろうフィールドを書いてデータを取得していました。また、各コンポーネントごとに必要なデータを取得するクエリを発行しているため、パフォーマンス面でも良くありません。そこで今回は手始めに、GraphQL周りのリファクタリングの一環として、今後のリファクタリングにおける前座の意味合いでFragmentsを導入することにしました。導入して良かったことなんといってもまずは、可読性と保守性の向上です。クエリ内の一部のフィールドセットを再利用可能な単位とした定義により、クエリ間で共通して取得しているフィールドを簡単に把握できるようになりました。また、Fragmentsのフィールドを編集することで、各クエリを編集することなく取得したいフィールドを変更可能になったのが大きな変化でした。さらに、Fragmentsを導入するにあたり、普段はメンテナンスできていないクエリに目を通す機会を得ました。その結果、使われていないのに取得しているフィールドがあるクエリがいくつか見つかりました。副次的効果ではありますが、それらをメンテナンスすることでパフォーマンスの向上に繋げることができて良かったです。Fragmentsの落とし穴ただし、Fragmentsの導入時には注意すべき点が2つあります。multiple definitions for fragment1つ目は、気づかずに一つのクエリの中で同じFragmentsを呼んでしまう可能性がある点です。以下はfragmentの定義と、それを利用しているクエリの例です。fragment subCommentFields on sub_comment {  id  status  author {    id        display_name  }  comment {    ...commentFields    topic {      id      content    }  }  created_at}query GetCommentDetailById($comment_id: String!) {  comment_by_pk(id: $comment_id) {    author {      id      display_name    }    topic {      id      content    }    sub_comments(order_by: { created_at: asc }) {      ...subCommentFields    }        ...commentFields  }}GetCommentDetailById というクエリでは、commentFieldsとsubCommentFieldsという2つのfragmentを利用しています。しかし、subCommentFields の中でcommentFields を利用しているため、一つのクエリの中で commentFields というfragmentが2回呼ばれてしまっています。そのため、multiple definitions for fragment "commentFields" というエラーが起こります。このエラーが発生するのは以下のような場合です。同じクエリまたはミューテーション内で、同じ名前のFragmentsを2回以上定義している。異なるクエリやミューテーションであっても、同じ名前のFragmentsが複数存在する。オーバーフェッチ2つ目はオーバーフェッチに繋がりうる点です。GraphQL利用のメリットとして、オーバーフェッチ（リクエスト元で不要なリソースまでフェッチしてしまうこと）を防げることがよく挙げられます。1つのFragmentsを多用すると、クエリによっては Comment 型の一部のフィールドだけ必要であるのにも関わらず、他のフィールドまでフェッチさせることになりかねません。同じ Comment 型に対するFragmentsであったとしても、多くのフィールドをまとめたFragmentsと少しのフィールドを集めたFragmentsに分割することで、帯域を節約する必要があります。今後の取り組み今後の取り組みとして、Fragment Colocationも導入したいと考えています。名称からお察しかもしれないですが、これはFragmentsとそれを利用するコンポーネントを「同じ場所に配置する」やり方です。www.youtube.comこれにより、コンポーネントで必要となるデータが変わった場合でも、同じ場所にあるFragmentsに変更を加えるだけなので、保守性が高まります。Mondでもこれを導入し、さらなる開発体験の向上を進めていこうと考えています。最後に以上のように、GraphQL Fragmentsを導入することで、複数のクエリやミューテーション間でフィールドを再利用することが可能になり、コードの可読性や保守性を向上させることができました。ただし、同一クエリ内で同名のFragmentsが複数回呼ばれるとエラーになる点には注意が必要で、オーバーフェッチにも気をつけたいところです。これを理解し、適切に利用することでGraphQLの効果を最大限発揮することができると思います。P.S. 弊社（Mond開発チーム）では エンジニアを絶賛募集中 です！まずはカジュアル面談からよろしくお願いいたします。

GraphQL Fragments を導入してクエリの可読性・保守性を高めた際の学びと落とし穴

はじめになぜ GitHub Copilot Business なのか？提案方法と内容提案方法背景と課題の設定費用対効果の算出上長からの承認を得る導入と測定定性的な方法定量的な方法浸透への試みベストプラクティスの調査と共有ペアプログラミング今後苦労した点費用対効果の算出方法効果測定の方法学び最後にはじめに23新卒エンジニアの根本です。GitHubによると、GitHub Copilotの使用によりコーディングが1.5倍早くできることが実験でわかりました。その上で私は元々GitHub Copilotを個人的に使用し明らかな生産性の向上を感じたため、職場でも使用したい・開発組織の生産性を向上させたいと思い、GitHub Copilot for Businessの導入を提案しました。今回は、新卒エンジニアが初めて開発組織全体に対してアプローチする挑戦について、経験と学びについて共有します。これを皆さんと共有することで、GitHub Copilot Businessを導入したいと考えている誰かの役に立てることができれば幸いです。なぜ GitHub Copilot Business なのか？GitHub Copilotは個人でも利用可能ですが、以下の二つの問題があり、GitHub Copilot Businessを導入することに決めました。一つ目の問題は、管理者が組織内で誰がCopilotを使用しているか把握できないことです。仮にGitHub Copilotの業務使用に問題が生じた場合、管理者が即座に使用を停止することは困難です。二つ目の問題は、ソースコードが外部に流出するリスクです。GitHub Copilot Businessでは、プロンプトや候補は保持されません。しかし、GitHub Copilot Individualでは、プロンプトや候補の収集許可設定はデフォルトで許可になっており、この設定を不許可にするか否かは個々のユーザーに委ねられてしまいます。   GitHub Copilot Individual  GitHub Copilot Business  組織の管理者によるライセンス管理  No  Yes  プロンプト・候補の保持のデフォルト設定  オン  オフ 提案方法と内容GitHub Copilot Businessを使用するには、一人あたり月$19のコストが発生します。これを会社の費用として利用するためには、それに見合うリターンがあることを説明する必要があります。提案方法まず、自分の提案を整理するために、Design Docを作成しました。Design Docは、提案内容を他人に理解してもらうとともに、議論や意思決定の記録を残すための文書で、Googleなどではソフトウェア開発の設計段階で使用されています。ここでは、背景の把握、それに起因する課題とその解決策の議論を行うために、Design Docのフレームワークとして利用しています。弊社では、次の画像のように、メンバーの提案を一箇所で統一して管理しています。Notionテンプレートを活用しており、何か提案したいと思った時、すぐに提案を作成できるように設定されています。Design Docs背景と課題の設定エンジニアの生産性向上は、人件費の費用対効果を高めるため、多くの企業で経営層から求められている要素です。したがって、GitHub Copilotの導入による生産性向上が、人件費に対して高い費用対効果をもたらすことを説明できれば良いと考えました。費用対効果の算出以下では、理解しやすい例として10人のエンジニアがいる場合を考えます。GitHub Copilot Businessの費用一人当たりの価格は$19/月で、約 2,660 円/月、約 32,000 円/年であるであるから、10人分の年間コストは32万円です。Copilotの導入効果に相当する人件費GitHubの実験結果によると、GitHub Copilotの使用によりコーディング速度が1.5倍になります。この生産性の向上をGitHub Copilotを導入せずに人員増加で補おうとすると、単純に考えて5人増員する必要があります。また、保守的に見積もって1.2倍になったとしても、2人の増員が必要となります。したがって、エンジニア一人の年間人件費（給与とそれ以外の会社が負担する総額）を600〜1000万円とし、その中央値である800万円を基に計算すると、Github Copilotの導入によりコーディング速度が1.5倍になるとすれば、それは人件費4000万円に相当します。さらに控えめに1.2倍になると見積もっても、人件費1600万円に相当します。上記で求めたGitHub Copilot Businessの費用とGitHub Copilotの導入効果に相当する人件費を比較すると、50倍〜100倍もの違いがあることがわかります。これにより、GitHub Copilotを導入すべき根拠を算出しました。   Copilotを導入しない場合のコスト  Copilotを導入した場合のコスト  コーディングの生産性が1.5倍になった場合  10人 * 1.5 = 5人増やす / 4000万円  0人 / 32万円  コーディングの生産性が1.2倍になった場合  10人 * 1.2 = 2人増やす / 1600万円  0人 / 32万円 上長からの承認を得る作成したDesign Docを部長に対して提案し、レビューを貰いながら修正を繰り返し、導入の承認を得ることができました。導入と測定GitHub Copilotを導入すること自体は簡単で、管理者が希望する人に対してGitHub Copilotの権利を付与するだけで実現可能です。しかし、GitHub Copilotを組織に導入する際の課題は、単に導入しただけではツールを有効活用できないということです。GitHub Copilotが導入されても、仕事の効率が上がらなければ、GitHub Copilotにかかる費用は無駄になってしまいます。GitHub Copilot導入後の効果を測定するためには二つのアプローチが考えられます。定性的な方法導入開始一ヶ月後に利用状況についてのアンケートを実施しました。その結果から、以下のことがわかりました。導入を希望した人の半数以上が、GitHub Copilotの使用によってコーディングの生産性が向上したと感じています。一方で、導入を希望した人の中には、GitHub Copilotに馴染めず、導入や日常の使用が難しかった人もいました。多くの人が私の期待していた1.2倍以上の生産性向上を実感できていませんでした。定量的な方法チームごとのチケットの消化量一人当たりのPR数について導入前後で比較を行いました。結果としては、過去の変動の範囲内で、大きな変化はありませんでした。これらの結果から、GitHub Copilotをすでに日常的に使用していた私と他の人とでは、GitHub Copilotの使い方や前提知識に差があることに気付きました。そこで、他の人にもGitHub Copilotを活用してもらうためのアクションを取ることにしました。浸透への試み生産性の向上が期待ほど実感できない原因として、GitHub Copilotをエディターに導入して業務で使用していても、人により機能を十分に活用できている人とそうでない人がいるという仮説を持ちました。そのため、以下の二つのアプローチを取りました。ベストプラクティスの調査と共有一つは、GitHub Copilotの効果的な活用方法についてNotionにまとめ、社内LT会で全体に共有したことです。私の調査の結果、GitHub Copilotを効果的に使用するためには、その仕組みを理解した上でエディター上でのファイルの開き方やコードの書き方を工夫する必要があることが明らかになりました。以下に、特に参考になった資料を示します。仕組みから学ぶ GitHub Copilot の使い方How to use GitHub Copilot: Prompts, tips, and use cases| GitHub Copilot Patterns & Exercisesペアプログラミング二つ目のアプローチは、希望者とのペアプログラミングを行なったことです。片方のエディター画面を共有しながら、プロダクトのコードのこの部分ではどのように使うかについて意見交換することで、具体的な活用シーンを共有することができました。今後上記の試みは、直近一ヶ月で行いました。すぐに数値に現れない可能性も考えられるため、継続的に計測をすることで、ツール導入の効果を説明できるようにしていきたいと考えています。苦労した点費用対効果の算出方法まず、GitHub Copilotのコーディング速度が速くなるという話をどのように費用対効果に落とし込むかというところが難しかったです。初めはコーディングのリードタイムの短縮・こなせるタスク量の増加という話で進めようと考えましたが、それを費用対効果として落とし込もうとすると効果の説明がわかりづらくなってしまいました。結果的に上記の説明がシンプルでわかりやすいと考えました。効果測定の方法アンケートを定性的な効果測定の手法として採用しました。しかし、アンケートは主観的な評価になるため、その数字を客観的に評価することが難しいです。定量的な効果測定の手法としては、導入前後のチケットの処理量やプルリクエストの数などが考えられます。ただし、コーディングやPRルールの変更・チームの増員など、導入から2ヶ月だけでは多くの変数が存在し、一人当たりの平均タスク処理量や平均PR作成数での比較が難しいです。学び組織内で新しいツールを導入することは初めての挑戦でした。ただツールを導入するだけでなく、その効果を導入前後で測定し、ツールを広く浸透させるための適切な方法についても考える必要があることを学びました。Design Docの費用対効果の部分において、自分以外の人にもわかりやすく説明することと厳密に見積もりを算出することのバランスの取り方が最初はわからず苦労しましたが、このようなわかりやすい題材を扱うことで塩梅を少しつかむことができました。最後にハウテレビジョンでは、ソフトウェアエンジニア/プロジェクトマネージャー/プロダクトマネージャーを積極採用中です！PdM/エンジニア の求人一覧 - 株式会社ハウテレビジョン

新卒エンジニアがGitHub Copilot Business導入に挑戦した話とそこから学んだこと

そもそもスクラム開発とはLiiga プロダクト開発チームにおけるスクラム開発のこれまで~2022.6 （スクラム開発ではない）アジャイル開発期2022.6~2023.8 スクラム開発導入、なんちゃってスクラム開発期2023.9~ 脱なんちゃってスクラム、マジスクラム開発スタートなんちゃってスクラム開発期に抱えていた問題解決策として、スプリントレビューを導入今だからわかる、なんちゃってスクラムをなかなか抜け出せなかった原因結局大事なのは「守破離」だった。しかし…最後にハウテレビジョンで若手社会人向けプラットフォーム Liiga の開発とスクラムマスターをしている 59k です。Liiga プロダクト開発チームでは、スクラム開発を取り入れて機能開発・保守運用を行なっていますが、つい最近「脱なんちゃってスクラム」をできたのではないかと思える変化があったので、それについて記録を残そうと思います。また私がハウテレビジョンに入社して 3 年、Liiga プロダクト開発チームのスクラムマスターになって 1 年という節目でもあるので、これまでのチームのスクラム開発についても振り返りつつ、本題について書ければと思います。そもそもスクラム開発とは「なんちゃってスクラム」について語る前に、そもそもスクラム開発とは何かについて軽くふれておきます。Notion AI さんの力を借ります。NotionAIスクラム開発とは、プロジェクトを小さな部分（スプリントと呼ばれる）に分割し、それぞれのスプリントで具体的な成果物を作り出す形のアジャイル開発の一種です。スプリントは通常、2〜4週間の期間で設定され、その間に特定のタスクを完了する目標（スプリントゴール）が設定されます。スクラム開発では、プロジェクトチームが日々の進捗を確認し、問題点をすぐに共有・解決することを重視します。これにより、プロジェクトの進行中に新たな要件や問題が発生した場合でも、素早く対応することが可能となります。また、スクラム開発では、開発チーム全体が互いの進捗状況を把握し、共同で問題を解決するための環境作りが求められます。これにより、チーム全体として問題解決能力や生産性を高め、より質の高いプロダクトを効率的に開発することが可能となります。補足として、スクラムとは？を正しく理解したい方は、公式のスクラムガイドのご一読を進めます。https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdfLiiga プロダクト開発チームにおけるスクラム開発のこれまでまず、Liiga プロダクト開発チームがこれまでどのように開発フローを変えてきたかを振り返りたいと思います。~2022.6 （スクラム開発ではない）アジャイル開発期まず、私が知る限りチーム発足(2015年頃)〜2022年6月まで続いた、「スクラム開発ではないアジャイル開発期」です。この記事の本題とは遠いので深掘りはしませんが、この時期の私は1メンバーとして、「頑張ってはいるつもりだが、どこまで頑張れば合格点なのかわからない…」といった悩みを抱えていました。「自分に降ってきたタスクを、自分のペースでやるだけ」みたいな日々で、「これがベストではない気がする、でもどうすればいいのかわからない」とモヤモヤを感じていた時期だったと記憶しています。2022.6~2023.8 スクラム開発導入、なんちゃってスクラム開発期そんな中、外資就活チームから異動されてきた方により、Liiga プロダクト開発チームにスクラム開発（2週間スプリント）が導入されました。私自身はここで初めてスクラム開発という開発手法の存在を知ったので、個人的にはとても大きな出会いです。バーンダウンチャートで日々の進捗を確認できるようになったことで、スクラム導入前に感じていた「どこまで頑張っても、これでいいのかわからない」モヤモヤからも、無事解放されたように思います。チームにも小さくない変化を与えました。具体的には各チケットの見積もりを人日ではなく作業量ベースで行い、スプリントごとのベロシティをモニタリングするようになったことで、それまで関心ごとでなかった「中長期的なチームの成長度」に嫌でも関心が向くようになりました。しかし、この時期はまだ「なんちゃってスクラム」だったと思います。理由は以下2つです。スプリントレビューを行っていなかったスプリントゴールを設定せず、ベロシティが上がればいい、みたいな空気だったスプリントレビューを実施していなかった背景には、役割が近い別MTG がすでにあったからではありますが、そのMTGは以下3つの点でスプリントレビューとは異なっていました。営業の方のみが参加しており、オープンにレビューを集める場ではなかった（マーケ等他部署に開かれていなかった）インクリメントに対してではなく、直近リリースされた機能について共有する場だった開発チームからは固定の代表者1人のみが参加しており、全員参加ではなかったちなみに「なんちゃってスクラム」かどうかの判定はこちらの記事の「スクラムの各イベントで、『スプリントゴールの達成のために』という言葉が出ているか？」のイメージです。2023.9~ 脱なんちゃってスクラム、マジスクラム開発スタートそして 2023 年夏、チームで経験したある失敗をきっかけに、ついになんちゃってスクラムを卒業します。この頃に行っていたある新機能開発において、リリースの直前に「本当にこの仕様で良かったんだっけ…？」という迷い・不安がチーム内で生まれてしまったのです。この機能自体は不安を抱えたままリリースし、結果的には多くのユーザーに利用いただいたものの、これがチームにとって脱なんちゃってスクラムのきっかけとなりました。ここからはその仔細を説明します。なんちゃってスクラム開発期に抱えていた問題上記「なんちゃってスクラム開発期」においては、以下のようなフローで開発していました。プロダクトオーナーが要件定義書を作成要件定義書をもとにデザイナーが UI (Figma) を作成要件定義書と Figma をもとにエンジニアが実装リリース前に PdM + デザイナー + エンジニアで UIUX&動作チェック今思えば、要件定義書を作成している時点で純粋なアジャイル開発とも言い難いですね。実際ウォーターフォールっぽい側面があり、大きな仕様変更やアクシデントがない限りは順調にリリースまで漕ぎ着けていたものの、先述の機能開発のようなケースでは「後の祭り」として片付けざるを得ないような開発フローだったと思います。また、仕様検討フェーズが プロダクトオーナー（PO）に依存しており、キャパシティオーバー気味だった問題もありました。要件定義書の作成コストや、そこに書ききれない背景をエンジニアやデザイナーに伝えるコミュニケーションコスト、さらには「仕様の質が PO 次第」という心理的負荷もあったと思います。当時の「仕様策定〜開発」の流れgraph TB  b(プロダクトオーナーが要件定義書を作成)  b-->c(要件定義書をもとにデザイナーがUIを作成)  c-->d(要件定義書と Figma をもとにエンジニアが実装)  d-->e(リリース前にPdM、デザイナー、エンジニアでUIUX&動作チェック)解決策として、スプリントレビューを導入上記の問題を解決できる可能性があると思い導入したのが、スプリントレビューです。狙いは以下です。より早く、より短いスパンでチーム内外からレビューをもらうことで、リリース直前での大きな仕様変更を防ぎたかったよりユーザーに近い、Biz やマーケの方からレビューをもらうことで、仕様の質を高めたかった開発者全員が仕様検討に参加することで、実装時のコミュニケーションコストを下げたかったスプリントレビューを導入して 2 ヶ月ほど経過しましたが、上記の狙いは果たせており、最近の開発ではチームで自信を持って仕様策定〜リリースできているように思います。現在の「仕様策定〜開発」の流れgraph TB  b(スクラムチーム+ステークホルダー（Bizやマーケ）でユーザーストーリーマッピング ※)  b-->c(デザイナーがUIを作成)　　　　b-->d(PO＆エンジニアがプロダクトバックログアイテムを作成)  c-->e(エンジニアが実装)  d-->e  e-->f(リリース前にPdM、デザイナー、エンジニアでUIUX&動作チェック)  f-->g(スプリントレビュー)※仕様検討のとっかかりを作るため、ユーザーストーリーマッピングにも併せてチャレンジしました。今だからわかる、なんちゃってスクラムをなかなか抜け出せなかった原因スプリントレビューをやるようになると、チームは自然とスプリントゴールを意識して動けるようになりました。（これをもって「なんちゃってスクラム卒業」できたと考えています。）実はスプリントゴールが重要であること自体は以前から認識しており、ゴール策定には何度かチャレンジしていたのですが、チーム内で「スプリントゴール達成のために」というワードを聞くことはありませんでした。今振り返ると当然なのですが、当時はベロシティからなんとなくスプリントゴールを決めており、「なぜゴールを決める必要があるのか？」という疑問に誰も答えられなかったのです。しかしスプリントレビューを導入すると、自然と「スプリントゴール」が重要な意味を持つようになります。スプリントゴール ≒ 「スプリントレビューで何をお披露目したいか」であり、それが達成できなければスプリントレビューは開催できず、フィードバックをもらうのは 2 週間後。リリース時期にも大きく影響します。結局大事なのは「守破離」だった。しかし…結果から言うと、私たちがなんちゃってスクラムをなかなか抜け出せなかったのは「スプリントレビューを実施していなかったから」でした。スクラムガイドにも定義されている重要なイベントをやっていなかったわけですから、当然と言えば当然です。しかし、「スクラムガイドでこう定義されているから」という理由で何かをするのは、目的と手段を混同する危険性もあると思います。スプリントレビューの導入は、どちらかと言えばメンバーへの負担が増える変化だったので、そのような説明では納得感も得られなかったかもしれません。私たちの場合はそうではなく「我流でやってきたが、このフローではダメだ」という失敗をチームで経験できたから、スプリントレビュー導入をスムーズに行えたのではないかと思っています。これもまたスクラム開発で重要な「経験主義」という考え方に通ずると思います。「守破離」は大事にしつつ、でも今後も経験に基づいてチームにあった方法を模索していければいいなと考えています。最後にエンジニア絶賛募集中です！

スプリントゴールとスプリントレビューを導入して、なんちゃってスクラムを卒業できた話

こんにちは、id:hc0001 です。今日は会社が掲げるミッションとプロダクトとして目指すところ、そしてそこに向かうためにどういった課題を抱えているのかといった話をします。ハウテレビジョンのプロダクトプロダクトおよび組織の課題組織の共通言語となるプロダクトロードマップおよび運用プロセス外資就活ドットコムで顕在化する技術負債の根本的解消エンジニアリングの核となるプロダクトを横断した技術戦略課題を踏まえた今後についてハウテレビジョンのプロダクトハウテレビジョンはキャリアプラットフォームである外資就活ドットコムと Liiga、そして知の交流プラットフォーム Mond を展開しています。外資就活ドットコムは 2010 年にはじまった、外資系・日系を含む一流企業を目指す学生向けの就職活動サイトで、Liiga は若手をハイキャリアを目指す若手向けの、厳選された求人を掲載する転職活動サイトです。どんな企業のどういった求人があり、どういう募集要項と選考フローで、どのように応募してどう内定を貰えばいいのか。就職や転職における一連のプロセスを自ら調べて対策するのは大変な労力を伴います。外資就活ドットコムはそうした就職活動における情報の非対称性を解消するために誕生しており、その時の「就職や転職に際して発生する、労働動機や能力を見つめ直すプロセスが能力開花するために重要なものである」という弊社代表の原体験が「全人類の能力を全面開花させ、世界を変える。」というコーポレートミッションに繋がっています。このように、キャリア形成において重要な意味を持つ「就職」と「転職」を通じて、志ある人の自己実現を支援します。gaishishukatsu.comliiga.meMond は「問い」という根源的な欲求を通じて、世界の可能性を広げることを目指すプラットフォームです。問の重要性は先の自分を見つめ直すプロセスで言及した通りで、就職や転職といった特定のライフイベントに焦点を当てるのではなく、人類の能力開花の源泉とも言える「問答」を通じて、社会の変革を促すことを目指しています。私自身も認定回答者として日々 Mond 上で生まれる問に対して、問答しています。mond.how私自身の労働動機も時々に応じて変化してきました。生きていく上で必要な稼ぎを得るという前提はありつつも、エンジニアリングバックグラウンドが全くない状態で SIer に就職するところから始まっています。受託開発と技術投資が相反するベクトルということを悟り、より技術者として大成するための環境を探す中で、新規事業の大量立ち上げを掲げてエンジニアを募集していたサイバーエージェントに転職しました。事業会社で働く中でソフトウェアエンジニアリングという専門性を磨きながらも組織や事業に思考が変化してきた中で、当時のキャッシュレス勃興期の最中、すでに C2C マーケットプレイスとして成功を収めていたメルカリが決済事業に乗り込んでいくということで、日本の価値交換のあり方を変えていくミッションの一助になるためにメルカリにジョインします。その後は、様々な業務を様々なレイヤで関わる中で、日本社会のボトルネックは何なのかを自問する日々が続きました（ちなみにこれは仕事で直接的に求められてきたわけではありませんが、同僚との対話の影響です）。mond.how当然、こうした壮大なテーマの答えが簡単に出る訳もありませんが、いくつか感じていた課題のひとつに「雇用」がありました。ここ 30 年間、日本経済は停滞が続いていますが、その要因にあらゆる組織に存在する既得権益があり、必要な新陳代謝を妨げています。企業の営みにおいては、就職した会社に終身で勤め上げる慣習や正社員の雇用保護などがそれに当たるでしょう。戦後の教育制度もこれらの文化的背景に強く影響していますが、昨今では転職や副業が一般化してきたことで転換期を迎えています。「ひとりひとりが働くテーマを持ち、適した環境で能力を発揮する。優秀な人材を抱えるために企業は新陳代謝を繰り返し、より優れた事業を社会に創出する。」こうした体質転換が、これからの日本社会に必要なことではないかと感じています。優秀な人材を採用し抱え続けるために、企業側の組織改善を促しつつ、人材の新陳代謝を促すためにも、雇用される側の機動性を高める必要がある。100% がそうではないにせよ、年功序列を助長しかねない新卒一括採用等の枠組みや終身雇用は転換期を迎えているのだろうな。— Shogo SENSUI 🍵 (@1000ch) 2021年10月9日  プロダクトおよび組織の課題このように個人的なテーマと組織や事業として目指すところの交差が決め手となり、ジョインしました。事業としては順調に成長拡大し、新たな事業の種も芽が出ている一方で、エンジニアリングを含む組織やモノづくりの在り方には発展の余地を残しており、今後更なる速度で成長できるポテンシャルを感じています。今後も労働市場におけるキャリアの動向を捉えながら、ミッションの達成に向けて邁進していくことは前提ですが、短期でフォーカスするべきいくつかの重点課題を設定しています。組織の共通言語となるプロダクトロードマップおよび運用プロセス現状の組織図は、ビジネス本部・プロダクト本部・コーポレート本部・Mond 事業部・人材戦略部という大きく 5 つから構成されており、ビジネス本部とプロダクト本部がキャリア事業の推進を主幹とし、Mond 事業部がその名の通り Mond を育てています。ビジネス本部にはプロダクトの価値を営業活動を通じて提供する事業開発部と広報活動を通じて届けるマーケティング部があり、プロダクト本部は大きく分類してプロダクトマネジメント、エンジニアリング、デザイン、編集の専門性を持った人材と部付の HRBP で構成されています。中長期の目標は存在していましたが、部門がそれぞれの目標を設定していたため、専門性の垣根を超えて事業に向き合うための目標や共通言語が曖昧でした。これを払拭するために、その事業の未来を描くプロダクトロードマップを創り、レビューを通じて経営として合意した状態にすることで、ロードマップに対して各専門性がどのようにコミットできるのかを思考していくように、現在進行系で構造を転換しています。これによって、プロダクトロードマップが部門を超えた共通の羅針盤の役割を果たし、ビジョンに対して組織が部門を超えて一体となって向き合うことを目指しています。当然ながら事業を取り巻く環境は、考慮しきれないほど多くの要因に左右されるため、定期的にアップデートしていく必要があります。だからこそ、ひとりひとりが専門性の壁を超えて事業に向き合いコラボレーションしていくことが求められます1。外資就活ドットコムで顕在化する技術負債の根本的解消創業以来、会社の成長を支え続けてきた外資就活ドットコムですが、システム面へ十分に投資してこれなかったこともあり、大きな技術負債を抱えています。また、十数年の間に発生してきた人の入れ替わりに伴って肥大化したシステムの全容を把握している人がおらず、目下の開発生産性だけでなく問題発生時への対処が難しく、システムの管理体制として不確実性が高い状況です。中でも、PHP の古いバージョンやアップデートされていないフレームワークなどは、可及的速やかに対応すべき事項です。技術負債は、収益として大きな割合を占める外資就活ドットコムだからこそ喫緊の課題であり、解消に向けて集中的に投資することを経営として意思決定しました。これを完遂することで、開発生産性とシステム可用性を確保しこの先の数年を戦えるシステムに転換するとともに、この技術的な投資実績は今後の経営判断の糧になるでしょう。この進捗はまたの機会に発信していければと思います。エンジニアリングの核となるプロダクトを横断した技術戦略外資就活ドットコムでは PHP, Go, React, Next.js, TypeScript, AngularJS、Liiga では Ruby on Rails, Vue.js, Nuxt、Mond では React, TypeScript, Node.js といったように、それぞれが独立した開発体制や技術選定で進められています。こうした分化は、担当メンバーの得意な技術で取り組めるメリットがある一方で、チームで蓄積したナレッジを再活用し難く組織学習を進めにくいという弊害があります。結果として中長期での開発生産性や人材流動性などを確保できなくなるため、戦略的に統制を図っていく必要があります。docs.google.com前述の技術負債の解消後も、Liiga や Mond の実装に使われている技術との差異が残ります。Mond については事業フェーズが若いこともありソフトウェアとしての負債は限定的と捉えますが最新バージョンにアップデートされていない Vue.js/Nuxt と Ruby on Rails の抱える Liiga は既に実施対象です。Liiga は中途事業として大きく加速を目論むフェーズであり、技術負債の規模としても外資就活ドットコムほど大きくないため、Liiga のプロダクトロードマップのアイテムとのバランスを加味した上で、システム課題としてプロダクトロードマップに含めています。Vue.js/Nuxt のバージョンアップデートだけでなく、Frontend 技術の何をどこまで揃えていくのか、Backend 実装を Go 言語にしていくのか、そしてプロダクトを問わずシステムの冗長化をどのように図っていくのかを整理・議論しています。プログラム言語ごとの Lint ルール、テストや CI/CD の戦略、開発スタイルなどの改善も、システムの潜在的なリスクヘッジと開発生産性のボトムアップに向けて PDCA をはじめました。技術スタックや開発プロセスの統合だけでなく、各プロダクトのシステムに共通化するべき部分を統合することで、資源の投資効率を高める必要もあります。キャリアプラットフォームに分類される外資就活ドットコムと Liiga については特に、アカウントや認証の基盤を統合することで、新卒・中途という分類ではなくジョブ型雇用への転換をシステム面から推進することに繋がるでしょう。ただし、実行に向けては、外資就活ドットコムの技術的負債を解消しシステムの全容を明らかにした上での検討が必要になるため、現時点での具体的な計画には落としていません。課題を踏まえた今後について非連続な成長を遂げていくには上記の重点課題のみならず、それ以外や今後新たに発生する課題にも対処し、ひとりひとりだけでなく組織として進化していくことが必要不可欠です。ビジョンを見据えたプロダクトの勝ち筋、実現する組織の構造や仕組み・リーダーシップ、それらに欠かせないメンバーの活躍と成長など、向き合うべきことはたくさんありますが、着実に歩みをはじめています。これを加速させるには、志を同じくする仲間が必要です。既存事業が生み出すシナジーや今後の組織展望に興味がある方は、プロダクトやエンジニアリングのポジションのみならず、ビジネスのポジションを含めて様々なポジションがオープンしていますので、是非カジュアルにお話しましょう。recruit.howtelevision.co.jp1人1人の強みを理解し、それに敬意を払っていこう。チームハウテレビジョンにいるメンバーはさまざまな能力をもったプロフェッショナル。みんなが少しずつ違った強みを持つ、異能集団だ。エネルギー高いメンバーがぶつかりあって、化学反応が起き、絶大なバリューを生み出していく。そのためには相手の背景やこれまでやってきたことを十分理解し、どういった枠組みで価値を発揮しているのかに思いを馳せることがだいじ。価値観はみんな異なるのはあたりまえ。その大事にしたいことを受け止めて、さらに強いエネルギーを放出していこう。↩

ハウテレビジョンのプロダクトの現在地

ハウテレビジョンに4月から入社した新卒エンジニアの根本です。この半年間で経験した学びや働き方・挑戦した取り組みについての振り返りをしました。弊社での働き方について、解像度を上げることができたら嬉しいです。目次体制変更土台となる学び実務での成長フラットな組織での挑戦相互理解の機会の多さ充実したサポート入社前とのギャップこれからやっていくこと最後に体制変更一番驚いた出来事だったのは、元々技術顧問をされていた泉水翔吾さんがプロダクト本部長として7月から入社されたことです。執行役員人事に関するお知らせ｜株式会社ハウテレビジョンのプレスリリース多数の登壇経験や技術書の執筆など技術的な知識の高さのみならず、開発組織のマネジメントのご経験が豊富で、組織の動かし方について日々学ばせていただくことが多く、そのような方と距離の近い所で働けるのは貴重な機会だと感じています。そして、泉水さんの意思決定により、少なくとも今年度中はチームのほとんどの人員を割いて、外資就活ドットコムの技術負債解消に専念することになりました。まずは、外資就活ドットコムのweb版に関係する部分を優先し、CakePHP から Next.js + Go への移行が現在進行中です。土台となる学び一番大きいのが、新卒研修です。新卒ビジネス職の方と合同で、主にビジネスマナー・ロジカルシンキング・社内ルール・福利厚生・事業理解に関する内容でした。特徴は、新卒が5名と人数が少ないため、多くの研修が一方通行の内容ではなく、講師の方との双方向のやり取りに多くの時間を割くことができ、理解を深めることができたことです。個人的には、ロジカルシンキングに関する研修が仕事で成果を出す上で一番役立ったと感じました。なぜなら、仕事では、問題解決を行なったり、自分の考えをわかりやすく人に伝えるという場面が多く発生し、それを円滑に行うために必要だからです。次が、技術書の読書会です。読書は一人で行うこともできますが、人と一緒に読むと、見落としを早期に発見できたり、自分では思いつかない意見を知ることができることに気がつきました。半年間で以下の本を新卒エンジニア内やチーム内で一緒に読みました。SCRUM BOOT CAMP THE BOOKSQLアンチパターン単体テストの考え方/使い方フロントエンド開発のためのテスト入門エンジニアのためのドキュメントライティング以下は学びをみんなで分担してブログ記事にしたものです。第一回 課題図書知見共有会 ~SCRUM BOOT CAMP~ - ハウテレビジョン開発者ブログ第二回 課題図書知見共有会 ~SQLアンチパターン~ - ハウテレビジョン開発者ブログ実務での成長研修を挟みつつ、4月から実務で学んでいきました。私は技術に幅広く興味を持っているので、フロントエンドとバックエンドどちらもフルスタック触りたいので、希望に応じてどちらも任せて頂きました。（その人の希望に応じて、どちらかに専念することも可能です。）フルスタックであることも含め、手を出そうと思えば色々な所に手を出せるのが小さい組織の魅力だと思います。特にGoは初めて触る技術でしたが、最初は小さい部分の修正から徐々に慣れていったので、自然にキャッチアップができました。新入社員でも技術負債解消のタスクを機能単位で任せて頂けるので、挑戦的で裁量のある仕事だと思います。フラットな組織での挑戦年齢や年次に関わらず、意味のある提案が通る風通しの良い組織だと感じています。タスクに慣れた頃から、疑問に思う部分や改善できそうな部分を（新人ながら）色々な提案をさせていただきました。私の提案により、ドキュメンテーション・命名規則やユニットテストのルールの整備ある遅いページの高速化Github Copilot for Businessの導入などが実現できました。また、業務時間にカンファレンスに参加することもできました。新卒エンジニアが開発生産性Conferenceに参加した感想 - ハウテレビジョン開発者ブログ相互理解の機会の多さ新しく入社された方はもちろんですが、新卒には特にたくさんの相互理解の場が与えられたように感じます。まず、社内全体の場で自己紹介をする機会を頂きました。人によって時間の長さは自由ですが、少なくとも5分から10分程度の間、自分の話を聞いて頂けるのはとても嬉しいです。次に、それぞれの部署ごとに新卒と一緒にご飯を食べるウェルカムランチを開催して頂きました。これにより、社内のほとんどの方と会話することができました。また、研修の一環でインタビューをお願いしたり、同じチームのエンジニアの方に1on1を申し込んだりした時は快諾して頂き、お互いのことを知る機会になりました。特に、新卒同士では1on1やランチなどいつも同じメンバーでお互いのことを知る時間をたくさん取ることができたので、協力して仕事がやりやすいと感じています。充実したサポート開発環境に関しては、必要十分な環境を与えて頂けています。弊社では、エンジニアの入社時に好きなディスプレイ・キーボード・マウスなど伝え、会社のデスクに配備してもらえます。また、PCのスペックはMacBook ProのM2・メモリ64GBです。一部のデスクですが、スタンディングデスクも配備されています。また、定期的な1on1で悩み事や自分の課題や悩みについて気軽に相談することができました。週一で(先輩エンジニア)メンターとの1on1隔週で上司との1on1入社前とのギャップインターンでは時間の都合上システムの一部にしか関わらなかったのですが、入社してみて実際には社内システムなど複数のシステムが連携していて、全てを継続的に維持していく難しさを感じました。今回の技術負債解消プロジェクトでは、技術のリプレイスだけでなく、再び同じようなことが起こらないような仕組みづくりもやっていきたいと思っています。これからやっていくことやりたいことはたくさんありますが、まずはE2Eテストの導入に挑戦しています！これにより、細かいリリースをたくさんできるようにしていきたいです。これについては、また記事にしたいと思います。最後に半年間を振り返って、十分なサポートがありつつ、エンジニアとしてスピード感を持って色々なことができる環境が整っていると思いました。弊社での働き方に興味を持ってもらえたら嬉しいです。エンジニア募集中です！

新卒エンジニアが最初の半年間について振り返り

新卒エンジニアの根本です。7/13(木)に開催された開発生産性Conferenceに参加したレポートです。イベント概要　ここ数年で注目の集まりつつある”開発生産性”をテーマとして、「LeanとDevOpsの科学」の著者であるDr.Nicole氏の講演や各企業の取り組み事例の紹介など、最新の情報を学ぶことができるイベントです。個人的にも、開発で実現したいことが多くある中で、より素早く実現していくためにどんな行動を取るべきか知りたかったため、非常にタイムリーなイベントでした。今回はオフライン限定の講演が多く用意されていたため、オフラインで参加することに決めました。会場の様子　スポンサーを含めない現地参加者だけでもconnpassへの登録者は600名を超えていて、初めての試みにも関わらず会場にはたくさんの人が集まっていました。この様子からも、開発生産性への注目度の高さを感じます。さらに、Dr.Nicole氏の講演を除き、部屋別に並行して最大3つの講演が行われる形になっていたのですが、一部の講演では用意していた席では足りず、残念なことに別の会場へ移動せざるをえない状況でした。　スポンサーブースへのスタンプラリーが用意されており、すべてのスタンプをゲットすると景品が当たる抽選が回せる仕組みでした。以下の写真が各ブースで頂いた物です。特に印象に残ったのは、Route06社の”開発生産向上”というラベルのついたオリジナルドリンクです。スタンプラリーを制覇し抽選にチャレンジした結果、3等のAmazonギフト券を頂きました。講演の感想カンファレンスに参加する前は、”変更のリードタイム”や”デプロイ頻度”といった定量的に結果がわかりやすいものに興味があったのですが、講演を聞いているとそこを見るだけで開発を改善できるほど単純な問題ではないということがわかりました。「LeanとDevOpsの科学」は2017年までの少し古い情報であることを知ることができ、最近の情報のアップデートについて追従することができました。今回はGithub CopilotやAIがテーマではないにも関わらず、多くの講演で話題に上がっていました。当たり前かもしれないですが、それらを開発に活かせているかで今後大きな差になってきそうですね。終わりに　このような有益なイベントを無料で開催していただいたFindy社と、有益な講演をしてくださったゲストスピーカーの方々・スポンサー各社へ感謝します。また、業務時間にイベントへの参加を許して頂いた上長やチームメンバーの方々に感謝します。早速得た知見をまとめ、社内に共有しました。また、自身の仕事にも活かしていこうと思います。

新卒エンジニアが開発生産性Conferenceに参加した感想

はじめに私たち新卒エンジニア4名は、SQLアンチパターン を読み、第二回図書知見共有会を開催しました。今回この本を選択したのは業務で扱うことが多いにも関わらず、テーブル設計やSQLに詳しくないことが私たちの共通点だったからです。本稿ではSQLアンチパターンを読み終えた後の知見共有会についてまとめていきます。本の紹介SQLアンチパターン*1本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分かれて、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。データベースに関わるすべてのエンジニア必携の一冊です。得られた知見数字データは丸め誤差が起きるSQLのNULLの演算NULLとの不等号比較：NULL  NULL = FALSE、NULL > 値 = FALSE、NULL NULLとの論理演算：NULL AND TRUE = NULL、NULL OR FALSE = NULL、NOT (NULL) = NULL のように、NULLとの論理演算結果はNULLとなります。ただし、NULL AND FALSE = FALSE、NULL OR TRUE = TRUE とNULLにはならないので、注意が必要です。以上が、NULL演算の法則です。NULL値は特殊な値であり、通常のデータと同じように取り扱うことはできません。NULLを扱う際には、これらの法則を理解し、注意深く対応する必要があります。適切な場面でインデックスを指定しよう大量のデータが格納されるテーブルにインデックスを作成する：レコード数が多いテーブルは検索が遅くなりがちですが、インデックスを適切に設定することで検索速度を向上させることができます。特に結合操作やソート、集約関数の使用が多いテーブルには、インデックスの設定が有効です。適切な場面でインデックスを指定することは、データベースのパフォーマンス向上に直結します。効果的なインデックスの設定により、検索や結合操作の処理速度が向上し、データベースの応答性が向上します。一方で、上記で挙げたような目的以外でインデックスの過剰な使用や不適切な設定はデメリットをもたらす可能性もあります。インデックスはデータベースの容量を増やし、データの変更操作や新規データの挿入にも影響を与えることがあります。そのため、インデックスを設定したことによって逆にパフォーマンスが落ちることもあるので気を付けましょう。ディスカッション議題としては以下が挙がりました。画像の保存を外部に置くことはアンチパターン？SQLアンチパターン11章ファントムファイルよりトランザクション分離の問題データベースのバックアップツール使用時における問題これらの問題を踏まえ、本書ではBLOB型でDBに保存することを推奨しています。確かに本書に示すような問題はあるでしょう、しかしながらこれらの問題に気をつけてしっかりと管理をしていれば外部保存の手法も決して悪くはないのではないでしょうか？本書の知見、そして同期との議論を通し今まで当たり前にしていた実装を注意深く見れるようになったかもしれません。既にアンチパターンなテーブルと私たちはどう向き合っていくのか問題の洗い出しと理解：アンチパターンなテーブルに直面したら、まず問題点を洗い出し、その理由や背景を理解することが重要です。不適切な設計やパフォーマンスの低下など、具体的な問題点を把握しましょう。プロジェクトへのフィードバック：アンチパターンなテーブルに遭遇した経験や学びを、プロジェクトチームや上司にフィードバックしましょう。改善案や適切な設計原則の導入など、アンチパターンの予防策について提案することで、より良いデータベース設計への貢献が可能です。アンチパターンなテーブルと向き合うことは、新卒社員にとって大きなチャレンジですが、同時に成長の機会だと前向きに捉えたいです。同僚やメンターとの協力を大切にしながら、アンチパターンなテーブルに立ち向かいましょう。まとめ第二回図書知見共有会では読書前には知らなかった知識であったり、正しい実装と思っていたものが間違っていたりなどの発見がありました。今回話し合ったアンチパターンに心当たりがある一同。特にアンチパターンによってとんでもない技術負債が引き起こされるということを私たちは学びました。今後はアンチパターンを使ってしまわないよう細心の注意を払って業務に取り組んでいきたいと強く思いました。実際にテーブル設計をしてレビューし合う会をやってみよう！という話も出てきたり意欲的に学んでいく所存です。次回はどんな本を読むかは未定ですが、今回のように多くのことを学んでいければと思いますのでお楽しみに！*1:Karwin, B., Wada, T., Wada, S., & Kojima, O. (2013). Esukyūeru anchipatān. Orairījapan. SQLアンチパターン | Bill Karwin, 和田 卓人, 和田 省二, 児島 修 |本 | 通販 | Amazon

第二回 課題図書知見共有会 ~SQLアンチパターン~

はじめに弊社では、開発手法としてスクラムを導入しています。私たち新卒エンジニア4名はスクラム開発の経験がこれまでなかったため、まずは基本の型を知ろうということになり、SCRUM BOOT CAMP THE BOOK を課題図書にしました。そして今回、読後の疑問点を解消し、より理解度を深めるために、共有の場を設けました。本の紹介SCRUM BOOT CAMP THE BOOK“はじめて「スクラム」をやることになったら読む本"が7年ぶりに増補改訂!近年、より複雑化しているプロダクト開発をチームでうまく進めていく手法として、世界中で注目されている「スクラム」。実際の開発現場にどう適用すればよいのかを、とにかくわかりやすく解説しています。・理論だけで終わらない“実践"の手引き・架空の開発現場を題材に、実際のプラクティスを詳しく解説!話したこと弊社では開発チームの数が大きくないため、厳密なスクラムマスターをやっている人はいない。通常知識が属人化してしまうことは起こりがちなので、ドキュメントを作ることを促したり、ペアプロなど一緒に作業する時間を意識的に設けるようにしていくことが大事弊社ではNotionに情報を蓄積していくようにしていますタスクの完了条件をより明確にしても良いのではという意見デイリースクラムが15分よりも長くなってしまうことがある書籍には、人数に関係なくデイリースクラムを15分間で行い延長しないと書かれているが、延長してしまうこともしばしば話すべきことは全員に共有したいことだけで、個別に話しても済むことは後で話す時間を設けるように意識していきたい良かったこと全員が同じ開発チームのメンバーでなく、同じスクラムといえどもチームごとに少しやり方が違うため、チームごとにうまく行っている部分や改善したい部分を共有できた新卒ではあるが4月から徐々にタスクをこなし始めていたので、数スプリント経験した上での振り返りにもなった。また、課題点に対して次のアクションを議論することができた他の人の挙げた論点を再び本を見返し議論することで、一人で読むだけで終わるよりもスクラムに対する理解度を高めることができた。開発チームでは、実装した特定の人にしかコードの内容を説明できない、といった属人化は避けるのは難しい。しかし、スウォーミング（ペアプロ）によって、複数人のメンバーで同じタスクに取り組むことによって知識の移転を図ることができ、属人化をある程度避けることができると分かった。書籍には誰でもバックログに書き込めるようにするべきと書いてあり、開発チーム以外のメンバーがバックログに書き込めるようにすべきかどうかという議論ができた。まとめ今回は、スクラムガイド2017年版に対応し増補改訂された、SCRUM BOOT CAMP THE BOOK を新卒エンジニア4名で読み、そこから得た知見を共有しました。今後は書籍で紹介されていたようなスクラムの利点を活かした開発を進めていきます。次回は『SQLアンチパターン』を課題図書とし、開発チームに依存しない、DB設計やSQL記述の際のアンチパターンについて学ぼうと思います。

第一回 課題図書知見共有会 ~SCRUM BOOT CAMP~

東京ビッグサイト目的Nex Tech Week 2023春(2023年5月10日〜12日)に参加しましたので、そのレポートになります！弊社エンジニア4名が会場に足を運び、「AI・人工知能 EXPO」をメインに、最新のAI関連の情報をキャッチアップする目的で参加しました。各々が興味ある講演の聴講を事前に申し込み、その他の時間で出展ブースを見て回りました。聴講した講演は下記になります。5/10 午前: AIビジネス入門講座5/11 午前: 基調講演5/11 午後: 生成AIの未来AIビジネス入門講座初日の朝10時からスタートの講演になります、参加者が会場全体を埋まるほどの人気ぶりでした、AIを実際どうビジネスに生かすのか誰でも考えることでしょう、なのでこの人気ぶりは裏付けだと思います。講演の内容自体は2012年から登場するAIモデルの説明やHugging Faceの紹介までとコンテンツ盛りたくさんでしたが、制限時間45分という短い枠の中でもっと踏み込んだ話をするのは難しかったようです。基調講演「デジタルリテラシーからはじまるDX人材育成」デジタル人材育成とはこの公演の登壇者は以下の4名でした。データサイエンティスト協会 高橋 隆史氏情報処理推進機構 富田 達夫氏日本ディープラーニング協会 西山 圭太氏デジタルリテラシー協議会 小泉 誠氏4名の登壇者たちが「使って作ろうとは？なぜ重要なのか？」、「DX推進パスポート（３検定）はなぜ重要か？」、「生成AIでそう変わるか？逆に変わらないことは？」といったテーマを元に討論するといった公演でした。印象的だったお話が、写真にも書いてあるように、デジタル人材はデジタルを「知らない人」→「理解している人」→「使える人」→「活かせる人」→「作れる人」という順で進化していくそうで、中でもデジタルを「知らない人」は会社にとってマイナスの影響を与えるということです。特に、社内の上層部に「知らない人」がいるとDX化が進まないそうです。デジタルリテラシーから始まるDX人材育成は、企業の競争力向上につながる重要な要素です。今後は、社員全体がデジタルを理解し、課題に気づく人と技術を持つ人が協力することが求められます。デジタル化の波に乗り遅れないために、積極的な取り組みが必要です。生成AIの未来満席になる前の会場の様子この講演は始まる前から凄まじく、ただでさえ広い会場が満席となり立見が続出するというとんでもないセッションでした。それもそのはず、昨年話題となり今のAIブームの火付け役となったStable Diffusionを展開するStability AI Japan（株）のChi Jerry氏が登壇するためです。前半は昨今のAIの活用事例を紹介し、後半は生成AIが世の中をどう変えるのかといった内容となっていました。特に印象に残ったのは3ヶ月前に話題になった技術を「もう古い技術なんですが」と言ってしまうこの業界のスピード感です。市場価値はとんでもなく大きくなるAI業界から目が離せませんね。そしてビジネスへのAIの参入により我々はどのようなスキルを求められるのか、といったテーマでは「キュレータ、プロデューサとしての選ぶ力が重要なのだ」ということでした。未来のクリエイティブとは独自のものを選ぶことができることを言うのかも知れませんね。出展ブース見学出展ブースの様子出展ブースでは企業や団体、大学などが最新のAI関連プロダクトについて見学することができました。特に気になったテーマとしては、-  お問い合わせ系チャットbot- 画像解析AI- 会議のAIによる効率化- 人材育成あたりが弊社プロダクトへの展開をイメージでき、「こういうこともできるんじゃないか」というアイデアが浮かぶきっかけともなりました。さいごに最新トレンドをキャッチアップしたい技術者だけでなく、今後全てのビジネスマンがDXを推進しうまく使うこなすことが求められていく中で、非技術者の方にもおすすめできるイベントでした。次回は秋に同様のイベントが開催されるということなので、ぜひ興味ある方は足を運んでみてください。弊社では今後AIをプロダクトに落とし込んだ開発を積極的に実装していきたいと考えており、今イベントに限らず今後も最新トレンドをキャッチアップしていきたいと考えています。

東京ビッグサイトに行ってきました

目的AWS Summit 2023 に 4/20, 4/21 の両日とも現地参加が叶ったので、そのレポートとなります！セッションは正午から始まるものが多かったものの、海浜幕張まで移動する時間と体力がもったいないため、4/19, 4/20, 4/21 と2泊3日で千葉駅に宿泊しました。Expo業務で「これ SaaS にしちゃって楽したいなぁ」など漠然と思うことが多いですが、AWS Summit の Expo にたくさんの企業が出展しており、食指が動かされました。セッション昼から最後までがっつり参加してきました！【AWS-05】AWS サポートを賢く使ってコストもアーキテクチャも最適化しよう！こちらの講演はケースに対応するサポートエンジニアに関する内容でした。普段、困ったり焦った状態でケースをオープンすることが多く、情報量とかが少ない状態での問い合わせになりがちだったと反省しました...簡易的なシステム関連図再現性や頻度の共有発生日時 (分・秒・タイムゾーンまで)ログ原文 (スクショでない)などサポートエンジニアの方が必要とする情報は、私が社内で相談に乗るさいに欲しいと思う情報と同じで「分かる！」という感じでした他にも、実際のケースを事例として紹介いただき、内容が Linux のシステムコールの話などまで展開したり内容が充実していました。さいごに久しぶりのオフライン開催ということで、来場者も多く賑わっている雰囲気は懐かしかったですね！来年も開催したら行きたいと思います！

幕張メッセに行ってきました

チームトポロジーこんにちは、SREチームの小川です。はじめにblog.howtelevision.co.jp以前『SCRUM BOOT CAMP THE BOOK』の読書会を始めたエントリーを投稿しました。ハウテレビジョンの開発部では各チームともスクラムを導入していましたが、読み進める中で「できていること」や「できていないこと」を発見できました。振り返り運営面前回のエントリー時点ではY: やれていること、うまくいっていることW: わかったこと、できていないことT: 次やること、やってみることを Milanote で各員殴り書きして意見を共有しあう形式で運営していました。T の Next Action の意見はバージョン管理して振り返りをしっかりと行うべく、 YouTrack で管理するようにしました。YouTrack で Next Action 管理実務面読書会の振り返りを建設的に行うことが可能となったことで、ハウテレビジョンの開発部でどのような変化が現れたかみていきます。1. デイリースクラムがブラッシュアップされたワークフロー2. 好き嫌い表3. YouTrack を使いこなせ他にも、読書会を通してスクラムについて理解が深まったからこそ、スクラムを続けるべきか？といった意見もあり、今後も開発をより良くするために色々な変化が起こるのではないでしょうか！読み終えてからさて、このように読書会でチームを横断して、何かのテーマについて議論することで学びが多かったため、引き続き読書会は継続しようということになりました。『チームトポロジー』となった決め手は普段技術書ばかりなため非技術的テーマの書籍が新鮮で学びに溢れていること馴染みのないテーマでも全員で議論できるため怖くないだろうという希望的観測弊社の技術顧問の推している書籍であることなどでした。書籍の候補一覧『チームトポロジー』 １章・２章を終えて抽象度が高く読み応えがあり、また議論の余地が非常に多く、活発な意見交換を行うことができています。日々業務をしているとなんとなく感じる、「今日やらないといけないこと多いな...」であったり、同じ日に複数プロダクトでの作業でコンテキストの切り替えに負担を感じた経験などは、感情論になりがちで言語化がおざなりになり課題の議論と本質的な解決策の模索が難しいところです。スクラムは開発を良くする手段ですが、チームトポロジーでは開発組織の課題は何か、への言及があり、課題がどのように生じるかについて学び、それに対応するためにスクラムのエッセンスを利用することができれば良いなと考えています。さいごにちょっと難しい本に手を出してしまった感がありますが、参加者の中に不安を抱えたメンバーはおらず、むしろ他人と意見を共有しながらなら読み続けることができる！といったポジティブな雰囲気であるのは、読書会の醍醐味といったところでしょうか。ハウテレビジョンの開発部では読書会などの不断の努力によって、チームのプロダクト生産性を日々高めております。ぜひ一緒に取り組んでくれるエンジニアの方、募集しております！

『チームトポロジー』の読書会がはじまりました

導入こんにちは、データ分析PJTの縄司です。寒気の流入が顕著になり、西高東低な気圧配置が頻繁に見られる冬が訪れてきましたね。今年は寒くなるのでしょうか？気になった方はAOI(北極振動指数)やエルニーニョ現象、ラニーニャ現象の詳細をぜひご覧になってください。肌の潤いは失われビニールの袋を開けるのに苦戦する日々を送っています。さて今回は弊社データ分析基盤刷新のお話しをさせていただきます。内容従来のデータ分析基盤アーキテクチャ弊社のデータ分析アーキテクチャは上のようになっており、MySQLやBigQueryで集めたデータをRedashに集約してデータの分析・可視化を行なっておりました。異なるデータソースを結合するQuery Resultsや豊富なチャート機能は便利ですが、日頃データ抽出やデータの整合性を確認する時にどのクエリを見ればいいの?といった疑問が業務の中でたくさんありました。課題上記アーキテクチャでの問題点は次が挙げられます。管理されていないクエリの溜まり場  Redashは気軽にクエリを実行し、データ可視化を自動的に行ってくれ、容易に解析することができます。その反面Redashは構造上、クエリをArchiveにはできるも削除することができません。そのため、誰かが作成したクエリが残り続けてしまい欲しいクエリを容易に見つけることができないです。また、間違ったクエリも混在していました。  これによって、KPIや解析のために作成したクエリで正しいデータはどれなのかわからない現象が起こっていました。データの一元管理ができていないため柔軟に分析ができない  MySQLとBigQueryをそれぞれデータソース、データレイクとして位置付けていますがそれらのデータを連携する場所はRedashのみとなっています。そのため、Data Ware HouseやData Martの作成はRedashに依存しており他の環境で分析することが困難でありました。また高い負荷がかかってしまい動かなくなることもしばしば起きていました。SQLの知識が必須  Redashではクエリやプログラミング(主にpythonやGA api)の知識があってこそ分析できるツールであり、非エンジニアにはハードルが高いです。そのため分析する際に属人的になってしまい、課題解決の速度や検証の柔軟性に大きな弊害となっていました。不要なコスト  Redashでは、BigQueryとの連携が可能であるが、クエリの実行にはコストが発生します。そのために起きていた問題として、定期実行されていたクエリが、作り直しによって利用されなくなったあとも解除されず、コストが発生し続けていました。これらを解消し、データ分析基盤として更なる進化を遂げるためにアーキテクチャを一から見直し次のように再構築しました。基盤刷新後新データ分析基盤アーキテクチャこれにおいて改善されたことは大きく3個あります。データの一元化 データレイク及びデータウェアハウス、データマートをBigQueryに置き、データソースや他ツールによるデータを一元管理するように変更しました。これによりBigQuery内でデータ加工が完結し、様々なデータの連携が可能になります。データソースをBigQueryに移送するツールとしてはAirbyteを採用しました。AirbyteはOSSでコストがかからずELTとしてGUIで直感的に操作できるのが魅力です。重要なクエリの管理 正しいデータがわからない。同様のクエリで無駄なコストが発生する。を防ぐため重要なクエリをDBTで管理することにしました。DBTはETLの”T”(Transformation)を担ってくれるOSSツールで、無料ながら機能が充実しており、コード管理やテスト機能、メタデータ管理を提供してくれるツールです。DBTを使用してSQLコードをGit管理でき、レビューを持って正しいデータを維持できる体制を整えました。 また定期的に出力する必要があるデータのために、DBTをcronjobで定期実行するように環境を作っています。Tableauの導入 非エンジニアでも属人的にならず、自主的に分析ができるようTableauを導入。直感的にデータ加工、データ可視化ができる環境を整えました。またTableauはRedashよりもvisualization機能が充実しており手軽に分析や予測が可能なのが魅力です。現在はRedashや自社開発した数値観測をTableauのダッシュボードに移行しています。以上のように、安全で継続的に正しい数値を観測できる環境を目標にデータ分析基盤を再構築しました。Airbyte・DBTの管理弊社のサービスでは、本番環境と開発環境をAWSのECS、ECRで管理しています。SREチームと協力をいただき実装しました。余談まだまだ発展途上のAirbyteでは重要な課題がありました。それは、Airbyteには実行スケジュール機能が実装されていますが、例えば24hour実行に設定すると前回実行完了してから24hour後に再実行されることがたまに起こります。これでは5:30 AMに定期的に移送したいデータがあった場合徐々に時間が遅れていき、ユーザーが活発な時間に移送が実行されサービスに支障をきたす可能性があります。この対策は公式には無かったのでこちらを元にカスタマイズしました。幸いにもAirbyteにはAPIでの連携が可能であったため(https://airbyte-public-api-docs.s3.us-east-2.amazonaws.com/rapidoc-api-docs.html#auth)、任意なタイミングで実行することが可能でした。これを元にcronjobで理想的な時間にデータ移送ができるようになりました。今後の課題Tableauを導入してから日にちが浅く、全社的にデータドリブンな文化を築けているわけではありません。今後は、手軽に分析できる環境を周知および浸透させられればと思っています。また採用したDBTに関しても知識のキャッチアップや技術の活用が不十分であるため、より安全で継続的であり、活用しやすいデータ分析基盤に確立するために精進していこうと思っております。終わりハウテレビジョンの開発部ではチームのプロダクト生産性を日々高めております。ぜひ一緒に取り組んでくれるエンジニアの方、募集しております！herp.careers

データ分析基盤のカオスに平穏をもたらした話

SCRUM BOOT CAMP THE BOOKこんにちは、SREチームの小川です。はじめに社内の有志が集まり「SCRUM BOOT CAMP THE BOOK」を読みました。これまでは各チームのリートエンジニアが創意工夫を凝らし、より良いスプリントを実施できるように取り組んでいました。いざ読書会初めての読書会ということもあり手探りで始めています。読書会の目的と今回のテーマを共有（2分）読む（15分）振り返り（40分）読書会の振り返り（3分）振り返りについては milanote を使用して、YWT というフレームワークを採用しました。普段のスプリントレトロスペクティブでは KPT を使用していますが、読書会で学んだことをよりポジティブに捉えられるようにこちらを採用しています。読書会にあわせて少しニュアンスを変更しました。Y：やれていること、うまくいっていることW：わかったこと、できていないことT：次やること、やってみること読書会の目的と今回のテーマを共有人によって参加の目的やスクラムへの理解度もバラバラなため、ここで目的をすり合わせています。読む事前に各々が指定した章を読んでおくやり方もありますが、初めてということもあり肩肘張らずに読書会を行いたかったため、事前課題のようなものは設けませんでした。書籍の詳細についてはここでは触れませんが、2017年のスクラムガイドをもとにスクラムの概要の説明がされていました。振り返りY：やれていること、うまくいっていること指定した章を読み終えて、現在の開発部のスクラムについて、「やれていること、うまくいっていること」というポジティブな点について意見交換を行いました。やれていること、うまくいっていることW：わかったこと、できていないこと初回ということもあり、書籍にある通りにできていないという反省の色が少し多くなっています。また、スプリントレビューで成果物をステークホルダーにチェックしてもらうことができていないことも反省としてあげられました。わかったこと、できていないこと次やること、やってみること読書会を経ての Next Action についても意見交換を行いました。スプリント内で行うタスクのプランニングは、エンジニアとして見えやすいところではありますが、意外とそのタスクを終えた時にどのような状態になっていたいか、という目標の設定が曖昧になっている場合があるため、改めてゴールを明確にしていきたいという意見が上がりました。次やること、やってみること読書会の振り返り（3分）初めての開催ということで読書会自体の振り返りも入れていましたが、時間配分や設計も問題なく活発に話し合いが行われていたためこちらはスキップとなりました。次回以降進めていく中で新たに改善点が出てくることもあると思うので、ここも大事にアップデートしていきたいです。さいごに初めての読書会ということで手探りな中で始まった取り組みでしたが、参加者全員が「スクラムを理解して、より良いプロダクト開発を行いたい」という思いを持っていたため、非常に有意義なものとなりました！またすでに取り込むことができているスクラムの要素もありましたが、改めて掘り下げてそれぞれの定義を理解することで、今後のスクラムを改善していくためにやるべきことの解像度が高くなりました。全体の総意として好感触を得ることができたため、これで終わりにせず今後も継続的に「SCRUM BOOT CAMP THE BOOK」の読書会を実施していきたいものです！ハウテレビジョンの開発部では読書会などの不断の努力によって、チームのプロダクト生産性を日々高めております。herp.careers

SCRUM BOOT CAMP THE BOOK の読書会はじめました

こんにちは、SREチームの小川です。今回は「外資就活への扉」である、ALB・Route53をSREがどのように管理しているか紹介したいと思います！はじめに以前よりSREチームが「外資就活ドットコム」のインフラをEC2中心のものから、コンテナ中心のEKSへと移行したお話をしてきました。AWS Load Balancer ControllerとExternalDNSを利用して管理を行うようにしたお話しをします。EKSのサービスをALBを利用して公開する際に、アプリケーションコンテナをNodePortで公開し、ALBがNodeGroupの特定のNodePortにリバースプロキシするなどがあります。AWS Load Balancer Controllerを利用すると、Ingressリソースを元に作成されたALBは、アプリケーションコンテナのClusterIPを解決してリバースプロキシすることができるようになります。AWS Load Balancer Controllerを採用しました。またExternalDNSを併せて利用することで、特定のIngressリソースから作成されたALBのルールを元に、自動でRoute53にレコードを登録することができます。rulesパラメータを設定するだけで、公開したサービスを名前解決することができるようになります。AWS Load Balancer ControllerのデプロイAWS Load Balancer Controllerを利用してALBを作成するためにはSecurityGroupIAMロールaws-load-balancer-controlleringressの定義をする必要があります。このうち、1・2はTerraformで構成管理し、3・4はK8sのマニフェストで管理しています。SG, IAMロールSGは適宜インターネットなどに公開したいポートをオープンにしたものを定義します。公式ドキュメントに酷似した定義を利用しているため割愛します。IAMロールは以下の通り定義します。IRSAで関連づけることを目的としたリソースとなっています。Federatedにすることで、EKSのOIDC ID プロバイダとIAMロールを関連づけています。resource "aws_iam_openid_connect_provider" "eks_oidc" {  url = var.eks_oidc  client_id_list = [    "sts.amazonaws.com"  ]  thumbprint_list = [data.tls_certificate.eks_oidc.certificates[0].sha1_fingerprint]}data "http" "alb_management" {  url = format(    "https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/%s/docs/install/iam_policy.json",    var.alb_version  )}data "aws_iam_policy_document" "alb_management" {  statement {    effect = "Allow"    principals {      identifiers = [aws_iam_openid_connect_provider.eks_oidc.arn]      type        = "Federated"    }    actions = ["sts:AssumeRoleWithWebIdentity"]    condition {      test     = "StringEquals"      variable = format("%s:sub", replace(aws_iam_openid_connect_provider.eks_oidc.url, "https://", ""))      values = [        "system:serviceaccount:kube-system:aws-load-balancer-controller"      ]    }  }}resource "aws_iam_role" "alb_management" {  name               = format("%s-%s-alb-management", var.env, var.project)  assume_role_policy = data.aws_iam_policy_document.alb_management.json}resource "aws_iam_role_policy_attachment" "alb_management" {  policy_arn = aws_iam_policy.alb_management.arn  role       = aws_iam_role.alb_management.name}resource "aws_iam_policy" "alb_management" {  name   = format("%s-%s-alb-management", var.env, var.project)  policy = data.http.alb_management.body}aws_iam_openid_connect_providerのurlに渡す値は下記のように取得可能です。output "eks_oidc" {  value = aws_eks_cluster.cluster.identity[0].oidc[0].issuer}aws-load-balancer-controller外資就活ドットコムではK8sリソースのデプロイ管理にArgo CDを利用しています。apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:  name: aws-load-balancer-controllerspec:  project: gaishishukatsu  source:    repoURL: マニフェストのGitHubリポジトリURL    targetRevision: main    path: alb/overlays/x  destination:    server: https://kubernetes.default.svc    namespace: kube-system  syncPolicy:    automated:      prune: true      allowEmpty: true    retry:      limit: 0      backoff:        duration: 10s        factor: 1---apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:  name: cert-managerspec:  project: gaishishukatsu  source:    repoURL: マニフェストのGitHubリポジトリURL    targetRevision: main    path: cert_manager/overlays/x  destination:    server: https://kubernetes.default.svc    namespace: cert-manager  syncPolicy:    automated:      prune: true      allowEmpty: true    retry:      limit: 0      backoff:        duration: 10s        factor: 1ArgoCDがrepoURLからポーリングするaws-load-balancer-controllerのマニフェストは、Kustomizeを利用して下記のように定義しています。# base/kustomization.yamlbases:  - https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/${controllerのversion}/docs/install/${controllerのversion}full.yaml# overlays/x/deployment-patch.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: aws-load-balancer-controller  namespace: kube-systemspec:  template:    spec:      containers:        - name: controller          args:            - --cluster-name=cluster            - --aws-region=ap-northeast-1            - --aws-vpc-id=EKSの所属するVPCのID          env:            - name: AWS_DEFAULT_REGION              value: ap-northeast-1            - name: AWS_ROLE_ARN              value: Terraformで作成したIAMロールのARN            - name: AWS_WEB_IDENTITY_TOKEN_FILE              value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token# overlays/x/service-account-patch.yamlapiVersion: v1kind: ServiceAccountmetadata:  name: aws-load-balancer-controller  namespace: kube-system  annotations:    eks.amazonaws.com/role-arn: Terraformで作成したIAMロールのARN# overlays/x/kustomization.yamlresources:  - ../../basepatchesStrategicMerge:  - service-account-patch.yaml  - deployment-patch.yamlingress下記のようなIngressを作成することで、ALBが80,443番で公開され、K8sのapp-svcというClusterIPへとリバースプロキシすることができます。alb.ingress.kubernetes.io/load-balancer-attributesというアノテーションを設定することで、別途Terraformで作成したS3へALBのログを保存することや、alb.ingress.kubernetes.io/wafv2-acl-arnでWAFを設定することもできます。apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: app-ingress  namespace: app  annotations:    kubernetes.io/ingress.class: alb    alb.ingress.kubernetes.io/group.name: "public"    alb.ingress.kubernetes.io/scheme: internet-facing    alb.ingress.kubernetes.io/target-type: ip    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'    alb.ingress.kubernetes.io/security-groups: Terraformで作成したSGのID    alb.ingress.kubernetes.io/certificate-arn: HTTPSの場合にはTerraformで作成したACMのARN    alb.ingress.kubernetes.io/actions.app: "{\"type\":\"forward\",\"forwardConfig\":{\"targetGroups\":[{\"serviceName\":\"app-svc\",\"servicePort\":80}]}}"spec:  rules:    - host: app.gaishishukatsu.com      http:        paths:          - backend:              service:                name: app                port:                  name: use-annotation            pathType: ImplementationSpecific---apiVersion: v1kind: Servicemetadata:  name: app-svc  annotations:    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP    alb.ingress.kubernetes.io/healthcheck-port: traffic-port    alb.ingress.kubernetes.io/healthcheck-path: /healthz    alb.ingress.kubernetes.io/healthy-threshold-count: '5'    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '300'    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'    alb.ingress.kubernetes.io/success-codes: '200'spec:  type: ClusterIP  ports:    - name: "http"      protocol: "TCP"      port: 80      targetPort: 80  selector:    app: appExternalDNSここまででALBを作成することができました。ここからはExternalDNSを利用して、作成したIngressからRoute53のレコードを登録するためのマニフェストの管理を紹介していきます。IAMロール本来はIRSAを利用したいですが、EKSノードにRoute53を操作可能なIAMロールをアタッチしています。data "aws_iam_policy_document" "eks_node_route53_policy" {  statement {    effect = "Allow"    actions = [      "route53:ChangeResourceRecordSets",      "route53:ListHostedZones",      "route53:ListResourceRecordSets"    ]    resources = ["*"]  }}external-dnsArgoCDとKustomizeを利用してデプロイしています。--annotation-filterで先ほど作成したIngressのアノテーションalb.ingress.kubernetes.io/group.nameを指定することで、特定のALBのルールを管理することができます。upsert-onlyではレコードの新規作成と上書きができ、レコードの削除は行わないようになっています。開発環境などではsyncにすることで削除も行うことが可能となるため、検証がスムーズに進みます。Kustomizeを利用することでこの辺の環境差分を管理することが可能です。このマニフェストのデプロイに成功することで、gaishishukatsu.comというホストゾーンに レコード  Type  値  app.gaishishukatsu.com  A (エイリアス)  ALBのDNS名 というレコードを作成することができます。これで本エントリーの目的である、ALBの公開とDNSでの名前解決が達成されました。# base/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: external-dnsspec:  strategy:    type: Recreate  selector:    matchLabels:      app: external-dns  template:    metadata:      labels:        app: external-dns    spec:      serviceAccountName: external-dns      containers:        - name: external-dns          image: k8s.gcr.io/external-dns/external-dns:tag# overlays/x/deployment-patch.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: external-dnsspec:  template:    spec:      containers:        - name: external-dns          image: k8s.gcr.io/external-dns/external-dns:tag          args:            - --domain-filter=gaishishukatsu.com            - --annotation-filter=alb.ingress.kubernetes.io/group.name in (public)            - --provider=aws            - --policy=upsert-only            - --source=service            - --source=ingressまた、外資就活ドットコムはインターネットに公開していますが、バックオフィス向けのサービスなどについてはVPNからのアクセスしか許可しない体制をとっています。aws-load-balancer-controllerとexternal-dnsを利用している場合には、Ingressを追加しalb.ingress.kubernetes.io/group.name: "vpn"など、別のグループを指定することで複数のALBを管理することができます。external-dns側ではannotation-filterを別途作成したIngressのアノテーションにし、argsに--aws-zone-type=privateを追加することで、プライベートなDNSレコードを利用した名前解決により、閉ざされたネットワークでサービスを公開することができます。さいごにここまでが外資就活ドットコムのトラフィックの入り口を、SREチームでどのように管理しているか紹介でした。他にもexternal-secrets + Secrets Mangerであったり、ArgoCD + ArgoCD Notificationsなど、K8sのエコシステムを活用した取り組みを行なっています。こういった挑戦できる機会が外資就活にはあります。「これを使ってもっと良くしたい」とか「あそこはこうしなきゃ...」など改善していきたいと考えています。一緒に取り組んでくれるエンジニアの方、募集しております！

AWS Load Balancer ControllerとExternalDNSを利用しています

SREチームの肥沼(clover0)です。少し前にSREの取り組みの紹介として、Kubernetesへ移行した基盤刷新を紹介する記事を執筆させていただきました。今回は、基盤刷新を行うにあたって、チームで日々取り組んできたことを紹介します。blog.howtelevision.co.jpSREはじめに、SREについて簡単に説明します。Site Reliability Engineeringの略で、「サイト信頼性エンジニアリング」と訳されることが多いです。数年前に、いわゆるSRE本が出版されたことから、SREが広く知られるようになってきました。SREとは何か？をめちゃめちゃざっくり説明すると、サービスの信頼性をソフトウェアを書いて担保すること、になりそうです。SREそのもののちゃんとした説明は今回は省きます。ハウのSREチームSREチームという名前で活動していますが、実際のところ、信頼性を担保する部分だけではなく、プロダクト開発のスピードを維持することや、向上させるために必要なことにも取り組んでいます。ハウのSREチームでは、冒頭にあげたSRE本に書かれていることを意識しつつも、日々改善を続けていけるようにすること、プロダクトの価値を最大化すること、を目標として活動しています。例えば、Datadogを使った問題の発見や改善がSREチームだけでなく、開発全体としてできるように民主化を行ったり、コストコントロールやアプリケーションのパフォーマンス改善を行なったりもしています。SREがいなくてもできるようにしていくこと、SREが中心となって引っ張ること、も意識しています。またハウのSREチームは、開発のプロジェクトごとにメンバーをアサインするスタイルではなく、プロダクト横断で担当しています。現状、プロダクトの数が多いわけではないので、SREチームとしてプロダクト開発に関わっています。こうすることで、SREのあるメンバーがプロジェクトに入って担当して終わったら戻るスタイルではなく、常にSREの誰かがやっていることはSREの他の誰かにも見えるように工夫しています。SREチームの関係チームの立ち上げさて、紹介するSREチームですが、自分がSREチームに入ってからSREチームを再編成しています。以前は、SREを始めたが課題が多くて、チームで取り組むというより、アウトプットの量を重視して個人が諸々のピンポイントの課題に取り組んでいる状態でした。EC2の運用からKubernetesへ移行する予定があったので、達成するために、まずはチームで取り組んでいけるようにする必要があると考えました。基盤の刷新は、ただやって終わりではなく、今後の土台となるため、通常の機能開発側の連携も必要であり、移行後は滞りなくサービスが稼働すること、移行後も運用を続けられること、が必要です。そのため、情報共有で効率を上げたりチーム開発のレベルも上げていくことを目指し、チームで取り組んでいけるような体制を構築しました。弊社SREの歴史新生SREチーム新しく編成し直したSREチームでは、以下のようなことをやってきました。日々のコミュニケーションメンバー全員、ほぼリモートだったのでSlackやZoomなどをメインにコミュニケーションを取ってきました。もともとslackでSREチャンネルがありましたが、チームがメインで活動するチャンネルとして定義し直しましたSREは常にここで情報を共有したり、他のチームからも依頼や相談があったりしますissueが作られたことや、コメントはslackに流れるようにしているので、だいたいここを見ていれば他のメンバーが何をやっているかが分かるようになっています議論や意見、ナイスな対応など、コメントが飛び交いますslackチャンネルを複数作ったりせず、チームがどこを見ていればよいのか？をシンプルにすることで、リモートでも円滑に進めているのではないかと思います。振り返り、SREの予定づくり毎日15分SREチーム全員が同じところに集まることやったこと、やることの発表ではなく、チームとして共有しておくべきことを共有する2週間に一度、振り返りと次の2週間の予定を立てるsmall,medium,largeのような感じで日々issueにラベル付けしているので、ラベルが付いているもので予定するissue管理日々、こうしたほうがいいな、こうだったらいいな、と思うことはissueとしてアウトプットするissueに最低限書くことの簡単なルール化どうしてそのissueを書くことになったのか？なにをやったらよさそうか？どういう状態が終わりなのか？GitHub Issueのラベルを明確にして、ラベル付けを丁寧にやる着手する前にそもそも議論が必要なこと、急ぎの対応が必要なこと、などが分かるようにするドキュメンテーションチームで苦にならず、継続できる方法を模索しながら運用しています。ざっと以下のような感じで、ドキュメントを書いたり、管理したりできるようになってきました。弊社ではドキュメント管理ツールとしてNotionを利用しています。大事なことは書く、slackで終わりはもったいないドキュメントは、それが何のために書かれているのか最初に書くことissueに残すもの、Notionに書いておくべきものを分けて残していく調査メモなど、終わったらほとんど見返さないものはissueにそのまま残しておいてもよいある程度情報が多くて、まとめておきたいものはNotionに書くある時期だけ役目を果たすものと、そうでないものを区別する永続的に更新、他の人の役に立ちそうなドキュメントの配置は、アクセスしやすいように配置するあるリポジトリ内だけで済むようなものはそのリポジトリのREADMEに書くPR、レビュー弊社では、プルリクエストベースで開発を行なっておりますが、PRを出してからマージできるまでに時間がかかってしまい、予定をコントロールするのが難しい状況でした。改善するために、おもに以下のようなことをやってきました。レビューする人は、レビュー依頼出している人がなるべく速くマージできるようにしてあげることを意識する直してほしいことはちゃんと指摘する直してほしいけど、別のタイミングでもよければissueを作って対応を促すレビュー依頼する人は、レビューしやすいようにPRを作る自分しか持っていないと思われる知識は、説明して共有することを意識するPRの目的を書くPR外で必要なことを明記するコミットメッセージを分かりやすくするAngularのコミットメッセージ運用を参考に整備して、運用していますPRで議論になりそうなことは、issueを挙げてissueで議論する意識する、というのが多いですが、チームで日々感じていたことを言語化しただけでも、取り組めるようになりました。こういうPRだといいよね、というのが1つでもできると、毎日15分集まっている時間で、こうしましょう！と共有することができます。さいごに振り返ってみると当たり前のことかもしれません。日々、もやもやしていることに対して1つずつチームでできるようにしていくことは、時間がかかることですが、後々大きな武器となることを感じられたチームビルディングでした。最終的にこのチームで、無事に基盤刷新が達成され、Kubernetes上で稼働しています！herp.careers

Kubernetesへ移行できるSREチームになるまでにやってきたこと

こんにちは、SREチームの小川です。作られる壮大な物語が始まったのでしょうか。作り出したので、今回の記事ではその軌跡をご紹介します！はじめに外資就活運用基盤刷新記事の第２弾です。TerraformとはIntroduction to Terraformこうした柔軟性はクラウドの利点である反面、その手軽さからインフラリソースを無計画に作成することで管理が不行き届きになってしまうことがままあります。外資就活のTerraformまず、Terraformを外資就活に導入するに際して意識したことや解決した課題がありますが、御託を並べる前にTerraformがどのように運用されているか紹介します。導入・運用に当たって意識したことTerraformを導入する１番の目的は、効率的にインフラリソースを管理することです。変更に強く保守性の高いディレクトリレイアウトを採用するモジュール機能を積極的に利用してTerraformをDRYに保つ環境ごとの差異は変数として切り出すことで変数以外の差が環境間で起きないようにするworkspaceを利用して環境の複製を容易に行えるようにするディレクトリレイアウトTerraformの利用にあたっては、変更に強いIaCを実現するためにディレクトリレイアウトの設計が重要になりますが、外資就活では下記のレイアウトを採用しています。ありきたりではありますが、AWSのサービス単位でモジュールを作成し、envディレクトリ以下でパラメータを注入してモジュールを呼び出しています。├── _modules│   ├── alb│   ├── domain│   ├── ec2│   ├── eks│   ├── memcached│   ├── mysql│   ├── redis│   └── s3└── env    ├── dev    │   ├── locals.tf    │   ├── main.tf    │   ├── output.tf    │   ├── dev01.terraform.tfvars    │   ├── provider.tf    │   └── variables.tf    ├── prd    │   ├── locals.tf    │   ├── main.tf    │   ├── provider.tf    │   └── variables.tf    └── stg        ├── locals.tf        ├── main.tf        ├── output.tf        ├── provider.tf        └── variables.tfモジュールEC2やRDSなどAWSサービスのテンプレートを定義できる機能です。マシンスペックなどはprd,stg,devで異なることが一般的ですが、マシンスペックごとにリソースの定義をしていては効率的にIaCを行えているとは言えません。たとえば、EKSクラスタの作成に関しては_modules/eks/eks.tfで下記のようにリソースを定義してテンプレート化します。resource "aws_eks_cluster" "cluster" {  name     = format("%s-%s-cluster", var.env, var.project)  role_arn = aws_iam_role.eks_cluster.arn  version  = var.eks_version  vpc_config {    subnet_ids = var.subnet_ids    security_group_ids = [      aws_security_group.cluster_sg.id    ]    endpoint_private_access = true    endpoint_public_access  = false  }  enabled_cluster_log_types = var.eks_log_enabled ? var.eks_log_types : null  tags = merge(    var.tags,    tomap({ Name = format("%s-%s-cluster", var.env, var.project) })  )  depends_on = [    aws_iam_role_policy_attachment.eks_cluster_policy,    aws_iam_role_policy_attachment.eks_service_policy,    aws_cloudwatch_log_group.eks  ]}このようにすることで、productionはEKSのバージョンが1.19で動作しているが、developで1.20の動作確認がしたい場合に、developでモジュールを呼び出す際にvar.eks_versionの値を1.20にすることで、productionに影響を与えることなく、developで新しいバージョンのEKSの動作確認を行うことが可能になります。環境差分各モジュールでマシンスペックなど環境ごとに差分が生じるパラメータを変数で定義しています。そしてenvディレクトリ以下のmain.tfでモジュールを呼び出す際に、変数に値を指定することで環境差分を管理可能にして柔軟な対応が可能となるようにしています。さきほどのEKSモジュールを利用してEKSクラスタを作成する場合には各envディレクトリ内のmain.tfを下記のようにします。module "eks" {  source          = "../../_modules/eks"  env             = terraform.workspace  project         = local.project  eks_version     = var.eks_version  eks_log_enabled = var.eks_log_enabled  eks_log_types   = var.eks_log_types  subnet_ids      = module.network.private_subnet_ids["eks"]  tags = {    Project = local.project    Env     = terraform.workspace  }}そしてdevelopではEKSバージョンを1.20で、ログ取り込みによるAWSコストの上昇を抑制するためログを収集しないようにし、productionではEKSバージョンが1.19で、ログはしっかり収集したい場合には、変数の定義を下記のようにします。※ tfvarsとlocals.tfとファイルの種類が異なるのは、一部workspaceを利用しているためです。## env/dev/dev01.terraform.tfvarseks_version     = "1.20"eks_log_enabled = falseeks_log_types   = []## env/dev/variables.tfvariable "eks_version" {}variable "eks_log_enabled" {}variable "eks_log_types" {}## env/prd/locals.tflocals {  eks_version     = "1.19"  eks_log_enabled = true  eks_log_types   = ["api", "audit", "authenticator", "controllerManager", "scheduler"]}## env/prd/variables.tfvariable "eks_version" {}variable "eks_log_enabled" {}variable "eks_log_types" {}workspace外資就活のTerraformでは、prd,stg,devといった環境の単位をenv以下にディレクトリで表現しています。workspaceはenv/dev/ディレクトリで、例えばdev02を作成したい場合に下記コマンドを実行します。terraform workspace new dev02あとはenv/dev/main.tfに渡す変数の値をdev02.terraform.tfvarsに定義し、適用時には-var-file dev02.terraform.tfvarsオプションを指定して実行します。このようにすることで、main.tfで指定したモジュールで定義したリソースを新たに作成することが可能です。## env/dev/dev02.terraform.tfvarseks_version     = "1.19"eks_log_enabled = trueeks_log_types   = ["scheduler"]workspaceを利用しない場合には、env/dev/のようなディレクトリが環境の数だけ増加してしまいますが、workspaceを利用することで簡単に管理を行うことができます。そしてこの特徴は環境を増やす要望が出やすいdevelopと親和性が高いと判断したので導入しています。一方でprd,stgについては、workspaceでの管理には特性上向いていないと判断し、ディレクトリによる管理を行うことにしています。module "domain" {  source = "../../_modules/domain"}module "eks" {    ## <=== このモジュールだけ利用しないという柔軟な選択ができない！  source = "../../_modules/eks"}module "alb" {  source = "../../_modules/alb"}またworkspaceはterraform workspace select xxxで選択しますが、単純にこのコマンドを忘れたために切り替え漏れによるオペレーションミスを未然に防ぐ目的もあります。productionへ誤った内容の適用は笑えませんので。課題では、実際Terraform導入以前、もとい運用基盤刷新以前の外資就活のインフラリソースに、どのような課題があったのか紹介したいと思います。冒頭で説明した通り、クラウドサービスは便利な反面、管理が不充分になってしまう落とし穴もあり、クラウド上にある外資就活のインフラリソースには以下の課題がありました。IaCが中途半端で完全に宣言的にリソースを定義できていないリソース命名規則が固定されておらず混乱を招くリソース構成が管理されておらず不明瞭環境間で見過ごせない差分が存在するIaCが中途半端厳密にはTerraformは利用されていました。しかし利用は徹底されておらず、新規に作成したリソースのみTerraform管理とされていたり、途中からTerraformの利用を止めてマネジメントコンソールで修正を加えたりされていました。リソース命名規則にムラがあるAWSが発行するランダムでユニークな文字列で構成されたリソース名と、エンジニアが恣意的に命名したリソース名が混在していました。リソースの構成が不明瞭IaCで管理されておらず、どのリソースにどのような振る舞いをして欲しいか不明確な状態でした。prd,stg,devでの乖離が大きいリソース命名でも触れましたが、環境ごとの差分が生じていました。Terraformを導入してみてそれではTerraformの本格導入によって、外資就活のインフラリソース管理がどのようになったのか、課題は解消されたのか紹介したいと思います。IaC文化の定着・AWSリソースの把握AWSリソースの変更を原則Terraformからしか行なっていないため、Terraformのコードを読むことでAWSリソースを把握することが可能となりました。またTerraformの利用を原則とすることで、インフラリソースの定義をGithub上でレビューする習慣がSREチーム内で絶対となりました。そしてこのようにインフラリソースの把握と管理が行えたことで、不具合が生じた場合などに手探りで原因を特定するのでなく、あたりをつけて原因の特定と対応をスムーズに行える心理的に負担の少ない土壌を醸成することができました。リソース命名規則をフィックスname = format("%s-%s-cluster", var.env, var.project)tags = merge(  var.tags,  tomap({ Name = format("%s-%s-cluster", var.env, var.project) }))Terraformのフォーマット関数を利用してリソース名に統一をもたらすことができました。非常に瑣末なことではありますが、「名は体を表す」というように、AWSリソースの役割とリソース名をルール化することは大事です。また命名に関連して、IPアドレスについても整理整頓しました。/16として、EC2やRDS、EKSといったAWSサービスごとに/24のサブネットを作成しています。さらにEC2は第３オクテットが10~19、RDSは20~29という具合に法則を設けています。/24であればネットワーク部が255個と、よほど大規模なサービスでなければ持て余すほどあるため、このように大胆にサブネットを区切り、よりエンジニアにとって直感的なネットワーク構成としました。cidrhostやcidrsubnetといったIPを効率的に管理する関数が用意されており、利用しない手もないので。このようにTerraformを本格導入することで、数々の課題を解消することができました。今回の運用基盤刷新を機に、IaCを導入し、インフラリソースをレビューする実績を残すことができました。今後も外資就活ではインフラリソースをエンジニアが過不足なく引き継ぎながら、機能追加や改修を行なっていくことができるようになったと確信しています。さいごにTerraformを本格導入し、かつAWSリソースを１から構築しなおしたことで、完全なインフラの管理を実現することができました。terraform importして妥協できるところはしようかなぁ」とか「段階的にリソースを置き換えていけば楽なのでは？」といった迷いも当然生じました。インフラがある程度大きくなってしまってから、Terraformを導入するなど整備する場合には、このような移行プランもしっかりと議論する必要があると感じます。この記事ではテクニカルな紹介が少なくなってしまいました...また、まだまだ「これを使ってもっと良くしたい」とか「あそこはこうしなきゃ...」など改善していきたいと考えています。一緒に取り組んでくれるエンジニアの方、募集しております！https://herp.careers/v1/howtv

運用基盤を刷新しました-Terraform本格導入編

こんにちは、SREチームの肥沼です。さて、ハウテレビジョンでは2021年8月に運用基盤を刷新して新しい構成で本番稼働を始めています。特にKubernetesの導入やTerraformの本格利用、Datadogによる可観測性の向上などさまざまな取り組みを行ってきたので今回のブログではそれらの取り組みを一気に紹介させていただきます。まずはじめに本題に入る前に、弊社SREチームを簡単に紹介させていただきます。SREチームは私の入社以前からありましたが、私が入社後、メンバーが一新されて新生SREとして再編成を行いました。私を含めてメンバーは3人で、以下のミッションを掲げて活動しております。継続的な改善の土壌づくり新しいサービスやツールを使った効率化、その民主化など事業継続性の維持とユーザーへの価値提供の最大化コストコントロールや信頼性の維持、向上などまた、弊社は主な事業として、大学生向けキャリアプラットフォームの「外資就活ドットコム」と若手プロフェッショナルを対象としたキャリアプラットフォームの「Liiga」を運営しております。SREチームの活動は、「外資就活ドットコム」「Liiga」の双方にまたがっておりますが、今回の取り組みでは運営の歴史が長く、複雑になってしまった「外資就活ドットコム」を対象としました。今回取り組んだ課題OSやミドルウェア・設定の変更が難しい、手間がかかるこれまではVMを使った運用をしており、EC2インスタンスに対して以前からChefを利用して構成管理を行っていました。ところが、いつからかChefでの定義と実態に差分が生じるようになっていました。理由としては、IaCの文化が開発部に根付かず、EC2に直接SSHして設定を変更することが当たり前となっていたためです。そのため、ミドルウェアの変更をするにも心理的負担が非常に大きいことが問題でした。複数サービスを使った監視やモニタリングMackerel、CloudWatch、PagerDutyなど複数のサービスを利用している状態で、何がどういう意図で設定・通知されているのか整理する必要がありました。可視化が足りず調査に時間がかかるMackerelやCloudWatchで管理が行き届いていないダッシュボードがあったり、形骸化してしまったものが多数存在し、肝心の障害対応の際に生かせていませんでした。リソースコントロール、スケーリングの柔軟性を得たいVMの運用を行なっておりましたが、リソースの余剰が目立っていました。アクセスが集中する際のスケーリングもEC2のAMIや設定を準備したりと手順が多く簡単にできませんでした。深刻な属人化やドキュメンテーションが不足属人的な知識や操作が多く存在し、新規メンバーの活躍の場が少なくなってしまったり、新しいことに挑戦しにくい状態でした。Kubernetesの導入導入理由やはり巷ではKubernetesを導入すべき・でない、などいろいろ言われており、チームでも議論が交わされてきました。例えばECSのほうがいいんじゃないか？などはよくある議論だと思います。弊社では、いくつかの理由で最終的にはKubernetesを導入することに決定しています。理由としては大きく以下があります。コンテナの振る舞いをマニフェストで記述したうえGitで管理できるマニフェストで定義した振る舞いをシンプルに展開できる、リソースコントロールを柔軟にできる、スケーリングが容易にできる強力なエコシステムの恩恵を受けることができる特定のベンダーに依存せず、オープンなものに依存することで拡張性を得ることができるまず、マニフェストがないとコンテナのデプロイはできないためIaCの実践を強制されます。これまでIaCが根付かなかった反省をこれで解消することができると考えました。また、外資就活ドットコムは、デプロイライフサイクルの異なる複数のコンポーネントから成り立っています。そのため、マニフェストを柔軟に記述し、管理できることや、リソースやスケーリングの設定をアプリケーションの定義に近いところで定義できることは大きなメリットでした。何より、クラウドプロバイダにべったりするというよりかは、ベンダーによらないオープンな技術を使っていくことで進化の速さを享受できたり、そもそもエンジニアのモチベーションにもつながってきます。モチベーション大事です。環境ごとのクラスター構成本番環境稼働・検証環境・開発環境でKubernetesクラスターを分けています。これにより検証環境では、本番環境と同等な状態でのアプリケーションの動作確認と負荷試験の結果を受けたキャパシティプランニングができるようになっています。また、開発環境はnamespaceで論理的に区切ることで、アプリケーションの機能開発に対する環境構築を柔軟に行えるようにしています。namespaceで本番環境・検証環境・開発環境を分離する方法も検討しましたが、クラスタ自体が分離されているほうがテストをしやすく、本番環境だけの特別な操作という心理的な負担を減らすことができます。マニフェストの管理はシンプルにkustomizeを利用することで環境差分を吸収して、1つのリポジトリで全マニフェストを管理する方法をとっています。Helmはより柔軟にパラメータの指定ができますが、学習コストが高くマニフェスト管理への障壁になる点を考慮し導入を見送りました。CI/CDCIでは、もともと利用していたCircleCIを利用して、コンテナイメージのビルドまでを担っています。CDにはArgoCDを利用しています。まずは、シンプルに始めたかったので多機能よりもシンプルさを重視しました。またArgoCDによってマニフェストの変更によってクラスタへの展開が行われるため、デプロイはマニフェストに対してコンテナイメージのタグのコミットだけすればよい、という単純な仕組みとなるようにしています。全体の流れとした以下の図のようになっています。CI/CDTerraformの本格利用実はTerraform自体は一部で利用していました。しかし、Terraformでの定義と実際のAWSリソースに乖離があったり、ディレクトリ構成も今後保守していくのは骨が折れる状態でした。これらの理由からTerraformについても、このタイミングでモジュールの設計方針など決めながら新しく構築していくことにしました。どんなことをやったのか改めて以下のような方針で取り組みました。Terraformを利用してインフラを1から構築することインフラは基本的にコードで管理することコード化することで変更に対してのレビューができる、必要とさせる都度ドキュメントを書いて説明するのではなく、インフラの変更はコードの変更を介してレビューされ、歴史が刻まれていく状態になることを重視しました。こうすることで、これまで問題となっていた属人化やドキュメンテーションの課題に対処できます。また、Terraformを使うにしても、AWSのタグの付け方やリソースの命名規則、モジュールの設計など多くの議論がありました。モジュールの設計としては、AWSのリソース変更のただのラッパーではなくそのリソースを作るときのSREチームにとってスタンダードな構成を基本として設計しました。例えば、RDSなどを追加したいときにはそのサブネットやタグのセット、セキュリティグループなど一通りそろえられるような設計としました。こうすることで、あるリソースを構築するときに何が必要なのかがセットになるため、一度モジュールのレビューをしてしまえばあとは構築時にはパラメータに対するレビューだけで済むなどのメリットを受けられます。Datadogの導入複数のサービスや自前の監視サーバーを全面的に廃止して、Datadogを導入して監視・モニタリングを統一しました。使うものを減らし統一することで、目的に早くたどりつけるような状態にしていきたいと考えていました。どんなことをやったのかまずは、Kubernetes基盤への切り替えリハーサル用の環境で導入してトライアルを実施しました。ダッシュボードからLogs、メトリクス、あるいはアラートから横断的に一気通貫で、1つのサービスでできることは大変効率がよく、導入決定にいたりました。また、SREチームだけが監視やモニタリングに向き合うのではなく、以下のようなことを考えていました。SREチーム主導でDatadogの開発組織への平準化を率先問題があったときに、他チームとDatadogを見ながらコミュニケーションを取れるようにしていくことこうすることで、機能開発に加えて、改善もしやすい土壌を整える狙いがありました。さいごにインフラの再構築からKubernetesやDatadogの導入にいたるまで、多くの議論や意志決定があり、途中、苦しいこともありましたが、なんとか刷新することができました。今回は一部の紹介となりましたが、個々にクローズアップした内容など、今後もアウトプットしこうと思います。ところで、今回紹介した課題はほんの一部にしかすぎません。一緒に取り組んでくれるエンジニアの方、募集しております！herp.careers

運用基盤を刷新しました-Kubernetesの導入やTerraformの本格利用などの取り組み紹介

今年の4月に新卒入社した開発部のnawajiです。5月も毎月恒例の社内LT会が開催されたので資料をご紹介いたします。今回は、モチベーション維持,データ間の類似性, Web APIについてをテーマにLTが行われました。1本目「高いモチベーションを保つ SDDについて」始めは, 今年の2月に入社されたプロダクトマネジメント部の @picopicopyさんの発表です。SDD＝高いモチベーションを保つsushi-driven design2本目「Mr.Childrenの“もっとも似ている2曲”の組み合わせを知りたい 🎧」続いては, 昨年の11月に入社された開発部の@t-kikaiさんの発表です。3本目「改めてWeb API入門」最後は, 今年の4月に新卒入社した開発部の@m-bookさんの発表です。今回のLT会より発表者の中からMVPを3度受賞した方に高級な鮨をご馳走する企画がスタートいたしました。@t-kikaiさんでした🎉🎉ハウテレビジョンのLT会は、外部ゲストの参加も大歓迎です🙌 ご興味ある方は、以下からカジュアル面談にご応募いただくか、CTOのGo里宛にDMをいただければ幸いです。皆さんの参加をお待ちしております!

LT会やりました(2021-05)

こんにちは。CTOの 大里です。今年もサマーインターンの時期が近づいていまいりましたので、2020年9月開催したハウテレビジョンのサマーインターンについて振り返りたいと思います。概要昨年のインターンは、9月7日〜14日のA日程と、9月23日〜30日のB日程との2回開催でした。プログラムの内容はどちらも同じで、各日程12~13名の学生が参加してくれました。インターンの内容は前年同様「外資就活ドットコムをさらに進化させる」をテーマに新機能の企画から実装までをやりきるという濃密な6日間でした。コロナウイルス感染対策について本インターンは研修含め六本木オフィスでのオフライン開催となりました。当時も今も新型コロナウイルスが猛威を奮っているため、例年オフラインでインターンを実施している他社でもオンラインでのインターンに切り替えるケースが多い状況でした。しかし、オンラインでは参加学生へのサポートが十分にできず、その結果 インターン参加による成長機会を十分に与えられないという懸念が大きかったこともあり、オンラインかオフラインかは開催ギリギリまで本当に悩みました。最終的に、緊急事態宣言が解除されて8月下旬は感染者も減少傾向であったことから、感染対策を徹底することを前提としオフラインでの開催を決断しました。感染対策としては、参加学生・社員への出社前の体調確認、検温（1Fでの入館時、32Fのオフィス入室時の両方）、手指消毒、マスク着用必須化、個包装の食事提供、十分な広さのある作業スペースの提供など、考えうる限りの対策を実施しました。1day研修9月からのインターンで開発業務にスムーズに入れるよう8月に1day研修を実施しました。外資就活ドットコムのシステムの全体像の理解からMVCフレームワーク、クリーンアーキテクチャ、React/Reduxのモダンフロントエンド、RDBMS、DockerやAWSなど、Web開発に必要な知識全般を駆け足でインプットしました。Web開発経験が少ない方の場合、正直1日で全てを理解するのは難しい内容だったと思います。ただ、社員のメンターが対面でサポートしながら環境構築を行うことで、「とりあえず手元で動かして試行錯誤できる状態」「何か困ったことがあったらどのメンターに聞けば良いか分かっている状態」までは1日で行けたかと思います。1day研修から9月のインターン本番までの期間には個人課題が課され、バックエンドかフロントエンドのいずれかを選んで架空の新機能を実装してもらいました。個人課題で行き詰まった場合はいつでもSlackでテキスト or 通話のコミュニケーションで社員のメンターがサポートする体制を組み、9月のインターンで技術面でのレベルを統一できるようにしました。研修で使った資料は全てGithubにまとめています。github.com6daysインターンDay1初日は参加学生同士の自己紹介と、研修からの約1ヶ月間で実装してきた個人課題の発表から始まりました。バックエンド、フロントエンドに別れ、1人ずつ簡単にデモを見せてもらったり、スクリーンにコードを映して社員がレビューし質疑を行いました。バックエンドはクリーンアーキテクチャ、フロントエンドではReduxやSagaなどのライフタイムの理解にそれぞれ苦戦している人が多く見られましたが、ほぼ完璧に全課題を実装しきっている猛者もチラホラおり、学生とは思えないレベルの高さに社員陣も舌を巻きました。その後、お楽しみのお弁当タイムを挟んでからCEO音成によるプロダクトづくりについてのセッションがありました。外資就活ドットコムがどんな背景で生まれたのか、UsersFirstなサービスを作って運営するとはどういうことか、などついて熱くお話しました。それらを踏まえ、午後は3人x4チームに別れ、チームごとに企画のアイデアを出し合い、チームとして何を作るのかを議論する時間になりました。各チームには社員のメンターが2名ずつ付き、技術面や仕様面でアドバイスしながら企画を固めていきました。Day2 ~ 52日目にはプロダクトマネジメントチームから企画に対する中間レビューがあり、その企画がどんなユーザーの課題を解決しているのか、その課題を解決することの優先度はどうか、なかなか思い通りには動いてくれない学生や企業を動かすためにどう動機づけを設計するか、リリース後の運用負荷についてはどうか…、などの観点でフィードバックしました。実際に多くのサービスを企画・開発した経験がある参加者は多くなく、すんなり企画が固まるチームもあれば一度決まった後に二転三転するチームもありました。企画が固まったチームから設計や実装を進めていきます。限られた期間で最終日のデモまでに動くものを実装するのには各チームかなり苦戦していたようでしたが、中には期間中に20本近いエンドポイントの実装をやり切ったり、スクレイパーを実装して新機能に必要なダミーではない実用的なデータを集めたりと、中途としても即戦力レベルの参加者が技術力を発揮していました。Day6最終日は午前中に実装の仕上げと発表の準備を行い、午後からチームごとに成果発表を行いました。評価ポイントは「ユーザーへの価値」と「技術的挑戦」の2点で、審査員はCEO音成、COO佐々木、現CXO鈴木と開発部エンジニア陣が務めました。各日程の優勝チームには賞金10万円が贈呈されることもあり、各チーム発表に熱が入っていて大いに盛り上がりました。今回は各日程の優勝チームの企画を簡単に紹介します。A日程: 「ユーザー同士のクローズドなコミュニティサービス」外資就活ドットコムの中には、匿名掲示板機能の「外資就活コミュニティ」や優秀なプロフェッショナルにキャリア相談できる「外資就活相談室」などのサービスがありますが、学生同士で仲間を作る機能がありません。そこに目をつけ、学生同士でグループを作りクローズドなやり取りをできるチャットサービスを実装したチームが優勝しました。「ユーザーへの価値」を探るために実際にTwitterのアンケート機能でニーズを調査したり、（一部モックの状態ではあったものの）デモとして動くものをUIも綺麗に整えて発表できており、短期間での成果としては十分過ぎるものでした。B日程: 「クリップしたコンテンツを整理する新機能」外資就活には選考体験記という先輩ユーザーが投稿した企業毎のレポートを閲覧する機能があり、それをクリップして保存する機能があるのですが、「その機能が使いづらすぎる！」というポイントに目をつけたチームが優勝しました。他の多くのチームが全く新しいサービスを企画していたのに対し、このチームだけが既存機能の進化に取り組んでいるのが興味深かったです。振り返って今年もバックグラウンドがさまざまな学生が多く集まり、僕らにとっても刺激的なインターンになりました。一部の例を挙げると、中学時代から個人開発に取り組んでいて受賞経験のある人、企業インターンで2〜3年の開発経験を積んでいてフルスタックなスキルを持っている人、海外大でコンピュータサイエンスを専攻している人、AtCoderでイエローコーダーの人などなど。また、前年は初回のインターンということもあり、色々と至らない点があったなという反省がありましたが、今回はそこの学びから多くのアップデートを実施。毎日美味しいお弁当や軽食の差し入れも行ったり、社員が使っているのと同等のリープチェアやモニターで開発してもらったり、Vagrantを脱却してDockerでクイックに環境構築できるようにしたり、前年以上にインターン中の体験をかなり向上できたかなと思います。参加者の声インターン後、参加者にはアンケートに協力してもらったのでそこで出た生の声を抜粋します。・ 短期間でギリギリできる開発量が設定されていて、それを達成するためのサポートがしっかりしている・ アイデアを提案して実務コードを書き換えるという、かなり実務に近い貴重な経験ができたと思います。・実務経験や他人のコードを読む経験がある人にとっては心から楽しめるインターンでした。ただ、実際のサービスのコードを理解しながら機能追加するのには１週間は短いと感じたので、開発経験が豊富な人にはおすすめしたいです・環境面もとても充実していて、広く清潔なオフィス、ディスプレイの貸し出し、美味しい昼ごはん、おやつの支給、１０万円の支給など、とても恵まれていたと思いました。・今まで見た中で一番関係性が良い職場環境だったと感じました。エンジニアにとって働きやすい環境を追求されているためなのかと思いました。・エンジニアとして働く環境（技術本の支援、テックドリブンなカルチャー）をとても魅力に感じた。また、インターンの参加レポートをブログで公開してくれている学生がおり拝借する許可を頂いて紹介させていただきます。masamichhhi.hatenablog.comtakaki.takeu.ch今年もやりますgaishishukatsu.com昨年を上回る充実した内容になるよう鋭意企画中ですので、Webエンジニアとしての成長を求める方の参加をお待ちしております！

ハウテレビジョン サマーインターン2020

2月も毎月恒例の社内LT会が開催されたので、資料をご紹介します。今回は、①GitHub Actions ②営業台帳のシステム化 ③IaC の3本立てです！1本目「GitHub Actions に入門しました」 speakerdeck.com最初の発表は、毎月登壇されている @Doarakko さん。「そもそもGitHub Actionsとは何か？」から始まり、「GitHubのissueに"ドロー"とコメントすると、遊戯王カードが表示されるGitHub Action」を作ったお話も、とてもわかりやすかったです。非公式ではあるのものの、遊戯王APIなるもの（https://db.ygoprodeck.com/api-guide/）が公開されていること自体初耳でした...。2本目「実録！六本木のベンチャーに秘伝のEXCELを見た！！」 speakerdeck.com2本目は、社内システムを担当されている@yumasukeyさん。EXCELで管理していたために入力ミスも発生してしまっていた営業台帳を、システム化する取り組みについてお話いただきました。今後も「操作ログの保存」「クラウド会計サービスとの連携」等様々な機能を追加されるとのこと。営業台帳の進化が楽しみです。3本目「おや、ハウのインフラのようすが......?」3本目は、昨年11月にSREチームにジョインした @masahirogawa さん。テーマは、「IaC(Infrastructure as Code = インフラ構成をコード管理する文化)」。これまで画面から管理していたAWSリソースをTerraformでコード管理化したことで、様々なメリットを得られたとのこと。ハウのインフラ管理を改善する素晴らしい取り組みです。ハウテレビジョンのLT会は、外部ゲストの参加も大歓迎です🙌 ご興味ある方は、以下からカジュアル面談にご応募いただくか、CTOのGo里宛にDMをいただければ幸いです。エンジニアも絶賛採用中です。採用に関してもこちらからご確認ください👇herp.careers

LT会やりました(2021-02)

どうも、Liigaの開発を行っているkinoshitaです。恒例の社内LT会を1月にも実施したので、そこでのLT資料を紹介いたします。 （LT会は全社員リモートでzoomを使用して行いました。）今回は、tailwindcss、LexRank、Ginkgo、自律神経などのテーマでLTが行われました。1本目「tailwindcss はじめました」昨年4月に入社したフロントエンドエンジニアの  @koki3090 さんの発表です。CSSフレームワークを使ってみての感想を発表いただきました。このフレームワークを使うと、クラス名に直接CSSを書く事ができるようになるそうです。そのせいでコードの見通しが悪くなるなど一長一短があるようですが、面白い技術ですね。2本目「積ん読を消化するために」 speakerdeck.com一昨年12月に入社したサーバサイドエンジニア  @Doarakko  さんの発表です。読みたい記事が貯まってしまうということから、自動文章要約のアルゴリズムを使って要約文章を作ってみるという発表でした。文章要約の技術は、外資就活の記事にも応用できそうなので、@Doarakko  さんの今後に期待します。3本目「ギはGinkgoのギ」 speakerdeck.comSREチームで活躍されてる @8823-scholarさんの発表です。GinkgoというGoのテスティングフレームワークの紹介とともに、TDD・BDDについて発表していただきました。TDD・BDDという概念についてしっかり調べたことがなかったのでとても参考になりました。4本目「在宅中に自律神経が壊れた話」2017年10月に入社したLiigaのエンジニア@YSK616 さんが、自律神経について熱弁を振るってくれました。（技術関係ない） ハウテレビジョンのLT会は技術系でもプロダクト系でも趣味系でも何でもOKのゆるい会です。在宅勤務が続く中で、健康を壊すことはよくあることなので、とても参考になりました。ハウテレビジョンでは、絶賛エンジニア採用中ですので、ご興味ある方は以下をご覧くださいー🙌herp.careers

LT会やりました(2021-01)

どうもこんにちわ。外資就活の開発を行なっているKokiです。今回は12月に開催されたLT会についてシェアしたいと思います！1本目「Liigaイベント課金の裏」Liiga開発部 業務委託エンジニアの@RyoKobashiriさんはStripeについての発表でした。Liigaの新サービスとして、課金性イベントが実装されました。そのイベントの金銭の支払いの際にStripeを使用しており、今回はそのStripeについての歴史や機能についての紹介でした。便利な管理画面やAPIが用意されており、機会があれば触ってみたいなと感じました。2本目「kubernetesのLT」11月からSREチームにジョインした @masahirogawaさんの発表でした。kubernetesの概要や運用する上でのメリット、デメリット、またそのデメリットに対する対策などとても簡潔にまとめられておりました。私自身まだここらへんの知識が皆無だったので、とても有意義な発表でした！3本目「にゃーんとわんわん」 speakerdeck.com@Doarakko さんはある面倒な作業を機械学習を用いて簡略化するという発表でした。動物の識別を機械学習で行なっていたのですが、本当に機械学習を用いる必要性があったのかについて様々なルールベースから考察されており、とてもおもしろい発表でした。4本目「GORM 2.0 のScanは使いやすくなったのか ？」 @huanshenyi さんはgorm2.0のScanについての発表でした。本番環境では起こらないエラーが開発環境では起きてしまう理由について、どのように対処したかなどについて発表していただきました！どうしてもブログ上でシェアできないLTもありますが、ハウテレビジョンのLT会は外部ゲストの参加も大歓迎です🙌ご興味ある方は、以下からご応募頂きカジュアル面談にお越しいただくか、CTOのGo里宛にDM頂いても結構です！herp.careers

LT会やりました(2020-12)

どうも、2020年11月からハウテレビジョンにジョインしたエンジニアの@Syoituです。この記事を書く時点で丁度ジョインしてから一ヶ月半経ちまして、今回の転職は結論から言うと成功でした。その結果を踏まえて、職場を選ぶ際に心掛けた方が良いことの話をしようと思います。ここで言う職場はあくまでエンジニアとして働く環境、楽しく働けるかの話です。自分の転職歴社会人になってから今年で三年目(記事を書く時)、そしてハウテレビジョンはちょうど三社目になります。ほぼ一年に一度くらいのペースで転職してきました。転職活動する際に、大体週三日くらい面接を入れて、特に今年はリモートでできる面接も増えたお陰で、多い時は平日は毎日面接を入れていました。もちろん、できれば転職したくない、同じ会社で長く働きたいのが本音です。転職活動は大量に時間が必要ですし、本当に疲れます。でも会社が採用する技術が自分が求めるものと違う時、どうしても技術を優先してしまいます。転職サービスどう選ぶ現在転職サービスは非常に多くて、自称「エンジニア転職特化」のサービスも少なくありません。私が現在利用してるサービスは以下のものになります。PaizaGReenWantedlyLAPRASFindy優劣を語る訳ではありませんが、この五つのサービスは大体二種類に分けることができます。自己アピールとデータアピール 、ちょっとわかりにくいかもしれませんが自己アピールいわゆるサイト上で自分で履歴書を書いたり、アピールしていくスタイル。上記の五つのサービスの中では、Paiza、GReen、Wantedlyがそれにあたります。データアピールサイト上で自己アピールを書くものもあると思いますが、主にデータ連携でアピールします。連携先は主にGitHub、Qiita、teratailなどです。上記の五つのサービスの中では、LAPRASとFindyはそれにあたります。この自己アピールとデータアピールでは何が違うのか。もう一方のサービス利用者である採用企業側のユーザのポジション（エンジニア/非エンジニアである人事）が違うと私は考えます。自己アピールのスタイルは人事サイドの方が見てて、そしてデータアピールはエンジニアサイドの方が見てます。なので、自己アピールのサービスを通して面接すると、人事の方が最初に面接をしてくださる確率が高く、データアピールのサービスを利用すると、最初にエンジニアの方が面接をしてくださる確率が高かったです。もちろん絶対とは言えません、エンジニアと人事のペアで面接担当してくださることもよくありました。相性が良いのは最初にエンジニアの方が面接してくれる企業でした。最初の面接もしくはカジュアル面談で受ける企業のエンジニアと話をすることで、よりこれからの働くイメージも湧きやすく、早い段階で技術面の相性がわかりますので、お互いに時間ロスになりにくいです。私のような採用する技術目当てで転職する人にとっては、最初にエンジニアとお話ができるのは本当に助かります。面接で注意すべきものリモート面接が増えた今、面接を受ける側にとって、面接で得られる情報もより増えて正直有難いです。極端な例をあげると、もし面接官が自宅でリモート面接してくださるのであれば、面接官の部屋をちょっと見た方が良いです。まるで廃墟のような場所でしたら、その会社の待遇面が優れてるとは考えにくいです。コミュニケーション力冗談はさておき、面接はある意味では、将来一緒に働くことになるかもしれない方々との最初のコミュニケーションでもあります。どんな仕事でも、コミュニケーションがうまく取れなければ仕事になりません。入社後、初めて触るシステムのタスクをもらう際に、特に疑問点は多く出てくると思います。仕様はこうだったのか、それとも不具合だったのか、うまくコミュニケーションが取れる古株のメンバーがいないと、相当苦労すると思います。もし面接中に明らかに話が進みにくいと感じたら、入社後の仕事もある程度進みにくいかもしれません。面接官の身嗜み、精神状態コミュニケーションと少し被る内容でもありますが、面接官を担当する方、特にエンジニアの方の人物像は、入社後の自分もそうなるかもしれないと思った方が良いです。ブランド品を身に付けた方がいいという話ではないのですが、面接を行なっていただく面接官はその会社の顔を張る方でもあります。社内のリモート会議中にだらしない格好をするの分には別にいいですが、社外の人に対して、見るに耐えないような身嗜みでしたら、常識ないのか、適当に面接しているか、もしくは、生活に余裕がないかもしれません。精神状態は一概とは言えないですが、明らかにやつれていれば、何が原因なのか一言確認した方が良いです。笑顔これが一番大事かも知れません。面接官に笑顔があれば、頑張ればコミュニケーションをとれる気がするし、身嗜みもある程度気にならなくなります。面接中にずっと険しそうな顔をしていたら、一緒に仕事するにもプレッシャーが大きいでしょう。タスクの配分はどうなる募集ページに開発言語はGoと書いてあるのに、実際入社後にもらったタスクはほとんどRubyでした。もしくは、リプレースする案件でジョインしたのに、貰ったタスクは殆どレガシープロダクトの運用保守でした。あんまりないことだと思うでしょうけど、実際私は一度経験してますw。入社後、どんな配分でタスクをもらうのか、面接時に担当者とある程度事前に決められた方が良いです。エンジニア採用時に、その人に何をやってもらいたいのかある程度は決まってるはずです。そこで返答が曖昧でしたら、ちょっとタスク内容が期待したものから外れる可能性があります。最後に私が1社目の時、業界で一番マイナーかもしれない技術を使用していました。2社目は、面接時に聞いていた技術とは違う業務が待っていました。3社目のハウテレビジョンは私にとって初めてやりたい技術ができる環境でもあります。Go言語を独学で学んで、実務経験を積みたくハウテレビジョンに入社しました。今のメイン業務はGo(Ginフレームワーク)を使ったシステムの運用保守、新機能の開発をやっています。勉強してきたつもりではありますが、ちゃんとしたGoのユニットテストは書いたことがなくて、今携わってるでプロダクトで業務を通して大変勉強をさせていただいています。弊社、今でも絶賛エンジニア採用中ですので、ご興味ある方は以下をご覧ください🍺hrmos.co

職場を選ぶ際に個人的に心掛けていること

恒例の社内LT会を11月にも実施したので、そこでのLT資料を紹介いたします。今回は、OSSコミット、AWS ALB、Webpack、データ分析、ReactNativeのチューニングなどのテーマでLTが行われました。1本目 「バルサ CL 初戦大勝のその後」 speakerdeck.com最初の発表は @Doarakko さん。バルセロナの圧倒的勝利の余韻からOSSコミットしたお話です。Goのフレームワークであるginのisuue(https://github.com/gin-gonic/gin/issues/2534)を解決するという内容で、Issueの探し方からpull requestを上げるまでの手順についてまとまっているのでとても参考になりました。2本目 「AWS ALBのちょっとイイ話」    AWS ALBのちょっとイイ話  from Yuta Okoshi   www2.slideshare.netSREチームの @YutaOkoshi さんの発表でした。AWS Application Load Balancer(ALB)についてのお話で、直面している技術的負債に正面から向き合うアツいテーマです🔥3本目 「デザインで悩んだのでデータ分析に手を出した」創業メンバーであり、エンジニアとデザイナーの両方のスキルを兼ね備える@YTsuda さんの発表。弊社が運営しているLiigaという転職支援サービスで、ユーザーは何を基準に応募する求人を決めているのかを分析したお話です。「マンガでわかる統計学」により統計学を完全に理解した津田さんのユーザー分析が光る発表でした。4本目 「ReactNative Listのパフォーマンスチューニング」 @RyoFuji619 さんはReactNativeのListのパフォーマンス改善についての発表でした。Listの数が増えるとパフォーマンスに問題が生じることが多々ありましたが、それを見事に解決してくれました。アプリが急に落ちるなどの事象が発生していたので、とても素晴らしい改善でした。ハウテレビジョンのLT会は外部ゲストの参加も大歓迎です🙌ご興味ある方は、以下からご応募頂きカジュアル面談にお越しいただくか、CTOのGo里宛にDM頂いても結構です！絶賛エンジニア採用中ですので、ご興味ある方は以下をご覧くださいー🙌herp.careers

LT会やりました(2020-11)

どうも、CTOの大里です。恒例の社内LT会を10月にも実施したので、そこでのLT資料を紹介いたします。今回は、Rust、コンパイラ、Webpack、AR、ベクトル探索などのテーマでLTが行われました。1本目「Rui Ueyama先生の低レイヤを知りたい人のためのCコンパイラ作成入門をRustでやってみる」ハウテレビジョンOBでLT会に遊びに来てくれた@ymgytさん発表。普段の開発ではなかなか意識することのない機械語へのコンパイルについて、簡単な四則演算の処理を例にお話しいただきました。余談ですが、もともとGolang大好きだった@ymgytさんに「連休中どこか行きましたか？」と聞くと「Rustに留学してました」と返されたことがあります。あと、ハウテレビジョンの開発チームでも、数年前にRustを触ってみたことがありました↓blog.howtelevision.co.jp2本目「ビルド時間を30秒から1秒に縮めた話」今年4月に入社したフロントエンドエンジニアの @koki3090 さんの発表。開発環境でReactのビルド時間が長すぎるという地味だけど生産性に大きく影響する問題を改善したよという内容で、地道にチームに貢献してる感があってとても良い取り組みでした。3本目「Nice to meet you, LiDAR scanner」今年1月からジョインしたバックエンドエンジニアの @yuichi-saito-howtv さんの発表。こちらも普段の業務ではなかなか触れることのないARを使ってみたという内容で、実際に試した際のデモ動画もふんだんに盛り込まれており会場もひときわ盛り上がっていました。4本目「眠気を覚ます方法を見つける」最後の発表は @Doarakko さん。外資就活ドットコムで一番PVのあるページがサービス内検索においては類語検索対応できてないという問題をベクトル探索を活用して改善しようと試みた意欲作でした。@Doarakkoさんは内容もさることながらスライドの構成が秀逸でユーモアがあり、毎度LTが一番ウケてる気がします。ハウテレビジョンでは、絶賛エンジニア採用中ですので、ご興味ある方は以下をご覧くださいー🙌https://hrmos.co/pages/howtelevision/jobs?category=1523160766922473472hrmos.co

LT会やりました(2020-10)

どうも、CTOの大里です。8月から始めたLT会ですが、順調に毎月開催しておりました。大変遅ればせながらですが、9月に開催したLT会の内容をシェアしたいと思います！ちなみに9月はエンジニア職のサマーインターンを2日程開催したため、それに合わせてLT会も2回開催しました。1本目「ベンチャーCTOのお仕事」    ベンチャーCTOのお仕事  from howtelevision   www.slideshare.netハウテレビジョンのサマーインターンに参加してくれた22卒学生向けにお話しており、ハウテレビジョンというWeb系ベンチャーに5年在籍しCTO1年目となった僕が考えるCTOの役割についてお話しました。スライド内でも出てきますが、「CTOは技術系の役職ではありません」という衝撃フレーズがハイライトです。2本目「AWS SSOを導入してみた」    AWS SSOを導入してみた  from Yuta Okoshi   www.slideshare.net5月からSREチームにジョインした @YutaOkoshiさんの発表でした。これまであまり真面目に管理できていなかったAWSのIAMユーザーをSSOを使って一本化したよ、という内容です。社内に複数サービスができたり、本番とステージングなど複数環境が必要になったりしてAWS環境が増えたときでも開発者のアカウントをラクに管理できる優れものです 👏3本目「エンジニア向けデザイン入門」創業メンバーであり、エンジニアとデザイナーの両方のスキルを兼ね備える @YTsuda さんの発表。エンジニアであっても押さえておくべき4つのデザイン原則について分かりやすくレクチャー頂きました。余談ですが、@YTsudaさんに「デザイナーかエンジニアかどっちなんですか？」と聞くと「モテそうだからデザイナーです」と答えます。4本目「遊戯王カードをドローする前に」昨年12月に入社したサーバサイドエンジニア @Doarakko さんの発表です。CLI上に遊戯王カードを表示するコマンドをGoで実装したよ、という力作でした。「遊戯王API」というパワーワードで会場はこの日イチの笑いに包まれました。5本目は「エンジニアだからこそ投資をしよう」 speakerdeck.comSREチームで活躍されてる @8823-scholarさんが、なぜか投資について熱弁を奮ってくれました。（技術関係ない）ハウテレビジョンのLT会は技術系でもプロダクト系でも趣味系でも何でもOKのゆるい会です。インターン生の中には投資は身近でないという人も多かったと思うので新鮮なテーマになったかも知れません。他スライドはお見せできないですが、この他にも以下のようなLTがありました。Liigaで今年リリースした転職エージェント口コミサービスという新サービス立ち上げの裏側ReactNativeForWebについて（発表スライドがReactNativeForWeb製でした）SIerの闇（!?）初心者向けサウナ講座（!!??）どうしてもブログ上でシェアできないLTもありますが、ハウテレビジョンのLT会は外部ゲストの参加も大歓迎です🙌ご興味ある方は、以下からご応募頂きカジュアル面談にお越しいただくか、Go里宛にDM頂いても結構です！https://hrmos.co/pages/howtelevision/jobs?category=1523160766922473472hrmos.co10月〜12月分も、まもなくアップ予定です！！

LT会やりました(2020-09)

どうも。毎年今くらいの時期になるとなぜか新しい自転車を買いたくなってしまい、今年はグラベルロードを注文して現在納車待ちの大里です 🚴‍♂️今日は8月から始めた社内LT会の取り組みについて紹介したいと思います。第1回LT会の模様（弊社オフィス）コロナでオンライン主体の開発チームに6月に渋谷から六本木の新オフィスに移転したハウテレビジョンですが、コロナ禍ではリモートワーク主体となり、対面でのコミュニケーションがめっきり減ってしまいました。4~5月頃の業務に関してはオンラインのコミュニケーションでも問題なく行えていたのですが、徐々にコロナが収束してオフラインのコミュニケーションをする機会が増え始めると「やっぱり対面の方が意思疎通が早かったり発言しやすかったりするなぁ」と感じる場面がありました。社歴の長いメンバーはある程度コミュニケーションの貯金があるので何とかなるのですが、入社したばかり、特にコロナ禍に入社したメンバーはオンボーディングが難しかったのかなぁと感じてます。エンジニア急増でコミュニケーション不足にさらに、ハウテレビジョンではこの1年でエンジニアの人数が倍近くに増え、チームが違うために話したことのない人がいたり、他のチームがどんな技術を使っててどんな施策をやってるのか知らなかったり、ということが次第に増えてきました。エンジニアの人数が少ない頃はスプリントごとに全体でKPTをやっていて、そこで誰からともなくプライベートな話も放り込んでワイワイするみたいなことがあったのですが、KPTの参加者が15人とかになると時間がかかりすぎて発言しづらくなってしまい、会議形態の変更を余儀なくされました。LT会は、他のチームが持っている技術的知見を社内で共有しつつ、LT用に作ったスライドをそのままブログに掲載してしまい、あまつさえピザを食べたりボードゲームしたりしてエンジニア同士の中を深める…、社内の技術力UP採用広報としての発信力UPチーム間のコミュニケーション量UPの一石三鳥の作戦なのです！やったぜ！！こんな感じでやってますLT会は原則オフラインでオフィスのセミナースペースでやります。オフラインのコミュニケーションを促進する施策なのでオンライン参加者向けの中継などは敢えて行わず、参加しなかったメンバーには後日資料が共有されるスタイルです。話すテーマは、技術ネタ、UI/UXデザインネタ、業務でやってることなどの真面目な話から完全に自分の趣味の話などでもOKと、とてもゆるい感じでやってます。ギリギリ業務時間の18時から開始し、LTを始める段階からお酒を飲みながら聞いて良いというルールです。お酒や食べ物は会社から支給されます🍺🍣🍕🍺🍣🍕参加は義務ではなく、基本的には任意参加としています。LTをする登壇者はある程度いないと困るので、自薦がいなければ僕の方から指名して発表してもらう感じです。頻度はまずは月1回からはじめ、もう少し参加者が増えたら頻度を増やしていきたいと考えています。LT会(#001)のスライド紹介第1回はトライアルだったのと夏休みのメンバーが多かったのと体調不良者がちょこちょこいたのとで参加者が少なく、ソーシャルディスタンス取り放題な感じでした😇登壇者にもキャンセルが出てしまいLTは3本になってしまいましたが、今回はその時のLTを紹介していきます。    LT会#001(2020/08/21)bumcru_CTOが最近やってたこと  from howtelevision 1本目は、僕の最近やってる取り組みについて。技術ネタと言うより「3月にCTOになってからこんなことやってました」という報告みたいなLTです。ここ最近、自分がやってる仕事について現場のメンバーに語る場があまりなかったので良い機会になりました。スライドの中でも話していますが、SREチームの立ち上げは開発チームにとってここ最近の大きな第一歩でした。当たり前のことですが、きちんとエンジニアを採用してチーム化することで技術課題の解消スピードが圧倒的に速くなりました。    GitHubのissue管理をいい感じにしたい TakeshiKoenuma @clover0 2020/08/21  from howtelevision 2本目は、来年4月に新卒として入社予定の @clover0 の発表。まだ入社していない彼ですが、今年の2月（学部3年の2月）から週2くらいでSREの仕事をしてくれており、長らく放置されていた積年の課題に取り組んだ内の1つの取組みについて話してくれました。新しくJoinしたメンバーならではの目線でおかしい部分、非効率な部分をガンガン指摘してくれ、オーナーシップを持ってカイゼンを進めてくれてます。    herokuは死んだのか @8823-scholar 2020/08/21  from howtelevision 最後は、昨年8月から一緒に働いているフリーランスの@8823-scholarさんの発表。ハウテレビジョンではほとんど使っていないheroku。PaaSとして一世を風靡したあのheroku。そんなherokuの現在を追った意欲作でした。オフショットエンジニアとPdMのメンバーがゴキブリポーカーに白熱する図まとめ今回は社内LT会をはじめたよ、というゆるい報告でした。今後もLT会をやるたびにその模様を開発ブログで発信していきたいと思います。ゆくゆくは社外の人もお招きし、ハウテレビジョンの開発チームについて知ってもらいがてら親睦を深め、あわよくば採用に繋げていきたい所存です( ˘ω˘)ハウテレビジョンでは、絶賛エンジニア採用中ですので、ご興味ある方は以下をご覧くださいー🙌https://hrmos.co/pages/howtelevision/jobs?jobType=FULLhrmos.co

LT会はじめました

こんにちは。CTOの大里です。2019年9月開催したハウテレビジョンのサマーインターンについて振り返りたいと思います。Goを使ったWebAPI実装についての講義概要今回のインターンは9月2日（月）〜17日（火）までの期間で開催。営業日換算で11日間のインターンに、総勢14名の学生が参加しました。最初の3日間は個人課題パート、残りの8日間がチーム開発パートです。個人課題パート参加した学生のレベルはまちまちで、プログラミング初学者でWebアプリケーションの開発経験があまり無い人もいれば、Web系ベンチャーでインターン経験がありバリバリコードを書いてきた人もいました。最低限の知識レベルを揃えるべく、参加者にはインターン参加前の約3週間を使い、HTML,CSS,Linux Command,Git,SQL,Go,JavaScript,React,PHPについて、基礎的な部分のみ学習してきてもらいました。（学習教材にはProgateを使わせていただきました）その上で、インターン初日は自己紹介などのオリエンが終わり次第 講義を行います。講義の内容は、「ブラウザ」や「URL」「DNS」といったWebの基礎的な理解に始まり、MySQLなどのRDBMS、MVCアーキテクチャ、RESTfulAPIの原則、Goを使ったWebAPIの実装、クリーンアーキテクチャ志向のレイヤードアーキテクチャ、Webフロントエンドの概略、チーム開発におけるgit運用ルールまで、外資就活ドットコムの開発に必要な技術や決め事の大枠を駆け足でインプットするものでした。講義で使った資料はGithubのこちらのリポジトリで公開しています。React/ReduxによるWebフロントエンド開発についての講義外資就活ドットコムのレイヤードアーキテクチャの講義その後、参加者はバックエンドかフロントエンドのどちらかを選択して個人課題に取り組みます。課題の内容は「外資就活ドットコム日記」という架空の新機能の実装で、バックエンドコースでは「日記を投稿する」「日記一覧を取得する」などの一連のAPIの実装を、フロントエンドコースではそのAPIを利用してUIの構築を、3日間で行います。既存の外資就活ドットコムのコードベースを拡張する形で開発を行うため、技術基盤の構築に時間を割かなくて良い反面、プロダクションコードの設計やコーディング作法の理解が必要になります。講義以外でもメンターが手厚く解説参加者の生の声座学パートについて、参加者の感想です。・技術的には、一初心者としては絶望的な難易度だったが、個人課題に取り組む時間が用意されていたため、徐々に慣れることができた。・自分自身初心者だったので初めは戸惑いましたが、日を追うごとに成長出来たのでちょうどいい課題になりました。・フロントとバックで別れており、片方に集中できたのでよかった。ただ、フロント開発経験が全くなかったので難しくはあったと思う。全体的に「難易度が高かった」という声が多かったですが、「成長を実感できた」という声も多く聞かれました。チーム開発パート4日目以降は参加者同士で2~3人のチームを組み、チーム開発に取り組みます。お題は「外資就活ドットコムへの機能追加」で、「どんなものを作るか？」からチームごとに考えて実装までを行います。評価するポイントは「ユーザーへの価値」と「技術的挑戦」の2軸で、優勝チームには賞金5万円が贈呈されます。肩を突き合わせてチーム開発する様子各チームが取り組んだ開発の内容の一部をご紹介します。外資就活Wiki外資就活ドットコムにはコラムやコミュニティ（ユーザー同士の掲示板機能）などがありますが、就活初心者のユーザーはそれらのコンテンツ内に登場する単語（MBB、BIG4、ガクチカ、ES…etc）の意味が分からないことが多くあります。外資就活Wikiは、そうした外資就活特有の単語のWikiをユーザー同士で編集・公開する機能です。この発想はハウテレビジョン社内には無かったもので、参加者自信が外資就活ユーザーであるがゆえに生まれた素晴らしいアイデアでした。結果、外資就活Wikiの開発チームが優勝し、サマーインターン終了後に実際のリリースを目指すプロジェクトが発足し、今も鋭意開発中です。興味のない募集情報を非表示にする機能外資就活ドットコムで最も利用されている機能の1つに「募集をさがす」という機能があります。これは外資就活ドットコムが取り扱っている企業の求人情報の全てを一覧で見ることができる機能なのですが、あるチームは「募集一覧で興味のない募集を非表示にすると、今後表示されないようにする」という機能を実装しました。「募集をさがす」に掲載している募集情報は企業がお金を払って掲載している商品という側面もあるため、これほど思い切った仕様は社内からなかなか出てこないものでしたが、「もっと効率よく就活したい！」というユーザーのニーズを上手く捉えた秀逸なアイデアでした。特別講義「ソフトウェアエンジニアキャリア論」 by 伊藤直也インターン10日目の夜には、ハウテレビジョンの技術顧問・伊藤直也さんによる特別講義が行われました。詳細は外資就活ドットコムのコラムとして近日公開予定ですが、ソフトウェアエンジニアという職業をとりまく業界の動向や、現代のエンジニアとして働く上での心構えについてお話し頂きました。参加者の中にはエンジニアという職業をファーストキャリアに選ぶことに悩みを抱えている人もおり、・エンジニアの将来性というのは本当に知りたかった部分で、そこのところを伊藤さんの意見を聞けたのは貴重な体験をしたと思いました・web業界で長年エンジニアを経験した方の話をきく貴重な機会であり、内容も充実していた・なんどもなるほどなと思わせられる話の内容であった…と、学びの多いセッションとなりました。全体を振り返って初のサマーインターン開催ということで運営側の反省点は多くありましたが、多くの参加者が成長を実感することが出来たと思います。以下に、全体を通した参加者の声を紹介します。・就活用語wikiを初め提案する時、思いつきのようなものだったので少し提案するにも抵抗があったのですが、メンターのTさんがすぐに「めちゃめちゃいい」と言ってくださって、どんな提案でも真剣に向き合って改善のための話し合いを積める雰囲気は、僕はとても好きでした。実際、当初想定していたよりも色々な機能が追加されていって、実装できなかった部分が大半ですが、前向きな姿勢が産んだ可能性だと思います。・社員の方がとても懇切丁寧に指導していただき、非常に開発がスムーズであった。・このインターンをやる前と後では明らかに自身の成長を感じます。このような機会を設けてくださりありがとうございました。・技術レベルが非常に高く、実際に業務で使われている言語やフレームワークでの開発が体験できたため。<中略>また給与や交通費など金銭面的に学生が負担となることがないのもおすすめできる。今年も開催します！ハウテレビジョンでは2020年夏にも、サマーインターンプログラムを開催予定です！gaishishukatsu.com昨年を上回る充実した内容になるよう鋭意企画中ですので、Webエンジニアとしての成長を求める方の参加をお待ちしております！

ハウテレビジョン サマーインターン2019

どうも、大里です。今回は副業のはなしです。（TOP画像だと1週間休み無く毎日働いてる感がありますが、そんなことはないです）話題のツイート友人が副業禁止されてる会社に副業がバレて二度と副業をしないよう上司に言われた。言われた通り翌日から会社に行くのを辞めたら鬼電が止まらなかったとか。友人いわく、何が副業かは俺が決めること。そして二度と副業をしないように言われたのでそうしたのだと。それを聞いてメッチャ笑ったよｗｗ— 茶とらーずの隠れ家* (@chatora_hideout) 2019年7月9日少し前に副業禁止の会社に関するtweetがバズってましたが、ハウテレビジョンでは副業を全面的に推奨しています。もちろん事業的に競合する会社はダメとか、体を壊すような無茶な働き方はダメとか一定の基準はありますが、あらかじめ申請した上で副業しているメンバーは結構います。僕もその1人で、2018年11月から hey という会社で副業エンジニアとして働いており、主にGoで書かれたWebアプリ開発のお手伝いをしています。（厳密にはheyの100%子会社のコイニー社と業務委託契約しています）開発をお手伝いしていたのは新たな決済サービスで、簡単にいうと「スマホがあれば、リアル店舗でツケ払いで買い物できる」というサービスです。https://www.bynw.jp/www.bynw.jpこのプロジェクトは内密に進めていたheyの新規事業だったので、あまりおおっぴらにどんな事をやっているか話せなかったのですが、去る5月にようやくプレスリリースも出て世間にお披露目されたので、副業エンジニアをやってみて分かったことなどをお話していきたいと思います。副業をはじめたのはEMとしての経験値不足を補うためハウテレビジョンに入社してから丸3年たった2018年9月頃、僕は開発部長に正式に任命されました。世にいうエンジニアリングマネージャー（EM）というやつです。それまでも開発チームの代表として、自分自身コードも書きつつ、開発案件の整理や計画・進捗の管理、エンジニア採用などやっていましたが、EMになって一番大きな変化は他のエンジニアメンバーの評価、あけすけにいうと給料を決める立場になったことでした。その時点で僕はエンジニアになって（=プログラミングを始めて）4年半。前職は受託やSESをやっている会社におり、いわゆるWeb系ベンチャーでの経験はハウテレビジョン1社しかない状態。開発チームの中には自分より年上でエンジニアとしての業務経験も豊富なメンバーもいる中で、そんなエンジニアの評価についてメンバーや経営陣が納得する判断をできるかが不安が募ります。副業を考え始めた最大の理由は、「EMとして自信を持てるためにより多くの経験値を獲得したいから」でした。EMの役割とは何か？少し話は逸れますが、EMの役割について私見を述べます。EMに求められるものはチームごとに異なるかもしれませんが、僕が考えるEMの役割はエンジニアメンバーの給料を上げることに集約されます。エンジニアメンバーの給料を上げるためには開発チームが事業インパクトの高い開発をして成果を出す成果の出る開発をスピーディーに進められる開発チームを作る個々人の技術スタックが増え、技術レベルが上がるなどが必要で、これらを実現することで最終的に事業成長に貢献できると考えています。つまり、EMとは開発チームに働きかけることで事業成長に貢献する人、という定義です。より具体的には、開発ロードマップの策定、メンバーとの1on1、トラブル解決の旗振り役、メンバーの採用、開発以外の部署との調整ごと、予算管理などを担当していて、『エンジニアのためのマネジメントキャリアパス』 という本の第6章中で紹介されている「技術部長」のジョブディスクリプションが近しいイメージです。heyとの出会い副業の話に戻ります。heyとの出会いは、2018年夏にWantedlyでスカウトを貰ったことからでした。僕は転職するつもりが無くても面白そうな会社からメッセージを貰ったらカジュアル面談しに行くことがあります。冷やかしのようで気が引けますが、他社の開発チームの内情を聞くこと自体が自分の糧になったりすんですよね。そんなこんなでheyに話を聞きに行った所、Goで開発してる新規事業をやろうとしてるチームメンバーが優秀な人ばかりで、雰囲気もめちゃくちゃ良いオフィス内にタダで飲めるお酒が大量に置いてある(!?)と、自分にとって魅力的な条件が揃っていました。とはいえ当時は転職という状況にはならなかったため、ダメ元で「副業という形でチームに入れてくれないか」とコイニー代表の佐俣さんにお願いしたところお許しを頂けることになりました。どんな感じで副業してるか？まず、ハウテレビジョンでの仕事は引き続き週5フルコミットでやっています。今年の4月 晴れて東証マザーズに上場したハウテレビジョンですが僕が副業を始めた2018年11月時点はまさに上場が決まるか決まらないかという大事なタイミングでした。UXの改善、新商品の開発、セキュリティ課題への対応、上場に備えてのコーポレートサイトのリニューアル、エンジニアメンバーの採用…などの仕事が山ほどある上に、EMとしてメンバーを評価するという重責も担うようになったので副業をするからといって本業を疎かにしてよい状況では全くありませんでしたし僕もそうするつもりはありませんでした。なのでheyの業務は月32時間を目安に基本 土日に行っており たまに平日の早朝や帰宅後にもやるようにしました。開発マシンは私物のMacで自宅作業。完全にフルリモートの副業という感じです。hey開発チームとのコミュニケーションはSlackやGithubで行っており、週に1回 appear.in を使って10分程度のオンラインミーティングをして開発進捗やプロジェクトの状況シェアをしています。（これは平日の昼休憩の時間でやってます）あと、ハウテレビジョンのオフィスからheyのオフィスまで歩いて12分くらいなので新しいメンバーが増えたときなどには一緒にランチに行ったり、リリース後の打ち上げに参加させてもらったりしてます。業務委託費用について。始めは稼働開始と終了をSlackで報告する方式にして実働時間分を請求するスタイルにしていたのですが、スキマ時間で開発することも多く報告が煩雑になってきたので、最近は担当するIssueごとに事前に見積もり工数を出してその月にPRを出したIssueの工数分を請求するスタイルに変更しました。どんな開発をしてるか？「ツケ払い」はWebアプリケーションで、お店で買物をする購入者向けのスマホ画面や、お店のスタッフが決済を登録する画面、運営側が使う管理画面などがあります。技術スタックは、GoVue.jsDockerMySQLTravisCIなどを使っています。話せる範囲で具体的に担当したIssueを挙げると、管理画面の登録・更新機能に入力値バリデーションを追加する店舗担当者がログインを一定回数失敗した場合にアカウントをロックする返済が滞っているユーザーを利用停止にするための管理機能運営向けの管理画面でページングのコンポーネントを実装するGoのErrorハンドリングでerrorsパッケージでWrapするようにするなどがあり、やや大きなものから細かいものまでやっています。↑は自分が担当したIssueがリリースされた時のSlackの様子です。副業をやってよかったことGoと言えば並列化ですが、2つの開発チームに所属することで得られる経験値も倍増しました。技術面での経験値が増えたGoは外資就活ドットコムの開発でも使っていますが、使っているフレームワークやライブラリ、アーキテクチャなどは異なるため、自分の中の引き出しが増えました。知らなかったGoの挙動を発見したこともありました。また、決済という事業ドメインも外資就活ドットコムというメディア事業・人材事業とはまったく異なり、その裏側に登場する技術も普段触れることがないものが多くあります。たとえばツケ払いではSMS送信の機能があるのですが、外資就活の開発では今の所SMSを使う場面はなかったので、もし今後SMSを使って何かしたくなった時に役立ちそうです。マネジメント的な経験値も増えたGithubのIssueにテンプレート機能があることcommitの分け方についてのポリシーコードレビューについてのポリシーといった開発寄りのノウハウや、副業エンジニアとの付き合い方どんなIssueをお願いできるかどのくらいの頻度でコミュニケーションが必要かなどを学ぶことができました。実際、7月に就業体験目的で副業エンジニアの方を1ヶ月だけ受け入れる機会が発生したのですが、その時にも自分が副業をしていて得た知見を活かすことができました。まとめ実際、エンジニアとしてもEMとしてもまだまだ修行が足りませんが、副業をすることで経験値を増やせることは間違いないように思います。最近では転職する前に副業してミスマッチを防ぐようなやり方をしている人も増えてきました。ハウテレビジョンでも副業エンジニアの受け入れは積極的に進めたいと考えているので、GoやReact、ReactNativeなど書きたい！！という人がいましたらいつでもオフィスに遊びに来て下さい 😀募集しているポジション一覧は以下をご覧ください。https://herp.careers/v1/howtv

Howtelevision

GraphQL Fragments を導入してクエリの可読性・保守性を高めた際の学びと落とし穴

新卒エンジニアがGitHub Copilot Business導入に挑戦した話とそこから学んだこと

スプリントゴールとスプリントレビューを導入して、なんちゃってスクラムを卒業できた話

ハウテレビジョンのプロダクトの現在地

新卒エンジニアが最初の半年間について振り返り

新卒エンジニアが開発生産性Conferenceに参加した感想

第二回課題図書知見共有会 ~SQLアンチパターン~

第一回課題図書知見共有会 ~SCRUM BOOT CAMP~

東京ビッグサイトに行ってきました

幕張メッセに行ってきました

『チームトポロジー』の読書会がはじまりました

データ分析基盤のカオスに平穏をもたらした話

SCRUM BOOT CAMP THE BOOK の読書会はじめました

AWS Load Balancer ControllerとExternalDNSを利用しています

Kubernetesへ移行できるSREチームになるまでにやってきたこと

運用基盤を刷新しました-Terraform本格導入編

運用基盤を刷新しました-Kubernetesの導入やTerraformの本格利用などの取り組み紹介

LT会やりました(2021-05)

ハウテレビジョンサマーインターン2020

LT会やりました(2021-02)

LT会やりました(2021-01)

LT会やりました(2020-12)

職場を選ぶ際に個人的に心掛けていること

LT会やりました(2020-11)

LT会やりました(2020-10)

LT会やりました(2020-09)

LT会はじめました

ハウテレビジョンサマーインターン2019

エンジニアリングマネージャーやるにあたり別の会社で副業始めたらめちゃくちゃ良かったぞ、という話

Go/Mongo/KubernetesでSlack Botを作る

GraphQL Fragments を導入してクエリの可読性・保守性を高めた際の学びと落とし穴

新卒エンジニアがGitHub Copilot Business導入に挑戦した話とそこから学んだこと

スプリントゴールとスプリントレビューを導入して、なんちゃってスクラムを卒業できた話

ハウテレビジョンのプロダクトの現在地

新卒エンジニアが最初の半年間について振り返り

新卒エンジニアが開発生産性Conferenceに参加した感想

第二回 課題図書知見共有会 ~SQLアンチパターン~

第一回 課題図書知見共有会 ~SCRUM BOOT CAMP~

東京ビッグサイトに行ってきました

幕張メッセに行ってきました

『チームトポロジー』の読書会がはじまりました

データ分析基盤のカオスに平穏をもたらした話

SCRUM BOOT CAMP THE BOOK の読書会はじめました

AWS Load Balancer ControllerとExternalDNSを利用しています

Kubernetesへ移行できるSREチームになるまでにやってきたこと

運用基盤を刷新しました-Terraform本格導入編

運用基盤を刷新しました-Kubernetesの導入やTerraformの本格利用などの取り組み紹介

LT会やりました(2021-05)

ハウテレビジョン サマーインターン2020

LT会やりました(2021-02)

LT会やりました(2021-01)

LT会やりました(2020-12)

職場を選ぶ際に個人的に心掛けていること

LT会やりました(2020-11)

LT会やりました(2020-10)

LT会やりました(2020-09)

LT会はじめました

ハウテレビジョン サマーインターン2019

エンジニアリングマネージャーやるにあたり別の会社で副業始めたらめちゃくちゃ良かったぞ、という話

Go/Mongo/KubernetesでSlack Botを作る

第二回課題図書知見共有会 ~SQLアンチパターン~

第一回課題図書知見共有会 ~SCRUM BOOT CAMP~

ハウテレビジョンサマーインターン2020

ハウテレビジョンサマーインターン2019