Discover companies you will love

Takuya Natsume

株式会社プレイド / プラットフォームチーム静岡県

Takuya Natsume

株式会社プレイド / プラットフォームチーム

株式会社プレイドにて、チーム横断的な取り組みを行うチームの立ち上げ・リーディングを行なっています。具体的には、チーム横断的なソフトウェアアーキテクチャ改善や技術課題の解決といったエンジニアリング的な取り組みを推進しつつ、「これまでの組織の在り方ではなぜこういった課題に対応してこれなかったのか」という観点からワークフロー

Personal Achievements

個人開発：ブックレビューサービス（フロントエンド）
### 概要 * エンジニアが技術書を購入する際にはネットで検索して探してみることも多いと思うが、"Amazonなどでコメント付きのレビュー数が少なく実際にどのような書籍なのか分からない"・"何かいい書籍がないかと思い検索などを行ってみると毎回同じ書籍を紹介している同じようなブログにたどり着く"といった不満を抱えていた。そこで、技術書籍情報の透明化を目指したサービスを開発しようと思い取り組んでいる。 * 本格的な開発を2021/01頃から初めており、04/09現在ではサーバサイド・フロントエンドの開発が概ね完了している状態である。 * 6月中のリリースを目指して、ソースコードの最終的な調整・確認、リリース方法の学習・選定などを行っている。 * サービスのデモ動画は[こちら](https://youtu.be/KaMyk3Qh8qI)からご覧いただけます。 [![](https://img.youtube.com/vi/KaMyk3Qh8qI/0.jpg)](https://www.youtube.com/watch?v=KaMyk3Qh8qI) ### アピールポイント * 業務では主にサーバサイドを担当している中で、技術研鑽を通してUIの設計・実装を一から行うことができた点 * 既存のサービスやリソースなどをうまく活用しながら、UX・デザインについても自身で一貫して進めた点 * SPAとして実装を行い、リッチな振る舞いを持つUIを必要に応じて実装することができた点 ### 開発 #### フロントエンド（React） * 既存サービスのデザイン・UIを参考にしながらUIを実装 * 既存のデザインをそのまま転用するのではなく、自身のサービスに付随するであろうユースケースやニーズに適したUIとなるように微調整や修正を加えながら実装を進めた * 現状では主要なモデルが4つほど（User・Book・Review・Author）存在する中で、直感的かつシンプルなUIに保つためにオブジェクト指向UIデザインの指針に沿ってUIの設計を行うように工夫した * 各種モーダル実装 * サインアップ・ログイン・レビュー投稿などのフォームはモーダルとして実装 * 画面ベースではなくモーダルベースとすることで余計な画面遷移・デザイン工数を削減するとともに他ページでも同一機能を持つフォームモーダルを簡単に呼び出せるようにすることで、出したいフォームをどこの画面からでも・任意のアクションに紐付けて表示できるようにした * 各フォームではバリデーションを実装しており、ユーザ側に入力不備が分かりやすいように即時反映で表示を行っている * 一部サーバ側でバリデーションをかける必要があるもの（同一アカウント名の入力禁止など）についてはサーバからのレスポンスに応じてバリデーションを実装している * グローバルスナックバー実装 * ReactのContextAPIを活用することで、任意のコンポーネントから呼び出せるグローバルスナックバーを実装 * 紐付けるアクションに応じてメッセージ・分類（error・success・infoなど）を自由に設定できるようにしているため、簡単にどこのコンポーネントからでも任意のアクションに紐付けてスナックバーを表示することができるようにした * 検索UI実装 * 書籍の検索を行うため、様々な条件で検索を行うことができるUIの実装を行った * タイトル・著者・書籍説明などに対するキーワード検索だけでなく、カテゴリー・レーティング・価格・出版年など複合的な条件を入力しでき、それらの値が検索結果に反映されるようなインタラクティブなUIを目指した * 現状では検索結果の書籍順をソートできる実装になっていないため、価格順・レーティング順・レビュー数順などでソートできるようにする機能性を検討している * アカウント画面実装 * ログイン時には時アカウントの各種関連情報を参照することができるUIの実装を行った * 現在では確認できる情報は"自身のレビュー"・"ブックマークした書籍"・"アカウント画像・名称・自己紹介文などのアカウント情報"の3つで、余計な画面遷移をさせないようにタブを用いて各種情報を簡単に切り替えることができるようにした * アカウント情報タブでは自身のアカウントに紐づく画像・アカウント名・メールアドレスなどが編集でき、アカウント削除などの機能性も合わせて提供している * 書籍・著者詳細情報UI実装 * 各書籍・著者の情報やレビューを参照できるUIの実装を行った * 自アカウントのレビューはモーダルを経由して編集・削除が可能で、他アカウントのレビューには"イイね"をつけることもできる * 書籍情報だけでなく書籍に対して投稿されているレビューも一覧で表示でき、"イイね順"などのソーティングも可能 * 現状ではレビュー一覧のページング処理は実装していないが、（幸運にもユーザがこのサービスを利用してくれてたくさんのレビューが投稿されていった場合には）将来的にレビューのページング処理についても追加で実装を行う必要があるかもしれない
Jan 2021
個人開発：ブックレビューサービス（サーバサイド）
### 概要 * エンジニアが技術書を購入する際にはネットで検索して探してみることも多いと思うが、"Amazonなどでコメント付きのレビュー数が少なく実際にどのような書籍なのか分からない"・"何かいい書籍がないかと思い検索などを行ってみると毎回同じ書籍を紹介している同じようなブログにたどり着く"といった不満を抱えていた。そこで、技術書籍情報の透明化を目指したサービスを開発しようと思い取り組んでいる。 * 本格的な開発を2021/01頃から初めており、04/09現在ではサーバサイド・フロントエンドの開発が概ね完了している状態である。 * 6月中のリリースを目指して、ソースコードの最終的な調整・確認、リリース方法の学習・選定などを行っている。 * サービスのデモ動画は[こちら](https://youtu.be/KaMyk3Qh8qI)からご覧いただけます。 [![](https://img.youtube.com/vi/KaMyk3Qh8qI/0.jpg)](https://www.youtube.com/watch?v=KaMyk3Qh8qI) ### アピールポイント * 個人開発として0から取り組む中で、都度発生する課題やエラーについて情報検索・技術研鑽を通して自身で対応することができた点 * DDD開発を実践するために、具象的な実装だけでなく基底として抽象的な実装についても行った点 * 開発を急ぐ一方でテストケースの拡充やCI環境の整備、Docker環境の整備などリリースを見据えた対応を行うことができた点 ### 開発 #### サーバサイド（Kotlin with Spring Boot） * DDD（ドメイン駆動設計）の設計原則の下で各種設計・実装を行う * DDDの設計を行うにあたり、各種Entity・Value Object・Collectionなどの基底クラスを設計・実装した * ブックレビューサービスを作成するにあたり、どのようなモデルが存在しそれらがどのように関わり合っているのかを実際のコードに落とし込むことを意識した * アプリケーションを開発していく中で、当然ながら当初のモデル設計の過不足が明らかになっていった。その際にはアジャイル的に"修正" -> "テスト" -> "リリース"のサイクルを頻繁に回していくことでそれらのギャップをうまく埋めていきながら開発を継続していくことができた * 現状の実装では一部JPAとの兼ね合いのためにSetなどのKotlin提供の仕組みをそのまま利用している実装箇所があり、リファクタリング対象である * モデルに紐づくAPIの実装 * 設計した各モデルに対してRESTにリソースアクセスが行えるAPIを実装した * KotlinやSpring Bootの機能を利用し、シンプルに設計・実装を行うことを意識した * 現状の実装では後述のユーザ関連APIに一部RESTではなく個別用途のAPIが存在しており、リファクタリング対象である * サインアップ・ログイン機能 * サインアップを行うことで、様々な機能性（書籍へのレビュー投稿・レビューの評価・書籍のブックマークなど）を利用できるサインアップ・ログイン機能を実装した * サービスとしてのリリースを目指していることを踏まえて、実際のユースケースやニーズに沿った機能性についても実装するよう意識し（トークンを利用したパスワードリセット機能・アカウントアイコンの設定機能など） * 現状の実装ではユーザ登録・ログインを実行するAPIがDDDの原則を遵守していない箇所も存在し、リファクタリング対象である * サインアップ時には"アカウント名"・"メールアドレス"・"パスワード"を入力してもらいそのページ上でサインアップが完結する仕様になっている。そうではなく（よく他のサービスでもあるように）入力されたアドレスにフォームを送信し、そこをクリックすることでサインアップ完了とする仕様にするべきか検討している * 書籍検索API機能 * 書籍の検索を行うため、様々な条件で検索を行うことができるAPIの実装を行った * タイトル・著者・書籍説明などに対するキーワード検索だけでなく、カテゴリー・レーティング・価格・出版年など複合的な条件を入力し、その条件にマッチした書籍を検索できるようなAPI * 現状の実装ではAmazonやGoogleと比較してキーワード検索の実用性が低く（書籍情報として登録されているワードのマッチのみで判定）、より直感的・感覚的なキーワード検索を行った場合にもイメージに近い書籍がマッチできるように検索機能の性能を見直す必要がある * レビュー投稿機能 * ログイン済みのアカウントが書籍に対してレビューを投稿できる機能性を実装 * 自身のレビューは編集・削除も可能で、他のアカウントが作成したレビューには"イイね"をつけることもできる * 現状では手が回っていないが、レビューに対してコメントを投稿してスレッドのように対話できる機能性も検討している * セキュリティ関連 * jwtを用いた認証・CORSポリシーの設定などをSpring Securityを用いて実装 * サーバサイドをステートレスにするためにセッションなどではなくjwtを認証・認可に利用することとする * パスワードについてはDB格納前の段階でエンコーディングを行い暗号化する * （アカウント機密情報を除く）リソースに対してのGETリクエストは未認証のユーザからも認めるが、リソースの変更を伴うPOST・PUT・DELETEについては認証を必須とするように設定 * リリースを行うにあたり現状のポリシーが適切がどうかを検討する必要があるため、GCPでのリリース作業フェーズの際に改めてサーバサイド側のセキュリティについても確認を行う必要がある * テストケースの実装 * ユニットテストを中心に、ロジックを網羅するテストケースを作成している * ユニットテストだけでなく、必要に応じてシナリオテストなども作成することでデグレーションリスクを低減することを目指している * githubとcircleCIを連携させることでテストを自動化させ、マージ前には確実にテストが実行されるような仕組みを作っている * リリース時の想定として、GCPのCloud Buildとgithubを連携させることでCIだけではなく安定的なCDを行える環境も用意することを考えている
Jan 2021

Ambition

In the future

事業観点と技術観点を兼ね備え、社会にインパクトのある事業を作り育てていく人材になる

株式会社プレイド2 years

プラットフォームチームPresent

Apr 2022 - Present

・サーバサイド Go, typescript, javascript（Node）・フロントエンド typescript, javascript（Vue）・インフラ GCP, AWS

組織横断的な課題に取り組むチームの立ち上げ・リーディング
## チーム編成 - リーダー 1 名（自分） - エンジニア 3 名 - dept head（部長） - security担当 - SRE担当 - 共同創業者兼CPO（支援者） - 領域ごとに存在するボランタリーなチーム（CICDチーム / 監視チーム / ilbraryチーム / etc） ## 背景 - マイクロサービスを推進してきた中で、各プロダクトチームの枠を超えた課題が取り組みづらい体制になっていた - 会社の風土としても「作ったものをメンテしていく」といった文化があまり強くなかったこともあり、オーナーシップが曖昧になりがちな組織横断的な技術課題が取り組まれずに蓄積されてしまっていた - ユーザーへの継続的な価値提供今後も実現できるようにするため、こういった重要課題に取り組む重要性をCPOと議論し、結果として自分がチームの立ち上げ・リーディングを担うことになった ## 詳細 #### 課題 - プライオリティマトリックスでいうところの”緊急な課題”にばかりリソースを向けていることで、”緊急ではないが重要な課題”への投資が疎かにされていた - その結果、技術負債の解消やアーキテクチャの改善が進まず開発速度の低下やモチベーションの低下が発生し、エンジニアリングによるユーザーへの継続的価値提供に支障がではじめていた #### ソリューション - 組織横断的な重要課題に取り組むチームの立ち上げ - 横断分野のステークホルダーを招いたミーティングの定期実施 - 長期的なビジネスニーズの洗い出し - 組織内の課題をさまざまな視点から探索 - エンジニアチームのリソースプランニングを改善 - 健全な形で”緊急ではないが重要な課題”に取り組めるように、予めdept head（部長）に働きかけることで対応リソースをプランニング段階で組み込むように修正 -「できたらやる」ではなく、プランニングの段階で「計画として、これだけのリソースで、これを解決する」ということを定義 - securityタスクフォースの組成 - 主にアドホックに対応していたsecurity関連課題を戦略的に進めることを目的としてsecurity専任のタスクフォースを組成 #### 成果 - 中長期的な取り組みであるため、本質的な成果がユーザーに還元されるのはもう少し先にはなる - securityコアロジックのリアーキテクチャ - 認証・認可周りのコアロジックをgateway serverに切り出すことで共通packageへの依存を解消 - ユーザーへの価値提供をスピード感を持って進められるアーキテクチャに一歩近づく - 各マイクロサービスのオーナーシップを洗い出し - これまでsystem横断的な対応を進める際にissueの管理・トラックなどは行えていなかった - ステークホルダーを巻き込んで各種サービスのオーナーシップを洗い出しつつissue化の方法をまとめ、課題の管理・トラックもできるようになった - 自律性が強い文化が故に組織の課題になっていた横断課題の推進を進められる基盤を築けた - SLOの策定 - これまではユーザーに明確なSLA / SLOを提供できておらず、プロダクトのエンタープライズ導入などを進めていく上で課題となっていた - 各種サービスが依存している担当チームを巻き込む形でコアロジックを実行するsystemのSLOを策定していき、各チームがオーナーシップを持ってプロダクトに対応するSLO策定を推進できる素地を整えた #### 工夫 - 初めての取り組みを力強く推進 - 「この取り組みを通して具体的にどのような価値をユーザーに提供することにつながるのか」・「そのために、どういった課題をどのように解いていくのか」といったことを自分の方でまとめきり、それをベースにチームのメンバーと考えることで明確な価値提供目標とそのために必要な取り組みを提示 - 意思決定者の巻き込み - 取り組みをサポートしてくれていたCPOへの必要に応じた根回しに加え、ビジネスジャスティフィケーションの提示・チームメンバーを巻き込む形でのモメンタム醸成など、意思決定者を動かしていくために必要なアクションを都度実施
Oct 2022
securityコアロジックを切り出したgateway serverの設計・実装・導入
## チーム編成 - PJM兼エンジニア 1名（自分） - エンジニア 3 名 - dept head（部長） ## 背景 - マイクロサービス化にあたり各サービスは独立したsystemになっていたが、認証・認可処理に使われるコアロジックはnpmパッケージにて共有されていた - 今後のサービス拡張や既存サービスのリファクタリングを考え、レガシー化している認証・認可処理を担うnpmパッケージに依存している状態を解消することで、より健全かつ柔軟なアーキテクチャを実現できると考えた ## 詳細 #### 課題 - マイクロサービス化している独立したsystem群であるにも関わらず共有packageを利用することが事実上必須になってしまうことから、ユーザーに価値を還元することを念頭に置いた適切な技術選定ができない - 複数systemに固有の関心事が共有packageに実装されており、処理が複雑になっていた - コアロジックにも関わらずテストが存在していなかったため、手を入れることが難しくレガシー化していた - 共有pakcageへの依存によって、security valunability対応やEOL対応に際するnodeのバージョンアップが困難になっていた #### ソリューション - 共有packageの認証・認可実装を元に事実上の処理要件を洗い出し、gateway serverに実装 - gateway serverはGEK上のpodにsidecarとしてinjectするアーキテクチャを採用し、golangで実装 - ユニットテストを丁寧に整備することで、事実上の認証・認可要件をテストコードとして仕様化 - systemごとのmiddleware設定機構の導入 - 複数systemへの導入を想定し、system毎に有効にしたいmiddlewareをyml形式で指定できる機構を設計・実装 - 対象systemへの導入・検証 - プロダクトチームを巻き込んで対象systemにgatewayを導入 - securityチームを巻き込んで、セキュリティホールがないかを検証する手順の作成・実行 #### 成果 - 導入systemにおいて、共有packageの依存を剥がすことに成功 - 該当systemは今後独自に技術選定やバージョンアップなどを実行できるため、ユーザーへの価値還元をスピード感を持って進められる - 現在各種プロダクトチームを巻き込む形で横展開を推進しており、今後は上記のようなケースがsystem横断的に増えてくる想定 - 組織スケールで継続的なユーザーへの価値提供にコミットしやすくなる環境へ #### 工夫 - PJMとしての貢献 - チームのロードマップを策定〜ステークホルダーとの調整まで一気通貫に行った - ソフトウェア開発とは進めていく中で想定していない課題が見つかるのが常なため、プロジェクトをマネジメントするといってもあくまでアジャイルに、つど柔軟に優先度を見直しながら進めていった - ステークホルダーとの調整を事前に行い、柔軟なプロジェクト管理ができるような体制をスタートから作っていき、健全な形でプロジェクトを遂行できるよう意識した
Aug 2021

株式会社リフカム9 months

エンジニア

Aug 2021 - Apr 2022

・サーバサイド Ruby（Rails）・フロントエンド Typescript（React）・インフラ AWS（EKS）

エディタライブラリのリプレイス
# エディタライブラリのリプレイス@リフカム ## チーム編成 - エンジニア 3 名（自分含む） - CTO ## 背景 - これまでのエディタ関連機能はProseMirrorというlibraryを利用して実装されていたがフリーのlibraryで機能性に乏しく、細かい仕様に合わせて自前実装がなされており、レガシー化していた - UX向上のためにエディタ関連機能を磨き込んでいく必要があったが、現状のままでは機能の拡張や修正は難しいような状態になっていた - 影響範囲が広く難易度が⾼かったためこれまで負債として据え置かれてしまっていたが、自分が引き受ける形でリプレイスに着手していくことにした ## 詳細 #### 課題 - エディタ機能が依存しているProseMirror周りの設計・実装がレガシー化していた - 例えばDB内の各値もProseMirrorの仕様を前提としており、実装とデータ構造が密結合してしまっているような状態だった - エディタ機能を磨いていくことでUXを向上させられる点はチームとしても認識していたが、この負債を解決しないとそういった機能性を磨き込んでいくことができない状況になっていた #### ソリューション - まずエディタ機能が依存していたProseMirrorを有償のFroalaにリプレイスし、仕様の柔軟性や拡張性を担保した - 合わせて、UX改善として着手したかったメンション機能などをリプレイスに合わせてFloalaを用いて実装した - Floalaの機能性だけでは実現できない仕様については、3rdパーティlibraryなども上手く組み合わせて実装した - バックエンドについても、これまでフロントエンドの内部仕様と密結合していた設計を見直し今後は柔軟にlibarryの置き換えや機能の拡張が実現できることを目指した設計に改善した - 既存のデータについては、migrationを実行してより汎用的な表現に変換 #### 成果 - 技術負債の解消により提供価値にフォーカスした取り組みが可能に - 対応が困難なため据え置かれていた技術負債を解消し、エディタ機能というコア機能に一つを磨きこめる状態に持っていけ、ユーザーへの価値をより柔軟かつスピーディに行えるようになった - プロダクト観点からレバレッジを効かせる形でのリアーキテクチャ - リプレイスしたFroalaエディタは汎用的なコンポーネントとして実装したので、新しくエディタ機能を取り込みたい画面や機能にも簡単に導入できるようになった #### 工夫 - 技術的貢献 - ⽐較的難易度の⾼いプロジェクトだったが、主体性を持ってプロジェクトを管理・進捗させることで 1.5ヶ⽉ほどで完了させることができた - キャッチアップ力 - これまでエディタlibraryやフロントエンドを集中的に扱ってきた訳ではなかったが、コニュニケーションや主体的な取り組みをベースに迅速にキャッチアップし、スムーズにプロジェクトを進められた
Aug 2020 - Dec 2022